Independent IT consultant and trainer. 10 years of experience in Atlassian Jira and Atlassian Confluence consulting and training.
Jira: permissions, permission schemes and security levels
One of the essential features of a process administration is its rights management. How is it ensured that every user sees only what he is allowed to see?? Can users be divided into groups and roles? How granular can permissions be?
The permissions concept implemented in Jira consists of several components that are highly interdependent and should therefore always be considered together:
- Global permissions,
- Authorization schemes,
- Workflow permissions and
- Security schemes.
Global permissions apply across projects in the entire Jira instance. Among other things, they determine which users and user groups have administrator rights, who can share filters and dashboards, and who can make multiple changes to tasks.
The most important global permission is Jira Users. All members of the user groups entered here have permission to log into Jira. In other words, users who are not in at least one of the classes listed in Jira users registered groups (or are administrators) can not log into the system.
The authorization Jira administrator defines which users should be "general" Jira administrators. All users entered here can log in to Jira (even without belonging to a group in Jira users). Jira administrators can create schemas, masks, permissions, etc., in Jira. create and edit schemas and assign them in projects. This point often causes confusion: the permission "Manage projects" in the permission scheme of a project allows not, to assign schemas to this project – only the global Jira administrators described here can do that.
However, Jira administrators do not have full access to the system administration, this is only available to the users with the authorization Jira system administrators (see list of features available to system admins only).
Also for Jira license are the global permissions relevant: in the license count all users who are in one of the global groups (Jira users, Jira administrators, Jira system administrators) and are not disabled.
In contrast to global permissions, permission schemes refer to one or more concrete projects and define which users have which rights in these projects. This includes, among other things, the creation, commenting and deletion of tasks. The visibility of a project will be restricted by the authorization Browse Projects defined. Users who are not registered here will not see the project or any of the tasks within it – not even on the global dashboard or via the task navigator.
Project permissions can be assigned to concrete persons as well as to user groups, project roles and task-specific users (creators, editors, persons in user-defined fields). I personally recommend to use project roles instead of individual users or user groups.
When working with authorization schemes, it is important to be aware of the difference between project authorizations and workflow authorizations. The former refer exclusively to non-workflow-specific authorizations – even if the designations Resolve issues (Resolve Issues) and Close issues let assume otherwise. Still: permissions at workflow transitions are defined in the workflow itself.
Transitions between workflow statuses can be defined in Jira with Conditions (Conditions) are provided. Only if the conditions specified for a transition are met can the process be transferred to the associated target status. Conditions include project permissions and project roles of the current user as well as the status of the subtasks of the task to be selected.
By defining workflow authorizations, it becomes z.B. it is possible that tasks can only be assigned a status after all subtasks have been completed Review be transferred and only the members of the project role Quality Review be able to finally close the process.
Within a project, it may be necessary to restrict the visibility of individual operations to certain user groups. Jira implements this requirement through security schemas. Within a security schema, security levels are defined and linked to individual users, user groups or project or. activity roles. Operations for which a security level has been selected are only visible to the user groups associated with that level.
In the simplest case, you can earn z.B. a security level Admins created and the user group jira-administrators be assigned. All operations for which this security level is selected are exclusively for members of the group jira administrators visible.
When creating a security scheme, a default level should be set that all newly created tasks should automatically receive. This is especially important if not all project members have the permission to select a security level or the corresponding fields have been hidden via the field configuration.
The visibility of individual fields of a process cannot be restricted to certain user groups with standard means. Despite numerous efforts, Atlassian has finally decided not to include this feature in Jira in the future. For some special scenarios, however, a workaround and a commercial plugin are available.