Workflow Extensions

When using Workflow (6.x, 7.x-1.2), be it with or without Rules (6.x), this module comes in handy to help you realise some common workflow-related scenarios and to spruce up your Workflow interface to create something more user-friendly.
The module addresses two use-cases in particular:

1. Alternative UI options

   a) Finally! 4 years after this change request for Workflow, #73412: [EXPORTING] Add named, labeled transitions, you can now replace the traditional Workflow radio buttons by either a drop-down selector or by single-action buttons featuring explanatory labels (pictured), to achieve a more intuitive user experience. By default the names on the buttons are based on the workflow states you have defined. However, bring Workflow Named Transitions (currently D6 only) and Tokens into the mix and you have full control to place any text on your buttons, including context-sensitive details, such as Reject, return to [node:author] or Go live with "[node:title]". All three UI styles (radio, drop-down and single-action buttons) are available as a configurable block so that you can change workflow state from anywhere on any page you choose, not just the node edit form or the Workflow tab.
   b) If you have Views enabled, a Workflow dashboard menu item will appear in the navigation menu. This is like a Workflow control panel, in that it displays on one single page, for each node on your system that has a workflow attached, the state change transition form for that node. So you won't have to visit node after node to transition their states, everything is on a single page. Naturally, using the Views UI, you can modify and extend this view to your heart's content, adding columns, moving it to another menu, into a block etc...
   c) A second handy view Workflow history (also in the navigation menu and available as a block as well) lists in reverse chronological order all recent state transitions, together with the times these occurred, names of the users who transitioned states and the workflow comments they attached.
   d) The last column of the Workflow history view contains links to edit the workflow comment. When using the Workflow module by itself, workflow comments cannot be edited. With Workflow extensions enabled, users with the new permission "edit workflow log" may edit the workflow comment. A tickbox on the Administer >> Site configuration >> Workflow extensions page controls whether the edited comment may be blank (i.e. erased).
   e) There's a new permission "allow workflow state change via node edit form" to control whether or not a role should be offered to transition the workflow state while editing a node.
   f) A configuration setting controls visibility of the workflow schedule transition form. Until the user presses the radio button to reveal the schedule details form, the form won't be visible. This prevents users from making the mistake of filling out date and time, but forgetting to push the schedule button. Inspired by btully: #1162632: Proposed patch to show/hide the workflow schedule date/time fields depending on context

2. Invoking actions after inactivity

   The bottom of this project page explains how with the help of an extra token, supplied by this module, and the Rules module, you can invoke actions, like sending reminder emails, when a workflow did not transition state for some time, for instance an article left in the "draft" state with the author forgetting to submit it to the reviewer/moderator.

1. Alternative UI

a) Let's say we have a basic workflow with states "draft", "review" and "live".
Traditionally authors and moderators must select the next state by pressing the correct radio-button and clicking submit. Experience from the field suggests that not everybody finds this intuitive. Rather than having to think in terms of state transitions, users prefer to press a button with an explanatory label that clearly expresses what is going to happen.
For instance, traditionally in Workflow to "submit for publication" is to "transition the workflow state from draft to review by selecting the appropriate radio button and pressing Save".
Using this module authors will instead find clearly labeled single-action buttons, for instance Submit for publication and Save as draft, but don't submit.
Similarly moderators will see on their edit form buttons like Reject, return to author John (i.e. "review -> draft") and Publish this or Go live with this! ("review -> live").
b) The Workflow dashboard is on by default, provided Views is enabled and the logged-in role has the "access workflow summary views" permission. You can switch this feature off by disabling the view.
c) The Workflow history view accepts a node id (nid) as an optional argument so you can use URLs of the form workflow-history/%, where % is the nid, to show the state transitions for a single node. This is similar to the Workflow History displayed on a node's Workflow tab (node/%/workflow), except that the latter cannot be customised. When using the block version of the Workflow history, the view will automatically pick up the node context and show the history fot that node only. Outside the node context a history across all nodes subject to workflow will be displayed.
d) The "edit workflow log" permission is set at Administration >> User management >> Permissions.
e) This permission too is found at Administration >> User management >> Permissions. If you choose not to allow a role to change workflow state on the edit form, you want to make sure they can use the Workflow tab instead. You configure this on the workflow in question, at /admin/build/workflow/edit/# (D6) or admin/config/workflow/workflow/edit/# (D7).
f) This feature is on by default. You can switch it off by unticking the box at the bottom of this page: Administration >> Configuration management >> Workflow extensions

2. Invoking actions after a period of inactivity

This module defines a workflow replacement token, [node:workflow-state-age], which makes it easier to invoke an action (like sending a reminder email) when a workflow state was not transitioned for some time. You do not need to resort to PHP when using this token. See the appendix, which details the use of the token. It also describes alternatives that do use simple PHP.

Installation and configuration

Installation is like any other module. Uncompress the .tar.gz file and drop it into the "sites/all/modules" subdirectory. Visit Administer >> Site building >> Modules, tick the box in front of the module name and press "Save configuration".
Or use drush.
For total control over the labels to put on your workflow buttons also install Token and Workflow Named Transitions (both highly recommended, D6 only).
With Workflow Named Transitions enabled, visit Administer >> Site building >> Workflow and click the "Edit labels" tab to enter your custom labels (D6). With Token enabled you may use replacement tokens in your custom labels, for instance: Reject, send back to [author-name].
In addition, there are a couple of self-explanatory configuration options at Administer >> Configuration >> Workflow extensions.

Finally, this module also makes the state change form used on the Workflow tab available as a block, giving you more control over where on the page users may change workflow state. A use-case is a trouble-ticket system, whereby operators can view the ticket status AND update it on the same page, minimising clicks.
Using the block visibility controls you may place the block on any page that provides a node context, typically the node/* pages, or more specifically the node view page. To prevent the Edit and other tabs from also displaying the block tick "Show if the following PHP code returns TRUE" and enter:

  <?php return !arg(2); ?>

If your theme does not have any block regions to suit your esthetic requirements, you can instead insert the line below in the node.tpl.php file of your theme, for instance immediately above (or below) the line containing print $content;:
<?php if (!$teaser) print workflow_extensions_change_state_form($node); ?>

Usage

Users will find that the workflow radio buttons previously used to instigate state transitions are now replaced by either a drop-down selector or more intuitive single-action buttons labeled with the texts you entered above. This applies to the node edit and comment forms, as well as the Workflow tab, node/%/workflow, if enabled. Naturally, it also applies to the "Workflow change state form" block introduced by this module.

Appendix: using Rules to invoke actions after a period of inactivity (D6)

As an example of acting on something that did not happen, we'll send a reminder email to the author of a piece of content when after say, 5 days, they still have not submitted their draft for publication. The instructions below cover two realisations, one that uses the new token [node:workflow-state-age] and one that uses an existing token plus a PHP expression. Once you've followed these steps it's easy to dream up your own variations, which may or may not involve the Workflow module.

o Install Rules (6.x.1-3) and enable the Rules Admin UI and Rules Scheduler submodules. At Administer >> Rules >> Settings flick on Debug rule evaluation. This will come in handy to check the correctness of our rules. If you're ok with trying the PHP solution, make sure that at Site building >> Modules the optional core module PHP filter is enabled.

o Go to Administer >> Rules >> Rule sets to Add a new rule set. Label it something like "If state not changed for long, send reminder (rule set)". Enter the same for the machine readable name, replacing spaces by underscores.
For the argument select the Data type: Content. If you have Workflow installed, resist the temptation to add the Workflow state data type -- you'll run into trouble when scheduling the Rule Set.

o After saving, click the rule set name and then the tab Add a new rule. For the rule label enter "If state not changed for long, send reminder (rule)". A Rule set may contain more than one rule, but for now one will suffice. Save.

o Open the "Rule elements" fieldset to Add a condition.
For the non-PHP solution pick "Rules: Numeric comparison". Press Next. Change the label to "State not changed recently". Under "Number 1:" enter [node:workflow-state-age], the token provided by this module. For "Operation" select Greater than. "Number 2:" 60, i.e. sixty seconds for now, to test. Save.
Alternatively, for the PHP solution pick the condition "Rules: Check a truth value". Press Next. Change the label to "State not changed recently". Under "Truth value:" enter
<?php return [node:workflow-current-state-date-tstamp] < strtotime('-30 seconds'); ?>

o Secondly, Add a condition "Workflow: Content has a workflow state" to make sure to only proceed with the action if the state is "in draft" at the time that this rule is executed.

o Add an action "System: Send an email to an arbitrary address". Next. "Recipient:" [node:author-mail-raw]. Enter a message. You may again use tokens. For instance:

Hello [node:author-name],

This is a system-generated message to remind you that your article "[node:title]" has been in draft for over five days. Can you please complete and submit it for publication at your earliest convenience?

Thank you!
[node:site-name]

o We now need to schedule this rule set at some point in the future, whenever content is created or updated. So, Administer >> Rules >> Triggered rules >> Add a new rule. Call it "Schedule check for unchanged state". For the event use Node After updating existing content. Save changes.
Add a condition : "Node: Content has type". Select one or more types. You can add other conditions so that the rule is only considered for content in a particular workflow state, say, "draft". For this you'd use a "Rules Textual comparison" condition of [node:workflow-state-current-state-name] against the desired state name, e.g. "draft". Save.

o Add an action: scroll down to the section "Rule Scheduler" and find your rule set name, preceded by the word "Scheduled", i.e. "Scheduled "If state not changed for long, send reminder (rule set)"".
For the Identifier enter: "[node:title]": check for unchanged state.
For "Scheduled evaluation date" enter + 5 days, or maybe +61 seconds while testing. Save

o Now edit a piece of content that is of an applicable type and press Save. Go to Administer >> Rules >> Rule sets >> Scheduling to verify that your triggered rule is scheduled. Wait till at least the scheduled time.

o Then whenever cron next runs, e.g. manually by entering in your browser address bar .../admin/reports/status/run-cron, the triggered rule should fire its action (i.e. the rule set) after which the task will be removed from the Scheduling page. An email should be sent. Check the Reports >> Recent log entries page.

o When it looks like all's working, change the "Scheduled evaluation date" to +5 days (or whatever value you like).
Finally, for the non-PHP solution, in the "Numeric comparison", increase Number 2 to a value just under 5 days, i.e. 5 * (24*60*60) = 432000 (seconds).
For the PHP solution change your Truth value to
<?php return [node:workflow-current-state-date-tstamp] < strtotime('-5 days'); ?>