Managing project permissions

Project permissions comprise permission schemes that Jira admins configure according to their projects' requirements and then assign to these projects. Project permissions can be granted to:

  • individual users
  • groups
  • project roles
  • issue roles such as Reporter, Project Lead, and Current Assignee
  • the Anyone group to allow anonymous access
  • a multi-user picker custom field
  • a multi-group picker custom field, which is either an actual group picker custom field or a multiselect list where values are group names

Some permissions depend on others to ensure that users can perform required actions. For example, if a user wants to be able to resolve an issue, they must be granted both the Transition Issue permission and the Resolve Issue permission. 

As a system admin or admin, you can manage project permissions, but you can't create new, custom permissions.

Learn more about the global permissions

Learn more about the difference between global and project permissions

On this page:

Some project permissions require product access. This means they're applicable only if your users have access to the Atlassian product associated with the permission. For example, if you give someone the permission to edit issues in a Jira Software project, they still require product access to Jira Software to use this permission.

If you add users to a role that grants particular permissions, make sure these users have product access to Jira Software (for software projects) or Jira Service Management (for service projects). Otherwise, your users will see a read-only version of the projects you want them to work on.

Only a Jira admin can grant individual product access. Learn more about product access

Project permissions overview

The following table lists different types of project permissions and user actions they allow. Note that project permissions can also be used in workflow conditions.


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 details (Project Name, URL, Project Lead, Project Description).

Granting this permission alongside the Browse projects permission lets a user see the audit log for a specific project.

A user with the Administer Projects permission automatically becomes a project admin. Unlike Jira admins,  project admins can't manage multiple system configurations, including project permission schemes. 

Learn more about the differences between a project admin and Jira admin

Extended project administration

Gives the project administrator the ability to edit workflows and screens under certain conditions, as well as maintain their own workflows within predefined guardrails (data type recommendations for identifying potential risks and making decisions about your instance optimization).

Restrictions for editing the project's workflows...
  • The workflow mustn't be shared with any other projects and mustn't be a system workflow.
  • Only a status that already exists on the instance can be added to the workflow. The project admin can't create new statuses or edit existing ones.
  • A status can be deleted if it's not used in any of the project's issues.
  • The project admin can create, update, or delete transitions. But they can't select or update a screen used by the transition nor edit and view a transition's properties, conditions, validators, or post-functions.
Restrictions for editing the project's screens...
  • The screen mustn't be a default system screen.
  • The screen mustn't be shared with any other projects nor used as a transition screen in workflows.
  • The project admin can add, remove, and rearrange system fields.
  • The project admin can add, remove, and rearrange existing custom fields, but they can't create custom fields.
Why can your project administrator edit workflows when the permission is disabled?

When the Extended project admin permission is disabled, a project administrator may still be able to edit the Simplified Workflow by adding statuses that may not exist in the system. 

This is because the project admin is also listed as a board admin. Their changes to the Simplified Workflow will alter the project’s regular workflow. 

If you don't want this to happen, we recommend switching from the Simplified Workflow to the regular workflow. 

Browse projects

Permission to browse projects, use the Issue Navigator, and view individual issues, except for the issues that have been restricted via issue-level security

Many other permissions depend on this permission. For example, the Work on issues permission only works for users who also have the Browse projects permission.

Granting this permission alongside the Administer projects permission lets a user see the audit log for a specific project.

The Browse Projects permission may make your projects publicly visible on the internet

Here are a few important things you should remember about this permission.

The Browse projects permission may make your project details visible to all users in directories and while searching through Jira.

When you grant the permission to ReporterCurrent assignee, or Group custom field value, your project becomes visible to any logged in user on your Jira site.

Also, granting the Browse Projects permission to Anyone in your permission scheme means that issues from a project that uses this scheme become publicly viewable on the internet. 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. Learn more about anonymous access

Use the Browse Projects permission to allow users only to view issues

To give users view-only access to issues:

  • Grant the Browse projects permission
  • Make sure your users don't have permissions of any other type

Users can also comment on issues or track work in them without editing issue details. To do this:

  • Grant the Browse projects permission
  • Grant the comments or time tracking permissions, depending on what you'd like to allow users
  • Make sure users don't have any issues permissions

Manage sprints (only available to Jira Software users)

Permission to perform the following sprint-related actions for all projects on a board.

Actions
  • Create sprints
  • Start sprints
  • Complete sprints
  • Reopen sprints
  • Reorder future sprints
  • Add sprint goals
  • Delete sprints
  • Edit sprint information (sprint name, goal, dates)
  • Move the sprint footer

When you have complex board filter queries, you should be careful with 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.

Notes on working with sprints

