documentation: Update access control for new ref syntaxes

We now support ${username} variables and regular expressions,
so try to document their use a bit.

Change-Id: I3c42fd59b00094eee745de827055794823021618
Signed-off-by: Shawn O. Pearce <sop@google.com>
This commit is contained in:
Shawn O. Pearce 2010-07-15 11:42:34 -07:00
parent f14ada51fa
commit 6d6d451ce6

View File

@ -135,10 +135,22 @@ Reference-level access control is also possible.
Permissions can be set on a single reference name to match one Permissions can be set on a single reference name to match one
branch (e.g. `refs/heads/master`), or on a reference namespace branch (e.g. `refs/heads/master`), or on a reference namespace
(e.g. `refs/heads/*`) to match any branch starting with that (e.g. `refs/heads/\*`) to match any branch starting with that
prefix. So a permission with `refs/heads/*` will match prefix. So a permission with `refs/heads/\*` will match
`refs/heads/master` and `refs/heads/experimental`, etc. `refs/heads/master` and `refs/heads/experimental`, etc.
Reference names can also be described with a regular expression
by prefixing the reference name with `\^`. For example
`\^refs/heads/[a-z]\{1,8\}` matches all lower case branch names
between 1 and 8 characters long. Within a regular expression `.`
is a wildcard matching any character, but may be escaped as `\.`.
References can have the current user name automatically included,
creating dynamic access controls that change to match the currently
logged in user. For example to provide a personal sandbox space
to all developers, `refs/heads/sandbox/$\{username\}/*` allowing
the user 'joe' to use 'refs/heads/sandbox/joe/foo'.
When evaluating a reference-level access right, Gerrit will use When evaluating a reference-level access right, Gerrit will use
the full set of access rights to determine if the user the full set of access rights to determine if the user
is allowed to perform a given action. For example, if a user is a is allowed to perform a given action. For example, if a user is a