I have been trying to get our Squiz 5.1.3.0 system to automatically put pages up for review when a metadata date field value is before the current date.
The metadata field has a display format of:
Y-m-d 23:59:59
The trigger appears to work sometimes, which makes it even more frustrating.
Below are a few screen shots showing my setup, if anyone has any pointers I would really appriciate it.
Thanks
screenshots.pdf (1.18 MB)
I don't think the offset works like you think it does. I've had the same issue, and the problem is the trigger will look at the raw date, i.e. before doing the offset calculation, not the resultant date. This may also explain why the trigger appears to sometimes not run. You should find all the really old dates are running but more recent ones are not. It's really frustrating as if it did the way we wanted then some things would be so much simpler.
How I solved this in my case was not use offset at all, and I had to create another trigger to set the date when a certain event takes place, in your case looks like you are trying to get 183 days after an asset is updated. So the trigger will be:
Event: asset updated
Condition: <whatever limitations you want>
Action: Set metadata field Disposal Review Date to current date + offset 183 days
(yes, I'm using the word 'offset' again. In this case the offset on the trigger gets applied immediately, so the date stored in the metadata field is the correct one).
Then your second trigger, I'm assume you've already set up, is a metadata time trigger acting from Disposal Review Date.
Note: many instances I have seen where up for review processes are following use future statuses to set to Up for Review. This initially looks ideal as it reduces the number of triggers back down to 1. However, it's relatively unmanageable, e.g. the future status job will still try to run even if the asset is already Up for Review, or archived, or any status. So you end up creating additional triggers to strip out these future status jobs for a myriad of conditions. In the end it's more complex. With a metadata time trigger you can disable it easily, and when you next turn it on it will go back and catch all the ones you missed.
Note 2: Also be careful using asset updated as your basis for the review date. Assets get updated far more frequently than you might think, and not just from contents. E.g a metadata change, a metadata regen, changing to Safe Edit and then cancelling back to live, and even things as basic as assigning permissions or roles, will result in the asset updated. Asset updated can literally mean the review date is perpetually pushed out from basic admin tasks on the instance, some assets may never go up for review. In my systems I use 'asset published' instead. There are edge cases that will be missed, such as making changes direct to live, but this is a no-no in our system anyway (publishing is tied into our records mgmt system as well) and publishers do so at their own risk.
Note 3: (last one I promise) I've also been very un-thrilled using the Up for Review status at all. Technically Up for Review is a workflow state, and may work for some systems but I've found it to create some very significant issues. Currently I'm working on a proposal, still testing it, where Up for Review is flagged in a metadata field instead, and we never use the Up for Review status. This approach will simplify our workflow and avoids the issues of the Up for Review status.
Thanks Tim for your detailed response, I will try what you have suggested, it sounds like you have spent a fair amount of time researching the problem.
How do you get the trigger to fire? Can it be done after the asset has been on the system for awhile? Mine isn't working either
Check under Scheduled Jobs Manager > Metadata Triggers Scheduled Job > Options.
Use Last Run should be No and make sure the Minimum Date is set far enough in the past to capture your oldest assets. If it's set too soon, and you have assets that are older, or the metadata field is older, then it won't be picked up by the trigger.