Closed damon18 closed 4 years ago
You cannot give up the UID because it would be linked to a lot of other things (like people's forum posts). Hopefully no-one used the uname as a identifier. There is an event if memory serves correctly for user-delete user.account.delete
but this is intended for admin user use only. There is no legal right to "be forgotten" but more importantly, data integrity is the issue. There is an event for user delete so modules that rely on the userdata can take action. What action that is, in up to implementation. The UID IMO should never be removed.
I think that at least for privacy-sake, the uname should also never be used again.
I think that at least for privacy-sake, the uname should also never be used again.
Probably, but maybe it would be sufficient if all the current content that is identified by as a particular username is now changed to "user deleted" or something. Then after a configured period of time a username might be re-used.
Oh, I just did a test on what currently happens if a user who has content (Dizkus posts) is deleted and broke Dizkus, sorry. zikula-modules/DizkusModule#214
Dizkus should implement that event.
in thinking about this, the solution would require the data to be reassigned to a new user, not just an empty "nobody" because of Doctrine's dependence on entity relations. So this would mean constructing a core user and giving them a name like "unknown user" and then reassign from there. The new user would need a password that nobody should know and an email address such that nobody could log in as that user and wreak havoc. So, I'm thinking this "unknown user" should be created on installation of the core so that any module could use it if required. The email address could be a zikula.org email that is setup to pipe any incoming mail to null. The password could be a randomly generated string that is immediately encrypted. The name could be translated at least on Installation. Thoughts? @cmfcmf @Guite @drak
This was already considered when @rmburkhead did the work on the users module. We would allow an admin to delete users and fire an event so that any subscribers who relied on the module can take whatever action they needed (Dizkus was specifically discussed :grinning: in this regard). It's not the core's business after this point.
I would also say that if someone wants to make a "My Account" - user delete widget, then that is fine, but I doubt it would be something we include in the core because it's such a problematic area. Certainly, modules that rely on user data SHOULD subscribe to the user delete event.
@guite handles this in MOST by assigning all stuff made by the deleted user to the admin. But for Dizkus this is no option of course.
I think an "unknown" core user would be fine. If we don't have such a user, Dizkus had to create one, and all the other modules with these problems would have to create one, etc.
Re Diskuz, we're getting off topic, that's a module specific ticket.
On the topic of this issue, there was a module for this in 1.2.x by quan-Florian @ifs-net that is awaiting adoption at https://github.com/ifs-net/UserDeletion
After some research it looks like most major user-content websites do allow users to delete their own account. They all make it difficult to some degree both to retain users and to prevent "deletion remorse".
Old but well written article about major website policies here. http://www.smashingmagazine.com/2010/06/11/how-to-permanently-delete-your-account-on-popular-websites/
I actually like the Facebook option to "deactivate account for a specified time" they offer as an alternative to Facebook suicide.
As I said in the related PR, I think we should eliminate this option entirely and change it to "deactivation". There are potential parts of Zikula websites that will be like the wikipedia model in the referenced article where the deletion of the author could have other negative impacts on the site.
I propose to postpone this feature to a later milestone.
ACK
:+1: 1.5.0
I think we should address this issue with 3.0. Either implement it or decide we never want it and close it.
I think to solve this properly (my view) would be to add setting in users module like allow users to delete/disable their own account. Then when this is "checked" chose between deleting completely or deactivation or any other action. This should be GPRD compliant which means including right to be forgotten/delete stuff as well (at least the core).
Either implement it or decide we never want it and close it.
:+1: for implementing it.
setting in users module like allow users to delete/disable their own account
Yes! A module variable would be helpful.
compliant
Sidenote: As far as I know, it is not legally necessary to be able to implement this right at the push of a button. It would also be sufficient to be able to contact the admin to demand that the data be deleted.
Additional note:
All modules which store a user id need to implement user deletion handlers.
In ModuleStudio there are three options for each user field:
ADMIN
- Sets the corresponding user id to 2 (admin user).GUEST
- Sets the corresponding user id to 1 (guest).DELETE
- Deletes the entity.feels good when you can close an 8 year old ticket. 🎉 🎆
feels good when you can close an 8 year old ticket. 🎉 🎆
@craigh That's got to be a record for a ticket I opened! Looks like I was ahead of my time on the need to allow users to delete their account and data. (GDPR)
Now if I could find a way to upgrade thebeachcats.com and other "orphan" sites still running Zikula 1.2.10 :confounded:
a way to upgrade
I took a quick look. Looks like there are some nuts to crack :thinking:
a way to upgrade
I took a quick look. Looks like there are some nuts to crack 🤔
Yes, some great big hairy ones.. I'll send you an email (for your entertainment) rather than airing my dirty laundry here.
Feature Request and Discussion
In "My Account" a user can change their email and password. Similarly they should be able to delete their user account.
Issues