Let a user deactivate or remove their own account

ax convinced me by referring to user privacy ... i've assigned this one to myself.

just curious - any progress on this?

i tried and gave up on this one. user_edit() is my nemesis.

anyone else then? it should be possible to delete a user account, shouldnt it?

assigning this feature to 'unassigned' [again - sorry]. any takers?

I'll have a look at it.

Any ideas on how secure this should be? Should a mail be sent to the user telling them their account was deleted? The account will never be removed completely from the database, just a status change.

i've completed this one. patch forthcoming. the implemetation is that a new link appears beside 'view' and 'edit' on the geenral user pages. it reads 'delete account'. after following that link, the user confirms that he really wants to delete his account. after agreeing, the user records are actually deleted from the database. i believe this is wha tthe user really wants, and is the most 'privacy friendly' option. the watchdog logs sufficient information such that an admin could reconstruct the user account if he really needed to.

Committed to CVS. Just needs some more testing before this can be closed.

Closed.

in an <quote>Improvement</quote> to the user module, dries <quote>also removed the "delete account" link/functionality (for now).</quote> [1]. i'm not the only one who thinks that this is a bad idea [2] and hope i can trust in the "for now" and get this back as soon as possible.

[1] http://lists.drupal.org/archives/drupal-cvs/2003-10/msg00431.html
[2] http://lists.drupal.org/archives/drupal-devel/2003-10/msg01580.html

I've modified the user.module included in the Drupal 4.4.2 Debian package.

Basically, I've undone an adapted the patch in which the delete functionality was removed. Now a user can "delete" her own account, but in fact it remains only deactivated.

I hope this patch to be useful for everyone. Please, feel free to add it to the Drupal mainstream if you like. :-)

The "for now" is still lasting...

+1 for the principle of allowing user to delete account.
But:
What happens to all the posts that user has posted? Do they get deleted too?
What about the comments?
What about to all the replies by other posters to those posts and comments?

The link to the privacy document is dead.
Any alternative one?

When a user asks for removal, what should ideally happen after a confirmation phase, preferably through an email instead of just on site, seems to be :

• any nominative information is removed from the system. This includes IP logging if a module has been used to track it.
• the user login uid is flagged as deactivated (status ? data ?) and cannot be reused, and a generic "unsubscribed" name is used to replace name
• choice is given to the outgoing user to remove his postings or not.
  • If he leaves them in place
    • as the uid is still there, the generic "unsubscribed" name is used as the author name in all nodes
    • ideally, all comments in a node for which the user has posted are parsed to replace the user name by the generic replacement (which is probably error-prone, alas)
  • otherwise
    • comments by that user are replaced by an empty comment marking "deleted" and with the generic name, to maintain threading
    • nodes by that user are removed with all their comments, and comments pertaining to it are emailed to their respective authors so they can choose to repost them with an explanation instead of losing them (or could be directly removed, choice given to the administrator in a site setting)

Note that IANAL and, especially in the EU, personal data is regarded as highly sensitive (much more so than in the USA), and any webmaster implementing drupal should probably consult a lawyer for the implications of setting up a site and choosing to keep personal data (think backups). At the very least, for EU Drupal users, this is a must-read:

http://www.europarl.eu.int/stoa/ta/privacy_and_data_security/privacy_and...

Please don't change the title. putting it back :).

Um... This is node ***8*** on this site, and it still remains to be fixed.

Please let's get this fixed. It's a privacy and legal issue.

Robin

http://drupal.org/node/29373 has been marked as a duplicate of this bug.

Marked http://drupal.org/node/43674 a duplicate of this bug.

Btw, the truste link at the beginning seems dead, but here is a relevant excerpt from COPPA (The Children's Online Privacy Protection Act) for sites which collect data from children: http://www.ftc.gov/bcp/conline/pubs/buspubs/coppa.htm

Relevant excerpt:

"At any time, a parent may revoke his/her consent, refuse to allow an operator to further use or collect their child's personal information, and direct the operator to delete the information."

So this is still a legal issue, at least in certain circumstances, and should be addressed.

I can see two options: a) we clean the user data, his email, his password, his username (set it to 'deleted user') his profile data and then and block b) we delete the user and all his nodes, his comments in faith that it's all his content.

I posted this in http://drupal.org/node/43674 but since that's a duplicate, I suppose I should post it here...

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.

simon, excellent post! i agree 100% and was about to post similar.

