What to do when you delete a user?

Do not delete users. Block them. This has been debated more than once.

I actually disagree w/ chx and think this is a needed feature...

Firstly because I see a 'blocked' user as a 'banned' user, which is different from a user who either requested their information to be deleted for whatever reason (usually privacy), or who I want to delete because I was simply using the account for testing or because I'm an admin with a grudge or for whatever other reason. It's also a legal requirement in certain situations.

Btw, this is a duplicate of http://drupal.org/node/8 .. yes *8*! This has been an issue for quite some time, apparently. ;)

If you are running your site as a web community, then I can understand the need for users to be able to delete their own accounts and (possibly) content. However, if you are running a "commericial" content management system then you really don't want users to be able to delete themselves or, worse still, delete their content. Drupal must, therefore, cope with both situations.

Proposed Solution

A configurable setting which allows administrators to determine:

1. Are users allowed to delete their own account?
2. Are users allowed to delete all their own content when they delete their account?

This could be in the form of permissions under access control, or it could be in the form of a setting (like for registrations) on admin/settings/user. My feeling is the 1 should be a permission ("delete own account") and 2 should be a setting ("delete own content on account deletion").

So, when the user profile form is editted, drupal needs to check whether the current user has the permission "administer users" or "delete own account" and if either is granted then we should allow them to commence the deletion process.

At the deletion confirmation page, drupal would check if the user has "administer users" permission or if the setting "delete own content on account deletion" is true (and they are deleting their own account!). If it is, then we should display checkboxes for optional deletion of content. Otherwise we don't.

Deleting content means totally removing it from the database.

Not deleting content when a user is removed, remains the difficult question.

Possible Solutions

A) The user remains in the database. Remove all of the personal information except their username. Set the account status to a new (third) status: "deleted". Pros: content can still be attributed to a name, particularly nice when the post information is displayed. Possibility of "undeleting" users, if the need arose. Cons: username cannot be reused by new registrants.

B) The user is deleted from the database. Nodes which were attributed to that user should have uid set = 0. Pros: content left after deletion will behave nicely; true respect for user privacy. Cons: Don't know who created content and lots of posts show as "unknown"; possible issue not crediting the true author of content on your site.

I personally prefer A). But either works for me.

I am willing to take on the coding of this but would appreciate some feedback before I begin!

I like simon's suggestion, and also favor A. If the username needs to be recycled, the admin can (or should be able to) still edit it to something else. "Deleted" then becomes an alternate version of "Block"; "Block and remove user information" vs" Block and do not remove user information" (give or take labeling, that's what it essentially becomes).

I'm currently implementing a rather large custom module, and I'm running into a similar Issue. The primary problem is the content ownership. I've thought a lot about it, and I've concluded that I really do need the seperation between "deleted" and "blocked". I've tacked on a custom system which implements the multiple roles, in a manner much like Simon Rawson's option A. A new "fullname" table is created and indexed on the user id which is assigned by drupal, but it contains a third status code for each user. If a user is deleted, information is removed from the drupal user database, but the user's full name remains in this auxiliary table with updated status, so content (not in the drupal sense, content that's part of the customized module system) still has a user name associated with it.

Essentially, it's almost exactly like option A. Good thinking :D It also contains what Crell is talking about, a way for the admin to edit old names, and re-link new accounts with the old content.

If anyone else wants to develop this, I'd be happy to work with them, I could just isolate some of the code I've written -- contact me through my profile.

The solution which I am developing is in http://drupal.org/node/8. You might want to repost there.