For many years Jira had users and groups. You associated users and groups with specific permissions to make sure the right people could do the right things. This worked okay at first, but it turned out to be hard to maintain.

Here’s why this wasn’t ideal. Let’s say we have two Jira users, jeff.tweedy and jay.farrar, who could be assignable in two different projects. Using just users or groups, you would have to create two permission schemes, one that lists Jeff as assignable for the Wilco project and another that lists Jay as assignable for the Son Volt project. But wait… you just remembered that they are both assigned issues in the Uncle Tupelo project! Now you need a third permission scheme.

With lots of users, this leads to permission scheme sprawl. (This same scenario occurs just as often when you use groups rather than users in your permissions schemes.) Keeping track of differences between each of these schemes is tedious and error-prone, even with the Permissions Helper.

Further, only Jira Admins can create and modify Permission Schemes, create Groups, add or remove users from groups and switch which scheme is applied to a project.

This is why Project Roles exist

Project Roles were created to fix this problem. Project Roles provide a way to distribute the activation of pre-configured project based permissions to the people running each project. In its default configuration, whoever is designated as the Project Lead on a project is able to add and remove people (or groups) from any project role in their project. They can do this whenever they like.

In our example above, jeff.tweedy and jay.farrar (who naturally are both in a Jira group called Musicians) don’t need to explicitly appear in any permission scheme to become assignable. Instead the Project Administrator can add any Jira user to the Project Role of Band Members for their project.

Instead of having two or three permission schemes for different combinations of band members, you just have one permission scheme that effectively says “whoever the project lead puts in the Band Members role should be assignable”. In our example, Jeff and Jay are both assignable in the Uncle Tupelo project, so the Project Administrator simply adds both jay.farrar and jeff.tweedy to the Band Member role for that project. In the Son Volt project the project administrator would add jay.farrar without adding jeff.tweedy to the Band Member role. Finally, the Wilco project would show jeff.tweedy, but not jay.farrar, in the Band Member role. Everyone would have the correct permissions and every project would be using the exact same permission scheme.

Why would I ever use groups then?

Groups are still useful, and some permissions lend themselves to group permissions. For example, the Browse Project permission is how any user is granted the ability to see that a project exists and to be able to view the issues within that project. This permission is typically granted to groups of internal employees.

Group and role based permissions are often used together

Most organizations propagate all full time employees into a Jira group from their LDAP Directory. We might find a group in our LDAP directory called Staff that populates a Staff group in Jira. Our permission scheme would then be configured to grant Browse Project permissions to the Staff group members.

Contractors are not listed in this Staff group. This means if you create a Jira account for a contractor, when they login to Jira they won’t actually be able to see any projects. But we certainly don’t want to add them to the staff group as we don’t want them to see every project. Instead, we’ll have the Jira Administrator create a project role called Contractor and associate this role with the Browse Project permission, right along side the Staff group. The Jira Administrator would only need to do this once.

Now in order for our contractor to be able to see the project she’s working on, the Project Administrator simply adds her to the Contractor role in the correct project. If she is only working on one project, she is only added to the role in that project. This means she will only be able to see that one project. If any unique combination of contractors work on a project, it’s as easy as adding the unique combination of contractors to the Contractor role.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *