Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-22034

Restore a Backup from another Moodle fail

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Not a bug
    • Affects Version/s: 1.9.8
    • Fix Version/s: 1.9.9
    • Component/s: Backup
    • Labels:
      None
    • Database:
      PostgreSQL
    • Affected Branches:
      MOODLE_19_STABLE
    • Fixed Branches:
      MOODLE_19_STABLE

      Description

      I backup and restore courses between two moodle-instances. They were not (and don't have to be) connected, but the Login-ID's came from the same AD.

      Everything worked fine with moodle 1.9.7 - but now (1.9.8): Moodle-ID AND Login-ID have to be the same! Well, that's not what I have - and I'm not able to connect those moodles together (because one has to run very local with no connection to the internet...). Restore breaks up with: "trying to restore user xyz from backup file will cause conflict".

        Gliffy Diagrams

          Activity

          Hide
          stronk7 Eloy Lafuente (stronk7) added a comment -

          Hi Dennis,

          the "trying to restore user xyz from backup file will cause conflict" means that such user (xyz) already exists in destination site AND that moodle isn't sure they are, really the SAME user (based in some email and/or user first access date information).

          These email/user creation date were introduced in Moodle 1.9.7+ because before them, the match of users used to happen only by username and thad could (was, in fact) leading to problems with restored information assigned to users that weren't correct.

          So, since Moodle 1.9.7+ we are more consistent about how user matching is performed, preventing any restore to happen if some conflicts are found. Way, way, safer.

          If you are 100% sure than your xyz user is the SAME in source and target sites... then just make their email to be the same (or their first access), so they will match and restore will happen.

          Ciao

          Show
          stronk7 Eloy Lafuente (stronk7) added a comment - Hi Dennis, the "trying to restore user xyz from backup file will cause conflict" means that such user (xyz) already exists in destination site AND that moodle isn't sure they are, really the SAME user (based in some email and/or user first access date information). These email/user creation date were introduced in Moodle 1.9.7+ because before them, the match of users used to happen only by username and thad could (was, in fact) leading to problems with restored information assigned to users that weren't correct. So, since Moodle 1.9.7+ we are more consistent about how user matching is performed, preventing any restore to happen if some conflicts are found. Way, way, safer. If you are 100% sure than your xyz user is the SAME in source and target sites... then just make their email to be the same (or their first access), so they will match and restore will happen. Ciao
          Hide
          schorsch101 Dennis Meyer added a comment -

          Hi, thanx for the fast report.

          Well - all my users stored in an ActiveDirectory. Name, Login-Name and E-Mail came from AD and are equal on both moodles. E-Mail, Login-Name are the same - just the Moodle-ID is different. (My error came from here: 1D - If match by username and mnethost and doesn't match by id => conflict, return false / restorelib.php).

          Best regards
          Schorsch

          Show
          schorsch101 Dennis Meyer added a comment - Hi, thanx for the fast report. Well - all my users stored in an ActiveDirectory. Name, Login-Name and E-Mail came from AD and are equal on both moodles. E-Mail, Login-Name are the same - just the Moodle-ID is different. (My error came from here: 1D - If match by username and mnethost and doesn't match by id => conflict, return false / restorelib.php). Best regards Schorsch
          Hide
          stronk7 Eloy Lafuente (stronk7) added a comment - - edited

          1D ? But weren't you trying to restore in different site? If the instances are different... then the steps 2A...2D should be happening. How did you create those sites?

          Show
          stronk7 Eloy Lafuente (stronk7) added a comment - - edited 1D ? But weren't you trying to restore in different site? If the instances are different... then the steps 2A...2D should be happening. How did you create those sites?
          Hide
          schorsch101 Dennis Meyer added a comment -

          Ah - okay! Thanks for that hint
          I work with a copy of a productive moodle - that's why hash&url were the same. My fault :-/
          I guess I have to work on it...

          Thanx a lot
          Schorsch

          Show
          schorsch101 Dennis Meyer added a comment - Ah - okay! Thanks for that hint I work with a copy of a productive moodle - that's why hash&url were the same. My fault :-/ I guess I have to work on it... Thanx a lot Schorsch
          Hide
          stronk7 Eloy Lafuente (stronk7) added a comment -

          NP! I guess that by changing the hash ($CFG->siteidentifier) is enough to force rules 2A..2D to be used instead of the 1A..1D ones.

          In fact, there is one "secret" setting... if you look to the restore_check_user() function you will find it (I don't want to publish it too much for now)... that allows to "force" the 2A...2D (different site) conditions to be always used. Perhaps it's useful in you case (don't use it in the prod server!)

          Resolving as not a bug.

          Ciao

          Show
          stronk7 Eloy Lafuente (stronk7) added a comment - NP! I guess that by changing the hash ($CFG->siteidentifier) is enough to force rules 2A..2D to be used instead of the 1A..1D ones. In fact, there is one "secret" setting... if you look to the restore_check_user() function you will find it (I don't want to publish it too much for now)... that allows to "force" the 2A...2D (different site) conditions to be always used. Perhaps it's useful in you case (don't use it in the prod server!) Resolving as not a bug. Ciao

            People

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

              Dates

              • Created:
                Updated:
                Resolved:
                Fix Release Date:
                8/Jun/10