We think it should be as easy for users to remove themselves from the database as to add themselves.

Our privacy policy, like most others, stipulates that we will remove all data we hold about any user, if requested by that user. In some jurisdictions, it is a legal obligation.

Users would have more confidence if they could do it themselves, on assurance from us that after logging in with their password, a click on the delete button would remove their authentication and permanently remove them from the database.

Associated option: block anyone else from using the surplus username.

AOL has run into the problem with unused/unreusable ID's.

It would be better to block the name for a period of 30 or 60 days, then put it back into the queue.

You will find the "best" names go first, and if they go unused, no one can use them. It's pointless to leave them unused. This is why so many systems have started using the email address as your logon name. It prevents reusability problems in _most_ cases. Of course, over time, even that will start to back up a bit.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

Whether abandoned usernames should be permanently disabled or returned to the pool should be an admin option.

The real issue is user confidence. People like to see their deletion happen. The alternative -- to be required to send an email deletion request to admin -- may result in suspicion that we are not wholly professional. It's also extra unwelcome work for us.

GT? Requesting user self-deletion as an option.

Deleting a user should _only_ be allowed under certain circumstances eg: they have taken no actions on the site.

For instance, if a user has any activity on the site, posts, llinks, reviews, etc, they should _not_ be allowed to self delete, without approval, or they could cause trouble, create problems, then remove any trace of themselves.

Bad idea.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

That's why we think it should an admin option.

Our users may not be typical. They don't own their data. We think of them as contributors to a knowledge base, and that is how they see themselves becasue that is the basis on which they sign up.

If they are removed, their contributions remain intact -- everything they have done (which has all had admin approval/validation) stays in the database, but their personal info & email addresses disappear. They may choose to be removed if they think they have contributed enough or get bored or for any other reason -- but we really would like it to be their decision and action.

The nearest comparison would be a moderated mailing list -- subscribers' posts are distributed only after admin approval, but then remain permanently in the list archives. When subscribers want to unsubscribe, they do it themselves -- and it is important that they should do it themselves.

I know that does not match the default LSQL model, but in DBManSQL there seems to be no problem separating users from their data. Apart from that, our privacy policy leaves us no alternative -- we guarantee that all personal info can be, and will be, deleted if the user requests it. Although we have not consulted lawyers about this, we believe the obligation may be legal as well as ethical. It may also be a requirement imposed by our funding sources. If users can't delete themselves, we have to provide a means for them to ask admin to do it for them.

Our choice is not whether users can be deleted or not -- it is who does the deleting.

One thing to be aware of (and I found this out the HARD way!)- if a user has made any contributions to Links, and that user is deleted, their Links go away. I THINK it might not be a bad idea for GT to:

1) have a admin display of ANY Links owned by a user
2) A least the option for the admin to review deletes (because of this) befor finalizing a delete
3) Give the admin an option to "re-owner-ize" any potentially lost Links.
dave

Big Cartoon DataBase
Big Comic Book DataBase

In this case, you could set the links to a default user, before deleting a user.

Call a hook, set Links.LinkOwner = Default_User where Links.LinkOwner = user_to_be_deleted

This is a problem, (eg deleting users) in general. For any specific site installation, it's possible to develop a system, but it would not work for everyone, and adding in "options" increases the complexity greatly.

One other thing that can be done, is simply blanking out the user information, except for the Username (and plugin fields). That keeps the username, the links, and database intact, but no pesonal or other information is there.

Adding a "Deleted" field would prevent a user from trying to reclaim the ID in some manner. Deleting profile information and the password, and setting the email address to the admin email would work. Again, in specific instances.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

Hi,

Interesting suggestion. It won't be in the next release, but it might be something we add in (only as admin option of course). It wouldn't be too hard to code, as you just need to call Community::User::cuser_delete() and pass in the user and they will be removed.

Cheers,

Alex
--
Gossamer Threads Inc.

Alex,

How will you handle the cascade of deleting associated posts, reviews, etc by a user deleting themselves?

This will cause holes/gaps in Links, GForum, etc.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.