[drupal-devel] [bug] Cannot delete users

[Dries]

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

 Project:      Drupal
 Version:      cvs
 Component:    user.module
 Category:     bug reports
 Priority:     critical
 Assigned to:  Anonymous
 Reported by:  AtomicMaestro
 Updated by:   Dries
 Status:       patch

Last patch committed to DRUPAL-4-6.  Still waiting for a better fix for
HEAD.




Dries



Previous comments:
------------------------------------------------------------------------

March 31, 2005 - 11:33 : AtomicMaestro

I can't seem to delete users.


To reproduce:
1. Create a user.
2. View the user created in 1.
3. Click Delete 


I would expect to be told I have to block the user first, but instead,
I'm sent back to the user report. There's no message, nothing in the
log.




------------------------------------------------------------------------

April 1, 2005 - 09:40 : asimmonds

Attachment: http://drupal.org/files/issues/fix_delete_user.patch (581 bytes)

Patch attached to fix this, the delete code in node.module works the
same way




------------------------------------------------------------------------

April 3, 2005 - 16:15 : moshe weitzman

when one deletes a user from list of users in admin, he expects to
return back to that list after successfully deleting. thats the intent
of the $_REQUEST['destination']. I think this patch will defeat that
behavior. There certainly is a bug here, but I don't think we have
found the right fix yet. I suggest testing a delete from both admin and
user/edit pages. make sure you arrive at the expected page after a
successful delete.




------------------------------------------------------------------------

April 4, 2005 - 09:19 : asimmonds

There are two methods to enter the user edit page as a admin:
1/ View a user, then select the edit tab.
2/ Click 'edit' for the user in the admin/user list.


The 2nd method sets destination=admin/user in the URL, when the user
edit page is shown. If the Delete button is clicked, it calls
drupal_goto("user/$account->uid/delete") (the code's comment mentions
this is done to make the tabs disappear). As destination is already
set, drupal_goto() redirects to that ie. "admin/user" instead of
"user/$account->uid/delete"


If after successfully deleting a user, the code calls
drupal_goto("admin/user").


I looked at how node.module does the node delete/confirm sequence and
it has this unset($_REQUEST['destination']) in there as well. Maybe
this delete/confirm sequence pattern needs a re-think for 4.7




------------------------------------------------------------------------

April 6, 2005 - 06:01 : moshe weitzman

Attachment: http://drupal.org/files/issues/user_15.patch (1020 bytes)

here is an alternative. this one properly maintains the destination
parameter which is useful especially when you are not on the 1st page
of your user listing. the redirect insures that you return to the page
you were on. another advantage is that i was able to  delete a few
lines of code which were performing a drupal_goto().


the downside is that the pupose of the drupal_goto() was to get rid of
the tabs. I don't mind the tabs on the delete confirm page, so I think
my patch is better, and removes a couple lines of code.


either patch presented here would work ok.




------------------------------------------------------------------------

April 6, 2005 - 07:13 : moshe weitzman

Attachment: http://drupal.org/files/issues/menu_set_location.patch (2.23 KB)

here is a different patch suggested by UnConed. Uses menu_set_location()
to remove the tabs on the delete confirmation page for both nodes and
users.




------------------------------------------------------------------------

April 6, 2005 - 21:28 : Dries

Mmm, Steven's patch fixes the tabs but still is a bit of a hack.  


(Also, parts of the strings can't be translated, the use of arg(1) vs
$edit['nid'] looks a bit weird.)


Can't we fix this properly?




------------------------------------------------------------------------

April 8, 2005 - 14:50 : Dries

Could this be fixed properly by making a stand-alone callback for the
delete view?