Automated verification of user permissions using CLI tools and REST API

Still need help?

The Atlassian Community is here for you.

Ask the community

 

Platform Notice: Server, Data Center, and Cloud By Request - This article was written for the Atlassian server and data center platforms but may also be useful for Atlassian Cloud customers. If completing instructions in this article would help you, please contact Atlassian Support and mention it.

Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

Summary

Manual verification of dozens of project permissions could be time-consuming and cumbersome (and error-prone since this is a manual step). Especially in case, you are facing an error similar to the one described in Cannot enable or save Automation rule due to the error "Either you or the rule actor for this rule is missing some required permissions" when the Automation for Jira rule might affect dozens of objects. Unfortunately, currently, there is no functionality available in Jira out-of-box that could help simplify this step.

However, for quick verifications, we could try to mitigate this problem with the help of a small bash script that will utilize /rest/api/2/mypermissions REST endpoint to check and list available permissions for the user. You will still need to prepare a list of project keys (string or text file) but still, this is better than checking all permissions manually through the Jira UI.
Short description:

  1. We will query /rest/api/2/mypermissions REST endpoint using curl and provided credentials (the user that you need to check permission for).
  2. Then we parse the returned JSON output with jq (might need to be separately installed if not available) to extract only nodes with required permission permission.

The below examples use Basic Authentication. In case you can't use plain text passwords, then you could generate PAT (Using Personal Access Tokens) and use it instead. You will need to add an 'Authorization' HTTP header with a token to curl parameters instead of '-u <username>:<password>':

-H "Authorization: Bearer <pat_token>"

Environment

Any Jira version.

You will need to have curl and jq command line utilities preinstalled in your environment.

Solution

Option 1 (verification if a particular user has described project permission)

Please replace <username>, <password>, <jira_base_url>, <proj_key> and <permission> with values appropriate for your case:

Utilizaing /rest/api/2/mypermissions REST endpoint
curl -s -u <username>:<password> \
    <jira_base_url>/rest/api/2/mypermissions?projectKey=<proj_key> \
    | jq -r '.permissions[]
        | select (.key == "<permission>")
        | [.name, .description, .havePermission]
        | @tsv'

Example output:

Testing of 'jira_admin' user has "EDIT_OWN_WORKLOGS" for project "SSS"
curl -s -u jira_admin:jira_admin \
    http://localhost:9112/9112/rest/api/2/mypermissions?projectKey=SSS \
    | jq -r '.permissions[]
        | select (.key == "EDIT_OWN_WORKLOGS")
        | [.name, .description, .havePermission]
        | @tsv'

 Edit Own Worklogs	Ability to edit own worklogs made on issues.	true

You can remove "select (.key == "EDIT_OWN_WORKLOGS")" from jq parameters to list all values for <proj_key> permissions and tested user

Option 2a (checking permission against the project list)

Please replace <username>, <password>, <jira_base_url>, <proj_key_list> and <permission> with value appropriate in for your case:

#!/bin/bash
# Array with project keys separated with space. 
# For example, declare -a project_keys=("AAA" "BBB" "CCC")
declare -a project_keys=("<proj_key_list>") 

# Jira Base URL
jira_base_url="<jira_base_url>"

# Credentials
username="<username>"
password="<password>"

# Permission to check. Full list of possible permissions could be returned with the help of 
# curl -s -u <username>:<password> $jira_base_url/rest/api/2/mypermissions?projectKey=<proj_key> | jq -r '.permissions[].key'

permission="<permission>"  

echo -e "Permission: $permission \n";
for i in "${project_keys[@]}"; do
    echo -e "Project Key: $i" "$(curl -s -u $username:$password $jira_base_url/rest/api/2/mypermissions?projectKey=$i \
        | jq -r '.permissions[] | select (.key == "'$permission'") | [.name, .havePermission] | @tsv')" \
        | tr -d "\r";
done

Example output:

Testing user has "TRANSITION_ISSUES" for projects "AAA" and "BBB"
// Save above script at 'check_perm.sh' file, grant execution rights and run script

 ~ ./check_perm.sh
Permission: TRANSITION_ISSUES

Project Key: AAA Transition Issues	true
Project Key: BBB Transition Issues	true
Project Key: CCC Transition Issues	true

Option 2b (checking permission against the project list from a text file)

The second version might come in handy if you have a lot of projects to check. You could add project keys to the text file projects.txt (every project key should be on a new line, no need to escape them with quotes).

Same as in the above example, please replace parameters with values appropriate for your case and save the below script at text file:

#!/bin/bash
# Path to the file with project keys. Every project key should be on new line
filename="/path/to/projects.txt"

# Jira Base URL
jira_base_url="<jira_base_url>"

# Credentials
username="<username>"
password="<password>"

# Permission to check. Full list of possible permissions could be returned with the help of 
# curl -s -u <username>:<password> $jira_base_url/rest/api/2/mypermissions?projectKey=<proj_key> | jq -r '.permissions[].key'

permission="<permission>"  

echo -e "Permission: $permission \n";
if [ -f "$filename" ]; then
    while IFS= read -r line; do
        echo -e "Project Key: $line" "$(curl -s -u $username:$password $jira_base_url/rest/api/2/mypermissions?projectKey=$line \
            | jq -r '.permissions[] | select (.key == "'$permission'") | [.name, .havePermission] | @tsv')" \
            | tr -d "\r";
    done < "$filename"
fi



Last modified on Oct 31, 2023

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.