Handling of deleted/blocked user accounts

we can fix up all these problems by not actually deleting the uid. IMO, when a user account is deleted we should delete everyhting but the uid and the name and set status to blocked.

I don't think this should be changed for 4.7. It was how it is for 4.6 and earlier, we can survive another release.

I think this needs to be flexible and simple. There definately are different types of user deletions. Such as spammer and cleaning out old accounts. On the deletion screen there should be a small number of good choices for what to do with the various stuff. Anything deleted should probably have some way of saying user deleted, such as threaded comments.

As an interim fix, and along the lines of what Moshe suggested, you can just block users, rather than deleting them.

I _really_ want to properly delete users though; I don't like Moshe's suggestion because I don't like to clutter my database with redundant data/records.

I don't think there is an easy fix because there will be various use cases, and a such, it will take a setting or two to define the behavior. (Example: some people will want to delete a deleted user's posts, others will want to reassign it to the anonymous user.)

I'd have to re-investigate the various bug reports to see how feasible such approach is.

Changing INNER to LEFT will slow down queries and this needs some benchmarking. Can't we just transfer all content to anonymous and be done?

I haven't checked all the modules to see if this is already being addressed, but the set_to_anonymous patch should ensure that all tables with uids are addressed. For e.g. the current patch doesn't update node_comment_statistics (which leads to the last comment by a deleted user issue in the critical queue right now). Similarly, poll, profile and other modules might need to be taken care of appropriately. The delete block in user.module should also probably clear the history table along with the others already in there atm.

Thanks,
-K

• accesslog - updates to uid 0 - Jose.
• authmap - deletes rows belonging to uid - Drupal
• comments - updates to uid 0 - Jose
• history - will be cleared by cron - Drupal
• node - updates to uid 0 - Jose
• node_revisions - updates to uid 0 - Jose
• node_comment_statistics - updates last_comment_uid to 0 - me
• poll_votes - updates to uid 0 - me
• profile_values - deletes rows from profile_values belonging to uid - me
• sessions - deletes rows belonging to uid - Drupal
• users - deletes rows belonging to uid - Drupal
• users_roles - deletes rows belonging to uid - Drupal
• watchdog - will eventually be cleared by cron - Drupal

A test delete resulted in the following queries.

0.55		user_edit	DELETE FROM users WHERE uid = 4	
0.4		user_edit	DELETE FROM sessions WHERE uid = 4	
0.52		user_edit	DELETE FROM users_roles WHERE uid = 4	
0.32		user_edit	DELETE FROM authmap WHERE uid = 4	
0.55		list_themes	SELECT * FROM system WHERE type = 'theme'	
9.88		watchdog	INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES (1, 'user', 'Deleted user: <em>test1</em> <em><test1@blahblah.com></em>.', 0, '', '/~karthik/projects/cvs/drupal/?q=user/4/delete', 'http://castor/~karthik/projects/cvs/drupal/?q=user/4/delete', '10.0.0.4', 1143366419)	
6.93		node_user	UPDATE node SET uid = 0 WHERE uid = 4	
12.38		node_user	UPDATE node_revisions SET uid = 0 WHERE uid = 4	
1.64		watchdog_user	UPDATE watchdog SET uid=0 WHERE uid=4	
0.39		comment_user	UPDATE comments SET uid = 0 WHERE uid = 4	
4.4		comment_user	UPDATE node_comment_statistics SET last_comment_uid = 0 WHERE last_comment_uid = 4	
0.32		poll_user	UPDATE poll_votes SET uid = 0 WHERE uid = 4	
0.19		profile_user	DELETE FROM profile_values WHERE uid = 4	
0.2		statistics_user	UPDATE accesslog SET uid = 0 WHERE uid = 4

I dunno what list_themes is doing there :S

I also fixed some code style issues and reworked the confirmation message.

-K

enabled all modules, created and deleted a user. Works as advertised. i also read the code and found it OK.

applied. Yay for simplicity.

ok for all us newbies

2006 - now is 2009 drupal 6 installation I'm still getting pink n/a and I think its the same problem..

Ive never used a patch - do I just copy paste it into the file mentioned?

Setting uid to 0 makes Node not accessible via Drupal user interface in some cases.
This doesn't happen with normal Drupal install but since the error is related to the drupal standard behavior I am posting here until I know a better place.

I have one i18n site with several modules installed where everything was running smoothly until I deleted old editor accounts. A few days later I realized that the content of the editors was not accessible any more (404). not via alias not via node/x not via node/x/edit, not for user 1. Menu items still appeared.
I found out that the content was still in the database and could get it back via SQL but that’s obviously not an option for everyone.
Unfortunately I can't recreate the error on a fresh Drupal install (tried installing i18n and cck as well). So maybe someone can advise me to track the bug a bit better.