Remove Embargo & Expiry feature from codebase. Add support for external module

[chrispenny]

The Gist

Remove the Embargo & Expiry feature from code base, and add support for external Embargo & Expiry module.

The Embargo & Expiry module already supports the Fluent module.

WorkflowEmbargoExpiryExtension.php

The DB fields between Advanced Workflow and Embargo & Expiry match, so they should not require any "migration", so long as devs apply the EmbargoExpiryExtension to the same model that previously had WorkflowEmbargoExpiryExtension.

Migration dev task

The DB fields above are fine, but if the site already has some existing jobs from this module, then those will need to be migrated to jobs from the Embargo & Expiry module.

EmbargoExpiryMigrationTask has been provided for this.

Below are the tests I went though. I started with Workflow's Embargo feature, and I then switched to Embargo & Expiry, ran a dev/build plus the above dev task. Below indicates the "state" that the page was in when I switched modules. Each page remained in the desired state after the migration.

• Page with no workflow saved with E&E: Expected Jobs to be created
• Page with workflow saved (but not submitted) with E&E: Expected no Jobs but saved "Desired" dates
• Page with workflow submitted (but not approved) with E&E: Expected no Jobs but saved "Desired" dates
• Page with workflow submitted and approved with E&E: Expected Jobs to be created

Before:

After:

How we're doing it

Embargo & Expiry provides an extension point (preventEmbargoExpiryQueueJobs ) which can be used to interrupt to queueing of Jobs when a record is saved.

If a DataObject has a Workflow applied, then we want to interrupt Job creation so that we can first go through the approval process. Once the process is completed, and the "Un/Publish" action is triggered, then we can queue the Jobs.

PublishItemWorkflowAction.php & UnpublishItemWorkflowAction.php

When either of these actions are submitted, we check for the existence of the required Extensions as well as any Desired embargo/expiry dates. If some are found, then we queue up the appropriate Jobs, rather than publish/unpublish at the time of the actions trigger.

Delay action fields

When publishing, if the Action has a PublishDelay, then we will queue up that PublishDelay as an embargo date. This will override any DesiredPublishDate that might have been set.

Similar process for unpublishing and the UnpublishDelay.

WorkflowPublishTargetJob.php

Removed. No longer required as this process is taken care of by Embargo & Expiry module.

WorkflowEmbargoExpiryTest.php

Updated to only cover the areas that this module is now interested in. Which is to say, that the module now only needs to care that Jobs are correctly created (or not created) when approvals are made.

[ScopeyNZ]

The PHP support question is a good one. I personally feel like we should be able to release a major version of this module after June and set a minimum version of 7.2. That's just my opinion though 🙂

I haven't checked this out locally for testing just given it a quick once over on the code.

[chrispenny]

Thanks, @ScopeyNZ!

Sorry that took me forever. This is my first hackday since my hiatus.

[chrispenny]

Is it worth me picking this up again?

The original blocker isn't an issue any more, but I would need to see where I've taken Embargo & Expiry in the last few years to make sure things are still compatible.

[chrispenny]

Hi team,

This pull request has been updated to match the current state of both modules. I wasn't sure if this should target 5 or master. master looks to be very far behind.

I would leave it up to you to decide (of course), but I'm guessing this would need to be a new MAJOR. The DB fields themselves map fine, but existing Jobs needs to be migrated. I've provided some documentation and a dev task for folks to do that.