GET Get priority schemes - needs user to be part of jira-admins group?

[Naveenkumar Goudar]

Requirement:

• Get list of priorities availble for a project

Approach

• We are fetching list of priority schemes using GET priority schemes and filter the schemes availble for project
• pick priorities from the project matching  priority scheme

But loks like  GET priority schemes expects user to be part of jira-admins group otherwise API does not return any priority schemes

Is that the pre-requisite for this end point? this is posing challenge that we always have to use an admin user credentials..

Is there any other way to Get list of priorities availble for a project? We are using this approach because Issue Priorities end point is marked deprecated

[Sebastian Krzewiński]

Hi @Naveenkumar Goudar 

You can ask for that by this API - https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-rest-api-3-issue-createmeta-projectidorkey-issuetypes-issuetypeid-get

No admin rights needed.

Regards,

Seba

[Sunny Ape]

Hello @Sebastian Krzewiński 

Can you provide a detailed example of how to use that endpoint you recommended to get a list of priorities availlable for a project.

Thanks

[Naveenkumar Goudar]

But this is for specific issuetype .. we need to get them for a project, not specific to issuetype  

[Sunny Ape]

Hello @Naveenkumar Goudar 

But looks like  GET priority schemes expects user to be part of jira-admins group

As stated in that endpoint's documentation:

Permissions required: Permission to access Jira.

Data Security Policy: Exempt from app access rules

There's no mention, anywhere, about the user required to be part of jira-admins group

[Naveenkumar Goudar]

But I have tested in our test acount if I remove user from jira-admins-<> group then it does not return any priority schemes 

[Sunny Ape]

I recommend that you then try using OAuth 2.0 style authentication and test with the documented scope:

OAuth 2.0 scopes required:

Classic: manage:jira-configuration

If I had to guess, it's probably a mistake in the documentation of those new, experimental endpoints, since a Classic scope of manage:jira-configuration is very high level, and certainly doesn't equate with what the documentation says about Basic Auth permission level only needing access to Jira.

WARNING. Creating an OAuth 2.0 token with the manage:jira-configuration scope just to read Priority Schemes is dangerous, as it allows broad permission to also do harm to Jira. This scope is required because the documented Granular scopes of *.priority-scheme:jira are not yet available to allocate to an OAuth 2.0 account using the GUI. This topic has been discussed in this Developer Forum thread and raised as a Bug in JRACLOUD-96390