So I'm working on a project now where nodes are mass-imported from a third party. By default, these nodes are unpublished until the delegated party can add additional information that the import can't capture. We publish the node when it's through being reviewed and updated.
To be clear, the workflow looks like:
1) Import nodes (CCK type: "Item"), default status is Unpublished.
2) User with "Reviewer" role looks at the queue of Items that needs reviewed
3) Reviewer reviews Item nodes, then sets them as Published.
Here's the problem though:
A Drupal user role can't publish/unpublish nodes without the "Administer Nodes" permission from node.module. Whoops! That means the subset of users we entrust to review and publish these nodes can also delete them, create new nodes of any type, and so forth. Far from ideal.
The solution is a mashup of code I assembled together. First on the list is the Override Node Options module. This module allows a Role to be able to publish/unpublish the nodes they already have permission to Create or Edit.
That's all fine and good, but they won't be able to *see* those unpublished nodes to make the change (they'll get tossed to an access denied page) without the View Unpublished module. Put these two together and we can do this!
Step 1: Grab and install the modules
Download the Override Node Options and the View Unpublished modules. Install them.
Step 2: Permissions
Navigate to your access control page at /admin/user/access and set the following permissions for each role you want to do this for:
"override node publishing options" - checked
create/edit XXXX content - checked as appropriate (where XXXX is the content type you want to enable this for).
"use view_unpublished module" - checked
"view unpublished XXXX content" - checked (where XXXX is the content type you want to enable this for).
That's it! Simple! Those roles can now publish and unpublish content for the node types you enabled in step 2, and view those same ones when they're unpublished.
Caveats:
This isn't going to change your Views, so if you have a published = yes filter on a View, that's something to be aware of. On this project I'm on, I've got a seperate view where published = no, specifically.
Shout out:
Thanks to Brad Bowman for the view_unpublished code. Standing on his shoulders I modularized it and took care of module weight (has to be lighter than node.module -- the install hook should handle this automagically now).
domenic's blog
Comments
Fantastic timing! I was
Fantastic timing! I was beginning to beat my head against the wall trying to find a solution to this issue. Thanks for the HowTo
View Unpublished
One problem with the View Unpublished module - it doesn't appear in the modules list so it can't be activated?
It does; make sure it's
It does; make sure it's unzipped into the right location.
Oh, eek, I think I may have made the tarball without a parent directory. I'll fix that up, but in the meanwhile take a look at where the files got untarred to -- I bet that's the issue.
Tracked down what it was and
Tracked down what it was and you were almost right with the no parent directory thing. I use Gnome and when right-click Extract here, it automatically created a directory but without execute rights for group/others!
Fixed that and I am now testing this out. Once again thanks for the module.
OG!
This would be a great way to use OG/OG User Roles. I used this combo for our corporate intranet. Add the nodes to a particular group to which the "Editor" or "Admin" is part of that group, and you can assign special access controls for that group's content. works like a charm and they only have the roles within that group.
OG == overkill for this?
I can see how that would definitely work, but OG tends to create huge levels of complexity for something as basic as permissions control.
Domenic put up a dev release of the view_unpublished module on drupal.org. Please feel free to take a look there and provide feedback.. We'd love to get this to stable, and can use all the help we can get.
Post new comment