Revisioning

Authors will be able to control which version of their content is displayed and can easily go back and forward between them.

In realising this functionality we initially looked at the Revision Moderation module, but found that the additional functionality that our customers required could not be implemented via a simple patch.

In the RM module the permissions to 'edit' vs 'revert/publish' content are lumped together, so that it isn't possible to enforce separation of these responsibilities by role. Revisioning allows you to assign distinct permissions for authors (to only create and edit content) and moderator roles (to review, publish, revert, unpublish and optionally delete content).

Permissions to view revisions may be set per content type, so that authors, editors and moderators may or may not share their work.

By taking advantage of the Module Grants module (optional, but strongly recommended, see comments made in the Recent enhancements section further down this page), Revisioning lets you set up workflows and control access to pre-published, as well as published and unpublished content.
   
Also thanks to Module Grants this module integrates better with the Workflow and Taxonomy Access Control or TAC Lite modules. This means that by adding one or both of these modules you can easily implement fine-grained access control based on workflow states ("draft", "in review", "live"), as well as content categories, like departments or regions.

With Workflow in the mix you will also get for each piece of moderated content a history of all the state changes that content went through, so you always have a full audit trace of who changed, published or unpublished what and when.

One of the nice features of the module is the "pending revisions" block. Configurable like any other Drupal block this can be placed in the corner of a moderator's screen to automatically alert them the moment new content is submitted for their attention. A simple click on the title brings up the latest revision which may then be published or rejected.

The admin may fork, that is he can edit and save the same original twice, thus producing two pending revisions.

With Views enabled, a new item, Content summary, appears in your navigation menu. This is a view that you may use as is, or as a base for customised views of pending, current and archived content on your site.

Alternatively try the Accessible content menu item of Module Grants Monitor (bundled with Module Grants but not dependent on it), for a different style of presenting your site's content, using handy filtering tabs.

Revisioning is frugal with disk space. By default, a new copy of a revision is created only when you update a current or previously published revision. When you update a pending revision (i.e. a work in progress not yet visible to the public), all edits are saved to the same copy, until it is published. You can switch this feature off though, in which case a new revision is created with every save, thus allowing authors to compare editions prior to moderation. See Content management>>Content types>>edit.

Triggers are provided for the publish, unpublish and revert events, allowing configurable actions to be executed, such as the sending of emails to authors when their submissions are approved or declined. With Token actions installed, these emails may be tokenised. Revision-specific tokens such as [revision-author-name] are provided. See the Revisioning at its simplest tutorial for an example.

Revisioning is integrated with Rules, adding a number of revision-specific conditions and events.

Installation:

Unpack in your modules folder (usually '/sites/all/modules/')
Enable under Administer > Site Building > Modules

Features:

• Authors write content that prior to being made publicly visible must be reviewed (and possibly edited) by moderators. Once the moderators have published the content, authors should be prevented from modifying it while "live", but they should be able to submit new revisions to their moderators.
• Both authors and moderators should be allowed to only access content relevant to their department (or region or division etc.).
• We shouldn't have to grant these roles "god-like" powers (e.g. "administer nodes" permission) to implement this.

What is new in this release:

• Improve token behaviour (make author pertain to loaded revision, not very first).
• Make rules tokens avail.
• Extend Views interface for scheduled revisions.
• Fix redirection from edit form.
• Fix for nodes with multiple tax terms.

What is new in version 7.x-1.8:

• Fixed content access bug.

Requirements:

• Drupal 6.x/7.x