Mechanism to automate workflow state changes

I'm actually in the same situation right now.
I had to define a simple workflow for documents, with just two editing roles (writers and editors), but I stumbled upon something like that.
The workflow is set up like this (simple, basic workflow that everyone loves):

draft <-> verify -> publish -> draft
  

meaning that from the first draft from the writers we move to the editors. If they deem the content worth of publishing, on to publish: if they don't, back to draft.
Setting up content type defaults, actions and node permissions using the nodeperm_role appropriately, this works.
Writers can't publish directly and editors are e-mailed when their intervention is necessary.
The trouble comes when you get from publish to draft, when content that has been published needs retouching (say, a new price tag for an article, a spec change on a product, a date shift for an event), a task which is obviously appointed to writers, not editors.
Writers can edit the node (thanks to actions and nodeperm_role we reassign editing rights when publishing), but it either remains published without being assessed by editors (BAD) or unpublished without notice (if you set this via nodeperm_role, again), or you are simply trusting that your writers will infallibly advance the workflow of their own accord, which, simply put, is whishful thinking.

I hope we can find a smart solution for this, possibly without calling in cron to execute external SQL.

--

vector at exea dot it

I agree that we eventually need to implement conditionals.

I do think, though, that the problem of revisioning (which is really what resmini is talking about) is a bigger problem than just workflow. We need to wait for the revisions patch to hit core before constructing workflow's contribution to this problem.

I checked that thread and I completely agree with you. I had missed it, thanks for pointing it out.

that revisions patch finaaly landed

Yup. The action is now here.

Automation of workflow state changes would be beneficial to me as well. I described my suggestion in Earl Miles' Module Proposal: Workflow Publishing thread.

How can I restrict author's edit access to a node when it has gone to review (assigned to moderator)? Only if the permission "edit own nodetype" is checked? Or I need a new type of action (something like "Allows the author editing privs via node_access" ?

I have an actions module in testing that may do what you are looking for. It is an action that can spawn sub-actions. Since it is an action you can have as many of these defined as desired. Obviously it is less pwoerful than defining actions for every possible transition. But it is a time saver when most transitions are linier.

I presents a list of all states and allows those states to be re-ordered.

Actions are associated with each state (as many as desired). Actions within a state can be re-ordered. When executed actions are guaranteed to be done in the order listed. A new sub-call for actions (actions_plus.module) optimizes these to avoid unnecessary node_saves.

States can be set to inherit actions from prior states AND whether that state can be inherited from the next state.

When a state change is detected the system calculates a path from the current state to the target state. If the current state is AFTER the target then the path starts at (create) (which is can have its own actions, I usually use this to reset a node to a known configuration) and the proceeds through each state's actions until reaching the target state. Exceptions are:
* If final state is set to inherit=NO then ONLY the target state's actions are triggered (I use this for a reject state during a submission process)
* If an intermediate state has the inheritable=NO then that state's actions are not processed

Finally there is a checkbox that will replace every possible transition as defined in the workflow module with the new action. In most cases that is what you want to do but you can always combine this action with others in custom transitions.

It requires the 'update_pre' (and friends) patches to node.module an workflow.module

Example:
Create - Used to reset a node to a known state
Reject - set to non-inheritable - this means its actions are skipped if this is between create and another state
Private - Node is editable and viewable only to author
Submit - The node becomes read-only except to role 'Reviewer'
Edit - The node becomes read-only except to editor
Review - The node becomes read-only except to editor
Publish - The node becomes viewable to all

My transitions allow a node to go from each state forward and most states can reject the node.T his leads to a LOT of transitions but I only needed to design the flow from Create ... Publish with the exception state of reject (hence the inherit and inheritable flags, they allow simple exceptions). To go from private to publish (perhaps an admin transition) the node will be processed against the actions for: Submit, Edit, Review, Publish). To go from Publish to Edit: create; private; submit; edit (reject is skipped because it is non-inheritable). If I add more transitions I simply edit my autoflow action and click the rebuild-states button to add the autoflow to all new states. Easy. In my case there is only one node save no matter how many states are processed.

There is a flag set by this action that allows other actions to know if they are part of an intermediate state or final state. I use this to control when I issue email notifications. For example transition through edit does NOT issue an email (the email action sees it is intermediate and does nothing) but transition to edit would fire the action.

Does this do what you want? If so I will clean it up and post it here in the next few days.

Maybe an action that performs a transition on a node into the next workflow state (or which ever one is specified) ?

So you could have a list of actions for a state, and the final one being "transition to next"

Things to consider

- What happens when it fails? is there where other logic comes into it to push it different states when that happens?

- If some of the actions are time-intensive, how do we run them in the background? (Ive seen coldfusion guys schedule a task that needs to be run in 1 second from now, which is handled in the background by the java server and the webapp continues along)

Workflow now has an action that transitions from one state to another.

There is also an API function: workflow_execute_transition. This can be called from a cron job.

I'm going to mark this as fixed, unless someone wants to reopen it.