View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005513 | Composr | core_privacy | public | 2023-12-28 19:02 | 2024-08-04 23:34 |
| Reporter | Patrick Schmalstig | Assigned To | Patrick Schmalstig | ||
| Severity | Feature-request | ||||
| Status | resolved | Resolution | fixed | ||
| Product Version | |||||
| Fixed in Version | |||||
| Summary | 0005513: Auto-delete certain data when an account is deleted | ||||
| Description | The GDPR expects that when a user deletes their account, the website no longer maintains any data of that user except that which is absolutely necessary (and to disclose in the Privacy Policy which data persists). Currently, Composr does not delete any user data when they delete their account. We expect members to separately contact staff for that. We shouldn't do that. Add a task (using the task queue when applicable) that fires in the background when a member deletes their account. It will run through every privacy hook and perform the removal_default_handle_method action on data that meets one or more of the following criteria: * Any member_id_fields contain the ID of the member who was deleted * Any ip_address_fields contain the most recent IP address of the member AND either has no member_id_fields defined, has the deleted member in at least one of the member_id_fields, or has nothing but the guest ID in member_id_fields * Any email_fields contain the e-mail of the deleted member Also anonymise all additional_anonymise_fields on the rows matching any of the above criteria. | ||||
| Tags | Roadmap: v11, Type: Legal compliance / Privacy | ||||
| Time estimation (hours) | |||||
| Sponsorship open | |||||
| related to | 0005512 | closed | Patrick Schmalstig | Composr | Secondary Privacy block detailing the data stored in the database |
| related to | 0005514 | closed | Patrick Schmalstig | Composr testing platform / automation goals | Add a unit test for removal_default_handle_method and allowed_handle_methods in privacy hooks |
| related to | 0005849 | closed | Patrick Schmalstig | Composr | Add more staff control over user deletion |
|
|
Actually, we already have purge member. Perhaps a tick box (option whether it's ticked by default) that sends a request to the admin upon account deletion (would of course have to be communicated through email). Uses tickets system if implemented to ensure security (can verify the email of the member), else sends a regular email. For regular email, from site email, to staff email, reply to member email. Always CC to the member. Staff option: * Never auto-delete user data on deletion * Ask user via (above) tick box * Always delete user data (not recommended because staff would have to customize the hooks to make absolutely sure it is what they want) |
|
|
Also moved member deleting into a task as it should ideally run in the task queue. But I added protections... e.g. when a member requests to have their account deleted, it is put in the task queue, however: * Their session is invalidated (logged out) * Their password compat scheme is changed to "pending_deletion" which will prevent them from logging in while the account is pending deletion * The password compat scheme will also trigger member does not exist when others try to view their profile |
|
|
I don't really understand this one. Are we saying that if a new tickbox is checked, account deletion is paused pending staff doing a manual purge (that they sanity check), but otherwise the account is auto-deleted with data otherwise being left intact? |
|
|
No, When a member requests their account to be deleted, it's all automatic. The new process is as follows: * Their session is invalidated, and their password scheme is changed to a special one indicating it is pending deletion (so they cannot log in again even if it hasn't yet been actualised... and so no one can view their profile). The actual deletion is added to the task queue because it can be a resource-intensive operation depending on how much content there is to delete. * On the delete page, they are also asked if they want their data to be purged as well. If ticked, a purge operation is also performed on their content in the queued task (before the member is actually deleted). It uses the default actions as specified in the privacy hooks. |
|
|
Ok, I think maybe we need to have a staff notification for an account being deleted (if it does not already exist). And if the new option is "Never auto-delete user data on deletion", provide a link to do a purge manually. |
|
|
I can do that |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-12-28 19:02 | Patrick Schmalstig | New Issue | |
| 2023-12-28 19:02 | Patrick Schmalstig | Status | non-assigned => assigned |
| 2023-12-28 19:02 | Patrick Schmalstig | Assigned To | => Patrick Schmalstig |
| 2023-12-28 19:03 | Patrick Schmalstig | Tag Attached: Roadmap: v11 | |
| 2023-12-28 19:03 | Patrick Schmalstig | Tag Attached: Type: Legal compliance / Privacy | |
| 2023-12-28 19:04 | Patrick Schmalstig | Relationship added | related to 0005512 |
| 2023-12-28 19:09 | Patrick Schmalstig | Relationship added | related to 0005514 |
| 2024-01-14 17:37 | Patrick Schmalstig | Note Added: 0008189 | |
| 2024-01-29 03:30 | Patrick Schmalstig | Status | assigned => resolved |
| 2024-01-29 03:30 | Patrick Schmalstig | Resolution | open => fixed |
| 2024-01-29 03:30 | Patrick Schmalstig | Note Added: 0008269 | |
| 2024-03-30 03:28 | Patrick Schmalstig | Project | Composr alpha bug reports => Composr |
| 2024-03-30 03:52 | Patrick Schmalstig | Category | General / Uncategorised => core_privacy |
| 2024-08-04 22:53 | Chris Graham | Note Added: 0009096 | |
| 2024-08-04 23:06 | Patrick Schmalstig | Note Added: 0009101 | |
| 2024-08-04 23:07 | Patrick Schmalstig | Note Edited: 0009101 | View Revisions |
| 2024-08-04 23:22 | Chris Graham | Note Added: 0009108 | |
| 2024-08-04 23:32 | Patrick Schmalstig | Note Added: 0009112 | |
| 2024-08-04 23:34 | Patrick Schmalstig | Relationship added | related to 0005849 |
