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.

If both are inside Herald, they would be close to each other and the bug would disappear.

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 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 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".

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.

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

@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.

In T15043#1246, @TitanNano wrote:

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

Indeed.

Should we limit it to one column per type for each workboard?

Probably, yes.

A column type would be a new entity, I guess? How do we create a new column type? Or is a type just something we can configure in the Config application, like task statuses?

This seems reasonable to me.

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".

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.

One additional thing to account for though is when a projects columns are updated or changed, which would invalidate rules. Or is this why the idea of adding types to columns is being investigated? Even with types I think we would have issues where boards might not have a column with that type or have multiple columns of that type?

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.

Making this an object rule is not possible as it has to be a Maniphest Task rule, which do not support object rules.

In T15043#1251, @speck wrote:

One additional thing to account for though is when a projects columns are updated or changed, which would invalidate rules. Or is this why the idea of adding types to columns is being investigated?

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.

In T15043#1251, @speck wrote:

Even with types I think we would have issues where boards might not have a column with that type or have multiple columns of that type?

If no column with the specified type exists, then nothing will happen. We should limit each type to only be assignable to one column per board. If there are somehow more than one column of a type, we probably have to default to the first column found. My current idea of this herald action is "Try to move this task into a column of type x on each project board".

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.

If no column with the specified type exists, then nothing will happen. We should limit each type to only be assignable to one column per board. If there are somehow more than one column of a type, we probably have to default to the first column found. My current idea of this herald action is "Try to move this task into a column of type x on each project board".

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"?

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"?

I like this approach, but also see complications. We would have to also create new project conditions for task changes, that shouldn't be a problem, it's just a bit more work. The bigger problem is that we would want to apply our herald actions to the changed task and not the target project. As far as I know, herald currently only can modify the current rule target, so task rules apply actions to tasks, commit rules apply to commits, revision rules to revisions and so on. We would also introduce a dependency between the condition "a task status changed to x" and the action "move the changed task into column x", which is also not something Herald does at the moment, I think.

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.

Honestly, if the UI gets a sorted select box, or even something dynamic that allows selecting a project first and a column second, this shouldn't be too bad to handle for most instances.

If no column with the specified type exists, then nothing will happen. We should limit each type to only be assignable to one column per board. If there are somehow more than one column of a type, we probably have to default to the first column found. My current idea of this herald action is "Try to move this task into a column of type x on each project board".

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"?

I personally think "column types" makes the whole concept more complicated than it is right now. Currently in Phabricator, when I move a task from one column to another, the rule gets triggered. It makes the rules ultra simple to work with and creating them very intuitive. The idea of having a rule that globally applies to all projects seems like it would create side-effects on projects that were not intended for that. I understand that having to create rules for every single project can be labor intensive, but the mechanism would be kept straightforward.

For example, I have a column called 'ready for testing' in two projects with different clients. When I move a task into the appropriate column, the QA person that the client assigned will get assigned the task. If I could assign those globally I would be causing side effects (the QA person of another project would be assigned). I think that a feature that causes side effects is better avoided, since we otherwise would have to provide mechanisms to deal with the side effects.

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#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.

Yes, definitely.

Agreed!

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

And, in order to solve the original issue here (multiple projects)

How about a herald rule that says //If Project is like X AND project has Y workboard, then add Herald Rule 123 for that project -

This would take some work too, but, it would allow you to automate that addition of Herald rules to new or existing projects based on conditions...

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

Because tasks can belong to multiple projects they can exist on multiple workboards. The trigger seems to fit cleanly in the Maniphest Herald Rule but the action is very specific to the project and is hard to express. Because the action is so specific to a project is what makes me lean more towards having supporting this as a Project Herald Rule (object-level).

• Level: Object (specific project Y)
• Trigger: When a project task's status is changed
• Move the task to column X

This makes the trigger more specific but it seems reasonable to me.

Alternatively for the Maniphest Herald Rule we could create some new selector widget for selecting a Project and Column for the action. Though in this scenario it feels like there should also be a further condition required: "when a task's status is changed AND the task has project Y", but that further constraint wouldn't apply to the trigger -- to my knowledge this isn't supported as it starts to move herald rules into "scripting language" territory (which would be kinda cool, eventually...)

Separately from the Herald setup we'll also want to include addressing these behaviors:

1. In most cases objects don't get deleted instead they're usually archived. For workboard columns those can be outright deleted though - what should happen to a Herald rule which is constructed specifying a column and then the column is later deleted?
2. There was something else but it's slipped my mind :c

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

In T15043#1618, @20after4 wrote:

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

yes, that is true. I'm not certain if they can be deleted via the CLI tool, though.

(I agree that internally, the Herald rule should be saved as a Global Task-based. And I agree that it should be easily added and edited from the Workboard. I think that, in the future, this still need the Project Tag to be saved internally - as a kind of Object rule - so that, in the future, it will allow a more efficient query to find all global Herald rules without a Tag + all global Herald rules that are assigned to a Tag where that Tag is IN the list of Task's Tags.)