Permissions overview

Jira applications overview

On this page

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. For more information about setting application access, see Managing user access to Jira 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 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:

Permissions

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

Managing global permissions

Project permission

A user with the Jira System administrator permission

A user in a group with Admin access

Managing project permissions

Issue security permission

A user with the Jira System administrator permission

A user in a group with Admin access

A project admin

Configuring issue-level security

 

Jira Service Desk global and project permissions

Jira Service Desk provides a standard permission scheme (Jira Service Desk Permission scheme for project) that automatically gives your service desk users the correct permissions for the project role they are in. For example, adding agents to your service desk will add users to the Service Desk Team role. This role gives them access to Jira Service Desk projects to which they're assigned and also allows them to work on issues. 

Global permissions

At installation time, Jira Service Desk 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 desk 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

  • Service Desk Customer - Portal Access
  • Project Role (Service Desk Team)
  • Project Role (Administrators)

Permission to browse projects, use the Issue Navigator and view individual issues (except issues that have been restricted via issue security). Many other permissions are dependent on this permission, e.g. the 'Work On Issues' permission is only effective for users who also have the 'Browse Projects' permission.

View Development Tools

  • Project Role (Administrators)
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

  • Project Role (Service Desk Team)
  • Project Role (Administrators)

Permission to view the project's 'read-only' workflow when viewing an issue. This permission provides the 'View Workflow' link against the Status field of the 'View Issue' page.

Issue Permissions

Users / Groups / Project roles

Explanation

Create Issues
  • Service Desk Customer - Portal Access
  • Project Role (Service Desk Team)
  • Project Role (Administrators)
Permission to create issues 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 Issues
  • Service Desk Customer - Portal Access
  • Project Role (Service Desk Team)
  • Project Role (Administrators)
Permission to edit issues (excluding the 'Due Date' field — see the Schedule Issues permission). Includes the ability to convert issues to sub-tasks and vice versa (if sub-tasks are enabled). Note that the Delete Issue permission is required in order to delete issues. The Edit Issue permission is usually given to any groups or project roles who have the Create Issue permission (perhaps the only exception to this is if you give everyone the ability to create issues — it may not be appropriate to give everyone the ability to edit too). Note that all edits are recorded in the issue change history for audit purposes.
Transition Issues
  • Service Desk Customer - Portal Access
  • Project Role (Service Desk Team)
  • Project Role (Administrators)
Permission to transition (change) the status of an issue.
Schedule Issues
  • Service Desk Customer - Portal Access
  • Project Role (Service Desk Team)
  • Project Role (Administrators)
Permission to schedule an issue — that is, to edit the 'Due Date' of an issue. In older versions of Jira this also controlled the permission to view the 'Due Date' of an issue.
Move Issues
  • Service Desk Customer - Portal Access
  • Project Role (Service Desk Team)
  • Project Role (Administrators)
Permission to move issues from one project to another, or from one workflow to another workflow within the same project. Note that a user can only move issues to a project for which they have Create Issue permission.

Assign Issues

  • Service Desk Customer - Portal Access
  • Project Role (Service Desk Team)
  • Project Role (Administrators)

Permission to assign issues to users. Also allows autocompletion of users in the Assign Issue drop-down. (See also Assignable User permission below)

Assignable User

  • Project Role (Service Desk Team)
  • Project Role (Administrators)

Permission to be assigned issues. (Note that this does not include the ability to assign issues; see Assign Issue permission).

Resolve Issues
  • Service Desk Customer - Portal Access
  • Project Role (Service Desk Team)
  • Project Role (Administrators)
Permission to resolve and reopen issues. This also includes the ability to set the 'Fix For version' field for issues. Also see the Close Issues permission.

Close Issues

  • Service Desk Customer - Portal Access
  • Project Role (Service Desk Team)
  • Project Role (Administrators)

Permission to close issues. (This permission is useful where, for example, developers resolve issues and testers close them). Also see the Resolve Issues permission.

Modify Reporter

  • Service Desk Customer - Portal Access
  • Project Role (Service Desk Team)
  • Project Role (Administrators)

Permission to modify the 'Reporter' of an issue. This allows a user to create issues 'on behalf of' someone else. This permission should generally only be granted to administrators.

