Uploaded image for project: '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

      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

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            skodak Petr Skoda added a comment -

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

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

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

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

            sending totally untested patch for proper suspend/review

            • new admin user list UI option - suspend/revive
            • untested required ldap changes
            Show
            skodak Petr Skoda added a comment - sending totally untested patch for proper suspend/review new admin user list UI option - suspend/revive untested required ldap changes
            Hide
            skodak Petr Skoda 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
            skodak Petr Skoda 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
            skodak Petr Skoda 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
            skodak Petr Skoda 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
            skodak Petr Skoda added a comment -

            adding more ppl here

            Show
            skodak Petr Skoda added a comment - adding more ppl here
            Hide
            stronk7 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
            stronk7 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
            skodak Petr Skoda 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
            skodak Petr Skoda 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
            dougiamas Martin Dougiamas added a comment -

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

            Show
            dougiamas Martin Dougiamas added a comment - Looks a bit scary right now, I need to read/try it ...
            Hide
            stronk7 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
            stronk7 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
            Hide
            marina Marina Glancy added a comment -

            We have detected that this issue has been inactive for over two years and also did not collect many votes. It is possible that it has been already implemented in a more recent version of Moodle, or it is not highly demanded. There are unlimited number of ways Moodle functinality can be expanded and improved but we would like to concentrate on the features that will benefit majority of users, and which can not be implemented as plugins. If you have a suggestion for improving Moodle core, and there is no open issue for it in the tracker, please start a new forum discussion to see how many other users agree with you, and then create a new issue providing as many details as possible.

            ==BLK2YIMP20141121==

            Show
            marina Marina Glancy added a comment - We have detected that this issue has been inactive for over two years and also did not collect many votes. It is possible that it has been already implemented in a more recent version of Moodle, or it is not highly demanded. There are unlimited number of ways Moodle functinality can be expanded and improved but we would like to concentrate on the features that will benefit majority of users, and which can not be implemented as plugins. If you have a suggestion for improving Moodle core, and there is no open issue for it in the tracker, please start a new forum discussion to see how many other users agree with you, and then create a new issue providing as many details as possible. ==BLK2YIMP20141121==

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: