Why does Search Priorities require the "manage:jira-configuration" scope?

I would like to get a list of the possible Priorities for a project. I see that there is a “Get priorities” endpoint (/rest/api/3/priority) but that it’s deprecated. The replacement “Search priorities” (/rest/api/3/priority/search) works but requires manage:jira-configuration instead of read:jira-work. No changes can be made with this endpoint so it seems a bit weird that it requires management scope when it’s predecessor did not. Is this correct? Is it possible to get a list of priorities as a regular Jira user (e.g. read:jira-work) without using the deprecated endpoint?


Yes, it does seem like overkill to require a such high level permission just to search for priorities. It is contradicted by the fact that if you use Basic Auth with that endpoint, you don’t need a user account with Jira management permissions.

Maybe someone just got a little carried away with the OAuth scopes for that replacement endpoint by mistake?

The Get Priorities endpoint is still working and only requires read:jira-work for OAuth scope, so maybe use it until such time as someone at Atlassian can re-consider the permissions for the replacement endpoint.

Yeah that’s what I’m going to do. Do you know what kind of timeframe should I expect for a deprecated endpoint to be removed?

Thanks for your help!


No removal date was declared in either the changelog notice or the community announcement. And I’m not aware of any targeted removal date.

That said, I can’t recommend using a deprecated endpoint (that’s kind of definitional). Rather, I would recommend getting the change of scope logged as a suggestion so you, and others who might stumble upon this thread, would have something formal to track. Could you please open a “suggestion” issue yourself in our open Jira (JAC) in the JRACLOUD project. I think you could just copy/paste your opening post. Once you have the issue key, please let us know here so other folks can watch, vote, and comment.

1 Like

Scopes on this platform are a mess. Connect scope conventions were simple (albeit broad). With Forge they went hyper-specific with scope requirements, and with each new version they change those requirements.

eg UI Kit 1 in Confluence using the useContentProperty hook required read:content.property:confluence and write:content.property:confluence

Then at some point they recommended using read:confluence-props and write:confluence-props. For multiple @forge/cli versions the linter changed its mind on which of these two pair of props it wanted. My git history shows this as I flipped back and forth.

Now with UI Kit 2 the useContentProperty hook requires read:page:confluence and write:page:confluence. That obviously makes zero sense and defeats the point of forcing developers to use hyper-specific scopes.

And of course each time Atlassian inflicts these permission scope changes on developers, it requires manual version updates by end-customers (who do not update). It’s very difficult building a business here on such unstable foundations.

Hi - can you please guide me on how to actually do this? When I click “Create” on the linked page the JRACLOUD project is not available - though there is a similar one? When I select the most appropriate project I’m basically blocked from creating a ticket:

It just tells me to look for existing issues?