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
    • Rank:
      39483

      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.

        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 Škoda 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 Škoda 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 Škoda 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 Škoda 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 Škoda 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 Škoda 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 Škoda 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 Škoda 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 Škoda 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 Škoda 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 Škoda added a comment -

          Thanks for the report!

          Show
          Petr Škoda 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 Škoda 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 Škoda 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 Škoda 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 Škoda 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: