When your app is installed into multiple workspaces and/or by multiple users, the er_id can be any of the installed users' ones. 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. The new "actor" IDs remain the same for interactivity events such as slash commands, global shortcuts, etc. You should be curious about the difference. 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. Please refer to #855 or the details of the changes. These properties are optional, so all the existing Authorize / AsyncAuthorize sub classes are expected to continue functioning without any code changes.Īlso, this version includes the fix for the existing bug where the user_id can be absent when both bot_token and user_token exist. user_scopes: the scopes associated with the user_token this can be absent when user_token does not exist.
These properties are used to associate specific scopes with bot_token and user_token, and the built-in InstallationStore automatically resolves them. In v1.17, two new optional properties bot_scopes and user_scopes have been added to the AuthorizeResult / AsyncAuthorizeResult classes. Pre-releaseone month ago New Features Updates on AuthorizeResult properties
0 kommentar(er)
