How permissions interact with each other

On this page, we’ll cover the most common ways that permissions can interact with each other, including:

• Spaces that share workflows and work item layouts

• Permissions for actions that involve multiple spaces

• Tasks that require multiple permissions

• How Jira handles overlapping restrictions

Spaces that share workflows and work item layouts

Those who hold the Edit workflows and Manage work item layouts permission in a scheme can only make changes if their space is the only one using those configurations. If the space shares its workflows or work item layouts with another space, users need the Administer Jira permission to update them.

Actions that require permissions in multiple spaces

In order to make changes that span multiple spaces, such as managing cross-space boards or moving work from one space to another, users need to have permissions in all impacted spaces.

For example:

• To update sprints that contain work from multiple spaces, users need to have the Manage sprints in all spaces where the work items live

• To link work items in different spaces, users need the Link work items permission in both spaces.

Tasks that require multiple permissions

Jira’s permissions are very granular, meaning that some common actions require multiple permissions to complete, such as:

• Almost all work item permissions require the Browse spaces permission.

• The Manage sprints permission only allows a user to update a sprint – not the work within it. To make changes to work items, users need work item-specific permissions such as Edit work items and Schedule work items.

• The Move work items permission allows a user to move work items between spaces, but they also need the Create work items permission in the space to which they’re moving the work.

How Jira handles overlapping restrictions

As as general rule, only users who have been explicitly granted permission can perform an action in Jira. Jira also has permissions with varying levels of specificity which often overlap. When two permissions overlap, the most specific applicable permission determines who can perform an action.

For example, the Edit work items permission allows a user to update all fields on a work item. However, the Assign work items permission grants users the ability to update the Assignee field, specifically. If your scheme only defines the Edit work items permission, anyone who has it can edit any field on a work item, including the Assignee field. But once you configure the Assign work items permission in your scheme:

• only users granted the Assign work items permission can update the Assignee field.

• users who only have the Edit work items permission can still change other fields – just not the Assignee field.

• users with the Assign work items permission but not the Edit work items permission can only change the Assignee field, and no others.

Workflow conditions like the jira.issue.editable condition or the jira.permission* condition can further limit when a field can be edited based on its status. They’re applied using the same logic that favors specific restrictions over generic ones.