deleted users' nodes disappear

At this state I strongly -1 the patch. I'd like to see a message about what happened (maybe a number of nodes changed would be nice, too) but this is a minor thing -- mayor is that I feel unpublishing such nodes is a must. Let the admin decide whether it fits her purposes to let other uses see them as Anonymous posts or do something else.

when we first implemented deletion of users, we discussed a lot and decided to not delete the whole uid row; we removed the email address and set the users.status = 0. I must have missed the patch which implemented the full deletion from the database. I think full deletion is too dangerous because all nodes and comments will disappear, as you've noted. So my suggestion is to soften the deletion which is found in user_edit() as it used to be.

How hard would it be to change delete the user but change any content using that users id to first user ownership? This would prevent the house of cards effect.

We'd need to make every module which stores anything user-related to respond on the user delete event, and then change ownership. It sounds like a large hassle, and I agree with moshe that resetting the e-mail adress and blocking the account is much easier and safer.

There are several different actions that might be wanted in different situations. How about a followup page after user deletion providing options, e.g.,

User [name] had [number] of posts and [number] of comments. What do you wish to do with this content?

Action:
[] Leave it in its current status.
[] Unpublish it.
[] Delete it.

Unless you delete the content, it should be assigned to a different user. What do you wish to do?
[] Assign it to the admin user.
[] Assign it to anonymous user.
[] Assign it to a different user ________.

I will be a PITA, but there are legal issues, too. If I post something, I will have copyright on it, and the most important is the attribution right which -- if I remember correctly -- is not even transferable.

In short, it's a legal minefield if you change a post's author.

Good point. It's a bit of a knotty question, isn't it? Seen from another point of view, there are privacy and personal information issues. In my home jurisdiction of British Columbia, Canada, for example, a Personal Information and Privacy Act says that personal information may be kept only with informed concent, must be produced on request, and must be destroyed as soon as it is no longer required. Are the data Drupal logs included here? If so, a deleted user may have a legal right to know that all data kept on them have been likewise deleted.

Yet it is often necessary and appropriate to retain information entered by someone no longer on record. A concrete example: The organization I work for maintains a Drupal-based inventory of local food producers. When a departing staff member deleted her user account, I was chagrined to find that all her records (most of what we had) had disappeared. In this case, the data entry was done on work time and belonged to the organization. I revived her work by reassigning it to another user.

I'm not sure where this leaves us. Should we consider an "owner" field, distinct from the author?

I see some conflict here. If my private data can not be kept for some reason (yes, Hungarian laws similar) how could I exercise my rights as the copyright holder? We stumbled upon a hornet nest.

Keeping an owner (oid) in addition to the author (uid) seems like a major part of the right solution.

For author copyrighted work, the owner and author are likely to be the same person. In such a case, either the authored, copyrighted work should be deleted along with the user, or the author should be deactivated but remain so that attribution for copyright can be made.

For work owned by someone else as in Nedjo's example of food producers (this is called "work for hire" in the USA, and means the person hiring owns the work, not the author), the owner is different than the author. When the author is deleted, the nodes could be assigned to the owner, or anyone the owner designates.

The user interface for accomplishing this is a problem to be solved.

The legal issues of ownership and privacy are important and closely related to the question of deleting users, but maybe the user module isn't the place to deal with them. Rightly or wrongly, these questions won't be of primary concern to everyone. There is already a (contributed) legal.module. Should user.module stick to the mechanics of user deletion and some basic options for what to do with leftover content, as suggested above, and leave any legal enhancements to changes to the legal.module?

Nedjo: I agree; the user module is not the right place to determine legal issues. I'm sorry if my previous response implied that.

Instead, I just was trying to clarify some use cases, I think.

Doesn't that mean we need some sort of default behavior for deleting users? Would that behavior then be altered by an addition to the legal module? Is that what you were thinking?

A nearly identical patch was posted at http://drupal.org/node/28345--a good sign that this issue remains relevant.

I would like to take this assignment as I wrote in other issue http://drupal.org/node/28345 .

Having worked for a major hosting company (100.000+ users) we got visits by the authorities once in a while. They had the proper paper work to get particular information.

Just from that point of view any kind of content removal should be completely separate from user removal as most of you have agreed. From the viewpoint of the user (creator, copyright, etc) it would be appropriate if he has the right and option to delete the content.

As admin I would prefer to leave any content intact _and_ tagged with the name of the user who it belonged to. In that sense deleting a user is closer to disabling him and making the content that is tagged to that uid inaccessible to the general public i.e. tagging its as 'dead'.

Tagging with anonymous maybe ok in a small installation, but in a larger organization tracking and accountability becomes crucial. If I then decide to wipe any contents I do that as a deliberate and controlled of maintainance. This would translate into an admin tool where choose to delete the content of any 'dead' users whose accounts have been disabled.

my two p's
Martin

node/8 will resolve this bug, by making the behavior admin configurable.