In general, sprint actions require the Manage Sprints permission. But there are some sprint actions (like adding issues to sprints or removing issues from sprints) that require the Schedule Issues and Edit Issues permissions.

When adding an issue to a sprint:

  • Sub-tasks can't be moved independently of their parents.
  • An issue can only be assigned either to one active sprint or to one future sprint. 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 a filter query of the board where the sprint was created. When you do this:
    • The issue will be assigned to the sprint but won't be visible on boards where the filter query excludes it.
    • Any sprint actions (like starting a sprint or closing a 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 won't appear in any board.
  • A sprint appears on any board—a 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.

Start/Complete sprints (only available to Jira Software users)

Permission to start sprints and end them when the sprint dates are set. This permission doesn’t let the user change any sprint properties, such as the name, goal, and dates. The user can only change sprint status to Active or Completed.

Edit sprints (only available to Jira Software users)

Permission to change the sprint name and goal. With this permission, the user can’t change sprint dates nor start or end a sprint.

View development tools (only available to Jira Software users)

Permission to view the Development panel, which provides the user with information to evaluate the status of an issue's development.

View (read-only) workflow

Permission to view the project's read-only workflow when viewing an issue. This permission provides the View workflow link in the Status field in the issue view.

Issue permissions

Explanation

Assign issues

Permission to assign issues to users. This permissions also allows autocompletion of users in the Assign Issue dropdown.

Assignable user

Permission allows a user to be assigned issues but doesn't include the ability to assign issues to other users. The latter is provided by the Assign Issues permission.

Close issues

Permission to close issues based on the workflow conditions. This permission helps developers resolve issues and testers close them. It also requires the Transition Issue and Resolve Issue transitions. 

Create issues

Permission to create issues and sub-tasks (if enabled) in the project. To create attachments, the Create attachments permission is also required.

Users with this permission don’t need the Browse projects permission to create issues. However, you should still ensure that your users at least have permission to browse projects. Otherwise, even though they will be able to create an issue, they won’t be able to see it.

Delete issues

Permission to delete issues along with individual comments and attachments in them.

  • To delete only comments or only attachments, but not issues, users need the Delete comments or Delete attachments permissions, respectively. 
  • But if the user doesn’t have these permissions and is deleting an issue, the related comments and attachments will be deleted. 
  • Think carefully which groups or project roles you assign this permission to. Usually, it’s only given to administrators. 

Edit issues

Permission to edit issues and convert issues to sub-tasks and vice versa, if sub-tasks are enabled.

  • When granting this permission, make sure your users also have at least the Browse projects permission. Without it, they won't see any projects and issues in them.
  • Users with this permission won’t be able to edit the Due Date and Sprint fields. To allow this, give them the Schedule issues permission. 
  • The Edit issues permission is usually given to groups or project roles that have the Create issues permission. But if all your users can create issues, you may want to give the Edit issues permissions to some of them only. 
  • To delete issues, the Delete issues permission is required. 
Link issues

Permission to link issues together when issue linking is enabled.

Modify reporter

Permission to modify the Reporter of an issue so that it’s created on behalf of another user. 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. With this permission, users can only move issues to a project where they have Create Issue permission.

Resolve issues

Permission to resolve and reopen issues based on the workflow condition, as well as set the Fix for version field for issues. Note that this permission requires the Transition Issues permission. 

Schedule issues

Permission to schedule issues by editing the Due Date and Sprint fields. In older versions of Jira, this permission also controls the permission to view the fields.

When granting this permission, make sure your users also have at least the Browse Projects permission. Without it, they won't see any projects and issues in them.

Set issues security

Permission to set the security level for an issue to control who can access the issue. The permission is relevant if issue security has been enabled.

Transition issuesPermission to change the status of an issue.

Voters & watchers permissions

Explanation

Manage watcher list

Permission to manage the watcher list of an issue: view users, add them to or remove them from the list.

View voters and watchers

Permission to view the voter list and watcher list in issues. 

Comments permissions

Explanation

Add comments

Permission to add comments to issues but without the ability to edit or delete comments.

Delete all comments

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

Delete own comments

A user with this permission can only delete their own comments.

Edit all comments

Permission to edit any comments, regardless of who added them.

Edit own comments

A user with this permission can only edit their own comments.

Attachments permissions

Explanation

Create attachments

Permission to attach files to issues if attachments are enabled. This permission doesn't include the ability to delete attachments.

Delete all attachments

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

Delete own attachments

A user with this permission can only delete their own attachments.

Time-tracking permissions

Explanation

Work on issues

Permission to log work on an issue (that is to create a worklog entry) if time tracking is enabled. This permission is required as a prerequisite for applying the other time-tracking permissions.

Delete all worklogs

Permission to delete any worklog entries, regardless of who added them. This permission only works if time tracking is enabled.

Delete own worklogs

A user with this permission can delete only their own worklog entries. This permission only works if time tracking is enabled.

Edit all worklogs

Permission to edit any worklog entries, regardless of who added them. This permission only works if time tracking is enabled.

Edit own worklogs

A user with this permission can edit only their own worklog entries. This permission only works if time tracking is enabled.

Archiving permissionsExplanation
Archive issues for a projectPermission to archive issues in a specific project. This permission doesn't allow the user to archive issues in bulk.
Restore issues for a projectPermission to restore issues in a specific project.
Browse archivePermission to view all archived issues. To do this, go to Issues > Archived issues.
Browse project archivePermission to view archived issues that belong to a specific project. To do this, go to Issues > Archived issues.


Permission schemes

Learn about the concept of permission scheme and why you should use it to configure user permission on your Jira instance. 

What is a permission scheme?

A permission scheme is a set of assignments between project permission and a user, group, or role. Every project has a permission scheme. One permission scheme can be associated with multiple projects. 

Why use permission schemes?

In many organizations, multiple projects have the same requirements for access rights. Permission schemes eliminate the need 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.

Default vs. project-specific permission scheme

All Jira instances come with the Default Permission Scheme that contains default configurations for all permissions on your instance. You can't delete the default permission scheme. 

Also, when you create a software or business project, it already has its own permission scheme assigned. The permission configurations in this project-specific scheme are very similar to those in the default permission scheme.

You can delete the permission scheme that comes with your software or business project. In this case, the default permission scheme will apply to your project. A project must always have an assigned permission scheme.

You can also create your own permission scheme and assign it to a project. The new permission scheme you assign will override the permission scheme that was previously assigned to the project. Learn how to change the permission scheme for your project

Creating a permission scheme

To create a new permission scheme: 

  1. In the upper-right corner of the screen, select Administration  > Issues.
  2. Select Permission Schemes to open the list of all permission schemes in your Jira and the projects that use each scheme.
  3. Select Add Permission Scheme.
  4. In the Add Permission Scheme form, enter a name and a short description of the scheme.
  5. Select Add. You'll return to the Permission Schemes page where you'll find the new scheme.

Adding users, groups, or roles to a permission scheme

To add a user, group, or role that can have permissions from a permission scheme: 

  1. In the upper-right corner of the screen, select Administration  > Issues.
  2. Select Permission Schemes to open the list of all permission schemes in your Jira and the projects that use each scheme. 
  3. Open a scheme by selecting Permissions in the Actions column. 
  4. Select Edit for a permission where you want to add a user, group, or role.
  5. You’ll see the Grant permission dialog. Select who you want to grant the permission to. Select Grant. The selected users, groups, and roles will be added to the permission.

Project roles are useful for defining specific team members for each project. Selecting project roles rather than users or groups can help you minimize the number of permission schemes in the system.

Deleting users, groups, or roles from a permission scheme

To remove a user, group, or role from a permission scheme:

  1. In the upper-right corner of the screen, select Administration  > Issues.
  2. Select Permission Schemes to open the list of all permission schemes in your Jira and the projects that use each scheme.
  3. Open a scheme by selecting Permissions in the Actions column.
  4. Select Remove for a permission where you want to delete a user, group, or role
  5. Select a user, group, or role you want to remove. Then, select Remove. The deleted users, groups, and roles won’t be able to perform an action provided by the permission. 

Associating a permission scheme with a project

To apply a permission scheme to a project:

  1. In the upper-right corner of the screen, select Administration  > Projects.
  2. Select a project. See Defining a project for more information.
  3. In the Project settings, go to Permissions.
  4. Select Actions > Use a different scheme.
  5. On the Associate Permission Scheme to Project page, select a permission scheme you want to associate with the project.
  6. Select Associate. The scheme will be applied to the project. 

Deleting a permission scheme

To delete a permission scheme:

  1. In the upper-right corner of the screen, select Administration  > Issues.
  2. Select Permission Schemes to open the list of all permission schemes in your Jira and the projects that use each scheme.
  3. Select Delete in the Actions column. Note that you can delete the Default Permission Scheme.
  4. On the Delete Permission Scheme page, select Delete to confirm your action. The scheme will be deleted. All associated projects will be automatically associated with the Default Permission Scheme.  

Copying a permission scheme

To copy a permission scheme: 

  1. In the upper-right corner of the screen, select Administration  > Issues.
  2. Select Permission Schemes to open the list of all permission schemes in your Jira and the projects that use each scheme.
  3. Select Copy in the Actions column. The copy will be created with the same permissions as well as with the same users, groups, and roles assigned to them. 
Last modified on Dec 6, 2022

Was this helpful?

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