Best Ways to Define Permissions in Jira
I work with all different types of Jira users everyday, and one topic that always comes up are the permission concepts. To help you wrap your head around it and to answer the most common questions about this, I decided to put together this blog post.
Which permissions to give to which users? This is pretty much the most important question no matter which Jira version your team uses. At the very least, you'll have to consider the permission concept for your Jira instance if a customer, external contributor or someone from the management team needs to manage tasks or issues, but you only want them to be able to access certain topics.
A Systematic Approach to Permissions in Jira
The permissions are modelled as Permission Schemes. This is where you define and manage all the project permissions. Every type of permission can be tied to the access requirements of your users, to different groups you defined or to a specific user. But which user-permission-mappings make sense and what should definitively be avoided?
In my experience it works best to model the permission scheme according to different project roles users have. By setting the system up like this, every Jira admin on your team can add users to a project role thereby granting them all the right permissions. This way, you won't have to manage each and every request for a permission change yourself and save quite a bit of time. Plus, this way it's super easy to see who's working on a project and who isn't.
In general, the list of permissions is long: who is allowed to create an issue or who can make edits are just the tip of the permission iceberg. I've found it quite hard to give advice on detailed questions that apply to every user scenario. So please don't hesitate to get in touch with us if you have a specific question. We think about Jira permissions schemes all day every day, and there's pretty much no scenario we haven't figured out yet.
Top Three Jira Permissions to Think About
These are the top three permissions I get asked to explain the most:
- Project Administration:
This is the permission that allows a user to change to the project configuration mode. You should only grant these rights to admins and project team members that are allowed to configure components, versions, users, and roles. In addition, you should add them to the administrative group. This way, the project admin can't lock out the other admins by accident.
- Search a project
This permission manages the visibility of a project. Again, I recommend you include project roles for this one. If you as the admin have to look at issues in details a lot, it's definitively worth to configure the administrative group as well.
- Move an issue
To migrate an issue from one project to another, you have to have to following permission both in the project the issue is located at the beginning as well as for the project where you want to move it to: Search Project and Create Issue
Be Frugal with the Permissions
For pretty much every other kind of permission (like e.g. Create Issue or Delete Issue) my experience tells me to keep them as general as possible. This could be
Applikations Zugriff XYZ,
Jeder angemeldete Benutzer oder
Project Roles. Try and avoid creating persons or groups. The reasoning behind this: You don't want to spend all your time activating user accounts.
Image your permission concept as a funnel. The amount of people who are given certain permissions gets more and more narrow as you move down the funnel. You can't open them up further anymore.
For example: Only the users whose project role allows them to search certain projects are able to see all the related issues, even if all users are allowed to work on issues in general.
Once you've worked out such a permission scheme you and your organization should be good to go for 80 to 90 % of all cases. This scheme can also be used as a blueprint for other projects and you won't have to deal with every single permission in detail anymore. Investing some time to figure out your first permission scheme is definitely worth it, because it saves you a lot of time in the future.
One thing to be super careful about: Be sure all the project admins are aware that only people and groups who attended a Jira training should be added to the project role of project admins. I've noticed that project admins like using descriptive group names like Jira-Customers which they end up configuring as system admins to give them more transparency for the project. But this means their project role allows them to see the whole project.
In general this type of configuration also has its advantages, though: It makes the organization much more flexible and agile.
Whenever you're unsure of a certain configuration, create a test user and go through different permission scenario until you've figured out what works best for you.