Uploaded image for project: '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
    • Status: Closed
    • Priority: 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

          Attachments

            Issue Links

              Activity

              Hide
              salvetore 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
              salvetore 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
              moodlevcc 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
              moodlevcc 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
              moodlevcc 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
              moodlevcc 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
              moodlevcc 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
              moodlevcc 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
              moodlevcc 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
              moodlevcc 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
              skodak 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
              skodak 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
              moodlevcc 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
              moodlevcc 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
              skodak 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
              skodak 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
              moodlevcc 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
              moodlevcc 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
              skodak 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
              skodak 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
              skodak 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
              skodak 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
              skodak 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
              skodak 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
              skodak Petr Skoda added a comment -

              Thanks for the report!

              Show
              skodak Petr Skoda added a comment - Thanks for the report!
              Hide
              moodlevcc 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
              moodlevcc 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
              skodak 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
              skodak 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
              stronk7 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
              stronk7 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
              skodak 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
              skodak 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
              stronk7 Eloy Lafuente (stronk7) added a comment -

              Integrated (22, 23 & master), thanks!

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

              Works as expected
              Thanks

              Show
              ankit_frenz Ankit Agarwal added a comment - Works as expected Thanks
              Hide
              moodlevcc 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
              moodlevcc 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
              poltawski 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
              poltawski 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:
                    Fix Release Date:
                    12/Nov/12