Scheduled Publishing#21

Allow users to specify a date & time on which the entry is toggled into a “Published” state.

It would make sense to have the same for unpublishing then.

See my comments on #19 , as these two are more related than you might think.

Also, and I know this complicates things, but I’d suggest you at least discuss decoupling workflows from any specific concept like Draft vs. Published. If it were me, and I wanted a robust framework for handling workflows, I’d implement this under the hood using a finite state machine model. The initial implementation might just be Draft/Published, but you’d set yourself up for future features where customers could define custom workflows with arbitrary states (I’m looking at you, @Ambroise Dhenain ).

If you want to see a great example, look at the Workflow Plugin for Foswiki. You define a state table that lists the possible document states and allowed edit/view roles for each, and a transition table the defines how to move between states, what roles can perform those transitions, and what actions are triggered at transition time (think webhooks or other triggered events).

Beyond states and transitions, Foswiki also supports attaching different forms at different states, effectively allowing you to transform the schema of a document as it moves through a workflow. In the past I’ve used that to add new fields to a document, like a “reason why this was rejected” text field when an editor sends a document back for more revisions. That transition also triggered a custom email alert along the lines of:

<EDITOR_NAME> rejected <DOCUMENT_TITLE> for the following reason: <REASON_REJECTED>. Please [login](<DOCUMENT_EDIT_LINK>) to resolve the issue.

Okay, that last bit is super scope creep, but it gives you an idea of how folks use systems like that in the wild.