Summary

In JIRA User, Groups & Roles are located in different places and have different functions and Permissions. This document will review the key functionality and differences around people and permissions in JIRA.

User, Groups & Roles

Locations

The locations of people is in more than one place in JIRA. This represents not only the functional use of these features, but also their representative functionality.

User & Groups are located in the User Management section. This provide the functionality of basic representation in JIRA and basic grouping of people which can be transferred in and out of JIRA to other tools. For example, a connected Active Directory can be tied to and feed JIRA with both Users and Groups.

Roles are located in the System Administration section. They provide the functionality to manage the representation of users specifically within JIRA projects. Roles also provide a key efficiency function in JIRA that allows multiple users to be in the same Role but not the same Project.

There is some limited cross-functionality among these features within JIRA

• Only Users can be assigned to Groups
• Both User and Groups can be assigned to Roles.
• Roles can not be assigned to either Users or Groups

Functionality

The functionality of Users, Groups, and Roles may be similar but JIRA also allows for some key differences.

Users are used primarily to represent individual people in the system. Users can be assigned to Groups or Roles. And individual users can be assigned to Project Permissions or Notification – although that is typically not best practice.

Groups are used to organize users. Groups are primarily used for the following purposes in JIRA

• Connect a group of users between JIRA and some external user management tool
• Connect a set group of user to some JIRA functionality like project permissions or notification
• Assign people to Global Permissions

Roles provide a unique functionality in JIRA. Roles allow multiple projects to have similar functional names but unique user access. To understand Roles consider the following example:

Note the efficient functionality this allows:

• Even though User 1, 11, & 21 are all assigned the Administrator role, they can only administer their own projects and not the other two project
• Project Teams are limited to seeing their own project and no others
• Developers can see any project they need to without creating unnecessary roles
• If any user need to access a different project, they are simply added to that project’s role

The structure that allows this functionality is managed by two simple rules

• The System Admin assigns Users 1, 11 & 21 to their individual projects as the Role: Administrators
• As Project Admins, Users 1, 11, & 21 assigned other users to the projects as needed based on the Roles: Project Team or Developer

Users (or entire Groups) can then be moved in or out of a specific project’s role based on how the Project Admin wants to control access their own project.

Permissions

Permissions exist at two levels in JIRA

• Global Permissions
• Project Permissions

Global Permissions

Global Permissions are a unique, finite, set of permissions that are managed by the System Admin and relate to system wide features. For a complete review of Global Permissions reference the following Expium article:

Global Permission or Group? Clearing up confusion on JIRA Administrators

One important note on Global Permissions is that they can only be assigned to Groups. They cannot be assigned to Users or Roles.

Project Permissions

Project Permission relate to key activities within a project. They are limited to 33 specific permissions that fall into the following categories:

• Project Permissions
• Issue Permissions
• Voters & Watchers Permissions
• Comment Permissions
• Attachment Permissions
• Time Tracking Permissions

Project Permissions should be determined by the Project Administrator, but must be set by the JIRA Administrator and applied to a Permission Scheme that will then be tied to the project (or multiple projects if they have the same permission needs). Permission schemes are often shared among diverse projects because functionality, like the use of Roles, prevent users with the same permissions to impact projects to which they are not related.

While Project Permission are primary assigned to Role, they can be assigned to multiple representations which then lead back to a user or set of users.

• Project Role
• Application Access (user or public)
• Group
• User custom field value
• Service Desk Customer – Portal Access
• Reporter
• Current assignee
• Single User
• Project lead
• Group custom field value