Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Required permissions for 'Get group' API call -- finer granularity than Administer Jira global? Edited

jma dev I'm New Here Jan 21, 2021

Hi all, 

Very new to using the JIRA API so any guidance would be appreciated!

I am working with an engineer who has full global and project permissions for API calls to our JIRA host ({organization-name}.atlassian.net). This engineer wrote a script in TS using the npm library jira-client, where our JIRA client looks somewhat like this:

import JiraApi from 'jira-client'

export class JiraClient {
private client: JiraApi

constructor (email: string, apiToken: string) {
this.client = new JiraApi({
protocol: 'https',
host: '{organization-name}.atlassian.net',
username: email,
password: apiToken,
apiVersion: '3',
strictSSL: true
})
}

// Other methods making calls to the client

private async getUsersInGroup (): Promise<...> {
const response = await this.client.getUsersInGroup(
'jira-software-users'
)
return ...
}
}

We want several other engineers -- let's call them 'script engineers' -- to be able to run this script with their own username and password (i.e. 'email address registered with JIRA' and 'JIRA API token associated with that account'). Many script engineers, including me, do not have the same level of permissions as the engineer who wrote the script.

Some of the methods written in our client already work for me! For instance, calling the client's searchJira function to find child issues of some given parent issue works, because I must already have Browse projects permissions as is written that I must. But the getUsersInGroup method that I included above, which uses the (deprecated) Get group API, fails with the following message:

(node:62384) UnhandledPromiseRejectionWarning: StatusCodeError: 403 - {"errorMessages":["이 동작을 수행할 권한이 없습니다. 관리자 권한이 필요합니다."],"errors":{}}

(This translates to: "You do not have permission to carry out this action. Administrator permissions are required.") 

Now, this is not a surprise -- I do not currently have Administer Jira global permissions.

IMMEDIATE SOLUTION: Give Administer Jira global permissions to all script engineers.

This is an obvious solution but less than ideal. Script engineers do not need access to do everything associated with Administer Jira global permissions.

OPTIMAL SOLUTION: Give the minimum permissions required to run the script to all script engineers.

This might very well be the same as the 'Immediate Solution' due to how permissions are bundled, but I just wanted to check that currently there is no other way to give a finer granularity of permissions than just Administer Jira across the board.

Note #1: For all I know, permissions might be bundled this way for a good reason! If it really is best an engineer who wishes to use the Get group API must have the full Administer Jira permission, then I suppose it is good to know that this is the case, and why.

Note #2: I do not believe this to be an XY problem -- this script really does need the results of the Get group API call so it can look at all kinds of user information for each user in the 'jira-software-users' group. That said, if there is a better way to get this information without resorting to an Administer Jira API call, please let me know! Perhaps the Get all users call could work, but I am still familiarizing myself with how it is different from Get group for 'jira-software-users'.

Thank you again for any guidance. Looking forward to using more of this product!

1 answer

You're out of luck. The access permissions granted via the REST API are the same as per the web interface for any user account; if the user account doesn't have permission to do something, then you can't 'bypass' that somehow.

The global permission level required to get all users in a group, or to get all groups a user is in, isn't actually Administer Jira, it's just below that level and is called 'Browse users and groups'. It's just that a Jira Administrator account inherits that lower permission level by default.

You could grant Browse users and groups permissions to a security group those script engineers were members of, giving due consideration to the security impacts of doing that.

Alternatively, you could create a script that used a dummy account with Browse users and groups permissions, schedule it to run once or twice a day, then place the results in a file somewhere that the scripts of the engineers could access to get the data set. You'd want to set the key / token of the dummy account to only last for a short period of time, for a bit of security to prevent the account being abused.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
TAGS
Community showcase
Published in Trello

📹 Favorite Trello templates

Hello Community!  My name is Brittany Joiner and I am a Trello enthusiast and Atlassian Community Leader. In this video, I'll share my favorite Trello templates. Templates mentioned in ...

75 views 4 5
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you