Moodle
  1. Moodle
  2. MDL-32572

Cannot create any new User Account via database synchronization if user with different auth type already present

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.2.2, 2.3.2, 2.4
    • Fix Version/s: 2.2.6, 2.3.3
    • Component/s: Authentication
    • Labels:
    • Database:
      MySQL
    • Testing Instructions:
      Hide

      1/ set up external user table with several accounts which include user with username 'admin' (collision with normal admin)
      2/ set up auth_db
      3/ execute cli sync in auth_db in verbose mode
      4/ verify in master you are told about admin username collision, in 22 and 23 make sure general insert error is displayed
      5/ try to log in as the new users
      6/ switch to internal passwords for auth_db and manually set new passwords for the users
      7/ try to login with the new passwords

      Show
      1/ set up external user table with several accounts which include user with username 'admin' (collision with normal admin) 2/ set up auth_db 3/ execute cli sync in auth_db in verbose mode 4/ verify in master you are told about admin username collision, in 22 and 23 make sure general insert error is displayed 5/ try to log in as the new users 6/ switch to internal passwords for auth_db and manually set new passwords for the users 7/ try to login with the new passwords
    • Workaround:
      Hide

      Remove/change colliding usernames in other auth plugins or change auth type to 'db' for existing users.

      Show
      Remove/change colliding usernames in other auth plugins or change auth type to 'db' for existing users.
    • Affected Branches:
      MOODLE_22_STABLE, MOODLE_23_STABLE, MOODLE_24_STABLE
    • Fixed Branches:
      MOODLE_22_STABLE, MOODLE_23_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      w38_MDL-32572_m24_authdbduplicates

      Description

      Hello,

      This is about creating using account through database synchronization

      I have this working on 1.9.14+ but for 2.2.2+, it's giving me an error

      sudo -u apache /usr/bin/php /var/www/html/moodle2test/auth/db/cli/sync_users.php -v

      User entries to add: 146
      !!! Error writing to database !!!

      So I turned on debugging and got this ...
      -----------------

      User entries to add: 146
      !!! Error writing to database !!!
      !! Duplicate entry '5-000186727' for key 'mdl_user_mneuse_uix'
      INSERT INTO mdl_user (firstname,lastname,email,username,confirmed,auth,mnethostid,lang,timecreated,timemodified) VALUES(?,?,?,?,?,?,?,?,?,?)
      [array (
      0 => 'Kardassian',
      1 => 'Kim',
      2 => 'kim.kardassian@student.ourschool.com',
      3 => '000186727',
      4 => 1,
      5 => 'db',
      6 => '5',
      7 => 'en',
      8 => 1333141068,
      9 => 1333141068,
      )] !!
      !! Stack trace: * line 397 of /lib/dml/moodle_database.php: dml_write_exception thrown

      • line 893 of /lib/dml/mysqli_native_moodle_database.php: call to moodle_database->query_end()
      • line 935 of /lib/dml/mysqli_native_moodle_database.php: call to mysqli_native_moodle_database->insert_record_raw()
      • line 375 of /auth/db/auth.php: call to mysqli_native_moodle_database->insert_record()
      • line 91 of /auth/db/cli/sync_users.php: call to auth_plugin_db->sync_users()
        !!

      looks like the same as this bug recorded ...

      http://tracker.moodle.org/browse/MDL-29267

      I figured out the cause... it works better in 1.9.x =)

      Everyday we have new users that we can insert into moodle taken from a delimited file which is inserted into a database for synchronization. At the end of the work day (Monday to Friday), we rename this file so it would create a new one. If not, new accounts will be appended to this text file.

      This is the cause of the problem.

      When we append new records, existing ones already exist from the previous day's synchronization. That is why we get this error.

      In version 1.9.x, we don't have this problem as it will just skip it...

      User entries to add: 62
      Error inserting user 000186727
      Error inserting user 000173269
      .....
      Error inserting user 000331042
      Inserted user 000331043 id 60992
      Inserted user 000331044 id 60993
      Inserted user 000331045 id 60994
      Inserted user 000331046 id 60995
      ......

      Note how in 1.9.x it continues on and adds the new users at the end BUT NOT IN 2.2.2+.

      In version 2.2.2+, it stops at the first instance of the error and does not add any new ones.

      Is there a fix to this so it would like for 1.9.14+?

      Thank you.

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            Michael de Raadt added a comment -

            Thanks for reporting that.

            I've put that on the backlog.

            In the meantime feel free to help us work on this issue. If you are able to provide a patch, please add a patch label so we will spot it.

            Show
            Michael de Raadt added a comment - Thanks for reporting that. I've put that on the backlog. In the meantime feel free to help us work on this issue. If you are able to provide a patch, please add a patch label so we will spot it.
            Hide
            Lawrence N added a comment - - edited

            I created a workaround.

            I will simply replace/overwrite the delimited file with new accounts every time; import them into a database and our moodle 2.2.2+ synchronize these accounts for now.

            Again, 2.2.2+ should behave like 1.9.14.x where it skips dupes.

            ====

            User entries to add: 121
            Error inserting user 000195400
            Error inserting user 000195854
            Error inserting user 000228027
            Error inserting user 000321140
            Error inserting user 000322136
            Error inserting user 000324317
            Error inserting user 000328383
            Error inserting user 000332159
            Error inserting user 000332161
            Error inserting user 000332162
            Error inserting user 000332163
            Error inserting user 000332167
            Error inserting user 000332171
            Error inserting user 000332173
            Error inserting user 000332174
            Error inserting user 000332175
            Error inserting user 000332176
            Error inserting user 000332177
            Error inserting user 000332178
            Error inserting user 000332179
            Error inserting user 000332180
            Error inserting user 000332181
            Error inserting user 000332182
            Error inserting user 000332183
            Error inserting user 000332185
            Error inserting user 000332186
            Error inserting user 000332187
            Error inserting user 000332188
            Error inserting user 000332190
            Error inserting user 000332191
            Error inserting user 000332192
            Error inserting user 000332196
            Error inserting user 000332197
            Error inserting user 000332202
            Error inserting user 000332204
            Error inserting user 000332205
            Error inserting user 000332206
            Error inserting user 82377490
            Error inserting user 88907019
            Error inserting user 95722880
            Inserted user 000175217 id 54996
            Inserted user 000302347 id 54997
            Inserted user 000304156 id 54998
            Inserted user 000315445 id 54999
            Inserted user 000315547 id 55000
            Inserted user 000317390 id 55001
            Inserted user 000319981 id 55002
            Inserted user 000320603 id 55003
            Inserted user 000321852 id 55004
            Inserted user 000322593 id 55005
            Inserted user 000322958 id 55006
            Inserted user 000323542 id 55007
            Inserted user 000325777 id 55008
            Inserted user 000325778 id 55009
            Inserted user 000325903 id 55010
            Inserted user 000326183 id 55011
            Inserted user 000326250 id 55012
            Inserted user 000326556 id 55013
            Inserted user 000326634 id 55014
            Inserted user 000326921 id 55015
            Inserted user 000326922 id 55016
            Inserted user 000327000 id 55017
            Inserted user 000327005 id 55018
            Inserted user 000327051 id 55019
            Inserted user 000327599 id 55020
            Inserted user 000327912 id 55021
            Inserted user 000328724 id 55022
            Inserted user 000328741 id 55023
            Inserted user 000328804 id 55024
            Inserted user 000328826 id 55025
            Inserted user 000328907 id 55026
            Inserted user 000329146 id 55027
            Inserted user 000329242 id 55028
            Inserted user 000329683 id 55029
            Inserted user 000329785 id 55030
            Inserted user 000329876 id 55031
            Inserted user 000329943 id 55032
            Inserted user 000330687 id 55033
            Inserted user 000330725 id 55034
            Inserted user 000330884 id 55035
            Inserted user 000331055 id 55036
            Inserted user 000331312 id 55037
            Inserted user 000331433 id 55038
            Inserted user 000331535 id 55039
            Inserted user 000331771 id 55040
            Inserted user 000331939 id 55041
            Error inserting user 000331997
            Inserted user 000332069 id 55042
            Error inserting user 000332147
            Inserted user 000332207 id 55043
            Inserted user 000332209 id 55044
            Inserted user 000332213 id 55045
            Inserted user 000332214 id 55046
            Inserted user 000332216 id 55047
            Inserted user 000332218 id 55048
            Inserted user 000332227 id 55049
            Inserted user 000332228 id 55050
            Inserted user 000332229 id 55051
            Inserted user 000332230 id 55052
            Inserted user 000332231 id 55053
            Inserted user 000332232 id 55054
            Inserted user 000332233 id 55055
            Inserted user 000332234 id 55056
            Inserted user 000332235 id 55057
            Inserted user 000332236 id 55058
            Inserted user 000332237 id 55059
            Inserted user 000332239 id 55060
            Inserted user 000332240 id 55061
            Inserted user 000332241 id 55062
            Inserted user 000332243 id 55063
            Inserted user 000332245 id 55064
            Inserted user 000332250 id 55065
            Inserted user 000332251 id 55066
            Inserted user 000332254 id 55067
            Inserted user 000332255 id 55068
            Inserted user 000332258 id 55069
            Inserted user 000332259 id 55070
            Inserted user 000332262 id 55071
            Inserted user 82707175 id 55072
            Inserted user 95962569 id 55073
            Inserted user 96921846 id 55074

            Show
            Lawrence N added a comment - - edited I created a workaround. I will simply replace/overwrite the delimited file with new accounts every time; import them into a database and our moodle 2.2.2+ synchronize these accounts for now. Again, 2.2.2+ should behave like 1.9.14.x where it skips dupes. ==== User entries to add: 121 Error inserting user 000195400 Error inserting user 000195854 Error inserting user 000228027 Error inserting user 000321140 Error inserting user 000322136 Error inserting user 000324317 Error inserting user 000328383 Error inserting user 000332159 Error inserting user 000332161 Error inserting user 000332162 Error inserting user 000332163 Error inserting user 000332167 Error inserting user 000332171 Error inserting user 000332173 Error inserting user 000332174 Error inserting user 000332175 Error inserting user 000332176 Error inserting user 000332177 Error inserting user 000332178 Error inserting user 000332179 Error inserting user 000332180 Error inserting user 000332181 Error inserting user 000332182 Error inserting user 000332183 Error inserting user 000332185 Error inserting user 000332186 Error inserting user 000332187 Error inserting user 000332188 Error inserting user 000332190 Error inserting user 000332191 Error inserting user 000332192 Error inserting user 000332196 Error inserting user 000332197 Error inserting user 000332202 Error inserting user 000332204 Error inserting user 000332205 Error inserting user 000332206 Error inserting user 82377490 Error inserting user 88907019 Error inserting user 95722880 Inserted user 000175217 id 54996 Inserted user 000302347 id 54997 Inserted user 000304156 id 54998 Inserted user 000315445 id 54999 Inserted user 000315547 id 55000 Inserted user 000317390 id 55001 Inserted user 000319981 id 55002 Inserted user 000320603 id 55003 Inserted user 000321852 id 55004 Inserted user 000322593 id 55005 Inserted user 000322958 id 55006 Inserted user 000323542 id 55007 Inserted user 000325777 id 55008 Inserted user 000325778 id 55009 Inserted user 000325903 id 55010 Inserted user 000326183 id 55011 Inserted user 000326250 id 55012 Inserted user 000326556 id 55013 Inserted user 000326634 id 55014 Inserted user 000326921 id 55015 Inserted user 000326922 id 55016 Inserted user 000327000 id 55017 Inserted user 000327005 id 55018 Inserted user 000327051 id 55019 Inserted user 000327599 id 55020 Inserted user 000327912 id 55021 Inserted user 000328724 id 55022 Inserted user 000328741 id 55023 Inserted user 000328804 id 55024 Inserted user 000328826 id 55025 Inserted user 000328907 id 55026 Inserted user 000329146 id 55027 Inserted user 000329242 id 55028 Inserted user 000329683 id 55029 Inserted user 000329785 id 55030 Inserted user 000329876 id 55031 Inserted user 000329943 id 55032 Inserted user 000330687 id 55033 Inserted user 000330725 id 55034 Inserted user 000330884 id 55035 Inserted user 000331055 id 55036 Inserted user 000331312 id 55037 Inserted user 000331433 id 55038 Inserted user 000331535 id 55039 Inserted user 000331771 id 55040 Inserted user 000331939 id 55041 Error inserting user 000331997 Inserted user 000332069 id 55042 Error inserting user 000332147 Inserted user 000332207 id 55043 Inserted user 000332209 id 55044 Inserted user 000332213 id 55045 Inserted user 000332214 id 55046 Inserted user 000332216 id 55047 Inserted user 000332218 id 55048 Inserted user 000332227 id 55049 Inserted user 000332228 id 55050 Inserted user 000332229 id 55051 Inserted user 000332230 id 55052 Inserted user 000332231 id 55053 Inserted user 000332232 id 55054 Inserted user 000332233 id 55055 Inserted user 000332234 id 55056 Inserted user 000332235 id 55057 Inserted user 000332236 id 55058 Inserted user 000332237 id 55059 Inserted user 000332239 id 55060 Inserted user 000332240 id 55061 Inserted user 000332241 id 55062 Inserted user 000332243 id 55063 Inserted user 000332245 id 55064 Inserted user 000332250 id 55065 Inserted user 000332251 id 55066 Inserted user 000332254 id 55067 Inserted user 000332255 id 55068 Inserted user 000332258 id 55069 Inserted user 000332259 id 55070 Inserted user 000332262 id 55071 Inserted user 82707175 id 55072 Inserted user 95962569 id 55073 Inserted user 96921846 id 55074
            Hide
            Lawrence N added a comment -

            Looks like this issue is still a big bug for 2.x.

            To clarify, we use database synchronization to create new accounts in Moodle (2.2.3+ and 2.2.4+). When we execute our /our/mooodle/root/folder/auth/db/cli/sync_users.php and the script finds that an account already exist in moodle, it WOULD NOT CONTINUE/JUST STOPS and none of the accounts in the database are created.

            Unlike in 1.9.x, it would simply skip and notify users that the account already exist and continues on.

            Here again is an example:

            Database transaction aborted automatically in /var/www/html/moodle224/auth/db/cli/sync_users.php
            Default exception handler: Error writing to database Debug: Duplicate entry '4-000307235' for key 'mdl_user_mneuse_uix'
            INSERT INTO mdl_user (firstname,lastname,email,username,confirmed,auth,mnethostid,lang,timecreated,timemodified) VALUES(?,?,?,?,?,?,?,?,?,?)
            [array (
            0 => 'Natasha',
            1 => 'Portman',
            2 => 'natasha.portman@student.ourshool.net',
            3 => '523307235',
            4 => 1,
            5 => 'db',
            6 => '4',
            7 => 'en',
            8 => 1346431583,
            9 => 1346431583,
            )]

            • line 397 of /lib/dml/moodle_database.php: dml_write_exception thrown
            • line 973 of /lib/dml/mysqli_native_moodle_database.php: call to moodle_database->query_end()
            • line 1015 of /lib/dml/mysqli_native_moodle_database.php: call to mysqli_native_moodle_database->insert_record_raw()
            • line 375 of /auth/db/auth.php: call to mysqli_native_moodle_database->insert_record()
            • line 91 of /auth/db/cli/sync_users.php: call to auth_plugin_db->sync_users()

            !!! Error writing to database !!!

            Show
            Lawrence N added a comment - Looks like this issue is still a big bug for 2.x. To clarify, we use database synchronization to create new accounts in Moodle (2.2.3+ and 2.2.4+). When we execute our /our/mooodle/root/folder/auth/db/cli/sync_users.php and the script finds that an account already exist in moodle, it WOULD NOT CONTINUE/JUST STOPS and none of the accounts in the database are created. Unlike in 1.9.x, it would simply skip and notify users that the account already exist and continues on. Here again is an example: Database transaction aborted automatically in /var/www/html/moodle224/auth/db/cli/sync_users.php Default exception handler: Error writing to database Debug: Duplicate entry '4-000307235' for key 'mdl_user_mneuse_uix' INSERT INTO mdl_user (firstname,lastname,email,username,confirmed,auth,mnethostid,lang,timecreated,timemodified) VALUES(?,?,?,?,?,?,?,?,?,?) [array ( 0 => 'Natasha', 1 => 'Portman', 2 => 'natasha.portman@student.ourshool.net', 3 => '523307235', 4 => 1, 5 => 'db', 6 => '4', 7 => 'en', 8 => 1346431583, 9 => 1346431583, )] line 397 of /lib/dml/moodle_database.php: dml_write_exception thrown line 973 of /lib/dml/mysqli_native_moodle_database.php: call to moodle_database->query_end() line 1015 of /lib/dml/mysqli_native_moodle_database.php: call to mysqli_native_moodle_database->insert_record_raw() line 375 of /auth/db/auth.php: call to mysqli_native_moodle_database->insert_record() line 91 of /auth/db/cli/sync_users.php: call to auth_plugin_db->sync_users() !!! Error writing to database !!!
            Hide
            Lawrence N added a comment -

            This always fails when the user logs in to moodle first and then when this script runs, it always fails and won't add the others.

            serious bug I would think... the external database sync users does not work has a "bug"

            Show
            Lawrence N added a comment - This always fails when the user logs in to moodle first and then when this script runs, it always fails and won't add the others. serious bug I would think... the external database sync users does not work has a "bug"
            Hide
            Lawrence N added a comment -

            Is there any new update? This is a serious bug I think... no other accounts created if it does not skip the duplicate user account already in moodle. It just stops.

            Works great in 1.9.x but not in 2.2.x... not sure about 2.3.x but could be the same buggy behaviour too.

            Show
            Lawrence N added a comment - Is there any new update? This is a serious bug I think... no other accounts created if it does not skip the duplicate user account already in moodle. It just stops. Works great in 1.9.x but not in 2.2.x... not sure about 2.3.x but could be the same buggy behaviour too.
            Hide
            Petr Skoda added a comment -

            Did you try the latest version? In any case please make sure your external database does not contain duplicate records, Moodle can try to work out some problems but if your external database contains invalid data the results are not guaranteed. For example if you have duplicate usernames in external table Moodle may decide to use different record each time the sync is executed. The easies way to prevent duplicates is to define unique indexes in the external table.

            Show
            Petr Skoda added a comment - Did you try the latest version? In any case please make sure your external database does not contain duplicate records, Moodle can try to work out some problems but if your external database contains invalid data the results are not guaranteed. For example if you have duplicate usernames in external table Moodle may decide to use different record each time the sync is executed. The easies way to prevent duplicates is to define unique indexes in the external table.
            Hide
            Lawrence N added a comment -

            Hi again Petr,

            There are no duplicates in our external database because we always start with new accounts and no dupes. It's on the moodle side that is breaking it.

            As I mentioned in my report, 1.9.14+ does not have this problem. It just proceeds on and skips the account if it finds a match in the external database and in moodle and moves to the next record in the the external database.

            In 2.2.4+, if it finds an account in the external database and in moodle, it would break and NOT ADD ANY of the records in the external database, even though they are not in moodle.

            Thanks

            Show
            Lawrence N added a comment - Hi again Petr, There are no duplicates in our external database because we always start with new accounts and no dupes. It's on the moodle side that is breaking it. As I mentioned in my report, 1.9.14+ does not have this problem. It just proceeds on and skips the account if it finds a match in the external database and in moodle and moves to the next record in the the external database. In 2.2.4+, if it finds an account in the external database and in moodle, it would break and NOT ADD ANY of the records in the external database, even though they are not in moodle. Thanks
            Hide
            Petr Skoda added a comment - - edited

            It worked fine for me the last time I tested it, are you sure all usernames are lowercase in your external database?

            In any case I am going to add unit tests soon both for auth_db adn enrol_database, that should hopefully uncover all problems and prevent regressions in the future.

            Show
            Petr Skoda added a comment - - edited It worked fine for me the last time I tested it, are you sure all usernames are lowercase in your external database? In any case I am going to add unit tests soon both for auth_db adn enrol_database, that should hopefully uncover all problems and prevent regressions in the future.
            Hide
            Lawrence N added a comment -

            Hi Petr,

            the user accounts created are for our students only and are numeric (i.e 123456789)

            It works for the most part but sometimes an eager student will log in to moodle first, thus creating the account in moodle before we actually run a sync to add these new users. That is when this fails

            Show
            Lawrence N added a comment - Hi Petr, the user accounts created are for our students only and are numeric (i.e 123456789) It works for the most part but sometimes an eager student will log in to moodle first, thus creating the account in moodle before we actually run a sync to add these new users. That is when this fails
            Hide
            Petr Skoda added a comment -

            Oh, that explains it! There is a missing test for existing accounts of different auth type. I always expected admins disable manual signup or use a locked idnumber that can not be changed by user because otherwise the enrol_database plugin can not trust the user mapping. Users must not be able to modify the sync field value for user authentication and enrolments!

            Imagine user 123 creates an account with username 456, the auth_db silently skips the user creation and enrol_database enrols user into 10 courses which are intended for username 456...

            I am going to add a big warning if account with the same identification already exists in different auth plugin because it most probably means seriously site misconfigure or invalid external database data.

            Thanks for the report and explanation!

            Show
            Petr Skoda added a comment - Oh, that explains it! There is a missing test for existing accounts of different auth type. I always expected admins disable manual signup or use a locked idnumber that can not be changed by user because otherwise the enrol_database plugin can not trust the user mapping. Users must not be able to modify the sync field value for user authentication and enrolments! Imagine user 123 creates an account with username 456, the auth_db silently skips the user creation and enrol_database enrols user into 10 courses which are intended for username 456... I am going to add a big warning if account with the same identification already exists in different auth plugin because it most probably means seriously site misconfigure or invalid external database data. Thanks for the report and explanation!
            Hide
            Petr Skoda added a comment -

            Hmm, I think I found a different problem in the auth_db - user_login() does not limit the lookup to own users only, I am not sure that affects anything, but that definitely is not correct.

            Show
            Petr Skoda added a comment - Hmm, I think I found a different problem in the auth_db - user_login() does not limit the lookup to own users only, I am not sure that affects anything, but that definitely is not correct.
            Hide
            Petr Skoda added a comment -

            To fix your site please edit the auth type of those manually crated accounts to 'db' and it should sync without problems.

            Eh, I just found out that I fixed this issue already in MDL-13363, but the fix is not completely correct. I am going to backport it to stable branches and add better explanation and docs.

            Show
            Petr Skoda added a comment - To fix your site please edit the auth type of those manually crated accounts to 'db' and it should sync without problems. Eh, I just found out that I fixed this issue already in MDL-13363 , but the fix is not completely correct. I am going to backport it to stable branches and add better explanation and docs.
            Hide
            Petr Skoda added a comment -

            Thanks for the report!

            Show
            Petr Skoda added a comment - Thanks for the report!
            Hide
            Lawrence N added a comment -

            I'm surprised no one has encountered this yet

            While you're at it, I'm a big fan of verbose output so we could see what it's actually doing. Could you code that in also?

            To recap, I would like to see the revised script to do the following 2 things and show the result of it's process:

            1. Accounts WILL BE CREATED in moodle from the external database if the ACCOUNT DOES NOT ALREADY EXIST in our moodle mdl_user table and a verbose line output mentioning that it was added successfully.

            2. Accounts WILL NOT BE CREATED in moodle from the external database if the ACCOUNT ALREADY EXIST in our moodle mdl_user table and a verbose line output mentioning that it WAS NOT ADDED BECAUSE IT ALREADY EXIST IN MOODLE and moves on to the next record in the external database to process.

            After the script finishes, I then write a MySQL procedure to simply update all accounts whose auth type is db and change it our default auth type of "ldap". This works now regardless of Moodle version as we're currently using it with success.

            Does this make sense?

            Thanks

            Show
            Lawrence N added a comment - I'm surprised no one has encountered this yet While you're at it, I'm a big fan of verbose output so we could see what it's actually doing. Could you code that in also? To recap, I would like to see the revised script to do the following 2 things and show the result of it's process: 1. Accounts WILL BE CREATED in moodle from the external database if the ACCOUNT DOES NOT ALREADY EXIST in our moodle mdl_user table and a verbose line output mentioning that it was added successfully. 2. Accounts WILL NOT BE CREATED in moodle from the external database if the ACCOUNT ALREADY EXIST in our moodle mdl_user table and a verbose line output mentioning that it WAS NOT ADDED BECAUSE IT ALREADY EXIST IN MOODLE and moves on to the next record in the external database to process. After the script finishes, I then write a MySQL procedure to simply update all accounts whose auth type is db and change it our default auth type of "ldap". This works now regardless of Moodle version as we're currently using it with success. Does this make sense? Thanks
            Hide
            Petr Skoda added a comment -

            1. it was already listing users created in the sync
            2. my patch adds listing of failed users in 2.3 and in 2.4dev it tells you if there are username duplicates

            Show
            Petr Skoda added a comment - 1. it was already listing users created in the sync 2. my patch adds listing of failed users in 2.3 and in 2.4dev it tells you if there are username duplicates
            Hide
            Eloy Lafuente (stronk7) added a comment -
            • Why is the 23_STABLE branch missing the "collision" query and also the final user context instance() ? Will it fail in the insert instead an done? (less debugging info)
            • Why isn't this backported to 22_STABLE ? At least the transactions thing to avoid full rollback.

            Ciao

            Show
            Eloy Lafuente (stronk7) added a comment - Why is the 23_STABLE branch missing the "collision" query and also the final user context instance() ? Will it fail in the insert instead an done? (less debugging info) Why isn't this backported to 22_STABLE ? At least the transactions thing to avoid full rollback. Ciao
            Hide
            Petr Skoda added a comment -
            • the collision detection is a new feature in master, in 2.3 it just fails in the standard insert
            • feel free to cherry pick to 2.2, in my opinion the failed insert is highly unlikely if you do not mix multiple auths or do not have borked utf-8 in your external database
            Show
            Petr Skoda added a comment - the collision detection is a new feature in master, in 2.3 it just fails in the standard insert feel free to cherry pick to 2.2, in my opinion the failed insert is highly unlikely if you do not mix multiple auths or do not have borked utf-8 in your external database
            Hide
            Eloy Lafuente (stronk7) added a comment -

            Integrated (22, 23 & master), thanks!

            Show
            Eloy Lafuente (stronk7) added a comment - Integrated (22, 23 & master), thanks!
            Hide
            Ankit Agarwal added a comment -

            Works as expected
            Thanks

            Show
            Ankit Agarwal added a comment - Works as expected Thanks
            Hide
            Lawrence N added a comment -

            Yes. I agree.. I tested it myself also and ran it multiple times and it worked as expected.. and the verbose is great

            Thanks again

            Show
            Lawrence N added a comment - Yes. I agree.. I tested it myself also and ran it multiple times and it worked as expected.. and the verbose is great Thanks again
            Hide
            Dan Poltawski added a comment -

            Congratulations, you've done it!

            Thanks, this change is now in the latest weekly release!

            Join the crowds of people tomorrow from 8am and download this Moodle release from your local apple store!

            Show
            Dan Poltawski added a comment - Congratulations, you've done it! Thanks, this change is now in the latest weekly release! Join the crowds of people tomorrow from 8am and download this Moodle release from your local apple store!

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: