@recaptime-dev's working patches + fork for Phorge, a community fork of Phabricator. (Upstream dev and stable branches are at upstream/main and upstream/stable respectively.)
hq.recaptime.dev/wiki/Phorge
phorge
phabricator
Downgrade accepts on "request changes", and make sticky accepts optional
Summary:
Fixes T3202. This fixes a couple of workflow issues:
- Accepted Revision -> Request Review. Currently this stays "accepted" due to sticky rules being too aggressive, but should transition to "needs review".
- Accepted Revision -> Plan Changes -> Request Review. Currently this stays "accepted". I think this behavior is correct, and have retained it. (In this case, you don't update the revision, you just "undo" your plan changes.) You can "Request Review" again to get back to "Needs Review".
Then implements a "sticky accept" switch:
- When off, updates downgrade accepts.
- When off, "request review" always downgrades accepts.
Test Plan:
- Went through all (I think?) of the plan changes / request review / accept / update workflows, with sticky accept on and off.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3202
Differential Revision: https://secure.phabricator.com/D8614
+79
-22
+19
src/applications/differential/config/PhabricatorDifferentialConfigOptions.php
+19
src/applications/differential/config/PhabricatorDifferentialConfigOptions.php
···
114
114
"generated by an automatic process, and thus get hidden by ".
115
115
"default in differential."))
116
116
->addExample("/config\.h$/\n#/autobuilt/#", pht("Valid Setting")),
117
+
$this->newOption('differential.sticky-accept', 'bool', true)
118
+
->setBoolOptions(
119
+
array(
120
+
pht("Accepts persist across updates"),
121
+
pht("Accepts are reset by updates"),
122
+
))
123
+
->setSummary(
124
+
pht("Should updating an accepted revision require re-review?"))
125
+
->setDescription(
126
+
pht(
127
+
'Normally, when revisions that have been "Accepted" are updated, '.
128
+
'they remain "Accepted". This allows reviewers to suggest minor '.
129
+
'alterations when accepting, and encourages authors to update '.
130
+
'if they make minor changes in response to this feedback.'.
131
+
"\n\n".
132
+
'If you want updates to always require re-review, you can disable '.
133
+
'the "stickiness" of the "Accepted" status with this option. '.
134
+
'This may make the process for minor changes much more burdensome '.
135
+
'to both authors and reviewers.')),
117
136
$this->newOption('differential.allow-self-accept', 'bool', false)
118
137
->setBoolOptions(
119
138
array(
+36
-8
src/applications/differential/editor/DifferentialTransactionEditor.php
+36
-8
src/applications/differential/editor/DifferentialTransactionEditor.php
···
238
238
$actor_phid = $actor->getPHID();
239
239
$type_edge = PhabricatorTransactions::TYPE_EDGE;
240
240
241
+
$status_plan = ArcanistDifferentialRevisionStatus::CHANGES_PLANNED;
242
+
241
243
$edge_reviewer = PhabricatorEdgeConfig::TYPE_DREV_HAS_REVIEWER;
242
244
$edge_ref_task = PhabricatorEdgeConfig::TYPE_DREV_HAS_RELATED_TASK;
243
245
246
+
$is_sticky_accept = PhabricatorEnv::getEnvConfig(
247
+
'differential.sticky-accept');
248
+
244
249
$downgrade_rejects = false;
250
+
$downgrade_accepts = false;
245
251
if ($this->getIsCloseByCommit()) {
246
252
// Never downgrade reviewers when we're closing a revision after a
247
253
// commit.
···
249
255
switch ($xaction->getTransactionType()) {
250
256
case DifferentialTransaction::TYPE_UPDATE:
251
257
$downgrade_rejects = true;
258
+
if (!$is_sticky_accept) {
259
+
// If "sticky accept" is disabled, also downgrade the accepts.
260
+
$downgrade_accepts = true;
261
+
}
252
262
break;
253
263
case DifferentialTransaction::TYPE_ACTION:
254
264
switch ($xaction->getNewValue()) {
255
265
case DifferentialAction::ACTION_REQUEST:
256
266
$downgrade_rejects = true;
267
+
if ((!$is_sticky_accept) ||
268
+
($object->getStatus() != $status_plan)) {
269
+
// If the old state isn't "changes planned", downgrade the
270
+
// accepts. This exception allows an accepted revision to
271
+
// go through Plan Changes -> Request Review to return to
272
+
// "accepted" if the author didn't update the revision.
273
+
$downgrade_accepts = true;
274
+
}
257
275
break;
258
276
}
259
277
break;
···
265
283
$old_accept = DifferentialReviewerStatus::STATUS_ACCEPTED_OLDER;
266
284
$old_reject = DifferentialReviewerStatus::STATUS_REJECTED_OLDER;
267
285
268
-
if ($downgrade_rejects) {
286
+
if ($downgrade_rejects || $downgrade_accepts) {
269
287
// When a revision is updated, change all "reject" to "rejected older
270
288
// revision". This means we won't immediately push the update back into
271
289
// "needs review", but outstanding rejects will still block it from
···
277
295
278
296
$edits = array();
279
297
foreach ($object->getReviewerStatus() as $reviewer) {
280
-
if ($reviewer->getStatus() == $new_reject) {
281
-
$edits[$reviewer->getReviewerPHID()] = array(
282
-
'data' => array(
283
-
'status' => $old_reject,
284
-
),
285
-
);
298
+
if ($downgrade_rejects) {
299
+
if ($reviewer->getStatus() == $new_reject) {
300
+
$edits[$reviewer->getReviewerPHID()] = array(
301
+
'data' => array(
302
+
'status' => $old_reject,
303
+
),
304
+
);
305
+
}
286
306
}
287
307
288
-
// TODO: If sticky accept is off, do a similar update for accepts.
308
+
if ($downgrade_accepts) {
309
+
if ($reviewer->getStatus() == $new_accept) {
310
+
$edits[$reviewer->getReviewerPHID()] = array(
311
+
'data' => array(
312
+
'status' => $old_accept,
313
+
),
314
+
);
315
+
}
316
+
}
289
317
}
290
318
291
319
if ($edits) {
+24
-14
src/docs/user/userguide/differential_faq.diviner
+24
-14
src/docs/user/userguide/differential_faq.diviner
···
5
5
6
6
= Why does an "accepted" revision remain accepted when it is updated? =
7
7
8
-
When a revision author updates an "accepted" revision in Differential, the
9
-
state remains "accepted". This can be confusing if you expect the revision to
10
-
change to "needs review" when it is updated.
8
+
You can configure this behavior with `differential.sticky-accept`.
11
9
12
-
This behavior is intentional, to encourage authors to update revisions when they
13
-
make minor changes after a revision is accepted. For example, a reviewer may
14
-
accept a change with a comment like this:
10
+
When a revision author updates an "Accepted" revision in Differential, the
11
+
state remains "Accepted". This can be confusing if you expect the revision to
12
+
change to "Needs Review" when it is updated.
13
+
14
+
Although this behavior is configurable, we think stickiness is a good behavior:
15
+
stickiness encourage authors to update revisions when they make minor changes
16
+
after a revision is accepted. For example, a reviewer may accept a change with a
17
+
comment like this:
15
18
16
19
> Looks great, but can you add some documentation for the foo() function
17
20
> before you land it? I also caught a couple typos, see inlines.
18
21
19
-
If updating the revision reverted the status to "needs review", the author
22
+
If updating the revision reverted the status to "Needs Review", the author
20
23
is discouraged from updating the revision when they make minor changes because
21
24
they'll have to wait for their reviewer to have a chance to look at it again.
22
25
23
-
Instead, the "accept" state is sticky to encourage them to update the revision
26
+
Instead, the "Accepted" state is sticky to encourage them to update the revision
24
27
with a comment like:
25
28
26
29
> - Added docs.
···
41
44
Unless you've configured additional layers of enforcement, there's nothing
42
45
stopping them from silently changing the code before pushing it, anyway.
43
46
47
+
44
48
= How can I enable syntax highlighting? =
45
49
46
50
You need to install and configure **Pygments** to highlight anything else than
47
-
PHP. Consult the configuration file for instructions.
51
+
PHP. See the `pygments.enabled` configuration setting.
52
+
48
53
49
54
= What do the whitespace options mean? =
50
55
···
61
66
setting.
62
67
- **Ignore All**: Ignore all whitespace changes in all files.
63
68
64
-
= What does the very light green and red backgrounds mean? =
65
69
66
-
Differential uses these colors to mark changes coming from rebase - they are
70
+
= What do the very light green and red backgrounds mean? =
71
+
72
+
Differential uses these colors to mark changes coming from rebase: they are
67
73
part of the diff but they were not added or removed by the author. They can
68
-
appear in diff of diffs against different bases. See
69
-
[[ https://secure.phabricator.com/D3324?vs=6468&id=6513#toc | D3324 ]] for
70
-
example.
74
+
appear in diff of diffs against different bases.
75
+
76
+
= Next Steps =
77
+
78
+
Continue by:
79
+
80
+
- returning to the @{article:Differential User Guide}.