1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2025-01-27 23:18:20 +01:00
Commit graph

8 commits

Author SHA1 Message Date
epriestley
2fbc9a52da Allow users to "Force accept" package reviews if they own a more general package
Summary:
Ref T12272. If you own a package which owns "/", this allows you to force-accept package reviews for packages which own sub-paths, like "/src/adventure/".

The default UI looks something like this:

```
[X] Accept as epriestley
[X] Accept as Root Package
[ ] Force accept as Adventure Package
```

By default, force-accepts are not selected.

(I may do some UI cleanup and/or annotate "because you own X" in the future and/or mark these accepts specially in some way, particularly if this proves confusing along whatever dimension.)

Test Plan: {F4314747}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T12272

Differential Revision: https://secure.phabricator.com/D17569
2017-03-28 11:51:40 -07:00
epriestley
fab37aa4e3 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 14:25:04 -07:00
epriestley
269dd81f91 Allow users to re-accept or re-reject a revision if they have authority over package/project reviewers not yet in the target state
Summary:
To set this up:

  - alice accepts a revision.
  - Something adds a package or project she has authority over as a reviewer.
  - Because alice has already accepted, she can not re-accept, but she should be able to (in order to accept on behalf of the new project or package).

Test Plan:
  - Created a revision.
  - Accepted as user "dog".
  - Added "dog project".
  - Re-accepted.
  - Could not three-accept.
  - Removed "dog project.
  - Rejected.
  - Added "dog project".
  - Re-rejected.
  - Could not three-reject.

Reviewers: chad, eadler

Reviewed By: chad, eadler

Differential Revision: https://secure.phabricator.com/D17226
2017-01-18 13:16:01 -08:00
epriestley
7d3d022407 Restore "[Action]" mail subject lines to Differential/Diffusion
Summary: Ref T11114. Ref T10978. These hadn't made it over to EditEngine yet.

Test Plan:
  - Took various actions on revisions and commits.
  - Used `bin/mail show-outbound --id ...` to examine the "Vary Subject", saw it properly generate "[Accepted]", "[Resigned]", etc.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11114, T10978

Differential Revision: https://secure.phabricator.com/D17191
2017-01-12 11:44:24 -08:00
epriestley
50de3071ac Define Differential email action in terms of EditEngine
Summary: Ref T11114. Move email/command actions, like "!reject", to modular transactions + editengine.

Test Plan: Used `bin/mail receive-test` to pipe "!stuff" to an object, saw appropraite effects in web UI.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11114

Differential Revision: https://secure.phabricator.com/D17133
2017-01-02 13:25:45 -08:00
epriestley
f7b5955d33 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-31 10:10:05 -08:00
epriestley
48fcfeadaf Allow comment actions to be grouped; group Differential "Review" and "Revision" actions
Summary:
Ref T11114. Differential has more actions than it once did, and may have further actions in the future.

Make this dropdown a little easier to parse by grouping similar types of actions, like "Accept" and "Reject".

(The action order still needs to be tweaked a bit.)

Test Plan: {F2274526}

Reviewers: chad

Reviewed By: chad

Subscribers: eadler

Maniphest Tasks: T11114

Differential Revision: https://secure.phabricator.com/D17114
2016-12-31 10:09:41 -08:00
epriestley
5a6643f36f Restore "Accept", "Reject" and "Resign" actions to Differential on EditEngine
Summary:
Ref T11114. Some rough edges, but this largely makes Accept, Reject and Resign work in the new EditEngine comment area.

Ref T11050. This lays a little bit of groundwork for having "resign" mean "I don't want to review this, even if projects or packages I'm a member of need to", not just "remove me personally as a user reviewer".

Test Plan: Accepted, rejected and resigned from revisions without any major state issues.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11114, T11050

Differential Revision: https://secure.phabricator.com/D17113
2016-12-31 10:09:27 -08:00