Bug 31739

Will upload a patch shortly.

Created attachment 141732 [details] [review]
Bug 31739:  Remove need to pass update param to Koha::Patron::Password::Recovery::SendPasswordRecoveryEmail

Bug 31739: Password recovery from staff fails if previous expired reset-entry exists.
    
SendPasswordRecoveryEmail relies on the calling script to tell if there is an existing valid recovery already. If there's an expired recovery-entry the members/notices.pl script will try to create a new entry resulting in a duplicate key error.
    
This patch fixes the bug by removing the need for the calling script to do the check since SendPasswordRecoveryEmail does the same thing anyway. SendPasswordRecoveryEmail will now use DBIx ->update_or_create instead of looking at the $update param to determine if it should update an existing entry or create a new.
    
The update param is removed from all calling scripts and test are updated.
    
To test:
1. Generate a password recovery mail for a patron
2. Let it expire.
3. Generate a new password recovery from staff to the same patron - Fail!
4: Apply patch
5. Generate a new password recovery from staff to the same patron - Success!
6. Opac password recovery flow should also work.
7. Tests pass.
    
Sponsored-by: Lund University Library

Setting to Needs signoff as well.

Did the patch by changing the behaviour of SendPasswordRecoveryEmail. Could probably have made it easier but since the bug was related to the somewhat convoluted logic I chose to simplify the code instead.

Created attachment 142110 [details] [review]
Bug 31739: Password recovery from staff fails if previous expired reset-entry exists.

SendPasswordRecoveryEmail relies on the calling script to tell if there is an
existing valid recovery already. If there's an expired recovery-entry the
members/notices.pl script will try to create a new entry resulting in a duplicate
key error.

This patch fixes the bug by removing the need for the calling script to do the check as
since SendPasswordRecoveryEmail does the same thing anyway.
SendPasswordRecoveryEmail will now use DBIx ->update_or_create instead of looking at
the $update param to determine if it should update an existing entry or create a new.

The update param is removed from all calling scripts and test are updated.

To test:
1. Generate a password recovery mail for a patron
2. Let it expire.
3. Generate a new password recovery from staff to the same patron - Fail!
4: Apply patch
5. Generate a new password recovery from staff to the same patron - Success!
6. Opac password recovery flow should also work.
7. Tests pass.

Sponsored-by: Lund University Library

Signed-off-by: David Nind <david@davidnind.com>

Comment on attachment 141732 [details] [review]
Bug 31739:  Remove need to pass update param to Koha::Patron::Password::Recovery::SendPasswordRecoveryEmail

I obsoleted the first patch - for whatever reason, when I signed it off there were two patches.

Testing notes (using koha-testing-docker):

1. For a patron category (for example, Patron (PT)), set 'Password reset in OPAC' to 'Allowed' (Administration > Patrons and circulation > Patron categories).

2. Enable system to send emails (for testing, using Gmail) and restart everything (flush_memcached, restart_all):
   - You need a valid SMTP configuration in koha-conf.xml.
   - Generate an 'app password' for your Gmail account.
   - Edit koha-conf.xml and add this configuration (YOUR APP PASSWORD = the app password):
     <smtp_server>
       <host>smtp.gmail.com</host>
       <port>587</port>
       <timeout>5</timeout>
       <ssl_mode>STARTTLS</ssl_mode>
       <user_name>YOUR GMAIL ADDRESS</user_name>
       <password>YOUR APP PASSWORD</password>
       <debug>1</debug>
     </smtp_server>

3. Update the details for a patron:
   - add your Gmail address to a patron (for example: YOUR GMAIL ADDRESS for Mary Burton, borrower number 49)
   - update the OPAC/Staff interface login username (for example: mary)

4. Initiate a password reset from the OPAC:
   . From the OPAC home page, click on 'Forgot your password' below the log in box
   . Enter the username for the login and press 'Submit'

5. Update the expiry date for the password reset in the database so that it is expired:
   - List password recovery requests:
     . koha-mysql kohadev
     . select * from borrower_password_recovery;
   - Update the expiry date:
     . update borrower_password_recovery set valid_until = "2022-10-18 00:00:00" where borrowernumber=49;

6. Go to the patron's details page in the staff interface and select More > Send password reset:
   ==> You get an error trace: 
       DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Duplicate entry '49' for key 'PRIMARY' at /kohadevbox/koha/Koha/Patron/Password/Recovery.pm line 132  at /usr/share/perl5/DBIx/Class/Exception.pm line 77

7. Apply the patch and restart everything (flush_memcached, restart_all).

8. Send password reset from the staff interface again - it should now work (email received and 'Koha password reset' notice under notices).

9. Re-test the forgotten password recovery process - steps 4, 5 and 8. Everything should work as expected:
   . Note that for step 4 you may get an error message "The process of password recovery has already been started for this account ("mary")...". Click on the link 'Get new password recovery link'.

10. Tests should pass: prove t/db_dependent/Passwordrecovery.t

Created attachment 142399 [details] [review]
Bug 31739: Password recovery from staff fails if previous expired reset-entry exists.

SendPasswordRecoveryEmail relies on the calling script to tell if there is an
existing valid recovery already. If there's an expired recovery-entry the
members/notices.pl script will try to create a new entry resulting in a duplicate
key error.

This patch fixes the bug by removing the need for the calling script to do the check as
since SendPasswordRecoveryEmail does the same thing anyway.
SendPasswordRecoveryEmail will now use DBIx ->update_or_create instead of looking at
the $update param to determine if it should update an existing entry or create a new.

The update param is removed from all calling scripts and test are updated.

To test:
1. Generate a password recovery mail for a patron
2. Let it expire.
3. Generate a new password recovery from staff to the same patron - Fail!
4: Apply patch
5. Generate a new password recovery from staff to the same patron - Success!
6. Opac password recovery flow should also work.
7. Tests pass.

Sponsored-by: Lund University Library

Signed-off-by: David Nind <david@davidnind.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Pushed to master for 22.11.

Nice work everyone, thanks!

backported to 22.05.x for upcoming 22.05.08

applied to 21.11 for 21.11.15