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
Every structure has a list of permission rules, which defines wh= o is allowed to see, edit or configure the structure.
=20Each user has one of the following access levels to a structure:
=20None | =20
The user does not see the structure at all a= nd does not know that it exists. | =20
View | =20
The user can view the structure but cannot m= ake changes. | =20
Edit | =20
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. | =20
Control | =20
The user can view, edit and configure the st= ructure - including changing structure permission rules and configuring syn= chronizers. | =20
By default, all users have None access level.
=20The structure's owner and JIRA administrators always have Contro= l access level.
=20Therefore, 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.
=20Users who have Control permission on a structure can de= fine permission rules by =EF=BB=BFEditing Structure Details.
=20Permission 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.
=20The following conditions are supported by permission rules:
=20Anyone | =20
Matches any user, including anonymous (not l= ogged in). This condition can be used to set a default permission for every= one. | =20
Group(G) | =20
Matches users that belong to the group G. = p> | =20
Project Role(R,P) | =
=20
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 1. View for Anyone | =20
1. Edit for jira-users (Group) | =20
1. Control for jira-developers (Group) | =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.
=20If 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.
=20The user must also have Edit access level to the struct= ure to be able to make changes at all.
Note the following:
=20