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

Bulk user upload force password change when auth=POP3

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.9.7
    • Fix Version/s: 2.0
    • Component/s: Administration
    • Labels:
      None
    • Database:
      MySQL
    • Difficulty:
      Moderate
    • Affected Branches:
      MOODLE_19_STABLE
    • Fixed Branches:
      MOODLE_20_STABLE

      Description

      When bulk uploading users with auth=POP3, Moodle forces password change for those users. Since password are managed by an external system, users are no longer able to login once the password has been updated. That creates a major workload fro Admins who need to upload users in bulk.

      To reproduce:

      • use a password salted site, with Password Policy=on
      • create a CVS user import file, with a password column and authtype POP3
      • import the users
      • check the forcepassword field in the profile or in the db user table, the field is set to on.

        Gliffy Diagrams

        1. 20100310_MDL-21559_HEAD.patch
          5 kB
          Rossiani Wijaya
        2. 20100311_MDL-21559_HEAD_add_edit.patch
          10 kB
          Rossiani Wijaya
        3. 20100311_MDL-21559_HEAD_add.patch
          6 kB
          Rossiani Wijaya
        4. 20100312_MDL-21559_HEAD_add_edit.patch
          11 kB
          Rossiani Wijaya
        5. 20101007_MDL-21559_2.0.patch
          16 kB
          Rossiani Wijaya
        6. 20101101_MDL-21559_2.0.patch
          16 kB
          Rossiani Wijaya
        7. 20101105_MDL-21559_2.0.patch
          16 kB
          Rossiani Wijaya
        1. force.jpg
          17 kB

          Activity

          Hide
          andreabix Andrea Bicciolo added a comment -

          Assigning to Eloy for triaging

          Show
          andreabix Andrea Bicciolo added a comment - Assigning to Eloy for triaging
          Hide
          andreabix Andrea Bicciolo added a comment -

          Drilling down while trying to spot the problem, it looks like the issue is generate the password policy set t on.

          Password policy should not influence external authenticated users, but it does. Should it ?

          Show
          andreabix Andrea Bicciolo added a comment - Drilling down while trying to spot the problem, it looks like the issue is generate the password policy set t on. Password policy should not influence external authenticated users, but it does. Should it ?
          Hide
          stronk7 Eloy Lafuente (stronk7) added a comment -

          Hi Andrea... and what are you sending as passwords in the CSV file? (the passwords themselves, empty string, some arbitrary string?).

          Apart of the main question above, just to have this noted:

          I've been reviewing the upload script and I think it really needs some love, as far as some things aren't properly supported, like:

          • Any record containing passwords for one external authentication method should be discarded (you case).
          • For records inserted, the password field must match current agreement (store it with "external" value, if I'm not wrong).
          • ....

          Ciao

          Show
          stronk7 Eloy Lafuente (stronk7) added a comment - Hi Andrea... and what are you sending as passwords in the CSV file? (the passwords themselves, empty string, some arbitrary string?). Apart of the main question above, just to have this noted: I've been reviewing the upload script and I think it really needs some love, as far as some things aren't properly supported, like: Any record containing passwords for one external authentication method should be discarded (you case). For records inserted, the password field must match current agreement (store it with "external" value, if I'm not wrong). .... Ciao
          Hide
          andreabix Andrea Bicciolo added a comment -

          Thanks Eloy.

          In the CSV file passwords are uploaded according to password policy. Looks like something related to the password policy flag.

          Show
          andreabix Andrea Bicciolo added a comment - Thanks Eloy. In the CSV file passwords are uploaded according to password policy. Looks like something related to the password policy flag.
          Hide
          stronk7 Eloy Lafuente (stronk7) added a comment -

          But... if the auth for those users is POP3... which is the point about to send (and store) those passwords in Moodle's DB ?

          In fact, as commented above, they should be discarded IMO.

          In any case, have you tried sending all the passwords empty? Quick reading code... it seems to be the solution for avoiding password change (not tested).

          Ciao

          Show
          stronk7 Eloy Lafuente (stronk7) added a comment - But... if the auth for those users is POP3... which is the point about to send (and store) those passwords in Moodle's DB ? In fact, as commented above, they should be discarded IMO. In any case, have you tried sending all the passwords empty? Quick reading code... it seems to be the solution for avoiding password change (not tested). Ciao
          Hide
          andreabix Andrea Bicciolo added a comment -

          If I correctly recall, there are two options when uploading: password present in CSV file OR create a passowrd if necessary.

          The second option create random passwords, send it to users and force them to change it.

          Show
          andreabix Andrea Bicciolo added a comment - If I correctly recall, there are two options when uploading: password present in CSV file OR create a passowrd if necessary. The second option create random passwords, send it to users and force them to change it.
          Hide
          stronk7 Eloy Lafuente (stronk7) added a comment - - edited

          Buff, then, for sure, the upload scripts needs to be reviewed when uploading users using "external" authentication methods, as far as right now it isn't performing any different processing of passwords at all. And they must, definitively, be processed differently.

          IMO, it should be:

          • internal authentication: current behavior:
            • non-empty passwords are loaded and validated (forcing change if doesn't fulfill politics)
            • empty passwords force change
          • external authentication:
            • passwords must be always empty.
            • non empty passwords will be handled as error and the process will stop before performing any action (complete file rejected).
            • empty passwords (the correct ones) won't trigger any change of password.
            • passwords in DB for those created users will contain "not cached"

          Note, for storing passwords, in any case we should be using, always, the update_internal_user_password($user, $password) function as far as it controls the hashing and the storage (real/not cached).

          Note2, at all effects, "external authentication" means $plugin->prevent_local_passwords() == true and "internal authentication" the opposite.

          Sounds ok?

          Show
          stronk7 Eloy Lafuente (stronk7) added a comment - - edited Buff, then, for sure, the upload scripts needs to be reviewed when uploading users using "external" authentication methods, as far as right now it isn't performing any different processing of passwords at all. And they must , definitively, be processed differently. IMO, it should be: internal authentication: current behavior: non-empty passwords are loaded and validated (forcing change if doesn't fulfill politics) empty passwords force change external authentication: passwords must be always empty. non empty passwords will be handled as error and the process will stop before performing any action (complete file rejected). empty passwords (the correct ones) won't trigger any change of password. passwords in DB for those created users will contain "not cached" Note, for storing passwords, in any case we should be using, always, the update_internal_user_password($user, $password) function as far as it controls the hashing and the storage (real/not cached). Note2, at all effects, "external authentication" means $plugin->prevent_local_passwords() == true and "internal authentication" the opposite. Sounds ok?
          Hide
          andreabix Andrea Bicciolo added a comment -

          Eloy, to me it sounds ok. Thanks!

          Show
          andreabix Andrea Bicciolo added a comment - Eloy, to me it sounds ok. Thanks!
          Hide
          stronk7 Eloy Lafuente (stronk7) added a comment -

          Assigning to Rosie, I think the objective is to fulfill the points in my previous comment.

          Adding Petr as watcher as far as he knows a lot about auth plugins and current impl.

          Ciao

          Show
          stronk7 Eloy Lafuente (stronk7) added a comment - Assigning to Rosie, I think the objective is to fulfill the points in my previous comment. Adding Petr as watcher as far as he knows a lot about auth plugins and current impl. Ciao
          Hide
          wenxin Wenxin Lu added a comment -

          I'd this problem for years. It is a big burden of my workload. After I created hundreds of students with CSV file, I have to de-select the 'Force' check button ONE-BY-ONE!
          Since I choose the "LDAP server' from the dropdown menu, the 'Force' should be ignored.
          Or, I should be able to use SQL line to change the database. But, I cannot find which table the 'force' is in.
          This problem is easy to be reproduced, please try with this file and check my screenshot.
          username,password,firstname,lastname,email,maildisplay,description,course1,type1
          gtg6853,nomatterwhat,yoane,Pele,yoapel@yahoo.co.nz,1,Visual Arts,RCMVisual,1

          PLEASE fix this problem to save my life!
          Cheers

          Show
          wenxin Wenxin Lu added a comment - I'd this problem for years. It is a big burden of my workload. After I created hundreds of students with CSV file, I have to de-select the 'Force' check button ONE-BY-ONE! Since I choose the "LDAP server' from the dropdown menu, the 'Force' should be ignored. Or, I should be able to use SQL line to change the database. But, I cannot find which table the 'force' is in. This problem is easy to be reproduced, please try with this file and check my screenshot. username,password,firstname,lastname,email,maildisplay,description,course1,type1 gtg6853,nomatterwhat,yoane,Pele,yoapel@yahoo.co.nz,1,Visual Arts,RCMVisual,1 PLEASE fix this problem to save my life! Cheers
          Hide
          wenxin Wenxin Lu added a comment -

          Force button always ON, even choose LDAP server or anything

          Show
          wenxin Wenxin Lu added a comment - Force button always ON, even choose LDAP server or anything
          Hide
          wenxin Wenxin Lu added a comment -

          I fixed it by SQL:
          SELECT * FROM mdl_user_preferences WHERE name='auth_forcepasswordchange' and value='1'

          Show
          wenxin Wenxin Lu added a comment - I fixed it by SQL: SELECT * FROM mdl_user_preferences WHERE name='auth_forcepasswordchange' and value='1'
          Hide
          rwijaya Rossiani Wijaya added a comment -

          Hi Eloy,

          The login system will not process user login when the password field is empty. Therefore, with internal authentication, empty password will create an issue for user to login.

          Should we create a function in moodlelib.php to initialize empty password for internal authentication?

          function initialize_password () {
          return 'changeme';
          }

          $user->password = initialize_password();

          Or assign empty $user->password to language string?
          $user->password = get_string('changeme');

          Or do you have any other solution?

          Thanks
          Rosie

          Show
          rwijaya Rossiani Wijaya added a comment - Hi Eloy, The login system will not process user login when the password field is empty. Therefore, with internal authentication, empty password will create an issue for user to login. Should we create a function in moodlelib.php to initialize empty password for internal authentication? function initialize_password () { return 'changeme'; } $user->password = initialize_password(); Or assign empty $user->password to language string? $user->password = get_string('changeme'); Or do you have any other solution? Thanks Rosie
          Hide
          stronk7 Eloy Lafuente (stronk7) added a comment -

          Hi Rosie,

          I think the main problem is that, when uploading users we are, practically, ignoring the "auth" field (i.e. the authentication type of the user), so all the uploaded users end with the password set and the "force password change" enabled. And it only should happen for internal users! (I mean, users authenticating from pop/ldap... doesn't have to be forced to change password, nor their password must be stored in Moodle user table at all!

          So I think we should introduce these modifications:

          1. For each user in file, get the results of this function:

            $prevent = $auth->prevent_local_passwords();

          2. Based on $prevent, do this:
            1. If $prevent = true (the authentication is external and moodle doesn't store passwords at all), do this:
              • Check the password in CSV file is empty, causing error & rejecting the file if not empty.
              • Never mark as "force password change" this users.
              • Set user password to 'not cached' before inserting it.
            2. If prevent = false (the authentication is internal and moodle does store passwords and handle them, do this:
              • Current process (check policy, force password change, hash it... blah, blah...) Nothing changes.

          So, basically, what we need is to handle better those situations where passwords are stored externally by achieving the points above. Note the password won't be empty in db in any case. It will be 'not cached' for external auths and the hash one for internal ones.

          Ciao

          Show
          stronk7 Eloy Lafuente (stronk7) added a comment - Hi Rosie, I think the main problem is that, when uploading users we are, practically, ignoring the "auth" field (i.e. the authentication type of the user), so all the uploaded users end with the password set and the "force password change" enabled. And it only should happen for internal users! (I mean, users authenticating from pop/ldap... doesn't have to be forced to change password, nor their password must be stored in Moodle user table at all! So I think we should introduce these modifications: For each user in file, get the results of this function: $prevent = $auth->prevent_local_passwords(); Based on $prevent, do this: If $prevent = true (the authentication is external and moodle doesn't store passwords at all), do this: Check the password in CSV file is empty, causing error & rejecting the file if not empty. Never mark as "force password change" this users. Set user password to 'not cached' before inserting it. If prevent = false (the authentication is internal and moodle does store passwords and handle them, do this: Current process (check policy, force password change, hash it... blah, blah...) Nothing changes. So, basically, what we need is to handle better those situations where passwords are stored externally by achieving the points above. Note the password won't be empty in db in any case. It will be 'not cached' for external auths and the hash one for internal ones. Ciao
          Hide
          andreabix Andrea Bicciolo added a comment -

          My +1 for Eloy approach. Hope the issue will be addressed soon, at the present time in a multi-auth enabled system the only workaround is disable password policy, which affect any type of authentication, including manual and email auths that are the most impacted by weak passwords

          Show
          andreabix Andrea Bicciolo added a comment - My +1 for Eloy approach. Hope the issue will be addressed soon, at the present time in a multi-auth enabled system the only workaround is disable password policy, which affect any type of authentication, including manual and email auths that are the most impacted by weak passwords
          Hide
          rwijaya Rossiani Wijaya added a comment -

          Hi Eloy,

          I understand how the authentication process should be done. However, I'm still not sure with your suggestion for internal authentication if password is set to empty.

          internal authentication: current behavior:

          • empty passwords force change

          I meant i can set the DB for empty string in hash. Then first time login user will be able to login and immediately directed to change password page. This is where i have question. on this page, current password is not allow to have empty field. without current password, user won't be able to change their password.

          in other words:

          • upload new user with auth field is set to empty (or manual) and password is set to empty
          • store to database where password will have the value of d41d8cd98f00b204e9800998ecf8427e (hash value for empty string) and mark force password change to true.
          • user login with username and empty password
          • user successfully login to the system and directed to password change
          • leave current password to empty and set new password and new passwords fields with new password. error will occurs, because current password field can't be set to empty.

          I created a patch which currently will check the value of the password field. if auth field is set to empty (or manual) it will produce and error and rejecting the file. however, if auth field is set to pop3/ldap... and password field is empty, it will not produce an error and will accept the file.

          Please take a look the patch and let me know if it is in the correct direction.

          I'm also in the process of fixing the update process for this section.

          Show
          rwijaya Rossiani Wijaya added a comment - Hi Eloy, I understand how the authentication process should be done. However, I'm still not sure with your suggestion for internal authentication if password is set to empty. internal authentication: current behavior: empty passwords force change I meant i can set the DB for empty string in hash. Then first time login user will be able to login and immediately directed to change password page. This is where i have question. on this page, current password is not allow to have empty field. without current password, user won't be able to change their password. in other words: upload new user with auth field is set to empty (or manual) and password is set to empty store to database where password will have the value of d41d8cd98f00b204e9800998ecf8427e (hash value for empty string) and mark force password change to true. user login with username and empty password user successfully login to the system and directed to password change leave current password to empty and set new password and new passwords fields with new password. error will occurs, because current password field can't be set to empty. I created a patch which currently will check the value of the password field. if auth field is set to empty (or manual) it will produce and error and rejecting the file. however, if auth field is set to pop3/ldap... and password field is empty, it will not produce an error and will accept the file. Please take a look the patch and let me know if it is in the correct direction. I'm also in the process of fixing the update process for this section.
          Hide
          rwijaya Rossiani Wijaya added a comment -

          Created patch to add new user (only).

          Eloy,

          when the file is error free, I made slight changes for 'new user password' selection option process.
          if user select 'field required in file' option,

          with internal auth:

          • if password is empty, file row won't be added to DB

          with external auth:

          • if password is empty, it will add the row to DB and store the password as 'not cached'.

          is it ok to do that?

          also, with updating process: with error free file, there is a select option for "existing user password". If 'no changes' is selected,

          what should happen if auth is change from pop3 to manual or vice versa? in this case, we can't leave the password as it is. i am in process of forcing to update the password column if auth is changing and removing/adding rows in user_preference table for force password change and create password.

          Please advise.

          Thanks

          Show
          rwijaya Rossiani Wijaya added a comment - Created patch to add new user (only). Eloy, when the file is error free, I made slight changes for 'new user password' selection option process. if user select 'field required in file' option, with internal auth: if password is empty, file row won't be added to DB with external auth: if password is empty, it will add the row to DB and store the password as 'not cached'. is it ok to do that? also, with updating process: with error free file, there is a select option for "existing user password". If 'no changes' is selected, what should happen if auth is change from pop3 to manual or vice versa? in this case, we can't leave the password as it is. i am in process of forcing to update the password column if auth is changing and removing/adding rows in user_preference table for force password change and create password. Please advise. Thanks
          Hide
          rwijaya Rossiani Wijaya added a comment -

          Just created another patch to fix the add and update process for upload. I will do more testing with the patch tomorrow.

          In the mean while, please feel free to apply the patch and give some feedback.

          Show
          rwijaya Rossiani Wijaya added a comment - Just created another patch to fix the add and update process for upload. I will do more testing with the patch tomorrow. In the mean while, please feel free to apply the patch and give some feedback.
          Hide
          stronk7 Eloy Lafuente (stronk7) added a comment - - edited

          Hi Rosie,

          so, when creating new users (add) is this always true:

          1) External auth users:

          • always (no matter of the 'field required in file' and 'create password if needed',) store the password as 'not cached'.
          • never store any preference to them (about password change or create new one).

          2) Internal auth users:

          • If 'field required in file' is set, reject users with missing/incorrect password.
          • If 'create password if needed' is set and password is empty/incorrect, define the 2 preferences, so new password will be created (by cron) and force password will be set.

          Yes? The FOUR points are correct?

          Then, one question:

          Q1: With your patch... users not fulfilling the password policy...what happens with them?

          And, then, about updating users:

          A) if auth changes from internal to external, do the same than 1) above:

          • always set password to 'not cached'
          • never set any preference.

          B) if auth changes from external to internal, the 'no changes' option hasn't sense (so 'update' will be always executed, and you'll need to do exactly the same than in 2) above:

          • If 'field required in file' is set, reject users with missing/incorrect password.
          • If 'create password if needed' is set and password is empty/incorrect, define the 2 preferences, so new password will be created (by cron) and force password will be set.

          C) if auth changes from internal to internal, then 'no changes' has sense and any process related with passwords will be ignored. If 'update' is defined, then we'll perform exactly like in B).

          In any case... as far as logic is becoming more and more complex... what if:

          1) We do one change to handle "add" 100% ok.
          2) After that we review the "update" case (here or in another bug).

          I say that because I guess 99% people uses that exclusively to "add" new users and it seems that right now we have it under control (if the 1) and 2) above are ok).

          Ciao

          Edited: Blame tracker's wiki. Reformatting a bit for better readability

          Show
          stronk7 Eloy Lafuente (stronk7) added a comment - - edited Hi Rosie, so, when creating new users (add) is this always true: 1) External auth users: always (no matter of the 'field required in file' and 'create password if needed',) store the password as 'not cached'. never store any preference to them (about password change or create new one). 2) Internal auth users: If 'field required in file' is set, reject users with missing/incorrect password. If 'create password if needed' is set and password is empty/incorrect, define the 2 preferences, so new password will be created (by cron) and force password will be set. Yes? The FOUR points are correct? Then, one question: Q1: With your patch... users not fulfilling the password policy...what happens with them? And, then, about updating users: A) if auth changes from internal to external, do the same than 1) above: always set password to 'not cached' never set any preference. B) if auth changes from external to internal, the 'no changes' option hasn't sense (so 'update' will be always executed, and you'll need to do exactly the same than in 2) above: If 'field required in file' is set, reject users with missing/incorrect password. If 'create password if needed' is set and password is empty/incorrect, define the 2 preferences, so new password will be created (by cron) and force password will be set. C) if auth changes from internal to internal, then 'no changes' has sense and any process related with passwords will be ignored. If 'update' is defined, then we'll perform exactly like in B). In any case... as far as logic is becoming more and more complex... what if: 1) We do one change to handle "add" 100% ok. 2) After that we review the "update" case (here or in another bug). I say that because I guess 99% people uses that exclusively to "add" new users and it seems that right now we have it under control (if the 1) and 2) above are ok). Ciao Edited: Blame tracker's wiki. Reformatting a bit for better readability
          Hide
          rwijaya Rossiani Wijaya added a comment -

          Hi Eloy,

          Thanks for the comments.

          <code>
          1) External auth users:

          always (no matter of the 'field required in file' and 'create password if needed',) store the password as 'not cached'.
          never store any preference to them (about password change or create new one).
          2) Internal auth users:
          If 'field required in file' is set, reject users with missing/incorrect password.
          If 'create password if needed' is set and password is empty/incorrect, define the 2 preferences, so new password will be created (by cron) and force password will be set.
          Yes? The FOUR points are correct?
          </code>

          Yes the above points are correct. (20100311_MDL-21559_HEAD_add.patch)

          <code>
          Q1: With your patch... users not fulfilling the password policy...what happens with them?
          </code>
          as for right now, password policy is not checked for internal password. The password is hashed and stored to db. it will also create password_change in preference table.

          my question with internal: if password is not empty, should it be checked with password policy and if its fail, the file should be rejected?

          updating user:
          The last patch is working towards your suggestion. I still need to perform some testing and make sure it works correctly.

          +1 for creating another tracker to fix update.

          Show
          rwijaya Rossiani Wijaya added a comment - Hi Eloy, Thanks for the comments. <code> 1) External auth users: always (no matter of the 'field required in file' and 'create password if needed',) store the password as 'not cached'. never store any preference to them (about password change or create new one). 2) Internal auth users: If 'field required in file' is set, reject users with missing/incorrect password. If 'create password if needed' is set and password is empty/incorrect, define the 2 preferences, so new password will be created (by cron) and force password will be set. Yes? The FOUR points are correct? </code> Yes the above points are correct. (20100311_ MDL-21559 _HEAD_add.patch) <code> Q1: With your patch... users not fulfilling the password policy...what happens with them? </code> as for right now, password policy is not checked for internal password. The password is hashed and stored to db. it will also create password_change in preference table. my question with internal: if password is not empty, should it be checked with password policy and if its fail, the file should be rejected? updating user: The last patch is working towards your suggestion. I still need to perform some testing and make sure it works correctly. +1 for creating another tracker to fix update.
          Hide
          rwijaya Rossiani Wijaya added a comment -

          updated the latest patch to fulfill the above conditions (add and edit).

          Eloy, I'm still not clear with password policy, I removed password policy because internal user will always be force to change their password. Should password policy be use to validate the file password field? and if its not valid, reject the file?

          Please take a look and leave some feedback.

          Thanks

          Show
          rwijaya Rossiani Wijaya added a comment - updated the latest patch to fulfill the above conditions (add and edit). Eloy, I'm still not clear with password policy, I removed password policy because internal user will always be force to change their password. Should password policy be use to validate the file password field? and if its not valid, reject the file? Please take a look and leave some feedback. Thanks
          Hide
          markpearson Mark Pearson added a comment -

          I applied patch 0100312_MDL-21559_HEAD_add_edit.patch to a 1.9.9 moodle installation with mixed results:
          File to patch: admin/uploaduser.php
          Patching file admin/uploaduser.php using Plan A...
          Hunk #1 succeeded at 154 with fuzz 1 (offset -10 lines).
          Hunk #2 failed at 201.
          Hunk #3 succeeded at 427 with fuzz 1 (offset -7 lines).
          Hunk #4 succeeded at 455 (offset -10 lines).
          Hunk #5 succeeded at 495 with fuzz 1 (offset -7 lines).
          Hunk #6 succeeded at 527 with fuzz 2 (offset -11 lines).
          Hunk #7 succeeded at 571 (offset -7 lines).
          Hunk #8 failed at 820.
          2 out of 8 hunks failed--saving rejects to admin/uploaduser.php.rej

          Looking at uploaduser.php.rej the following lines are marked:

              • 201,223 ****
              • 201,212 ----
              • 779,784 ****
              • 820,838 ----

          File uploaduserform.php patched successfully

          Then:
          File to patch: lang/en_utf8/moodle.php
          Patching file lang/en_utf8/moodle.php using Plan A...
          Hunk #1 succeeded at 1829 with fuzz 2 (offset -1 lines).
          patch: **** misordered hunks! output would be garbled

          Can probe this some more to find out what's going on.
          Mark

          Show
          markpearson Mark Pearson added a comment - I applied patch 0100312_ MDL-21559 _HEAD_add_edit.patch to a 1.9.9 moodle installation with mixed results: File to patch: admin/uploaduser.php Patching file admin/uploaduser.php using Plan A... Hunk #1 succeeded at 154 with fuzz 1 (offset -10 lines). Hunk #2 failed at 201. Hunk #3 succeeded at 427 with fuzz 1 (offset -7 lines). Hunk #4 succeeded at 455 (offset -10 lines). Hunk #5 succeeded at 495 with fuzz 1 (offset -7 lines). Hunk #6 succeeded at 527 with fuzz 2 (offset -11 lines). Hunk #7 succeeded at 571 (offset -7 lines). Hunk #8 failed at 820. 2 out of 8 hunks failed--saving rejects to admin/uploaduser.php.rej Looking at uploaduser.php.rej the following lines are marked: 201,223 **** 201,212 ---- 779,784 **** 820,838 ---- File uploaduserform.php patched successfully Then: File to patch: lang/en_utf8/moodle.php Patching file lang/en_utf8/moodle.php using Plan A... Hunk #1 succeeded at 1829 with fuzz 2 (offset -1 lines). patch: **** misordered hunks! output would be garbled Can probe this some more to find out what's going on. Mark
          Hide
          rwijaya Rossiani Wijaya added a comment -

          Hi Mark,

          Thank you for testing the issue. The patch was created for 2.0 distribution, therefore it won't suitable for 1.9.9 version.
          Also, 2.0 distribution has been modified tremendously since March and the patch might not valid to be applied successfully.

          I'm going to take a look the issue and create a new patch for this.

          Rosie

          Show
          rwijaya Rossiani Wijaya added a comment - Hi Mark, Thank you for testing the issue. The patch was created for 2.0 distribution, therefore it won't suitable for 1.9.9 version. Also, 2.0 distribution has been modified tremendously since March and the patch might not valid to be applied successfully. I'm going to take a look the issue and create a new patch for this. Rosie
          Hide
          markpearson Mark Pearson added a comment -

          Thanks. Although the 'fix version' above says 1.9.10 so I figured it may work on 1.9.9.
          I may try backporting to 1.9.9 – right now I'm swamped with user demands (including uploading new users!)
          Cheers
          Mark

          Show
          markpearson Mark Pearson added a comment - Thanks. Although the 'fix version' above says 1.9.10 so I figured it may work on 1.9.9. I may try backporting to 1.9.9 – right now I'm swamped with user demands (including uploading new users!) Cheers Mark
          Hide
          rwijaya Rossiani Wijaya added a comment -

          Update patch for 2.0 version

          summarizing the patch functionality of user upload:

          1) External auth users:
          always store the password as 'not cached'.
          never store any preference to them (about password change or create new one).
          2) Internal auth users:
          If 'field required in file' is set, reject users with missing/incorrect password.
          If 'create password if needed' is set and password is empty/incorrect, define the 2 preferences, so new password will be created (by cron) and force password will be set.
          3)users not fulfilling the password policy will check the above internal auth users rule.

          Please take a look the patch and let me know if there's any error.

          Thanks

          Show
          rwijaya Rossiani Wijaya added a comment - Update patch for 2.0 version summarizing the patch functionality of user upload: 1) External auth users: always store the password as 'not cached'. never store any preference to them (about password change or create new one). 2) Internal auth users: If 'field required in file' is set, reject users with missing/incorrect password. If 'create password if needed' is set and password is empty/incorrect, define the 2 preferences, so new password will be created (by cron) and force password will be set. 3)users not fulfilling the password policy will check the above internal auth users rule. Please take a look the patch and let me know if there's any error. Thanks
          Hide
          rwijaya Rossiani Wijaya added a comment -

          Adding Sam watcher list.

          Show
          rwijaya Rossiani Wijaya added a comment - Adding Sam watcher list.
          Hide
          rwijaya Rossiani Wijaya added a comment -

          Update Patch.

          Sam,
          When you have a chance, could you help testing the latest patch for 2.0?

          Thanks
          Rosie

          Show
          rwijaya Rossiani Wijaya added a comment - Update Patch. Sam, When you have a chance, could you help testing the latest patch for 2.0? Thanks Rosie
          Hide
          rwijaya Rossiani Wijaya added a comment -

          Re-produce patch.

          Show
          rwijaya Rossiani Wijaya added a comment - Re-produce patch.
          Hide
          rwijaya Rossiani Wijaya added a comment -

          upgrading patch.

          Show
          rwijaya Rossiani Wijaya added a comment - upgrading patch.
          Hide
          skodak Petr Skoda added a comment -

          1/ the 'notcached' is not supposed to be translated

          +1 for commit after 1) is fixed, thanks a lot!

          Show
          skodak Petr Skoda added a comment - 1/ the 'notcached' is not supposed to be translated +1 for commit after 1) is fixed, thanks a lot!
          Hide
          rwijaya Rossiani Wijaya added a comment -

          Fixed 'nocache' string and committed to 2.0 version.

          resolved.

          Show
          rwijaya Rossiani Wijaya added a comment - Fixed 'nocache' string and committed to 2.0 version. resolved.

            People

            • Votes:
              6 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Fix Release Date:
                24/Nov/10