I deleted a user from interface in Moodle 3.5 but when I checked that same in database that user data wasn't cleared. I don't know the logic behind, but if a user wants to remove all his data from a system, then his all data whether that is in the database or any other place (related to system) should be deleted
Hi Rishi,
Please can you clarify whether you deleted the user via the Browse users page or by approving the user's request for their data to be deleted?
Hi Helen,
I deleted the user via both process (via the Browse users page and by approving the user's request).
Hi Rishi,
What tables of the data base still held user data after approving the user's request?
Hi Al
I'm just trying to implement the delete request as well. I see the user record in the users table although they can't log on and don't appear in the admin browse users list.
Richard
What appears to happen is this:
- user gets a deleted flag set
- username is replaced by email plus numeric code
- email entry gets obscured/encoded in some way
Therefore I assume this is intentional.
It does mean if you are reporting data from your plugin (eg attempts), you have to be a bit more careful (with your sql queries) or their records will still appear to teachers.
Hi Richard,
The results you are seeing have been standard for a long time. I don't have a Moodle 2.0 or 2.1, but from Moodle 2.2 forward, what you describe is what happens when you delete someone. Except for the email part, that is what I also see in Moodle 1.9.19. In it the email is blanked out entirely.
Thanks Al
I suppose there is a debate about what right to be forgotten actually means and the contrasting need to keep some data in the system for various legitimate reasons (certification, alleged abuse, change of mind, accidental erasure and falsified deletion requests to name a few).
I never really looked at this area from a dev perspective before GDPR.
Cheers
Richard
I am sure that the need to keep some data is going to be problematic in more than one plugin. The need to keep some data is one of the things giving me problems with the MooTyper plugin. I've had the fix ready to go from a student standpoint, but what if it is the teacher leaving and they want to be forgotten? No problem, if they never made any lesson categories and never made any exercises. But, what if they came up with all the lessons categories and exercises? That is the predominate case, as I do not supply anything but a couple of sample lessons and exercises for guides in getting started. If I arbitrarily delete everything per their request, I run the risk of breaking every MooTyper activity for every student as well as the whole site.
I think my only viable option is to change ownership from that of the leaving teacher, to the site admin like the sample lessons. I suppose that will mean that there will need to be a warning about this condition that teachers will need to agree to before using MooTyper.
I think there is a need here to distinguish between personal data and data created by a person.
A forum post, a submitted assignment, a grade given, etc. are all personal data in that they relate, in some way, to that person (their opinions, their ability, etc.).
Lesson categories, typing exercises, forum instance settings, assignment configuration, etc. are not personal data - whilst it is true that they were created by a person, they are not about that person and do not express anything about them (and in many cases, there is no stored link between the person who created them and the data itself).
Thanks for the clarification, Davo. This will make my provider.php much simpler as I had things working that way back before May 25. Besides, the teacher has had the capability to remove/delete any lesson category or exercise they made, for many versions now.
Just to be clear - what I've written above is my best understanding of the situation and should not be construed as legal advice. However, I'm confident enough to use that as the basis for how I've worked with the checklist module: I export extra checklist items that a student has added for themselves, as well as the check marks against a student, whether made by the student or one of their teachers; I do not export general checklist items created by a teacher (when exporting the teacher's personal data), nor do I consider comments about a student's progress to be personal data of the teacher (it is about the student, so it is included in the student's export, but not the teacher's - this last part is a little more uncertain).
Thanks Al
I suppose there is a debate about what right to be forgotten actually means and the contrasting need to keep some data in the system for various legitimate reasons (certification, alleged abuse, change of mind, accidental erasure and falsified deletion requests to name a few).
I never really looked at this area from a dev perspective before GDPR.
Cheers
Richard
My understanding is that the right to be forgotten allows for data to be anonymised rather than deleted if required.
That suggests that obfuscating the first/last/alternative/user names and email address within the user table is sufficient in most cases. The principle (as I understand it - and I am not a lawyer!) is that any data should not be identifiable back to the user (even via links to other systems such as student record information systems), not that all the data necessarily needs to be deleted.
There may be a case for requiring a text search through any possible content such as forum posts, but that is problematic itself too (what if the reference to an individual is contained in a file attachment etc).
Of course, user deletion/anonymisation is a little different to what a plugin needs to report about the info it may hold on a user!
And again - I am not a lawyer and any institution should seek proper legal advice around GDPR and user deletion/data reporting.
Hi Richard,
When we delete a user from Moodle, a column in table mdl_user called deleted is set to 1, making it not to appear anywhere in the browse user list and reports.
Not sure but if the entire user data including his/her personal details along with the data associated with the user must also be removed.
What is the point of changing the flag and not entirely deleting the user and his data?
There is some kind confusion which occurred while working on auth plugin where I was only checking the user existed in the database or not, and if yes then log him into the site.
Then I found out there should to be 2 more conditions to be checked i.e. the user is not suspending and not deleted.
The user which are no longer existed their data is still there.
Even if you delete all the courses from the site but their data will be still there for each user, which doesn't make any sense.
You will still find the user data in the moodle data folder.
Then I found out there should to be 2 more conditions to be checked i.e. the user is not suspending and not deleted.
The user which are no longer existed their data is still there.
Even if you delete all the courses from the site but their data will be still there for each user, which doesn't make any sense.
You will still find the user data in the moodle data folder.
Gopal
Well, I think prior to GDPR there were always legitimate reasons for maintaining data in the database - there are all kinds of requirements for schools and universities some of which apply even with GDPR requirements, so marking the deleted flag in the database and ensuring that any and all front-end applications (such as auth plugins, reports, etc) comply with that flag (and the suspended one) was always sufficient.
Even with GDPR there are legitimate reasons for needing to maintain some of the data - if you simply delete a user from the database, what happens to their forum posts for example? and then what happens to any replies to those posts? You could lose an entire thread because one user gets deleted - and if that forum is a graded activity and you lose all the other student's contributions...
It really isn't as simple as a user should be deleted along with all their data.
The new GDPR plugins take a different approach, but its still a more complex situation than simply removing the user from the database.
And yes, there are flags to check, not just whether the user exists, as other plugins do.
Thank you, Richard, for your response which pretty much explains many of the doubts which I had.
All of my doubts were basically related with GDPR, and most of these have been taken care by Moodle 3.5.
We simply can't afford to delete all the data related to a particular user.