chore(deps): bump slack-bolt from 1.15.2.dev0 to 1.17.0

[dependabot]

Bumps slack-bolt from 1.15.2.dev0 to 1.17.0.

Release notes

Sourced from slack-bolt's releases.

version 1.17.0

New Features

Updates on AuthorizeResult properties

In v1.17, two new optional properties bot_scopes and user_scopes have been added to the AuthorizeResult / AsyncAuthorizeResult classes. These properties are used to associate specific scopes with bot_token and user_token, and the built-in InstallationStore automatically resolves them.

• bot_scopes: the scopes associated with the bot_token; this can be absent when bot_token does not exist
• user_scopes: the scopes associated with the user_token; this can be absent when user_token does not exist

These properties are optional, so all the existing Authorize / AsyncAuthorize sub classes are expected to continue functioning without any code changes.

Also, this version includes the fix for the existing bug where the user_id can be absent when both bot_token and user_token exist.

Please refer to slackapi/bolt-python#855 or the details of the changes.

New actor IDs in context

Starting in v1.17, context objects in middleware and listeners provide a few new properties -- actor_enterprise_id, actor_team_id, and actor_user_id--, in addition to existing enterprise_id, team_id, and user_id. You should be curious about the difference. The new "actor" IDs remain the same for interactivity events such as slash commands, global shortcuts, etc. The key difference can appear when your app handles Events API subscription requests such as "app_mention" and "message" events in Slack Connect channels and/or when your app is distributed, and it has multiple workspace installations.

When your app is installed into multiple workspaces and/or by multiple users, the context.user_id can be any of the installed users' ones. Also, if your app is installed into multiple workspaces plus your app is added to a Slack Connect channel shared by those organizations, context.enterprise_id, context.team_id, and context.user_id are associated with any of the workspaces/organizations. Therefore, the tokens provided by bolt-python are still correct, as the tokens are associated with any installations for the received event.

However, when a user mentions your app's bot user in the Slack Connect channel, your app may desire to quickly check if the user (let us call this user "actor") has granted the app with the user's scopes. In this scenario, context.user_id etc. does not work. Instead, you must write your code to identify the "actor"'s workspace and user ID. The newly added "actor" IDs can easily help you handle such patterns. You can rely on the "actor" IDs as long as they exist. In other words, note that they can be absent for some events due to the lack of response data from the Slack server side. Such patterns can be improved by either SDK updates or server-side changes in future versions.

New user_token_resolution option

Related to the above, we added a new option called user_token_resolution: str for App / AsyncApp initialization. The available values for the option are "authed_user" and "actor". The default value is "authed_user", which is fully backward-compatible.

When you set "actor" for the option, your OAuth-enabled app's authorize function can behave differently. More specifically, the authorize function receives all the "actor" IDs. The built-in InstallationStore-based authorize tries to resolve the user token per request using "actor" IDs instead of context.user_id.

Setting "actor" for this option can be beneficial for the apps that require all the users to grant the app some use scopes. In this scenario, your app can easily identify the users who haven't installed the app with sufficient user scopes just by checking the existence of the user token and user scopes in the context.authorize_result object.

If your app does not request any user scopes when installing the app into a workspace, configuring this option does not have any effect on your app.

New before_authorize option

To skip unnecessary workload in a bolt-python app, now you can use before_authorize middleware function for it. Let's say your app receives "message" events but there is nothing to do with subtyped ones such as "message_changed" and "message_deleted". Your authorize function looks up installation data in your database and performs auth.test API calls. In this case, before_authorize can enable the app to skip the authorize operations for subtyped message events this way:

def skip_message_changed_events(payload: dict, next_):
    if payload.get("type") == "message" and payload.get("subtype") in ["message_changed", "message_deleted"]:
        # acknowledge the request and skip all the following middleware/listeners
        return BoltResponse(status=200, body="")
    next_()

Changes

• #855 #858 Enhance AuthorizeResult to have bot/user_scopes & resolve user_id for user token - Thanks @​seratch
• #854 Introduce actor enterprise/team/user_id for Slack Connect events - Thanks @​seratch

... (truncated)

Commits

• f52b7ff version 1.17.0
• c15141e version 1.17.0rc4
• 48dd31e Add before_authorize middleware (#869)
• 12aae7f version 1.17.0rc3
• 8334d17 Improve token rotation error handling and installation error text (#861)
• 84bb73d version 1.17.0rc2
• fbba6cd Fix a #855 bug where user_scopes exist even when user token is absent (#858)
• a301d3a version 1.17.0rc1
• 01ff59e Set valid Chalice version range (#856)
• 65d1435 Introduce actor enterprise/team/user_id for Slack Connect events (#854)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

The following labels could not be found: pip, dependencies.