Moodle
  1. Moodle
  2. MDL-32792

Anonymised restore should not create anonymous user accounts

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.2.2
    • Fix Version/s: DEV backlog
    • Component/s: Backup
    • Labels:
    • Rank:
      39796

      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.

        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.

          People

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

            Dates

            • Created:
              Updated: