Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slack bridge: Implement multiple channels bridges. #739

Merged
merged 2 commits into from
Oct 19, 2022

Conversation

rht
Copy link
Contributor

@rht rht commented Nov 28, 2021

No description provided.

@rht
Copy link
Contributor Author

rht commented Sep 29, 2022

@PIG208 thank you for the review!

@rht
Copy link
Contributor Author

rht commented Sep 29, 2022

I have implemented the requests in the 3rd commit.

@rht rht force-pushed the slack-bridge branch 2 times, most recently from a6dec61 to ff88713 Compare September 29, 2022 10:51
Copy link
Member

@PIG208 PIG208 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Except for a minor issue and the CI failure, it LGTM! Thanks.

msg: Dict[str, Any], zulip_to_slack_map: Dict[str, Any], bot_email: str
) -> Tuple[bool, str]:
) -> Union[str, None]:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can use Optional[str] here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I intentionally didn't use Optional because this is different from the situation with arg=None in function arguments. It'd be better with str | None, but this is not supported in Python <3.10 unless there is from __future__ import annotations. See https://peps.python.org/pep-0604/.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that the future syntax is more explicit (if unavailable), but while the choice is kinda arbitrary, I thought Zulip had mainly settled on Optional in these cases? The typing is exactly equivalent. I don't see the relevance of arg=None cases.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK I will just do what is done in zulip/zulip.

Copy link
Contributor

@neiljp neiljp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rht Always interested to see more bridge extensions 👍

The other review pushed it onto my radar, this is only from the perspective of reading the code.

msg: Dict[str, Any], zulip_to_slack_map: Dict[str, Any], bot_email: str
) -> Tuple[bool, str]:
) -> Union[str, None]:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that the future syntax is more explicit (if unavailable), but while the choice is kinda arbitrary, I thought Zulip had mainly settled on Optional in these cases? The typing is exactly equivalent. I don't see the relevance of arg=None cases.

@@ -18,23 +18,25 @@ ZULIP_MESSAGE_TEMPLATE = "**{username}**: {message}"
SLACK_MESSAGE_TEMPLATE = "<{username}> {message}"


def check_zulip_message_validity(
def get_zulip_message_slack_channel(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may be a difference in how (human) languages name variables, but I'd choose something closer to slack_channel_for_zulip_message.


stream_name = msg["display_recipient"]
topic_name = msg["subject"]
stream_topic = stream_name + "-" + topic_name
stream_topic = f"{stream_name}-{topic_name}"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The f-string formatting is an improvement, but reading this I wondered if you'd considered using a stream-topic tuple in your dicts instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Converted to tuple.

Comment on lines 145 to 146
print("MAKE SURE THE BOT IS SUBSCRIBED TO THE RELEVANT ZULIP STREAM(S)!")
print("MAKE SURE THE BOT IS SUBSCRIBED TO THE RELEVANT SLACK CHANNEL(S)!")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good to include, but I think as a user, seeing these two lines 'shouting' at me with a lot of common text, I might not notice that they're subtly different. Maybe an (expanded) formatting on three lines relating to 1) common subscribe text 2) zulip stream(s) 3) slack channel(s) ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have combined the 2 lines into 1 sentence.

Comment on lines +11 to +12
# Mapping between Slack channels and Zulip stream-topic's.
# You can specify multiple pairs.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd be inclined to give a 'multiple pair' as an example, so the format is obvious. Or maybe more than one "pairs" section, with some commented out, as alternative examples.

Then maybe even multiple examples of how it could be used. eg. multiple slack channels -> many topics in one stream, etc

@rht
Copy link
Contributor Author

rht commented Sep 30, 2022

I have implemented the requests and tidied the commits.

@neiljp
Copy link
Contributor

neiljp commented Oct 1, 2022

@rht I'm not sure how much detail is expected here before merging, but other than the checks above (one needing fixing - static-analysis), has this been tested and if so how?

@rht rht force-pushed the slack-bridge branch 2 times, most recently from 3b161d2 to 3bb52f8 Compare October 1, 2022 01:41
@rht
Copy link
Contributor Author

rht commented Oct 1, 2022

The static analysis test has been fixed.

has this been tested and if so how?

I tested this on a live Slack workspace and CZO. I have retested just now, just in case if the refactor causes any regression.
See https://chat.zulip.org/#narrow/stream/7-test-here/topic/.3C-.20slack-bridge.20general and https://chat.zulip.org/#narrow/stream/7-test-here/topic/.3C-.20slack-bridge.20general

"pairs": {
"C5Z5N7R8A -- <Slack channel; must be channel id>": {
"stream": "test here",
"topic": "<- slack-bridge",
Copy link
Member

@timabbott timabbott Oct 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a way to specify "Use the slack channel name as the topic" here? Could be nice to support substitution of the Slack channel name with a syntax like "slack: {channel_name}.

The other feature that might be nice is to support the special key default to be used for any Slack channels not listed here, so you can just have a single map for a whole Slack instance. But might be better as a follow-up feature.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be nice to support substitution of the Slack channel name with a syntax like "slack: {channel_name}.

For a few number of pairs, users can specify that pattern by themselves explicitly. Adding this feature adds more complication to what the config can be, and requires more documentation

I haven't encountered >40 Slack channels pairing use case. The original use case is to bridge Julia Slack to Julia Zulip for content preservation, and they wanted to do so for only a few of the channels they are comfortable with being preserved. If this is needed soon, I can do it a follow-up PR.

@timabbott timabbott merged commit 582e973 into zulip:main Oct 19, 2022
@timabbott
Copy link
Member

Merged, thanks @rht!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants