Triggers do seem like some sort of global Herald rules but limited to a specific column in a workboard. As such, Triggers should probably not be made avalaible for all users for obvious reasons. I suggest that they be restricted to Trusted-Contributors or some ad hoc acl*, at least; if that's an option.

Tested the Triggers on T150807#5307526. The trigger seems to be executed under the person's account that moved the card to the column which has a trigger enabled, so it does not seem it involves Herald. Still unsure if, as @Aklapper mentioned above, this means a performance cost.

N.B.: For some reason https://phabricator.wikimedia.org/project/trigger/3/ is marked as unused when I've kept it enabled.

Triggers currently only activate when a task card is dropped into a column with triggers (see this comment for details). They don't impose a global performance cost like Herald, and act on behalf of the user moving the card.

The "Used by Columns" table on the trigger detail page is updated by the search engine indexer, which runs in the background, so it may not immediately reflect reality after a change (usually it shouldn't take more than a minute or so to update, though). At time of writing, it shows trigger ID 3 as used for me, which I think is the expected state:

Adventurous users shouldn't be able to do too much damage by creating silly (or even malicious) triggers, unless you have some complicated chain of events like this:

• Alice, an unprivileged user, creates a trigger like "Assign to: Alice" on the "Alice Things" workboard when tasks are dropped into an "Alice's Stuff" column.
• Bailey, a privileged user, views the workboard and drags a sensitive task which appears on this workboard into the "Alice's Stuff" column.
• Dropping the task into the column assigns it to Alice and gives her permissions on it (as the task owner) which she would not normally have.

Triggers show a preview of what they'll do in the lower right corner of the screen, so you can check that before moving tasks if you aren't sure what effects will occur. There's also normally no reason that a sensitive task would be tagged with "Alice Things" or a privileged user would have a reason to move it to "Alice's Stuff" (although, in this scenario, Alice could conceivably choose deceptive names for the project and column), so I think this is fairly unlikely to cause problems, but maybe I'm being optimistic. If this specific workflow is an issue, we could perhaps add a prompt asking the user to confirm that they want to take an action which will increase the scope of a user's permissions. This is generally consistent with plans upstream in https://secure.phabricator.com/T4411.

The other trigger actions available today can not normally cause any surprising side effects (like affecting view or edit policies), although custom extensions could complicate the situation.

[bulk] Setting points to "", given it doesn't make any sense to have them as "0".

Documentation is going to be useful, I was thinking "why I don't see it in User-Urbanecm". I wanted to make a rule "when a task is dropped into Backlog column and has xx project, move to yy column", but given this doesn't have support for sub-conditions nor moving tasks to a column, it doesn't help :/.

In T227300#5307525, @MarcoAurelio wrote:

Triggers do seem like some sort of global Herald rules but limited to a specific column in a workboard. As such, Triggers should probably not be made avalaible for all users for obvious reasons. I suggest that they be restricted to Trusted-Contributors or some ad hoc acl*, at least; if that's an option.

Strong +1. Can @Aklapper as a Phab admin do that in Maniphest configuration?

In T227300#5456702, @Urbanecm wrote:

In T227300#5307525, @MarcoAurelio wrote:

Triggers do seem like some sort of global Herald rules but limited to a specific column in a workboard. As such, Triggers should probably not be made avalaible for all users for obvious reasons. I suggest that they be restricted to Trusted-Contributors or some ad hoc acl*, at least; if that's an option.

Strong +1. Can @Aklapper as a Phab admin do that in Maniphest configuration?

I tried to make a trigger at https://phabricator.wikimedia.org/project/trigger/2/, and I couldn't get it to work - I understand that triggers shouldn't be available to everyone, but if someone can get trigger 2 to work I'd be grateful

In T227300#5456702, @Urbanecm wrote:

In T227300#5307525, @MarcoAurelio wrote:

Triggers do seem like some sort of global Herald rules but limited to a specific column in a workboard. As such, Triggers should probably not be made avalaible for all users for obvious reasons. I suggest that they be restricted to Trusted-Contributors or some ad hoc acl*, at least; if that's an option.

Strong +1. Can @Aklapper as a Phab admin do that in Maniphest configuration?

I recommennd #traigers through. They already have some functionality, and this isn't too irrelevant.

In T227300#5456717, @DannyS712 wrote:

In T227300#5456702, @Urbanecm wrote:

In T227300#5307525, @MarcoAurelio wrote:

Triggers do seem like some sort of global Herald rules but limited to a specific column in a workboard. As such, Triggers should probably not be made avalaible for all users for obvious reasons. I suggest that they be restricted to Trusted-Contributors or some ad hoc acl*, at least; if that's an option.

Strong +1. Can @Aklapper as a Phab admin do that in Maniphest configuration?

I tried to make a trigger at https://phabricator.wikimedia.org/project/trigger/2/, and I couldn't get it to work - I understand that triggers shouldn't be available to everyone, but if someone can get trigger 2 to work I'd be grateful

Can try, could you add me, or acl*Batch-Editors to the edit policy?

In T227300#5456717, @DannyS712 wrote:

In T227300#5456702, @Urbanecm wrote:

In T227300#5307525, @MarcoAurelio wrote:

Triggers do seem like some sort of global Herald rules but limited to a specific column in a workboard. As such, Triggers should probably not be made avalaible for all users for obvious reasons. I suggest that they be restricted to Trusted-Contributors or some ad hoc acl*, at least; if that's an option.

Strong +1. Can @Aklapper as a Phab admin do that in Maniphest configuration?

I tried to make a trigger at https://phabricator.wikimedia.org/project/trigger/2/, and I couldn't get it to work - I understand that triggers shouldn't be available to everyone, but if someone can get trigger 2 to work I'd be grateful

It works? See T231735.

In T227300#5456747, @Urbanecm wrote:

In T227300#5456717, @DannyS712 wrote:

In T227300#5456702, @Urbanecm wrote:

In T227300#5307525, @MarcoAurelio wrote:

Triggers do seem like some sort of global Herald rules but limited to a specific column in a workboard. As such, Triggers should probably not be made avalaible for all users for obvious reasons. I suggest that they be restricted to Trusted-Contributors or some ad hoc acl*, at least; if that's an option.

Strong +1. Can @Aklapper as a Phab admin do that in Maniphest configuration?

I tried to make a trigger at https://phabricator.wikimedia.org/project/trigger/2/, and I couldn't get it to work - I understand that triggers shouldn't be available to everyone, but if someone can get trigger 2 to work I'd be grateful

It works? See T231735.

It only works if you drag it on the workboard - if you use the 'move on workboard' option it does nothing. That is what I missed. Is that the intended behaviour?

I guess so, I'm not a phabricator dev, so can't say with certainity. PS: Explain "not work" when reporting broken stuff in the future please, it could save debug tasks, among other things ;). Thanks,

if you use the 'move on workboard' option it does nothing. That is what I missed. Is that the intended behaviour?

For now, it's expected, yes. I'm potentially open to changing it, but if it does change, I think the UI needs to make it clear what the trigger effects of your "Move on Workboard..." action will be -- something like this:

[ Add Action...  V ]

    Move on Workboard: [ Skunkworks • Done ]
       /!\ Column trigger will take these actions:
           - Close task as "Resolved".
           - Play sound "Fanfare".

+-----------------------------------------------------------------------------+
|                                                                             |
|     <Your comment goes here.>                                               |
|                                                                             |
+-----------------------------------------------------------------------------+
                                                   [ Set Sail for Adventure ]

This is somewhat complicated to implement, and kind of a mess if you've already selected a conflicting action, like a different status change. We should probably respect your explicit choice of some other status, but then also need to indicate that the trigger would resolve the task, but won't because you've explicitly selected a different effect. Since this is messy and it wasn't obviously-high-value to me, it's not part of the initial implementation.