January 2005 - Development - lists.drupal.org

[drupal-devel] [feature] let admins mass delete nodes
by Bèr Kessels 15 Jan '05

15 Jan '05

Project: Drupal Version: cvs Component: node system Category: feature requests Priority: critical Assigned to: Bèr Kessels Reported by: killes(a)www.drop.org Updated by: Bèr Kessels Status: patch Attachment: http://drupal.org/files/issues/batch_delete_4-6.patch (6.66 KB) Updated for 4.6. (hint, hint) Bèr Kessels Previous comments: ------------------------------------------------------------------------ May 12, 2004 - 16:44 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/node_2.patch (1.41 KB) It would be nice if admins could mass delete unpublished nodes. The attached patch allows this. It also improved error handling. ------------------------------------------------------------------------ May 12, 2004 - 20:48 : Kjartan Looks good to me. Since it only allows deletion of unpublished nodes there probably isn't need for an approval page? Thats the only thing I can think of as a critism. Everything else is reversable, but delete is permanent (unless the site has some form of backup). ------------------------------------------------------------------------ May 12, 2004 - 23:43 : killes(a)www.drop.org Well, I found I'd need this capability and therefore coded it. I don't know how to fit a "are you sure" page in that filter mechanism. ------------------------------------------------------------------------ May 13, 2004 - 00:34 : killes(a)www.drop.org Teh patch also does not call the neccessary delete hooks thu sleaving data in additional tables like event or flexinode. ------------------------------------------------------------------------ May 13, 2004 - 20:08 : Dries Setting the status to 'active' until it works like it should. ------------------------------------------------------------------------ June 29, 2004 - 22:01 : killes(a)www.drop.org Ber is developing a better patch. ------------------------------------------------------------------------ June 29, 2004 - 22:33 : Bèr Kessels Attachment: http://drupal.org/files/issues/batch_delete_easy_coding.patch (4.16 KB) Extracting the bits and bytes from http://drupal.org/node/view/5162. Hope it might help bring life into this feature. Overall my comment is that that part of node.module is quite messy. There's html hardcoded and the function handling this part is one big bloat of code. That makes it kinda hard to fix this issue in a more elegant way, without cleaning up that mess before. I would like to use a nicer method of confirmation once this part is cleaned. But as it currently stands thats a quite hard task. ------------------------------------------------------------------------ June 29, 2004 - 22:46 : Bèr Kessels Moshe had some better ideas. Those need a lot more coding however. moshe_work>I think you can give a confrim screen just like we do for nodes, comments, etc. moshe_work>"You are about to delete ..." and then do a theme(item_list, $items) showing all the titles moshe_work>you would want to stick all the nids about to be deleted in a hidden form field the problem with this is, that somehow you need to bypass the update and filter form generation. Since that whole admin part is gernerated in one big (120 + lines.) function node_admin_nodes() this needs some work too, if you wnat to apply moshe's idea. For now i am satisfied with the above attached patch. And I would like to hear feedback about the UI for confirmation. Regards ------------------------------------------------------------------------ June 30, 2004 - 09:09 : stefan nagtegaal Can you show us some screenshots Ber? ------------------------------------------------------------------------ June 30, 2004 - 10:20 : Bèr Kessels Attachment: http://drupal.org/files/issues/batch_delete_step1.png (18.8 KB) Screenshot: first you select the nodes you want to have deleted. Than from the dropdown you select "delete selected nodes". ------------------------------------------------------------------------ June 30, 2004 - 10:22 : Bèr Kessels Attachment: http://drupal.org/files/issues/batch_delete_step2.png (26.77 KB) After pressing [update] you see the screen back, and in the "update actions dropdown" you get a confirmation. ------------------------------------------------------------------------ June 30, 2004 - 10:22 : Bèr Kessels Attachment: http://drupal.org/files/issues/batch_delete_step3.png (15.72 KB) after pressing [update] again the nodes are actually deleted. ------------------------------------------------------------------------ June 30, 2004 - 14:59 : Dries Wouldn't a dedicated confirmation page be a lot better usability-wise? At least, that's what one would expect. ------------------------------------------------------------------------ June 30, 2004 - 15:52 : kika Attachment: http://drupal.org/files/issues/typepad_multiitem_deletion.png (54.11 KB) please, resign step 2 in you patch and build a proper confimation page. Have look at the screenshot included, this is the Typepad multi-item-deletion workflow (scroll down) ------------------------------------------------------------------------ June 30, 2004 - 15:57 : Bèr Kessels True Dries, kika, thats why I pasted some comments in http://drupal.org/node/view/7743#comment-9138. I see only one big issue in the typepad approach. That will do for deleting, but our range of updating- actions will not work there, or you would need 5 columns of selection boxes. IMO thats a no-go. I linke the current method. My gmx mail uses that, and Ive seen it a lot. The dedicated screen for confirmation is a good idea, but kinda hard to code, in the current state. The big problem is that I tried that raod first (it seems much more logical to go for that). But untill the node_admin_nodes() gets a big cleanup, I think that adding a dedicated UI is a pain, and will make the mess even worse. :( So in fact the road to take here (IMO) is: 1) clean up the node.module admin area. 2) split all actions into separate functions (e.g. node_admin_update_promote($nodelist) ) 3) add a function forbatch deleting 4) maybe add some more actions (e.g batch re-taxonomising) I tried to skip 1 and 2 and go straight for 3, but I ended up with 3-levels deep nested ifs nad foreaches and a 200+ lines big function node_admin_nodes(). And still it had some bugs. I might have done it worong there, but that made me decide to use this much simpler approach. ------------------------------------------------------------------------ June 30, 2004 - 15:59 : kika to clarify: I am not suggesting to use popup, just a standard confimation page ------------------------------------------------------------------------ July 1, 2004 - 10:29 : Bèr Kessels Allright, All has been said, little done. I think we all agree on the fact that there should be some confirmation screen. But, as i pointed out, that will not be there for a while. Unless someone else takes this task and does a total revamp of (the code of) the node admin UI. So, if we want some batch deletion, I would suggest to either start coding and come up with a better UI, or use this solution. Regards, ------------------------------------------------------------------------ July 1, 2004 - 11:58 : Dries I don't intend to commit this patch as is. I'll see if I can make a confirmration screen. Marking this active in the mean time. ------------------------------------------------------------------------ July 23, 2004 - 19:23 : laird This patch is wonderful; I install it everywhere I use Drupal (several sites now). I'd like to make two feature requests: 1) It leaves behind records in the node-type specific tables. For example, if you have node 1000 that's an image, this patch will delete node 1000 from the node table, but won't delete node 1000's entry in the image table. This isn't a huge problem, since it doesn't cause anything to break (since they're not linked anywhere, so don't appear in any selects joined against the node table). But it's a bit messy to leave these disconnected records around in the database, so it should be fixed on general principles. 2) If you are deleting a large number of nodes, you have to manually click on each check box, then delete the batch. It'd be great to have a 'check all' button, to speed the process. It'd be even better to have a means to 'delete all unpublished nodes' as a one-click way to clean up the database. I have several automated feeds on one site, and it accumulates tons of unused nodes that are quite tedious to delete manually. - LP ------------------------------------------------------------------------ August 15, 2004 - 21:59 : Anonymous newbie who needs help how do you incorporate the patch file into the node.module file? does it have to be in a certain area or just at the top of the code? ------------------------------------------------------------------------ August 15, 2004 - 22:00 : Anonymous newbie who needs help how do you incorporate the patch file into the node.module file? does it have to be in a certain area of the code? ------------------------------------------------------------------------ August 16, 2004 - 11:49 : Bèr Kessels please refer to http://drupal.org/book/view/323 for info about patching. And please be aware that you should be carefull with changing the category of an issue. ------------------------------------------------------------------------ August 25, 2004 - 11:51 : Bèr Kessels Attachment: http://drupal.org/files/issues/batch_delete_with_confirm page.patch (6.41 KB) Final attempt. Now with a default confirmation screen. That confirmation shows a list with titles of all nodes that are about to be deleted. ------------------------------------------------------------------------ October 29, 2004 - 19:46 : mpamphile Is this patch 4.5 compliant ? I would like to add it to a 4.5 site. If anyone is intrested, I'm also modifying taxonomy.module so that multiple terms can be added. If anyone is interested in this, let me know... mpamphile hotmail . com. ------------------------------------------------------------------------ December 9, 2004 - 02:09 : michaelemeyers can this be added to core? Very valuable/useful patch... thnx. _m re - mpamphile on October 29, 2004: Is this patch 4.5 compliant ? I just patched 4.5.1 and other than line numbers being slightly off, the only difference was that in the Menu callback function node_admin() I needed to make the following change: case t('Delete'): // $output = node_delete($edit); // remove this and add line below $output = node_admin_nodes($edit); break; -- View: http://drupal.org/node/7743 Edit: http://drupal.org/project/comments/add/7743

