Managing project permissions

Project permissions are created within permission schemes, which are then assigned to specific projects by Jira Administrators. Project permissions can also be used in workflow conditions.

Project permissions are able to be granted based on:

  • Individual users
  • Groups
  • Project roles
  • Issue roles such as Reporter, Project Lead, and Current Assignee
  • Anyone
  • A (multi-)user picker custom field.
  • A (multi-)group picker custom field. This can either be an actual group picker custom field, or a (multi-)select-list whose values are group names.

Granting permission to anyone

Granting the browse projects permission to anyone means issues from projects using that permission scheme are publicly available on the internet. Granting permission to anyone to perform tasks means people who aren't logged in have permission to perform those tasks on issues they're permitted to see.

You may legitimately want to grant public access to some projects and issues on your site, like in the case of a public bug tracker. See Allowing anonymous access to your project for more information.

Some permissions are dependent upon others to ensure that users can perform the actions needed. For example, in order for a user to be able to resolve an issue, that user must be granted both the transition issue permission and the resolve issue permission.

Project permissions overview

Project permissions

Explanation

Administer projects

Permission to administer a project in Jira. This includes the ability to edit project role membershipproject componentsproject versions, and some project detailsproject name, URL, project lead, and project description.

Browse projects

Permission to browse projects, use the issue navigator, and view individual issues (except issues that have been restricted via issue-level security). Many other permissions are dependent on this permission. For example, the work on issues permission is only effective for users who have the browse projects permission.

Manage sprints (only available to Jira Software users)

Permission to perform the following sprint-related actions for all projects in a board:

  • Creating sprints
  • Starting sprints
  • Completing sprints
  • Reopening sprints
  • Reordering future sprints
  • Deleting future sprints
  • Editing sprint information (sprint name and dates)
  • Moving the sprint footer

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.

In general, sprint actions require the manage sprints permission. However, there are some sprint actions (for example, adding issues to sprints, removing issues from sprints) that require the schedule issues and edit issues permissions.

When adding an issue to a sprint:

  • Sub-tasks cannot be moved independently of their parents.
  • An issue can only be assigned to one active sprint or future sprint. This means you can't add an issue to both an active sprint and a future sprint at the same time.
  • You can add any issue to any active or future sprint, even if the issue doesn't match the filter query of the board where the sprint was created. When you do this:
    • the issue is assigned to the sprint, but will not be visible on boards where the filter query excludes it.
    • any sprint actions (for example, start sprint and close sprint) that span multiple boards will also affect the sprint in all boards where the sprint is visible.
    • if the issue doesn't match the filter query of any agile board, the issue will be linked to the sprint but not appear on any board.
  • A sprint appears on any boarda single board or multiple boards, as long as the issues assigned to the sprint match the filter query of the board or boards. This also applies to completed sprints.

See Planning sprints for more information.

View development tools (only available to Jira Software users)

Permission to view the Development panel, which provides you with just enough information to evaluate the status of an issue's development, at a glance.

View (read-only) workflow

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

Explanation

Assign issues

Permission to assign issues to users. It also allows autocompletion of users in the Assign Issue dropdown. See assignable user permission below for more information.

Assignable user

Permission to be assigned issues.

Note that this permission does not include the ability to assign issues. See assign issues permission above for more information.

Close issues

Permission to close issues based on the workflow conditions. This permission is useful where, for example, developers resolve issues and testers close them. Requires the transition issues and resolve issues transitions. See the resolve Issues permission for more information.

Create issues

Permission to create issues in the project. This permission includes the ability to create sub-tasks if sub-tasks are enabled.

Note that the create attachments permission is required in order to create attachments.

Delete issues

Permission to delete issues. Be careful about which groups or project roles you assign this permission to. Usually, only administrators get permission to delete issues.

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.

Edit issues

Permission to edit issues excluding the Due Date field. See the schedule issues permission for more information. 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. If you have given everyone the create issue permission, everyone will have permission to edit issues. However, it is not advisable to give everyone the ability to edit issues.

Link issues

Permission to link issues together. This permission is relevant if issue linking is enabled.

Modify reporter

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.

Move issues

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.

Resolve issues

Permission to resolve and reopen issues. This also includes the ability to set the Fix For version field for issues. Requires the transition issues permission. See the close issues permission for more information.

Schedule issues

Permission to schedule an issue—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.

Set issue security

Permission to set the security level on specific issues to control who can see them.

Transition issues Permission to transition (change) the status of an issue.

Voters & watchers permissions

Explanation

Manage watcher list

Permission to manageview, add, and remove users to or from the watcher list of an issue.

View voters and watchers

