[drupal-devel] [bug] Cannot delete users

[asimmonds]

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:   asimmonds
 Status:       patch

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


asimmonds



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

March 31, 2005 - 21: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 - 19: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 4, 2005 - 02: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.