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

[jma dev]

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!

[David Bakkers]

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.