feat(slack): Request extended OAuth scopes on production install#114091
feat(slack): Request extended OAuth scopes on production install#114091alexsohn1126 merged 6 commits intomasterfrom
Conversation
The production SlackIntegrationProvider only requested identity_oauth_scopes, omitting app_mentions:read, channels:history, groups:history, and assistant:write. Without app_mentions:read Slack does not deliver app_mention events to the bot, so the @mention-driven Seer Explorer entrypoint never fires for production installs. Union extended_oauth_scopes into the production scope set, matching what SlackStagingIntegrationProvider already does, so newly installed and reauthorized apps grant the scopes needed by Seer Explorer. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Collapse the separate extended_oauth_scopes frozenset into the canonical identity_oauth_scopes so the production install requests a single, flat scope list. This replaces the prior union-based approach with one source of truth and removes the implication that the additional scopes are conditional. extended_oauth_scopes is left as an empty frozenset because SlackStagingIntegrationProvider still references it; its override now ORs identity_oauth_scopes with an empty set, so behavior is unchanged. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Explain why the empty frozenset still exists: it is the place to stage new scopes for testing via SlackStagingIntegrationProvider before promoting them to identity_oauth_scopes. Without this comment, the empty collection reads as dead code. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
========== DO NOT MERGE =============== DO NOT MERGE UNTIL APP UPDATE HAS BEEN PUBLISHED ========== DO NOT MERGE =============== |
The four scopes promoted into identity_oauth_scopes already have SlackScope enum constants defined; reference those instead of the raw strings to keep a single source of truth and stay consistent with how they were declared previously. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
| # Stage new scopes here to test them via SlackStagingIntegrationProvider | ||
| # (which unions these into its install scopes) before promoting to | ||
| # identity_oauth_scopes. Empty in steady state. | ||
| extended_oauth_scopes: frozenset[str] = frozenset() |
There was a problem hiding this comment.
clever! I like this pattern, do we want to rename it something like staging_oauth_scopes to be explicit about its usage?
| SlackScope.CHANNELS_HISTORY, | ||
| "groups:read", | ||
| SlackScope.GROUPS_HISTORY, | ||
| "users:read", |
There was a problem hiding this comment.
TBH I don't know how we guard against this fully, but we should probably make it explicit for future integration devs that these new scopes must always be checked before using them.
Since its possible that some organizations never reinstall, We don't want to break their flows.
There was a problem hiding this comment.
thinking about it more, it might actually be easier to enforce a pattern of checking even the existing assumed scopes rather than delineate between our re-publishing of the slack app 🤷 all of that is not within scope but a comment could be helpful in the interim
There was a problem hiding this comment.
that's a good idea, also coding agents may also pick up that pattern if we do it for existing scopes. let's add a comment for now as you mentioned: e047126
…4091) we have the approval from slack to publish the updated version of our slack app with upgraded permissions. when we launch, we will need to request upgraded permissions with the production slack app. we now include the new permissions that we'll be approved for in the list of permissions we request. we will keep the `extended_oauth_scopes` and the logic behind the staging app, so in the future, if we want to test out a new scope, we can use the staging app. DO NOT MERGE UNTIL APP UPDATE HAS BEEN PUBLISHED completes iswf-2551 --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
we have the approval from slack to publish the updated version of our slack app with upgraded permissions.
when we launch, we will need to request upgraded permissions with the production slack app. we now include the new permissions that we'll be approved for in the list of permissions we request.
we will keep the
extended_oauth_scopesand the logic behind the staging app, so in the future, if we want to test out a new scope, we can use the staging app.DO NOT MERGE UNTIL APP UPDATE HAS BEEN PUBLISHED
completes iswf-2551