Hi,
My small team & I have been using Phabricator for a year. This is the feature that we lack and that makes our day-to-day work difficult. It would be nice to have even the basics (drag & drop to a column -> update to a given status). Any advise or workaround in the meanwhile would also be nice if they are some. Sorry if I lack Phabricator knowledge and missed an obvious workaround feature.

@epriestley, @chad > The paid prioritization Chad mentionned in 2015 is apparently not a thing anymore, and the Roadmap page was not updated since 300d+. Can I guess it means users can't have more visibility on this than the entry's status itself? Or did I miss a valuable page? It's always nice to get an idea of when an expected feature will be done, even roughly.

There is no secret tracker with a different set of priorities or timelines
for features. Everything we plan is 100% open. This feature is not on any
short or medium term roadmap and you can read Planning for more
information on how we build the roadmap. We do plan to offer paid support
soon which will let installs prioritize features they need.

Thanks for the reply @chad.

+1 that this is really needed.

FYI to everyone, looks like this feature is on the starmap.

The other side of the status-column relationship is also needed btw for a decent workflow: T6409

@kislinsk Is it possible to externalize your solution? I have no information about the status of Phabricator supporting extensions but when there is a way to separate your solution from the core cleanly, why not creating a repository on GitHub? I would love to use this right now! :D

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

1. By dragging it on a workboard.
2. As part of a bulk move via Move Tasks to Column... on a workboard.
3. Via the Move on Workboard action in the comment area.
4. Implicitly, by adding a project tag, to put a task in the "Backlog" column.

For now, I'm only going to make method (1) activate triggers. I'm probably going to prevent triggers from being attached to the "Backlog" column to make it more clear that method (4) does not work and does not activate triggers.

The general idea is that triggers are a convenience, not a strict workflow constraint. You can always put a task in a state which violates triggers in these ways:

• Drag a task to a column, then edit it with the "Edit" workflow or API.
• Drag a task to a column, then edit it by dragging it to some contradictory column on some other board which it's also on.
• Drag a task to a column, then edit the triggers for that column to imply some other state.

That is, when you apply some kind of edit to an object, we aren't going to check that the edit conforms to all the triggers in all the columns the object is present in. I think this would often be a confusing mess with no way forward, and it would make certain flows fairly absurd, e.g.:

You can not add a "Change Status: Resolved" trigger rule to this trigger ruleset because the ruleset is used by one or more columns which have one or more tasks in that are currently also in columns on other boards which have contradictory trigger rules. For each column in conflict: change the trigger rules; or remove all the conflicting tasks from the column; or remove all conflicting tasks from other conflicting columns so that they are no longer in conflict. Resolve all conflicts to continue.

Board	Column	Task	Conflicting Board	Conflicting Column	Conflicting Ruleset	Conflicting Rule
Engine	Done	T123: Yorble a Florble	Engineering	In Progress	Triggers 38: Engineering Triggers	Change Status: In Progress
...	...	...	...	...	...	...

I want to avoid having this kind of state in the product. I think users making reasonable use of this feature will never really hit this (tasks won't be on multiple boards with multiple conflicting states), and users who do hit this are likely to prefer that the operation just works over being handed a quest to slay 90 state conflicts.

Strict constraints would also make it easy to set things up so that a particular drag is impossible, by putting a task in a "Change Status: X" column on board A, then trying to drag it to a "Change Status: Y" column on board B.

In the future, we could improve the ability of triggers to act as a soft constraint by highlighting cards that are not in a state consistent with the column trigger while you're looking at the board. For example:

• You drag a task to a "Change Status: Resolved" column, which resolves it.
• You manually edit it to reopen it.
• On the board, it shows in red to indicate that the task state is currently inconsistent with the column triggers.

At least for the moment, I'm not planning to make methods (2) or (3) apply triggers, although method (2) probably should. I'm less sure about method (3). A naive implementation seems bad and an integration integrated with the action stack seems complex.

I'm currently planning to store trigger rulesets as a separate object with a PHID. I think there are probably two reasonable ways to bind triggers to columns, and we may implement either one or both:

• Each column has its own TriggerRuleset object. When you copy columns from an existing workboard, the triggers are also copied into a new TriggerRuleset. Although these are separate objects, they mostly act as though they are properties of the column.
• Each column references an external TriggerRuleset. Multiple columns can reference the same ruleset. When you edit a ruleset referenced by multiple columns, all referenced columns have their behavior updated. A "Copy and Edit Ruleset" option allows you to edit a copy of a ruleset.

These are both pretty similar in terms of what we have to implement. The former approach is probably generally better if rules are simple (e.g., close tasks dropped here) since it means fewer clicks when managing ad-hoc rules. The latter approach is probably better if rules are complex, since it means fewer clicks when managing rules shared across multiple columns.

I could imagine that 95% of usage might go either way. We could simplify the implementation somewhat if I was confident that the simple approach is sufficient (e.g., rulesets would only need to know about one parent column, not multiple potential parent columns), but I strongly suspect (?) it probably (?) isn't.

I think I'll probably implement the complex case first, and then expect to implement the simple case unless feedback suggests that the complex case covers 95% of things already.

Under the complex case, rulesets need their own "Editable By" policy. (In the simple case, we could bind them to the edit policy of the project, since we know they are bound to only one column.) This is fairly straightforward, although we may need to adjust it when copying a ruleset.

I'm inclined to make them globally visible, similar to Herald rules. Users who can see any project a rule is used in must be able to see the rule, and hiding rules selectively means that transaction records sometimes become more mysterious (we can't "Explain Why" and link to a trigger rule if the user can't see the triggers).

This harms use cases like naming a ruleset "My Boss is A Big Jerk Who I Do Not Like Very Much" or putting a lot of sensitive operational details in a "Show Instructions: ..." rule, but these seem like a small loss, and we've survived a similar change from semi-private to public in Herald uneventfully.

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

Wouldn't it detangle a lot of complexity to handle triggers more like actual triggers compared to continuous states, though? If I understand the text above correctly, it seems like you try to continuously ensure a certain task state that is expressed by a trigger rule while the task is in the column. That's something I would be surprised when editing tasks and suddenly there is some "invalid state". My personal natural understanding of triggers is a one-shot action instead of a continuous state. Something that happens *when changing* the column of a task and I can forget about this afterwards. I guess that would also unify the handling of at least (1) and (3).

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). Is this expected / intentional?

Yes.

In T5474#245062, @epriestley wrote:

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

1. ...
2. As part of a bulk move via Move Tasks to Column... on a workboard.
3. Via the Move on Workboard action in the comment area.
4. ...

...

At least for the moment, I'm not planning to make methods (2) or (3) apply triggers, although method (2) probably should. I'm less sure about method (3). A naive implementation seems bad and an integration integrated with the action stack seems complex.

Got it, thanks for clarifying.