Reordering milestones is convenient when you want to treat milestones as workflow steps rather than sequential numerical versions.

In T15082#2028, @golyalpha wrote:

epriestley was very much against this idea but wikimedia's users loved it.

Do we have epristley's reasoning as to why he was against this? Might help in deciding about including this patch in Phorge.

epriestley was very much against this idea but wikimedia's users loved it.

In T15043#1618, @20after4 wrote:

I didn't know columns could be deleted... I thought they were only ever hidden.

I didn't know columns could be deleted... I thought they were only ever hidden.

Expressing the desired behavior here seems difficult to fit into Herald.

• Level: Global
• Trigger: When a task's status is changed
• Action: Move the task to a different column X on project Y

The Herald rule should be project specific. If X happens then move task to Project->Column

In T15043#1258, @CSharp wrote:

Maybe the "move to column" rule should only apply if the task is already assigned to the project, if it isn't, it gets ignored.

In T15043#1256, @speck wrote:

Making this an object rule is not possible as it has to be a Maniphest Task rule, which do not support object rules.
My main reason to explore this, is that without column types, we can only create rules like this "If task status changes to complete, then move task into column DONE in Project A.". Which means we have to create this rule for every project. In the rule builder UI we would also have to load a list of all project boards and their columns, which could be quite a few. The herald rule doesn't know with which project a task will be connected.

Ah okay - I was thinking this would be a Project rule rather than Maniphest, which would allow it to determine what possible columns can be used in the rule/action definitions.

In T15043#1256, @speck wrote:

I think this will work out technically but it feels a bit nebulous to me, in that the rule isn't really clear about what it's doing as it's very dependent on the project workboard that gets triggered. For example some workboards might be roadmaps/planning and want to have columns for e.g. inbox, backlog, next_version, etc. but other workboards might be categorical in nature rather than planning and there would be no overlap between what column types exist on those boards. I think a solution revolving around Project-based rules should be investigated - for example is it reasonable/possible to have a herald rule on a project that says, "when a task on this project board changes status to: x, then move to column y"?

Making this an object rule is not possible as it has to be a Maniphest Task rule, which do not support object rules.
My main reason to explore this, is that without column types, we can only create rules like this "If task status changes to complete, then move task into column DONE in Project A.". Which means we have to create this rule for every project. In the rule builder UI we would also have to load a list of all project boards and their columns, which could be quite a few. The herald rule doesn't know with which project a task will be connected.

Ah okay - I was thinking this would be a Project rule rather than Maniphest, which would allow it to determine what possible columns can be used in the rule/action definitions.

In T15043#1251, @speck wrote:

Maybe the herald rule should only apply to specific objects? I think there’s a concept like this already where certain rules can only be made at the object level and not global level, possibly for similar reasons.

In T15043#1244, @TitanNano wrote:

I started to implement this as a new herald action. There is just one major problem. I would have to load all columns from every project and present them to the user. A user could then select one specific column of one specific project for his herald action... This seems kind of pointless to me. It's way too specific to be usable.

I think we first need some way to target project columns in a more generic way. If columns had a type, like "backlog" or "in_progress", then we could say, move this task on every related workboard into a column of type "in_progress".

In T15043#1246, @TitanNano wrote:

Just having a dropdown here would be enough, I guess?

Indeed.

@TitanNano: One way to store the type, without changing any schema, would be to drop it into the metadata json blob which columns already use for recording which column is the 'default'. Unfortunately that isn't the most convenient thing to query, however, it's not that bad thanks to mysql's json functions.

Just having a dropdown here would be enough, I guess?

It wouldn't be too hard to add a type to columns but we'd need a way to set the type from the UI somehow.

I started to implement this as a new herald action. There is just one major problem. I would have to load all columns from every project and present them to the user. A user could then select one specific column of one specific project for his herald action... This seems kind of pointless to me. It's way too specific to be usable.

I also agree that #3 seems promising. FWIW it's incredibly easy to develop new herald actions and as long as the current herald rules do the thing you want to do then the action would be very straightforward. Maybe the usability would be improved by exposing the rules that affect a board through the workboard UI instead of having them scattered around random and disorganized herald rules in the herald ui?

I agree with @CSharp that option 3 is probably the best approach here. It looks like on https://secure.phabricator.com/T6409 the initial request was that items get automatically moved based on state change and the main pushback is against the design of an approach like 1 or 2. I think setting this up utilizing Herald makes sense though. I wasn't aware that triggers/transactions weren't fired from both locations though. That might be a bit involved.

I would support using approach number 3 and actually consider moving the triggers into Herald in the long run. Triggers are only dispatched from Javascript when moving the items on the board, but moving them within a task using the "Add action..." dropdown does not trigger them.