Bunty wrote: Dispostion is to be driven by a custom date field (myDateField) which is entered during checkin of content item.
Bunty wrote: Now, for the items with (currentDate - myDateField) = x yearsSo is statement 1 ("Dispostion is to be driven by a custom date field (myDateField) which is entered during checkin of content item.") or statement 2 ("Now, for the items with (currentDate - myDateField) = x years") the correct behavior? These statements are not equivalent. In statement 1, you are saying the custom date is the sole driver. In statement 2, you say a calculation must occur first. You might being getting the disposition "wait" period mixed up with the triggering event. These are two different things, and defined in different parts of the overall disposition.
I can't, x is not constant.
I think the way you'd probably need to do this is to simply have a multi-phase disposition defined. Create a new trigger called "After CustomDate". In the content date field, add xCustomDate. This will cover the latest revision.it also covers the revisions that are not latest. Correct me if I am wrong.
Bunty wrote:it also covers the revisions that are not latest. Correct me if I am wrong.This is the easiest part of the discussion. In the multiphase scenario I posted earlier, the first event that is satisfied in a category disposition instruction set is the event that is executed. Think of a multiphase instruction set as a series of decision paths. The processing goes down the path of the first event that is satisfied. It doesn't "complete one path, then jump to another path", so setting "No Action" for items that are "not the latest revision" will just sit there until the latest revision of the item (whatever that rev number is) triggers the xCustomDate trigger. The event for xCustomDate is ignored on the older revs, and is technically in force only on the latest revision.
Bunty wrote:Wait for: x years from Custom Date field of "latest revision".And the multiphase disposition setup I described earlier behaves in exactly that manner. No extra data manipulations needed (or extra hidden/phantom fields). The "latest revision" is subject to the xCustomDate trigger event until a new rev is checked in (UNLESS you fail to check in a new rev PRIOR to the xCustomDate value of the previous rev.) Using the example from earlier, if you were to create rev 3 on 8/1, you would be too late to prevent the action tied to xCustomDate on rev 2.