Page MenuHomePhabricator

Web UI can only create "reference" relationships between Revisions and Tasks, not "close" relationships
Open, WishlistPublic

Description

If you add a task(s) to a revision via the "Edit Maniphest Tasks" link, the task(s) doesn't get resolved and closed when that revision is landed.

Why should this behavior be any different from adding "Fixes T123" in the revision summary? Currently, in order to add a task to a revision so that it gets closed upon landing, one has to "Edit Revision" and add "Fixes T123" in the summary.

Also, every once in a while some new developer in our team sees "Maniphest Tasks: " in the revision template that is displayed by arc diff. Adding the task to this field again does not close the task. Is this field still used and is it supposed to ever show up in the revision template?

Event Timeline

adityar7 updated the task description. (Show Details)
adityar7 added a subscriber: adityar7.
epriestley triaged this task as Wishlist priority.Jul 18 2013, 4:54 PM

The behavior is the same as Ref T123. The behavior of the "Maniphest Tasks" field is also the same as Ref T123. We might change this default or provide more controls in the UI to choose a "reference" vs "close" vs "close, wontfix" relationship, but the current behavior is intentional.

epriestley renamed this task from Edit Maniphest Tasks doesn't close added tasks upon landing the revision to Web UI can only create "reference" relationships between Revisions and Tasks, not "close" relationships.Jul 18 2013, 4:54 PM
epriestley added a project: Maniphest.
epriestley added a subscriber: epriestley.

Ok, thanks. It may be useful to mention the Ref T123 format in the docs or elsewhere. I wasn't aware of it at all, and it doesn't appear to be in the docs.

It'll also help to avoid confusion since the "close" behavior seems more natural for workflows such as ours -- all our developers assume that either approach (Web UI or "Maniphest Tasks") should create a "close" relationship and that the actual behavior is a bug.

turadg added a subscriber: turadg.Jul 8 2014, 4:25 PM
revi added a subscriber: revi.Oct 11 2014, 9:41 AM
scfc added a subscriber: scfc.Feb 9 2015, 1:01 PM
chad changed the visibility from "All Users" to "Public (No Login Required)".Jul 3 2015, 4:38 AM
eadler added a subscriber: eadler.Jul 15 2015, 3:01 AM
epriestley added a subscriber: swisspol.

A related issue surfaced recently. Actual use case (forensically reconstructed):

  • A user wrote Fixes TT... (instead of Fixes T..., note double TT) in a message by accident.
  • When they noticed the mistake, they (probably) manually used Edit Related ObjectsEdit Tasks to add a link between the revision and the task.
  • When this commit landed, the commit and task did not get an edge between them.

The current behavior of the piece of code which creates the <Commit, Task> edges is to parse the message for "magic words" in the form of Fixes T123, add edges for any it finds, and then change the relevant task statuses.

This means:

  • (From reading the code only, I haven't verified this) If you write Ref T123 in a commit message, only the revision (not the commit) gets linked to the task because the phrase doesn't change the task's status.
  • If you add links from the web to the revision, they aren't carried over to the commit since we don't look at edges on the revision.

I'm not entirely sure what to do about this. One additional factor is that the instance ran into this because they were using a script to compile a changelog-like record of changes, not because humans were confused, so the root problem was more one of changelog compilation rather than usability, per se.


At a minimum, I think the Ref T123 behavior is probably inconsistent and undesirable. If you push a Ref T123 commit without a revision, you should probably get an edge.

I'm somewhat less sure about copying edges in the general case, although I think it's probably correct to say that Ref T123 and Edit Related ObjectsEdit Tasks should be as close to equivalent as possible.

Part of the issue is that commits are a bit special. For other types of objects, we organize relationships in a "hub and spokes" pattern with tasks at the center. This is generally good but Commits/Revisions get to break these rules and be related to one another directly. (This also gets a bit muddier with things like Builds and, in the future, perhaps release-related objects from T9530).

It feels kind of bad to just copy edges, since copying things is The Greatest Evil In Software, but I think this is mostly a theoretical problem and works fine in practice.

An alternative is to limit or reduce copying and guide installs instead: "If you're compiling a changelog, follow the edge to the revision and then find tasks from there, in addition to tasks on the commit: it is possible that not all tasks are linked directly to the commit.". Regardless, this guidance is true in the general case, because tasks may be linked to a revision after commits for it land.

T11934 is a possible way forward on this (and other niche things) without adding a lot of Javascript and UI complexity, by supporting it through !fixes.