JIRA Best Practices: Configuring JIRA Permissions



This is part of a blog series with our own tips on configuring your JIRA, maximizing your use of JIRA’s many features, and tailoring the platform to best suit your organization’s needs.

When using a comprehensive software platform like Atlassian's JIRA, it may seem difficult initially to familiarize yourself with all of its robust features. In this post, we’ve put together a list of suggested best practices on how to use the sometimes forgotten Built-in Field Values in JIRA. Using them can be a good way to filter and prioritize issues.

Last year we blogged about Project Roles, which was very popular with our users. In this blog, we'll go into more detail about Project Roles and the relationship between Project Roles and other permission-based concepts in JIRA.

JIRA is a powerful and a flexible system in many ways, which allows each company to adjust the system to their needs. Because of its flexibility, JIRA configuration can be quite complex for new JIRA Administrators.

In this blog, I’ll explain JIRA Permissions, how we work with permissions at our company, and as Atlassian Experts, what we advise as best practices when administering it.

First, there are several concepts that are vital to understand when it comes to implementing JIRA's Permissions.

These concepts are: Users, Groups, Global Permissions, Permission Schemes and Project Roles. 

It took me quite some time to understand how these three are connected together, and how you use all three to control permissions and access.

  • JIRA's Global Permission is where you grant users permissions that are global across all projects in your JIRA instance. These permissions include:
    • JIRA System Administrators
    • JIRA Administrators
    • JIRA Users
    • Browse Users (and more)
  • Permission Scheme is a set of permissions and Users, Groups, or Project Roles that are assigned to each permission. Permission Schemes are assigned to JIRA Projects, and can a single JIRA Project only be assigned to one Permissions Scheme, while each Permission Scheme can be used by multiple JIRA Projects. This way, you can grant users different permissions to different JIRA Projects.
  • Users are the users that can log into your JIRA instance.
  • Groups are simply groups of the users that can log into your JIRA instance.
  • Each JIRA Project has Project Roles that users or groups can be assigned to. The Project Roles are global for all JIRA Projects.  The default Project Roles are: Administrators, Developers and Users. JIRA Administrators can add new Project Roles in JIRA. Some add-ons for JIRA, including Tempo, add new Project Roles to JIRA Projects. For example, Tempo recently added the Tempo Project Managers Role to help project managers manage their project worklogs.

How We Do It

We recommend the following to customers when setting up Permissions in JIRA:

  1. When assigning permissions in a Permission Scheme, only assign Project Roles, and refrain from assigning specific Users or Groups.
  2. Then, within the Project administration panel in JIRA, you can assign those Project Roles to the appropriate Users or Groups.
  3. This way, you can use the same Permission Scheme for multiple projects and minimize complexity in your JIRA configuration.
  4. Sometimes, it is necessary to grant individual Users or Groups a specific Permissions in the Permission Scheme, but this should be the exception, and not the rule.

Below is a graph illustrating this setup:


The Three Project Roles

As mentioned, each JIRA Project has three default project roles; Administrators, Developers, and Users. It’s good form to define each Role before assigning any permissions to them.

Here is an example of role definitions:

  • Administrators:  The person/s managing the project. Admins need permission to add new Users or Groups to the Project, and can manage Components and Versions.
  • Developers:  The people doing actual work on Issues in the project, can edit issues and log work. People in this Role can be assignees on the Issues.
  • Users:  Interested parties who are not doing actual work on Issues, but should be able to create and view Issues and comment on them.

You may want to define your Project Roles differently and create additional roles based on your needs, which is fine. Just be sure that your definition of the role is used consistently across all of your projects.

Delete Permissions

Deleting Permissions often include some discussion.

One question that frequently arises is: Should we allow people to delete comments on Issues, delete Issues, and delete worklogs?

One reason to not allow people to delete a comment, for example, is that you might lose an important part of the entire comment thread in the Issue, which means that other comments suddenly don’t make sense anymore.

Some companies feel similarly towards deleting Issues -- that it means losing an important thread of Project Issues’ history.  However, for Log Work Permissions, you usually want to grant users the Permission to Delete Own Worklog. Because when moving a worklog from one Issue to another, you are in fact deleting the worklog on one Issue and creating it on another.

JIRA offers significant flexibility for organizations to manage their teams and reach their objectives, but it's important to obtain a foundational grasp of project roles and permissions concepts before getting started. Stay tuned for more JIRA Best Practices tips from us!

Find a Tempo Partner

Subscribe to our blog

Get the inside scoop, previews, news and other fun stuff.

tempo laptop