Content moderation

User reviews can be found here

Iam looking for Co-Maintainers helping to deal with the bugs and features. Just contact me - thank you in advance

In Short

This module does what a lot of people know under staging. While you have a live version for all visitors, you can work on a new revision (or revisions). To set a newer revision live, you have to approve it in a workflow.

You can have a look at this video podcast. The module and its usecase is explained there.

Usecases

You want a lot of people edit your nodes or documents, but they should not change the "visible" version just right away. Lets say for some quality assurance, process description or sensible content in your company.

1. Some selected group should first review those changes (based one a specific revision marked for "approval). In the meantime others should be able to edit and create new revisions (which are not part of this approval process)
2. Later some group can approve that revision and make it the new live-version
3. Every state change (review, approval..) should get logged in a history. You always want to know, who reviewed / approved what, when and what revisions
4. You want to have a different workflow, like some other states between review and approve and live. You want to define your own workflow.
5. You want to create ToDo list for you reviwer / approval teams

Thats exactly what this module deals with, while keeping an eye on code-quality, security and usability.

Features implemented

• Moderate: Select a revision to be send into the "approval workflow". Roles with the specific permission for that content type can then review and finaly others (with additional permissions) can approve it.
• Stage: There is always a live version, which can not be modified directly. If a revision gets approved, exactly that revision gets the new live version (not other revisions maybe created in the meantime)
• Edit: Nodes can still be editted - new revisions are saved as pending. Please read this issue
• Edit-XXL:You can choose to even be able to edit during other revision are in a approval workflow(not the default, read this - be ware of the pitfalls)
• Drafts You can chose to work with drafts. Every document not has a live version yet is not published. On approval its published automatically.
• Custom workflows: You can now use the Content moderation workflow ui to design your own workflows or change the current!
• Compare: You can review and compare pending revisions (using diff)
• Rules and Trigger integration:For every node type and every transition events are fired. That way you can e.g. email when a revision becomes live or needs an review and so forth.
• Content types: You can chose which content types you want to moderate. Every content type gets its own rights matrix (review / approved / anystate)
• Views integration: You can generate views of the different revisions with the different states to get a overview or generate TODO lists (thanks to dereine for helping here, or better doing all the work!)

Usage

General

When a content type is under moderation, it always has a live version which is the one got approved most recently. While you have a live version which is shown to the visitors, you can still edit the node and create new revisions.

Finally, you can choose a specific revision to be the new live version. But before that revision becomse the new live one, this revision enters a workflow where it must first get reviewed and after that it must be approved. For every content type there is a user permission to review or approve that content type, so e.g. for company news and blogs you can have different roles (users) reviewing and aproving. You can even define your own workflows, so adding a "managers pov" after approving or a "public viewing" before reviewing etc.

After a revision gets approved, it becomes the new live version. The live-version history gets updated what means, that the reviewer and approver(or any other state change) are added to the list (with date). So you always have a history about what revisions have been approved when and who did it.

Views

To generate views for the node revisions to filter for states or something else, view integration has been build in. To use it, just go to views and create

1. Add a view with the base table node_revisions and not node
2. Under Filter under 'node revisions' you can now select a specific workflow state or expose it to the user
3. You can yet also order by state and also view the state as field / part of a table

Installation

You can have a look at this videa podcast also. The installation and configuration is explained there.

• Download and activate the module
• Activate (optional) the Content moderation workflow ui module to be able to customize workflows

Dependencies

• Diff

Module

Download the module as usual and activate it.

Configuration

1. For every content type you want to be moderated you must edit the node-type and select "Moderate revisions" under the general workflow options
   • Note: You must activate "create new revisions" and "publish" here, as they are enforced anyway. Every edit must be a new revision so you cannot edit content "in the dark". We cant handle drafts right now, so just publish the nodes.
2. Now you go to the roles permissions and look under "content moderation". There you can give roles the permission to be allowed to do a specific transition like review -> approve, approve->live and so forth
3. Give roles to see messages(verbose) or view the content moderation history
4. Now you need to place the "Content moderatio info" block in your toolbars (e.g. left bar) using the block configuration. This is the place where the information of a specific revision, other pending revisions and the current live revision are shown. Also changing states is initiated here
5. Finally when you now create a new node you will recognise after saving that the new live reversion is a template, while your content is under moderation in a revision. That template is changeable using the API. If you enable content moderation for a existing content type, the current revisions of the nodes are further taken as a the live version, every new edit becomes pending.

Goals

Quality

Similar to the tagging module, this module is not hunting to be bloody edge - including the most impressive features is not the main focus. It is primary focused on quality - being robust and working and nearly all enviroments. It should be safe - it should be not possible to exploit or pass arround the revision moderating. So being stable is the main goal compared to features-richness. So having a bug issue queue of 0 is one of the main goals.

Simplicity

This module should be simple. If code size can be reduced - it will get reduced. The module will try to use the Drupal API by best practise. If you have notes on how to improve i beg you for those ideas!

Extendable

While beeing simple and small the module is aiming to provide some proper API to extend it. Most of the things should get themeable, most of the workflows and dataflows should be able to get altered. There is an API to hook into you own rights management or e.g. how revisions (and what) revisions are presented to the users.

Publishing / Drafting

It is possible to work with drafts. Those drafts are only visible for the author first. The author then can pass it over to a moderator which can aprove it and make it a live version.

Search/Taxonomy integration

Moderating nodes should properly work with indexing and searching. So searches should only index the "Live"-version and should maybe provide a switch to search the pending-revisions also. Also terms assigned to pending revision should be not visible in addition that you wont find pending revisions using term "search".

API

Rules and Triggers

For every node type and every transition events for rules and the triggers are fired. you for example to the following things using the Userinterface provided by this modules:
- If a revision of type company_news gets live, send an email to the CEO
- If a revision of type company_news is entering the "needs review" state, write an email to Person XYZ

Your own access control

/*
 * Provides a hook where modules can register there access handler.
 * Example:
 *
 * function mymodul_content_moderation_access($op,$node) {
 *  switch($op) {
 *    case 'view history':
 *      return node_acces($op,$node)
 *    break;
 *  }
 * }
 */

theming

theme_content_moderation_info_block

Provide a theme method for the block used to present the user interface for content moderation

theme_content_moderation_node_history($history)

Theme the display of the history of workflow state changes
$history object

• uid, nid, vid
• stamp: timestamp when the change happend
• state_name: the new state name
• old_state_name: the old state name

theme_content_moderation_revisions_list($revisions)

Theme the list of revisions displayed to the user, e.g. in the info block
$revisions object

• uid, nid, vid, title, body, teaser, timestamp (all fields of node_revisions)
• state: workflow state of that revision

Main differences to other implementations

• You can work on revisions. So you can set revision (2) to get approved, while there is even a newer revision (3) of that node. That also means, you can still edit the node while the approval-workflow is underway, as the approval "approves" one specific revision and not the latest revision like in (nearly) all other implementations
• Every action gets logged in the history. The history is forever and can be viewed.
• Wokflow for the approval process (which also can be modified)
• User rights for every workflow step for every content type

Maintainers

• Maintainer: Eugen Mayer
• Co-Maintainer: Gold

General

This plugin was sponsored by KontextWork GbR for the enterprise Wiki based on Drupal called Drupal Wiki

If you like the module, please write a comment here to motivate the people working on this project!