-
Improvement
-
Resolution: Fixed
-
Minor
-
3.7
-
MOODLE_37_STABLE
-
MOODLE_37_STABLE
-
In our institution we do not want our 'DPO' staff to be able to make delete requests.
Delete requests are dangerous as obviously they delete the user's data meaning that our system stops working for the user. Although there are plenty of steps in the process, we and they are still worried that it might happen by accident, so we have been requested to remove the option.
(Some background: our process is that we will never apply student deletion requests on our main system - we can use various other aspects of GDPR law to justify keeping the data for all students for the retention period.)
Currently if you give somebody the tool/dataprivacy:managedatarequests capability, they by default become a DPO, or you can configure the role list in admin settings... this capability is weird... Anyway my point is there is an existing tool/dataprivacy:managedatarequests capability, it is complicated and I don't want to change it.
Proposal
Add a new capability
tool/dataprivacy:requestdeleteforotheruser
1. When visiting the form for making a new request for another user, admin/tool/dataprivacy/createdatarequest.php?manage=1, if you do not have this new capability then the 'Type' dropdown would be fixed to the single value 'Export all of my personal data'. (The form field will be frozen so it doesn't appear as a dropdown any more.) You will not be able to select the other option 'Delete all of my personal data'.
2. If making a request for yourself (the same form but without the manage=1) then there is no change and both options will be available regardless of capabilities. (Note: We could consider also adding a second new capability tool/dataprivacy:requestdelete, that works a similar way but for individuals - we haven't got that requirement here but I'm happy to get it implemented as part of this if people think it would be beneficial/more consistent.)
3. The new capability would initially be made to default to the value of tool/dataprivacy:managedatarequests (so maintaining existing behaviour).
4. The development should include a simple Behat scenario to check the new feature (i.e. set up a role that does/doesn't have this capability, go to the form and confirm the option is/isn't there).