We need to make a series of changes in Mahara to comply with the GDPR. More info is available on the wiki at https://wiki.mahara.org/wiki/Developer_Area/Specifications_in_Development/GDPR_compliance
Currently, only when self-registration is turned on can users delete their account. This should be possible for anyone though also for those from external authentication methods or those that had accounts created manually in institutions where self-registration is not allowed.
Sometimes, institutions may like to keep certain student content (upon agreement) and thus account deletion could not be good if the student hadn't already transferred their content to an area where it can be retained.
Therefore, it might be good to implement a "Review account before self-deletion" option in an institution. This could work the following way:
1. User clicks the "Delete" button and is informed that the admin receives a notification and will need to approve the deletion. They'd also get the general warning that all their content in their personal portfolio area will be deleted but that group content stays, but is not associated with their name anymore.
2. In their account settings page they'll see when they triggered the deletion and if they don't receive a message, can re-trigger it and append a message to the institution admins.
3. The request for deletion triggers a notification to the institution admins (or site admin if there is no institution admin) letting them know about this action. They can then approve the deletion or deny it and provide a mandatory reason so that the student can get in touch with them and discuss the deletion.
Checking the code I noted that in fact, we have a configuration setting for deleting users.
If we add in config.php
$cfg->alwaysall
we are able to delete any user, even if there is no self-registration enabled in any institution. We can always delete a user but the last admin of the site. But I consider this correct as the admin does not represent a real person but a role in the system.
Now the question is, should we leave the 'alwaysallowsel