Moodle
  1. Moodle
  2. MDL-32792

Anonymised restore should not create anonymous user accounts

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Inactive
    • Affects Version/s: 2.2.2
    • Fix Version/s: DEV backlog
    • Component/s: Backup
    • Labels:

      Description

      By current implementation restore of anonymized backup creates anonymous user accounts which seem to merely pollute the server with inactive virtual users.

      It is not entirely clear what actual use case justifies such a behavior of restoring anonymized backup and at any rate there are use cases which require assigning restored anonymized data to the restorer rather than to a new anonymous user.

      The current backup/restore could be improved by making the owner of restored anonymized data a setting with the options 'restorer' and 'anonymous users'. Arguably, the 'restorer' option should be the default.

      It may also be useful to allow access to such settings (in the final and root tasks of the backup/restore) through the plan api so as to make the creation of variant plans easier. An example would be a backup/restore from within an activity that needs to pass in the current activity cmid and omit the module info step so that the restore won't create a new course module.

        Gliffy Diagrams

          Activity

          Hide
          Dan Poltawski added a comment -

          The problem is that in many cases the user information itself is part of the data which is attempting to be retained, even if anonymosied (i.e. the relation between multiple users)

          Take for example a forum thread - if we assign all the posts to a single user then we loose the fact that the discussion was taking place between multiple users.

          Furthermore (and the point I was trying to get across in the forum thread) we may actually break the relational integrity of the data by doing this. For example, in the workshop module there may be a database restriction which says that a piece of work can't be peer marked by the author. How would we deal with that?

          Show
          Dan Poltawski added a comment - The problem is that in many cases the user information itself is part of the data which is attempting to be retained, even if anonymosied (i.e. the relation between multiple users) Take for example a forum thread - if we assign all the posts to a single user then we loose the fact that the discussion was taking place between multiple users. Furthermore (and the point I was trying to get across in the forum thread) we may actually break the relational integrity of the data by doing this. For example, in the workshop module there may be a database restriction which says that a piece of work can't be peer marked by the author. How would we deal with that?
          Hide
          Itamar Tzadok added a comment -

          I'm still not sure how restored anonymized data can be useful on production servers. Since anonymous users are not real users restored anonymized data is unlikely to be used for anything but review/analysis in which case export would probably be a better approach.

          There may be ways to preserve the distinction between restored anonymized elements for forums and workshops without creating new anonymous users but it's probably not very important to explore them since the current method need not be eliminated. I'm merely proposing to make it optional and offer another option of assigning all restored data to the restorer. The default for this option could/should be determined by the module's backup definition.

          The requirement is particularly relevant in cases where the module serves as a resource but the content is still user content, for example the database module (or the dataform). The content may often be just samples meant to give the restorer some sense what it should look like and then replaced by the restorer with new content. Such content may not be transferable if it needs to create new users and that is prevented by the restorer's moodle admin.

          Show
          Itamar Tzadok added a comment - I'm still not sure how restored anonymized data can be useful on production servers. Since anonymous users are not real users restored anonymized data is unlikely to be used for anything but review/analysis in which case export would probably be a better approach. There may be ways to preserve the distinction between restored anonymized elements for forums and workshops without creating new anonymous users but it's probably not very important to explore them since the current method need not be eliminated. I'm merely proposing to make it optional and offer another option of assigning all restored data to the restorer. The default for this option could/should be determined by the module's backup definition. The requirement is particularly relevant in cases where the module serves as a resource but the content is still user content, for example the database module (or the dataform). The content may often be just samples meant to give the restorer some sense what it should look like and then replaced by the restorer with new content. Such content may not be transferable if it needs to create new users and that is prevented by the restorer's moodle admin.
          Hide
          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 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:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: