User account self-delete (UASD2) [Deleted]

What happens if the user deletes himself?
Will all postings be deleted or is the user only anonymized?
 
Hi :-))).

Some ideas:
  1. DSGVO require to anonymize the username as well. I use "Gast$user_id" (Guest$user_id).
  2. Some of the mods said it is a bad idea that users have the option to delete himself after they got a penalty. So my idea is to save the checksum of the email in a seperate table and check it on each registration.
  3. The user should be logged out after the request. If the user login in the period the deletion should cancel automatically.
  4. Change usertitel of user so other users are able to recognize it.
 
Some of the mods said it is a bad idea that users have the option to delete himself after they got a penalty. So my idea is to save the checksum of the email in a seperate table and check it on each registration.

I don´t like ths method, keep it straight. Instead of keeping the checksum we should think about an option to let UASD deactivate a user account, instead of hard deleting, when a user has received {x} warning points or user priviliges have been revoked in the last {y} days. With regards to the GPDR, in those cases we have a legitimate interest to prevent a specific user registering twice or at all. Since the specific user isn´t deleted, we have account data still present. That has the benefit, that implemented antispam-services still can check new registrations against the user data and we are complying with the GPDR.

@au lait , what do you say? Something that would make sense to you?
 
I think if the user want to delete the account you have to delete all the personal data (not posts!). If you have a legitimate interest that the user should not be able to register a new account you can keep some data to prevent a new registration. To encyrpt the email and store it in a seperate table you are able to delete the account completely and prevent new registration.

Or if you have a legitimate interest to store personal data (userid, blank email, username) UASD could backup it in a seperate table?

I think if you only deactivate an account the user will disturb you via email.

Maybe both options?
 
I think if you only deactivate an account the user will disturb you via email.
May be I just don´t get it - but what would prevent him 'disturbing' me when his account would be deleted? And why should this happen - when he´s deactivated instead - more often? :unsure:
 
Most of the users now believe that you have to delete all data and some of them try to force me with lawyer... that is what I mean with disturbing ;-). For them it is important that the profile is not viewable after deletion.

Now I can't use this addon because I don't want that users with warning points are able to delete their account.
To disable or delete (with backup) the user in case of warning points would be very nice.
 
Most of the users now believe that you have to delete all data and some of them try to force me with lawyer... that is what I mean with disturbing ;-). For them it is important that the profile is not viewable after deletion.
Just avoid this with an appropriate statement in your privacy policy. But I wouldn´t have a problem to have both optional - but thats up to Sebastian.
 
I think, for security means, Admins shouldn't be able to Delete their accounts, so I suggest to add a Groups-based permission to disable this functionality for certain groups.

Thanks for the add-on!
 
Hello @au lait,

I would like to report a major performance issue with your addon.

The member list pages are very slow.

I think I found why...

With your database join, query is executed in 5.6234 second(s) :
Code:
SELECT `xf_user`.*, `xf_xenmade_uasd_SelfDelete_1`.*
FROM `xf_user`
LEFT JOIN `xf_xenmade_uasd` AS `xf_xenmade_uasd_SelfDelete_1` ON (`xf_xenmade_uasd_SelfDelete_1`.`user_id` = `xf_user`.`user_id`)
WHERE (`xf_user`.`is_banned` = 0) AND (`xf_user`.`user_state` = 'valid') AND (`xf_user`.`message_count` > 0)
ORDER BY `xf_user`.`message_count` DESC
LIMIT 60

Without it, query is executed in 0.0090 second(s) :
Code:
SELECT `xf_user`.*
FROM `xf_user`
WHERE (`xf_user`.`is_banned` = 0) AND (`xf_user`.`user_state` = 'valid') AND (`xf_user`.`message_count` > 0)
ORDER BY `xf_user`.`message_count` DESC
LIMIT 60

Can you provide a fix please ?
 
I think, for security means, Admins shouldn't be able to Delete their accounts, so I suggest to add a Groups-based permission to disable this functionality for certain groups.

Thanks for the add-on!
in the next version



I would like to report a major performance issue with your addon.
The member list pages are very slow.
I think I found why...

I've made changes! Reasons for the slow query I cannot name any
Shouldn't be. Indexes are available.

fixed in the next version
 
Hello, I'm testing this addon and it works fine but how can I intercept in some way the pending deletion request in order to show the user a reminder notice or to put him in a different user group or to send him an email confirming the deletion request and so on?
Thank you!
 
Hello, I'm testing this addon and it works fine but how can I intercept in some way the pending deletion request in order to show the user a reminder notice or to put him in a different user group or to send him an email confirming the deletion request and so on?
Thank you!

in the upcoming version the following things are included:
  • Email reminder that a deletion is pending
  • E-mail confirmation of deletion
  • Logout option
  • Re-Login terminates Account Deletion
  • Move user to another group
 
Wow looks great :) You're a genius! If you could also include prevent admin account deletion it'd be perfect!
 
Top Bottom