2016-12-29 10:35:47 -08:00
|
|
|
<?php
|
|
|
|
|
|
|
|
final class DifferentialRevisionAcceptTransaction
|
2016-12-29 13:14:09 -08:00
|
|
|
extends DifferentialRevisionReviewTransaction {
|
2016-12-29 10:35:47 -08:00
|
|
|
|
|
|
|
const TRANSACTIONTYPE = 'differential.revision.accept';
|
|
|
|
const ACTIONKEY = 'accept';
|
|
|
|
|
|
|
|
protected function getRevisionActionLabel() {
|
2018-04-25 06:17:17 -07:00
|
|
|
return pht('Accept Revision');
|
2016-12-29 10:35:47 -08:00
|
|
|
}
|
|
|
|
|
2017-09-18 14:14:52 -07:00
|
|
|
protected function getRevisionActionDescription(
|
|
|
|
DifferentialRevision $revision) {
|
2016-12-29 10:35:47 -08:00
|
|
|
return pht('These changes will be approved.');
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getIcon() {
|
|
|
|
return 'fa-check-circle-o';
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getColor() {
|
|
|
|
return 'green';
|
|
|
|
}
|
|
|
|
|
Order actions sensibly within Differential revision comment action groups
Summary:
Ref T11114. See D17114 for some discussion.
For review actions: accept, reject, resign.
For revision actions, order is basically least-severe to most-severe action pairs: plan changes, request review, close, reopen, abandon, reclaim, commandeer.
Test Plan: Viewed revisions as an author and a reviewer, saw sensible action order within action groups.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11114
Differential Revision: https://secure.phabricator.com/D17115
2016-12-29 13:36:36 -08:00
|
|
|
protected function getRevisionActionOrder() {
|
|
|
|
return 500;
|
|
|
|
}
|
|
|
|
|
2017-01-12 07:40:48 -08:00
|
|
|
public function getActionName() {
|
|
|
|
return pht('Accepted');
|
|
|
|
}
|
|
|
|
|
2017-01-02 11:36:02 -08:00
|
|
|
public function getCommandKeyword() {
|
|
|
|
$accept_key = 'differential.enable-email-accept';
|
|
|
|
$allow_email_accept = PhabricatorEnv::getEnvConfig($accept_key);
|
|
|
|
if (!$allow_email_accept) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 'accept';
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getCommandAliases() {
|
|
|
|
return array();
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getCommandSummary() {
|
|
|
|
return pht('Accept a revision.');
|
|
|
|
}
|
|
|
|
|
When accepting revisions, allow users to accept on behalf of a subset of reviewers
Summary:
Ref T12271. Currenty, when you "Accept" a revision, you always accept it for all reviewers you have authority over.
There are some situations where communication can be more clear if users can accept as only themselves, or for only some packages, etc. T12271 discusses some of these use cases in more depth.
Instead of making "Accept" a blanket action, default it to doing what it does now but let the user uncheck reviewers.
In cases where project/package reviewers aren't in use, this doesn't change anything.
For now, "reject" still acts the old way (reject everything). We could make that use checkboxes too, but I'm not sure there's as much of a use case for it, and I generally want users who are blocking stuff to have more direct accountability in a product sense.
Test Plan:
- Accepted normally.
- Accepted a subset.
- Tried to accept none.
- Tried to accept bogus reviewers.
- Accepted with myself not a reviewer
- Accepted with only one reviewer (just got normal "this will be accepted" text).
{F4251255}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12271
Differential Revision: https://secure.phabricator.com/D17533
2017-03-22 09:28:36 -07:00
|
|
|
protected function getActionOptions(
|
|
|
|
PhabricatorUser $viewer,
|
Don't consider accepting on behalf of valid-but-accepted reviewers to be a validation error
Summary:
Fixes T12757. Here's a simple repro for this:
- Add a package you own as a reviewer to a revision you're reviewing.
- Open two windows, select "Accept", don't submit the form.
- Submit the form in window A.
- Submit the fomr in window B.
Previously, window B would show an error, because we considered accepting on behalf of the package invalid, as the package had already accepted.
Instead, let repeat-accepts through without complaint.
Some product stuff:
- We could roadblock users with a more narrow validation error message here instead, like "Package X has already been accepted.", but I think this would be more annoying than helpful.
- If your accept has no effect (i.e., everything you're accepting for has already accepted) we currently just let it through. I think this is fine -- and a bit tricky to tailor -- but the ideal/consistent beavior is to do a "no effect" warning like "All the reviewers you're accepting for have already accepted.". This is sufficiently finnicky/rare (and probably not terribly useful/desiable in this specific case)that I'm just punting.
Test Plan: Did the flow above, got an "Accept" instead of a validation error.
Reviewers: chad, lvital
Reviewed By: chad, lvital
Subscribers: lvital
Maniphest Tasks: T12757
Differential Revision: https://secure.phabricator.com/D18019
2017-05-25 13:19:30 -07:00
|
|
|
DifferentialRevision $revision,
|
|
|
|
$include_accepted = false) {
|
When accepting revisions, allow users to accept on behalf of a subset of reviewers
Summary:
Ref T12271. Currenty, when you "Accept" a revision, you always accept it for all reviewers you have authority over.
There are some situations where communication can be more clear if users can accept as only themselves, or for only some packages, etc. T12271 discusses some of these use cases in more depth.
Instead of making "Accept" a blanket action, default it to doing what it does now but let the user uncheck reviewers.
In cases where project/package reviewers aren't in use, this doesn't change anything.
For now, "reject" still acts the old way (reject everything). We could make that use checkboxes too, but I'm not sure there's as much of a use case for it, and I generally want users who are blocking stuff to have more direct accountability in a product sense.
Test Plan:
- Accepted normally.
- Accepted a subset.
- Tried to accept none.
- Tried to accept bogus reviewers.
- Accepted with myself not a reviewer
- Accepted with only one reviewer (just got normal "this will be accepted" text).
{F4251255}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12271
Differential Revision: https://secure.phabricator.com/D17533
2017-03-22 09:28:36 -07:00
|
|
|
|
|
|
|
$reviewers = $revision->getReviewers();
|
|
|
|
|
|
|
|
$options = array();
|
|
|
|
$value = array();
|
|
|
|
|
|
|
|
// Put the viewer's user reviewer first, if it exists, so that "Accept as
|
|
|
|
// yourself" is always at the top.
|
|
|
|
$head = array();
|
|
|
|
$tail = array();
|
|
|
|
foreach ($reviewers as $key => $reviewer) {
|
|
|
|
if ($reviewer->isUser()) {
|
|
|
|
$head[$key] = $reviewer;
|
|
|
|
} else {
|
|
|
|
$tail[$key] = $reviewer;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
$reviewers = $head + $tail;
|
|
|
|
|
|
|
|
$diff_phid = $this->getActiveDiffPHID($revision);
|
|
|
|
$reviewer_phids = array();
|
|
|
|
|
|
|
|
// If the viewer isn't a reviewer, add them to the list of options first.
|
|
|
|
// This happens when you navigate to some revision you aren't involved in:
|
|
|
|
// you can accept and become a reviewer.
|
|
|
|
|
|
|
|
$viewer_phid = $viewer->getPHID();
|
|
|
|
if ($viewer_phid) {
|
|
|
|
if (!isset($reviewers[$viewer_phid])) {
|
|
|
|
$reviewer_phids[$viewer_phid] = $viewer_phid;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-03-28 09:30:58 -07:00
|
|
|
$default_unchecked = array();
|
When accepting revisions, allow users to accept on behalf of a subset of reviewers
Summary:
Ref T12271. Currenty, when you "Accept" a revision, you always accept it for all reviewers you have authority over.
There are some situations where communication can be more clear if users can accept as only themselves, or for only some packages, etc. T12271 discusses some of these use cases in more depth.
Instead of making "Accept" a blanket action, default it to doing what it does now but let the user uncheck reviewers.
In cases where project/package reviewers aren't in use, this doesn't change anything.
For now, "reject" still acts the old way (reject everything). We could make that use checkboxes too, but I'm not sure there's as much of a use case for it, and I generally want users who are blocking stuff to have more direct accountability in a product sense.
Test Plan:
- Accepted normally.
- Accepted a subset.
- Tried to accept none.
- Tried to accept bogus reviewers.
- Accepted with myself not a reviewer
- Accepted with only one reviewer (just got normal "this will be accepted" text).
{F4251255}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12271
Differential Revision: https://secure.phabricator.com/D17533
2017-03-22 09:28:36 -07:00
|
|
|
foreach ($reviewers as $reviewer) {
|
2017-03-28 09:30:58 -07:00
|
|
|
$reviewer_phid = $reviewer->getReviewerPHID();
|
|
|
|
|
When accepting revisions, allow users to accept on behalf of a subset of reviewers
Summary:
Ref T12271. Currenty, when you "Accept" a revision, you always accept it for all reviewers you have authority over.
There are some situations where communication can be more clear if users can accept as only themselves, or for only some packages, etc. T12271 discusses some of these use cases in more depth.
Instead of making "Accept" a blanket action, default it to doing what it does now but let the user uncheck reviewers.
In cases where project/package reviewers aren't in use, this doesn't change anything.
For now, "reject" still acts the old way (reject everything). We could make that use checkboxes too, but I'm not sure there's as much of a use case for it, and I generally want users who are blocking stuff to have more direct accountability in a product sense.
Test Plan:
- Accepted normally.
- Accepted a subset.
- Tried to accept none.
- Tried to accept bogus reviewers.
- Accepted with myself not a reviewer
- Accepted with only one reviewer (just got normal "this will be accepted" text).
{F4251255}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12271
Differential Revision: https://secure.phabricator.com/D17533
2017-03-22 09:28:36 -07:00
|
|
|
if (!$reviewer->hasAuthority($viewer)) {
|
|
|
|
// If the viewer doesn't have authority to act on behalf of a reviewer,
|
2017-03-28 09:30:58 -07:00
|
|
|
// we check if they can accept by force.
|
|
|
|
if ($revision->canReviewerForceAccept($viewer, $reviewer)) {
|
|
|
|
$default_unchecked[$reviewer_phid] = true;
|
|
|
|
} else {
|
|
|
|
continue;
|
|
|
|
}
|
When accepting revisions, allow users to accept on behalf of a subset of reviewers
Summary:
Ref T12271. Currenty, when you "Accept" a revision, you always accept it for all reviewers you have authority over.
There are some situations where communication can be more clear if users can accept as only themselves, or for only some packages, etc. T12271 discusses some of these use cases in more depth.
Instead of making "Accept" a blanket action, default it to doing what it does now but let the user uncheck reviewers.
In cases where project/package reviewers aren't in use, this doesn't change anything.
For now, "reject" still acts the old way (reject everything). We could make that use checkboxes too, but I'm not sure there's as much of a use case for it, and I generally want users who are blocking stuff to have more direct accountability in a product sense.
Test Plan:
- Accepted normally.
- Accepted a subset.
- Tried to accept none.
- Tried to accept bogus reviewers.
- Accepted with myself not a reviewer
- Accepted with only one reviewer (just got normal "this will be accepted" text).
{F4251255}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12271
Differential Revision: https://secure.phabricator.com/D17533
2017-03-22 09:28:36 -07:00
|
|
|
}
|
|
|
|
|
Don't consider accepting on behalf of valid-but-accepted reviewers to be a validation error
Summary:
Fixes T12757. Here's a simple repro for this:
- Add a package you own as a reviewer to a revision you're reviewing.
- Open two windows, select "Accept", don't submit the form.
- Submit the form in window A.
- Submit the fomr in window B.
Previously, window B would show an error, because we considered accepting on behalf of the package invalid, as the package had already accepted.
Instead, let repeat-accepts through without complaint.
Some product stuff:
- We could roadblock users with a more narrow validation error message here instead, like "Package X has already been accepted.", but I think this would be more annoying than helpful.
- If your accept has no effect (i.e., everything you're accepting for has already accepted) we currently just let it through. I think this is fine -- and a bit tricky to tailor -- but the ideal/consistent beavior is to do a "no effect" warning like "All the reviewers you're accepting for have already accepted.". This is sufficiently finnicky/rare (and probably not terribly useful/desiable in this specific case)that I'm just punting.
Test Plan: Did the flow above, got an "Accept" instead of a validation error.
Reviewers: chad, lvital
Reviewed By: chad, lvital
Subscribers: lvital
Maniphest Tasks: T12757
Differential Revision: https://secure.phabricator.com/D18019
2017-05-25 13:19:30 -07:00
|
|
|
if (!$include_accepted) {
|
|
|
|
if ($reviewer->isAccepted($diff_phid)) {
|
|
|
|
// If a reviewer is already in a full "accepted" state, don't
|
|
|
|
// include that reviewer as an option unless we're listing all
|
2017-08-11 09:41:35 -07:00
|
|
|
// reviewers, including reviewers who have already accepted.
|
Don't consider accepting on behalf of valid-but-accepted reviewers to be a validation error
Summary:
Fixes T12757. Here's a simple repro for this:
- Add a package you own as a reviewer to a revision you're reviewing.
- Open two windows, select "Accept", don't submit the form.
- Submit the form in window A.
- Submit the fomr in window B.
Previously, window B would show an error, because we considered accepting on behalf of the package invalid, as the package had already accepted.
Instead, let repeat-accepts through without complaint.
Some product stuff:
- We could roadblock users with a more narrow validation error message here instead, like "Package X has already been accepted.", but I think this would be more annoying than helpful.
- If your accept has no effect (i.e., everything you're accepting for has already accepted) we currently just let it through. I think this is fine -- and a bit tricky to tailor -- but the ideal/consistent beavior is to do a "no effect" warning like "All the reviewers you're accepting for have already accepted.". This is sufficiently finnicky/rare (and probably not terribly useful/desiable in this specific case)that I'm just punting.
Test Plan: Did the flow above, got an "Accept" instead of a validation error.
Reviewers: chad, lvital
Reviewed By: chad, lvital
Subscribers: lvital
Maniphest Tasks: T12757
Differential Revision: https://secure.phabricator.com/D18019
2017-05-25 13:19:30 -07:00
|
|
|
continue;
|
|
|
|
}
|
When accepting revisions, allow users to accept on behalf of a subset of reviewers
Summary:
Ref T12271. Currenty, when you "Accept" a revision, you always accept it for all reviewers you have authority over.
There are some situations where communication can be more clear if users can accept as only themselves, or for only some packages, etc. T12271 discusses some of these use cases in more depth.
Instead of making "Accept" a blanket action, default it to doing what it does now but let the user uncheck reviewers.
In cases where project/package reviewers aren't in use, this doesn't change anything.
For now, "reject" still acts the old way (reject everything). We could make that use checkboxes too, but I'm not sure there's as much of a use case for it, and I generally want users who are blocking stuff to have more direct accountability in a product sense.
Test Plan:
- Accepted normally.
- Accepted a subset.
- Tried to accept none.
- Tried to accept bogus reviewers.
- Accepted with myself not a reviewer
- Accepted with only one reviewer (just got normal "this will be accepted" text).
{F4251255}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12271
Differential Revision: https://secure.phabricator.com/D17533
2017-03-22 09:28:36 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
$reviewer_phids[$reviewer_phid] = $reviewer_phid;
|
|
|
|
}
|
|
|
|
|
|
|
|
$handles = $viewer->loadHandles($reviewer_phids);
|
|
|
|
|
2017-03-28 09:30:58 -07:00
|
|
|
$head = array();
|
|
|
|
$tail = array();
|
When accepting revisions, allow users to accept on behalf of a subset of reviewers
Summary:
Ref T12271. Currenty, when you "Accept" a revision, you always accept it for all reviewers you have authority over.
There are some situations where communication can be more clear if users can accept as only themselves, or for only some packages, etc. T12271 discusses some of these use cases in more depth.
Instead of making "Accept" a blanket action, default it to doing what it does now but let the user uncheck reviewers.
In cases where project/package reviewers aren't in use, this doesn't change anything.
For now, "reject" still acts the old way (reject everything). We could make that use checkboxes too, but I'm not sure there's as much of a use case for it, and I generally want users who are blocking stuff to have more direct accountability in a product sense.
Test Plan:
- Accepted normally.
- Accepted a subset.
- Tried to accept none.
- Tried to accept bogus reviewers.
- Accepted with myself not a reviewer
- Accepted with only one reviewer (just got normal "this will be accepted" text).
{F4251255}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12271
Differential Revision: https://secure.phabricator.com/D17533
2017-03-22 09:28:36 -07:00
|
|
|
foreach ($reviewer_phids as $reviewer_phid) {
|
2017-03-28 09:30:58 -07:00
|
|
|
$is_force = isset($default_unchecked[$reviewer_phid]);
|
When accepting revisions, allow users to accept on behalf of a subset of reviewers
Summary:
Ref T12271. Currenty, when you "Accept" a revision, you always accept it for all reviewers you have authority over.
There are some situations where communication can be more clear if users can accept as only themselves, or for only some packages, etc. T12271 discusses some of these use cases in more depth.
Instead of making "Accept" a blanket action, default it to doing what it does now but let the user uncheck reviewers.
In cases where project/package reviewers aren't in use, this doesn't change anything.
For now, "reject" still acts the old way (reject everything). We could make that use checkboxes too, but I'm not sure there's as much of a use case for it, and I generally want users who are blocking stuff to have more direct accountability in a product sense.
Test Plan:
- Accepted normally.
- Accepted a subset.
- Tried to accept none.
- Tried to accept bogus reviewers.
- Accepted with myself not a reviewer
- Accepted with only one reviewer (just got normal "this will be accepted" text).
{F4251255}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12271
Differential Revision: https://secure.phabricator.com/D17533
2017-03-22 09:28:36 -07:00
|
|
|
|
2017-03-28 09:30:58 -07:00
|
|
|
if ($is_force) {
|
|
|
|
$tail[] = $reviewer_phid;
|
|
|
|
|
|
|
|
$options[$reviewer_phid] = pht(
|
|
|
|
'Force accept as %s',
|
|
|
|
$viewer->renderHandle($reviewer_phid));
|
|
|
|
} else {
|
|
|
|
$head[] = $reviewer_phid;
|
|
|
|
$value[] = $reviewer_phid;
|
|
|
|
|
|
|
|
$options[$reviewer_phid] = pht(
|
|
|
|
'Accept as %s',
|
|
|
|
$viewer->renderHandle($reviewer_phid));
|
|
|
|
}
|
When accepting revisions, allow users to accept on behalf of a subset of reviewers
Summary:
Ref T12271. Currenty, when you "Accept" a revision, you always accept it for all reviewers you have authority over.
There are some situations where communication can be more clear if users can accept as only themselves, or for only some packages, etc. T12271 discusses some of these use cases in more depth.
Instead of making "Accept" a blanket action, default it to doing what it does now but let the user uncheck reviewers.
In cases where project/package reviewers aren't in use, this doesn't change anything.
For now, "reject" still acts the old way (reject everything). We could make that use checkboxes too, but I'm not sure there's as much of a use case for it, and I generally want users who are blocking stuff to have more direct accountability in a product sense.
Test Plan:
- Accepted normally.
- Accepted a subset.
- Tried to accept none.
- Tried to accept bogus reviewers.
- Accepted with myself not a reviewer
- Accepted with only one reviewer (just got normal "this will be accepted" text).
{F4251255}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12271
Differential Revision: https://secure.phabricator.com/D17533
2017-03-22 09:28:36 -07:00
|
|
|
}
|
|
|
|
|
2017-03-28 09:30:58 -07:00
|
|
|
// Reorder reviewers so "force accept" reviewers come at the end.
|
|
|
|
$options =
|
|
|
|
array_select_keys($options, $head) +
|
|
|
|
array_select_keys($options, $tail);
|
|
|
|
|
When accepting revisions, allow users to accept on behalf of a subset of reviewers
Summary:
Ref T12271. Currenty, when you "Accept" a revision, you always accept it for all reviewers you have authority over.
There are some situations where communication can be more clear if users can accept as only themselves, or for only some packages, etc. T12271 discusses some of these use cases in more depth.
Instead of making "Accept" a blanket action, default it to doing what it does now but let the user uncheck reviewers.
In cases where project/package reviewers aren't in use, this doesn't change anything.
For now, "reject" still acts the old way (reject everything). We could make that use checkboxes too, but I'm not sure there's as much of a use case for it, and I generally want users who are blocking stuff to have more direct accountability in a product sense.
Test Plan:
- Accepted normally.
- Accepted a subset.
- Tried to accept none.
- Tried to accept bogus reviewers.
- Accepted with myself not a reviewer
- Accepted with only one reviewer (just got normal "this will be accepted" text).
{F4251255}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12271
Differential Revision: https://secure.phabricator.com/D17533
2017-03-22 09:28:36 -07:00
|
|
|
return array($options, $value);
|
|
|
|
}
|
|
|
|
|
2016-12-29 10:35:47 -08:00
|
|
|
public function generateOldValue($object) {
|
|
|
|
$actor = $this->getActor();
|
2017-01-18 12:56:49 -08:00
|
|
|
return $this->isViewerFullyAccepted($object, $actor);
|
2016-12-29 10:35:47 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
public function applyExternalEffects($object, $value) {
|
|
|
|
$status = DifferentialReviewerStatus::STATUS_ACCEPTED;
|
|
|
|
$actor = $this->getActor();
|
|
|
|
$this->applyReviewerEffect($object, $actor, $value, $status);
|
|
|
|
}
|
|
|
|
|
|
|
|
protected function validateAction($object, PhabricatorUser $viewer) {
|
|
|
|
if ($object->isClosed()) {
|
|
|
|
throw new Exception(
|
|
|
|
pht(
|
|
|
|
'You can not accept this revision because it has already been '.
|
|
|
|
'closed. Only open revisions can be accepted.'));
|
|
|
|
}
|
|
|
|
|
In Differential, prevent "Accept" and "Reject" from "Plan Changes + Draft"
Summary:
Ref T13130. See PHI483. Currently, "Plan Changes + Draft" uses rules like "Plan Changes", not rules like "Draft", and allows "Accept".
This isn't consistent with how "Draft" and "Accept" work in other cases. Make "Plan Changes + Draft" more like "Draft" for consistency.
Also fix a string that didn't have a natural English version.
Test Plan:
- Added a failing build plan.
- Created a revision.
- Loaded the revision before builds completed, saw a nicer piece of text about "waiting for builds" instead of "waiting for 2 build(s)".
- Builds failed, which automatically demoted the reivsion to "Changes Planned + Draft".
- As the author and as a reviewer, verified all the actions available to me made sense (particularly, no "Accept").
- Abandoned the revision to test "Abandoned + Draft".
- As the author and as a reviewer, verified all the actions available to me made sense.
- Reclaimed the revision, then used "Request Review" to send it to "Needs Review". Verified that actions made sense and, e.g., reviewers could now "Accept" normally.
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13130
Differential Revision: https://secure.phabricator.com/D19398
2018-04-21 13:00:54 -07:00
|
|
|
if ($object->isDraft() || !$object->getShouldBroadcast()) {
|
2017-11-28 11:05:15 -08:00
|
|
|
throw new Exception(
|
|
|
|
pht('You can not accept a draft revision.'));
|
|
|
|
}
|
|
|
|
|
2016-12-29 10:35:47 -08:00
|
|
|
$config_key = 'differential.allow-self-accept';
|
|
|
|
if (!PhabricatorEnv::getEnvConfig($config_key)) {
|
|
|
|
if ($this->isViewerRevisionAuthor($object, $viewer)) {
|
|
|
|
throw new Exception(
|
|
|
|
pht(
|
|
|
|
'You can not accept this revision because you are the revision '.
|
|
|
|
'author. You can only accept revisions you do not own. You can '.
|
|
|
|
'change this behavior by adjusting the "%s" setting in Config.',
|
|
|
|
$config_key));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-01-18 12:56:49 -08:00
|
|
|
if ($this->isViewerFullyAccepted($object, $viewer)) {
|
2016-12-29 10:35:47 -08:00
|
|
|
throw new Exception(
|
|
|
|
pht(
|
|
|
|
'You can not accept this revision because you have already '.
|
|
|
|
'accepted it.'));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
When accepting revisions, allow users to accept on behalf of a subset of reviewers
Summary:
Ref T12271. Currenty, when you "Accept" a revision, you always accept it for all reviewers you have authority over.
There are some situations where communication can be more clear if users can accept as only themselves, or for only some packages, etc. T12271 discusses some of these use cases in more depth.
Instead of making "Accept" a blanket action, default it to doing what it does now but let the user uncheck reviewers.
In cases where project/package reviewers aren't in use, this doesn't change anything.
For now, "reject" still acts the old way (reject everything). We could make that use checkboxes too, but I'm not sure there's as much of a use case for it, and I generally want users who are blocking stuff to have more direct accountability in a product sense.
Test Plan:
- Accepted normally.
- Accepted a subset.
- Tried to accept none.
- Tried to accept bogus reviewers.
- Accepted with myself not a reviewer
- Accepted with only one reviewer (just got normal "this will be accepted" text).
{F4251255}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12271
Differential Revision: https://secure.phabricator.com/D17533
2017-03-22 09:28:36 -07:00
|
|
|
protected function validateOptionValue($object, $actor, array $value) {
|
|
|
|
if (!$value) {
|
|
|
|
throw new Exception(
|
|
|
|
pht(
|
|
|
|
'When accepting a revision, you must accept on behalf of at '.
|
|
|
|
'least one reviewer.'));
|
|
|
|
}
|
|
|
|
|
Don't consider accepting on behalf of valid-but-accepted reviewers to be a validation error
Summary:
Fixes T12757. Here's a simple repro for this:
- Add a package you own as a reviewer to a revision you're reviewing.
- Open two windows, select "Accept", don't submit the form.
- Submit the form in window A.
- Submit the fomr in window B.
Previously, window B would show an error, because we considered accepting on behalf of the package invalid, as the package had already accepted.
Instead, let repeat-accepts through without complaint.
Some product stuff:
- We could roadblock users with a more narrow validation error message here instead, like "Package X has already been accepted.", but I think this would be more annoying than helpful.
- If your accept has no effect (i.e., everything you're accepting for has already accepted) we currently just let it through. I think this is fine -- and a bit tricky to tailor -- but the ideal/consistent beavior is to do a "no effect" warning like "All the reviewers you're accepting for have already accepted.". This is sufficiently finnicky/rare (and probably not terribly useful/desiable in this specific case)that I'm just punting.
Test Plan: Did the flow above, got an "Accept" instead of a validation error.
Reviewers: chad, lvital
Reviewed By: chad, lvital
Subscribers: lvital
Maniphest Tasks: T12757
Differential Revision: https://secure.phabricator.com/D18019
2017-05-25 13:19:30 -07:00
|
|
|
// NOTE: We're including reviewers who have already been accepted in this
|
|
|
|
// check. Legitimate users may race one another to accept on behalf of
|
|
|
|
// packages. If we get a form submission which includes a reviewer which
|
|
|
|
// someone has already accepted, that's fine. See T12757.
|
|
|
|
|
|
|
|
list($options) = $this->getActionOptions($actor, $object, true);
|
When accepting revisions, allow users to accept on behalf of a subset of reviewers
Summary:
Ref T12271. Currenty, when you "Accept" a revision, you always accept it for all reviewers you have authority over.
There are some situations where communication can be more clear if users can accept as only themselves, or for only some packages, etc. T12271 discusses some of these use cases in more depth.
Instead of making "Accept" a blanket action, default it to doing what it does now but let the user uncheck reviewers.
In cases where project/package reviewers aren't in use, this doesn't change anything.
For now, "reject" still acts the old way (reject everything). We could make that use checkboxes too, but I'm not sure there's as much of a use case for it, and I generally want users who are blocking stuff to have more direct accountability in a product sense.
Test Plan:
- Accepted normally.
- Accepted a subset.
- Tried to accept none.
- Tried to accept bogus reviewers.
- Accepted with myself not a reviewer
- Accepted with only one reviewer (just got normal "this will be accepted" text).
{F4251255}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12271
Differential Revision: https://secure.phabricator.com/D17533
2017-03-22 09:28:36 -07:00
|
|
|
foreach ($value as $phid) {
|
|
|
|
if (!isset($options[$phid])) {
|
|
|
|
throw new Exception(
|
|
|
|
pht(
|
|
|
|
'Reviewer "%s" is not a valid reviewer which you have authority '.
|
|
|
|
'to accept on behalf of.',
|
|
|
|
$phid));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-12-29 10:35:47 -08:00
|
|
|
public function getTitle() {
|
When accepting revisions, allow users to accept on behalf of a subset of reviewers
Summary:
Ref T12271. Currenty, when you "Accept" a revision, you always accept it for all reviewers you have authority over.
There are some situations where communication can be more clear if users can accept as only themselves, or for only some packages, etc. T12271 discusses some of these use cases in more depth.
Instead of making "Accept" a blanket action, default it to doing what it does now but let the user uncheck reviewers.
In cases where project/package reviewers aren't in use, this doesn't change anything.
For now, "reject" still acts the old way (reject everything). We could make that use checkboxes too, but I'm not sure there's as much of a use case for it, and I generally want users who are blocking stuff to have more direct accountability in a product sense.
Test Plan:
- Accepted normally.
- Accepted a subset.
- Tried to accept none.
- Tried to accept bogus reviewers.
- Accepted with myself not a reviewer
- Accepted with only one reviewer (just got normal "this will be accepted" text).
{F4251255}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12271
Differential Revision: https://secure.phabricator.com/D17533
2017-03-22 09:28:36 -07:00
|
|
|
$new = $this->getNewValue();
|
|
|
|
if (is_array($new) && $new) {
|
|
|
|
return pht(
|
|
|
|
'%s accepted this revision as %s reviewer(s): %s.',
|
|
|
|
$this->renderAuthor(),
|
|
|
|
phutil_count($new),
|
|
|
|
$this->renderHandleList($new));
|
|
|
|
} else {
|
|
|
|
return pht(
|
|
|
|
'%s accepted this revision.',
|
|
|
|
$this->renderAuthor());
|
|
|
|
}
|
2016-12-29 10:35:47 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
public function getTitleForFeed() {
|
|
|
|
return pht(
|
|
|
|
'%s accepted %s.',
|
|
|
|
$this->renderAuthor(),
|
|
|
|
$this->renderObject());
|
|
|
|
}
|
|
|
|
|
2018-06-27 09:48:18 -07:00
|
|
|
public function getTransactionTypeForConduit($xaction) {
|
|
|
|
return 'accept';
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getFieldValuesForConduit($object, $data) {
|
|
|
|
return array();
|
|
|
|
}
|
|
|
|
|
2016-12-29 10:35:47 -08:00
|
|
|
}
|