Action required: Update scopes for Forge and OAuth 2.0 (3LO) apps

Announcements
, ,
24

Hi @michelegranato what exactly do you mean with “nothing happened”? Have the new scopes not been adopted? Did you get an error message?

26

exactly.

the deprecated scopes were not replaced by new one designed.

no error messages shown

27

Hey @michelegranato, I had the same issue. I had to remove the old scopes before the new ones where recognized as missing. I then had to run forge lint --fix twice in order to get all required scopes added to the manifest. Looks like this gave me the full set of the newly required scopes.

1 Like
28

Hello!

Is there some documentation that maps the old permissions to new ones so I can just go through and find the ones I need? I went into that update flow but it made no sense so I cancelled that for now. It seems like some of the scopes I was using just don’t exist at all anymore as well like the read:jira-work and write:jira-work? We need those because we use them to auth into an App within JIRA.

If that update flow is supposed to show us the mappings I think it should at least tell us what the old scope was that we are removing because right now I just see a description of a scope and a list of like 100 things. Also the filters list closes every single time you select one making it extremely tedious to filter this massive scope list.

29

@tbinna @FatmehShuman @jscalise for Forge a new version of the app will need to be installed once the scopes have been updated with the new granular scopes and admin nad end user consent is needed thereafter. For 3LO apps when you update your app scopes the existing consent grants would not be invalidated. This is something we would enforce at the end of the deprecation period and we will communicate this step before we do so. Our engineering team is currently checking if the refresh tokens impact this expected behaviour

30

Hi @JuliaDaehne - Can you double check if the statement for 3LO apps is actually correct? Currently, when you request any new/changed scopes from users, all previously added scopes are removed. Also see my question here related to this. Thanks

31

Hi @JuliaDaehne,

I am facing two issues as part of the new scope implementations for OAUth2 APIs.

  • Adding “offline_access” scope in the auth url is causing 400 error for Webhook Creation API. See my question here. If I remove this scope then everything is working fine(except I won’t get refresh token which I will need to issue new access_token)

This sounds super weird BUT it’s exactly what is happening right now with me.

Another similar sort of issue:

  • adding “read:label:jira” is causing 400 errors in other APIs(below)
POST /rest/api/3/search
POST /rest/api/3/webhook

Again, If I remove this scope then everything is working fine(except I won’t be able to call Labels API which I need as part of the integration). See my question here.

Is there anything I am doing wrong because this seems super weird to me.

1 Like
32

Also, is there a way to create a new App with the current (old) scopes for right now? The JIRA app we are using does not yet support the new scopes and I am trying to create a new App for it to auth into.

33

Hi @AlexHofer old and new scopes are both supported at this stage. However, we would recommend adopting new scopes to avoid later migration if possible

34

@LukasGotter the new scopes would be adopted but whether or not a new consent is required for the new scopes is up to you at this stage - this will be restricted towards the end of the deprecation period

35

@JuliaDaehne I saw they were supported but I don’t see an option to add the old scopes in. The JIRA app I am integrating with does not support the new scopes yet. I don’t mind doing the migration later on as we will need to do it anyways for a different integration. I would just like to make a new app with the old scopes for right now, can you guide me towards where I could do that? Thank you!

36

Hi @michelegranato, could you please share the version of node used and forge-cli pkg, so we can investigate this further.

37

@AlexHofer I see - you are talking about 3LO app, not Forge. The way the dev-console won’t allow this

38

Hi @tino.winkler,

Which version of the Forge CLI were you using when you had this issue of needing to run forge lint --fix twice?

39

Hi @AnnaTalebBendiab,

I was using version 4.0.0 of the CLI. On the first run about 2/3 of the required permission scopes where added.

40

i did the tests on node v16.13.2, forge-cli both v3.0.0 and v4.0.0.

all after the official announcements (23 and 24 February 2022).

41

Atlassian team and @JuliaDaehne
I cannot find 2 scopes (read:issue-meta:jira, read:jql:jira) from my APP, which is released for external users (distribution status: sharing).

I have a separate APP for internal test (distribution status: not sharing). I can find both scopes from the editing-scope page of this APP.

I wonder if this is expected? Or something goes wrong?

my post: Cannot find scopes in my jira oauth2 app

Thanks

42

Would support be able to duplicate one of my 3LO apps then? These disappearing entirely is a blocker for us in using the App.

43

@JuliaDaehne we are looking for the following two API scopes to choose in the migration UI but they are not available:

Some feedback for the team:

From my first impression, I really struggle to make sense of this migration UI.

  1. Why does it count the same scope so many times when I select it in the UI? Let’s say I need the read:issue:jira scope. When I select this scope in the UI it counts it multiple times. Not really sure how this information is helpful. From my research, we need 29 of the new scopes in total. The list for “View Jira issue data” alone shows 51 new scopes added :thinking:

    image
    image2028×2170 426 KB

  2. We have different OAuth apps for development, test, staging, and production. Selecting scopes one by one for each app is really slow. It would be so much easier if we could just paste the list of scopes we require. Because the migration UI does not provide any assistance with compiling required scopes, we anyways have to manually prepare the list of required scopes on the side.

Here is what I would have expected the migration assistant to look like:
A list of API endpoints where I can select the ones we use and the migration assistant will compile the deduplicated list of required scopes for me.

44

Hi @AlexHofer unfortunately this is nothing we would be supporting