Page MenuHomePhorge

Resolving without Claiming causes error "Action with no effect"
Closed, ResolvedPublic

Assigned To
Authored By
valerio.bozzolan
Mar 9 2023, 17:52
Referenced Files
F267558: Task No Action.png
Jul 31 2023, 13:04
F325671: Preview before problem.png
Jul 31 2023, 13:04
F325669: Unset.png
Jul 31 2023, 13:04
F325667: Preview.png
Jul 31 2023, 13:04
F325665: Actions.png
Jul 31 2023, 13:04
Tokens
"Yellow Medal" token, awarded by valerio.bozzolan.

Description

Steps to reproduce:

  1. As an admin, go to /config/edit/maniphest.statuses/ and make sure that the a closed task status (e.g. "resolved") includes the line "claim": true
  2. Have a simple Task, Open, without owner
  3. Add Action > Change Status > Resolved
    • NOTE: An automatic Transaction is added to Claim=yourself
  4. Add Action > Assign / Claim > unset yourself
  5. Save

What happens:

Task No Action.png (186×581 px, 17 KB)

What should happen:

No warning should be raised.

This is a corner case since, the warning it's useful when a field is empty. But, in this case, there is a default in action: it is really setting yourself as Assignee. And you are unsetting it, and not leaving it as just blank.

What probably happens

This is an attempt to describe what kind of interaction happens under the hood. Every line is a new time phase.

Starting from a simple Task, Open, without owner:

PhaseWhat you DoWhat Phorge doesNotes
1Add Action > Change Status > Resolved
Actions.png (117×580 px, 6 KB)
2The ManiphestTransactionEditor (:356-368) expandes the transaction to set yourself as claimer
Preview.png (83×622 px, 9 KB)
(This is nice)
3Add Action > Assign / Claim > unset yourself
Unset.png (165×653 px, 18 KB)
behavior-comment-actions.js removeAction()
The Preview does not show anymore yourself as claimer.
Preview before problem.png (62×618 px, 7 KB)
4Save (what is it actually sent?)← On Save, maybe "Expanded transactions that were unset" should be skipped
5The PhabricatorApplicationTransactionEditor (:2821-2826) thinks Claim=null was unuseful
6throw new PhabricatorApplicationTransactionNoEffectException
7The mentioned error is shown
Task No Action.png (186×581 px, 17 KB)

Things that could be inspirational:

It seems the comment actions are generated from these files:

Event Timeline

valerio.bozzolan triaged this task as Wishlist priority.Mar 9 2023, 17:52
valerio.bozzolan renamed this task from Prevent warning "Action with no effect" when Resolving without Claiming to Resolving without Claiming causes error "Action with no effect".Mar 10 2023, 06:33
valerio.bozzolan updated the task description. (Show Details)

@valerio.bozzolan F267558 in the task description is not attached, thus it cannot be seen by others.

I'm quite sure we have to set PhabricatorApplicationTransaction.php::setIgnoreOnNoEffect(bool) somewhere but I don't know where ihih

Historical references: rP69eab4196de462e42b07b60e2b52071631f4a3c8 and rP4041a7e0f66406dbaa31faa3807d50833b7c7efd (which didn't help much).

We perform two transactions: $xaction->getTransactionType(): status and $xaction->getTransactionType(): reassign.
Looking at the latter:

Step1: Expand "Change Status" field (setting the Resolved status by default):

'type: reassign' at [/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php:717]
'oldValue: ' at [/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php:718]
'newValue: PHID-USER-....' at [/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php:719]

Step2: Also expand the "Assign / Claim" field (prepopulated with my username):

Same result as in Step1

Step3: Manually remove my username from the "Assign / Claim" field:

'type: reassign' at [/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php:717]
'oldValue: ' at [/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php:718]
'newValue: ' at [/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php:719]

The reassign action is not special-cased in transactionHasEffect() or parent transactionHasEffect(), so we end up calling generic getTransactionHasEffect() which simply compares if $old !== $new. The result is false (as the actor manually removes themselves from being automatically set as owner), though IMO it should be true (no owner was set before either).

Obviously, any fixes should be in ManiphestTransactionEditor and not spill into generic parent PhabricatorApplicationTransactionEditor.

I looked into adding a case in transactionHasEffect(). That is not possible as it handles one single transaction (e.g. reassign) while our situation depends on a second condition (status change transaction).

I also looked into adjusting/expanding the code which silently sets the actor as owner. This code handles only setting up the "hidden" reassign transaction but it is entirely unrelated to any UI dialogs. Still it provides some pointers / conditions to look into.

I failed to "locate" the PhabricatorApplicationTransaction that we're about to perform after manually opening the "Add Field > Assign / Claim" dropdown in a scope limited to Maniphest && also allowing to check for the other transaction condition (status change transaction), to try setIgnoreOnNoEffect mentioned above.