Delete Issues

  • Service Desk Customer - Portal Access
  • Project Role (Service Desk Team)
  • Project Role (Administrators)

Permission to delete issues. Think carefully about which groups or project roles you assign this permission to; usually it will only be given to administrators. Note that deleting an issue 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 Issues permission does not include the ability to delete individual comments or attachments.

Link Issues

  • Service Desk Customer - Portal Access
  • Project Role (Service Desk Team)
  • Project Role (Administrators)

Permission to link issues together. (Only relevant if Issue Linking is enabled).

Set Issue Security

  • Service Desk Customer - Portal Access
  • Project Role (Service Desk Team)
  • Project Role (Administrators)

Permission to set the security level on an issue to control who can access the issue. Only relevant if issue security has been enabled.

Voters & Watchers Permissions

Users / Groups / Project Roles

Explanation

View Voters and Watchers
  • Service Desk Customer - Portal Access
  • Project Role (Service Desk Team)
  • Project Role (Administrators)
Permission to view the voter list and watcher list of an issue. Also, see the Manage Watcher List permission.

Manage Watcher List

  • Service Desk Customer - Portal Access
  • Project Role (Service Desk Team)
  • Project Role (Administrators)

Permission to manage (i.e. view/add/remove users to/from) the watcher list of an issue.

Comments Permissions

 

Explanation

Add Comments

  • Service Desk Customer - Portal Access
  • Project Role (Service Desk Team)
  • Project Role (Administrators)

Permission to add comments to issues. Note that this does not include the ability to edit or delete comments.

Edit All Comments
  • Project Role (Service Desk Team)
  • Project Role (Administrators)
Permission to edit any comments, regardless of who added them.

Edit Own Comments

  • Service Desk Customer - Portal Access
  • Project Role (Service Desk Team)
  • Project Role (Administrators)

Permission to edit comments that were added by the user.

Delete All Comments
  • Project Role (Service Desk Team)
  • Project Role (Administrators)
Permission to delete any comments, regardless of who added them.
Delete Own Comments
  • Service Desk Customer - Portal Access
  • Project Role (Service Desk Team)
  • Project Role (Administrators)
Permission to delete comments that were added by the user.

Attachments Permissions

Users / Groups / Project Roles

Explanation

Create Attachments

  • Service Desk Customer - Portal Access
  • Project Role (Service Desk Team)
  • Project Role (Administrators)

Permission to attach files to an issue. (Only relevant if attachments are enabled). Note that this does not include the ability to delete attachments.

Delete All Attachments

  • Project Role (Service Desk Team)
  • Project Role (Administrators)

Permission to delete any attachments, regardless of who added them.

Delete Own Attachments

  • Service Desk Customer - Portal Access
  • Project Role (Service Desk Team)
  • Project Role (Administrators)

Permission to delete attachments that were added by the user.

Time Tracking Permissions

Users / Groups / Project Roles

Explanation

Work On Issues

  • Project Role (Service Desk Team)
  • Project Role (Administrators)

Permission to log work against an issue, i.e. create a worklog entry. (Only relevant if Time Tracking is enabled).

Edit Own Worklogs
  • Project Role (Service Desk Team)
  • Project Role (Administrators)
Permission to edit worklog entries that were added by the user. (Only relevant if Time Tracking is enabled). Also, see the Work On Issues permission.
Edit All Worklogs
  • Project Role (Administrators)
Permission to edit any worklog entries, regardless of who added them. (Only relevant if Time Tracking is enabled). Also, see the Work On Issues permission.

Delete Own Worklogs

  • Project Role (Service Desk Team)
  • Project Role (Administrators)

Permission to delete worklog entries that were added by the user. (Only relevant if Time Tracking is enabled). Also, see the Work On Issues permission.

 Delete All Worklogs
  • Project Role (Administrators)

Permission to delete any worklog entries, regardless of who added them. (Only relevant if Time Tracking is enabled). Also, see the Work On Issues permission.

Using custom permission schemes

If you are a service desk 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.

Last modified on Dec 5, 2017

Was this helpful?

Yes
No
Provide feedback about this article

Not finding the help you need?

Ask the community

Powered by Confluence and Scroll Viewport.