1 0

re: [drupal-devel] [feature] node_delete doesn't pass params to_deletecalls.
by Kent Livingston 15 Jan '05

15 Jan '05

oops... Thought I was replying to the message below the one that I actually did :-)... It actually made sense in context to my friend who was saying she was looking for intelligent men.... "Kent Livingston" <klivingston(a)worldwebsystems.net> wrote: __________ > >At least you still, theoretically, believe there are intelligent men in the universe. > >Kent Livingston/World Web Systems >Strategic Network, Web, and Email Systems - Sent via a wireless PDA > >darrian <drupal-devel(a)drupal.org> wrote: >__________

1 0

re: [drupal-devel] [feature] node_delete doesn't pass params to _deletecalls.
by Kent Livingston 15 Jan '05

15 Jan '05

At least you still, theoretically, believe there are intelligent men in the universe. Kent Livingston/World Web Systems Strategic Network, Web, and Email Systems - Sent via a wireless PDA darrian <drupal-devel(a)drupal.org> wrote: __________

1 0

[drupal-devel] [feature] node_delete doesn't pass params to _delete calls.
by darrian 15 Jan '05

15 Jan '05

Project: Drupal Version: cvs Component: node system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: darrian Updated by: darrian Status: patch A group is in fact multiple nodes. I did it this way for a few reasons, one of them being other modules (such as remindme) work with it better this way. I am no longer working on development of this feature, so I am not going to redesign the way its done. I only try and keep it updated so other people that need this feature can use it, seeing as there is no other alternative. As for this particular patch to node.module I still think it is a bug because variables available the first time any _delete function is called dissappear after the confirm step. Those variables should be available to module developers regardless of how they are used. -Darrian darrian Previous comments: ------------------------------------------------------------------------ June 18, 2004 - 21:07 : darrian Attachment: http://drupal.org/files/issues/node.module-cvs.patch (872 bytes) When you delete a node, it asks for confirmation, after that step all extra fields in $node get lost because $node is recreated with only 2 fields, nid and confirm. I created a small patch that adds extra fields back into the $node variable so they get passed to subsequent _delete calls. ------------------------------------------------------------------------ June 27, 2004 - 20:29 : Dries AFAIK, deleting a node works fine. How can we reproduce your problem? Not sure what you are trying to accomplish but this patch looks wrong. ------------------------------------------------------------------------ July 12, 2004 - 23:05 : darrian Right, this patch is so the modification I made to event.module works. I added functionality for repeating events to event.module, and in order for the delete to work I had to make this small change outside of event.module (believe me I really tried not to). What this patch does is pass variables originally passed to the delete function to whats called after the user clicks confirm. In other words when a user clicks delete the first thing they get is a prompt to confirm deletion, after the user clicks yes, the delete function is called, but the only variables that are passed are nid and confirmed, all other variables are lost, which is usually ok because no other vars needed for deletion, however in my case I needed another variable. This patch has no effect on all current modules, the reason i made this a bug report is because it seems to me like variables originally passed to node_delete should still exist after the user clicks confirm, even though current modules dont use other vars. I made a reference to this bug from this bug: http://drupal.org/node/view/4122 If the changes I made to event.module ever get put into the current cvs version, then this patch also needs to get put in. -Darrian ------------------------------------------------------------------------ July 13, 2004 - 07:28 : Dries When an event (node) is deleted, the _delete hook is called and the event (node) is passed as a parameter. That seems to work for all other node modules/types so I don't understand why this shouldn't work for the event module. What is so special about this particular field or node type that this does not suffice? ------------------------------------------------------------------------ July 14, 2004 - 14:14 : darrian $node is passed, but after the user clicks confirm, $node only has two fields, nid and confirm. I need an extra field, which is whether I'm supposed to delete only this event, or all events in the group. This is for the reocurring events feature I added. My modification adds the extra fields originally in $node back to $node after the user clicks confirm. -Darrian ------------------------------------------------------------------------ August 2, 2004 - 16:27 : darrian In order for my repeating/reocurring event module patch to get submitted to cvs, this very small patch needs to make it into core. It does not effect the functionality of anything current. Here's the details of what happens, >>> is what happens when my node patch is there: 1. User is looking at the form to delete an existing event, there are a bunch of fields like date/time title, etc. This holds true for any node, but I am going to reference an event node. 2. User clicks delete to delete the node being looked at. (User checks to delete all events in this group - from my event patch) 3. All the fields for that node are a form element at this point, some hidden, like nid, and a variable I set telling the event_delete function to delete all events in this group. 4. The code makes its way to the node_delete($edit) function. At this point all the form elements from above are members of the $edit variable, including my variable mentioned above. 5. The code checks to see if the user already clicked confirm, at this point they haven't. 6. Now we're in the else branch that creates only two form elements, the nid, and confirm. This has been ok in the past, because the only thing that you needed to delete a node was its nid. But in my case I want to delete multiple nodes, so this doesnt work. >>> My node patch creates hidden form elements of all the previous variables, not just nid and confirm. 7. The code makes it way back to node_delete, this time however there are only two members of $edit, nid and confirm. 8. The code checks to see if the user has clicked confirm, and they have. 9. Now we're in the true branch which deletes the core node components, then calls the node specific delete function, in our case the event_delete function, passing only the nid and confirm variables. >>> My node patch makes it so all variables, including my varible to check whether we're deleting all nodes or not, are passed back in. 10. Now we're in the event_delete function. The event delete function checks for the variable to see if we're deleting all events in group, it doesnt exist, so it acts as if the user didn't check to delete all events, and deletes just this event. >>> With my patch, all previous variables still exist, so event_delete knows that it needs to delete multiple nodes. Hopefully this patch gets into core before feature freeze for the sake of the event module. If it doesnt, then my patch for repeating/reocurring events also cannot make it into cvs. Thanks, Darrian ------------------------------------------------------------------------ August 2, 2004 - 17:29 : moshe weitzman the patch looks good to me. thanks for the clear description of the bug. ------------------------------------------------------------------------ August 13, 2004 - 08:03 : TDobes +1, except the single comment prefixed with a # should be changed to // ------------------------------------------------------------------------ August 16, 2004 - 21:57 : darrian Does the code freeze mean that this patch wont make it into 4.5? -Darrian ------------------------------------------------------------------------ August 16, 2004 - 22:31 : Steven This sounds like a bugfix or at least code fix, so it can still go in. I'm wondering about your description though. It sounds that if I first edit a couple of fields, then click delete, then my edited variables are passed around rather than the original ones. Because I did not click 'submit', this is not desirable. It may be better to call node_load() before deleting the node, so the correct, original data is passed to the nodeapi. ------------------------------------------------------------------------ August 17, 2004 - 01:09 : darrian Remember, for node_delete, only nid and confirm are passed. But I already do as you suggest, to be more specific: node_load is called, those variables, along with extra fields that are not loaded with node_load (such as my variable for deleting group events), are passed to subsequent _delete calls. Just to re-iterate, without this patch the ONLY variables that make it to the final delete call are nid and confirm. -Darrian ------------------------------------------------------------------------ August 17, 2004 - 01:55 : JonBob The point is that (efficiency aside) if you have the node ID, you can reconstruct the node with a simple node_load() call. If your delete function is called with only $nid, you can use that to load the whole node again if need be. Now this may not be enough in your case, as you are presenting additional interface to the user that adds fields to $edit that are not part of the node, but all the parts *of the node* are certainly available to you. ------------------------------------------------------------------------ September 5, 2004 - 17:47 : Steven "The point is that (efficiency aside) if you have the node ID, you can reconstruct the node with a simple node_load() call. If your delete function is called with only $nid, you can use that to load the whole node again if need be." At the point where hook_delete gets called, the node itself has been deleted already, so reconstruction is not an option. The point here seems to be to pass variables from the editing form to the delete operation. I'm not sure if this is a good idea. If it's not about this, then maybe we should invoke deletes in the opposite order: nodeapi, hook, node.module. ------------------------------------------------------------------------ September 9, 2004 - 23:05 : darrian Right, the point is to get variables from the form passed to the delete function, namely 1 variable, which tells me if I should delete 1 event, or all grouped reoccuring events, that I need for the modification I made to the event module. The way I made the modification is very UN-obtrusive. No variables get squashed, and everything current ignores the new variables. Also, the variable that I want exists in the node_delete function the first time around, its only after the user clicks confirm that all variables except the nid are lost. So I could delete things with my modified event module if i skip the confirm step, but I'm sure that would bite someone down the road and I really dont want to do it that way. -Darrian ------------------------------------------------------------------------ October 4, 2004 - 21:06 : Steven "Right, the point is to get variables from the form passed to the delete function, namely 1 variable, which tells me if I should delete 1 event, or all grouped reoccuring events, that I need for the modification I made to the event module." This sounds like really bad UI: the rest of the node form is about data related to the node, which gets saved when you click "submit". Adding a delete-related checkbox there sounds odd and confusing. ------------------------------------------------------------------------ October 8, 2004 - 21:58 : darrian Attachment: http://drupal.org/files/issues/editevent.png (35.72 KB) Here's the UI i'm referring to. This patch to node.module is extremely small and unobtrusive... Why so much resistance to it? ------------------------------------------------------------------------ January 12, 2005 - 22:47 : darrian Attachment: http://drupal.org/files/issues/node.module-4.5.1.patch (822 bytes) Here's an updated patch for drupal 4.5.1 -Darrian ------------------------------------------------------------------------ January 13, 2005 - 00:28 : tangent Is a recurring event a single node or a group of nodes? Without getting into the appropriate implementation of that, your bug suggests that the checkbox will allow multiple nodes to be deleted. This is why it has been suggested that it is a confusing UI. It isn't necessarily clear what the "group" of nodes is? FWIW, if a recurring event is a single node (which is displayed in multiple places on the calendar) then this would not be an issue. -- View: http://drupal.org/node/8611 Edit: http://drupal.org/project/comments/add/8611