as for what to do about the user's account, i think an hybrid approach is best, let the user or admin choose upon deletion. when they arrive at the confirm delete page, there should be some checkboxes:

"delete all content (nodes)"
"delete all comments"
"delete all forum posts"
"delete anything else i'm forgetting"

then there should be another checkbox with 2 sub-radio selections:

"delete user name"
( ) remove all personal information but leave username in tact
( ) remove account completely and set all posts to 'Anonymous'

i think these options should happen on the confirm delete page, because i can see many situations where these settings are differ greatly from user to user, especially as an admin deletes various users. there is really no global setting IMO, really depends on a per user to user basis.

however, with all of these options, all privacy laws can be met, across all borders. additionally, content can still be left in tact and this is left up to the author or admin.

i'd lets get a patch going and simon let's coordinate our efforts :-)

I'm open to the idea of having all of those checkboxes on the delete confirm page, however I would maintain the requirement for the two permissions/settings which are controlled by an administrator. Namely, 1. Are users allowed to delete their own account?, and 2. Are users allowed to delete all their own content when they delete their account?

You couldn't have a cms operating in a commercial environment where their content is deleted, when a member of staff (user) is deleted!

I'm willing to have a go at writing this, but wouldn't be making a start until the weekend. If you make headway before then, please let me know!

Nothing should impede the administrator doing whatever needs to be done, fairly quickly, e.g. completely delete a spammer and all his postings. The same my be said of flamers, and others consistently making inappropriate remarks.

Another possible option for the content of a deleted user is to assign it all (under a unique but nonmeaningful name) to someone whose permissions are reviewer who can selectively keep and delete the items.

Simon, I agree 100%. Those checkboxes would only be available if the right permissions have been granted as you stated. I can't start work on this patch till this weekend either so let's shoot for them. Catch me on #drupal as m3avrck, cheers!

I've attached a first attempt at this patch. What I've done:

Introduced two new permissions. "Delete own account" and "Delete content with account(s)".

So there are four scenarious now. Providing a user has suffiicient permissions they can:

1. Delete personal info excluding username and leave content.
2. Delete personal info including username and leave content (will become anonymous).
3. Delete personal info excluding username and delete content.
4. Delete personal info including username and delete content.

It all works, as far as I can tell. If you view a deleted user's profile, you get a message telling you they are deleted. If you have sufficient permissions (administer users) you can bring them back from the dead by going to the edit tab and entering a password, email address and marking them "active".

I can't imagine a situation when scenario 3 would be useful. Perhaps I should make this impossible.

The patch adds lots of queries, but only when you are actually deleting stuff. Otherwise it is fairly slim. And I think it is all security tight, with the new permissions.

Let me know what you think. The code still needs tidying up. One thing I haven't looked at yet is $destinations.

Slightly updated patch and setting to code needs work.

Simon, great start!!! This is certainly much needed, but here's a few things after looking at the patch.

I'm not sure what this means:
drupal_set_message(t('Your deletion instructions have been actioned.')); ... perhaps just saying "The user %user has been deleted" should suffice? Or, even depending on what options were checked, having different messages saying "The user %user and all content has been deleted" etc...

What about forum posts?

We shouldn't introduce hardcode HTML into core like this:
$form['warning'] = array ('#value' => '<strong>This action is irreversible.</strong>');

Perhaps something like: drupal_set_message(t('Warning: this action cannot be undone.'), 'error'); String should be translatable to and having 'undone' follows more along the lines of other core messages.

Upon user deletion we should *not* go back to the node page: drupal_goto('node'); but back to the admin > users page.

Shouldn't this query use UPDATE / SET syntax instead? db_query("REPLACE INTO {users} (uid, name, status) VALUES (%d,'%s',2)", $account->uid, $account->name);

This code:

Should have: else if on the following line. Also, it should return a translatable string: return t('This user has been deleted');

After a user is deleted but if I leave the username intact and I goto view the list of users, it says Member for: 36 years 3 weeks ... perhaps we should record in the database a timestamp of when the user was created? And this field can be the difference of when the user was created till user was deleted? Or for simplicity, maybe this member for should just return 'n/a' or 'never'.

Otherwise, patch looks good and is much delete!

Also with that last comment, in the users table, the status should say 'deleted', right now it just comes up blank.

m3avrck,

Thanks very much for all those points. I have much to learn about the core... it is a beautiful thing...

