When a patron is edited (reading the code at least using patron batch modification), the password is lost. Prior to bug 20287 ModMember took the $hash of modification, and '****' was a trick to not update the password (when coming from memberentry). The same trick has been reused for the move of ModMember to Koha::Patron->store, but then the following code will modify the password of the patron: my $password = 'password'; $patron->password($password)->store; $patron->surname('xxx')->store; => User is not longer able to login with 'password'
Highlighted by Jenkins with t/db_dependent/selenium/authentication.t # Failed test 'Patron with flags catalogue should be able to login' # at t/db_dependent/selenium/authentication.t line 63. Wide character in print at /usr/local/share/perl/5.20.2/Test2/Formatter/TAP.pm line 105. # 'Koha › Invalid username or password Log in to Koha' # doesn't match '(?^u:Koha staff client)'
Created attachment 77095 [details] [review] Bug 21087: Test to describe the issue
Created attachment 77096 [details] [review] Bug 21087: Hash passwords in ->update_password
Late here, I do not know if it's enough. Could someone take a look?
Test plan: Create patron, edit, change password (staff and opac), use the password recovery as well as the self registration features. Everything must behave as usual.
Created attachment 77200 [details] [review] Bug 21087: Test to describe the issue Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 77201 [details] [review] Bug 21087: Hash passwords in ->update_password Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 77254 [details] [review] Bug 21087: Fix one wrong call
Created attachment 77255 [details] [review] Bug 21087: Do not store the password in ->store for existing patrons When ->store is called on an existing patron we must not save the password, but keep the one in DB instead. There is a dedicated method (update_password) to call when the password need to be updated
Created attachment 77273 [details] [review] Bug 21087: Fix create_superlibrarian.pl script
Created attachment 77284 [details] [review] Bug 21087: Test to describe the issue Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: John Doe <you@example.com>
Created attachment 77285 [details] [review] Bug 21087: Hash passwords in ->update_password Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: John Doe <you@example.com>
Created attachment 77286 [details] [review] Bug 21087: Fix one wrong call Signed-off-by: John Doe <you@example.com>
Created attachment 77287 [details] [review] Bug 21087: Do not store the password in ->store for existing patrons When ->store is called on an existing patron we must not save the password, but keep the one in DB instead. There is a dedicated method (update_password) to call when the password need to be updated Signed-off-by: John Doe <you@example.com>
Created attachment 77288 [details] [review] Bug 21087: Fix create_superlibrarian.pl script Signed-off-by: John Doe <you@example.com>
Hi Kyle, something's odd about the sign-off line ;) Signed-off-by: John Doe <you@example.com>
Created attachment 77327 [details] [review] Bug 21087: (QA follow-up) Fix usage in create_superlibrarian.pl Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Pushed to master for 18.11, thanks all!
Now John Doe will have a sign off in release notes ;D
Caused by bug 20287 which is not in 18.05.x series. Marking RESOLVED FIXED.