Project: Drupal Version: 4.5.0 Component: node system Category: bug reports Priority: critical Assigned to: wazdog Reported by: wazdog Updated by: chx Status: patch 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. chx 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 permissions) ------------------------------------------------------------------------ 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 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. ------------------------------------------------------------------------ January 14, 2005 - 21:56 : mcd Sorry, I didn't mean to change the main title. -- View: http://drupal.org/node/12401 Edit: http://drupal.org/project/comments/add/12401