We have Workflow, Actions, Views, Revision Moderation and other assorted modules enabled in Drupal 5.1 on a linux system. Like many people, we need to have new content reviewed before publication by a small group of editors, though the number of users who can potentially submit content is larger. However, we also want to allow users to make changes to existing content, still subject to moderation, and we need to use revisions so we can roll back to an earlier revision if needed. We had been using Modr8 and Revision Moderation modules, but the editors want to be notified by email when content is submitted. This would seem to be a job for Workflows and Actions. Unfortunately, neither Workflows, Views, nor Actions seems aware of any Revision states or data. We are prepared to fund a developer to implement these features.
Here are the parameters for this requested development:
1 - We need to be able to display lists of node revisions and their current state in Views, as well as the author of the revision, similar to what is shown on the Revisions tab but with more flexibility. For example, we would like to be able to create a View which shows a list of all revisions of nodes awaiting approval within a specific taxonomy area, along with their author ("Updated by"), and perhaps a Views Action "Publish Revision" link.
2 - We need an action triggered on "Create New Revision" as per http://drupal.org/node/97802.
Test case: Set up a workflow with a simple set of three states: Draft, Review, and Public. Create views to display the editor queue. Set actions to notify users via email and/or a screen notice when a node enters the "Review" state. This works fine for new content as is.
However, when a user edits an existing node, a new version of the node is created. If revision moderation is enabled, this new version doesn't get displayed to unauthorized users (correct), but it also doesn't get flagged as needing to be reviewed, i.e. the state doesn't get automatically changed to "Review," and there is no action available to do this. Therefore, the editor isn't notified that the node has been revised and needs to be reviewed. We don't want to take the whole node back to "Review" state, either, which is what would happen with the current Workflow Access settings, because ordinary users aren't allowed to save a node in "Public" state.
There is a filter for moderated items in Views, but it doesn't get items which have revisions needing moderation -- this is stored differently than in the node's moderation flag. After the change we are requesting, it should be possible to create a new view that lists all new and revised content by workflow state, including the last modified date of the most recent revision, the author of the most recent revision, and a link to the most recent revision allowing viewing and approval. If a user without permission to save in "Published" state edits a node, they should be able to select a "review" state (we actually have several, depending on the area) for the revision.
For more information, please contact:
Elizabeth Dalton
Information Technologist
Whittemore School of Business & Economics University of New Hampshire - McConnell Hall
15 College Rd.
Durham, New Hampshire 03824
Phone: (603) 862-1291
Fax: (603) 862-4468
elizabeth (dot) dalton (at) unh.edu
Comments
Issue with Views
Main issue with your request is that Views is based on 1 to 1 relationships between the node table and the join table. In case of revisions under moderations, it's quite possible that there are more than 1 revisions waiting for moderation. If Views would handle 'RIGHT JOIN', which it does not due to a reason I don't think is correct, this 1 to many relationship would not be a problem.
So my conclusion after a couple of hours investigation: without patching views, you will not be able to
I will now try to patch the views and try whether I can come up with the above views.
View patch
With a very short views patch, I managed to get the views to work and create a list with the required fields. So, I guess good news if you can live with that patch. I will add an issue to the Views project and post the patch.
A patch to Views would be fine.
I expect it would get rolled in if you submit it to the Views project, anyway. :)
lapsus
Ok, I managed to get it to work without the patch. Clearly something I overlooked into Views. I'll post some results after I tested a bit deeper.
logs vs states
When you look at the node_revisions table, you will notice a log (longtext) field. The idea is that an editor (someone who has permission to edit a node) can fill in some log information. I was thinking about this some time ago, and I didn't really like this way of working. If you have a mass of editors (multi lingual), and you like to control all the edits, it would be more handy that your editors select what type of edit they made, rather than just typing it out in the log field. So, a controlled set of log options, let's call them revision states ;-)
The advantages:
There is a module which does something similar: Revision Tags, but it mainly based on tagging old revisions which are not under moderation. Still, what is interesting is that the developer (Robert) encountered the same issue as the previous comment. He writes:
I'm not a views expert, but I think this can only be managed with a RIGHT JOIN.
Don't know if you are still considering this...
But I was thinking that the workflow states would just attach to the revision, rather than to the node. I suppose the question is how to do a view with the revision as the main unit, then, rather than the node? That's not exactly right either... let me think about this.
How does Views get Comments data (e.g. last comment date, last comment author)? Does it have to use a right join, or does something in the Comments code update the node table?
Comments ->node_comment_statistics
Views probably accesses the table node_comment_statistics to get last_comment_timestamp and last_comment_name. Maybe we need node_revision_statistics for last_revision_timestamp and last_revision_name.
revision states are attributed to revisions, but nodes as well
Sure, but at the level of the database, the revision states table would hold nid and vid anyway. Otherwise, trying to integrate it with views would become impossible. So, you need nid to relate with the node table and vid to check whether thats a revision under moderation (vid > node.vid).
workflow_node -> vid rather than nid?
Would it be possible to change workflow so that it gets and stores the vid rather than the nid in workflow_node? This would make the workflow tab on a node a bit tricky, though. I guess the workflow tab would refer to the current revision, but one could select other revisions and that would change the contents of the workflow tab.
re: did this ever get resolved?
This is actually what I want.
What I am currently doing is setting a node to unpublished by default, and hiding the part of the form that changes this for one class of users. Then another administrative class of user approves all the new content.
However I want the first class of user to be able to edit their content, which would create a revision. I'd then like to display the original edit until the new edit gets approved/published.
Any idea of how to do this with the current workflow/actions/triggers module trio?
If not, I'll probably code it myself using a theming function.
Dave
My site: http://www.unitorganizer.com/myblog
Described a similar problem,
Described a similar problem, anyone have a look?
http://drupal.org/node/767974