Last updated 24 July 2012. Created on 20 March 2009.
Edited by jpoesen, RdeBoer, johnmunro, quicksketch. Log in to edit this page.

On this page we'll take the basic Revisioning tutorial one step further to configure a simple content revision workflow for content that is divided into categories (vocabularies, taxonomies). So far we've implemented this:
Authors write content that prior to being made publicly visible must be reviewed (and possibly edited) by moderators. Once the moderators have published content, authors should be prevented from modifying it while “live”, but they should be able to submit new revisions to their moderators.
Our next task is to realise this:
Both authors and moderators should be allowed to only access content relevant to their departments.

[If you need authors and moderators to view all content but only edit content relevant to their departments, then look at using TAC rather than TAC-Lite.]

So we're looking at the separation of access by taxonomy, more so than by content type (Page, Story, etc...). The latter is easily established using the "edit any|own type content" permissions (User management >> Permissions, node section) in combination with the "view any|own type content" permissions (revisioning section).

This page is self-contained. If you've just completed the steps of the basic Revisioning tutorial, simply install the TAC-Lite module and skip to step 5.

  1. Login to your drupal installation as administrator.
  2. Download install and enable the Module Grants (including Module Grants Monitor), Revisioning and TAC-Lite modules as per their README instructions. If you'd like to compare revisions side-by-side with the differences auto-highlighted, then also install the Diff module.
  3. With Revisioning loaded the Accessible content menu item comes with an additional In draft/Pending moderation tab. The content summary shown, which includes each content's vocabulary (i.e. category) term, is direct reflection of the logged-in user’s permissions and vocabulary grants. For administrators (and other roles with the "administer nodes" permission) the I can edit and I can view tabs will normally show all content on the site, when All is selected also.
  4. Under Administer >> Content management >> Content types, click edit next to the content types for which you wish to enable/disable revisioning. Under Workflow settings, "Default options", tick both the "Create new revision" and "New revisions in moderation" boxes. Also in this section untick "Published". Press “Save content type”.
  5. Navigate to User management>>Roles to create some author roles, e.g. Sports Author and Arts Author, and one or more Moderator roles.
  6. Under User management>>Permissions give the author roles “create content” permissions for the desired content types but none of the edit or delete permissions. As explained here these node module permissions take precedence over the access control grants used by modules like TAC-Lite and Workflow. So you need to switch off all of these in order to let modules using grants do their thing. Most importantly switch off “administer nodes” as this gives roles unconditional access to all nodes. Give Authors and Moderators the “view revisions” (node module section, or the relevant "view revisions of any|own content" from the revisioning module section) and “edit revisions” (revisioning module) permissions. Give Moderators the “revert revisions”, “publish revisions” and “unpublish current revision” permissions. You may not want to give any role the “delete revisions” permission, so that a full audit trail is always kept. Finally, under the module_grants_monitor section tick, at a minimum, "access I Can View tab", "access I Can Edit tab" and "access All tab" for authenticated users. Add "access Pending tab" (revisioning section) for Moderators. Press “Save permissions”.
  7. Create at least one user in the Sports Author role, one in the Arts Author role, and one in the Moderator role: User management>>Users>>Add user
  8. Go to Content management>>Taxonomy to Add vocabulary e.g. “department”. On the same page attach the vocabulary to the content types that require it. Press Save, then add some terms, for example “sports”, “arts”, “science”.
  9. Go to User management>>Access control by taxonomy.
    There a couple of ways to create access schemes. One is outlined in the comment to this page (thanks: johnmunro). Another one is to equate a "scheme" to a role and then proceed as follows. Select the “department” vocabulary, set the number of schemes to 4 and press “Save configuration”. Now click Scheme 1 (name it “sports author”) to assign view and update grants associated with the “sports” term to the Sports Author only. Then using Scheme 2 (“arts author) do the same for the “arts” term in relation to the Arts Author. Keeping things simple for now, use Scheme 3 to grant view, update and delete (if desired) access for all terms to the Moderator role. You may refine this later with more moderators. Finally, if the departmental content is to be viewed by the public, then use Scheme 4 (“public”) to grant view access only for all terms to anonymous users only. Do not include "authenticated users" in the "public" scheme as this will result in authors being able to create content for departments they don't belong to. Save.
    Finally, go to Administer>>Content management->Post settings and press “Rebuild permissions”. This will bring any existing grants in the node_access table in line with the newly edited vocabulary grants.
  10. You should now be in business. Log in as one of the authors and Create content for the selected department. Save. Log out.
    Log in as a moderator to inspect the revised content queue via the Accessible content>>In draft/Pending moderation tab. Click on the title of the content and then on the next page, pick the desired revision by clicking on its saved date. The page that appears next displays the content prepared by the author. Above the content you will find Edit this and Publish this links. Click the Publish this link and on the next page confirm. Log out to see the now public content.
    Log in as one of the authors in another department. Note that under Accessible content authors (and moderators) cannot see or share other authors' content unless they're part of the same department, which is exactly what we aimed for. Also note that under Create content the department drop-down only shows the department(s) the logged-in author belongs to.

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