Permission to view the voter list and watcher list of an issue. See the manage watcher list permission for more information.

Comments permissions

Explanation

Add comments

Permission to add comments to issues.

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

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.

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.

Attachments permissions

Explanation

Create attachments

Permission to attach files to an issue. This permission is 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

Explanation

Work on issues

Permission to log work against an issuecreate a worklog entry. This permission is relevant if time tracking is enabled.

Delete all worklogs

Permission to delete any worklog entries, regardless of who added them. This permission is relevant if time tracking is enabled. See the work on issues permission for more information.

Delete own worklogs

Permission to delete worklog entries that were added by the user. This permission is relevant if time tracking is enabled. See the work on issues permission for more information.

Edit all worklogs

Permission to edit any worklog entries, regardless of who added them. This permission is relevant if time tracking is enabled. See the work on issues permission for more information.

Edit own worklogs

Permission to edit worklog entries that were added by the user. This permission is relevant if time tracking is enabled. See the work on issues permission for more information.


Permission schemes

What is a permission scheme?

A permission scheme is a set of user/group/role assignments for the project permissions listed above. Every project has a permission scheme. One permission scheme can be associated with multiple projects.

Why permission schemes?

In many organizations, multiple projects have the same needs regarding access rights. (For example, only the specified project team may be authorized to assign and work on issues).

Permission schemes prevent having to set up permissions individually for every project. Once a permission scheme is set up, it can be applied to all projects that have the same type of access requirements.

Creating a permission scheme

  1. Select the Jira icon (, or ) > Jira settings > Issues.
  2. Select Permission Schemes to open the Permission Schemes page, which displays a list of all permission schemes in your Jira system and the projects that use each scheme.
  3. Click the 'Add Permission Scheme' link.
  4. In the Add Permission Scheme form, enter a name for the scheme, and a short description of the scheme. Select Add.
  5. You will return to the Permission Schemes page which now contains the newly added scheme.

Adding users, groups, or roles to a permission scheme

  1. Select the Jira icon (, or ) > Jira settings > Issues.
  2. Select Permission Schemes to open the Permission Schemes page, which displays a list of all permission schemes in your Jira system and the projects that use each scheme.
  3. Locate the permission scheme you would like to update, and select Permissions in the Actions column to view the scheme.
  4. Select the Edit link for the permission you wish to add to. This displays the Grant permission dialog.
  5. Select who to add the selected permission to, and click the Grant button. The users, groups, or roles will now be added to the selected permission. Project roles are useful for defining specific team members for each project. Referencing project roles rather than users or groups in your permissions can help you minimize the number of permission schemes in your system.
  6. Repeat steps 4 and 5 until all required users, groups, or roles have been added to the permissions.

Deleting users, groups, or roles from a permission scheme

  1. Select the Jira icon (, or ) > Jira settings > Issues.
  2. Select Permission Schemes to open the Permission Schemes page, which displays a list of all permission schemes in your Jira system and the projects that use each scheme.
  3. Locate the permission scheme of interest and click its name to show the list of project permissions (above).
  4. Click the Remove link for the permission you wish to remove the users, groups, or roles from.
  5. Select the users, groups, or roles you wish to remove, and click the Remove button.

Associating a permission scheme with a project

  1. Choose the Jira icon (, or ) > Projects.
  2. Search for and select the project you want to change permissions for.
  3. Select Settings to view the project's settings.
  4. Select Permissions from the sidebar. This displays the current permissions scheme.
  5. Click the Actions dropdown menu and choose Use a different scheme.
  6. On the Associate Permission Scheme to Project page, select the permission scheme you want to associate with the project.
  7. Click the Associate button to associate the project with the permission scheme.

Deleting a permission scheme

  1. Select the Jira icon (, or ) > Jira settings > Issues.
  2. Select Permission Schemes, which displays a list of all permission schemes in your Jira system and the projects that use each scheme.
  3. In the Actions column, click the Delete link for the scheme that you want to delete.
  4. The scheme will be deleted and all associated projects will be automatically associated with the default permission scheme. You can't delete the default permission scheme.

In Jira Software, you can delete the Default software scheme, but this is superficial. Jira will recreate this permission scheme if you create a new software project, and associate it to your new project.

Copying a permission scheme

  1. Select the Jira icon (, or ) > Jira settings > Issues.
  2. Select Permission Schemes to open the Permission Schemes page, which displays a list of all permission schemes in your Jira system and the projects that use each scheme.
  3. In the Actions column, click the Copy link for the scheme that you want to copy.
  4. A new scheme will be created with the same permissions and the same users, groups, or roles assigned to them.
Last modified on Sep 3, 2019

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.