Add Views integration

Would be extra practical if such an integration could affect which fields and links were visible on the moderation page of a node too, for example to get a column with the name of the author of each revision, which is much missed. Or is that rather a separate feature request for the module itself?

This would be a priority for us, and we're willing to fund, too.

Just to let you know I'm working on this. I'll probably submit it as a patch for the revision moderation module.

I'm finishing the patch. Here is already a screenshot of the views form.

Find attached the views include file. Store it into the revision_moderation module directory and change the extension into .inc (it's .inc.txt because drupal does not accept .inc extension).

In order to test it you need to add the following lines to the revision_moderation module:

if (module_exists('views')) {
  include_once drupal_get_path('module', 'revision_moderation') .'/revision_moderation_views.inc';
}

I'll make a cleaner patch once everything is tested.

Where does the code snippet need to go in revision_moderation.module? I tried putting it near the top, just above the //Actions... line, and knocked my whole website offline (empty white screen on all URLs).

Here is where I added it:

// $Id: revision_moderation.module,v 1.26.2.10 2007/02/20 15:55:17 webchick Exp $

/**
 * @file
 * Allows moderation of node revisions while existing revisions stay visible.
 */

// Actions module support.
if (module_exists('actions')) {
  include_once drupal_get_path('module', 'revision_moderation') .'/revision_moderation_actions.inc';
}

// Actions module support.
if (module_exists('views')) {
  include_once drupal_get_path('module', 'revision_moderation') .'/revision_moderation_views.inc';
}

/**
 * Implementation of hook_menu().
 */
...

I still get the white screen if I add this code in this position. If I remove the "IF" bracket statement, and just include_once, my site stays up, but I still don't see the additional fields in Views.

We are running Drupal 5.2 with the following Views and Revision Moderation related modules:

View field 5.x-1.2
CT Views 5.x-1.1
Event Views 5.x-2.x-dev
Event Repeat Views 5.x-1.x-dev
Insert view 5.x-1.x-dev
Revision Moderation 5.x-1.0
Views Alpha Pager 5.x-1.1
Editview 5.x-0.1
Views 5.x-1.6
Views Actions Links 5.x-1.1
Views Bonus Pack
Views Calc 5.x-1.x-dev
Views RSS 5.x-1.6
Views Slideshow 5.x-1.x-dev
Views Theme Wizard 5.x-1.6
Views UI 5.x-1.6

We still have Modr8 5.x-2.2 installed but not currently enabled.

Does a conflict with any of these modules seem likely?

Thanks!

I'm running D5.2 as well and with 2 views modules enabled:
Views 5.x-1.6
Views UI 5.x-1.6

You have two options:
- try to catch the php error which causes the freeze (check the php logs)
- disable all views modules except for the two you need (views and views ui) and if this works, enable the modules one by one

A conflict is always possible. The logs will tell you what went wrong.

Looks like this is the error:

[Tue Sep 18 11:20:30 2007] [error] [client 38.99.44.102] PHP Parse error: syntax error, unexpected '<' in /var/www/html/users/wsbe/sites/all/modules/revision_moderation/revision_moderation.module on line 10

Ok, I suppose this was stupid of me, but I left the php tags around your code snippet. I have to go to class now, but I'll test this when I get back.

Works now, but interestingly, I had to attempt to create a new View before the new menu items would show up. In an existing View I couldn't see them, until after I tried to create a new View.

Great job on this module. I just love Views. :)

I'd like to suggest a change for the "Under Moderation" filter: can this be "Moderation State" with a pick list of "current", "old", and "under moderation", as in the view listing? I think this would be more flexible in the long run.

Ok, I knew this one was coming, although I didn't see an immediate reason to filter old current and old. But no problem. I'll look into it.

In the previous comment, I meant "on old and current". Regarding your issue in #11, you should clear the cache. You can do this in a clean way with the devel module (make the devel block visible and chose 'clear cache'), or in a not so easy way, administering the database and clear the cache table. Look for help on the many drupal views issues regarding this problem.

Bug on sort - "Revised by" column

When I try to sort a view by the "revised by" column, I get:

