opendev/gerrit
Code Issues Proposed changes

Access control documentation: Final cleanup

Browse Source 
* Removing the disclaimer for outdated documentation.
* Add links between different sections, where referred.
* Fixed examples where Exclusive flag isn't a prefixing '-' on branch
references anymore, but instead it's own tick box.
* Removes mention of previously reserved words in the category_id
table.

Change-Id: Ifccd40c8fe12c570618701c36aa3d1c0ab1705d4
Signed-off-by: Fredrik Luthander <fredrik.luthander@sonyericsson.com>
This commit is contained in:
Fredrik Luthander
2012-01-20 16:18:41 +01:00
committed by Gustaf Lundh
parent 5d976a0d86
commit 2b3cd55297
1 changed files with 28 additions and 41 deletions
Download Patch File Download Diff File Expand all files Collapse all files

69
Documentation/access-control.txt
View File

@@ -1,17 +1,6 @@
Gerrit Code Review - Access Controls Gerrit Code Review - Access Controls
==================================== ====================================
.Disclaimer
****
This documentation is outdated.
In Gerrit 2.2.x the way how the access rights are configured has
changed, but this documentation was not updated yet.
This documentation still describes the access rights configuration as
it was in Gerrit 2.1.8 and before.
****
Access controls in Gerrit are group based. Every user account is a Access controls in Gerrit are group based. Every user account is a
member of one or more groups, and access and privileges are granted member of one or more groups, and access and privileges are granted
to those groups. Access rights cannot be granted to individual to those groups. Access rights cannot be granted to individual
@@ -96,7 +85,7 @@ Registered Users
~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~
All signed-in users are automatically a member of this group (and All signed-in users are automatically a member of this group (and
also 'Anonymous Users', see above). also <<anonymous_users,'Anonymous Users'>>, see above).
Any access rights assigned to this group are inherited by all Any access rights assigned to this group are inherited by all
users as soon as they sign-in to Gerrit. If OpenID authentication users as soon as they sign-in to Gerrit. If OpenID authentication
@@ -205,12 +194,12 @@ the `refs/heads/qa` branch, and the following ACLs are granted
on the project: on the project:
[options="header"] [options="header"]
|===================================================== |===============================================================
|Group |Reference Name|Category |Range |Group |Reference Name|Category |Range |Exclusive
|Registered Users |refs/heads/* |Code Review| -1..+1 |Registered Users |refs/heads/* |Code Review| -1..+1 |
|Foo Leads |refs/heads/* |Code Review| -2..+2 |Foo Leads |refs/heads/* |Code Review| -2..+2 |
|QA Leads |refs/heads/qa |Code Review| -2..+2 |QA Leads |refs/heads/qa |Code Review| -2..+2 |
|===================================================== |===============================================================
Then the effective range permitted to be used by the user is Then the effective range permitted to be used by the user is
`-2..+2`, as the user's membership of `Foo Leads` effectively grant `-2..+2`, as the user's membership of `Foo Leads` effectively grant
@@ -220,20 +209,21 @@ Gerrit also supports exclusive reference-level access control.
It is possible to configure Gerrit to grant an exclusive ref level It is possible to configure Gerrit to grant an exclusive ref level
access control so that only users of a specific group can perform access control so that only users of a specific group can perform
an operation on a project/reference pair. This is done by prefixing an operation on a project/reference pair. This is done by ticking
the reference specified with a `'-'`. the exclusive flag when setting the permission for the
`refs/heads/qa` branch.
For example, if a user who is a member of `Foo Leads` tries to For example, if a user who is a member of `Foo Leads` tries to
review a change destined for branch `refs/heads/qa` in a project, review a change destined for branch `refs/heads/qa` in a project,
and the following ACLs are granted: and the following ACLs are granted:
[options="header"] [options="header"]
|===================================================== |==============================================================
|Group |Reference Name|Category |Range |Group |Reference Name|Category |Range |Exclusive
|Registered Users|refs/heads/* |Code Review| -1..+1 |Registered Users|refs/heads/* |Code Review| -1..+1 |
|Foo Leads |refs/heads/* |Code Review| -2..+2 |Foo Leads |refs/heads/* |Code Review| -2..+2 |
|QA Leads |-refs/heads/qa|Code Review| -2..+2 |QA Leads |refs/heads/qa |Code Review| -2..+2 |X
|===================================================== |==============================================================
Then this user will not have `Code Review` rights on that change, Then this user will not have `Code Review` rights on that change,
since there is an exclusive access right in place for the since there is an exclusive access right in place for the
@@ -246,13 +236,13 @@ In order to grant the ability to `Code Review` to the members of
would be needed: would be needed:
[options="header"] [options="header"]
|===================================================== |==============================================================
|Group |Reference Name|Category |Range |Group |Reference Name|Category |Range |Exclusive
|Registered Users|refs/heads/* |Code Review| -1..+1 |Registered Users|refs/heads/* |Code Review| -1..+1 |
|Foo Leads |refs/heads/* |Code Review| -2..+2 |Foo Leads |refs/heads/* |Code Review| -2..+2 |
|QA Leads |-refs/heads/qa|Code Review| -2..+2 |QA Leads |refs/heads/qa |Code Review| -2..+2 |X
|Foo Leads |refs/heads/qa |Code Review| -2..+2 |Foo Leads |refs/heads/qa |Code Review| -2..+2 |
|===================================================== |==============================================================
OpenID Authentication OpenID Authentication
~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~
@@ -489,7 +479,6 @@ you grant the users the push force permission to be able to clean up
stale branches. stale branches.
[[category_forge_author]] [[category_forge_author]]
Forge Author Forge Author
~~~~~~~~~~~~ ~~~~~~~~~~~~
@@ -729,17 +718,15 @@ Your Category Here
Gerrit administrators can also make up their own categories. Gerrit administrators can also make up their own categories.
See above for descriptions of how `Verified` and `Code Review` work, See above for descriptions of how <<category_verified,`Verified`>>
and insert your own category with `function_name = 'MaxWithBlock'` and <<category_review,`Code Review`>> work, and insert your own
to get the same behavior over your own range of values, in any category with `function_name = 'MaxWithBlock'` to get the same
category you desire. behavior over your own range of values, in any category you desire.
Ensure `category_id` is unique within your `approval_categories` Ensure `category_id` is unique within your `approval_categories`
table. The default values `VRIF` and `CVRF` used for the categories table. The default values `VRIF` and `CVRF` used for the categories
described above are simply that, defaults, and have no special described above are simply that, defaults, and have no special
meaning to Gerrit. The other standard category_id values like meaning to Gerrit.
`OWN`, `READ`, `SUBM`, `pTAG` and `pHD` have special meaning and
should not be modified or reused.
The `position` column of `approval_categories` controls which column The `position` column of `approval_categories` controls which column
of the 'Approvals' table the category appears in, providing some of the 'Approvals' table the category appears in, providing some