Users do not have anyway to delete their accounts in a Plone site.
I searched the site, but have not seen any discussion on this issue. I believe this would be a very useful feature and remove the need for a user to email the site admin and ask for this. I am considering hiring someone to look into this. First I want to get input from this group:
has this been considered? Is there anything I need to be aware of that isn't obvious.
I would see this: a logged in user would have "Delete My Account" (perhaps on the fly out with "log out" and other options). The user would select this option, get a "are you sure" (perhaps the requirement to authenticate again. ). The system would log out the user and somewhere in this process the "magic" would happen.
i realize the permission needed would be site admin (based on the fact that deleting a user is now done in site setup). would this be a show stopper?
I am concerned about such a comment. In every system I want to be able to close my personal/own account for reasons I care about. The handling of stale content is a policy question. The privacy laws of some countries require that you should be able to remove all related personal content. Different policies may apply to community sites or company sites. In this case you need a process to handle the stale ownership. But answering "Why would someone want to delete their account" scares me.
It's a question about the reason for this feature request. When clients ask me "can X do Y?" I ask this question because I want to better understand the objective, and because in my experience it is very often the case that the immediately requested feature is either not going to accomplish the real objective or that it is not the best way to accomplish it.
Give me a break Andreas. I'm not some sinister person and I appreciate data privacy.
A technical difficulty has already be hinted at: objects (content objects, the catalog, ...) may contain references to the deleted user - based on the user id.
Depending on whether those references are all deleted with the user account, they might get wrongly associated should a new user later be created with the same id. Of course, this problem does not exist if "uuid"s are used as user ids.
Here is the reason I posted the original question. I host several smaller sites that one of the key functions is to send emails when content added, events added, etc.
So the reason for the delete ability is a person has left the group and no longer wants email.
As for the orphan content, I don't see this as a technical issue, it would need to be addressed even if the deletion was done by the admin (cerrtainly we have to acknowledge that users will be delted).
One possibility is, during the user deletion, we could auto create a new user to replace "john" with "john_deleted" and all content the "john" created would now be owned by "john_deleted". This allows the content to be identified with the original creator; however, it could be handled differrently and would be obvious to the admin. As to what state that should be in depends on the situation and couldn't be handled by a program.
this goes to another issue I am investigating: there is a Plone 4 product that allows you to change ownership of content. I'm looking iinto this and may try to bring it into Plone 5. this could be used to resolve this issue of orphaned. either the content would be deleted (if it is personal) or changed ownership (if it is work related). this is separate from this deleting self question.
any thoughs on how best to accomplish deleting a user. Is replacing the user with a _deleted' user a good idea?
In that case, wouldn't an "unsubscribe" function suffice?
If user self-deletion were to be implemented, it seems to me you have a few choices on how to deal with their content:
Do what regular user deletion does (i.e.. when an admin deletes a user, what does Plone currently do with the deleted user's content?)
Warn the user that all their content will also be deleted. Then you have to implement a catalog search for all their content and delete it.
Change the ownership of all their content. But to which user? Some generic placeholder user like "zombie content owner"? I think that would be a bad idea; that content would remain on the site but would not have anyone responsible for it. Also, your idea of changing "John" to "John_deleted" doesn't change the fact that there would be a growing amount of not-really-owned content on the site. What if some of that content becomes out of date or contains otherwise "bad" or unwanted information? I think it's best to delete content of deleted users.
Currently Plone does nothing, if some one deletes a use, as fare as i know.
I would go with option 3, but i don't see any problem in giving the owner to the admin user of the portal.
Deleting the content is a bad option.
Or the content could be somehow tagged, for review, so the admin can decide later to cleanup this if needed.
I thing a tag could be enough or a special WF state, but a tag is way simpler.
BTW @tkimnguyen I got your first command also wrong like Andreas, but after clearing this, it is good to ask of course.
But sometime the written word can have multiple meanings, so better a sentence more to make it clear
if a user deleted his/her profile, also the userfolder (in this project this was the only place users where able to create content in) also got deleted.
we implemented a form that describes the consequences and added a "i'm really sure" checkbox.
the form handler did the following:
mtool = getToolByName(self.context, 'portal_membership')
mdtool = getToolByName(self.context, 'portal_memberdata')
#obtain the current member
assert not mtool.isAnonymousUser(), "we should have an authenticated user call this method"
memberId = mtool.getAuthenticatedMember().getId()
#using this protected method does not work (requires post request) so we do the
#same steops in this unrestricted code.
#mtool.deleteMembers([memberId], delete_memberareas=1, delete_localroles=1, REQUEST=self.context.REQUEST)
#XXX make sure context is siteroot
mtool.deleteLocalRoles( self.context, [memberId], reindex=1, recursive=1 )
acl_users = mtool.acl_users
except (AttributeError, NotImplementedError, 'NotImplemented'):
raise NotImplementedError('The underlying User Folder '
'doesn\'t support deleting members.')
#logout the user so he does not get confused (am i deleted or still logged in)
#refreshing the page leads to the login_form anyway
why would someone want to leave their content on a site that is not going to use anymore?
I found this as a perfectly valid use case that could be covered by a third-party add-on an not by the Plone core itself, because of all the implications it has especially for sites with a lot of content.
After reading the posts, I would like to try to summarize the inputs
I believe it is an important function to allow users to remove their account (and their personal information) from any site they have created. The issue of content created by a user is more problematic and is addressed below. I recognize there isn’t universal agreement on this, that is why this is proposed as an optional add on product.
A user should be able to delete their account and, at a minimum, their personal information and stop receiving any messages from any Plone site. This account deletion should be final. To me, this is a privacy issue. Again, personal opinion; however, I don’t see any reason why a person shouldn’t be able to remove themselves.
A user will delete themselves as follows:
a. Log in
b. In the flyout next to their name, This will be added: “Delete Account”
c. If selected, this happens: a) require to log in again (this would be a nice touch, if not too difficult); b) text box explaining your account and personal information will be deleted (we may want to explain about what happens to content (deleted or not). Continue Y/N
d. If yes, I assume the user is logged out and the deletion happens (not a programmer, so just a guess). The user account is permanently deleted.
The content the user created is more problematic as to who owns, and thus who can delete it. Since Plone has broad uses in many countries, there will never be agreement on this issue, so a configlet with options is required.
e. To handle content retention/deletion, there would be a configlet with the options:
i. “Will users have option to delete their content during account deletion? Yes/No” (Note: if no, then issue of orphaned content would have to be handled, maybe by using the ‘user_deleted’ approach. 2) if user won’t be allowed to delte their created content, this should be clearly stated during the sign up process.
ii. If yes to above, do you want content deleted permanently or automatically assigned to ‘user_deleted’? (Radio button to choose) (Note: either option will prevent orphaned content, which should not allowed as it isn’t good site practice.)
iii. If “assigned to ‘user_deleted’ chosen, should the content be moved back to Private state to run through approval process again? Y/N
(Note: the purpose here is to ensure the content will go through the site approval process to determine if it is still relevant/appropriate for the site.
The wording/functionality on the configlet obviously needs work, but I think the intent is clear.
I believe this would allow users to control their personal information; however, give site admins the option to control content created for the site. Thus, sites could allow users to completely control their created content (allow them to delete it) or take control of the content, viewing it as property of the site. Allowing this option removes the debate over privacy, which varies widely across the world. (Note: this issue of who controls the content could be fully addressed to the prospective user during account creation.)
In most organisations the content outlives the employees, but in Plone the content life cycle is not complete.
A couple of organisations I worked with had to be able to transfer the ownership of all content created by one user to one other user. In our case the employee responsible for content is leaving before knowing who will take over responsibilities, so we allowed admins to search for two users and transfer the ownership of all content from one to another. In your scenario of a user deleting his/her own account, it would be good to allow the user to search for another user and transfer ownership to that user before deleting the account.
(This is an old post that I had started but didn't post, but it was here when I came back to view this thread. Please ignore)
Hi. Yes transferring created content to a new user is critical.
Question might be who should decide? So, when user deletes account should they be the one to decide to whom they transfer their content?
Or, should it be the admin/another designee ( Editor?)
I would say it should be admin/designee for a couple of reason: a) person leaving organization not always in best of terms and the ability for mischief is there. 2) person leaving may not know or care. 3) Their replacement may not have been hired
I figure by only allowing the admin/designee (the Editor role to me would be the most likely). To handle this I make a very reasonable simplifying assumption
So in summary I think during the setup it could be designated which Role should be allowed to reassign content