Sometimes, when cancelling waiting holds that have expired, the book on hold cannot be found on the holds shelf. In this case, the librarian would mark the item missing/lost and cancel the hold. However, if the librarian sets the lost status first and then cancels the hold on an item that would normally trigger a "return to home" transfer, the transfer still gets triggered and the lost status is removed, which is confusing and inaccurate. If the item is already marked as lost, it should stay lost and shouldn't generate a transfer.
Created attachment 172821 [details] [review] Bug 38186: Don't initiate transfer when cancelling hold on lost item To test: 0. In the Circulation Rules, set the default return policy to "item returns home (default settings have this already) 1. Find an item belonging to a branch other than the logged-in branch 2. Place a hold on that biblio record for pickup at the logged-in branch 3. Check in the item to set the hold to waiting 4. Set the expiration date to a date in the past To do this in KTD: ktd --shell koha-mysql kohadev UPDATE reserves SET expirationdate = < yesterday's date >; 5. Set a lost status on the item 6. Go to Circulation > Holds awaiting pickup --> The hold should appear on the "holds waiting past their expiration date" tab 7. Click the "Cancel and return to <homebranch>" button next to the hold 8. Open the biblio record for the item --> Note that the lost status is gone and the item shows as in-transit 9. Apply patch 10. Repeat steps 2-8 on the same item --> This time, the item is still lost and is not in-transit
Really, this whole workflow could use some refactoring... Fixing this obvious bug for now, but I'll try to make time to come back to this next cycle.
Created attachment 174433 [details] [review] Bug 38186: Don't initiate transfer when cancelling hold on lost item To test: 0. In the Circulation Rules, set the default return policy to "item returns home (default settings have this already) 1. Find an item belonging to a branch other than the logged-in branch 2. Place a hold on that biblio record for pickup at the logged-in branch 3. Check in the item to set the hold to waiting 4. Set the expiration date to a date in the past To do this in KTD: ktd --shell koha-mysql kohadev UPDATE reserves SET expirationdate = < yesterday's date >; 5. Set a lost status on the item 6. Go to Circulation > Holds awaiting pickup --> The hold should appear on the "holds waiting past their expiration date" tab 7. Click the "Cancel and return to <homebranch>" button next to the hold 8. Open the biblio record for the item --> Note that the lost status is gone and the item shows as in-transit 9. Apply patch 10. Repeat steps 2-8 on the same item --> This time, the item is still lost and is not in-transit Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Created attachment 174537 [details] [review] Bug 38186: Don't initiate transfer when cancelling hold on lost item To test: 0. In the Circulation Rules, set the default return policy to "item returns home (default settings have this already) 1. Find an item belonging to a branch other than the logged-in branch 2. Place a hold on that biblio record for pickup at the logged-in branch 3. Check in the item to set the hold to waiting 4. Set the expiration date to a date in the past To do this in KTD: ktd --shell koha-mysql kohadev UPDATE reserves SET expirationdate = < yesterday's date >; 5. Set a lost status on the item 6. Go to Circulation > Holds awaiting pickup --> The hold should appear on the "holds waiting past their expiration date" tab 7. Click the "Cancel and return to <homebranch>" button next to the hold 8. Open the biblio record for the item --> Note that the lost status is gone and the item shows as in-transit 9. Apply patch 10. Repeat steps 2-8 on the same item --> This time, the item is still lost and is not in-transit Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org> Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Pushed for 24.11! Well done everyone, thank you!
Backported to 24.05.x for upcoming 24.05.06
This makes sens, but I prefer not impact 23.11.x for stability