Anyway - I've addressed all of you points, I think, in this version. Which is must more robust in terms of deleting content and comments. Most notably I now use calls to node_delete($nid) and _comment_delete_thread($comment) rather than using my own SQL. This is much nicer, and invokes the appropriate hooks.

Still to do:

1. Add a 'Cancel' link to the delete confirm page. (possibly by reintroducing the use of confirm_form()).
2. Think about $destinations.
3. Properly think through and check what happens when we delete revisions which are authored by deletee. Could we end up with some nasty situations? (e.g. if deletee authored current version... what happens?)

Simon, new patch looks great! A few more things :-)

1. Biggest thing I overlooked on first review and what you mentioned is that we should move this to the confirm_form() screen. Check out filter_admin_delete() for an example. This doens't really require much code change, just shifting things around a bit and building the form into $form and passing this to the confirm_form()

2. user_edit_delete I'm guessing should be renamed user_delete

3. If I delete a user but leave his username, it still shows up in the list of users (which is good). However, I *cannot* delete that username/account anymore as the delete button is gone. Shouldn't it still be there so that account can be permanently deleted if need be as well?

Looks like this patch is almost ready for commit, keep up the awesome work!

I'm setting this bug back to critical due to the privacy and legal issues involved. I think resolving it would close a couple of other user deletion related bugs. Or at least pave the way, a couple of flags on hook_user $op = delete for delete or archive content... so other modules can know what to do...

Well, I'm quite happy to provide an updated patch (against HEAD), and with a fix for issue 2 mentioned by m3avrck in #30. I decided against fixing 1 and 3 in that post for now. I will await more feedback.

I believe this patch to be fully functional - however, as always, it will need review and testing thoroughly.

Please post feedback.

Sorry. What I should have said is that 1 is fixed. 2 and 3 are not. Apologies.

Simon, problem with the patch, seems the last portion of it got truncated somewhere, any idea? Patch is looking better ready to start testing it here.

Good to see progress being made on this.

Perhaps it doesn't matter much if things are progressing, but it seems that there are multiple issues involved here, so perhaps if it makes it easier, we should consider splitting some of them out to separate issues.

With respect to the last patch, wouldn't it make more sense to deal with deletion of content in node.module via a hook, rather than doing it in user.module. Better to let node.module deal with the complexities. For example, this patch does not deal with revisions.

Similarly, if we're interested in completely obliterating all traces of the user, we have to look a little farther. There are also instances of 'uid' in the following tables.

accesslog
comments
node_comment_statistics
history
profile values
poll_votes
watchdog

So, I'd suggest that we set up appropriate hooks in the associated modules to deal with user deletion.

Generally I agree about the hooks.

I've reattached the patch, but it isn't against head.

When you choose to completely delete content with the patch it does invoke node_delete, so in essence it does things "properly" where it can.

Let me know if it works this time.

Right!

Here's a patch against HEAD. I've had my eye off the ball for a couple of weeks and the core has changed a lot - most importantly the user module. So, although I've tested the patch and it appears to work, it will need thorough testing... and possible improvement.

Simon

I am a newbie and not familiar with patch things.
For testing purpose prior to upload the altered file to live server, how do I apply this patch and other patches out there on my windos machine?
What tools should I use?
Sorry for this silly question. Have I mentioned I'm a newbie? ;)
I need this function to delete user(s), and I currently am using Drupal 4.6.5.
Would this patch work on this version?
Is there any module available for 4.6.5?

Thanks

Here is a guide of how to patch on Windows. http://drupal.org/node/23409. I use Cygwin.

Unfortunately this patch does not apply to 4.6.5.

module_invoke_all('user', 'delete', $edit, $account); i thought we have user_invoke.

Please see http://drupal.org/node/53348

I updated patch 61 for Drupal 4.7.2. It seems to work fine for me, but it could very well be that I have messed things up or additional changes should be introduced in the patch. So, use it with care!

- This needs to be a patch for CVS (the 4.7.x version may apply, I haven't tried).
- The indentation is inconsistent, always use two spaces.
- All form arrays should follow the standards at http://drupal.org/node/318.
- I don't see how the user's page is changed if his status is 2. (I think there should be an informative message.)
- Can you post a screenshot of the new delete screen?

Wow, just a comment.. this was opened in 2001??? not a high priority huh? I think users should be able to delete their own accounts. Saves us the bother if they don't want it, we should not keep them.

Fusion Sushi: you're ignoring the legal aspects. In some situations (and I'm thinking very specifically of drupal sites being run by some public agencies, or possibly public companies bound by Sarbanes-Oxley or similar texts), deletion is not an option: every content must be kept archived and safe, although it may be mandatory to either keep it available or on the contrary hide it depending on the legal context.