user warning: Unknown column 'node_revisions_name' in 'order clause' query: SELECT DISTINCT(node.nid), node.title AS node_title, node.changed AS node_changed, node.type AS node_type, users.name AS users_name, users.uid AS users_uid, node_revisions.uid AS node_revisions_uid, node_revisions.timestamp AS node_revisions_timestamp, workflow_states.state AS workflow_states_state, node.vid AS node_vid, node_revisions.vid AS node_revisions_vid, node.uid AS node_uid FROM node node LEFT JOIN workflow_node workflow_node ON node.nid = workflow_node.nid INNER JOIN users users ON node.uid = users.uid LEFT JOIN node_revisions node_revisions ON node.nid = node_revisions.nid LEFT JOIN workflow_states workflow_states ON workflow_node.sid = workflow_states.sid WHERE (workflow_node.sid IN ('7')) AND (node.type IN ('curriculum_page','event','external_links','faculty_staff','page','story')) AND (node.changed > 0 + 0) ORDER BY node_revisions_name ASC LIMIT 0, 20 in /var/www/html/users/wsbe/includes/database.mysql.inc on line 172.

New version attached with two adjustments:

1. You can now filter on the state based on #12 remarks
2. The bug from the previous comment, is eliminated. In fact, it's not possible to sort on the Revision Author name, because a handler is being used to retrieve the name, after the query is executed. Therefore, this sort possibility was doomed to fail. It's not possible to sort, but of course, it is possible to filter.

Install:

• Remove the .txt extension from the attached file and place it under the revision moderation dir
• Clear the views cache under http://yoursite.com/admin/build/views/tools

Thanks!

Following these steps (including clearing the cache), I see an error on the view:

warning: Invalid argument supplied for foreach() in /var/www/html/users/wsbe/includes/form.inc on line 948.

This error persists even after I disable sorting on the "revised by" column. After removing and re-adding the "Revision State" column, filter, and exposed filter, the error went away.

This should only affect people who had the first version and upgraded to the second.

One ease-of-use point: when I add a filter for other parameters, e.g. "node type", I get a selection menu in the filter editor and in the exposed filter that allow me to select all, some, or none of the items from a list. On the "revision state" filter, I have to select a revision state, then enter "yes" (or any text, really) into the blank field next to the state. This isn't very obvious. There is also no way to select multiple states. If the database won't allow multiple states to be selected because of the type of join or something, I can live with that, but it would be more clear if the drop-down showed "All", "Under Moderation", "Current", and "Old" or something like that, rather than expecting the user to figure out that they need to put text in an unmarked empty field.

I accept that the type of join/query doesn't support sorting by "revised by," but the option to sort is still there in the view editor. Is there a way to remove this option? I can remember not to enable sorting by "revised by," but others might not.

You are right about the 'sortable' still being there. I forgot to take it out from another place as well.
Its fixed now.

Regarding the raised issue in #17, here is a new version which enhances the UI and implements filtering of multiple revision states.

@ emdalton

If you consider it stable and working, post a comment so I can create a decent patch and it can be committed. The best test is of course when you use it in production.

Sorry, I haven't had a chance to test yet. I'll be trying it after I upgrade to Drupal 5.3 tomorrow.

Hi all,

The Drupal 5.3 upgrade blew up (twice). I've just finished rebuilding our site on a test server. I plan to test this patch today. I'm very sorry for the delay -- we need to remove the Workflow module altogether and just use revision moderation with this patch, and Workflow is not so easy to remove, as it turns out.

Attached is a patch which includes the views.inc file and patches the revision_moderation module. As soon as someone has applied this patch successfully, it can be marked as RTBC.

My apologies for how long it took to test this patch.

