When password is not set as a mandatory patron field, it should not be required. To test: - make sure BorrowerMandatoryField is empty and doesn't list password - add a new patron, leave password fields empty - try to save - you will be forced to enter a password with the field now being highlighted as required. I have also tried changing RequireStrongPassword and emptying minPasswordLength. Often libraries will leave password and username empty for patrons that won't ever use the OPAC. For example when they are not using the OPAC functionalities in general or for internal users. Making the password mandatory is a regression to former behaviour.
Created attachment 70242 [details] [review] Bug 19908: Password fields in edit/add patron form should respect BorrowerMandatoryField preference Test plan: 0) Do not apply the patch, note the password field is always required 1) Apply the patch 2) Try to add and edit patron with and without "password" in BorrowerMandatoryField, it should always respect this setting 3) Use "Change password" button in patron toolbar, the password field should be never required here - when leaved blank, the password is unchanged 4) Play with minPasswordLength and RequireStrongPassword preferences, to ensure they work as expected
On members/member-password.pl I can submit the form without confirming the password.
Created attachment 71217 [details] [review] Bug 18908: Do not use .optional in password match validation function Test plan: 0) Aplly only first patch 1) You will be able to submit a from on member-password.pl even if the passwords don't match 2) Apply this patch -> you can't be able to submit the form if the paswords don't match, but you'll be able to submit the form when password fields are blank
(In reply to Jonathan Druart from comment #2) > On members/member-password.pl I can submit the form without confirming the > password. Should be fixed by this second patch. This is restoring the original behavior, but there is still room for imporvements: It is not possible to change only userid from here. When you submit the blank passwords, then you get the same form again - not very useful I think. So probably adding the ability to change only userid from here would be nice enhancement here I think.
Hi, I got as far as applying the first patch to test. BorrowerMandatoryField is empty I was unable to save the patron record without entering a username. I get the following message: The following fields are wrong. Please fix them. - Username/password already exists. It will not let me save until I have entered a username for the patron. Previous behaviour was that one was automatically generated if left blank.
(In reply to Claire Gravely from comment #5) > Hi, > > I got as far as applying the first patch to test. > BorrowerMandatoryField is empty > > I was unable to save the patron record without entering a username. I get > the following message: > > The following fields are wrong. Please fix them. > - Username/password already exists. > > It will not let me save until I have entered a username for the patron. > Previous behaviour was that one was automatically generated if left blank. Sorry, should add this was for patron categories with type Org.
(In reply to Claire Gravely from comment #5) > Hi, > > I got as far as applying the first patch to test. > BorrowerMandatoryField is empty > > I was unable to save the patron record without entering a username. I get > the following message: > > The following fields are wrong. Please fix them. > - Username/password already exists. > > It will not let me save until I have entered a username for the patron. > Previous behaviour was that one was automatically generated if left blank. That is bug in master too and not related to this bug. Other categories have username generated as "firstname.surname" if you leave it blank, but organization not and when you have any patron with userid=null in db, koha thinks its duplicate and you can't save it. But out of scope of this bug report i think.
Created attachment 71970 [details] [review] Bug 19908: Password fields in edit/add patron form should respect BorrowerMandatoryField preference Test plan: 0) Do not apply the patch, note the password field is always required 1) Apply the patch 2) Try to add and edit patron with and without "password" in BorrowerMandatoryField, it should always respect this setting 3) Use "Change password" button in patron toolbar, the password field should be never required here - when leaved blank, the password is unchanged 4) Play with minPasswordLength and RequireStrongPassword preferences, to ensure they work as expected
Created attachment 71971 [details] [review] Bug 18908: Do not use .optional in password match validation function Test plan: 0) Aplly only first patch 1) You will be able to submit a from on member-password.pl even if the passwords don't match 2) Apply this patch -> you can't be able to submit the form if the paswords don't match, but you'll be able to submit the form when password fields are blank
rebased on master
Created attachment 72159 [details] [review] Bug 18908: Do not use .optional in password match validation function Test plan: 0) Aplly only first patch 1) You will be able to submit a from on member-password.pl even if the passwords don't match 2) Apply this patch -> you can't be able to submit the form if the paswords don't match, but you'll be able to submit the form when password fields are blank https://bugs.koha-community.org/show_bug.cgi?id=19908 Signed-off-by: Roch D'Amour <roch.damour@inlibro.com>
Created attachment 72188 [details] [review] Bug 18908: Do not use .optional in password match validation function Test plan: 0) Aplly only first patch 1) You will be able to submit a from on member-password.pl even if the passwords don't match 2) Apply this patch -> you can't be able to submit the form if the paswords don't match, but you'll be able to submit the form when password fields are blank https://bugs.koha-community.org/show_bug.cgi?id=19908 Signed-off-by: Roch D'Amour <roch.damour@inlibro.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 72189 [details] [review] Bug 19908: Password fields in edit/add patron form should respect BorrowerMandatoryField preference Test plan: 0) Do not apply the patch, note the password field is always required 1) Apply the patch 2) Try to add and edit patron with and without "password" in BorrowerMandatoryField, it should always respect this setting 3) Use "Change password" button in patron toolbar, the password field should be never required here - when leaved blank, the password is unchanged 4) Play with minPasswordLength and RequireStrongPassword preferences, to ensure they work as expected Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 72190 [details] [review] Bug 18908: Do not use .optional in password match validation function Test plan: 0) Aplly only first patch 1) You will be able to submit a from on member-password.pl even if the passwords don't match 2) Apply this patch -> you can't be able to submit the form if the paswords don't match, but you'll be able to submit the form when password fields are blank https://bugs.koha-community.org/show_bug.cgi?id=19908 Signed-off-by: Roch D'Amour <roch.damour@inlibro.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
I was about to file a new bug for the problem with organisations, but then found it: bug 13655. I think this patch is important as a bugfix for stable releases so should not be blocked by old broken behavoiur.
We should apply the same fix at the OPAC, right? Please fix bug number on the second patch.
Our Koha as of 17.11.03 does not generate default username for any patron type. Josef said 'Other categories (than org) have username generated as "firstname.surname" if you leave it blank' - but that does not seem to be the case any more. Previous behaviour also assigned a default password, and that also does not happen any more. Result is staff have to add three fields, making them unique/matching, even if the patron does not want an online account. Looking forward to this being non-mandatory! Thanks.
Created attachment 72503 [details] [review] Bug 19908: Password fields in edit/add patron form should respect BorrowerMandatoryField preference Test plan: 0) Do not apply the patch, note the password field is always required 1) Apply the patch 2) Try to add and edit patron with and without "password" in BorrowerMandatoryField, it should always respect this setting 3) Use "Change password" button in patron toolbar, the password field should be never required here - when leaved blank, the password is unchanged 4) Play with minPasswordLength and RequireStrongPassword preferences, to ensure they work as expected Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 72504 [details] [review] Bug 19908: Do not use .optional in password match validation function Test plan: 0) Aplly only first patch 1) You will be able to submit a from on member-password.pl even if the passwords don't match 2) Apply this patch -> you can't be able to submit the form if the paswords don't match, but you'll be able to submit the form when password fields are blank Signed-off-by: Roch D'Amour <roch.damour@inlibro.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
(In reply to Jonathan Druart from comment #16) > We should apply the same fix at the OPAC, right? > > Please fix bug number on the second patch. Bug number fixed. Where in OPAC do you think? On change password page it doesn't make sense for me and on self registration, the password field is not required a if leaved blanked, the password is generated, which is correct.
(In reply to Agnes Rivers-Moore from comment #17) > Our Koha as of 17.11.03 does not generate default username for any patron > type. > Josef said 'Other categories (than org) have username generated as > "firstname.surname" if you leave it blank' - but that does not seem to be > the case any more. > Previous behaviour also assigned a default password, and that also does not > happen any more. > Result is staff have to add three fields, making them unique/matching, even > if the patron does not want an online account. > Looking forward to this being non-mandatory! Thanks. Hi Agnes, please fill a bug report about user names not generated.
(In reply to Josef Moravec from comment #21) > (In reply to Agnes Rivers-Moore from comment #17) > > Our Koha as of 17.11.03 does not generate default username for any patron > > type. > > Josef said 'Other categories (than org) have username generated as > > "firstname.surname" if you leave it blank' - but that does not seem to be > > the case any more. > > Previous behaviour also assigned a default password, and that also does not > > happen any more. > > Result is staff have to add three fields, making them unique/matching, even > > if the patron does not want an online account. > > Looking forward to this being non-mandatory! Thanks. > > Hi Agnes, please fill a bug report about user names not generated. Will test further and submit a new bug for Koha not auto-generating username & password.
Should this be assigned or another status?
Switching back to Passed QA, see comment 20
Bug 20378 created for Koha does not auto-generate OPAC ID and password.
Pushed to master for 18.05, thanks to everybody involved!
Will patches be issued for 17.x?
(In reply to Agnes Rivers-Moore from comment #22) > (In reply to Josef Moravec from comment #21) > > (In reply to Agnes Rivers-Moore from comment #17) > > > Our Koha as of 17.11.03 does not generate default username for any patron > > > type. > > > Josef said 'Other categories (than org) have username generated as > > > "firstname.surname" if you leave it blank' - but that does not seem to be > > > the case any more. > > > Previous behaviour also assigned a default password, and that also does not > > > happen any more. > > > Result is staff have to add three fields, making them unique/matching, even > > > if the patron does not want an online account. > > > Looking forward to this being non-mandatory! Thanks. > > > > Hi Agnes, please fill a bug report about user names not generated. > > Will test further and submit a new bug for Koha not auto-generating username > & password. It seems that resolving bug 19908 will probably fix the auto-generating username and password issue. They were generated when a new record was saved. Mandatory password prevented the save process. I believe this is why the username and password were never generated. Using a quick add without the password fields does allow save, and on reviewing the record, the username and password have been inserted.
Awesome work all, backported to stable for 17.11.05
Depending on Bug 18298 not in 17.05.x