Moodle
  1. Moodle
  2. MDL-21559

Bulk user upload force password change when auth=POP3

    Details

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

      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.
      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
        Andrea Bicciolo added a comment -

        Assigning to Eloy for triaging

        Show
        Andrea Bicciolo added a comment - Assigning to Eloy for triaging
        Hide
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        Andrea Bicciolo added a comment -

        Eloy, to me it sounds ok. Thanks!

        Show
        Andrea Bicciolo added a comment - Eloy, to me it sounds ok. Thanks!
        Hide
        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
        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 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 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 Lu added a comment -

        Force button always ON, even choose LDAP server or anything

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

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

        Show
        Wenxin Lu added a comment - I fixed it by SQL: SELECT * FROM mdl_user_preferences WHERE name='auth_forcepasswordchange' and value='1'
        Hide
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        Rossiani Wijaya added a comment -

        Adding Sam watcher list.

        Show
        Rossiani Wijaya added a comment - Adding Sam watcher list.
        Hide
        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
        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
        Rossiani Wijaya added a comment -

        Re-produce patch.

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

        upgrading patch.

        Show
        Rossiani Wijaya added a comment - upgrading patch.
        Hide
        Petr Škoda added a comment -

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

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

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

        Fixed 'nocache' string and committed to 2.0 version.

        resolved.

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