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.