[drupal-devel] [bug] new revisions not created if user doesn't have administer nodes permission

killes drupal-devel at drupal.org
Sun Mar 13 22:33:47 UTC 2005

Issue status update for http://drupal.org/node/12401

 Project:      Drupal
-Version:      4.5.0
+Version:      cvs
 Component:    node system
 Category:     bug reports
-Priority:     critical
+Priority:     normal
 Assigned to:  wazdog
 Reported by:  wazdog
 Updated by:   killes at www.drop.org
 Status:       patch
 Attachment:   http://drupal.org/files/issues/node-rev_0.patch (981 bytes)

Still applies, but I updated it anyway.

killes at www.drop.org

Previous comments:

November 1, 2004 - 09:33 : wazdog

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


November 3, 2004 - 01:48 : wazdog

Attachment: http://drupal.org/files/issues/node-rev.patch (721 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).


January 14, 2005 - 21:54 : mcd

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
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.


January 14, 2005 - 21:56 : mcd

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


January 14, 2005 - 22:11 : chx

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.


January 14, 2005 - 22:18 : mcd

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.


January 14, 2005 - 23:32 : robertDouglass

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
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


January 18, 2005 - 08:10 : wazdog

Ultimately, an "edit" permission would encompass the permission needed
in a "rollback revision" permission, as the latter is a subset of the
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).

More information about the drupal-devel mailing list