1 0

[drupal-devel] [task] Improve story help texts
by Bèr Kessels 15 Jan '05

15 Jan '05

Project: Drupal Version: cvs Component: story.module Category: tasks Priority: normal Assigned to: Bèr Kessels Reported by: Bèr Kessels Updated by: Bèr Kessels Status: patch Attachment: http://drupal.org/files/issues/story_improve_help.patch (3.19 KB) **sigh** Bèr Kessels Previous comments: ------------------------------------------------------------------------ January 7, 2005 - 14:19 : Bèr Kessels Attachment: http://drupal.org/files/issues/story_help.patch (3.06 KB) Because of historical reasons the story module help contained all sortts of odd texts, that are partly even untrue. This patch changes the help so that it: * stresses that stories are nodes in their simplest form * removes all the bloat about workflow. workflow can be configured for any node type, why should nstories mention it? * removes parts of voting, queues, promotion, comments etc. Any node type can have this. * adds a note that you can use stories for personal blogging, and as general pages, pages with no specific purpose (I consider, for example, a forum node a node with a special purpose) * stresses that you should use other modules (taxonnomy, menu) to give the node a place on your site. set to CVS but will apply to 4.5 too..... ------------------------------------------------------------------------ January 10, 2005 - 17:41 : Bèr Kessels Attachment: http://drupal.org/files/issues/story_help_0.patch (3.06 KB) previous patch was the one before spellchecking. This one is without the two spelling errors. ------------------------------------------------------------------------ January 10, 2005 - 20:29 : Dries Can someone review this please? ------------------------------------------------------------------------ January 12, 2005 - 14:53 : Bèr Kessels Attachment: http://drupal.org/files/issues/story_help_1.patch (3.01 KB) After some discussion on the drupal-docs ML, i came up with the following help-texts: Short: Stories are articles in their simplest form: they have a title, a teaser and a body, but can be extended by other modules. The teaser is part of the body too. Stories may be used as a personal blog or for news articles. Longer: Stories are articles in their simplest form: they have a title, a teaser and a body, but can be extended by other modules. The teaser is part of the body too. Stories may be used as a personal blog or for news articles. By default, no menu item, or navigation element is created for a story. An extra feature of a story is, that an administrator can specify a submission guideline and enforce a minimum word count for user submitted stories ------------------------------------------------------------------------ January 13, 2005 - 20:42 : Dries This patch doesn't apply against HEAD. patching file modules/story.module Hunk #1 FAILED at 14. Hunk #2 FAILED at 26. 2 out of 2 hunks FAILED -- saving rejects to file modules/story.module.rej ------------------------------------------------------------------------ January 14, 2005 - 23:55 : Bèr Kessels AARHGH, such a simple patch, so much hassle. My mistake, uplaoded the wrong one again. This one should be right. -- View: http://drupal.org/node/15264 Edit: http://drupal.org/project/comments/add/15264