As always, consult your lawyer for any decision in that field, but as the developing community, we must take into account most usual regulatory conditions regarding content archival/deletion.

Attached is a simple patch which adds a new permission ('delete own account') and provides users with that permission the ability to delete their own accounts.

This patch does not implement the ability to delete a users content - that can be a separate patch.

Patch applies and works as it should.
This is a great new feature for user privacy.
(After 5 years!)

Not critical. Will have to wait for Drupal 6.0.

Hi everyone. Is there a working patch for Drupal 5.1 ?
Would be really cool... i really cant launch my site without the users having the possibility to delete their account.
Greetings, Finn

Please see:

http://drupal.org/node/8#comment-151471

Patch no longer cleanly applies.

# patch -p0 < patch_43.txt
(Stripping trailing CRs from patch.)
patching file modules/user/user.module
Hunk #1 succeeded at 489 (offset 87 lines).
Hunk #2 FAILED at 896.
Hunk #3 succeeded at 1505 with fuzz 2 (offset 106 lines).
Hunk #4 succeeded at 1511 (offset 88 lines).
1 out of 4 hunks FAILED -- saving rejects to file modules/user/user.module.rej

@keith.smith: Is that against HEAD? The patch from #43 still works on v1.745.2.1 (from the official 5.1 release):

I was attempting to patch against HEAD, per drumm's comment in #43, since this was a feature request (features get implemented in the latest version of Drupal), and since the issue was flagged with 6.x-dev.

IMO, what should happen with the user's data is unrelated to this issue since this is independent on who deletes the user (i.e. admin or the user herself).

I rerolled the patch from #43 against head, and added some additional text in the confirm form to make it more user-friendly. Now let's hope this makes it into D6 :)

Notice: the patch only applies after this patch has been committed.

changing status to needs review -- sorry

DriesK, the difference between an admin and a user deleting a user is that it's likely that the user admin is a node admin as well and can change the authors of all nodes belong to said user.

that's true - so you feel this patch can't make it until there is a more general "reassign or delete all user content upon user deletion" patch (which could be used in together with this patch to let the user choose to delete all its data)?

I still think that's a different issue - in this patch the user _is_ warned that his content will become unassigned. If _webmasters_ don't want this to happen, they simply shouldn't grant this permission...

let me elaborate a bit further:

in my opinion, there is no difference between an admin choosing to allow users to delete their account, with the known consequence that all content of that user will then be assigned to anonymous, and the same admin assigning the 'create content' or 'post comments' permission to anonymous (which in all Drupal versions has been a valid option). In both cases, the admin knows that content can be anonymous. It's an admin decision.

I agree with DriesK. Admins have choice to enable user deletion or not (and even use something like Node Adoption), so I really don't see this as an issue.

However, the current text "All submissions you made to this website will no longer be linked to your account" is problematic. It's easy enough to change on a per site basis (using locale or displaying a custom block at user/*/delete in the content region), but I'd really like to see an admin setting for customizing the message.

Looks like this thing has been going on for a few years now. That's too long. I just realized that a user cannot cancel an account without engaging the Admin. That's not good. We want to be certified for privacy. User not being able to cancel eliminates us. This goes directly against the right to privacy.

There are watchdogs such as Truste that consider this a breach of privacy. Users can report violations such as this. Visit this website for an August 2007 report. I don't want to be among the violators! http://www.truste.org/consumers/reports/August2007.html

Using 5.1 on this site and new 5.2 doesn't address this. Any solution to prevent being in violation of privacy rights????

Drupalgirl

This can't be solved until 7.x because everything before that is locked for new features.

drupalgirl, there are the User Cancellation and User Delete modules that can handle this for now. I would like to see this functionality in core, too, but until that happens I've been using User Cancellation with great success (well, not that anyone has deleted their account yet but it does work).

Drupalgirl, read higher in the thread : enabling this feature can put a webmaster in an illegal situation depending on the country his site is running in (IANAL, but it seems this would be the case in France unless alternate contribution mechanisms are in place, thanks to the LCEN, which mandates keeping track of user interaction).

