Access control documentation: Read and Submit
Fine tuning the Read category, now that it's been stripped of all it's legacy surplus features and is a pure read permission. Also purging any old links to it that really should be push / push merge now. Submit category has it's link changed. Change-Id: I3fc7a181bb542cc647adb76df9a772f1fcfa6773 Signed-off-by: Fredrik Luthander <fredrik.luthander@sonyericsson.com>
This commit is contained in:
Fredrik Luthander
Gustaf Lundh
parent
5b75c00625
commit
5d976a0d86
@ -56,7 +56,7 @@ Any access rights assigned to this group are inherited by all users.
|
||||
Administrators and project owners can grant access rights to this
|
||||
group in order to permit anonymous users to view project changes,
|
||||
without requiring sign in first. Currently it is only worthwhile
|
||||
to grant `Read Access` to this group as Gerrit requires an account
|
||||
to grant `Read` access to this group as Gerrit requires an account
|
||||
identity for all other operations.
|
||||
|
||||
[[non-interactive_users]]
|
||||
@ -109,7 +109,7 @@ allowing signed-in users to vote on a change, but not actually
|
||||
cause it to become approved or rejected.
|
||||
|
||||
Registered users are always permitted to make and publish comments
|
||||
on any change in any project they have `Read Access` to.
|
||||
on any change in any project they have `Read` access to.
|
||||
|
||||
|
||||
Account Groups
|
||||
@ -287,9 +287,8 @@ Per-Project
|
||||
|
||||
The per-project ACL is evaluated before the global `All-Projects` ACL,
|
||||
permitting some limited override capability to project owners. This
|
||||
behavior is generally only useful on the `Read Access` category when
|
||||
granting `-1 No Access` within a specific project to deny access to
|
||||
a group.
|
||||
behavior is generally only useful on the `Read` category when
|
||||
granting 'DENY' within a specific project to deny a group access.
|
||||
|
||||
|
||||
[[access_category]]
|
||||
@ -676,38 +675,40 @@ To delete or overwrite an existing tag, grant `Push` with the force
|
||||
option enabled for reference name `refs/tags/*`, as deleting a tag
|
||||
requires the same permission as deleting a branch.
|
||||
|
||||
[[category_READ]]
|
||||
Read Access
|
||||
~~~~~~~~~~~
|
||||
|
||||
The `Read Access` category controls visibility to the project's
|
||||
[[category_read]]
|
||||
Read
|
||||
~~~~
|
||||
|
||||
The `Read` category controls visibility to the project's
|
||||
changes, comments, code diffs, and Git access over SSH or HTTP.
|
||||
A user must have `Read Access +1` in order to see a project, its
|
||||
A user must have this access granted in order to see a project, its
|
||||
changes, or any of its data.
|
||||
|
||||
This category has a special behavior, where the per-project ACL is
|
||||
evaluated before the global all projects ACL. If the per-project
|
||||
ACL has granted `Read Access -1`, and does not otherwise grant
|
||||
`Read Access \+1`, then a `Read Access +1` in the all projects ACL
|
||||
ACL has granted `Read` with 'DENY', and does not otherwise grant
|
||||
`Read` with 'ALLOW', then a `Read` in the all projects ACL
|
||||
is ignored. This behavior is useful to hide a handful of projects
|
||||
on an otherwise public server.
|
||||
|
||||
For an open source, public Gerrit installation it is common to grant
|
||||
`Read Access +1` to `Anonymous Users` in the `\-- All Projects
|
||||
\--` ACL, enabling casual browsing of any project's changes,
|
||||
as well as fetching any project's repository over SSH or HTTP.
|
||||
New projects can be temporarily hidden from public view by granting
|
||||
`Read Access -1` to `Anonymous Users` and granting `Read Access +1`
|
||||
to the project owner's group within the per-project ACL.
|
||||
`Read` to `Anonymous Users` in the `All-Projects` ACL, enabling
|
||||
casual browsing of any project's changes, as well as fetching any
|
||||
project's repository over SSH or HTTP. New projects can be
|
||||
temporarily hidden from public view by granting `Read` with 'DENY'
|
||||
to `Anonymous Users` and granting `Read` to the project owner's
|
||||
group within the per-project ACL.
|
||||
|
||||
For a private Gerrit installation using a trusted HTTP authentication
|
||||
source, granting `Read Access +1` to `Registered Users` may be more
|
||||
source, granting `Read` to `Registered Users` may be more
|
||||
typical, enabling read access only to those users who have been
|
||||
able to authenticate through the HTTP access controls. This may
|
||||
be suitable in a corporate deployment if the HTTP access control
|
||||
is already restricted to the correct set of users.
|
||||
|
||||
[[category_SUBM]]
|
||||
|
||||
[[category_submit]]
|
||||
Submit
|
||||
~~~~~~
|
||||
|
||||
|
||||
@ -16,10 +16,11 @@ If you are facing this problem, do the following:
|
||||
. Verify that you are pushing to the correct Gerrit server.
|
||||
. Go in the Gerrit WebUI to 'Admin' -> 'Projects' and check that the
|
||||
project is listed. If the project is not listed the project either
|
||||
does not exist or you don't have read access ('+1 Read Access' in
|
||||
the link:access-control.html#category_READ['Read Access'] category) for it. This means if you certain that
|
||||
the project name is right you should contact the Gerrit
|
||||
Administrator or project owner to request access to the project.
|
||||
does not exist or you don't have
|
||||
link:access-control.html#category_read['Read'] access for it. This
|
||||
means if you certain that the project name is right you should
|
||||
contact the Gerrit Administrator or project owner to request access
|
||||
to the project.
|
||||
|
||||
This error message might be misleading if the project actually exists
|
||||
but the push is failing because the pushing user has no read access
|
||||
|
||||
@ -6,13 +6,15 @@ pushing user has no permissions to upload merge commits for the
|
||||
project to which the push is done.
|
||||
|
||||
If you need to upload merge commits, you can contact one of the
|
||||
project owners and request for this project permissions to upload
|
||||
merge commits (access right '+3 Upload merges permission' in the
|
||||
link:access-control.html#category_READ['Read Access'] category).
|
||||
project owners and request permissions to upload merge commits
|
||||
(access right link:access-control.html#category_push['Push'] and
|
||||
link:access-control.html#category_push_merge['Push merge']) for this
|
||||
project.
|
||||
|
||||
If one of your changes could not be merged in Gerrit due to conflicts
|
||||
and you created the merge commit to resolve the conflicts, you might
|
||||
want to revert the merge and instead of this do a link:http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html[rebase].
|
||||
want to revert the merge and instead of this do a
|
||||
link:http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html[rebase].
|
||||
|
||||
|
||||
GERRIT
|
||||
|
||||
@ -8,8 +8,8 @@ push was done.
|
||||
There are two possibilities how to continue in this situation:
|
||||
|
||||
. contact one of the project owners and request upload permissions
|
||||
for the project (access right '+2 Upload permission' in the
|
||||
link:access-control.html#category_READ['Read Access'] category)
|
||||
for the project (access right
|
||||
link:access-control.html#category_push['Push'])
|
||||
. export your commit as a patch using the link:http://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html[git format-patch] command
|
||||
and provide the patch file to one of the project owners
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user