How to Avoid Problems with Jira Permissions

There are a lot of aspects to Atlassian security. In this post I will focus on Jira Permission Schemes and Project Roles, and how you can simplify these while still providing your Users with the access they need. Keeping the Jira security simple will make administrating JIRA much easier. This way Users will have just enough access to perform their work within their role at the company, but not any more than needed, and administrators will be able to troubleshoot this access quite easily.

In Jira, what permissions a User has depends on the security Groups and Project Roles they belong to, and how these Groups and Roles are applied to the permission to do something. In my mind, I like to think in terms of bubbles. Who is in what bubble, and what permission has been given to that bubble? With this approach, a bubble can contain other bubbles. So, for example, Groups can be added to Project Roles, putting the Group bubble inside of the Project Role bubble. People who are assigned to Groups are just inside of a bubble. What Jira permissions a User has is determined by what bubbles they are in and how those bubbles are applied to a project.

Simplifying Your Jira Permission Schemes

In short: Only use Project Roles in your Permission Schemes. There are some exceptions to this of course, but most of your Permission Schemes in Jira should only have Project Roles in them.

In Jira, much of the “who is allowed to do what” aspect of Atlassian Security is handled through Jira Permission Schemes. The system lets you put individual people, Groups and Project Roles into each scheme. But to avoid a great deal of unnecessary complication, I recommend that (with a few exceptions) you only assign Project Roles to your Jira Permission Schemes.

Why? Why not have Groups and individuals sprinkled through a Permission Scheme?

Because if you only use Jira Project Roles in Jira Permission Schemes, then you will know that all of the access to a particular project is determined solely by the Project Roles. There would be no individuals given special Jira permissions outside of a particular Jira Project. You wouldn’t find them in a Permission Scheme. You also wouldn’t have a problem with stray Groups having access to your Projects, even though they have nothing to do with those Projects at all. After all, if you add Groups to a Permission Scheme directly, there’s the possibility that those Groups might not belong to all of the Projects that that Permission Scheme has been applied to.

Chances are, you will have a multitude of JIRA Permission Schemes. When you mix and match the use of Groups and Project Roles within these schemes, it quickly becomes very difficult and time-consuming to figure things out. You’re never quite sure who has access to what, especially if you have a lot of Groups. But if you just use Project Roles, you know.

To simplify your life, I also recommend that you keep your quantity of Groups to a minimum (for example, you really don’t need to use every one of your organization’s many security groups), and keep your Jira Permission Schemes down to the Project Role level. This way all of your access comes from a Role within the Project and the individuals who are applied to that Role.

Troubleshooting Jira Permission Schemes

All of this advice is great if you’re setting things up from scratch. But what if you have to first untangle a complex web of Jira Permission Schemes that were created without the benefit of this approach?

When I’m faced with this type of problem, I find that the fastest and easiest way to piece it all together in my mind is to use Venn Diagrams. These simple logic diagrams that you first saw in grade school are a great aide in these situations.

In a given diagram I’ll have the Group as one circle and the Project Roles as another circle. Sometimes I’ll also show an individual user as an X within a certain circle. This helps me to see exactly who has access to what, and get things untangled so that it can be fixed.

JIRA permission
For example, in the diagram above Bob has the ability to create an issue in this particular Project. The Create Issue Permission has been assigned to the Project Role – Developer. The Jira-users Group has been placed in the Project Role – Developer Group. Bob is in this Jira-users Group; therefore, Bob has the permission, in this project, to Create Issues.

This is quite a bit clearer than a situation like this:


In this situation, while Bob is still in the Jira-users Group, how these Groups and Project Roles have been used determines what permissions Bob has. Bob, like many users, can be in multiple Groups and Projects. To determine his access you will therefore need to consider all of the Groups and Roles Bob is in, and then find what Jira permissions have been associated with each of these Groups and Roles. Only then will you be able to determine if Bob has the required access.

The approach represented by the first diagram is much simpler, much more secure, and quite a bit easier to maintain.

Using the Project Administrators Project Role

Another thing to consider is this: Who is assigned to the Project Administrators Project Role? A Project Administrator is someone who has the project-specific ”Administer Project permission, but not necessarily the global ”Jira Administrator” permission.

Project Administrators assign members to Project Roles specifically for their project(s). People in the Project Administrators Project Role have the ability to assign people and Groups to Project Roles. If the Permission Scheme that is applied to a Project uses Roles, then the access to the Jira Project can be controlled by the person who is assigned to the Project Administrator Role. This can take some of the load of maintaining security permissions away from the Jira System Administrators, and allow some self-service on the Jira Side.
Need help getting Jira permissions set up right? Give us a call. As an Atlassian Platinum Solutions Partner, Coyote Creek is here for you.