Cannot delete users

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

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.

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

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.

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.

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?

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

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

I'm reopening this for 4.6.0, as the bug still exists in the released 4.6.0 and I can't find moshe's patch being committed to the 4.6 branch.

A number of people in the forum (http://drupal.org/node/20970) have also found it doesn't work as expected.

Committed to DRUPAL-4-6.

i also had the delete issue with drupal 4.6.
wouldn't it be nice, if it's possible to decide, if drupal_goto should follow the destination?

The patch fixed part of the problem so that an admin can delete users created by the admin him/herself.
But still users who have registered by themselves still cannot be deleted.

This goes for newest version of 4.6

I tested again with a clean new install and only core modules. Am I the only one with this rather serious problem?

I am renaming this bug to original name -closing it and starting a new more specific one

re-opening

It is getting weirder. When filling out ONLY the required profile info. But you have to fill out ALL of the required profile info. NO more NO less. Then users can be deleted regardless of how they were created.

Since - when filling out the required fields in profile info, and no more than the required fields - it is possible to delete users, I am changing to normal priority.

Which fields are required are defined by admin under settings/profiles

So the bug probably has something to do with the interplay of profile.module, user.module and some database tables.

hm, i cannot verify this.
it's working for me with the drupal-4.6 branch out from cvs. i created some profile fields on the "account" category and set some to required, then i registered up a new user using the users way and i had no problem deleting him with an unfilled required profile field.. have i missed anything?

Hi I am experiencing the same problem:
Cannot delete users registered by selecting "create an account" or users created by admin

I logged in as admin
go users
clicked on a user->edit
click on "delete"

nothing happens.

Raj

The work around I have found for this is by going to the users profile --> edit --> delete

Then I am able to do this. However through the administion --> users --> edit the delete option is rendered useless.

I agree that you can delete from the user profile -> edit -> delete. And yes, the user's submissions do get deleted. However, a post which had 4 comments still shows ">> 4 comments" even though 2 of the four comments were from the deleted user are are gone.

I block first, submit, try to delete, and i'm bounced back to the user page with the user still there. No errors logged.

I fill out only the required info, no more no less, and the user is STILL not deletable.

What is going on here? Why can't I delete self-registered users? Anyone else not getting the "required fields" trick to work?

The $_REQUEST['destination'] problem is still an issue here. Can we not use the first patch submitted for this issue? It works for node.module.

I just tested the 4 following situations in a clean install of 4.6.3:

1. Admin creates user. Deletes by clicking on admin->list of users->edit user
2. Admin creates user. Deletes by clicking on admin->ist of users->username->edit
3. User creates user. Deletes by clicking on admin->list of users->edit user
4. User creates user. Deletes by clicking on admin->ist of users->username->edit

They all worked exactly as expected, returning me to the admin->list of users each time with the deleted user removed.

There seem to be some other problems with user fields being reported in this Issue. They should perhaps be in a new bug report. I don't think the original problem is a bug any more in 4.6.3.

I've also performed a basic check of the delete functionality in HEAD and it appears to be working OK.

Marking issue as fixed.

Thanks
-K