This seems to be an issue where the legal situation is significantly different between countries, and Drupal must be able to address all possible configurations (required, authorized, forbidden), which is probably part of the reason why this has lasted so long already.

I'm trying to summarize, since reading through all above comments is quite confusing.

Requirements / considerations:

1. A user needs to be able to remove her own account.
2. Laws for certain services/countries force the operator to delete all user related information.
3. Laws for certain services/countries force the operator to keep all information of removed users. This even applies to user deletions by site administrators.
4. If laws require to keep all user related information, a user should still be able to disable (block) her own account.
5. Independently from 2 and 3, a site administrator should be able to globally define
   • whether the username should be replaced by "Anonymous" (default), "Deleted" or a custom term
   • whether all contents of that user should be deleted (with implications regarding threaded and related/referenced contents), zero'ed, unpublished or kept as is.
6. A user might need to be informed that her account has been cancelled (in whatever fashion).
7. Independently from all previous points, users with a certain permission should be able to completely delete a user, optionally including all content created by that user (e.g. a spammer) and without notifying that user.

Based on the legal aspects, this issue could certainly be classified as a bug.

wow! I can't believe this issue has been around so looooong! what a classic.

after having a read through I can appreciate there are hidden depths, but still.

I think one point of view has not been given enough attention: what typically matters is the actual retention/erasure of the user and content, not necessarily actual removal from archives, although this can exist too (and possibly clash with legal requirements).

However, the actual online visibility of these data without administration privileges and/or a legal mandate is not considered and might be what helps solve this issue, in two distinct stages:

• a site-level setting defining the overall data retention policy for deleted users and content
• a user-accessible UI allowing users to request disappearance of their pseudo and its created content, and obtain removal of the related data from publication

IF and only if the site-level setting allows it, apply the various removal techniques discussed in the thread, otherwise remain at the "hidden" level above, with information effectively no longer visible, but still kept if required.

I think it is very late now to go with this in Drupal 6. This imaginably requires such huge changes which we should not make now as far as I see.

I believe the proper solution requires a new site administrator pane called "User Deletion Settings" where all of the points in #68 are addressed and controlled.

The organization I work for has a number of sponsors who need this functionality. Unfortunately, we are still on 4.7 and will be migrating to D5 or D6 between now and next spring. If we spend money to implement this, it would be to put it into D5 or D6, not D7.

It seems like a trivial problem at first sight, but I suppose that is part of its deviousness.

But since D6 is looming, and any patch that changes the API now will have one hell of a time getting in (if at all), what about the path of least resistance?

I've encountered hook_user($op='delete') every now and then in contrib; it usually serves to remove configuration values or personal information they entered, but never content. It seems to be safe to trigger both by users and by admins.

The user-deletion functionality is obviously *there* in the API; the admins can use it. What is wrong with slapping one or two perms and a form (with admin&email confirmation, if so configured) onto it? I find last-minute half-measures distasteful myself, but adding the possibility for admins to make user accounts deletable (it would be an optional permission, of course) seems like it would solve far more problems than it can create. True, optional content-deletion wouldn't be bad either, but it's the only part that isn't trivial?

With this reasoning, I'm really relying on the site admin to take care of all the legal issues of #68. I'm sure it's obvious that Drupal cannot be programmed in a way that makes it impossible to break the law with it - nor can it without difficulty use default values that can be used everywhere without being at risk. Can't we trust the owner of the root account to be responsible enough to let a user delete or not delete their information?

--

It sounds as simple as adding these three permissions to the access table:

* Block own account
* Delete own account pending approval
* Delete own account without approval

Perhaps with an additional setting:
* Require email validation for account deletion.

--

But perhaps I'm seeing the problem too simplistically - it must be bigger than that if it's lasted for six years...

It seems like the summarized requirements were unclear.

Requirements / considerations (revised):

1. A user needs to be able to remove her own account.
2. Laws for certain services or countries force the operator to
   • either delete all user related information
   • or keep all information of removed users. This applies to all user deletions (even those by site administrators) except those mentioned in 6). In this case, a user should be blocked upon removal request.
3. Independently from 2), a site administrator needs to globally define for all removed users
   • whether the username should be replaced by "Anonymous" (default), "Deleted" or a custom term
   • whether all contents of that user should be
     • deleted (with implications regarding threaded and related/referenced contents),
     • zero'ed,
     • unpublished
     • or kept as is.
