Workflow vs Triggers

(Douglas (@finnatic at @waikato)) #1

I'm considering a trigger to make certain assets (images + thumbnails) live in a section of a site where we have workflow applied to support a split author / editor&approver setup.

 

http://manuals.matrix.squizsuite.net/triggers/examples/configuring-a-trigger-to-set-an-asset-live-upon-creationcalls out that triggers + workflow aren't always a good combination:

 

"You won't be able to use triggers that automatically set the status on assets that have workflow applied. You will need to either select to not include these trigger types, or to not have workflow applied to these areas of your system."

 

Does anyone have any tips or tricks on getting the trigger to work when workflow is in effect?

(Talk) #2

Hey mate, have you tried using the trigger to set the status to approved to go live, and then to live, so two actions instead of one?

(Douglas (@finnatic at @waikato)) #3

Ok, so that might be an option - have a trigger setting the 'approved to go live' status - with the second trigger in the process, any thoughts on what's the best trigger action to use - after 'workflow approval' or 'status changed' ?

(Tim Davison) #4

It depends at which point you want to make it live.  

 
We have a trigger that removes the workflow (and then denies it) and then sets a future status to make it Live at the next run.  
 
We also have a trigger that sets things live when all workflow approvals have completed.
 
But if you are wanting to leave the workflow in place, in other words have the trigger carry out workflow steps, then no - haven't tried that before.  I'd assume you could set it's status to 'Approved to Go Live' and ignore permissions - system should be able to do that auto-approve thing it does, but you'd possibly have to add 'Root User' to every step in your workflow.

 

EDIT: I just saw other responses.  I know you'll have problems with any Trigger action that sets a status coming from a Status Changed event.  That typically doesn't work at all - you will need to use a future status.  And that would mean setting 2 future statuses in the same trigger, making sure they are separated by sufficient time for the previous one to run (pray for no deadlocks) or, which would be my preference, a second trigger.  So first trigger gets it to 'Approved to Go Live'.  Second trigger runs when it hits that status - but you'd probably want a condition that it's the root user that initiated it.

 

If you're wanting things to go live as soon as they are created, use 'Asset Created' event.

(Douglas (@finnatic at @waikato)) #5

Thanks, Tim.  We could possibly remove the workflow and I'll consult about whether we can do that.  In the mean time:

 

1) I've got two triggers for the images, one which approves it to go live on creation + another that sets a future status of live.  That second trigger works fine.

 

2) I've also created a trigger that sets pages to go live when workflow is approved, but it's only making the pages live when I execute the trigger via the Batching screen of the Trigger Manager - in which case it works fine and without any errors.  I'm approving the pages in both the back end and via edit+ (and suspect I'll need a second trigger for that).

 

Trigger is:

Event - after workflow approval.

Condition - Tree location - where the asset is

Condition - Asset type - page (inherit)

Action - set status to live, ignore permissions, action on asset + children.

 

Any thoughts why it works when batched but otherwise doesn't?  Have I missed something with the event / conditions?

(Tim Davison) #6

'After workflow approval' may not be the event you want (unless you have a single-step only workflow).  It will run any time someone approves a workflow step, not just when all workflow steps are completed.  If it *is* a single-step workflow then your 'after workflow approval' event will also be encapsulating a status change (from pending to approved).  You'll be running into the issue of you cannot set asset status while the asset status is changing.  I'd be guessing, but when batching it's only simulating the event, so the asset status isn't actually changing, but in 'real life' you're glitching on the asset status change.

 

How I've set up the auto-live trigger is:

Event - Before status change (*I only use the before event because it allows you to pick multiple statuses in the 'being changed to' condition - otherwise you could just use status change)

Condition - tree location, page, etc etc

Condition - asset status being changed to = approved to go live / safe edit approved to go live

Action - Set future status to Live at next run

 

It's not instant-live, though.