Atlassian's flexible rights model allows extensive authorizations and restrictions. However, with the many settings options, it is not always easy to keep track of things. In this article, we want to explain the user model to you and in particular address authorization management.

Rights management

A right enables its owner to carry out a specific action, such as viewing or editing processes or adding users. Rights are granted to groups, roles, or individual users in Jira. Groups here represent a plurality of users who are grouped together on the basis of their identical authorizations; administrators can create any number of such groups.

The groups cover the entire Jira instance and cannot be changed on a project-by-project basis. Unlike groups, roles are project-specific. With roles, users or even groups can be bundled in projects and be authorized together.

Rights are granted at instance, project and process levels.

Cross-instance permissions

These permissions can only be managed by users with the global “Jira Administrator” permission and are assigned in the “Jira Administration”.

Global permissions are issued to groups and not to individual users, and are applied to the entire Jira instance and therefore across projects. These permissions determine, for example, which groups can perform administrative functions or who can share filters or dashboards with other users. Learn more about global permissions here.

By default, Jira creates the Jira administrators group. Members of this group have access to Jira's administration masks. Of course, administration rights can also be granted to other groups created by yourself. Accordingly, this can also be deleted if the administration rights were previously saved in another way, i.e. via another group — otherwise the administrator can exclude himself in this way. A previous backup is highly recommended.

In application access is probably the most important cross-instance authorization granted. This is where you configure who should actually have access to the platform and therefore also needs to be licensed. Groups can be stored for each installed application (Jira Software, Jira Service Management, Jira Work Management), which allow users in the respective groups to use the applications. By default, Jira creates the appropriate groups for the installed applications: Jira software users, Jira work management users, Jira service management users. Of course, you can also create your own groups and use them to manage access to applications.

Application access regulates application-specific authorizations. The Jira Service Management specific functionalities such as queues or SLAs are therefore only seen by users who have Jira Service Management application access, the boards in Jira Software projects can only be accessed and used by users with the appropriate application access.

Project permissions

These permissions can only be managed by users with the global “Jira Administrator” permission and are adjusted in the “Project Settings”.

At this level, permissions can be assigned at project level, e.g. who can adjust the project configurations (“Manage Projects” permission) or who can see the processes in a project (“Browse Project” permission) and comment (“Add Comments” permission). You can find more information about project-specific permissions and their explanations here. These authorizations are set in so-called authorization schemes. The individual authorizations can be granted to individual users, groups, roles or even users on a process (processor, creator, user in a user-defined field). Authorization schemes can be shared by multiple projects, so adjustments require caution and communication, as the changes will apply to all projects.

With the “Workflow Actions” authorization, users can be given the right to change the status of a process. If certain transitions may only be carried out by a few users, this can be solved in the work processes using conditions. In the condition, you can then define which users (with authorizations, from groups, project or process roles) may carry out the transition. Users who do not meet the condition cannot see the status transition button either.

Process permissions

In certain projects, it can be useful to reduce the visibility of certain processes, e.g. if a project involves working with internal and external employees, but external parties should not see everything.

For this purpose, Atlassian offers the safety schemes. Different security levels can be created in this scheme; for each security level, it is defined who can see the processes at this level (i.e. individual users, project roles of the groups). One of the defined stages should be defined as a standard, which is then set to newly created processes. The processes are then only visible to users and groups who have the appropriate permission to do so.

Only users with the “Define process security” permission can change the security level.

Security schemes can only be managed by project administrators and edited in the “Project Settings”.

Best Practice

This image describes the different options in Jira authorization management. I don't think everything that is possible is equally useful. The options, which I don't necessarily recommend, are shown in the picture as gray, dashed arrows.

Global permissions can only be granted to groups. It is therefore worthwhile to create a group for each global authorization, which regulates application access or system admin rights.

At project level, too, I recommend using groups and not individual users and assigning groups to project roles. In this way, administration costs can be kept to a minimum. When a person has finished working on project A and is new to working for project B, only the group memberships need to be adjusted (from PROJECTA groups, including in ProjectB groups), and the person can correctly start working in the new project. If individuals are specified as project roles, the projects would have to be combed through and checked during the same change so that all individuals are correctly authorized in the end.

It is ideal if the roles are then used in the authorization schemes to grant rights. In this way, authorization schemes can be used by different projects and standardized authorization can be achieved. As a result of the fact that different groups are defined for roles in different projects, users still have different rights in different projects.

If it is set up this way, when employees change, only the users and group memberships need to be adjusted and there is no need for further checks and adjustments in the projects

In principle, it is therefore worthwhile to properly regulate users and, in particular, group membership - either directly in Jira's user management system or via an external user management system.

Atlassian often grants permissions to every logged-in user. I support this liberal stance, but I know that it is not equally well received in all companies or even in all projects. I therefore recommend taking a quick look at the standard authorization schemes and checking whether they can actually be used in this way.

And last but not least, I would like to mention the authorization assistant: Users in the “Project Admin” role have the option to check permissions for users in Project Settings > Authorization Scheme. By clicking on the “Authorization Helper” button, you can query whether someone can perform a specific action on a specific process. The authorization assistant then shows whether it can be carried out or, if not, which role the person would have to be assigned to obtain the rights. And anyone who has read carefully now knows that you don't add the user to the role, but you add the user to the group that is stored in the corresponding role.

--

anna is a senior consultant at linkyard. She has more than 10 years of experience in various roles in IT. She studied computer science at the University of Bern (MSc in Computer Science) and later also obtained a teaching diploma in computer science for Matura schools. She is a certified Professional for Requirements Engineering, certified SAFe 4 Agilist and has an IPMA-D certificate in project management. She is also a certified Jira Software and Jira Service Desk administrator. She also has further education in the area of data science.

She has many years of experience as a technical project manager and as a software and requirements engineer.