Bug 38186 - Cancelling a hold from the holds over tab shouldn't trigger "return to home" transfer on a lost item
Summary: Cancelling a hold from the holds over tab shouldn't trigger "return to home" ...
Status: Needs documenting
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Emily Lamancusa (emlam)
QA Contact: Chris Cormack
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-10-16 13:42 UTC by Emily Lamancusa (emlam)
Modified: 2024-12-18 13:36 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
24.11.00,24.05.06
Circulation function:


Attachments
Bug 38186: Don't initiate transfer when cancelling hold on lost item (3.17 KB, patch)
2024-10-16 14:32 UTC, Emily Lamancusa (emlam)
Details | Diff | Splinter Review
Bug 38186: Don't initiate transfer when cancelling hold on lost item (3.23 KB, patch)
2024-11-12 17:42 UTC, Brendan Lawlor
Details | Diff | Splinter Review
Bug 38186: Don't initiate transfer when cancelling hold on lost item (3.28 KB, patch)
2024-11-14 20:52 UTC, Chris Cormack
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Emily Lamancusa (emlam) 2024-10-16 13:42:50 UTC
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.
Comment 1 Emily Lamancusa (emlam) 2024-10-16 14:32:58 UTC
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
Comment 2 Emily Lamancusa (emlam) 2024-10-17 15:24:20 UTC
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.
Comment 3 Brendan Lawlor 2024-11-12 17:42:05 UTC
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>
Comment 4 Chris Cormack 2024-11-14 20:52:09 UTC
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>
Comment 5 Katrin Fischer 2024-11-18 16:45:49 UTC
Pushed for 24.11!

Well done everyone, thank you!
Comment 6 Lucas Gass (lukeg) 2024-12-05 22:59:25 UTC
Backported to 24.05.x for upcoming 24.05.06
Comment 7 Fridolin Somers 2024-12-18 13:36:38 UTC
This makes sens, but I prefer not impact 23.11.x for stability