Home ›
Agaric Wants: set 'view revisions' permission by content typeAgaric Wants: set 'view revisions' permission by content type
Submitted by Benjamin Melançon on September 30, 2007 - 8:06am
Naturally, if you have a wiki content type, you want everybody to be able to view revisions. Odds are they may have an edit tab also.
But do you really want a big "Revisions" tab and a redundant "View" tab added at the top of your carefully crafted about us page, the one where you just deleted all references to your collective cofounder and you really don't want anyone looking at revisions anyway?
One solution is simple: "View Revisions" has to be a per-content-type user access permission, as edit and all already are. Granted, this will make the user access settings page even more humongous than it already is (I wonder if, with CCK in core, node type based permissions should perhaps get their own page).
Are there other ways around this? Say, if you don't care that people could see revisions by finding the node number and adding /revisions to it, and all you want to do is hide the tab for most people for most content types? I think the real solution is better than the cosmetic.
So, can a contributed module add these permissions and have them used, or does it have to go in core?
Resolution
Searched words:
view revisions by content type permissions
Drupal user access privileges for viewing revisions of nodes set by content type
Comments
View revisions only if you have edit access modification
Not sure if you still need this or what version of Drupal you are referring to...but since I was looking for the same and ended up doing it myself (and this was the top result in google), I decided to share the solution. The solution works perfectly, but is not a good solution as it requires editing the core node module which makes upgrades one more step difficult. If someone comes up with a better one that does not require editing core, I'd be happy to adopt it myself.
The solution is to only allow access to see the revisions if you have access to edit the node. This makes perfect sense as if you can't edit it, why should you see revisions?
Here is how it works.
You have to edit three lines.
Line 1213:
FROM
$revisions_access = ((user_access('view revisions') || user_access('administer nodes')) && node_access('view', $node) && db_result(db_query('SELECT COUNT(vid) FROM {node_revisions} WHERE nid = %d', arg(1))) > 1);
TO
$revisions_access = ((user_access('view revisions') || user_access('administer nodes')) && node_access('update', $node) && db_result(db_query('SELECT COUNT(vid) FROM {node_revisions} WHERE nid = %d', arg(1))) > 1);
LINE 2397:
FROM
if ((user_access('view revisions') || user_access('administer nodes')) && node_access('view', $node)) {
TO
if ((user_access('view revisions') || user_access('administer nodes')) && node_access('update', $node)) {
LINE 2406:
FROM
if ((user_access('view revisions') || user_access('administer nodes')) && node_access('view', $node)) {
TO
if ((user_access('view revisions') || user_access('administer nodes')) && node_access('update', $node)) {
And that's it. It is pretty simple.
Hope this helps someone.
... and a module in the works from George Cassie
Thanks majorxp, and thanks even more George! We look forward to checking it out and probably starting to use it on most sites for that extra level of control over which roles can access revisions on certain node types.
Post new comment