Our method has an incompatible signature and cannot be validly typed
as an override.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
(cherry picked from commit 4703aed86f)
These are the changes that are backwards compatible with the 2024
style.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
(cherry picked from commit 653b0b0436)
Apparently some exports have a weird `ObjectId("idstring")` typed
value here, that stringify to the actual string.
(cherry picked from commit b249830715)
1. Fetching from the `/users.list` endpoint is supposed to use
pagination. Slack will return at most 1000 results in a single
request. This means that our Slack import system hasn't worked
properly for workspaces with more than 1000 users. Users after the
first 1000 would be considered by our tool as mirror dummies and thus
created with is_active=False,is_mirror_dummy=True.
Ref https://api.slack.com/methods/users.list
2. Workspaces with a lot of users, and therefore requiring the use of
paginated requests to fetch them all, might also get us to run into
Slack's rate limits, since we'll be doing repeating requests to the
endpoint.
Therefore, the API fetch needs to also handle rate limiting errors
correctly.
Per, https://api.slack.com/apis/rate-limits#headers, we can just read
the retry-after header from the rsponse and wait the indicated number
of seconds before repeating the requests. This is an easy approach to
implement, so that's what we go with here.
(cherry picked from commit f81e514d07)
The bug we're fixing here leaks information by returning an "invalid
subdomain" error when an attempt is made to log in to user@example.com
on a subdomain X when user@example.com does not exist on X, but does
on another subdomain Y.
This allows an attacker to determine that a certain email address has an
account on the server.
Instead, this should just return a regular authentication error.
In Slack webhook integration setup, the only scenario where a message
payload contains a channel mention without the channels name is when the
user mentions a private channel.
e.g <#C07AVLQ3AUQ|>
This commit updates the string we use for such mention to "private Slack
channel" for better clarity.
(cherry picked from commit f89881d843)
Previously, the notification message only informed users that the
integration URL was registered with Slack's Event API. However, it might
be misleading to send an "integration is successful" message when this
happens because we didn't verify that the token has the required scopes
or if the Slack token is even added to the URL at all.
Now that the integration also verifies the `slack_app_token`'s scope,
it's now more appropriate to send a notification message like
`get_setup_webhook_message` to let the user know that the setup is
indeed successful.
(cherry picked from commit 059782bb9f)
This commit makes the Slack incoming webhook use the original
`convert_slack_formatting` and `convert_slack_workspace_mentions` from
`slack_message_conversion.py`. Previously those were not refactored out
into two smaller functions yet.
Fixes part of #30827.
(cherry picked from commit c6fd0ba424)
Previously the `check_token_access` is called for every request we get
from Slack webhook, this may introduce significant latency.
This commit moves `check_token_access` to the same condition for when we
need to handle Slack challenge handshake so that we only do API token
check once per URL registered.
Additionally, we now check for the specific scopes that we need to run
the Slack webhook integration (SLACK_INTEGRATION_TOKEN_SCOPES).
Fixes part of #30827.
(cherry picked from commit f2599bf33d)
Previously, the `check_token_access` function had a hardcoded
`required_parameters` variable because it was only used in the Slack
data importer. This commit refactors `required_parameters` into a
function parameter, enabling the function to check a Slack token’s scope
for other purposes, such as Slack webhook integration.
Additionally, this commit changes the Slack API call in
`check_token_access` from `teams.info` to `api.test`. The endpoint is
better suited for this purpose since we're only checking a token’s scope
using the response header here.
(cherry picked from commit a746be807f)
This prep commit extracts the logic for converting Slack formatted text
into Zulip friendly markdown from `convert_to_zulip_markdown` into a new
helper function, `convert_slack_formatting`.
This is done to make reformating logic be reusable else where such as in
the Slack webhook or Slack incoming webhook.
(cherry picked from commit 6543dadd0f)
This prep commit extracts the logic for reformatting Slack mentions into
Zulip mentions from `convert_to_zulip_markdown` into a new helper
function, `convert_slack_workspace_mentions`.
This is done to make the reformatting logic be reusable else where such
as in the Slack webhook or Slack incoming webhook.
(cherry picked from commit 4b472611d0)
This prep commit moves `convert_to_zulip_markdown` and
`convert_markdown_syntax` so that they appear after the various
helper functions used in the main logic for converting Slack
messages to Zulip's formatting. This adjustment aligns with code
style conventions, improving readability.
The change also prepares the codebase for reusing Slack text
reformatting logic in the Slack incoming webhook.
(cherry picked from commit ff4d5daef4)
This commit refactors `render_attachment` and `render_block`
out of slack_incoming.py to promote reusability.
The primary motivation for this refactor is to add support for
converting integration bots messages in Slack exports, which could use
the same functions.
Part of #31311.
(cherry picked from commit 92437b4ab5)
The doc now shows instructions to setup the integration using
Slack's Events API instead of the legacy Outgoing webhook
service.
Co-authored-by: Alya Abbott <alya@zulip.com>
Co-authored-by: Lauryn Menard <lauryn@zulip.com>
(cherry picked from commit 82e0468071)
A Slack fail condition occurs when we don't respond with HTTP 200 within
3 seconds after Slack calls our endpoint. If this happens, Slack will
retry sending the same payload. This is often triggered because we need
to perform callbacks when converting messages. To avoid sending the same
message multiple times, we block subsequent retry calls from Slack.
This commit returns early HTTP 200 response as soon as we get any retry
calls from Slack.
Part of #30465.
(cherry picked from commit 42a22e6aaa)
Payloads from Slack's Events API don't include human-readbale
information for a Slack username and for Slack channels.
This commit makes the Slack integration callback to the relevant
Slack API endpoints for that information.
Fixes#30074.
(cherry picked from commit c54d90e5c7)
This commit adds 4 new payload fixtures to the Slack
integration for messages we don't process properly yet:
- Messages with code blocks.
- Messages with overlapping text formatting (e.g, bold
and italic).
- Messages with formatted mentions.
- Messages with quote blocks.
The follow-up plan to add support for these kind of
Slack messages is tracked in #30827.
Part of #30465.
(cherry picked from commit 1ebbe2fd99)
This updates the Slack webhook integration to handle the Slack Events
API[1], while maintaining backwards compatibility with Slack's legacy
Outgoing Webhook service.
The Events API introduces the "challenge" handshake[2] to verify and
add a new webhook URL for them to call. This commit adds a handler for
the challenge handshake.
Additionally, this commit reformats incoming payloads using the Slack
text reformatter from `slack_message_conversion.py`. There is some
duplicative code here because of the difference in Slack export data
and Slack's webhook payload.
Part of #30465
[1]: https://api.slack.com/apis/events-api#using-events-api
[2]: https://api.slack.com/apis/events-api#handshake
(cherry picked from commit f29312ce03)
Apparently `.data("category")` would be come back as a single-element
array for some French translations, rather than a string.
We fix this by using `.attr("data-category")` across this file, which
is our preferred coding pattern anyway.
(cherry picked from commit 77cac403ee)
Currently, we're unable to convert messages from Slack's integration
bots because this message subtype doesn't come from a Slack "user", that
is they don't have a Slack user profile.
This is a preparatory change to support converting Slack's integration
bot messages. This commit artificially creates Slack user data from the
integration bot's "profile" so that we can create a corresponding Zulip
user for them.
Part of #31311.
(cherry picked from commit f988412394)