We had persistent conflicts between Revision Moderation and Workflow. I finally pulled out the Workflow module (as far as I could-- it doesn't uninstall gracefully), because I thought with Revision Moderation Views we wouldn't need Workflow anymore, as I could set up Views with RSS->email to get the notifications we need that there is content waiting to be reviewed and approved.

However, the problem with only using Revision Moderation is that it doesn't require approval of new content, only changes to existing content.

Previously we had used Modr8 for the approval of new content, but now Modr8 seems to be fighting with Revision Moderation, as well. We have Modr8 5.x-2.3 and Revision Moderation 5.x-1.0 with the patch above. When I create a new page, it goes into moderation. When, as an admin, I try to approve the page, a new revision is created which is still moderated. There seems to be no way out of this cycle.

What this means for us is that in order for Revision Moderation to work the way we need it to, we need it to restrict the creation of new content as well as existing content, if this is at all possible.

Ok, I have a workaround. We can set the default "published" value to "no" on our various controlled content types. We can use Views Actions to provide a way to set "published" to "yes" directly on the revision without creating a new revision. I can make a mini-view that will display this action on the top of the content (I think). Except that currently "published" state is not available in Views. Can that be rolled into this patch? It seems integral to revision moderation to be able to manage publication state per revision, and right now one can't publish a revision if the default publication state for the content type is unpublished-- every new revision will be unpublished, and the only way to publish it without creating a new (again unpublished) revision is to use Actions, but we can't display the current publication state in a View, so people will be trying to publish content that's already published, etc.

We're very close on this. I think this one additional enhancement will stabilize our system.

Interesting case. I'm not quite sure whether I can follow it precisely, but I think I can. Yet, I have doubts that this request is something for the revision_moderation module & views addon.

Lets go back to your initial problem:
"When I create a new page, it goes into moderation. When, as an admin, I try to approve the page, a new revision is created which is still moderated. There seems to be no way out of this cycle."

The main issue is that you want to able to approve a node, without creating a new revision. Right now, you probably go to /node/xx/edit and put the node on 'published' and you leave 'new revision under moderation' checked. When hitting the save button, this creates a new revision which is under moderation, right?

Is it correct that you wish to have a view of revisions, which includes the 'initial revision' of a new node which is in the 'unpublished' state? In this view, you wish to see an extra field with a link which offers you the possibility to put a node in the 'published' state the moment you hit that button. Right?

Is it correct that you wish to have a view of revisions, which includes the 'initial revision' of a new node which is in the 'unpublished' state? In this view, you wish to see an extra field with a link which offers you the possibility to put a node in the 'published' state the moment you hit that button. Right?
No, I can do that now, with Views and Views Actions. In fact, that's the only way I can get out of the loop I described above.

The problem is that I want new created content to require approval. Revision Moderation doesn't require approval of new content-- it only requires approval of new revisions of existing content.

To require approval of new content, I need to either use Modr8 or have new content unpublished by default. But either method gives me the same problem: I create a new page (or whatever), then I try to approve/publish it from a different account, but all attempts to approve/publish the content generate a new revision, which ITSELF still requires approval/publishing.

Thanks to Revision Moderation Views (your great patch), I can display a view of all revisions, and I can show which is the current revision. Using Views Actions, I can put a "publish" link in that view that lets me publish a specific revision WITHOUT generating a new revision. However, I can't display whether a specific revision is already published or not, because that's not a field available to the display in Views.

What I can do is filter on whether the node/revision is published, because that IS available as a filter in Views. (Which is bizarre.)

What I'm asking for at this point is for Revision Moderation Views to add the publication state of the node/revision to the list of fields available for display in a View. (If it were also possible to make the "make curent revision" function an Action that could be displayed in Views Actions, that would be extra wonderful.)

Oops - "Revert" revision is already an Action. So it's just the ability to display publication status that I need, at this point.

Then I can make a mini-View that will display as a block in the Content only if the page is unpublished, and will contain the "publish" Action link.

So, if you only want the state of the node/revision as a field, I guess this is more a patch for the views module. You're saying it is in the filter already. I guess adding a field for the state shouldn't be a big development issue. Did you post an issue on the views project already?

There are requests for this in Views already:

http://drupal.org/node/182997 (with possible patch)
http://drupal.org/node/165212 (I'd added a comment to this one back in September)
http://drupal.org/node/150366

Guess I'll look through the patch and see if I can make any sense out of it.

Because all previous comments are probably not related anymore to this issue, I report the link to the patch which should be reviewed. If we have some test results, it can be signed as RTBC.

http://drupal.org/node/118666#comment-638558

Patch is tested and appears to be working well. Sorry for the distractions about the other functionality.

As far as I'm concerned, it's ready to go. (With the caveat for potential users that it can conflict with Workflow, but there is a workaround: use the Workflow tab to change workflow status, DON'T edit the item directly.)

I adjusted the patch according to the previous comments. Thank you webchick.
RTBC

I checked out the D5 branch, deployed the module and made a view with it. It's being used in an intranet.

One remark: as I was creating a new view, I was looking to sort it by revision creation time and I noticed this is not in the views. I had to use the node last update time stamp. And this is not very convenient when you don't filter on any state. @emdalton, did you encounter this as well?

I looked at it again and not having the sort by the revision timestamp was really inconvenient. So here is an addon patch.
I deployed this patch in an intranet env.

Thank you! :) Yes, I had noticed this problem before. I thought I had commented on it, but maybe not. It's great to have a fix.

Hi all

I downloaded the dev version from 12/20/2007.

I created a view and added "Node revision: State" to the filter list. When I viewed the page, I got a sql error.

For some reason, line 124
'value-type' => 'array',
was commented out. When I removed the doubles slashes, the sql error went away and the view seemed to work as it should.

@jbjaaz

Thx for the report. Indeed, it has been commented out. I don't know anymore why I did that since it has been a couple of months now, but I guess it did this because I was testing. Anyway, lets find the solution.

First thing I need to know, what views version are you using?
I tried to reproduce your problem but without success. I'm using the latest views 5.x-1.6. What version do you use?

toemaz

I'm also using views 5.x-1.6

Here's the steps I took to reproduce the problem.

- added the slashes back to line 124
- cleared cache
- refreshed page and got warning: Invalid argument supplied for foreach() in /projects/aac/dev/public_html/sites/all/modules/revision_moderation/revision_moderation_views.inc on line 137.
- removed the slashes from line 124
- refreshed page, got user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 1 query: SELECT DISTINCT(node.nid), node_revisions.title AS node_revisions_title, node_revisions.vid AS node_revisions_vid, node.type AS node_type, node_revisions.uid AS node_revisions_uid FROM node node LEFT JOIN node_revisions node_revisions ON node.nid = node_revisions.nid WHERE () in /projects/aac/dev/public_html/includes/database.mysql.inc on line 172.
- cleared cache
- refreshed page
- worked as advertised

Thanks for this, it did the trick for me :)

Based on #49 and #48, I made a simple patch which solves this single issue with the views integration.

Hello,

I've got a SQL issue when I try to display a block created with Views using a "Node revision : state" filter. The SQL error changes according to the displaying circumstances of the block, but here is an exemple :

user warning: Unknown column 'node_revisions.vid' in 'where clause' query: SELECT DISTINCT(node.nid) FROM node node INNER JOIN node_access na ON na.nid = node.nid WHERE (na.grant_view >= 1 AND ((na.gid = 0 AND na.realm = 'all') OR (na.gid = 2 AND na.realm = 'workflow_access') OR (na.gid = 3 AND na.realm = 'workflow_access') OR (na.gid = 2 AND na.realm = 'workflow_access_owner'))) AND ( (node_revisions.vid > node.vid) AND (node.type IN ('article')) ) LIMIT 0, 10

Sometimes, it's only a basic error in declaring the using tables.

Allright, I tried all your patches but I stuck with the #25 and commented out line 124 and cleared cache. And I already patched revision_moderation.module once but your patch only adds 3 lines and doesn't substract lines.

Thank you for helping me

Hi kirby,

Reading the second half of your comment, it's becoming clear that this issue is becoming hard to track. I should have closed it earlier and opened new issues for each patch/bug.

Anyway, I don't know whether you knew this already but the patch in #25 is already applied to the 5.x-1.x-dev version of the revision moderation module. The patches in the following comments are small adjustments which still need some testing. If you did apply them and tested, please leave a comment so they can be set RTBC.

Now regarding the problem you reported: indeed it might be just a basic error in declaring the using tables. It looks like you know something about it, so my question to you: would you be able to fix this problem? My focus is not on the development of this module for the moment so it would be great if you could just leave a comment on how you fixed it. It would be superb if you could attach a patch as well.

Thx!

Unfortunately, I'm only a beginner in Drupal for now. I'll probably return on this later, now and I have plenty of issues I have to work on for the website I have to design.

I hope I'll be able to fix it when I come to this.

I'd like to close this issue since it deals with several (bug & feature) reports at the same time. It's better to open new issues for each.

For comment #46 (opened by jbjaaz), a new issue is opened at http://drupal.org/node/217197 and the patch provided to #50 is attached to that new issue.

For comment #42, a new issue was opened at http://drupal.org/node/217347 and the patch is moved as well.

Issues is now closed and hopefully the above issues can be fixed asap since Drupal 6 is on the way.

as I could set up Views with RSS->email to get the notifications we need that there is content waiting to be reviewed and approved.

How did you do this? I can't find any instructions on how to do this and it's exactly what I'm looking for.

Thanks!