|
Description
Aleisha Amohia
2023-06-13 05:13:49 UTC
Created attachment 152288 [details] [review] Bug 33992: Only consider the date when labelling a waiting recall as problematic This patches makes sure Koha ignores the hours/minutes/seconds when comparing a recall waiting date to decide if it has been waiting too long for pickup. To test: 1. Enable UseRecalls syspref and set the relevant circulation and fines rules to configure recalls 2. Set the RecallsMaxPickUpDelay to 1 day 3. Check out Item A to Patron A 4. Log into the OPAC as Patron B 5. Search for Item A and place a recall 6. Log back into the staff interface and check in Item A 7. Confirm the recall as waiting for Patron B 8. Go to Circulation -> Recalls awaiting pickup 9. Confirm your recall exists under the 'Recalls waiting' tab 10. Log into the database and get the time for now sudo koha-mysql INSTANCE select now(); 11. Change the waiting_date in the database for this recall to yesterday so we would expect to see it under the 'Recalls waiting over 1 days' tab. Base the hours on the now() timestamp from the step before, add a few hours to this. For example, if the above SQl query returns "2023-06-13 10:54:21", change waiting_date to be slightly less than 1 day/24 hours before this now() timestamp, but still what we would consider 'yesterday' select * from recalls; # to get the recall_id update recalls set waiting_date = "2023-06-12 14:54:21" where recall_id = X; 12. Refresh the Circulation -> Recalls awaiting pickup page. The recall will not show up under the 'Recalls waiting over 1 days' tab, even though we expect it to. 13. Apply the patch, restart services, refresh the page 14. Confirm the recall now shows under the 'Recalls waiting over 1 days' tab as expected. Sponsored-by: Auckland University of Technology Created attachment 152289 [details] [review] Bug 33992: Only consider the date when auto-expiring problematic recalls This patch carries this fix into the misc/cronjobs/recalls/expire_recalls.pl cronjob so that recalls are automatically expired when they have been waiting a problematic number of days, not considering hours, as expected. To test, follow the test plan from the first patch. This will set you up with a waiting problematic recall. Run the cronjob manually perl misc/cronjobs/recalls/expire_recalls.pl Refresh your 'Recalls awaiting pickup' page. Your problematic recall should be gone/expired. Sponsored-by: Auckland University of Technology Created attachment 152363 [details] [review] Bug 33992: Only consider the date when labelling a waiting recall as problematic This patches makes sure Koha ignores the hours/minutes/seconds when comparing a recall waiting date to decide if it has been waiting too long for pickup. To test: 1. Enable UseRecalls syspref and set the relevant circulation and fines rules to configure recalls 2. Set the RecallsMaxPickUpDelay to 1 day 3. Check out Item A to Patron A 4. Log into the OPAC as Patron B 5. Search for Item A and place a recall 6. Log back into the staff interface and check in Item A 7. Confirm the recall as waiting for Patron B 8. Go to Circulation -> Recalls awaiting pickup 9. Confirm your recall exists under the 'Recalls waiting' tab 10. Log into the database and get the time for now sudo koha-mysql INSTANCE select now(); 11. Change the waiting_date in the database for this recall to yesterday so we would expect to see it under the 'Recalls waiting over 1 days' tab. Base the hours on the now() timestamp from the step before, add a few hours to this. For example, if the above SQl query returns "2023-06-13 10:54:21", change waiting_date to be slightly less than 1 day/24 hours before this now() timestamp, but still what we would consider 'yesterday' select * from recalls; # to get the recall_id update recalls set waiting_date = "2023-06-12 14:54:21" where recall_id = X; 12. Refresh the Circulation -> Recalls awaiting pickup page. The recall will not show up under the 'Recalls waiting over 1 days' tab, even though we expect it to. 13. Apply the patch, restart services, refresh the page 14. Confirm the recall now shows under the 'Recalls waiting over 1 days' tab as expected. Sponsored-by: Auckland University of Technology Signed-off-by: David Nind <david@davidnind.com> Created attachment 152364 [details] [review] Bug 33992: Only consider the date when auto-expiring problematic recalls This patch carries this fix into the misc/cronjobs/recalls/expire_recalls.pl cronjob so that recalls are automatically expired when they have been waiting a problematic number of days, not considering hours, as expected. To test, follow the test plan from the first patch. This will set you up with a waiting problematic recall. Run the cronjob manually perl misc/cronjobs/recalls/expire_recalls.pl Refresh your 'Recalls awaiting pickup' page. Your problematic recall should be gone/expired. Sponsored-by: Auckland University of Technology Signed-off-by: David Nind <david@davidnind.com> Created attachment 152365 [details] [review] Bug 33992: Only consider the date when auto-expiring problematic recalls This patch carries this fix into the misc/cronjobs/recalls/expire_recalls.pl cronjob so that recalls are automatically expired when they have been waiting a problematic number of days, not considering hours, as expected. To test, follow the test plan from the first patch. This will set you up with a waiting problematic recall. Run the cronjob manually perl misc/cronjobs/recalls/expire_recalls.pl Refresh your 'Recalls awaiting pickup' page. Your problematic recall should be gone/expired. Expiration dates will apply when expiring any 'unfulfilled' recall i.e. newly requested, overdue to be returned, and awaiting pickup. Sponsored-by: Auckland University of Technology Hi David,
Sorry I didn't realise this was already Signed off, I've just amended the second patch - this was the only change from the patch you had already tested.
--- a/misc/cronjobs/recalls/expire_recalls.pl
+++ b/misc/cronjobs/recalls/expire_recalls.pl
@@ -42,7 +42,7 @@ cronlogaction({ info => $command_line_options });
my $recalls = Koha::Recalls->search({ completed => 0 });
my $today = dt_from_string()->truncate( to => 'day' );
while( my $recall = $recalls->next ) {
- if ( ( $recall->requested or $recall->overdue ) and $recall->expiration_date ) {
+ if ( ( $recall->requested or $recall->overdue or $recall->waiting ) and $recall->expiration_date ) {
Thanks
Aleisha
Created attachment 152368 [details] [review] Bug 33992: Only consider the date when labelling a waiting recall as problematic This patches makes sure Koha ignores the hours/minutes/seconds when comparing a recall waiting date to decide if it has been waiting too long for pickup. To test: 1. Enable UseRecalls syspref and set the relevant circulation and fines rules to configure recalls 2. Set the RecallsMaxPickUpDelay to 1 day 3. Check out Item A to Patron A 4. Log into the OPAC as Patron B 5. Search for Item A and place a recall 6. Log back into the staff interface and check in Item A 7. Confirm the recall as waiting for Patron B 8. Go to Circulation -> Recalls awaiting pickup 9. Confirm your recall exists under the 'Recalls waiting' tab 10. Log into the database and get the time for now sudo koha-mysql INSTANCE select now(); 11. Change the waiting_date in the database for this recall to yesterday so we would expect to see it under the 'Recalls waiting over 1 days' tab. Base the hours on the now() timestamp from the step before, add a few hours to this. For example, if the above SQl query returns "2023-06-13 10:54:21", change waiting_date to be slightly less than 1 day/24 hours before this now() timestamp, but still what we would consider 'yesterday' select * from recalls; # to get the recall_id update recalls set waiting_date = "2023-06-12 14:54:21" where recall_id = X; 12. Refresh the Circulation -> Recalls awaiting pickup page. The recall will not show up under the 'Recalls waiting over 1 days' tab, even though we expect it to. 13. Apply the patch, restart services, refresh the page 14. Confirm the recall now shows under the 'Recalls waiting over 1 days' tab as expected. Sponsored-by: Auckland University of Technology Signed-off-by: David Nind <david@davidnind.com> Created attachment 152369 [details] [review] Bug 33992: Only consider the date when auto-expiring problematic recalls This patch carries this fix into the misc/cronjobs/recalls/expire_recalls.pl cronjob so that recalls are automatically expired when they have been waiting a problematic number of days, not considering hours, as expected. To test, follow the test plan from the first patch. This will set you up with a waiting problematic recall. Run the cronjob manually perl misc/cronjobs/recalls/expire_recalls.pl Refresh your 'Recalls awaiting pickup' page. Your problematic recall should be gone/expired. Expiration dates will apply when expiring any 'unfulfilled' recall i.e. newly requested, overdue to be returned, and awaiting pickup. Sponsored-by: Auckland University of Technology Signed-off-by: David Nind <david@davidnind.com> (In reply to Aleisha Amohia from comment #6) > Hi David, > > Sorry I didn't realise this was already Signed off, I've just amended the > second patch - this was the only change from the patch you had already > tested. > .. > Thanks > Aleisha No problem! I have retested (I think I tested correctly for the second patch, so have signed off.) David There were some warns when running the expire_recalls.pl script, but the lines seem unrelated to this change: Argument "" isn't numeric in numeric ge (>=) at misc/cronjobs/recalls/expire_recalls.pl line 61. Argument "" isn't numeric in numeric gt (>) at misc/cronjobs/recalls/expire_recalls.pl line 62. File separately? Created attachment 153512 [details] [review] Bug 33992: Only consider the date when labelling a waiting recall as problematic This patches makes sure Koha ignores the hours/minutes/seconds when comparing a recall waiting date to decide if it has been waiting too long for pickup. To test: 1. Enable UseRecalls syspref and set the relevant circulation and fines rules to configure recalls 2. Set the RecallsMaxPickUpDelay to 1 day 3. Check out Item A to Patron A 4. Log into the OPAC as Patron B 5. Search for Item A and place a recall 6. Log back into the staff interface and check in Item A 7. Confirm the recall as waiting for Patron B 8. Go to Circulation -> Recalls awaiting pickup 9. Confirm your recall exists under the 'Recalls waiting' tab 10. Log into the database and get the time for now sudo koha-mysql INSTANCE select now(); 11. Change the waiting_date in the database for this recall to yesterday so we would expect to see it under the 'Recalls waiting over 1 days' tab. Base the hours on the now() timestamp from the step before, add a few hours to this. For example, if the above SQl query returns "2023-06-13 10:54:21", change waiting_date to be slightly less than 1 day/24 hours before this now() timestamp, but still what we would consider 'yesterday' select * from recalls; # to get the recall_id update recalls set waiting_date = "2023-06-12 14:54:21" where recall_id = X; 12. Refresh the Circulation -> Recalls awaiting pickup page. The recall will not show up under the 'Recalls waiting over 1 days' tab, even though we expect it to. 13. Apply the patch, restart services, refresh the page 14. Confirm the recall now shows under the 'Recalls waiting over 1 days' tab as expected. Sponsored-by: Auckland University of Technology Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Created attachment 153513 [details] [review] Bug 33992: Only consider the date when auto-expiring problematic recalls This patch carries this fix into the misc/cronjobs/recalls/expire_recalls.pl cronjob so that recalls are automatically expired when they have been waiting a problematic number of days, not considering hours, as expected. To test, follow the test plan from the first patch. This will set you up with a waiting problematic recall. Run the cronjob manually perl misc/cronjobs/recalls/expire_recalls.pl Refresh your 'Recalls awaiting pickup' page. Your problematic recall should be gone/expired. Expiration dates will apply when expiring any 'unfulfilled' recall i.e. newly requested, overdue to be returned, and awaiting pickup. Sponsored-by: Auckland University of Technology Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Pushed to master for 23.11. Nice work everyone, thanks! Pushed to 23.05.x for 23.05.03 Nice work everyone! Pushed to 22.11.x for next release Backported to 22.05.x for upcoming 22.05.16 |