Permissions overview
This page describes the different types of permissions and access rights that can be set up in JIRA applications.
What are permissions?
Permissions are settings within JIRA applications that control what users within those applications can see and do. All JIRA applications allow a variety of permissions: from whether users can create new projects to whether a user can see a specific type of comment on an issue. These permissions can differ between applications.
Permissions are different from application access, which is controlled by groups that have Use access for an application. For more information about setting application access, see Managing user access to JIRA applications.
Types of permissions
We previously announced that we're releasing a new type of project-level permission inJIRA Software, the Manage Sprints permission, and this will be rolled out in two releases. Based on feedback we've collected after shipping the first release, we're not pushing through with the second release, as previously planned.
See Updates on the planned second release of sprint management permission for more information.
There are three types of permissions in JIRA applications, and they range from the high-level to granular:
- Global permissions - These apply to applications as a whole, not individual projects (for example, whether users can see the other users in the application).
- Project permissions - Organized into permission schemes, these apply to projects (e.g. who can see the project's issues, create, edit and assign them). While project admins can assign users to a project, they can't customize the permission schemes for a project. There are lots of project-level permissions you can set to control what users can do within a project.
- Issue security permissions - Organized into security schemes, these allow the visibility of individual issues to be adjusted (within the bounds of the project's permissions). For example, issue security permissions can let you set up types of issues that can only be seen by project admins or users in specific groups.
How do permissions get assigned?
Permissions can be assigned to groups or to project roles/and or issue roles. This diagram illustrates how permissions are assigned to users:
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 | |
Project permission | A user with the JIRA System administrator permission A user in a group with Admin access | |
Issue security permission | A user with the JIRA System administrator permission A user in a group with Admin access A project 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 issues, etc. Board usage permissions are derived from project permissions. This is described in more detail below.
JIRA Software functions by permission
In the JIRA Software documentation, most configuration options are described as being restricted to either JIRA administrators, project administrators, or board administrators.
- A JIRA administrator is a user with the JIRA administrators global permission.
- A project administrator is a user with the Administer projects project permission for a particular project.
By default, the 'Administer projects' permission is assigned to the 'administrators' group (via the Administrators role) for projects.
Additionally, to perform sprint-related actions, users need the 'Manage sprints' permission for all projects 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 | Project admin | Board admin | Notes |
---|---|---|---|---|
Create board | If you create a board via Boards (in header) > Manage Board, you will not be able to share it, unless you have the 'Create Shared Objects' global permission. If you create the board via the methods below, you do not need the 'Create Shared Objects' global permission to share the board:
| |||
Simplify workflow | The board must meet other criteria as well (see Simplified Workflow) | |||
Add status | Project must be currently using an Agile Simplified Workflow. You need to be a JIRA admin or board admin (to view the board configuration), In addition, you need to be a project admin for the one project that is on the board. | |||
Remove status | Project must be currently using an Agile Simplified Workflow. You need to be a JIRA admin or board admin (to view the board configuration), In addition, you need to be a project admin for the one project that is on the board. | |||
All other board configuration functions |
Board usage
Board usage permissions are derived from project 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 projects in the board) Schedule Issues permission and Edit Issues permission | |
Move issue (reorder/rank) | Schedule Issues permission and Edit Issues permission | Not required if you only move issues across the sprint footer without changing the order of the issues |
Start sprint | Manage Sprints permission (for all projects in the board) | Similar permission to creating a Version. Board ownership does not play a role here. |
Create sprint | Manage Sprints permission (for all projects in the board) | This permission applies even if the sprint (that is to be started) does not include issues from all projects queried by the board. |
Edit sprint information | Manage Sprints permission (for all projects in the board) | Can only be done in the backlog |
Reorder sprint | Manage Sprints permission (for all projects in the board) | |
Delete sprint | Manage Sprints permission (for all projects in the board) | |
Add issue to sprint | Schedule Issues permission and Edit Issues permission | |
Active sprints — Sprints | ||
Add issue to sprint | Schedule Issues permission and Edit Issues permission | |
Complete sprint | Manage Sprints permission (for all projects in the board) | Can only be done in Active sprints |
Remove issue from sprint | Schedule Issues permission and Edit Issues permission | |
Backlog — Epics | ||
Create epic | Create Issues permission | |
Rename epic | Edit Issues permission | |
Rank epic | Schedule Issues permission | |
Add issue to epic | Edit Issues permission | |
Remove issue from epic | Edit Issues permission | |
Backlog — Versions | ||
Create version | Project Admin permission, or JIRA Admin permission | |
Edit version | Project Admin permission, or JIRA Admin permission | |
Add issue to version | Edit Issues permission | |
Remove issue from version | Edit Issues permission |