What happens when a user is deleted?
Well specifically are the entries in all the various possibly related tables cleared out and is the deleted column in mdl_user then set to 1, or is it simply a matter of setting that column to 1?
The reason I ask is that we've now got about 21,000 users who are 'deleted'.
It would be nice to actually delete these and to know that moodle would not put up puzzling error messages or break in a less polite manner at some point.
I've searched around for info about an Entity Relationship Diagram. With a view to writing something myself.
Apparently there isn't one. The relations are implicit in the php code. How many thousands of lines?
So in essentially retaining 'deleted' users am I also retaining huge amounts of data most of which will never be viewed much less used in any way?
By the way I do understand the rationale of archiving data or setting a flag in this way rather than crudely wiping out rows from tables, but does this mean that the database will eventually become enormous?
IMO for a project as large and complex as moodle there should be an ERD and it should be maintained and adhered to in scripts.
Paul R.
The reason I ask is that we've now got about 21,000 users who are 'deleted'.
It would be nice to actually delete these and to know that moodle would not put up puzzling error messages or break in a less polite manner at some point.
I've searched around for info about an Entity Relationship Diagram. With a view to writing something myself.
Apparently there isn't one. The relations are implicit in the php code. How many thousands of lines?
So in essentially retaining 'deleted' users am I also retaining huge amounts of data most of which will never be viewed much less used in any way?
By the way I do understand the rationale of archiving data or setting a flag in this way rather than crudely wiping out rows from tables, but does this mean that the database will eventually become enormous?
IMO for a project as large and complex as moodle there should be an ERD and it should be maintained and adhered to in scripts.
Paul R.
Re: What happens when a user is deleted?
I agree, it is very annoying that they aren't actually deleted. All the delete function does is mark them as deleted.
It would be perfect if there were a page in the administration area that let you view the deleted users and have the option to delete some or all deleted users.
Can this be added in 1.9.x?
It would be perfect if there were a page in the administration area that let you view the deleted users and have the option to delete some or all deleted users.
Can this be added in 1.9.x?
Re: What happens when a user is deleted?
I don't think this can or should be added in 1.9.x. Come to that, I don't think it should be added to 2.0 either - it would be a gigantomammoth task, and I don't think Moodle 2 needs yet more encouragement to slip to 2011. 
(To answer the original post - no don't delete them, yes if you do that it will break or output odd blank parts or otherwise get confused when you look at a page that refers to the user in some way, e.g. a forum post they made.)
So back to the 'problem'.. why do you actually care if there are a handful of extra users in the user table? Data-storage-wise, a few user entries - say 21,000 - is hardly significant in the overall scheme of things. What's that, a few tens of megabytes?
It isn't possible to coherently delete users without also deleting all references to that user ever. (For example, if they made a forum post, you'd better delete it. Do you really want this to happen?) I suppose a more sensible option might be to alter all references to this user so that they point to a special 'deleted user'. But do you really want all historical data about these users, and what they did, to be splurged into one such unidentifiable überuser?
In order to implement either feature (deleting everything that references the user, or changing everything to point to the 'deleted user' user) there would need to be a new API function which would have to be implemented by every module and plugin (including third-party). That's the fundamental reason why this can't happen in 1.9.
--sam
(To answer the original post - no don't delete them, yes if you do that it will break or output odd blank parts or otherwise get confused when you look at a page that refers to the user in some way, e.g. a forum post they made.)
So back to the 'problem'.. why do you actually care if there are a handful of extra users in the user table? Data-storage-wise, a few user entries - say 21,000 - is hardly significant in the overall scheme of things. What's that, a few tens of megabytes?
It isn't possible to coherently delete users without also deleting all references to that user ever. (For example, if they made a forum post, you'd better delete it. Do you really want this to happen?) I suppose a more sensible option might be to alter all references to this user so that they point to a special 'deleted user'. But do you really want all historical data about these users, and what they did, to be splurged into one such unidentifiable überuser?
In order to implement either feature (deleting everything that references the user, or changing everything to point to the 'deleted user' user) there would need to be a new API function which would have to be implemented by every module and plugin (including third-party). That's the fundamental reason why this can't happen in 1.9.
--sam
Re: What happens when a user is deleted?
Agree with Sam completely.
But if you really wanted to delete the user - we do fire a user_deleted event on user deletion.
If you wished to develop an unsupported module which completely deletes the user you could hook onto this event and delete the user completely in a relatively clean (but dangerous!) way.
see the hook in the code:
events_trigger('user_deleted', $user);
And docs: Development:Events (not looked to see if that documentation is complete, sorry).
ps. this is a useful hook more module authors should think about (I recall it because in cvs://contrib/patches/cleo_mis_tool I have something akin to the role_assignments table and currently patch in deletion of these references to the user deletion function in moodlelib.php from the 1.8 days. I intend to replace with a user_deleted event hook when I get round to it!)
But if you really wanted to delete the user - we do fire a user_deleted event on user deletion.
If you wished to develop an unsupported module which completely deletes the user you could hook onto this event and delete the user completely in a relatively clean (but dangerous!) way.
see the hook in the code:
events_trigger('user_deleted', $user);
And docs: Development:Events (not looked to see if that documentation is complete, sorry).
ps. this is a useful hook more module authors should think about (I recall it because in cvs://contrib/patches/cleo_mis_tool I have something akin to the role_assignments table and currently patch in deletion of these references to the user deletion function in moodlelib.php from the 1.8 days. I intend to replace with a user_deleted event hook when I get round to it!)
Re: What happens when a user is deleted?
To Second thaughts of sam marshall and Dan Poltawski,
IMHO It is not wiser to have a automated system which wipes of complete existence of a student.And no matter whether the users are necessary any more within the course the contributions he made has to be present saying his name (till the whole course gets over for all other users).
But when you consider the situations mentioned above (the users table growing big with no more useful data) and the reasoning behind not deleting it (will break the regular flow or hierarchy on some activities or resources ex:forum as sam mentioned), i would like to propose this idea, When a user is deleted why dont we move his details to a seperate table whereas all his related entity mappings should point to the moved table and the respective record.
when the course gets over and all the contents (resources and activities) are going to be changed for the new set of students, the admin can be given an option to delete them completely from the moved temporavary table.
By doing this we achive three vital things wrt to this issue
1. Users table contains only active users information
2. The users who are deleted will still have their trace left in the server in the name of contributions.
3. After a complete phase or cycle of a course completion the unwanted data's are removed.
Dear experienced moodlers please do comment on this.
IMHO It is not wiser to have a automated system which wipes of complete existence of a student.And no matter whether the users are necessary any more within the course the contributions he made has to be present saying his name (till the whole course gets over for all other users).
But when you consider the situations mentioned above (the users table growing big with no more useful data) and the reasoning behind not deleting it (will break the regular flow or hierarchy on some activities or resources ex:forum as sam mentioned), i would like to propose this idea, When a user is deleted why dont we move his details to a seperate table whereas all his related entity mappings should point to the moved table and the respective record.
when the course gets over and all the contents (resources and activities) are going to be changed for the new set of students, the admin can be given an option to delete them completely from the moved temporavary table.
By doing this we achive three vital things wrt to this issue
1. Users table contains only active users information
2. The users who are deleted will still have their trace left in the server in the name of contributions.
3. After a complete phase or cycle of a course completion the unwanted data's are removed.
Dear experienced moodlers please do comment on this.
Re: What happens when a user is deleted?
Since code all over Moodle uses SQL to join against the user table this idea will not work without many many changes all over Moodle.
What's the real problem here? Databases can handle millions of records without an issue. Just use "deleted=0" in your queries. All the other things you mentioned are still possible.
What's the real problem here? Databases can handle millions of records without an issue. Just use "deleted=0" in your queries. All the other things you mentioned are still possible.
Re: What happens when a user is deleted?
Well thanks but...
I wasn't sure who to reply to so I've replied to myself.
What I think should happen:
The deleted column is set to 1.
The activity log for the user is retained.
All other data is deleted.
This would not be hard had this issue been born in mind at the outset:
SQL Server has optional cascade deletion of related rows. So do MySql and postgres, and probably others.
Sooner or later it will be a matter of gigabytes for all those obsolete users.
I wasn't sure who to reply to so I've replied to myself.
What I think should happen:
The deleted column is set to 1.
The activity log for the user is retained.
All other data is deleted.
This would not be hard had this issue been born in mind at the outset:
SQL Server has optional cascade deletion of related rows. So do MySql and postgres, and probably others.
Sooner or later it will be a matter of gigabytes for all those obsolete users.
Re: What happens when a user is deleted?
So, wait, you actually do want to keep the mdl_user entry, but delete everything else (except log)? That's kind of the opposite of the original suggestion But it is definitely more feasible.
Even so, I'm a bit surprised that anyone would really want to suddenly delete (for instance) every forum post, glossary entry, etc made (or edited or otherwise touched) by a particular user.
This is definitely more feasible than altering the mdl_user entries, but again, is not likely to happen in 1.9 (the API might already exist thanks to the mentioned event that I didn't know about before, but it still needs to be implemented in every module, and I don't really see that happening).
Also note that if you don't keep courses forever, you don't run into this problem anyway. In other words if you have fast student turnover, you should probably arrange that you have a reasonable course turnover too; every year you could start from a new version of the course(s). [Create new versions using backup and restore without user data.] Deleting an old course will delete all the data associated with activities on that course, regardless of user status.
(Incidentally, cascade deletion is IMO an insanely dangerous tool that should virtually never be used as standard practice. And it wouldn't help in this case given that under your plan we would still need to keep the mdl_user row anyhow.)
--sam
Even so, I'm a bit surprised that anyone would really want to suddenly delete (for instance) every forum post, glossary entry, etc made (or edited or otherwise touched) by a particular user.
This is definitely more feasible than altering the mdl_user entries, but again, is not likely to happen in 1.9 (the API might already exist thanks to the mentioned event that I didn't know about before, but it still needs to be implemented in every module, and I don't really see that happening).
Also note that if you don't keep courses forever, you don't run into this problem anyway. In other words if you have fast student turnover, you should probably arrange that you have a reasonable course turnover too; every year you could start from a new version of the course(s). [Create new versions using backup and restore without user data.] Deleting an old course will delete all the data associated with activities on that course, regardless of user status.
(Incidentally, cascade deletion is IMO an insanely dangerous tool that should virtually never be used as standard practice. And it wouldn't help in this case given that under your plan we would still need to keep the mdl_user row anyhow.)
--sam
Re: What happens when a user is deleted?
Given that users are not physically deleted and only marked as such, does this mean it would be possible to implement an undo function?
Re: What happens when a user is deleted?
Yes, it is surely possible. I have actually implemented this fully in one of my Moodle's (see my post in MDL-16838). Unfortunately, it is Moodle 1.5.