I have a simple Forge Custom UI app that uses the jira:projectPage template and reads Jira issues with an API call to …/rest/api/3/search. The permission needed was read:jira-work which I added to the manifest after the initial deployment (when no scopes were added to the manifest).
When (re)deploying via the cli, the message ‘We’ve detected new scopes or egress URLs in your app’ was displayed and after installing with the --upgrade argument, the permission is mentioned under ‘Your app will be upgraded with the following additional scopes’.
When I access the app, a consent page appears and after confirmation I can fetch the Jira issues.
However, in another app I used the wrong scope (read:issue:jira-software) initially and after giving consent confirmation I got a HTTP 403 on fetch with the message ‘Access to the resource was denied due to missing scope grants’. This seems correct because the message also suggests to use the read:jira-work scope.
But when I changed the scope to read:jira-work in the manifest and redeploying and installing the app with the --upgrade argument, no consent page was shown and the fetch kept giving an HTTP 403.
Using the right permission initially and then the wrong one afterwards gives the same result: no consent page and it keeps giving the issues on fetch.
I’ve tried it on development and on production. With production you can see the scopes on Developer console in the permission section. These permissions shown there contain the second scope specified. And the version of the app is upgraded to the next major version.
Can’t you change the scope after consent is given or do you have to remove something first?