How do Jira permissions work?
This page describes the different types of permissions and access rights that can be set up in Jira apps.
You can't edit space permissions or roles on the Free plan for software and business spaces, and you can't configure work-level security on any Free plan (including Jira Service Management). Find out more about how space permissions work in Free plans. To take advantage of Jira's powerful space permission management features, upgrade your plan.
What are permissions?
Permissions are settings within Jira apps that control what users within those apps can see and do. All Jira apps allow a variety of permissions — from whether users can create new spaces to whether a user can see a specific type of comment on a work item. These permissions can differ between apps.
Types of permissions
There are three types of permissions in Jira apps, and they range from the high-level to granular:
Global permissions: These apply to apps as a whole, not individual spaces (for example, whether users can see the other users in the app).
Space permissions: Organized into permission schemes, these apply to spaces (e.g. who can see the space's work items, create, edit, and assign them). While space admins can assign users to a space, they can't customize the permission schemes for a space. There are lots of space-level permissions you can set to control what users can do within a space.
Work item security permissions: Organized into security schemes, these allow the visibility of individual work items to be adjusted (within the bounds of the space's permissions). For example, work item security permissions can let you set up types of work items that can only be seen by space admins or users in specific groups.
How do permissions get assigned?
Permissions can be assigned to groups or to space and work roles.
A user can be identified as:
part of a group
associated with a space role
a relevant field value (assignee, reporter or custom fields)
Global (site-level) or space permission can be granted to a user:
through an email notification
if a group itself is granted permission
once assigned to the space role
Space permission can also be granted by selecting a field, then assigned the permission.
Schemes
Permission schemes contain a set of permission keys associated with permission grants.
Work security schemes contain a set of security levels associated with security level grants.
Both schemes are associated with spaces.
Who can set permissions?
Permission | Can be set by | For more info, see... |
|---|---|---|
Global permission | A user with the Jira System administrator permission A user in a group with Admin access | |
Space permission | A user with the Jira System administrator permission A user in a group with Admin access | |
Work item security permission | A user with the Jira System administrator permission A user in a group with Admin access A space admin |
Board permissions can be divided into two parts — board administration permissions and board usage permissions.
Board administration permissions cover functionality for changing the configuration of a board. For example, changing columns, customizing cards, etc. Board administration can be assigned to groups or users. Learn more: Configuring a board
Board usage permissions cover functionality for the usage of a board. For example, creating sprints, ranking work items, etc. Board usage permissions are derived from space permissions. This is described in more detail below.
Functions by permission in software spaces
In documentation for Jira software spaces, most configuration options are described as being restricted to either Jira administrators, space administrators, or board administrators.
A Jira administrator is a user with the Administer Jira global permission.
A space administrator is a user with the Administer spaces permission for a particular space.
By default, the Administer spaces permission is assigned to the 'administrators' group (via the Administrators role) for spaces.
Additionally, to perform sprint-related actions, users need the Manage sprints permission for all spaces in the origin board — the origin board being the board in which the sprint was originally created.
A board administrator is a user that has been added to the Administrators for a particular board.
By default, the administrator of a board includes the person who created it.
Board administration
Function / Functional area | Jira | Space | Board admin | Notes |
|---|---|---|---|---|
Create board | If you create a board by selecting Boards in the header, then Manage board, you won’t be able to share it, unless you have the Create Shared Objects global permission. If you create the board via the methods below, you don’t need the Create Shared Objects global permission to share the board:
| |||
Simplify workflow |
| The board must meet other criteria as well (see Use the simplified workflow) | ||
Add status | Space must be using the simplified workflow. You need to be a Jira admin or board admin (to view the board configuration). In addition, you need to be a space admin for the one space that is on the board. | |||
Remove status | Space must be using the simplified workflow. You need to be a Jira admin or board admin (to view the board configuration). In addition, you need to be a space admin for the one space that is on the board. | |||
All other board configuration functions |
|
|
Board usage
Board usage permissions are derived from space permissions. Depending on the complexity of your board's filter query, you may need further consideration when configuring the Manage Sprints permission for users. For more information on the impact of complex filters, and ways to simplify your filter query, see Using Manage Sprints permission for advanced cases.
Function | Permission Level | Notes |
|---|---|---|
Backlog — Sprints | ||
Move sprint footer | Manage Sprints permission (for all spaces in the board) Schedule work items permission and Edit work items permission | |
Move work item (reorder/rank) | Schedule work items permission and Edit work items permission | Not required if you only move work items across the sprint footer without changing the order of the work items |
Start sprint | Manage Sprints permission (for all spaces in the board) | Similar permission to creating a version Board ownership does not play a role here |
Create sprint | Manage Sprints permission (for all spaces in the board) | This permission applies even if the sprint (that is to be started) doesn’t include work items from all spaces queried by the board |
Edit sprint information | Manage Sprints permission (for all spaces in the board) | Can only be done in the backlog |
Reorder sprint | Manage Sprints permission (for all spaces in the board) | |
Delete sprint | Manage Sprints permission (for all spaces in the board) | |
Add work item to sprint | Schedule work items permission and Edit work items permission | |
Active sprints — Sprints | ||
Add work item to sprint | Schedule work items permission and Edit work items permission | |
Complete sprint | Manage Sprints permission (for all spaces in the board) | Can only be done in Active sprints |
Remove work item from sprint | Schedule work items permission and Edit work items permission | |
Backlog — Epics | ||
Create epic | Create work items permission | |
Rename epic | Edit work items permission | |
Rank epic | Schedule work items permission | |
Add work item to epic | Edit work items permission | |
Remove work item from epic | Edit work items permission | |
Backlog — Versions | ||
Create version | Space Admin permission or Jira Admin permission | |
Edit version | Space Admin permission or Jira Admin permission | |
Add work item to version | Edit work items permission | |
Remove work item from version | Edit work items permission | |
Was this helpful?