Message-ID: <373641358.16050.1711718970569.JavaMail.appbox@confluence> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_16049_634473631.1711718970569" ------=_Part_16049_634473631.1711718970569 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html Structure Permissions

Structure Permissions

Every structure has a list of permission rules, which define 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 an= d does not know that it exists.

View

The user can view the structure but cannot ma= ke changes.

Edit

The user can view the structure and can rearr= ange issues in the structure, add issues to the structure and remove issues= from the structure. The user cannot, however, create or modify Generators.

Edit Generators The user has full edit access to t= he structure, including modifying generators.

Control

The user can view, edit and configure the str= ucture - including changing structure permission rules and configuring sync= hronizers.

Default Access

By default, all users have None access level.

The structure's owner and JIRA administrators always have Contro= l access level.

Therefore, if you create a new structure and do not specify any permissi= on rules, it will be a private structure that only you and JIRA administrat= ors will be able to see and modify.

Permission Rules

Users who have Control permission on a structure can de= fine permission rules by Editing Structure Details.

Permission rules list is an ordered list that's used to calculate the ac= cess level for a given user. Each rule has a condition tha= t is matched against the user, and access level which is s= et 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 lo= gged in). This condition can be used to set a default permission for everyo= ne.

Group(G)

Matches users that belong to the group G.

=

Project Role(R,P)

Matches users that have role R in project P.<= /p>

Additionally, there is a special rule type Apply Permissions Fro= m, which works by going through the permission rules from a differ= ent structure. You can apply permission rules only from structures with Con= trol access level for you.

Examples

= Edit Issue JIRA Permission and Editing Structure

If you set Require Edit Issue Permission on Parent Issue f= lag on the Structu= re Details page, additional per-issue permissions checks will be p= erformed 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 child= ren issues) are treated as if they are part of the parent issue, and theref= ore adding sub-issues, removing sub-issues and rearranging sub-issues is ac= tually changing the parent issue - for which the Edit Issue permission is r= equired.

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

Note the following:

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 rol= es. The result could be that the changed permissions take effect several mi= nutes later (but only with regards to Structure Permissions). A user can force the cache t= o 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.

------=_Part_16049_634473631.1711718970569--