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?
Cheers
Steve
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!
@StephenWhitfield,
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?
