Child pages
  • Structure Permissions

This documentation relates to an older version 2.0 of the Structure Plugin for JIRA. View the current documentation home.

Skip to end of metadata
Go to start of metadata

Every structure has a list of permission rules, which defines who is allowed to see, edit or configure the structure.

Access Levels

Each user has one of the following access levels to a structure:

None

The user does not see the structure at all and does not know that it exists.

View

The user can view the structure but cannot make changes.

Edit

The user can view the structure and can rearrange issues in the structure, add issues to the structure and remove issues from the structure.

Control

The user can view, edit and configure the structure - including changing structure permission rules and configuring synchronizers.

Default Access

By default, all users have None access level.

The structure's owner and JIRA administrators always have Control access level.

Therefore, if you create a new structure and do not specify any permission rules, it will be a private structure that only you and JIRA administrators will be able to see and modify.

Permission Rules

Users who have Control permission on a structure can define permission rules by Editing Structure Details.

Permission rules list is an ordered list that's used to calculate the access level for a given user. Each rule has a condition that is matched against the user, and access level which is set if the condition matches. The conditions are applied from top to bottom, and the last matching rule has precedence.

The following conditions are supported by permission rules:

Anyone

Matches any user, including anonymous (not logged in). This condition can be used to set a default permission for everyone.

Group(G)

Matches users that belong to the group G.

Project Role(R,P)

Matches users that have role R in project P.

Additionally, there is a special rule type Apply Permissions From, which works by going through the permission rules from a different structure. You can apply permission rules only from structures with Control access level for you.

Examples
  • Anyone can view, developers can edit, only the owner and admins can control:

    1. View for Anyone
    2. Edit for jira-developers (Group)

  • Any logged in user can edit, except for the users from structure-noaccess group, who can't even view the structure. Project administrators are allowed to control the structure:

    1. Edit for jira-users (Group)
    2. None for structure-noaccess (Group)
    3. Control for Administrators of Mars Colony (Project Role)

  • Incorrect configuration: everyone is given View access level

    1. Control for jira-developers (Group)
    2. Edit for jira-users (Group)
    3. View for Anyone

    Although the configuration looks ok at first glance, remember that the last matching rule has precedence. So regardless of whether the user is part of jira-developers or jira-users group, their access level will be set to View by the last rule.

Edit Issue JIRA Permission and Editing Structure

If you set Require Edit Issue Permission on Parent Issue flag on the Structure Details page, additional per-issue permissions checks will be performed to decide whether the user is allowed to change the structure.

If the flag is on, the user must have Edit Issue permission on a parent issue to adjust its sub-issues. In other words, direct sub-issues (or children issues) are treated as if they are part of the parent issue, and therefore adding sub-issues, removing sub-issues and rearranging sub-issues is actually changing the parent issue - for which the Edit Issue permission is required.

The user must also have Edit access level to the structure to be able to make changes at all.

Note the following:

  • Top-level issues do not have a parent issue, and therefore are not affected by this flag: the user can add/rearrange issues at the top level of the structure if they have Edit access level.
  • If issue A has sub-issue B, and B has sub-issue C, then to be able to move or remove C from the structure, the user needs Edit Issue permission on B - not on A. In other words, the Edit Issue permission is required only for the direct parent issue.
Permissions Caching
Structure plugin maintains a cache of users permissions with regards to each structure. In most cases, the cache is recalculated automatically, but in some cases Structure plugin may miss a change in a user's groups or roles. The result could be that the changed permissions take effect several minutes later (but only with regards to Structure Permissions). A user can force the cache to be recalculated by doing hard refresh from the browser. Typically, it's done by holding Ctrl or Shift or both and clicking the Refresh button.