Seeking clarification on migration of scopes & permissions

Forge Adopting Forge from Connect
1

We are in the process of moving the first of our Connect apps (Confluence) to Connect on Forge, and I have a few questions:

  • To my understanding, there currently should not be a major upgrade required anymore when switching to the Forge based app. We should, however, add OAuth2 scopes already during the transition to Forge, since adding them afterwards will still require an admin approval, while adding them during the Forge switch will allow for the scopes to be mapped, correct?
    → So basically, having these scopes for our first Forge version should allow for a minor update?
permissions:
  scopes:
// Old connect scopes
    - read:connect-confluence
    - write:connect-confluence
    - delete:connect-confluence
// New OAuth2 scopes - mapped
    - read:confluence-content.all
    - read:confluence-content.permission
    - read:confluence-groups
    - read:confluence-props
    - read:confluence-user
    - search:confluence
    - write:confluence-content
    - write:confluence-props
    - write:confluence-space
  • When moving to Forge, with the intention of moving to the native Forge modules at some point, should we already add the following scopes? We would need those as soon as we want to call the GraphQL API from our current remote, correct? Would that impact the minor version migration to Forge? What about the storage and user privacy API scopes?
read:app-system-token	
read:app-user-token
  • It’s unclear to me what you are planning with granular vs. classic scopes. It says it’s recommended to use classic scopes, but I can’t figure out if something like read:incident:jira-service-management or read:customer.detail-field:jira-service-management is actually included in one of the classic scopes OR the scope mapping? The amount of scopes is … mind boggling.

Thanks in advance!
Tobi

cc: @LeonRothYasoon

2 Likes
2

Hey @tobias.viehweger

As long as the scopes declared align to scope equivalence, the migration from Connect to Forge should be eligible to occur without admin approval (as no permission elevation has occurred). When performing this check, the platform will evaluate the scopes declared in the currently installed Connect version with the latest Forge version.

This will still appear as a new major version on the marketplace (i.e. Connect 1.0 → Forge 2.0), however this comparison ensures that an admin approval is not required to perform the associated update.

These alongside app:storage and report:personal-data are Forge-specific scopes which can be added without impact to eligibility to minor updates.

Appreciate this is not ideal. The best consideration here is to evaluate the APIs which you interact with to identify which scopes they require today. Some APIs may only support one type of scope.

3

Thanks for the response, Sean :slight_smile: Just a minor additional question, I was not clear on that - the scopes I listed (e.g. read:incident:…) are not listed on this page: https://developer.atlassian.com/platform/adopting-forge-from-connect/connect-to-oauth2-scope-equivalences/

Would that mean they are currently unmapped? Are there plans to add e.g. the CSM or incident scopes to the mapping?

4

Hey @tobias.viehweger,

Good question! The Incidents REST API was previously inaccessible to Connect apps given its support for OAuth 2.0 scopes only. Given this, we had not reviewed or mapped these scopes.

1 Like
5

Hi @SeanBourke thanks for confirming.
As there is an explicit UNMAPPED state for this in the documentation page, would it be possible to add all unmapped scopes there as well for consistency reasons?

Thanks!
Tobias