Haut de page

A Primer for Jira Permissions


Posted by
Sonia Lelii

May 22, 2018

You’re a Jira administrator in charge of a project or instance and one of your first tasks is to assign roles and permissions to the project users. You probably feel like you have entered into some kind of labyrinth as you try to make sense of the different types of Jira permissions and roles.

All Atlassian applications provide a variety of permissions, which are both hierarchical and flexible. So once you have acquired a clearer understanding of the basic permission levels and roles, you will see there is a method to the madness in Jira’s permission capabilities.  To borrow a sports metaphor, it’s like you are a football coach who controls the playbook and now has to determine which assistant coaches and players have access, and can make changes, to the playbook at any given time during the big game.

The idea is to understand how to use these permissions so your project users have just enough access to perform their work within their company role. Making the process even more complex, some permissions are dependent on other permissions to ensure a structured workflow.

Jira permissions center on few main concepts, which include Permission SchemesGlobal PermissionsProject Permissions, Project Roles and the various user types associated with those permission levels. In this article, we will give you a primer to Jira permissions so you can put in place the controls that determine the visibility and security levels within a Jira project.

Permission Schemes: A fundamental concept

Jira’s Permission Schemes are initiated at the project-level so you can apply fine-grain permissions for each project.  They allow administrators to define who has rights to projects and issue types and they are comprised of Users and Project Roles as a best practice, but can also include Groups. These different roles will be further explained in the second half of the blog.

You can create as many Permission Schemes as you want, so that a scheme can be used for one project or multiple projects. It all depends on how generic you make it. Each Permission Scheme should be designed to address the common needs within an organization, so they should be self-contained and reusable.

Generic schemes allow project administrators to choose the scheme that best fits the project needs instead of requesting a new Permission Scheme for each project.  However, if you create too many Permission Schemes, it becomes another area that has to be managed because you have to keep track of the differences between each one.

Jira  permission types

Jira provides a Permission Helper for administrators who are troubleshooting permissions. Let’s first take a look at the types of permissions.

 

 Global Permissions Typically, Jira Administrators and Jira System Administrators control Global Permissions, which are the highest permission level in an instance. You generally assign this to Groups rather than individual Users.
 Project Permissions These types of permissions are created within Permission Schemes, and typically assigned to Users, Groups and Project Roles. There are a lot of project-level permissions that can be set to govern what users can do within a project.
 Issue Level Security Permissions This is set within issue security schemes and it allows for more granular access to project issues. It allows users to view permissions on issues by selecting a preconfigured Issue Security Level. Security permissions allow you to set up types of issues that are seen only by the project administrator or users who belong to a specific group.

 

Once you understand permission types, you can add Users, Groups and Project Roles to specific permissions within a Permission Scheme. The default Jira roles include administrators, developers and users, but you can always create new roles.

 

Users Everyone involved in a project can be a User, including Jira administrators and developers. All users with access to Jira should be assigned to a default Jira Group.
Project Roles Project Roles are a flexible way to associate Users and Groups within a Jira Permission Scheme. All project users are assigned to one or more project roles, depending on the level of access granted. In Jira you can create, edit and delete project roles as needed.
Groups This is a convenient way to manage a group of users. The difference between Groups and Project Roles is a Group gets a global view across the instance while Project Roles are specific to the project. One good rule of thumb is to use a Group when you want to refer to the same set of users across multiple projects; use a role when you want to refer to a set of users that differ per project.

 

As a Jira  administrator, you can add users, groups and project roles to specific permissions with a Permissions Scheme. What permissions a User has depends on which Groups and Project Roles they belong to.

Let’s take a look at a practical example. John Smith is on the marketing team, Jane Doe on the finance team and Lesley Morris is on the consulting team. You want everyone to have access to the Company Internal Tasks project, which potentially could apply to everyone, so that would be configured at a global level where all Groups (Marketing, Finance, Consulting) have access. But you don’t want the marketing team to see the company Invoice project, so you’d assign only the relevant groups to this project, which would be Finance and Consulting. John therefore does not have permission.

Within the Invoice project, Lesley, as a junior consultant, might need to refer to work that previously was billed for a company, but you wouldn’t want her to change anything. However other senior consultants might need the ability to change invoices, and likewise Jane needs to have access to the invoices for processing.  You’d assign Jane and other senior consultants to Project Role A, and Lesley and other junior consultants to Project Role B. By configuring the permission schemes, you can give users in Project Role A full editing and viewing rights, while users in Project Role B, such as Lesley, will only have viewing rights.

You don’t want every member of your team to have the same security level and access, which is why Jira permissions helps you build controls that are both hierarchical and flexible. This article is only a snapshot of the capabilities with Jira permissions but if you are looking for more expertise, Valiantys offers hands-on Jira Administration Training which is led by one of our experienced certified Atlassian consultants. They’ll guide you through the configuration of Jira permissions, ensuring everyone has the right access to do their jobs properly.