Thanks!

I believe the expected behavior is that "milestone, subproject" kicks the task out of the milestone (leaving it in only the subproject) while "subproject, milestone" kicks it out of the subproject (leaving it in only the milestone).

A bunch of related edits already have test coverage in PhabricatorProjectCoreTestCase so this should be fairly easy to get coverage on, at least, and hopefully also easy to fix.

Regarding the expected behavior, do you mean it should not be possible for a task to be in both a milestone and subproject simultaneously?

No, I don't mean that, as written.

A task can be in both a milestone and a subproject simultaneously. For example, "Project X > Milestone 3" and "Project Y > Subproject Z". Note that the parent projects are different ("X" vs "Y").

I intend that it can not be in "Project X > Milestone 3" and "Project X > Project Y" simultaneously. Note that the parent projects are the same (both "X").

I think there is no strongly technical reason we could not allow this, but I think this is the most reasonable product behavior. Particularly, I think would be surprising if moving a task from "Milestone 3" to "Backlog" could strip subprojects. With this rule, it can not (for the task to appear in "Milestone 3", it must not be in any subprojects).

I intend that it can not be in "Project X > Milestone 3" and "Project X > Project Y" simultaneously. Note that the parent projects are the same (both "X").

I would be disappointed if this was removed - my team finds this extremely useful. Our use case:

• Project X - a parent project representing my team of people
• Project X > Project Y - a specific project my team is working on.
• Project X > Project Z - another project that my team is working on.
• Project X > Milestone 3 - a mix of all of the active projects that my team members are working on in the current milestone. We are using milestones to represent sprints.

Particularly, I think would be surprising if moving a task from "Milestone 3" to "Backlog" could strip subprojects.

I agree, I don't think project tags should ever be automatically removed.

I agree, I don't think project tags should ever be automatically removed.

They already are in many cases, and this is unavoidable given the way the product works. If you add "Project X" to a task tagged with "Project X > Subproject Y", the subproject is stripped. If you add "X > Milestone 9" to a task tagged with "X > Milestone 8", the other milestone is stripped.