4. A user might need to confirm (double-opt-in) her removal request (see #73).
5. A user might need to be informed that her account has been cancelled.
6. Independently from all previous points, users with a certain permission should be able to completely delete a user, optionally including all content created by that user (e.g. a spammer) and without notifying that user.
   • Note: After upgrading from D5, this would be the default for all removals.

Basically, I agree with some of the previous posters - it should not be that hard to implement and we can default to the current behavior. After tinkering about this a bit more, I even do not think, it would change the current APIs that much - it would rather extend them.
Some further considerations:

1. Content display modules in core would need to check whether a content may be displayed depending on a user's status [maybe dependent from c)].
2. Because blocked and removed users are not the same, we may use users.status = -1 [tinyint(4) signed] to assert removed users.
3. Required user permissions:
   • Remove own account
   • Permanently delete user accounts & contents [see 6) above]
   • optional: Display contents of removed users
4. Required user hooks: delete [means removal request now; optionally using double-opt-in], remove.
   • Note: Existing hooks should be renamed.
5. UI:
   • New tab/task in user/# (i.e. user/#/remove) for 1).
   • New fieldset with radios in admin/user/settings for 2) and 3).
   • New textarea(s) in admin/user/settings for 4) and 5) [maybe two to supply different text templates].
   • New form action in user/#/remove and confirmation page with checkboxes (i.e. user/#/delete) for 6).
   • New content (based on user) status filter options in admin/content/node.
   • New user status filter options in admin/user/user.
6. For now, we might limit options for removal of user's content to 'zero', 'unpublish' and 'keep' to circumvent any implications of deleting threaded contents.
7. If a user needs to be able to view a page directly upon/after removal, we need to ensure that she is actually able to access it.

7. Give the admins a way of managing whether the user name should be made available to use by new user, or should be blocked and not be available to anyone even after the deletion.

8. If that same user, identified by confirming the original email address, comes back after a while, when the account and perhaps all content is deleted, it is a question whether he/she should be able to re-enable that user(name)/account.

9. Other users that has been communicating with the one that has been set as inactive (removed from active users/"deleted"), should perhaps have a way of checking the activity status and the last logged-in date, and perhaps even the status if the user has requested manually to be either set as inactive or removed (from view).

Some of these may suggest that once used, that particular user name should be blocked for usage by others unless made available by the user him/herself (by for example changing his/her user name.

If so, then there is a need to retain all the user names in the database after "deletion", so that the system has a way of preventing them from being re-used.

I agree about the privacy concerns which suggest that the sensitive information (the information about the user on the user page), should be deleted from the database. However, as far as I can see, that does not apply to the content posted in public. I think that the content (admin policy) should be possible to retain, along with the following details about the user account:
- user name, original/last email used (to enable reactivation by the user), active status, registration date, and last activity date.

(Retaining the emails could be an admin policy, and only used for enabling re-activation by the user, and obviously not accessible by either the public, nor (ideally) easily by the admins from the GUI. It should also be moved to a different place in the database where those emails cannot accidentally take part of future outgoing emails to active users, if some module has a bug or forgets to check the status, etc.)

When we get further down the road, several concerns seems to demand higher attention, for example related to digital identities, openid, search engine cache/internet archives, reputation management, etc,

The more I think along these lines, the more I tend to lean towards no actual/complete deletion of the user (but private data, yes), but rather flexible ways of managing inactivity status and appearance (content/user name/status).

Edit: This comment was initially just a subscription to the thread. I chose to add these points to this old comment of mine, as it seemed practical to have it posted right beneath the list of the Sun's other 6 points.

subscribing

subscribing

Funny this has been going on for years and the reason IMHO is that we are taking all the time the wrong approach here. All these requirements we have compiled may very well be a new drupaluserlegalrequirements.module :-)

Come on, it cannot be that difficult, we just need to add some simple cool features with reasonable defaults. And this issue was simple enough at the beginning: "Let a user remove her own account".

And this simple feature would allow our sites to be ok for about half of the world countries and, most important, keep your site users happy because they can remove their accounts.

