Introduced a new PermissionRule.Action: BLOCK.
Besides already existing ALLOW and DENY actions this change introduces
the BLOCK action in order to enable blocking some permission rules
globally.
A typical use case, and the main motivation for this change, is to
globally block update and deletion of tags. When tags are used to tag
releases it is important to ensure that tags are never updated or
deleted.
When looking to see if we can perform a given permission in RefControl
/ ProjectControl, we look to see if any of the parents has defined a
section matching this reference with BLOCK for the permission's
action. If so, we are forbidden from using the permission, even if
there is an ALLOW. This searching for BLOCK ignores the Exclusive flag
that is normally applied to sections.
A BLOCK-ing push rule blocks any type of push, force or not. A
BLOCK-ing force push rule blocks only force pushes, but allows
non-forced pushes if an ALLOW rule would have permitted it.
Site administrators that need to deny tag updates can thus put into
their All-Projects.git:
[access "refs/tags/*"]
push = block group Anonymous Users
It is also possible to block label ranges. To block a group X from
voting -2 and +2, but keep their existing voting permissions for the
-1..+1 range intact we would define:
[access "refs/heads/*"]
label-Code-Review = block -2..+2 group X
The interpretation of the min..max range in case of a blocking rule
is: block every vote from -INFINITE..min and max..INFINITE. This is the
only interpretation of the min..max range for a blocking rule that makes
sense for practical purposes IMO.
NOTE: Gerrit UI is still not able to produce a blocking label range rule.
The UI needs to be extended for that. This will be done in a follow up
change.
Change-Id: I8baeff2a49280fde05b2112df99322b87ce5d442
6 files changed