how to disable self-review

[Hyunil Shin]

hi~

I am using Gerrit v2.8

I created rules.pl as follows. But, when the author reviews +2, it can be submitted.

I really don't know what problem is.

submit_rule(submit(CR, V)) :-

   base(CR, V),

   CR = label(_, ok(Reviewer)),

   gerrit:commit_author(Author),

   Author \= Reviewer,

   !.

submit_rule(submit(CR, V, N)) :-

   base(CR, V),

   N = label('Non-Author-Code-Review', need(_)).

base(CR, V) :-

   gerrit:max_with_block(-2, 2, 'Code-Review', CR),

   gerrit:max_with_block(-1, 1, 'Verified', V).

Thank you.

[Zaro]

I don't think you even need prolog to disable self review.  You can use the change owner permission on a label and just set it to deny.  

https://gerrit-review.googlesource.com/Documentation/access-control.html#change_owner

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Hyunil Shin]

Thank you so much

It is so simple way~~ 

But, Change Owner is supported since Gerrit v2.9. I am using v2.8.

I will tell the Gerrit administrator to upgrade it.

Thank you again.

[Martin Waitz]

Hi,

Am Montag, 15. September 2014 18:14:30 UTC+2 schrieb Khai Do:

I don't think you even need prolog to disable self review.  You can use the change owner permission on a label and just set it to deny.  

It's not that simple, as there is no 'deny' for labels, all the ranges are simply combined.
We'd need a new 'restrict' flag next to the 'exclusive' one for review labels...

--
Martin

[Edwin Kempin]

AFAIK you can BLOCK voting on label ranges, although the UI doesn't support it.

For this you would need to edit the project.config file in the refs/meta/config branch manually.

 

--
Martin

[Martin Waitz]

Am Dienstag, 16. September 2014 09:41:48 UTC+2 schrieb Edwin Kempin:

AFAIK you can BLOCK voting on label ranges, although the UI doesn't support it.

How would you specify this?

Like this?

    label-Code-Review = +2..+2 block group Change Owners

That would be very interesting.
I tried to look this up in the source but could not find where this block is parsed/handled.

[Roy Zeng]

Try below:

 label-Code-Review = +0..+0 block group Change Owners

在 2014年9月17日星期三UTC+8下午3时21分14秒，Martin Waitz写道：

[David Ostrovsky]

It looks like PermissionRule.fromString()  [1] function does what you are looking for

and is called from ProjectConfig.loadPermissionRules().

[1] https://gerrit.googlesource.com/gerrit/+/master/gerrit-common/src/main/java/com/google/gerrit/common/data/PermissionRule.java#199

[Edwin Kempin]

Check the commit message of this change, it has a quite detailed explanation:
  https://gerrit-review.googlesource.com/22061

"
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.
"

--

[Лёша М]

I added "label-Code-Review = block -2..+2 group Change Owner" to All-Projects refs/meta/config and change owner can still change Code Review to -2 and +2.

What's the right way to use it?  Does it actually work?

[Khai Do]

if you are expecting to disable on master branch then you will probably need to set it in the section [access "refs/head/*"] instead of refs/meta/config.   

[Лёша М]

I set it in project.config file that's in refs/meta/config namespace.  It didn't work.  Is there some other place for project.config file where this access block can be specified?

[Bassem Rabil]

There is an open issue [1] against Gerrit 2.9 for inheriting BLOCK permissions from parent projects. I guess you were trying this by setting this up to a parent project or All-Projects. I tried the following in the project itself and it works for me, i.e. 

Here is how project.config looks like:
[access "refs/*"]

label-Code-Review = block -2..+2 group Change Owner

and the groups file should be added to define the group 
# UUID Group Name
#
global:Change-Owner Change Owner

[1] https://code.google.com/p/gerrit/issues/detail?id=2995

Regards

Bassem

[Vladislav Naumov]

Tried that "label-Code-Review = block -2..+2 group Change Owner" thing on All-Projects, it works as intended.
Nobody can +2 his own change in children projects.

Now, is there any way to override this setting for individual projects?
We have, like, 30 projects and we want this rule almost everywhere except some "special" ones.
Docs say BLOCK rules are not overridable, and DENY rules do not work for me for some reason (maybe priority thing? Never figured out how ALLOW/DENY rules play together, docs are sparse).

Maybe it would be better to try submit rules?
How are those inherited, can they be overriden?

[Edwin Kempin]

On Fri, Apr 15, 2016 at 8:48 AM, Vladislav Naumov <vladisla...@gmail.com> wrote:

Tried that "label-Code-Review = block -2..+2 group Change Owner" thing on All-Projects, it works as intended.
Nobody can +2 his own change in children projects.

Now, is there any way to override this setting for individual projects?

The purpose of a block rule is that it is final and cannot be overwritten.

So no, you cannot override a block rule.

 

We have, like, 30 projects and we want this rule almost everywhere except some "special" ones.

At best don't set the block rule on the All-Projects root project, but have a Default-Settings project below it where you set this rule. Then all projects, except those 30 projects, would inherit from the Default-Settings project, while the 30 projects can inherit from the All-Projects project. 

 

