Issue 308: Allow forbid of self +1 reviews
Status:  Released
Owner: ----
Closed:  Oct 2012
Cc:

Blocked on:
issue 112
issue 288
Reported by dav...@codeaurora.org, Oct 22, 2009
It would be nice to be able to configure Gerrit to forbid self +1 reviews.
Perhaps this could be done such that only people with +2 approval
permission could give themselves a +1 on a review.

We occasionally see code submissions where the author gives themselves a
positive review, and the approver has to notice and then ignore this
review.

Oct 22, 2009
#1 nas...@chromium.org
(No comment was entered for this change.)
Summary: Allow forbid of self +1 reviews
Cc: nas...@codeaurora.org
Oct 29, 2009
#2 sop+code@google.com
This is related to  issue 112  where we want to ensure verifier != code reviewer, or 
that neither is author, depending on site/project approval rules.
Status: Accepted
Blockedon: 112
Nov 4, 2009
#3 jbq+legacy@google.com
On the other hand I routinely give "myself" +1 or even +2 in situations where I'm the
owner (but not the author) or a change, i.e. in cases where I've created a commit on
behalf of someone else and review that other person's change.
Nov 4, 2009
#4 sop+code@google.com
I also tend to self-grant +1/+2 often.

Really this needs to be:

- per project.  Not every project wants to forbid self reviews.

- per review level.  Some projects might allow self Verified +1 but not Code Review.

- allow owners to bypass forbid.  Some projects might want to allow owners to self 
approve no matter what.

- forbid owners to self approve.  Some projects might want an owner to get approval 
from at least one other before submitting (so counter to the rule above).

There's a reason why we haven't implemented this yet, everyone wants a different 
function here.
Jan 25, 2010
#5 di...@google.com
For what's worth we need something similar but in our case to not allow either +1 nor +2 when the reviewer 
matches the author (as jbq says the committer is not important). At least that's our use case.
Jan 25, 2010
#6 di...@google.com
Actually since the Author can be filled in (spoofed) and the committer is the only piece of information trusted 
(assuming we trust Gerrit which I think it's the one generating the committer header) then if this feature is 
implemented it should be possible to restrict it when committers match reviewers too not only authors.
Jan 25, 2010
#7 sop@google.com
Author can be spoofed by the client.  There is no verification of it.

Committer is supplied by the client, but Gerrit Code Review enforces
that the email address listed as the committer matches one of the
verified email addresses for the user who is uploading the commit.
Any attempt to spoof the committer email is rejected with an error.

Therefore, we can match committer to an account, and use that to
block a "self approval".
Jan 30, 2010
#8 sop@google.com
(No comment was entered for this change.)
Labels: Milestone-2.1.3
Jun 15, 2010
#9 sop@google.com
(No comment was entered for this change.)
Labels: -Milestone-2.1.3
Jun 15, 2010
#10 sop@google.com
This should be based on the other approval rules stuff
that  issue 288  hopes to provide.
Blockedon: 288
Oct 13, 2011
#11 haohui....@gmail.com
Someone could always self verify their patches and merge directly to the mainline.
Nov 10, 2011
Project Member #12 bklarson@gmail.com
 Issue 1178  has been merged into this issue.
Mar 29, 2012
#13 amu...@wikimedia.org
We should just be forbidden to +1 our own patchset. We should still be able to +1 a patchsets submitted by other people on a change we own.
Apr 23, 2012
Project Member #14 bklarson@gmail.com
I think this is now possible with the prolog engine?  If so, maybe we just need to document how and then close this issue?
Cc: sop@google.com
Oct 24, 2012
#15 JBjo...@gmail.com
This is done and properly documented in the prolog-cookbook (example 8)

Oct 24, 2012
Project Member #16 bklarson@gmail.com
(No comment was entered for this change.)
Status: Released
Labels: FixedIn-2.5