Then if someone really needs to comply with all his/her country's legal requirements then you better hire a lawyer and a coder to work together on specific site customizations... And possibly in most countries you'll find out that you better do no web site at all to be 100% safe. Really, setting up a web site used to be (should be) easier :-(

So well, I just wanted to add my two cents to the discussion, specially since I'm getting notifications for all posts here from some time ago, but I won't be throwing any code at this one the way it is currently going. I'd just +1 any patch that gets something done.

i'm so fascinated that this has been a 6 year conversation with no resolve - data portability is a hot topic, and with it comes account shut-downs....i believe that this should be in core, not a popin module...

zilla: Looking forward to your patches.

@webchick - i unfortunately can not write code, but i DO wonder if this could be resolved with a simple workflow solution - here's the idea:

using the 'user request role' module - an admin creates a user type called "Deactivate" and in 'my account' all users can see the ability to request access to that role - a user requests such a change, and the request is 'automatically approved' and the admin is notified of the request at which point the admin logs in and deletes the users manually by request...a "trigger" perhaps notifies the admin and/or 'removes the user' if that is possible with a trigger???

that's a solution for less busy sites, because it wouldn't work with thousands of requests per day - though of course, if thousands want to deactivate per day then you might want to rethink your whole site idea ;)

what do you think? perhaps this would allow for some basic framework for a process to support account deactivation...

if you think this makes sense, let me know and i'll write up a detailed workflow type of thing in the handbook for people to examine...

Subscribing.

This is interesting! Subscribing

Subscribing.

Having "deactivated" as an extra role seems not to match the purpose of the user roles (a hack, in other words). Rather, I think there should be an extra account state next to "active" and "blocked" (currently a boolean state), named "resigned" or "withdrawn".

A "resigned" user account has the following properties:

- it can log in (unlike a blocked account)
- it can change its own state back to active
- it cannot create content or comments

Depending on admin configuration, a resigned account's

- profile cannot be viewed
- nodes are unpublished
- comments are unpublished

-------

I believe this will allow maximal control to the user about their own data, while being minimally destructive and completely reversible.

Possible criticism: Some jurisdictions require data to be deleted permanently at the user's request; this solution retains it outside public view.

