#5512 - Secondary Privacy block detailing the data stored in the database
-
By PDStig
- Added
- 8 views
| Identifier | #5512 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | Secondary Privacy block detailing the data stored in the database |
| Status | Closed (no changes needed) |
| Tags |
Type: Legal compliance / Privacy (custom) |
| Handling member | Deleted |
| Addon | core_privacy |
| Description | We have a block for auto-generating a Privacy Policy.
Let's have another block saved on another Comcode page (which the default Privacy Policy links to). This block will go in-depth regarding the data that is stored in the site database. For each table installed: * It will list its description to explain to the member the purpose of that table and its data (database_relations.php) * It will utilize privacy hooks to inform the member of any sensitive data that is stored in it, such as member_id_fields, ip_address_fields, email_fields, and additional_anonymise_fields * It will inform the user how long the data is stored in that table and what happens to it afterwards via retention_days and retention_handle_method * It will inform the user what will happen to their data in that table if they delete their account / their account gets deleted (via removal_default_handle_method) * It will inform the member what purging actions are allowed for that table via allowed_handle_methods should they contact staff to have their data removed. * It will inform the member if the data in that table will persist in website backups through the website software (but add a disclaimer that should the site admins use a different method of backing up, the data which persists in the backups may be different; perhaps be smart about this and detect via if there are any scheduled backups set) It will skip any tables which do not have any member_id_fields, ip_address_fields, email_fields, and additional_anonymise_fields defined as these tables are assumed to contain no member data. |
| Steps to reproduce | |
| Additional information | * database_relations.php should probably be modified to use do_lang for the descriptions... e.g. DATABASE_RELATIONS_table_name_DESCRIPTION=Description of the table. Do not require a do_lang result, and omit tables with no result.
* (If a similar test does not already exist) Add a unit_test that checks every table and compares it to the privacy hooks. If member_id_fields, ip_address_fields, email_fields, or additional_anonymise_fields is defined, and there isn't a table description defined, then it fails the test. |
| 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