Details
-
Type:
Sub-task
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 1.8, 1.9
-
Fix Version/s: DEV backlog
-
Component/s: Administration, Authentication
-
Labels:
-
Affected Branches:MOODLE_18_STABLE, MOODLE_19_STABLE
Description
See discussion http://moodle.org/mod/forum/discuss.php?d=86007
I have been using CAS authentication (based on LDAP) for two years, running auth_ldap_sync every night.
With Moodle 1.6, the users were deleted when they disappear from valid LDAP branch. And they were revived when they reappear in this branch. That was perfect for me.
Since Moodle 1.7:
- either the users are suspended; they cannot no longer connect to Moodle but they still appear in Moodle, in particular as course participant because their enrolments were not deleted
- either the users are deleted; but they will get a new account when they will reappear in valid LDAP branch
How to process users having been deleted/deactivated/suspended from LDAP? I think we need 5 different settings, from "do nothing" to "fully delete".
1) Keep internal
- does no change in Moodle
- however the user cannot log in Moodle because he cannot identify against LDAP
2) Suspend internal
- only one change in Moodle : tagged as "suspended"
- the user can no longer log in Moodle
- he still appears as course participant
- he would be be revived in Moodle if he did reappear in LDAP
3) Hide internal (new setting)
- the user is tagged as "hidden" in Moodle
- he can no longer log in Moodle
- he does no longer appear as course participant
- he would be revived in Moodle if he did reappear in LDAP (with his previous enrollments)
4) Deactivate internal (new setting, like "delete internal" in Moodle 1.6)
- the user is tagged as "deactivated" in Moodle
- he is unenrolled from his Moodle courses
- he can no longer log in Moodle
- of course he does no longer appear as course participant
- he would be revived in Moodle if he did reappear in LDAP (without any enrollment)
5) Delete internal
- the user is tagged as "deleted" in Moodle
- he is unenrolled from his Moodle courses
- his email and idnumber are cleared
- of course he can no longer log in Moodle
- of course he does no longer appear as course participant
- of course he won't be revived in Moodle if he did reappear in LDAP
Attachments
Issue Links
| This issue is duplicated by: | ||||
| MDL-13377 | Allow manual undeletion of users by admins from Browse Accounts page. |
|
|
|
| This issue has been marked as being related by: | ||||
| MDL-13363 | auth/db fails to undelete users, as the username field has been munged. |
|
|
|
| MDL-13162 | auth/db should reset email when undeleting users |
|
|
|
| MDL-9281 | auth sync_users does not reactivate suspended users |
|
|
|
| MDL-17219 | Privacy improvements project ideas for 2.0 |
|
|
|
| MDL-16838 | Administration: Loss of user data during delete |
|
|
|
Activity
- All
- Comments
- History
- Activity
- Source
- Test Sessions
I totally agree with Arnaud's proposition 
It would really be perfect
It would really be perfect My current plan is to make a patch that:
1/ removes the automatic undelete support completely - no automatic undelete
2/ add cleanup of user settings after delete, keep only module data
3/ implement suspend/resume suitable for automatic synchronisation
4/ implement data purging of deleted users - partially similar to reset, this should go deep into modules and remove all user submitted data
5/ fix all authplugins
at the same time keep full backwards compatibility
the options above would be too difficult to implement, we can not patch everything to respect so many states, sorry 
1) Keep internal
- does no change in Moodle
- however the user cannot log in Moodle because he cannot identify against LDAP
2) Suspend internal
- change auth plugin to suspended and store previous auth value in user preferences
- the user can no longer log in Moodle
- he still appears as course participant
- he would be be revived in Moodle if he did reappear in LDAP
- username is "reserver", nobody can reuse it
- it is possible to "Login as" this user
3) Delete internal
- the user is tagged as "deleted" in Moodle
- he is unenrolled from his Moodle courses
- his email and idnumber are cleared
- delete grades, preferences, custom profile fields + $modname_user_deleted() and block hooks
- of course he can no longer log in Moodle
- of course he does no longer appear as course participant
- of course he won't be revived in Moodle if he did reappear in LDAP
- username can be reused
+ manual purging
- user record anonymised
- logs removed
- user stats removed
- cleanup module $modname_user_purged() and block hooks
1) Keep internal
- does no change in Moodle
- however the user cannot log in Moodle because he cannot identify against LDAP
- change auth plugin to suspended and store previous auth value in user preferences
- the user can no longer log in Moodle
- he still appears as course participant
- he would be be revived in Moodle if he did reappear in LDAP
- username is "reserver", nobody can reuse it
- it is possible to "Login as" this user
- the user is tagged as "deleted" in Moodle
- he is unenrolled from his Moodle courses
- his email and idnumber are cleared
- delete grades, preferences, custom profile fields + $modname_user_deleted() and block hooks
- of course he can no longer log in Moodle
- of course he does no longer appear as course participant
- of course he won't be revived in Moodle if he did reappear in LDAP
- username can be reused
- user record anonymised
- logs removed
- user stats removed
- cleanup module $modname_user_purged() and block hooks
sending fresh patch with:
- improved delete
- new suspend/revive support
- delete and purge cleanup implementation
- UI for delete/purge cleanup (hidden - go to http://site/admin/deletedusers.php)
- needed ldap auth plugin changes (not tested yet)
going to work more on this tomorrpw 
- improved delete
- new suspend/revive support
- delete and purge cleanup implementation
- UI for delete/purge cleanup (hidden - go to http://site/admin/deletedusers.php)
- needed ldap auth plugin changes (not tested yet)
Hi Petr,
some comments about this:
1) One silly comment. Why are we calling them "xxxx INTERNAL". Everytime I read that, it suggests me that the auth mode is changed to internal and the user will continue being a "internal" user, not connected to the external auth source (ldap, db...) but working internally. +1 to name them keep, suspend and delete. Just that.
2) When suspended, user auth is changed to "nologin" correct? I see you store original auth method in preferences (to be able to restore it back, cool). What I'm not able to get is the difference stabilised by that $manual parameter, what is it about? I'm sure something needs to be differentiated.. but... what?
3) I really got lost with the delete_user() purge_user() and deleted_user_cleanup().... for example:
a) Why do you set the picture to 0 in the delete_user() function. If we keep names I think it's ok to leave picture.
b) deleted_user_cleanup() is only called if ($verbose) and you've moved all the stuff to deleted_user_cleanup() if I'm not wrong that breaks backwards compatibility because $verbose=false by default so now role unassign and others will happen now.
c) deleted_user_cleanup() seems to delete too much by default, calling modules and so on. I really like current status where user is simply "disabled" but all the activity remains there. How is this addressed now?
d) And then, I got completely lost when I saw modules & blocks have also one potential _purge_user() function, can you, plz, comment differences with _cleanu_user() ones?
Uhmmmm... +-1 for now, IMO (got really crazy reading the patch, I'm getting old).
1/ I do not like the internal word too - confusing
2/ if you suspend from UI, the plugin should not automatically revive it, on the other hand if plugin suspeds it user should not be able to revive easily in UI (except in advanced edit where you can do anything)
Originally the delete did nothing which was wrong both for performance and privacy reasons, but we did not have suspend so there was no other way, Starting with 1.9 we have suspend and delete user removes roles, groups and grades.
The difference between "delete cleanup" and "purge" is that delete cleanup removes only data which other normal participants may reacted to (== can see). Purge saves some db/disk space and can be used for privacy reasons when somebody requests full account delete.
The delete cleaunup removes pictures in this patch, why not? It could be in fact better to use some new general icon for delted accounts.
The patch is not finished yet == I might have overlooked some regression while doing several refactorings
I would like to dicuss this with MD tomorrow...
2/ if you suspend from UI, the plugin should not automatically revive it, on the other hand if plugin suspeds it user should not be able to revive easily in UI (except in advanced edit where you can do anything)
Originally the delete did nothing which was wrong both for performance and privacy reasons, but we did not have suspend so there was no other way, Starting with 1.9 we have suspend and delete user removes roles, groups and grades.
The difference between "delete cleanup" and "purge" is that delete cleanup removes only data which other normal participants may reacted to (== can see). Purge saves some db/disk space and can be used for privacy reasons when somebody requests full account delete.
The delete cleaunup removes pictures in this patch, why not? It could be in fact better to use some new general icon for delted accounts.
The patch is not finished yet == I might have overlooked some regression while doing several refactorings
I would like to dicuss this with MD tomorrow... Just one more thing to delete (user tags). Are you sure you are doing that ok?
IMO you can delete tags by userid. You need to:
1) Delete tag instances belonging to that user (itemid AFAIK). Can use API for that.
2) Move userids in instances, correlation and tag to another user. Not API present, although it'll be ok to have it API-ed.
Ciao
Thanks for the report, this is a very good start!