johnmunro’s picture

The existing instructions for step 9 work for a few author and a few moderator roles but become unmanageable for something like 5 author roles and 5 moderator roles (e.g. 5 departments). Were these instructions created for a version of TAC-Lite significantly old than 6.x-1.3?

Consider revising to:

  • Go to User management>>Access control by taxonomy, select the “department” vocabulary, set the number of schemes to 2 (or 3 if some roles are to have delete permissions) and press “Save configuration”.
  • Now click Scheme 1 (name it “read only”). Assign 'view' permissions. If the departmental content is to be viewed by the public then under 'Access for anonymous user' select all terms (except 'none'). Leave all other roles as 'none'. Do not include "authenticated users" in the "public" scheme as this will result in authors being able to create content for departments they don't belong to.
  • Then using Scheme 2 (“read and write”) assign 'view' and 'update' permissions. Leave anonymous and authenticated users as 'none'. For each of the roles below that, specify which terms each role should have read write access to and press “Save configuration”.
  • Optionally create a Scheme 3 (“delete”) assign 'delete' permissions. Leave anonymous and authenticated users as 'none'. For each of the roles below that, specify which terms each role should have the delete ability and press “Save configuration”.
  • Finally, go to Administer>>Content management->Post settings and press “Rebuild permissions”. This will bring any existing grants in the node_access table in line with the newly edited vocabulary grants.

This has the disadvantage of not allowing authors or moderators to even view public content from other departments while logged in, however the existing instructions appear to have the same effect.

MXT’s picture

To avoid increase number of moderator-authors specific roles, I suggest another "matrix" approach:

  • create an "author" role (permissions: create content, view revisions, edit revisions)
  • create a "moderator" role (permissions: view revisions, edit revisions, revert revisions, publish revisions, unpublish current revision)
  • now create as many "department" roles as you need, and give only access permission to this roles, through "Access control by taxonomy". For example, "department_1" will have "read and write" permission (Scheme 2) on Sports categories, "department_2" the same on Arts categories and so on.

Now the only thing you have to do is assign 2 roles per user, like this:

  • user1 e.g. "AuthorSport1" will have "author" and "department_1" roles
  • user2 e.g. "AuthorArt1" will have "author" and "department_2" roles
  • moderator1 e.g. "ModSport" will have "moderator" and "department_1" roles
  • moderator2 e.g. "ModArt" will have "moderator" and "department_2" roles

LIMITATIONS: this approach as the others described above, will fails when you need the possibility that a moderator can moderate more than one department.

A good solution (i think) to resolve all problems may be the following:

  • create a new module "user_parent-children", where you can assign a "parent" user to other users (these users became "childrens"). I think there can be a dropdown in the user profile page where you can choose the "parent user" from the existing users.
  • This module adds more permission in the permission page, like "Edit CHILDRENS content" more than "Edit own content" and "Edit any content".

With this solution we can have more possibilities to manage departments: a Moderator can moderate more selected categories (departments) but manage ONLY his children user contents.

Sorry for my bad english, I hope that I have made myself clear.

I'm not a programmer: could someone develop the module described above?



areikiera’s picture


Thank you for this wonderful module! I'm pretty new, so accomplishing this without a module like this would've made my head spin right off.

I've completed the first two tutorials, but I've run across an issue that I would love some input on. I have a site structure where several departments and related services exist. Each service is associated with one or more departments (department names are the taxonomy terms). When a user assigned to a department term edits a service page that is also associated with other department terms, only the user-specific department term appears, and when published, the other associated department terms are stripped from the page.

Any way around this?

Thanks for any help!

canishk’s picture

This is very serious issue.

I just enabled 3 content types for reviosioning. But while editing all the content-types came with revisoining which results pending the publication of new nodes. Even I have double checked all the content type to make sure that they are coincidently enabled reviosioning. I want to put these content-types without any pendiong/draft nodes.

Please reply. This is a stopper issue now!

mErilainen’s picture

I haven't tried any of this out yet, but I see a big problem if there are many taxonomies and they all have different content editors and moderators. I'm not going to make 10 additional roles to manage 5 different taxonomies. What if there were 20 taxonomies?

Is there any way to grant access to View/Edit/Delete "My taxonomies"? It would be one permission in the permissions table which can be granted for a general roles like "Content editor" and "Moderator". Then user accounts could be tagged with those taxonomies which they will be granted access on. Probably there are other issues with this approach, and doesn't actually relate directly to Revisioning, but the topic of this page does.

delacosta456’s picture


please how did you finally managed doing this ?

Your approach idea looks simpler and more friendly