#5584 - Handle catalogue fields in privacy system
-
By PDStig
- Added
- 5 views
| Identifier | #5584 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | Handle catalogue fields in privacy system |
| Status | Open |
| Tags |
Roadmap: v11 (custom) Type: Legal compliance / Privacy (custom) |
| Handling member | Chris Graham |
| Addon | core_privacy |
| Description | Currently, only the download privacy action handles catalogue fields (via serialise).
Also handle catalogue fields in the anonymise privacy action, and get_selection_sql privacy code module function: get_selection_sql: piggy-back off of catalogue_entries... in catalogue_entries, JOIN on the catalogue field values field hooks: Add a new method: privacy_anonymise. Return true if catalogue fields of this type should be anonymised via the privacy system. Generally, anything involving members, usernames, IP addresses, e-mails, legal names, phone numbers, etc should be true. privacy hook: Add the table holding fields and their values to the hook, with ANONYMISE as the default and only allowed method. Don't define anything for the fields. Add this table as an exception in privacy_hooks unit test when it complains about not defining this because it has no personal data fields defined. anonymise: Add an anonymise override on the privacy hook. When running on the table dealing with catalogue field values, check the field type and determine via the field hook if it should be anonymised (providing it matches criteria). It should be anonymised if either the value directly matches the criteria or its parent catalogue_entries row passes the is_owner check. |
| Steps to reproduce | |
| Additional information | This is work I'm going to do untracked as I'd like to see this functionality |
| Related to | |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
get selection SQL: cannot easily piggy back because we'd be joining on many tables (catalogues store entry values depending on field type)
Field hooks: Instead of defining in the hook whether to anonymise it, I added a new setting when creating fields on catalogues: "May contain personal information". That way, admins can define per-field which ones should be handled by privacy.
I did add a new method in some field hooks, privacy_field_type, to define how the privacy system should treat this field (e.g. what criteria to match against it). By default, privacy treats as an additional anonymise field unless this method returns otherwise.
Added IP address field hooks so admins can define IP addresses specifically; necessary so the privacy system can treat them as such.
Did NOT add the tables holding catalogue values to privacy hooks (at least not yet). It won't work the way I'd want it to considering values are stored separately from fields.
--- WHAT NEEDS DONE ---
* Currently v11 only matches against the catalogue entry details itself, not the values within an entry. So if a (sensitive) field contains, say, a member ID, it still won't match in privacy unless the catalogue entry itself matched. I have absolutely no idea right now how to remedy this; it is a very complex problem. Deferring to Chris on this one.