If you enable revisions for a node type via content > configure > default workflow, and the user who is editing a node of that type doesn't have the administer nodes permission, then a new revision is not created.

I see this a huge bug. I am trying to have all edits to a node type saved as revisions (in this case a flexinode, but I also tested with blog types). I want to recreate the book pages, but with more fields (hence, flexinode).

But if one of my authenticated users creates a node, and then later edits it, a revision is not made. However, if an admin or moderator (who both have the administer nodes permission) edits the node, a new revision is created. I don't want my regular users to have administer nodes permission, that gives them too much power, but their revisions need to be kept (just like I give them all publish permission via default workflow).

If this is supposed to be how it works, what is the point of the default workflow setting? (and why do the other default workflow settings behave differently? i.e. they all apply no matter the users permissions)

CommentFileSizeAuthor
#8 node-rev_0.patch981 byteskilles@www.drop.org
#1 node-rev.patch721 bytesjoshuajabbour
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

joshuajabbour’s picture

joshuajabbour CreditAttribution: joshuajabbour commented
Assigned: Unassigned » joshuajabbour
Priority: Normal » Critical
FileSize
node-rev.patch721 bytes

Okay, here's a short little patch. It seems like node_create_revision() was being called before $node->revision was set. Since $node->revision is what tells Drupal whether or not to make a new revision, this was causing nodes to not keep revisions. I moved node_create_revision() to after this check.

I'm not sure exactly why only regular users without 'administer nodes' permission were affected, but that seems the case.

Now, if a particular node type has 'revision' checked in content > default workflow, a new revision is always created, no matter who is doing the editing...

I'm setting this to critical because I think the current behavior goes against logic, and what admins may expect. And if they don't notice it's not working like they expect (i.e. revisions aren't being kept always), then content is lost...

The patch is against 4.5.0, but always applies to current cvs (with a slight offset error).

mcd’s picture

mcd CreditAttribution: mcd commented
Title: new revisions not created if user doesn't have administer nodes permission » non-intuitive revisions

I tried this patch against 4.5.1 and it worked, but it took me some time to figure out that it was working because it's still not doing the intuitive thing. The user still can't see the revisions tab unless they have node administration privileges (which makes it unlike the outline tab). They can't see the checkbox to decide whether their edit is a new revision, so every edit they do becomes a revision from which they derive no benefit.

I would let them see the revision checkbox and the revisions tab, and also roll back (non-destructively as suggested in http://drupal.org/node/12479).

I don't think there is an intuitive way to handle the five node administration Options checkboxes as a group while appearing to enable them separately in the default workflow. I've had similar issues with the defaults, like a page I made sticky coming unstuck every time the owner edited it (with the default non-sticky in the workflow). Now I see why that was happening, but it's still highly counterintuitive.

mcd’s picture

mcd CreditAttribution: mcd commented
Title: non-intuitive revisions » new revisions not created if user doesn't have administer nodes permission

Sorry, I didn't mean to change the main title.

chx’s picture

chx CreditAttribution: chx commented

IMHO in some situations it is a good thing if a new revision is created every time a user edits the node. It's not her privilege to roll back, it's something a moderator should do. It'd be even better if the new revision would not be automatically published only after approval by the moderator.

mcd’s picture

mcd CreditAttribution: mcd commented

Rolling back nondestructively is just a means of editing a page. Why should a user with permission to edit be prevented from that edit? They can certainly do more destructive things.

As for creating new revisions every time, it depends on usage patterns. You may not want too many almost indistinguishable revisions collecting in the revisions tab.

robertDouglass’s picture

robertDouglass CreditAttribution: robertDouglass commented

My opinions:

1. administer nodes is the wrong permission to determine revisions behavior. At least one revision-specific permission is necessary, perhaps two or more (view, create, delete, rollback revisions).

2. If the default workflow says revisions are made, this should definitely make it so that normal users create revisions every time.

3. Users with admin rights (either a revisions specific permission or administer nodes) can override the default. All others should not see the checkbox.

4. Whether revisions are rolled back destructively or non-destructively *could* be a setting, but if not, should be non-destructive by nature as we already have a mechanism for deleting revisions.

-----
That much is the minimum I consider necessary to be a useable system. I would additionally wish for the following:

5. Since I would like to have a site where normal users can view any of the revisions, but not delete and not roll back, I would really like to see the following permissions: read revision, rollback revision, delete revision

6. The ability to compare two or more revisions [1]

7. The possibility for moderation of revisions ie. people with administer nodes (or moderate revisions) look at a queue of revisions and rollbacks and approve or disapprove them.

8. The possibility to vote on revisions. 7 could be an extension of 8. If only administrators can vote on revisions, it would be the same as moderating them.

I know the last bits sounds like a bunch of pipe dreams, and may be off topic for this thread, but the system I imagine would be for a site where the wording of entries must be considered very carefully by many people and a concensus about the best version be found. The above features would achieve this.

[1] http://drupal.org/node/15596

joshuajabbour’s picture

joshuajabbour CreditAttribution: joshuajabbour commented

Ultimately, an "edit" permission would encompass the permission needed in a "rollback revision" permission, as the latter is a subset of the former.

Therefore, if a user can edit a node, they should be able to rollback a revision (though deleting a revision should still be a different permission, because it is destructive).

killes@www.drop.org’s picture

killes@www.drop.org CreditAttribution: killes@www.drop.org commented
Priority: Critical » Normal
FileSize
node-rev_0.patch981 bytes

Still applies, but I updated it anyway.

Steven’s picture

Steven CreditAttribution: Steven commented

I applied the patch to HEAD. Marking this as active for the rest of the discussion.

mcd’s picture

mcd CreditAttribution: mcd commented

I had the same issue with comments. (If the user didn't have permission to administer comments, then the workflow comment setting was ignored and all nodes created by the user were set to comment=0 instead of the workflow default of comment=2). I suppose it should be a new bug, but since it's related and hard to explain without the background, I'm putting it here.

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented
Category: bug » feature
imaclaiguana’s picture

imaclaiguana CreditAttribution: imaclaiguana commented
Version: » 4.6.0

Hello there eveyone--

This problem is a big headache for me, I am currently putting together a site and I want revisions to work, but I cannot give "administer nodes" access to all users.

I am currently using Drupal 4.6.0. I looked at the patches posted here, but I have not been able to figure out how to apply the patch to this version of Drupal.

Could someone post a patch for 4.6.0? I would be quite grateful. Thanks in advance!

veelo’s picture

veelo CreditAttribution: veelo commented

The mentioned patch has been incorporated into 4.6.0 already (see #9). However, the problems mentioned in #2 still count, as they are not addressed by the patch.

Bastiaan Veelo.

magico’s picture

magico CreditAttribution: magico commented
Status: Active » Fixed
Anonymous’s picture

(not verified) CreditAttribution: commented
Status: Fixed » Closed (fixed)
amcoms’s picture

amcoms CreditAttribution: amcoms commented

not sure if i am reading this correctly, is it necessary to create a super admin to assign super admin user permissions for admin modules? I was on the understanding that user 1 had super admin permissions