Counter: The admin can delete the account manually if required by law in their jurisdiction, along with any content. There is hardly any content management system that allows a user to delete their own submissions permanently (in fact, most don't even allow hiding it). Our job is to make it as easy as possible for the admin to comply with local regulations, not to follow these regulations by default or make it impossible to break them.

So: Allow users to de-activate their accounts, but keep their data and allow them to re-activate until the admin manually deletes it. Also allow the admin to disable the hiding of data.

subscribing

Let me propose a user interface for this feature. I agree that this needs to be made more of a priority, but I haven't seen anyone put forth a solution that would be straightforward from the perspective of the user and the administrator.

Obviously this discussion has not come to any resolution, so if you want it to reach closure and you like what I have to say, help me out a bit on this!

THE PROPOSAL:

Basically at the bottom of the page
http://www.site.org/user/*/edit

there ought to be an Account Removal section containing just one button with small print underneath it:

[ Delete Account ]
Removes this account so that it can no longer be used. You will be given the option to choose whether or not to remove any posts associated with this account.

When user clicks on the delete account button they should be taken to the page:
http://www.site.org/user/*/delete

and the content of this page would be 3 radio buttons:

Please confirm this action; you can choose whether to also remove posts created by this user.

[*] Remove account entirely as well as all posts associated with this user

[ ] Remove account entirely but reassign posts by this user to the 'anonymous user'

[ ] Deactivate the account. Associated posts remain, but logins, messaging, etc. are disabled

[ Confirm ] [ Cancel ]

If user had no posts, then only two choices should appear:

[*] Remove account entirely (no posts are associated with this account)"
[ ] Deactivate the account. Logins, messaging, etc. will disabled"

I think that leaving it up to the user is fine. If there really were a need to prevent users from deleting their content, then permanent delete requests could be be put into a "delete review queue" and there could be a setting to "Enable admin review of account removal" or something like that, but perhaps that is a bell and whistle that is unnecessary.

I don't think that allowing the user to log in to a deactivated account is necessary; it complicates things. Probably it should be possible for an admin to reactivate a deactivated account (an admin might deactivate someone for bad behavior and thus should be able to restore as well). Sure a user might mistakenly deactivate their account but this would be so rare that it is no big deal to force them to get admin help to restore things. A pay site might be deactivated after a certain number of months, so the message that you get when your account has been deactivated is something that ought to be customizable. "Your account was deactivated by _________ on this site. Please contact customer service to renew your subscription/ reinstate your account."

I don't think you need any more than 2 permissions "Delete own account" and "Delete/deactivate others' accounts"... "keep it simple stupid"

It would be great to see this issue fixed in versions 5 and 6.

-rich cowan
Organizers' Collaborative

Why would we offer the user the option to deactivate the account or disable it; If a user wants to deactivate an account, they just leave it be, I'm sure everyone here has an account on a website that's in that state. They don't want email messages from the site, they can deactivate them all (hopefully).

I see this being more of an administrative decision than a user decision. The user should be able to affect their account in the only way allowed by the administrator. I don't see the need to make this more complicated for the user.

Maybe I haven't been following this thread as closely as I thought, though, since most posts seem intent on leaving the "deactivated" state in this. I would think this option could be easily handled via contrib, however, and this issue was originally only about deleting the account.

At the very least, there should be a tick mark available for the user to set the account as disabled.
For example to stop being listed on user/country pages, etc., and also potentially to not be counted among "active users" if such a statistics is used on the site.

Administrative deactivation:
I also think there should be a separate tick mark for the administrator and even the system itself (automated) to set an account as "marked for deactivation" based on user activity. When that is set, an email would be sent to the user informing about a scheduled deactivation of the account and prompt to re-visit the site if wanting to prevent the account from being deactivated. The admin settings for that should include time frame settings: how long time before the system deems an account as inactive, and how long time to wait for the user to respond to the system email before deactivating it. (so, two tick marks).

I can't believe this is still around.

yeah, can't wait for d7 when this might show up :)

A user should never be able to sign up with a previously deleted username otherwise your going to have issues of stolen identity.

Yes, it is important that the administration of users includes features to prevent issues like stolen identity or confusion related to it.

So the record should not be deleted, only deactivated in a way that prevents it from being pulled into any queries etc.

How to prevent mistakes in future snippets etc. that may query the users table without taking this issue into consideration? Somehow "enforce" calling through an API or the like for any access to the user table, so that it effectively prevents access to deactivated accounts for other purposes than user account administration (for administrators)?

It would be practical with the possibility for a user to set his/her account deactive temporarily, but still be able to re-activate it later without administrator interference, simply by having access to the email address registered with that account.

For any account that has been in use and has posted comments or other, it should not be possible for others to use that user name even if the account is deleted or deactivated. But if an account has been registered but never been used, it should be possible to deleted it in a way that makes that user name available to either others that want to change their user name, or to be used with new user registrations.

Subscribing... thinking about some ideas to share if I can refine them (I have this kind of request often on my site, and it would be great to eventually put in the hands of the user rather than mine... in the mean time I'm trying to modify the user cancellation or user delete module to add more checks to guide the user and prevent accidental deletion).

Subscribing...

From a user point of view, I was trying out a website (kwippy, an app similar to twitter that gives you a public presence) a few days ago that I decided I wasn't interested in. I wanted to delete my account to remove the public profile, and to indicate I was not interested in using the service to the admin.

When I think about it, facebook allows for add / remove for their applications, and I think the workflow for that process works quite well. I'd love to see User Delete Account get to core.

When I think about it, facebook allows for add / remove for their applications, and I think the workflow for that process works quite well.

I really don't see how this is relevant. Facebook accounts are manually deleted by Facebook staff (which means Facebook just uses a fancy form and still doesn't allow users to delete their own accounts). Building this type of functionality in Drupal is easy.

There was only one objection to DriesK's patch and I think it should be rerolled for 7.x-dev. Otherwise, the only way I see this issue ever going forward is if a contrib module that handles all the multiple use cases sun listed is developed separately with the purpose of adding to core.

I realize that this is a difficult concept to code with many different approaches. Do we deactivate, delete, rename content/files/etc... from the site and if so how can we allow site admins to control what actually gets deleted or kept?

I would say the simplest solution would be to delete the account and change all users content over to a dummy "guest" account. From a non-developer's standpoint this would be the simplest approach:

1. Locate all nodes/comments from "X user"
2. Change "X user" to "Guest"
3. Block Account, Log off user, delete sessions and other cleanup
4. Remove account

This way we can at least get something on the table and can be expanded further down the road. Sometimes just starting it can help fuel the fire. Maybe even down the road there could be a whole API to handle this. But it seems to me that there is a lot of what should happen when a user wants to remove themselves from the site. I just think we can start with one option and expand it from there.

subscribe