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
    • Rank:
      2206

      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

        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 Škoda 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 Škoda 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: