Moodle
  1. Moodle
  2. MDL-22034

Restore a Backup from another Moodle fail

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major 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
    • Rank:
      32248

      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".

        Activity

        Hide
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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: