A framework to build Slack apps using Python
Test code improvements:
AuthorizeResult propertiesIn 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 existuser_scopes: the scopes associated with the user_token; this can be absent when user_token does not existThese 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 https://github.com/slackapi/bolt-python/pull/855 or the details of the changes.
contextStarting 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.
user_token_resolution optionRelated 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.
before_authorize optionTo 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_()