Project permissions

When working across multiple projects, it can be helpful to set up permissions in one project and then apply the same permissions to other projects. For example, only specified project teams can assign and work on issues in certain projects. You can set this up using a permission scheme. A permission scheme is a set of users, groups, or roles assigned to selected project permissions. Every project has a permission scheme, which JIRA administrators can then associate with multiple projects, so you don't have to set up permissions for each project.

Project permissions are granted based on:

  • Individual users
  • Groups
  • Project roles
  • Anyone – to allow anonymous access
  • Issue roles, such as Reporter, Project Lead, and Current Assignee
  • A user picker custom field
  • A group picker custom field – this can either be an actual group picker custom field, or a select list whose values are group names

 

This table lists the different types of project permissions. Note that project permissions can also be used in workflow conditions.

Project permissions

Explanation

Administer projects

Permission to administer a project in JIRA. With this permission, you can edit project role membership, project components, project versions, and some project details. e.g. project name, URL, project lead, project description.

Browse projects

Permission to browse projects, use the Issue Navigator, and view individual issues (except issues that are restricted via issue-level 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.

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 these filters, see Using Manage Sprints permission for advanced cases.

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

Assignable user

Permission to be assigned issues. Note that this doesn't include the ability to assign issues.

Assign issues

Permission to assign issues to users. This also allows auto-completion of users in the Assign Issue menu.

Close issues

Permission to close issues based on workflow conditions. This is useful where, for example, developers resolve issues and testers close them.

Note that this permission requires the Transition issue and Resolve issue transitions.

Create issues

Permission to create issues in a project, and includes the ability to create sub-tasks (if sub-tasks are enabled).

Note that the Create Attachments permission is required to create attachments.

Delete issues

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 doesn't include the ability to delete individual comments or attachments.

Think carefully about which groups or project roles you assign this permission to; usually, it will only be given to administrators.

Edit issues

Permission to edit issues, and includes the ability to convert issues to sub-tasks and vice versa (if sub-tasks are enabled). However, this permission excludes the ability to edit the Due Date field — see the Schedule Issues permission.

The Edit Issue permission is usually given to groups or project roles that have the Create Issue permission. Perhaps the only exception to this is if you give everyone the ability to create issues, you may not want to give everyone the ability to edit issues.

Link issues

Permission to link issues together. Note, that this permission requires issue linking to be enabled.

Modify reporter

Permission to modify the reporter of an issue. This lets a user 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 the Create Issue permission.

Resolve issues

Permission to resolve and reopen issues, and includes the ability to set the Fix For version field for issues.

Note that this permission requires the Transition issues permission.

Schedule issues

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.

Set issue security

Permission to set the security level on an issue to control who can access the issue. Note that issue security must be enabled for this permission.

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

Voters & watchers permissions

Explanation

Manage watcher list

Permission to view users in, add users to, and remove users from the watcher list of an issue.

View voters and watchers

Permission to view the voter list and watcher list of an issue.

Comments permissions

Explanation

Add comments

Permission to add comments to issues. Note that this doesn't 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. Note that attachments must be enabled for this permission, and that this doesn't 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 issue, i.e. create a work log entry. Note that time-tracking must be enabled for this permission.

Delete all work logs

Permission to delete any work log entries, regardless of who added them. Note that time-tracking must be enabled for this permission.

Delete own work logs

Permission to delete work log entries that were added by the user. Note that time-tracking must be enabled for this permission.

Edit all work logs

Permission to edit any work log entries, regardless of who added them. Note that time-tracking must be enabled for this permission.

Edit own work logs

Permission to edit work log entries that were added by the user. Note that time-tracking must be enabled for this permission

Last modified on Mar 30, 2017

Was this helpful?

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