(And, unless it's also bugged, I believe moving from a milestone to a non-milestone column on "Project X" should already strip subprojects. The proposed behavior just prevents there from being any subprojects to strip.)

In fact, I'm pretty surprised that your workflow doesn't hit major bugs/issues all the time, unless this stuff is currently far bugger than I believe it is. If you ever tag "Project Y" before moving a task to "Milestone 3", you'd no longer be able to move it from the workboard since it would vanish (until T11036)? Do you have a very specific sequence of organizational steps you take to avoid these issues? Are you just not using workboards at all?

I think we use workboards extensively, but this is the only company I've used Phab so I don't have a diverse sample set. We have workboards for subprojects, workboards for parent projects to view a team's list of new requests and high-level sprint plans (e.g. a backlog column, and a column for each sprint milestone). We click through on the milestone columns to view a sprint-specific workboard (typical Kanban columns).

Our end goal is to be able to view a unified workboard for a collection of tasks from different projects. The way we found to do that using a milestone on the parent project, because we were able to cross-list a task in a milestone and subproject.

I understand you are saying this is not the intended behavior, and it is in fact a bug. If that's the case, is there an alternative way to accomplish our goal in the product? Thanks!

If that's the case, is there an alternative way to accomplish our goal in the product? Thanks!

You could perhaps separate your "label" projects out of the hierarchy. Assuming the team is "Masons", you'd have two top-level projects like this:

• Masons (Labels)
  • Sculpture
  • Stonework
  • Quarrying
• Masons (Status)
  • Milestone 1
  • Milestone 2
  • Milestone 3
  • ...

Assuming this is your hierarchy today:

• Masons
  • Sculpture
  • Stonework
  • Quarrying
  • Milestone 1
  • Milestone 2
  • Milestone 3
  • ...

...I don't understand how you can use this sort of setup without constantly encountering issues like these (I've reproduced them locally, to double-check that I'm probably not crazy):

• If a new task is tagged with only "Sculpture", it won't appear anywhere on the "Masons" board, so it will never be put into a sprint/milestone/iteration (until T11036).
• If a task is dragged from "Milestone 2" to "Backlog" (or any other non-milestone column) on the "Masons" board, it will lose subproject tags ("Sculpture", "Stonework", etc).
• If "Sculpture" is added to a task in "Milestone 2", the task disappears from the milestone (this bug).
• I'm not 100% sure my repro case for this is complete, but if you move a task on a subproject board to a different column, then drag it to a non-milestone column on the parent, we seem to just fatal outright:

Thanks for tryout out this workflow!

If a new task is tagged with only "Sculpture", it won't appear anywhere on the "Masons" board, so it will never be put into a sprint/milestone/iteration (until T11036).

Yes, we actually find this useful - we can keep a deeper backlog of tickets for the sub-projects without cluttering up the parent project. We prune the subproject backlogs every sprint or two.

If a task is dragged from "Milestone 2" to "Backlog" (or any other non-milestone column) on the "Masons" board, it will lose subproject tags ("Sculpture", "Stonework", etc).

Yes, we work around this by using only a single non-milestone column on the "Masons" workboard. We call it "Needs Triage" and its where requests from another team land - they know the "Masons" are responsible for this, but they don't know or care if it's a Sculpture, Stonework or Quarrying task. This column is usually empty.

We don't have any other columns on the Masons workboard because as you said, anything listed there would have its subproject tag stripped. That's why we've never hit the fatal error that you encountered. Here's what our parent project workboard looks like:

What it looks like here:
We have the project Grammofy Collections which represents one of our products.
It has a milestone Full Catalog Access
It also has a subproject Grammofy Collections: Frontend/Web

When the milestone Full Catalog Access is added before the subproject Grammofy Collections: Frontend/Web, the Task won't show up in the workboard's corresponding milestone column.
When the milestone Full Catalog Access is added after the subproject Grammofy Collections: Frontend/Web, the Task will show up in the workboard's corresponding milestone column.

The assigned milestone/subproject are shown correctly in the Tasks details.

While there might be reasonable technical reasons for this behavior, it doesn't make sense at all for end users which expect to be able to arbitrarily apply Tags to Tasks.
Also from a product management perspective, I don't see anything wrong with the scenario we're having here.

A general project, representing a product, has milestones.
A tasks is assigned to one of those milestones.
This task is also assigned to one of the subprojects (here: the web frontend of this product).

This looks to me like a straightforward setup/scenario which should "just work" and doesn't look to me like I'm bending Phabricator beyond what it is supposed to do (or I misunderstood projects/subprojects completely).

Do you expect a task to be able to be tagged with "Warp Drive" and also simultaneously tagged with subproject "Warp Drive > Thermocoupling"?
Do you expect a task to be able to be tagged with "Warp Drive" and also simultaneously tagged with milestone "Warp Drive > Milestone 1"?

Do you expect a task to be able to be tagged with "Warp Drive" and also simultaneously tagged with subproject "Warp Drive > Thermocoupling"?

No, Thermocoupling alone is enough, as it implies it's part of Warp Drive.

Do you expect a task to be able to be tagged with "Warp Drive" and also simultaneously tagged with milestone "Warp Drive > Milestone 1"?

No, Milestone 1 alone is enough, as it implies it's part of Warp Drive

I expect:
A task to be tagged with Warp Drive > Milestone 1 and Warp Drive > Thermocoupling,
…as Milestone 1 tells me when this Task needs to be finished and Thermocoupling tells me who (the engineers figuring out how to realize Thermocoupling) have to work on it.

Okay. When a task is in "Warp Drive > Thermocoupling" and "Warp Drive > Milestone 1", and you view the "Warp Drive" board and drag the task from "Milestone 1" to "Backlog", what do you expect to happen to the projecs the task is tagged with?

Okay. When a task is in "Warp Drive > Thermocoupling" and "Warp Drive > Milestone 1", and you view the "Warp Drive" board and drag the task from "Milestone 1" to "Backlog", what do you expect to happen to the projecs the task is tagged with?

Hmm, good point…
From an end-user's PoV I think I'd expect:

• Warp Drive and column Backlog to be assigned
• Warp Drive > Milestone 1 to be removed

Knowing, that a simultaneous assignment of Warp Drive and Warp Drive > Thermocoupling won't work, makes this difficult.

• Losing the fine-grained subproject to Warp Drive > Thermocoupling classification just because pulling it off Warp Drive > Milestone 1 is destructive and feels wrong
• Not allowing to drag it to Backlog due to those restrictions feels like throwing sticks between the users' legs
• Assuming there's a Backlog column in Warp Drive > Thermocoupling and placing it there obviously won't work either

So either the simultaneous assignment of a Task to a parent and subproject at the same time needs to be possible to allow for this or this operation has to be restricted.
Other/better ideas?

We currently (at least, in theory) prevent this situation from ever occurring by preventing simultaneous tagging with both "Warp Drive > Thermocoupling" and "Warp Drive > Milestone 1". Since a task can not appear in both a milestone and subproject of a particular parent task, users can never be faced with the opportunity to perform a destructive drag operation.

I believe this is the least bad way to resolve things. This rule is mildly unintuitive, but I think the harm/surprise this rule causes is smaller than the harm/surprise caused by any other rule.

Some other rules we could use are:

Allow Ancestry Tagging: Let a task be tagged with both"Warp Drive" and "Warp Drive > Thermocoupling" simultaneously.

I believe this is a very bad rule here because "Warp Drive" and "Warp Drive, Warp Drive > Thermcoupling" would be different: in the case where the task had both tags, the task would appear on both workboards. Dragging a task from a subproject column to a parent project column might mean "move the task to the parent" or might mean "tag the task with the parent, but also leave it in the subproject". I anticipate many users would be generally confused about this behavior and spend a lot of time adding redundant tags, or not adding parent tags that they needed to add because workflows had been built around parent tags. These behaviors generally get worse after T11036 and T5474.

Allow Destructive Operations: This operation does some variation of this:

+---------------------------------------------------------------------------+
| WOAH BUDDY CAREFULLY READ THIS WHOLE DIALOG PLEASE                        |
+---------------------------------------------------------------------------+
| This task is currently tagged with a milestone ("Milestone 1") and one or |
| more subprojects (including "Thermocoupling") of the same parent project  |
| ("Warp Drive").                                                           |
|                                                                           |
| A task can not be tagged with a particular project and one or more of     |
| that project's subprojects simultaneously, so the move you've attempted   |
| can not be performed exactly as intended.                                 |
|                                                                           |
| You can remove all the other subprojects (including "Thermocoupling") and |
| leave only the parent project. Specifically, these subprojecs will be     |
| removed:                                                                  |
|                                                                           |
|   - Thermocoupling                                                        |
|   - Capacitance                                                           |
|                                                                           |
| Alternatively, you can leave the subprojects and remove only the parent   |
| project ("Warp Drive"). If you do this, the task will disappear from the  |
| parent project's columns on the workboard (it can still be found inside   |
| subprojects).                                                             |
|                                                                           |
|   [ Cancel ] [ Remove Conflicting Subprojects ] [ Remove Parent Project ] |
+---------------------------------------------------------------------------+

I believe this is also very bad because, basically, a lot of users will not read that and click one of the buttons randomly and be sad. This could be expressed with more nuance in terms of "the UI being unclear" but that's basically what it comes down to.

We also can't reasonably prompt users like this via Conduit, and any workflow like this also becomes more complicated after T11036 and T5474.

There is an actual bug here too, but I believe the "milestones and subprojects conflict" rule is the least bad way to address the "drag to backlog = destroy data" problem.

Note that T11036 will introduce a variant of the "drag to backlog" problem, where you might drag a task from the "Warp Drive > Thermcoupling" column to the "Warp Drive" column and cause removal of many other subproject tags. However, I believe this is broadly a more intuitive operation, and that there are some other UI affordances we can provide to make this operation more clear without requiring a "giant modal choice dialog".

It's possible that I'm mistaken, and that we'll eventually change this behavior, but I don't expect to change it until T11036, T5474, and T10333 ship, at a minimum. Once those changes ship, we may see feedback or confusion which motivate re-examining this.

See T13092; tangentially, it might be nice to render these stories more explicitly as "X added Y, removed Z (because Z is a subproject of Y, and objects may not be tagged with multiple mutual ancestors/descendant projects)", if some sufficiently terse phrasing can be found.