The attached patch allows users to schedule workflow changes for a later time. Every workflow change is now accompanied by a radio box with:
() Immediately
() Scheduled state change at:
[Year] [Month] [Day]
[HH:MM]

If the user selects the scheduled option, the state change is placed into another table. When cron runs, this table is searched for entries that require scheduled transitions. If any are found, the node is loaded and the transition is applied.

At any time before a transition occurs, a user can edit a node's scheduled time, including changing to an immediate change.

This patch makes workflow behave similarly to two other modules. Here is why this patch is different:

1. Scheduler.module: This module works with the old-school drupal workflow of status = 1 or status = 0. It also sets a time to publish and a time to unpublish. While there are some patches in the scheduler queue to integrate with workflow, I believe the UI for this is confusing (when combined on top of workflow) and the concept of going from state 1 to state 2 and back to state 1 may not be valid in all workflows. This patch simplifies the goal of scheduling workflow changes by placing all the relevant information close in the AI and making workflow more cognizant of scheduling changes.

2. Action Scheduling Actions: This module creates a wrapper action that can schedule another action. Eg. one could create a wrapper around "Send email to administrator" with a time of "2 weeks". Once initiated this action will be set to occur in two weeks. ASA could emulate a scheduled workflow by using the "move to next state" action or "move to an arbitrary state" action (which I believe is in the issue queue). Again, I think the UI would be confusing. Moreover, having actions move workflow seems backwards to my mind. Better to have workflow incite actions in most cases.

That said, I do think there is a valid place for ASA, just not as the scheduler of workflow state changes.

This patch introduces a dependency on cron. I think that most sites already require cron, so this is a minimal cost.

This patch has been tested to work from both the node edit form and the workflow tab form.

Thanks for reviewing,
-Mark

CommentFileSizeAuthor
#6 workflow_scheduling.20061227.patch13.52 KBmfredrickson
#2 workflowscheudling.datefix.patch20.96 KBmfredrickson
workflow.scheduling.patch11.95 KBmfredrickson

Comments

mfredrickson’s picture

mfredrickson commented

I just noticed this patch fixes a problem where the workflow tab and the "move to next state" action wouldn't work together. I suspect it's because I rewrote the tab save function to use node_save().

Yay for unintended bug fixes.

-M

mfredrickson’s picture

mfredrickson commented
StatusFileSize
new workflowscheudling.datefix.patch20.96 KB

I found 2 small bugs in my timestamp handling code. I've corrected and rerolled the patch.

-M

moshe weitzman’s picture

moshe weitzman commented

the update page just said "Failed" after updating. the tables do seem to get created fine, but i note that the workflow history records don't seem to be getting written.

mfredrickson’s picture

mfredrickson commented

The "failed" is because I used db_query instead of update_sql. I thought I had fixed in that in the second patch. Arg.

I'll review the second issue and repost the patch with a fix for both.

moshe weitzman’s picture

moshe weitzman commented

it is possible that the lack of workflow history is my fault. i noticed that my table differs slightly from core. fyi.

mfredrickson’s picture

mfredrickson commented
StatusFileSize
new workflow_scheduling.20061227.patch13.52 KB

Attaching an updated version of the patch.

This patch works against current 4.7-1.x-dev.

It fixes the install problems noted by Moshe.

It fixes a problem with dates where the months or days were less than 10. (eg. 200611 != 20060101 -- aka Jan, 1 2006).

Adds a permission for scheduling state changes.

This code has been in production for several months for a client. I'm probably going to commit it within the next couple of days unless I hear a lot of push back. I'd like to get it into the 1.0 release.

-Mark

moshe weitzman’s picture

moshe weitzman commented

This code assumes that only one transition can be scheduled at a time? would be nice to allow at least two. I have seen requirements for scheduled publish and then unpublish. I suppose we could refer people who have that need to ASA.

mfredrickson’s picture

mfredrickson commented

Yes, that would be helpful, but lets get this in first and then worry about expanding it.

I think that request falls in with my idea to simplify multiple transitions into a single action. Eg. if I can send a node from state A to state B to state C, why not just have one button to directly from A to C, also doing B's transition and actions? Attach a time to this, and you could potentially "script" very complex, automated workflow paths.

moshe weitzman’s picture

moshe weitzman commented

That makes sense, Mark. The sole remaining objection is duplicate functionality with the existing solution powered by ASA. Barry is using that one on a client site too, without any patches. Anyway, duplicate functionality is not that big a deal so feel free to commit this.

mfredrickson’s picture

mfredrickson commented
Status: Needs review » Fixed

Committed. We can sort out how best to work with Barry's ASA system later.

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)