Docs say BLOCK rules are not overridable, and DENY rules do not work for me for some reason (maybe priority thing? Never figured out how ALLOW/DENY rules play together, docs are sparse).

Deny would be the thing to use. It denies the access rights, but child projects can override it.

If Deny is not working this might be a bug.

 

Maybe it would be better to try submit rules?
How are those inherited, can they be overriden?

--

[Vladislav Naumov]

> Then all projects, except those 30 projects, would inherit from the Default-Settings project, while the 30 projects can inherit from the All-Projects project.

Nice trick!
Thanks for the tip!

> Deny would be the thing to use. It denies the access rights, but child projects can override it.
> If Deny is not working this might be a bug.

Yes, it might be that - or my misunderstanding of how ACLs are executed.

This is what I tried to do (and it worked with BLOCK):
[access "refs/*"]
label-Code-Review = deny -2..+2 group Change Owner

[access "refs/heads/*"]
label-Code-Review = -2..+2 group Project Owners

All project developers are in Project Owners group.

[Vladislav Naumov]

> Then all projects, except those 30 projects, would inherit from the Default-Settings project, while the 30 projects can inherit from the All-Projects project.

Nice trick!
Thanks for the tip!

> Deny would be the thing to use. It denies the access rights, but child projects can override it.
> If Deny is not working this might be a bug.

[Björn Pedersen]

Hi,

Shawn had a nice presentation on how  gerrit access controls and inheritance work at the 2012 user meeting.
In this case refs/heads is more specific, so it wins...

Björn

[Jungho Ahn]

I have a same issue. 'deny' doesn't work, although 'block' seems to work.

Did I miss something?

 

[David Ostrovsky]

On Tuesday, September 16, 2014 at 9:41:48 AM UTC+2, Edwin Kempin wrote:

2014-09-16 9:35 GMT+02:00 Martin Waitz <martin...@gmail.com>:

Hi,

Am Montag, 15. September 2014 18:14:30 UTC+2 schrieb Khai Do:

I don't think you even need prolog to disable self review.  You can use the change owner permission on a label and just set it to deny.  

It's not that simple, as there is no 'deny' for labels, all the ranges are simply combined.
We'd need a new 'restrict' flag next to the 'exclusive' one for review labels...

AFAIK you can BLOCK voting on label ranges, although the UI doesn't support it.

Now it does: [1].

[1] https://gerrit-review.googlesource.com/108395

[Sorin Ionuț Sbârnea]

Can someone tell me what is the magic syntax to use to deny self reviews? 

I tried the lines below on gerrithub.io but go this error: project.config: group "Change Owner" not in groups.

[access "refs/*"]

label-Code-Review = deny -2..+2 group Change Owner

What is the working solution for this?

[Gert van Dijk]

Are you by chance editing the project.config file yourself (not from the UI)? If so, you're probably introducing this "Change Owner" group to the project and it's not referenced in the groups file (for that project). Try again from the UI and it should just automatically update the groups file for you.

[Matthias Sohn]

you can implement this using a prolog rule given in [1]

[1] https://gerrit-review.googlesource.com/Documentation/prolog-cookbook.html#NonAuthorCodeReview

-Matthias

[Sorin Ionuț Sbârnea]

You are right, I figured out this few minutes ago. This means that the process for implementing this is quite intuitive.

If using edit approach the user is expected to also add a group file when it must define the Change Owner group

Also the change is tricky because by default new repositories are managed only by the person that did the import from github.

This means that if you are not careful you may lock yourself out because you would be the only person able to +2 but gerrit will forbid your your from doing +2 on your own change.

Due to this, I would advise anyone trying to play with the settings to give full access to their github organization groups (or subgroup like github/org/Owners) and to be sure that they have access to at least two accounts, so they do not endup locked.

Now I only have to start playing with ACL inheritance and maybe to also write a small blog post about to do this. For such a simple task the cookbooks seems quite complex.

PS. I wonder if there is a way to require 2x +2 votes before being allowed to submit.

Thanks

Sorin

--

--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---

You received this message because you are subscribed to a topic in the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/repo-discuss/_TVvO1uP-R8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to repo-discuss...@googlegroups.com.

[Sorin Ionuț Sbârnea]

While I was able to forbid self-reviews on a specific gerrithub.io repository, it seems that I am unable to change the parent project in in order to re-use permissions defined on a reference project (named acl in my case).

Change contains a project configuratiChange contains a project configuration that changes the parent project.

The change must be submitted by a Gerrit administrator.on that changes the parent project.

The change must be submitted by a Gerrit administrator.

What I tried to do was to configure "rhos-infra/cloud-config" ACL to use "rhos-infra/acl" project.

Somehow the error seems really weird because I really doubt gerrithub.io admins do have time to perform manual ACL management :D

PS. You can see the change that fails a https://review.gerrithub.io/#/c/387580/

So what is the process I need to follow to assure that we use only one gerrit project for ACL management?

[Igor]

Hi,

Is it possible to use DENY in label permissions to restrict self-review?

When I add the following access configuration I don't see any changes in permissions:

    [access "refs/heads/*"]

      label-Code-Review = deny -2..+2 group Change Owner

Thanks,

Igor.