-
-
Notifications
You must be signed in to change notification settings - Fork 377
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
Conversation
@PIG208 thank you for the review! |
I have implemented the requests in the 3rd commit. |
a6dec61
to
ff88713
Compare
There was a problem hiding this 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]: |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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/.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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]: |
There was a problem hiding this comment.
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( |
There was a problem hiding this comment.
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}" |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Converted to tuple.
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)!") |
There was a problem hiding this comment.
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) ?
There was a problem hiding this comment.
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.
# Mapping between Slack channels and Zulip stream-topic's. | ||
# You can specify multiple pairs. |
There was a problem hiding this comment.
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
I have implemented the requests and tidied the commits. |
@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? |
3b161d2
to
3bb52f8
Compare
The static analysis test has been fixed.
I tested this on a live Slack workspace and CZO. I have retested just now, just in case if the refactor causes any regression. |
zulip/integrations/bridge_with_slack/bridge_with_slack_config.py
Outdated
Show resolved
Hide resolved
zulip/integrations/bridge_with_slack/bridge_with_slack_config.py
Outdated
Show resolved
Hide resolved
"pairs": { | ||
"C5Z5N7R8A -- <Slack channel; must be channel id>": { | ||
"stream": "test here", | ||
"topic": "<- slack-bridge", |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
zulip/integrations/bridge_with_slack/bridge_with_slack_config.py
Outdated
Show resolved
Hide resolved
Merged, thanks @rht! |
No description provided.