1 0

[drupal-devel] [task] Improve story help texts
by Bèr Kessels 14 Jan '05

14 Jan '05

Project: Drupal Version: cvs Component: story.module Category: tasks Priority: normal Assigned to: Bèr Kessels Reported by: Bèr Kessels Updated by: Bèr Kessels Status: patch AARHGH, such a simple patch, so much hassle. My mistake, uplaoded the wrong one again. This one should be right. Bèr Kessels Previous comments: ------------------------------------------------------------------------ January 7, 2005 - 14:19 : Bèr Kessels Attachment: http://drupal.org/files/issues/story_help.patch (3.06 KB) Because of historical reasons the story module help contained all sortts of odd texts, that are partly even untrue. This patch changes the help so that it: * stresses that stories are nodes in their simplest form * removes all the bloat about workflow. workflow can be configured for any node type, why should nstories mention it? * removes parts of voting, queues, promotion, comments etc. Any node type can have this. * adds a note that you can use stories for personal blogging, and as general pages, pages with no specific purpose (I consider, for example, a forum node a node with a special purpose) * stresses that you should use other modules (taxonnomy, menu) to give the node a place on your site. set to CVS but will apply to 4.5 too..... ------------------------------------------------------------------------ January 10, 2005 - 17:41 : Bèr Kessels Attachment: http://drupal.org/files/issues/story_help_0.patch (3.06 KB) previous patch was the one before spellchecking. This one is without the two spelling errors. ------------------------------------------------------------------------ January 10, 2005 - 20:29 : Dries Can someone review this please? ------------------------------------------------------------------------ January 12, 2005 - 14:53 : Bèr Kessels Attachment: http://drupal.org/files/issues/story_help_1.patch (3.01 KB) After some discussion on the drupal-docs ML, i came up with the following help-texts: Short: Stories are articles in their simplest form: they have a title, a teaser and a body, but can be extended by other modules. The teaser is part of the body too. Stories may be used as a personal blog or for news articles. Longer: Stories are articles in their simplest form: they have a title, a teaser and a body, but can be extended by other modules. The teaser is part of the body too. Stories may be used as a personal blog or for news articles. By default, no menu item, or navigation element is created for a story. An extra feature of a story is, that an administrator can specify a submission guideline and enforce a minimum word count for user submitted stories ------------------------------------------------------------------------ January 13, 2005 - 20:42 : Dries This patch doesn't apply against HEAD. patching file modules/story.module Hunk #1 FAILED at 14. Hunk #2 FAILED at 26. 2 out of 2 hunks FAILED -- saving rejects to file modules/story.module.rej -- View: http://drupal.org/node/15264 Edit: http://drupal.org/project/comments/add/15264

1 0

[drupal-devel] [bug] new revisions not created if user doesn't have administer nodes permission
by robertDouglass 14 Jan '05

14 Jan '05

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

1 0

[drupal-devel] [bug] new revisions not created if user doesn't have administer nodes permission
by mcd 14 Jan '05

14 Jan '05

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

1 0

[drupal-devel] [bug] new revisions not created if user doesn't have administer nodes permission
by chx 14 Jan '05

14 Jan '05

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

1 0

[drupal-devel] [bug] new revisions not created if user doesn't have administer nodes permission
by mcd 14 Jan '05

14 Jan '05

Project: Drupal Version: 4.5.0 Component: node system Category: bug reports Priority: critical Assigned to: wazdog Reported by: wazdog Updated by: mcd Status: patch Sorry, I didn't mean to change the main title. mcd Previous comments: ------------------------------------------------------------------------ November 1, 2004 - 03: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 2, 2004 - 19: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 - 15: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. -- View: http://drupal.org/node/12401 Edit: http://drupal.org/project/comments/add/12401

1 0