Tutorial 2: Creating a simple reviewing system

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. So this allows configuring a lot of different conditions.
As the token module supports the CCK module, this 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 this three allowed values:

• needs work
• needs review
• published

Create some views

Now, users can start and create articles and set their status appropriate. Use the views module,
to create a list of articles that needs 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, 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 appropriate, e.g. use the subject "[node:title] has been reviewed!" and the message

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

Creating conditions

First of, 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.
But one could also 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.