Atlassian's flexible rights model allows for extensive permissions and restrictions. However, it is not always easy to keep track of the many possible settings. In this article, we would like to explain the user model to you, and in particular discuss authorisation management.

Rights management

A permission enables its holder to perform a specific action, such as viewing or editing tasks or adding users. Permissions in Jira are granted to groups, roles or individual users. Groups here represent a plurality of users who are grouped together based on their identical permissions; administrators can create any number of such groups.

Groups span the entire Jira instance and cannot be changed on a project-by-project basis. In contrast to groups, roles are project-specific. Roles can be used to bundle users or groups in projects and to authorise them together.

Rights are granted at the instance, project and task levels.

Cross-instance permissions

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

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

Jira creates the jira-administrators group by default. Members of this group are granted access to the administration screens of Jira. Of course, administration rights can also be granted to other groups that you have created yourself. Accordingly, this group can also be deleted, provided that the administration rights were previously secured in another way, i.e. via another group - otherwise the administrator can exclude himself in this way. It is strongly recommended to make a backup beforehand.

The most important, cross-instance authorisation is assigned in the application access. This is where you configure who is to have access to the platform in the first place and thus who also has to be licensed. For each installed application (Jira Software, Jira Service Management, Jira Work Management), groups can be stored that allow users in the respective groups to use the applications. By default, Jira creates the corresponding 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 manage application access through them.

Application access is used to control application-specific permissions. The Jira Service Management specific functionalities such as queues or SLAs can only be 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 corresponding application access.

Project permissions

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

At this level, permissions can be assigned at the project level, e.g. who can adjust the project configurations ("Manage projects" permission) or who can see the tasks in a project ("Browse project" permission) and comment on them ("Add comments" permission). You can find more information on project-specific permissions and their explanations here. These permissions are set in so-called permission schemes. The individual permissions can be granted to individual users, groups, roles or even users on a task (editor, creator, user in a user-defined field). Permission schemes can be shared by several projects, so care and communication is required when making adjustments, as the changes will apply to all projects.

Via the "workflow actions" authorisation, users can be given the right to carry out a status change on a task. If certain transitions may only be carried out by a few users, this can be solved in the workflows by means of conditions. The condition can then specify which users (with permissions, from groups, project or activity roles) are allowed to carry out the transition. Users who do not fulfil the condition cannot see the button for the status transition.

Operation authorisations

In certain projects, it can make sense to reduce the visibility of certain tasks, e.g. if a project involves internal and external staff, but the external staff should not see everything.

Atlassian offers security schemes for this purpose. In this scheme, different security levels can be created; for each security level, it is defined who can see the tasks of this level (i.e. individual users, project roles of the groups). One of the defined levels should be defined as the default, which is then set on newly created tasks. The tasks are then only visible to the users and groups who have the corresponding authorisation for them.

Only users with the "Set operation security" authorisation can change the security level.

Security schemes can only be managed by the project administrators and edited in the "Project settings".

Best Practice

This picture describes the different possibilities in Jira authorisation management. I do not consider everything that is possible to be equally useful. The options that I do not necessarily recommend are shown in the image as grey, dashed arrows.

The global permissions can only be granted to groups. It is therefore worthwhile to create a group for each global authorisation, via which the application access or also the system admin rights are regulated.

At the project level, I also recommend using groups rather than individual users and assigning groups to the project roles. This way, the administration effort can be kept to a minimum. If a person has finished working on project A and is now working on project B, only the group memberships need to be adjusted (from project A groups, into project B groups), and the person can start working on the new project with the correct authorisation. If individuals are specified in the project role, the projects must be combed through and checked for the same change so that all individuals are correctly authorised at the end.

It is ideal if the roles are then used in the authorisation schemes to grant rights. In this way, authorisation schemes can be used by different projects and a standardised authorisation can be achieved. Because different groups are stored in the roles in different projects, users still have different rights in different projects.

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

In principle, it is therefore worthwhile to regulate the users and especially the group membership cleanly - either directly in the user management of Jira or via an external user management system.

Atlassian often gives permissions to every logged-in user. I support this liberal attitude, but I know that this does not go down equally well in all companies or even in all projects. Therefore, I recommend taking a quick look at the standard authorisation schemes and checking whether they can actually be used in this way.

And last but not least, I would like to mention the permission helper: Users in the role "Project Admin" have the possibility to check permissions for users in the Project Settings > Permission Scheme. By clicking on the button "Authorisation helper", it can be queried whether someone can perform a certain action on a certain task. The authorisation helper then shows whether it can be carried out or, if not, which role the person would have to be assigned to in order to obtain the rights. And those who have now read carefully know that the user is not added to the role, but is included in the group that is stored for 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 for Matura schools in computer science. She is a certified Professional for Requirements Engineering, a certified SAFe 4 Agilist and holds 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 field of Data Science.

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