View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003596 | Composr | core | public | 2018-04-27 15:58 | 2019-07-08 20:06 |
| Reporter | Chris Graham | Assigned To | Chris Graham | ||
| Severity | Feature-request | ||||
| Status | resolved | Resolution | fixed | ||
| Product Version | |||||
| Fixed in Version | |||||
| Summary | 0003596: Easy deleting/anonymising of user data | ||||
| Description | We need to allow easy deleting/anonymising of any source of user data (e.g. accounts, submitted content, logs, stats). This should be integrated to the delete form, but also available as standalone. For any item/category of data allow specifying whether to delete it, or anonymise it, or keep it. Whether it is an item vs category would depend - log entry types would not need to be individually selectable, but content might be. It must be possible to run this on a username/member-ID after a member was deleted. | ||||
| Tags | ocProducts client-work (likely), Roadmap: v11, Type: Legal compliance / Privacy | ||||
| Time estimation (hours) | 16 | ||||
| Sponsorship open | |||||
|
|
Mention in tut_legal tutorial. |
|
|
This is implemented, with changes... "This should be integrated to the delete form, but also available as standalone." It is only implemented standalone. There is already a separate feature to delete individual items of member content on the member punishment form, designed for anti-spam purposes. I've amended the deletion form to cross-reference all the alternatives to deleting a member, including the privacy form, punishment form, account merge form, and the search module (for manually finding a user's content). This is cleaner. "For any item/category of data allow specifying whether to delete it, or anonymise it, or keep it. Whether it is an item vs category would depend - log entry types would not need to be individually selectable, but content might be." This would be unmanagable, generating a huge potential list that would be too cumbersome to work with given we're also dealing with individual log entries at the same time. Instead major content is findable from the normal search module (paginated content), or the punishment module (potentially very-long list of major content). For the case of removing privacy-affecting content in a fine-grained way, I've included a way to generate SQL queries that can be run manually in the database to find member-associated content. Additionally, the privacy-policy puts the responsibility on members to identify what content submissions they want deleted; the default for the privacy form is to just anonymise it. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-04-27 15:58 | Chris Graham | New Issue | |
| 2018-04-27 16:01 | Chris Graham | Tag Attached: Type: Legal compliance | |
| 2018-04-27 17:14 | Chris Graham | Sponsorship open | 0 => |
| 2018-04-27 17:14 | Chris Graham | Description Updated | View Revisions |
| 2018-05-02 17:50 | Chris Graham | Tag Attached: ocProducts client-work (likely) | |
| 2018-05-03 02:17 | Chris Graham | Note Added: 0005689 | |
| 2019-06-27 18:59 | Chris Graham | Tag Attached: Roadmap: v11 | |
| 2019-07-08 20:06 | Chris Graham | Assigned To | => Chris Graham |
| 2019-07-08 20:06 | Chris Graham | Status | non-assigned => resolved |
| 2019-07-08 20:06 | Chris Graham | Resolution | open => fixed |
| 2019-07-08 20:06 | Chris Graham | Note Added: 0006029 | |
| 2022-09-01 02:23 | Chris Graham | Tag Renamed | Type: Legal compliance => Type: Legal compliance / Privacy |
