| Issue 308: | Allow forbid of self +1 reviews | |
| 56 people starred this issue and may be notified of changes. | Back to list |
Sign in to add a comment
|
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 29, 2009
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
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
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
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
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
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
(No comment was entered for this change.)
Labels:
Milestone-2.1.3
Jun 15, 2010
(No comment was entered for this change.)
Labels:
-Milestone-2.1.3
Jun 15, 2010
This should be based on the other approval rules stuff that issue 288 hopes to provide.
Blockedon:
288
Oct 13, 2011
Someone could always self verify their patches and merge directly to the mainline.
Nov 10, 2011
Issue 1178 has been merged into this issue.
Mar 29, 2012
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
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
This is done and properly documented in the prolog-cookbook (example 8)
Oct 24, 2012
(No comment was entered for this change.)
Status:
Released
Labels: FixedIn-2.5 |
||||||||||
| ► Sign in to add a comment | |||||||||||
Cc: nas...@codeaurora.org