Moodle
  1. Moodle
  2. MDL-16838

Administration: Loss of user data during delete

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.9, 2.0
    • Fix Version/s: DEV backlog
    • Component/s: Administration
    • Labels:
    • Affected Branches:
      MOODLE_19_STABLE, MOODLE_20_STABLE

      Description

      As best as I can tell, the delete_user function in /lib/moodlelib.php causes data loss when deleting a user. The problem from my perspective is that the username is replaced with the email address concatenated with the time. The goal is to make the old username, email, and idnumbers available for use. However, as implemented, we lose the username and id number. The email could be found in the new username field. I think a better solution would be to use the description field and prepend a concatenation of those field to the description. Then if we opt to enable the ability to undelete a user, we could attempt to repopulate those fields (providing they do not conflict with an already existing username, email, or idnumber). Alternatively, another simpler solution would be to use username+time, email+time and idnumber+time; however, my concern would be that the username and email fields are varchar(100). Although I suspect that would be fine, in theory, a long username or email would get concatenate but that may be a risk worth taking since implementing would be so easy. Peace - Anthony

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            Anthony Borrow added a comment -

            changing to critical since technically speaking it results in a loss of data

            Show
            Anthony Borrow added a comment - changing to critical since technically speaking it results in a loss of data
            Hide
            Anthony Borrow added a comment -

            Here is a quick patch that uses the second approach of appending time to the username, email, and idnumber. At least that way no data is lost. One complication that could emerge down the road is that if a user has been deleted, recreated manually and deleted again you could have multiple deleted records for the same username at which point we would have to assume undeleting (should we wish to go down that road) the latest one.

            Show
            Anthony Borrow added a comment - Here is a quick patch that uses the second approach of appending time to the username, email, and idnumber. At least that way no data is lost. One complication that could emerge down the road is that if a user has been deleted, recreated manually and deleted again you could have multiple deleted records for the same username at which point we would have to assume undeleting (should we wish to go down that road) the latest one.
            Hide
            Anthony Borrow added a comment -

            Thinking about this further the period separator is not the best since that character is already allowed in the username - so we should use something else but I think the basic idea here is clear.

            Show
            Anthony Borrow added a comment - Thinking about this further the period separator is not the best since that character is already allowed in the username - so we should use something else but I think the basic idea here is clear.
            Hide
            Petr Skoda added a comment -

            the problem here is that we MUST delete a lot of data when deleting users, we can not keep role assignments, group membership, grades, subscriptions, etc forever on large sites; aslo the delete should be a two stage - see the proposed user purging in linked issues

            we are/will be using user preferences to remember other information about suspended users, I guess we could store username and email there too in 2.0 when deleting

            Show
            Petr Skoda added a comment - the problem here is that we MUST delete a lot of data when deleting users, we can not keep role assignments, group membership, grades, subscriptions, etc forever on large sites; aslo the delete should be a two stage - see the proposed user purging in linked issues we are/will be using user preferences to remember other information about suspended users, I guess we could store username and email there too in 2.0 when deleting
            Hide
            Dan Poltawski added a comment -

            Just linking to MDL-16647 which raises the issue about username storage too

            Show
            Dan Poltawski added a comment - Just linking to MDL-16647 which raises the issue about username storage too
            Hide
            Anthony Borrow added a comment -

            uploaduser.php could be used to "undelete" or restore a user; however, with the current storing of the information it is currently not possible. When and if it is possible then we should also take care of restoring unread messages.

            Show
            Anthony Borrow added a comment - uploaduser.php could be used to "undelete" or restore a user; however, with the current storing of the information it is currently not possible. When and if it is possible then we should also take care of restoring unread messages.
            Hide
            Robert Brenstein added a comment -

            I have been using the method suggested in MDL-16647 for a good year now. I have also added an interface to undelete users – we have cases nowadays, when students return to use our system after 3 or more years of absence. I have added an admin panel parallel to the user list which shows the deleted users with undelete instead of the delete link. When undeleting, the delete field is set to 2 not 0, so a) login procedure can recognize that and ask to update the profile, and b) that automatic deletion (cron) does not delete those users again. Whatever way of storing deleted users data is implemented, the user deletion should be looked at more comprehensively, that is properly support deletion, undeletion, as well as discarding – we are slowly approaching the stage when discarding (see MDL-7918) will come into play.

            Show
            Robert Brenstein added a comment - I have been using the method suggested in MDL-16647 for a good year now. I have also added an interface to undelete users – we have cases nowadays, when students return to use our system after 3 or more years of absence. I have added an admin panel parallel to the user list which shows the deleted users with undelete instead of the delete link. When undeleting, the delete field is set to 2 not 0, so a) login procedure can recognize that and ask to update the profile, and b) that automatic deletion (cron) does not delete those users again. Whatever way of storing deleted users data is implemented, the user deletion should be looked at more comprehensively, that is properly support deletion, undeletion, as well as discarding – we are slowly approaching the stage when discarding (see MDL-7918 ) will come into play.
            Hide
            Anthony Borrow added a comment -

            Robert - I like the idea of being able to delete and undelete especially if we then add an option to discard deleted students. For example, I can envision this being very helpful for a high school in the following scenario. A student enters as a freshman, is asked to leave for a year during the sophomore year, comes back as a junior. Graduates as a senior. The student is added as a freshman, deleted during sophomore year, undeleted his junior year, and the can be deleted again after graduation. After a period of time the school may wish to discard deleted students to clean up the database. It would be at this point that all role assignments, materials, etc. would be discarded and be irrecoverable. Part of what I would like to see is some type of backup option for the individual student that would take all of their activity, grades, etc. and zip it up for them. This will need to be worked through with a fine tooth comb and I will not digress into all the details of that. But I can see delete and undelete being useful. Peace - Anthony

            Show
            Anthony Borrow added a comment - Robert - I like the idea of being able to delete and undelete especially if we then add an option to discard deleted students. For example, I can envision this being very helpful for a high school in the following scenario. A student enters as a freshman, is asked to leave for a year during the sophomore year, comes back as a junior. Graduates as a senior. The student is added as a freshman, deleted during sophomore year, undeleted his junior year, and the can be deleted again after graduation. After a period of time the school may wish to discard deleted students to clean up the database. It would be at this point that all role assignments, materials, etc. would be discarded and be irrecoverable. Part of what I would like to see is some type of backup option for the individual student that would take all of their activity, grades, etc. and zip it up for them. This will need to be worked through with a fine tooth comb and I will not digress into all the details of that. But I can see delete and undelete being useful. Peace - Anthony

              People

              • Votes:
                2 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated: