That seems reasonable. I also ran into a couple of other suggestions elsewhere:

Off the wall suggestion: how about a trigger that sets the subtype:

See also PHI1594, which wants:

See T13357 for followup.

There's currently a bug (likely related to D20652 or D20654?) where normal edits aren't respecting card order correctly during the redraw. I suspect this is just an order parameter getting lost somewhere.

a logical clock to complement the wall-time clocks

From D20653:

Just thinking out loud:

Here's roughly where I'm headed next. I'm planning to:

The "default" controller currently needs to "force" the URI parameters...
The "filter" controller currently needs to "force" the URI parameters...
The "apply" flow, where a new custom filter is applied...

A couple of weird cases on state management:

Got it, thanks for clarifying.

It looks like these triggers don't run when you move tasks via "Move on Workboard" (instead of drag and drop). Is this expected / intentional?

It looks like these triggers don't run when you move tasks via "Move on Workboard" (instead of drag and drop).

ah, I missed that. I guess I should start testing this stuff soon :)

In T13269#245817, @pasik wrote:

well, I'd say for example the "Close as <status> (only acts if task is not already closed)" is useful, and definitely needed.
Move the task to "done" column on the workboard, and the task automatically gets closed. That's handy.

well, I'd say for example the "Close as <status> (only acts if task is not already closed)" is useful, and definitely needed.
Move the task to "done" column on the workboard, and the task automatically gets closed. That's handy.

Things feel pretty reasonable to me for now. I'm going to fix those bugs you hit and I think I have a couple other things I wanted to tweak, but I'm largely happy with the featureset as a v1.

Broadly, it's not clear to me that any of these rules are actually good/useful/worth building.

Are these different from the existing implementation in PhabricatorProjectTriggerManiphestStatusRule?

• Close as <status> (only acts if task is not already closed).
• Reopen as <status>.

This more or less exists, now. See T13269 for followups and T13074 for additional context.

See PHI119. PHI1128 is probably another copy of this, which suggests it's still a real bug.

Simply adding two position rows on the same board doesn't reproduce the exact same error, we get this instead: [Unable to find...]

Make drops when a column position already exists go through.

See PHI119. This may describe a race fixed by chaos reduction in T13054. PHI1128 is probably another copy of this, which suggests it's still a real bug.
See PHI208. This describes a performance issue on workboards with very large numbers of tasks.

We may still pursue this, especially after T4900, but a lot of the use cases / needs are mostly theoretical and it's not clear they're actually necessary. Some of the actual solutions (like T10335) may largely provide enough clarity about these cases on their own. I'm currently planning to wait for feedback about recent and near-future changes (including triggers) and then fix whatever issues arise surgically -- possibly through animation, but possibly through other UI/UX remedies.

Those changes haven't landed yet but I'm just going to tidy this up a little early, see T13074 for followups.

Very happy to see that you guys are working on this, thank you. 👍

I'm going to consider this resolved at this point. The one thing I haven't built is the "task/point count" from the mocks (on the right-hand side of the header, counting points in each group), but I think this is probably only of much use under "Group by Owner", and maybe not even then. I'm open to building this in a future iteration and it's not likely to be very much work, I'd just like to see feedback that we're generally headed in the right direction first and that the element would have real-world use cases.

Currently, you can put a task in a column in these ways: