Last updated April 12, 2013. Created on March 20, 2009.
Edited by RdeBoer, B-Prod, dooug, kpander. Log in to edit this page.

This tutorial demonstrates how you can extend the basic Revisioning workflow with state-based content access through the Workflow module. The additional goal we're setting ourselves is:

Enforce segregation of authors and moderators, so that authors can't modify revisions after submission (to the moderators) and moderators can't touch revisions still being worked on by authors.

Begin this tutorial after you've completed either the basic Revisioning workflow tutorial or the tutorial on Revisioning with categorised content (till at least step 7).

To realise our additional requirement, we'll create a simple workflow of three states: "in draft" (i.e with the author), "in review" (i.e. with the moderator) and "live" (i.e. publicly visible). Then we add permissions allowing certain roles to transition states as well as content access grants based on the above states.
As a bonus we'll also add some triggers to support automatic notification of authors and moderators as content transitions between states.
Let's start. These instructions were written for Workflow D6. D7 users will find that in the latest incarnation of the Workflow module the same UI elements are still present, just organised differently.

  1. Login to your drupal site as administrator.
  2. Install the Workflow (includes Workflow Access, which you must enable) and Token modules. Activate the Trigger module (part of core). For an alternative to Module Grant Monitor's (D6) Accessible content page (the one with the double row of tabs) you could install Views, which will give you a built-in Content summary option in your navigation menu.
  3. Create a workflow. Go to Administer>>Site building>>Workflow>>Add workflow, type a workflow name and add three states, “in draft”, “in review” and “live”.
  4. Select the content types to which your workflow will apply. If you want moderators to be able to deal with all content types create a single workflow. if you don't want roles that deal with one content type, say page, to see content that is being handled exclusively by another role, say blogs, then it's usually best to create separate, but near-identical, workflows, one per content type.
  5. Press the workflow's Edit link (/admin/build/workflow/edit/1) to define which roles may invoke which workflow state transitions. You may want to start with this:

    creation->in-draft (i.e. create initial revision): allow the pre-defined role of “author”
    in-draft-> in-review (i.e. submit for moderation): allow the Author role(s) (e.g. Sports and Arts Authors, if you've just come from the revisioning with content categories tutorial)
    in-review->in-draft (decline author's submission): allow Moderator
    in-review->live (optionally edit, then publish): allow Moderator
    live->in-draft (create new revision of live content): allow Author roles

    In a revisioning workflow, content (a node) normally doesn’t get unpublished. Rather different revisions, old or newly submitted, are made current, while the node as a whole remains published. The live->in-draft state transition doesn't mean that content is taken off the site, it merely makes a piece of content available for modification “behind the scenes” by the appropriate role(s). All the time the “live” (current) revision remains unchanged and visible to the public, until another revision is made current by the moderator. Keep in mind that the “in draft” and “in review” states pertain to new (i.e. pending) revisions, rather than the publicly visible copy. “live” means there is no pending revision to be reviewed. Maybe better names for the states are “with author”, “with moderator” and “with public”.

  6. Scrolling down the page, you may want to tick the boxes labeled Show a comment field in the workflow section of the editing form and Show a comment field in the workflow section of the workflow tab form. This comment field may be used, for instance, by a moderator to enter the reason why they declined submitted content, passing it back to the author by putting it “in draft”.
  7. Further down, in the Workflow tab permissions section tick Sports and Arts authors and Moderators. These permissions allow roles to invoke state-transitions via the Workflow tab. State transitions may be entered via the content editing form, but if the role has no access to edit the content in the state that it is in (see next point), the Workflow tab becomes the only way a user can invoke a change of state.
  8. The thing to note about the Access control section, all the way at the bottom of the page is that these grants have node granularity. As the current revision of the node needs to be viewable to the public regardless of the workflow state it is in, you'll want to grant “view” to anonymous user, as well as Authors and Moderators (or alternatively authenticated users) for all states. Also grant “edit” to the Sports and Arts authors when content is "in draft". For the “in review” state grant "edit" to the moderator role(s) only. Add “delete” where appropriate. To force authors to transition state before they edit content, do not allow "edit" to any role for content that is in the "live" state. Press Save.
    Important: uncheck all "edit ... content" permissions in the "node module" section on the User management >> Permissions page as these will supersede the workflow access controls you've just put in place. Why?
  9. You're pretty much there. Still logged in as administrator, press Accessible content and observe that the content summary now has a column for the node's workflow State. Content created prior to the installation of the Workflow module will be flagged as in No state and therefore may not be accessible to anyone but the administrator. Modules Workflow post install (D6) and Workflow import (D7) have a special function that you execute once as an administrator after installation of the Workflow module. These modules put all old content in a valid workflow state so that it becomes accessible to Authors and Moderators as part of the workflow.

You now have a workflow with clearly segregated “in draft” and “in review” states. As you (as an author) create content, you'll find that moderators cannot edit revisions while still being worked on by authors. It isn't until an author clicks "in review" on the editing form that the new revision becomes accessible to the moderator. From that moment authors can't modify the revision while it's still in moderation. Once a revision has been promoted to “live” an author can again grab that piece of content at any time by transitioning it to “in-draft” (via the Workflow tab). They can repeatedly edit and save content, but it always takes a moderator (or administrator) to review it and make it visible to the public.

A final tweak is for the integration and synchronisation between the Revisioning module, which does most of the heavy lifting, and the Workflow module, which is used primarily for its state-based access control. At the moment, publication (via the Revisioning module) and transitioning to the “live/with-public” state (via Workflow) are separate steps that aren't synchronised. The moderator executes these as separate clicks. To roll these steps into one we can first take away a moderator's permission to (manually) publish: User management>>Permissions (section “revisioning module”): untick “publish revisions”.
Then, taking advantage of core's Trigger module, go to Site building>>Triggers>>Workflow to configure a “Publish the most recent pending revision” action to occur automatically every time the workflow state goes from “in review” to “live”. Now the moderator can only publish by moving content into the “live” state and this transition automatically makes the pending revision current via the action triggered.

Alternatively, the same effect could be achieved using the Rules module.

As was shown in the basic Revisioning workflow tutorial, by employing triggers we can action state-change notifications, for instance an automatically generated email when a moderator declines an author’s submission as he puts the revision back “in draft”. Create the email action on Site configuration>>Actions, then set the trigger on the desired state transition via Site building>>Triggers>>Workflow.
Note: you may need this Workflow module patch to make the sending of emails work.

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

Comments

Tim-Erwin’s picture

Hi, I followed this tutorial and have one problem: after creating a piece of content with a non-admin user (authors and even moderators) this user is not allowed to edit this node. I disabled all "edit ... content" in the node module as described above. In the workflow settings I enabled editing even for authenticated user. I'd be thankful for any hint what I might be missing.

crea’s picture

That was a bug. Also please report bugs to the issue queue instead of posting them on doc pages.

MXT’s picture

It was a workflow or revisioning module bug? can you post the issue link?

thank you!!!

mrfelton’s picture

Sorry to post about this again on this documentation page, but I have hit this same problem, and can can not find a ticket in either the workflow or revisioning module's issue queues. If you know about this bug, please could you post the link to the issue queue ticket?

Thanks,
T

--
Tom
www.systemseed.com - drupal development. drupal training. drupal support.

MXT’s picture

Did you resolve it? How? I have the same issue!!!

Ellen Dee’s picture

I ran into this same issue. I resolved it by enabling Module Grants: http://drupal.org/project/module_grants

I suspect this wasn't mentioned in this tutorial because the Revisioning module used to require Module Grants (no longer as of 6.x.3.5 -- now it only requires the Node Tools submodule contained in the Module Grants package).

techgirlgeek’s picture

I'm having the same issue, and I do have module_grants installed and am still getting it where the node owner is no longer able to edit the node.

Jean Gionet’s picture

I'm in the same boat too!! Any workarounds for this issue? Both my authors and moderators CAN'T VIEW unpublished revisions/drafts. They can EDIT and change it's workflow status.. just not view.

A Day In The Life

Monzer Emam’s picture

It toke from me days to understand this tutorial and the basic Revisioning workflow.

The tutorial needs to be organized.Plus it contain extra uneeded information that confused me in the beginning.

Also the result of it is completly unsatisfactory (It adds too many step for author and moderator to do a Workflow based on revisioning) may be I missed something (or few things) but dealing with two tabs to achieve one thing is much.

I will seek anther module

pbarnett’s picture

Strange. I followed it and it took about an hour or so to do from start to finish.

I was perfectly happy with the result too, though I used Rules rather than Trigger for added functionality.

Jean Gionet’s picture

hi, I just followed the 3 tutorials and pretty much got everything working, however, all my authors can't see each others posts.
If they logout and just browse the site as an anonymous user they can see all the posts. Once they login they can only see the posts they made and not the ones made by other authors.
any ideas? I must have missed something somewhere.. but after going through it 5 times I'm a little lost.

thanks

A Day In The Life

Robert2011’s picture

If you have the content_access module you need to disable the "grant own content access" and "grant content access" to all roles except perhaps administrators. If it's enabled, authors, and moderators will not be able to edit content unless they give themselves permission to do so after having saved content.
edit: I have since found it best to remove content_access entirely because permissions still didn't work properly (sorry can't remember exactly how ATM)

dropbydrop’s picture

How this can be done with drupal 7?
Can revisioning do it?

Or only workbench and maestro?

skadu’s picture

Hey all,

Thanks for the great tutorial, this has got me set up to about 95% of what I needed. Then when I saw the section that starts with "Final Tweak" I thought the other 5% would be done here. So I followed the instructions and went to add the "Publish most recent pending revision" action to the appropriate trigger (move from 'In Review' to 'Published Live') only to discover that the action was not available.

I took a minute to dig into the Revisioning modules revisioning_action_info() [line 137] and discovered that this action is only made available to the following triggers : 'node_insert' and 'node_update'. Which means that this action can NOT be assigned on a workflow state change as indicated in the tutorial. As a very rough fix, I have enabled the 'revisioning_publish_latest_revision_action' for all triggers.

I'm sure this is not the best way to accomplish this, but the function fired by 'revisioning_publish_latest_revision_action' does check for a pre-existing revision before trying to publish it, and if the revision is not found, a warning message is printed.

Again, thanks for the great tutorial.

~Cooper

RdeBoer’s picture

Better late than never... Rik

ironkiat’s picture

While in Drupal 7, I couldn't get the trigger to work too.
The action to publish pending revisions was not available in the Triggers assign page for Workflow tab.

So instead of using Triggers, I used Rules to check workflow state of the content. If its in "Live" State, then Publish new pending revision.

Alternatively, I also tried another method which kinda works:
In Rules, check that the condition is when pending revision is published and the result action to change workflow state from "Review" to "Live"

Authors still needs to change the workflow state from Live to Draft before they can edit and create a new revision.

After new revision is created, submit to Review State and the cycle repeats.

Hope this helps!

rmccullough’s picture

First thank you great module and tutorial it has really helped me a lot

I am using the revision module along with work flow as described in your tutorial.
I have to say it is working a treat and doing exactly what I need for existing content.

When I create new content however the created content is visible to the anonymous user. I’m relatively new to Drupal so I’m sure I have missed something but am I right in saying that node access is controlled by workflow access and this is set to let anonymous users views nodes irrespective of their workflow states. This is fine for existing content but does it not mean that new content can be viewed.

RdeBoer’s picture

For solution and discussion, please follow this issue http://drupal.org/node/1492246.