Message-ID: <91046372.16014.1711715183139.JavaMail.appbox@confluence> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_16013_1987615425.1711715183139" ------=_Part_16013_1987615425.1711715183139 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 defines wh= o is allowed to see, edit or configure the structure.

=20
Access Levels
=20

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

=20
=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20

None

The user does not see the structure at all a= nd does not know that it exists.

View

The user can view the structure but cannot m= ake changes.

Edit

The user can view the structure and can rear= range issues in the structure, add issues to the structure and remove issue= s from the structure.

Control

The user can view, edit and configure the st= ructure - including changing structure permission rules and configuring syn= chronizers.

=20
Default Access
=20

By default, all users have None access level.

=20

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

=20

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.

=20
Permission Rules
=20

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

=20

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.

=20

The following conditions are supported by permission rules:

=20
=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 = =20 =20 =20

Anyone

Matches any user, including anonymous (not l= ogged in). This condition can be used to set a default permission for every= one.

Group(G)

Matches users that belong to the group G.

Project Role(R,P)

Matches users that have role R in project P.=

=20

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.

=20
Examples
=20 =20
= Edit Issue JIRA Permission and Editing Structure
=20

If you set Require Edit Issue Permission on Parent Issue f= lag on the =EF=BB=BFS= tructure Details page, additional per-issue permissions checks wil= l be performed to decide whether the user is allowed to change the structur= e.

=20

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.

=20

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

=20

Note the following:

=20 =20
Permissions Caching
= Structure plugin maintains a cache of users permissions with regards to ea= ch structure. In most cases, the cache is recalculated automatically, but i= n 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 minu= tes later (but only with regards to=20 Structure Permissio= ns). A user can force the cache to be recalculated by doing=20 hard refresh from the browser. Typically, it's done by hol= ding=20 Ctrl or=20 Shift or both and clicking the=20 Refresh button.
------=_Part_16013_1987615425.1711715183139--