Community Documentation

Tutorial 2: Creating a simple reviewing system

Last updated December 5, 2008. Created by gcassie on July 3, 2007.
Edited by Michelle, fago. Log in to edit this page.

Workflow-ng comes with a token replacement enabled condition called "Textual comparison". This is a simple condition, which just compares two texts - however both texts may contain multiple token replacements. This allows configuring a lot of different conditions.

As the token module supports the CCK module, these replacements work even with CCK fields. We will make use of this in this tutorial.

A simple reviewing system

Let's create a reviewing system for newspaper articles.

Create the content type

So first of create a new content type called "article" and create multiple fields as you prefer. Also add a text field called "Status" with the widget of your choice (select, radio buttons, ...) and define these three allowed values:

  • needs work
  • needs review
  • published

Create some views

Now users can start and create articles and set their status appropriately. Use the views module,
to create a list of articles that need review by using the appropriate views filters.
Now reviewers can use this view to watch out for articles that needs review.

Let's create another view, one which lists only published articles. This can go at your frontpage or elsewhere, where your user should read the articles. So far so fine - but what if the reviewer sets the status back to "needs work" ?

Then the author needs to informed that the article needs more work. This can be done easily with the help of workflow-ng:

Create the configuration

Start creating a new configuration, which is evaluated on the event "Content has been updated" and call it as you like - e.g. "Notify article authors". Add the action "Send a mail to a user" and select the content author as recipient. Configure the mail text as is appropriate, e.g. use the subject "[node:title] has been reviewed!" and the message

Hello [author_unchanged:user],
[user:user] has reviewed your article [node:title]:
[node:site-url]/node/[node:nid]

The new status of the article is: [node:field_status-formatted]

--- [node:site-name]

But now, the action would be executed every time a node is updated. To avoid this, we need to create appropriate conditions.

Creating conditions

First off, we want the action only apply to articles. So create a new condition, "Textual Comparison" and set the two texts to "[node:type]" and "article". Call it "Is article" and save it.

However, if the author himself updates the article, he is also notified about his own changes. As he knows what he is doing, we exclude this case by creating another condition: Compare two users, and select "Content author" and "acting user". Check the NOT checkbox, so that the action will be executed, if it's not the author, set a label "User Is author" and save it.

Now we are one step closer, but the author still gets informed, even if the reviewer doesn't update the status. So create another condition, textual comparison, and configure the two texts "[node:field_status-formatted]" and "[node_unchanged:field_status-formatted]", check the NOT checkbox and set the label "Status has not been updated".

Then let's say we are only interested if the status is set to "needs work". So create another condition, textual comparison, and configure the two texts "[node:field_status-formatted]" and "needs work" with label "article needs work". Now the action will be only executed, if all conditions match. So the author will be informed if a reviewer updates the status of an article to "needs work". Great!

and published?

However it might be also interesting to the author if a reviewer updates the status to "published". To do this, you can create another configuration, which allows you to configure a different mail text. However, one could also use the same text for both cases - as we have included the new status of the article in the mail's message body.

To do this, we would need an OR: the author has to be informed, if the updated content is an article and updated status is "needs work" OR "published".

To configure an OR, click on the "indent" icon right of the condition "article needs work". This creates the condition group "OR", which contains now the condition "article needs work". Click "Add another condition to this group" and configure a "Textual comparison" called "Is published" with the texts "[node:field_status-formatted]" and "published". Now the action will be only executed, if an article has been updated AND the article needs work OR has been published.

Enhancements

With some further conditions and actions, this simple example could be extended to a more powerful one. E.g. an action "Modify the Content access", might make sure that unpublished content is only visible to certain user roles.

Comments

The above solution works fine, but it bothered me that I needed a separate "approved" field and that it was modifiable by the node author. What I wanted, was to be able to use the "Published" field as a condition for my rules. Now this is possible with 2.0 of workflow-ng. The new replacement fields [node_unchanged:status] and [node:status] make this possible.

This allows the admin to create a even simpler (or the simplest?) review system, without the need to modify existing content types or create new ones. The nodes will have just two states in the workflow: published or not published.

All content types that are to be included in the review process should have their "Published" checkbox unchecked so that the nodes are not published automatically when created. Then the following rules are needed:

1) "Queue for moderation"
Notifies the moderator via email of a new node and display a message for the author that the node will be reviewed.

2) "Publish user content"
The moderator edits the node and clicks submit (taking the opportunity to make corrections if any). On submit, the rule actions will publish the node, send the node author a "node published" email, display a message the email is sent and also a message that the node is published.

3) "Publish moderator content"
The moderator themselves can create nodes probably, so rule 2) should exclude users that are moderators. Instead, when the moderator creates a node, it is published immediately.

Also create a "Pending publication" View for unpublished nodes that display a Block on the frontpage (for moderators only). The Block should display the date and title of the first three nodes and have a "more" link to a page View.

Some caveats:
1) Some more work is needed if the node should re-enter the moderation cycle when it has been updated by the author after it has been published.
2) The assumption is that you don't have a lot of unpublished nodes lying around or else it will be hard to distinguish them from those that are pending publication.

in my configuration for the

in my configuration for the status field i had to set the comparable fields to [node:field_status-raw] to get this working.

in cck i selected raw input and dropdown/checkboxes widget for the status field.

versions:
Drupal 5.12
Content Construction Kit (CCK) 5.x-1.9
Token 5.x-1.11
Workflow-ng 5.x-2.1

------------------------------------------------------
Remember: I compute you!

About this page

Drupal version
Drupal 5.x
Drupal’s online documentation is © 2000-2013 by the individual contributors and can be used in accordance with the Creative Commons License, Attribution-ShareAlike 2.0. PHP code is distributed under the GNU General Public License. Comments on documentation pages are used to improve content and then deleted.
nobody click here