Moodle
  1. Moodle
  2. MDL-13563

Hiding but not deleting users who are suspended in LDAP

    Details

    • Affected Branches:
      MOODLE_18_STABLE, MOODLE_19_STABLE
    • Rank:
      333

      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

        Issue Links

          Activity

          Hide
          Petr Škoda added a comment -

          Thanks for the report, this is a very good start!

          Show
          Petr Škoda added a comment - Thanks for the report, this is a very good start!
          Hide
          Séverin Terrier added a comment -

          I totally agree with Arnaud's proposition
          It would really be perfect

          Show
          Séverin Terrier added a comment - I totally agree with Arnaud's proposition It would really be perfect
          Hide
          Petr Škoda added a comment -

          sending totally untested patch for proper suspend/review

          • new admin user list UI option - suspend/revive
          • untested required ldap changes
          Show
          Petr Škoda added a comment - sending totally untested patch for proper suspend/review new admin user list UI option - suspend/revive untested required ldap changes
          Hide
          Petr Škoda added a comment - - edited

          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
          Show
          Petr Škoda added a comment - - edited 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
          Hide
          Petr Škoda added a comment -

          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

          Show
          Petr Škoda added a comment - 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
          Hide
          Petr Škoda added a comment -

          adding more ppl here

          Show
          Petr Škoda added a comment - adding more ppl here
          Hide
          Eloy Lafuente (stronk7) added a comment -

          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).

          Show
          Eloy Lafuente (stronk7) added a comment - 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).
          Hide
          Petr Škoda added a comment - - edited

          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...

          Show
          Petr Škoda added a comment - - edited 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...
          Hide
          Martin Dougiamas added a comment -

          Looks a bit scary right now, I need to read/try it ...

          Show
          Martin Dougiamas added a comment - Looks a bit scary right now, I need to read/try it ...
          Hide
          Eloy Lafuente (stronk7) added a comment - - edited

          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

          Show
          Eloy Lafuente (stronk7) added a comment - - edited 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

            People

            • Votes:
              3 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

              • Created:
                Updated: