Is there any documentation on what exactly gets deleted when users get deleted in moodle?
Specifically, I just deleted a user from our test system, which also deleted submissions in courses, and his messages from the messaging system. However, what was not deleted is his forum posts.
Generally, does it make any difference if I delete a user manually, or use the new GDPR data deletion tool?
I could not test this, because when I tried to delete an expired user with the GDPR data deletion, I got this message:
"The context "[username]" still has sub-contexts that have not yet expired. No contexts have been flagged for deletion."
I found this confusing, since I thought the data deletion tool enables me to always delete users and their respective data from courses?
As you've found, not all data is deleted when you manually delete an account. Please see the documentation Browse list of users for further details.
MDL-62564 is for ensuring that the same data is deleted when manually deleting an account as when a user has requested their account to be deleted.
so right now, the GDPR plugin deletes more information than manually deleting a user?
unfortunately, the browse list of users documentation doesnt really show what gets deleted and what remains, but if i understand correctly, right now deleting a user is not GDPR-compliant, while deleting a user via the GDPR interface is?
do you have any idea what the issue with the "The context "[username]" still has sub-contexts that have not yet expired. No contexts have been flagged for deletion." error could be? i could not find any information on that.
We are currently working on a set of changes to improve this behaviour to support the automatic creation of deletion requests when a user is deleted in Moodle (including deletion via CSV, and bulk interfaces) (MDL-62564).
We are also working on a separate feature improvement to create deletion requests for existing users who have been deleted.
I believe that I have also encountered the other issue you mentioned and am looking at how best to address that issue. If it is the same issue, essentially the user has a block on their Dashboard, and that block has a longer expiry than the user. This block should be included as part of the user and is incorrectly being mixed in with course-level blocks. I hope to have this change separated from the changes I'm currently working on and addressed soon, but it's non-trivial to fix.
so if I understand you correctly, when MDL-62564 is resolved, manually deleting a user will not result in the same thing as a deletion request, but manually deleting a user will create a deletion request for that user in the GDPR data deletion list?
If this is correct, I hope that by then the data deletion list can be used in a sensible way (sorted, exported, shown on one page, shows meaningful columns, etc.). Because right now the list is unusable for large amounts of data (see also: https://tracker.moodle.org/browse/MDL-62590)
My problem is:
- We wanted to delete users after 1 year of inactivity. I already set this in the data registry
- Now I have a list of 6500 users in data deletion - I absolutely do not want to delete them without cross-checking them with our user database, however I cannot do that since the data deletion list cannot be sorted, exported, shown on one page, and doesnt show the login name
- From what I've gathered, there is no way to purge the data deletion list again - even if I change the user retention period, users will still stay in the deletion list
We now settled on manually deleting users for GDPR reasons. However, as I just found out, manually deleting does not equal deletion requests. So in the current status, what MDL-62564 means for me is, that upon manually deleting an account, I have to search through 350 pages of unsortable lists for each user to find the specific entry in the data deletion list, and then delete the user again from there .
That's correct. Manually deleting a user will ask the DPO to confirm the deletion request first.
As of Moodles 3.3.8, 3.4.5, and 3.5.2 we have already added sorting, and filtering of requests.
We are also in the process of adding bulk deletion, and user-selectable pagination sizes (though limited to about 200 as I recall).
As you can see, we are actively developing and adding new functionality to the privacy system. Many of these features are currently being backported to 3.3, 3.4, and 3.5, though this trend will cease in November with the release of Moodle 3.6.
thats awesome, I'm glad to see all this progress
if the deletion list is improved, then I don't really have a problem to confirm user deletion there as well.
One more question: do you know if there is a way to get users off the deletion list again? Changing the retention period did not put users off the deletion list, so is there any other way? Maybe directly via the database?
I've been writing unit tests for this functionality today as it happens as part of MDL-63401. When that issue is integrated, the next time that either the calculation task, or the deletion task runs then the record will be removed from the list.
It is possible to delete it directly in the database, but I would not recommend doing this - at the moment this will work, though you should not delete any records marked as already having been deleted as we use these to keep track of locations which have already been wiped without being deleted yet (i.e. all forum posts and data have been removed, but the forum itself still exists).
I'm also adding a cleanup task to remove those user blocks, and to remove 'orphaned' records (i.e. when that forum is removed we can then delete the record which relates to it).
Hope this helps,