This page describes the different types of permissions and access rights that can be set up in Jira applications.
You can't edit project permissions or roles on the Free plan for Jira Software or Jira Work Management, and you can't configure work-level security on any Free plan (including Jira Service Management). Find out more about how project permissions work in Free plans. To take advantage of Jira's powerful project permission management features, upgrade your plan.
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 a work item. These permissions can differ between applications.
Types of permissions
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 work items, 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.
- work item security permissions - Organized into security schemes, these allow the visibility of individual work items to be adjusted (within the bounds of the project's permissions). For example, work item security permissions can let you set up types of work items 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 and work roles.
A User can be identified as:
part of a Group
associated with a Project Role
a relevant field value (Assignee, Reporter or custom fields)
Global (site-level) or Project permission can be granted to a User:
through an email notification
if a group itself is granted permission
once assigned to the project role
Project 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 projects.
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 | |
| Work item 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 work items, 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 Administer Jira 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 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 project admin for the one project that is on the board. |
| Remove status | | | | Project must be currently 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 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 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 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 work items 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 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 projects 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 | Project Admin permission, or Jira Admin permission | |
| Edit version | Project Admin permission, or Jira Admin permission | |
| Add work item to version | Edit work items permission | |
| Remove work item from version | Edit work items permission | |
Jira Service Management global and project permissions
Jira Service Management provides a standard permission scheme (Jira Service Desk Permission scheme for project) that automatically gives your service project users the correct permissions for the project role they are in. For example, adding agents to your service project will add users to the Service Desk Team role. This role gives them access to Jira Service Management projects to which they're assigned and also allows them to work on work items.
Global permissions
At installation time, Jira Service Management creates a global permission named Jira Service Desk agent access. If agent based pricing is enabled for the instance, users who require access to agent views or functionality need to have this permission. The number of users who are granted this permission determines how many agent licenses are used on the system.
Project permissions
This table shows the permission configuration for a standard service project permission scheme:
Project Permissions | Users / Groups / Project roles | Explanation |
|---|---|---|
Administer Projects | Project Role (Administrators) | Permission to administer a project. This includes the ability to edit project role membership, project components, project versions and certain project details (Project Name, URL, Project Lead, Project Description). |
Browse Projects | Permission to browse projects, use the work item Navigator and view individual work items (except work items that have been restricted via work item security). Many other permissions are dependent on this permission, e.g. the 'Work On work items' permission is only effective for users who also have the 'Browse Projects' permission. | |
View Development Tools | Permission to view the Development panel, which displays information from Bitbucket, GitHub, Fisheye, Crucible and Bamboo, if Jira Cloud is integrated with compatible versions of these applications. | |
View (Read-Only) Workflow | Permission to view the project's 'read-only' workflow when viewing a work item. This permission provides the 'View Workflow' link against the Status field of the 'View work item' page. | |
work item permissions | Users / Groups / Project roles | Explanation |
| Create work items | Permission to create work items in the project. (Note that the Create Attachments permission is required in order to create attachments.) Includes the ability to create sub-tasks (if sub-tasks are enabled). | |
| Edit work items | Permission to edit work items (excluding the 'Due Date' field — see the Schedule work items permission). Includes the ability to convert work items to sub-tasks and vice versa (if sub-tasks are enabled). Note that the Delete work item permission is required in order to delete work items. The Edit work item permission is usually given to any groups or project roles who have the Create work item permission (perhaps the only exception to this is if you give everyone the ability to create work items — it may not be appropriate to give everyone the ability to edit too). Note that all edits are recorded in the work item change history for audit purposes. | |
| Transition work items | Permission to transition (change) the status of a work item. | |
| Schedule work items | Permission to schedule a work item — that is, to edit the 'Due Date' of a work item. In older versions of Jira this also controlled the permission to view the 'Due Date' of a work item. | |
| Move work items | Permission to move work items from one project to another, or from one workflow to another workflow within the same project. Note that a user can only move work items to a project for which they have Create work item permission. | |
Assign work items | Permission to assign work items to users. Also allows autocompletion of users in the Assign work item drop-down. (See also Assignable User permission below) | |
Assignable User | Permission to be assigned work items. (Note that this does not include the ability to assign work items; see Assign work item permission). | |
| Resolve work items | Permission to resolve and reopen work items. This also includes the ability to set the 'Fix For version' field for work items. Also see the Close work items permission. | |
Close work items | Permission to close work items. (This permission is useful where, for example, developers resolve work items and testers close them). Also see the Resolve work items permission. | |
Modify Reporter | Permission to modify the 'Reporter' of a work item. This allows a user to create work items 'on behalf of' someone else. This permission should generally only be granted to administrators. | |
Delete work items | Permission to delete work items. Think carefully about which groups or project roles you assign this permission to; usually it will only be given to administrators. Note that deleting a work item will delete all of its comments and attachments, even if the user does not have the Delete Comments or Delete Attachments permissions. However, the Delete work items permission does not include the ability to delete individual comments or attachments. | |
Link work items | Permission to link work items together. (Only relevant if work item Linking is enabled). | |
Set work item security | Permission to set the security level on a work item to control who can access the work item. Only relevant if work item security has been enabled. | |
Voters & Watchers Permissions | Users / Groups / Project Roles | Explanation |
| View Voters and Watchers | Permission to view the voter list and watcher list of a work item. Also, see the Manage Watcher List permission. | |
Manage Watcher List | Permission to manage (i.e. view/add/remove users to/from) the watcher list of a work item. | |
Comments Permissions | Explanation | |
Add Comments | Permission to add comments to work items. Note that this does not include the ability to edit or delete comments. | |
| Edit All Comments | Permission to edit any comments, regardless of who added them. | |
Edit Own Comments | Permission to edit comments that were added by the user. | |
| Delete All Comments | Permission to delete any comments, regardless of who added them. | |
| Delete Own Comments | Permission to delete comments that were added by the user. | |
Attachments Permissions | Users / Groups / Project Roles | Explanation |
Create Attachments | Permission to attach files to a work item. (Only relevant if attachments are enabled). Note that this does not include the ability to delete attachments. | |
Delete All Attachments | Permission to delete any attachments, regardless of who added them. | |
Delete Own Attachments | Permission to delete attachments that were added by the user. | |
Time Tracking Permissions | Users / Groups / Project Roles | Explanation |
Work On Work Items | Permission to log work against a work item, i.e. create a worklog entry. (Only relevant if Time Tracking is enabled). | |
| Edit Own Worklogs | Permission to edit worklog entries that were added by the user. (Only relevant if Time Tracking is enabled). Also, see the Work On work items permission. | |
| Edit All Worklogs | Permission to edit any worklog entries, regardless of who added them. (Only relevant if Time Tracking is enabled). Also, see the Work On work items permission. | |
Delete Own Worklogs | Permission to delete worklog entries that were added by the user. (Only relevant if Time Tracking is enabled). Also, see the Work On work items permission. | |
| Delete All Worklogs | Permission to delete any worklog entries, regardless of who added them. (Only relevant if Time Tracking is enabled). Also, see the Work On work items permission. |
Using custom permission schemes
If you are a Jira administrator and you want to customize the standard permission scheme, make sure that the roles have the mandatory permissions. See Customizing JIRA Service Desk permissions.
Resolving permission scheme errors
If you encounter any error messages related to your service desk's permission scheme, check out Resolving service desk project permission errors.