Bug 31698

Summary: Add ability to move a hold to a new bibliographic record/item
Product: Koha Reporter: Nick Clemens (kidclamp) <nick>
Component: Hold requestsAssignee: Lucas Gass (lukeg) <lucas>
Status: Signed Off --- QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: andrew, barbara.johnson, carthur, Chip.Halvorsen, emily.lamancusa, felicity.brown, gmcharlt, hattara, iina.niemi, katariina.pohto, kebliss, kkrueger, lisette, lucas, magnus, michaela.sieber, mspinney, olivier.delangle, piia.semenoff, rcoert, rkuiper
Version: Main   
Hardware: All   
OS: All   
URL: https://bywatersolutions.com/crowdsourcing/move-hold
GIT URL: Change sponsored?: Sponsored
Patch complexity: Small patch Documentation contact:
Documentation submission: Text to go in the release notes:
Version(s) released in:
Circulation function:
Attachments: Bug 31698: Add alter_hold_targets permission
Bug 31698: Add new move_hold_item subroutine to Hold.pm
Bug 31698: Implement move_hold_item in request.pl
Bug 31698: Make move_hold_item use CanItemBeReserved and add logging
Bug 31698: Template and javascript changes to request.tt
Bug 31698: Report errors and failures back to request.tt
Bug 31698: Deal with priority
Bug 31698: Improve priority
Bug 31698: Flip the logic for priority
Bug 31698: Add missing filters
Bug 31698: Use _ShiftPriority to deal with priority
Bug 31698: Call _FixPriority on orginal biblio to clean-up priorty
Bug 31698: Add alter_hold_targets permission
Bug 31698: Add new move_hold_item subroutine to Hold.pm
Bug 31698: Template and javascript changes to request.tt
Bug 31698: Report errors and failures back to request.tt
Bug 31698: Add missing filters
Bug 31698: Add alter_hold_targets permission
Bug 31698: Add new move_hold_item subroutine to Hold.pm and request.pl
Bug 31698: Template and javascript changes to request.tt
Bug 31698: Report errors and failures back to request.tt
Bug 31698: Add support for moving record level holds
Bug 31698: Combine item and record level subroutines
Bug 31698: Add ability to move holds to new items or new records
Bug 31698: Fix modals for item level moves
Bug 31698: Fix modals for biblio level moves
Bug 31698: Add alter_hold_targets permission
Bug 31698: Add ability to move holds to new items or new records
Bug 31698: Fix modals for item level moves
Bug 31698: Fix modals for biblio level moves
Bug 31698: Add unit tests
Bug 31698: Add alter_hold_targets permission
Bug 31698: Add ability to move holds to new items or new records
Bug 31698: Fix modals for item level moves
Bug 31698: Fix modals for biblio level moves
Bug 31698: Add unit tests
Bug 31698: Disallow moving waiting or intransit holds
Bug 31698: Add alter_hold_targets permission
Bug 31698: Add ability to move holds to new items or new records
Bug 31698: Fix modals for item level moves
Bug 31698: Fix modals for biblio level moves
Bug 31698: Add unit tests
Bug 31698: Disallow moving waiting or intransit holds
Bug 31698: Disallow moving waiting or intransit holds
Error Message for Don't allow holds on damaged items
Checkbox for record level moves sometimes shows twice

Description Nick Clemens (kidclamp) 2022-10-06 13:22:25 UTC
Sometimes a library gets a new edition, or a new copy of an item and would like to be able to directly provide this to a patron with an existing hold.

We propose add a new action on the holds table on request.pl 'Move hold'

For an item level hold it would provide a modal with a barcode entry box so librarians can scan a new copy in hand, and move the hold to that specific item

For a biblio level hold it would provide a modal with a search box - entering keywords would search the catalog, and add a 'Move hold' button to the results - similar to 'Add to basket form existing record' search in acquisitions
Comment 1 Kristi 2023-10-18 19:10:29 UTC
We would love to see this capability! It would be ideal if moving all holds on the bib at once were built in. This would be helpful for bibs with many (over 50) holds on them.
Comment 2 Felicity Brown 2024-01-16 19:30:13 UTC
This would be a fantastic solution to a problem we've been having with re-orders of older titles, where we get the newer edition as a replacement. Our current workaround creates some pretty yucky metadata.
Comment 3 Kristi 2024-01-16 19:38:01 UTC
(In reply to Felicity Brown from comment #2)
> This would be a fantastic solution to a problem we've been having with
> re-orders of older titles, where we get the newer edition as a replacement.
> Our current workaround creates some pretty yucky metadata.

Same for us.
Comment 4 Rhonda Kuiper 2024-05-20 22:00:55 UTC
This function would be fantastic for our library.  Currently, our processes to move holds is time consuming and prone to errors.  This would be great!  
One thing to specifically note is that the date that the hold was placed on the original item would be preserved.  This was the order of the holds queue could be preserved and sorted in the the holds on the new item.
Comment 5 Piia Semenoff 2024-06-05 10:06:15 UTC
This sounds good! I totally agree that currently the transfer of the holds takes time and the possibility of errors is high. 

I think these are the things that can go wrong now while doing the hold transfer and should be considered when building this function:

- It should be taken into account whether the hold has been suspended or whether it is a itemlevel hold or a non-urgent hold. 

- In addition, you must choose the right pick-up location for the hold, change the hold date and priority of the hold.
Comment 6 olivier.delangle 2024-12-17 13:42:32 UTC
I agree. We are facing the same situation.  A new action on the holds table on request.pl 'Move hold' would be very helpful
Comment 7 Lucas Gass (lukeg) 2025-03-12 17:31:03 UTC
Created attachment 179226 [details] [review]
Bug 31698: Add alter_hold_targets permission
Comment 8 Lucas Gass (lukeg) 2025-03-12 21:32:31 UTC
Created attachment 179235 [details] [review]
Bug 31698: Add new move_hold_item subroutine to Hold.pm
Comment 9 Lucas Gass (lukeg) 2025-03-12 21:34:28 UTC
Created attachment 179236 [details] [review]
Bug 31698: Implement move_hold_item in request.pl
Comment 10 Lucas Gass (lukeg) 2025-03-13 17:44:25 UTC
Created attachment 179279 [details] [review]
Bug 31698: Make move_hold_item use CanItemBeReserved and add logging
Comment 11 Lucas Gass (lukeg) 2025-03-13 19:55:04 UTC
Created attachment 179287 [details] [review]
Bug 31698: Template and javascript changes to request.tt
Comment 12 Lucas Gass (lukeg) 2025-03-13 21:36:22 UTC
Created attachment 179290 [details] [review]
Bug 31698: Report errors and failures back to request.tt
Comment 13 Lucas Gass (lukeg) 2025-03-13 22:27:13 UTC
Created attachment 179291 [details] [review]
Bug 31698: Deal with priority
Comment 14 Lucas Gass (lukeg) 2025-03-13 23:29:56 UTC
Created attachment 179292 [details] [review]
Bug 31698: Improve priority
Comment 15 Lucas Gass (lukeg) 2025-03-13 23:55:28 UTC
Created attachment 179295 [details] [review]
Bug 31698: Flip the logic for priority
Comment 16 Lucas Gass (lukeg) 2025-03-25 20:15:10 UTC
Created attachment 179704 [details] [review]
Bug 31698: Add missing filters
Comment 17 Lucas Gass (lukeg) 2025-03-25 22:55:54 UTC
Created attachment 179711 [details] [review]
Bug 31698: Use _ShiftPriority to deal with priority
Comment 18 Lucas Gass (lukeg) 2025-03-25 23:22:10 UTC
Created attachment 179713 [details] [review]
Bug 31698: Call _FixPriority on orginal biblio to clean-up priorty
Comment 19 Lucas Gass (lukeg) 2025-04-21 18:19:40 UTC
Created attachment 181222 [details] [review]
Bug 31698: Add alter_hold_targets permission
Comment 20 Lucas Gass (lukeg) 2025-04-21 18:19:44 UTC
Created attachment 181223 [details] [review]
Bug 31698: Add new move_hold_item subroutine to Hold.pm
Comment 21 Lucas Gass (lukeg) 2025-04-21 18:19:48 UTC
Created attachment 181224 [details] [review]
Bug 31698: Template and javascript changes to request.tt
Comment 22 Lucas Gass (lukeg) 2025-04-21 18:19:52 UTC
Created attachment 181225 [details] [review]
Bug 31698: Report errors and failures back to request.tt
Comment 23 Lucas Gass (lukeg) 2025-04-21 18:19:55 UTC
Created attachment 181226 [details] [review]
Bug 31698: Add missing filters
Comment 24 Lucas Gass (lukeg) 2025-04-21 19:23:53 UTC
Created attachment 181228 [details] [review]
Bug 31698: Add alter_hold_targets permission
Comment 25 Lucas Gass (lukeg) 2025-04-21 19:23:57 UTC
Created attachment 181229 [details] [review]
Bug 31698: Add new move_hold_item subroutine to Hold.pm and request.pl
Comment 26 Lucas Gass (lukeg) 2025-04-21 19:24:00 UTC
Created attachment 181230 [details] [review]
Bug 31698: Template and javascript changes to request.tt
Comment 27 Lucas Gass (lukeg) 2025-04-21 19:24:04 UTC
Created attachment 181231 [details] [review]
Bug 31698: Report errors and failures back to request.tt
Comment 28 Lucas Gass (lukeg) 2025-04-21 21:35:49 UTC
Created attachment 181232 [details] [review]
Bug 31698: Add support for moving record level holds
Comment 29 Lucas Gass (lukeg) 2025-04-21 22:02:34 UTC
Created attachment 181233 [details] [review]
Bug 31698: Combine item and record level subroutines
Comment 30 Lucas Gass (lukeg) 2025-04-21 22:06:06 UTC
Created attachment 181234 [details] [review]
Bug 31698: Add ability to move holds to new items or new records
Comment 31 Lucas Gass (lukeg) 2025-05-05 16:44:55 UTC
Created attachment 181929 [details] [review]
Bug 31698: Fix modals for item level moves
Comment 32 Lucas Gass (lukeg) 2025-05-05 17:02:40 UTC
Created attachment 181930 [details] [review]
Bug 31698: Fix modals for biblio level moves
Comment 33 Lucas Gass (lukeg) 2025-05-05 20:53:07 UTC
Created attachment 181944 [details] [review]
Bug 31698: Add alter_hold_targets permission
Comment 34 Lucas Gass (lukeg) 2025-05-05 20:53:11 UTC
Created attachment 181945 [details] [review]
Bug 31698: Add ability to move holds to new items or new records
Comment 35 Lucas Gass (lukeg) 2025-05-05 20:53:14 UTC
Created attachment 181946 [details] [review]
Bug 31698: Fix modals for item level moves
Comment 36 Lucas Gass (lukeg) 2025-05-05 20:53:18 UTC
Created attachment 181947 [details] [review]
Bug 31698: Fix modals for biblio level moves
Comment 37 Lucas Gass (lukeg) 2025-05-05 20:53:21 UTC
Created attachment 181948 [details] [review]
Bug 31698: Add unit tests
Comment 38 Lucas Gass (lukeg) 2025-05-05 22:35:50 UTC
Created attachment 181951 [details] [review]
Bug 31698: Add alter_hold_targets permission
Comment 39 Lucas Gass (lukeg) 2025-05-05 22:35:54 UTC
Created attachment 181952 [details] [review]
Bug 31698: Add ability to move holds to new items or new records
Comment 40 Lucas Gass (lukeg) 2025-05-05 22:35:57 UTC
Created attachment 181953 [details] [review]
Bug 31698: Fix modals for item level moves
Comment 41 Lucas Gass (lukeg) 2025-05-05 22:36:01 UTC
Created attachment 181954 [details] [review]
Bug 31698: Fix modals for biblio level moves
Comment 42 Lucas Gass (lukeg) 2025-05-05 22:36:04 UTC
Created attachment 181955 [details] [review]
Bug 31698: Add unit tests
Comment 43 Lucas Gass (lukeg) 2025-05-05 22:36:08 UTC
Created attachment 181956 [details] [review]
Bug 31698: Disallow moving waiting or intransit holds
Comment 44 Lucas Gass (lukeg) 2025-05-05 22:38:45 UTC
Created attachment 181957 [details] [review]
Bug 31698: Add alter_hold_targets permission
Comment 45 Lucas Gass (lukeg) 2025-05-05 22:38:49 UTC
Created attachment 181958 [details] [review]
Bug 31698: Add ability to move holds to new items or new records

Test plan:

1. APPLY PATCH, updatedatabase, restart_all
2. Have two staff members. 1. Superlibrarian, 2. Staff with new permission to `alter_hold_targets`
3. Now place some holds on different record, you'll want some item level holds and some record level holds.
4. After placing some holds go to a record with some holds on it.
5. Go to the holds tab (reserve/request.p)
6. You should notice a disabled 'Move selected (0)' button, next to 'Cancel selected (0)'
7. Select some holds to move, ensure that the number updates accordingly. ( Move selected (2) )
8. When you click the button you should see 2 options, 'Item level holds to a different item' and 'Record level holds to a different record'
9. Clicking on either should bring up a modal with information about the holds you selected to move.
10. If you have item level holds and you select 'Item level holds to a different item' those holds should appear pre-checked.
11. If you have item level holds and you select 'Record level holds to a different record' those holds checkboxes should be disabled by default, you should see the 'Problem' as 'Cannot move a waiting or record level hold'
12. If you are moving a item level hold you should see a searchbar labeled 'Enter the item barcode of new hold target:'.
13. Enter a full or partial barcode and click search
14. You should see your item, if it exists.
15. Check 'Move all selected item level holds to this item', once you do so the yellow 'Move selected holds' button should be enabled.
16. Click 'Move selected holds', the hold should be moved.
17. You should see a message like " Moved the following holds:
    Hold ID: 1854 - Moved from The Arden edition of the works of William Shakespeare. to The Arden edition of the works of William Shakespeare."

19. Do steps 12 - 17 again, but with a record level hold.
20. Now make or have many holds on a specific target record to test priority. Make note of the current priority
21. Now move a hold on to that record, testing both item and record level holds.
22. Now on the target record review the priority. The holds originally on the record should not have changed. The hold you move should now have the lowest priority on the record.
23. Check the original record, if a hold was moved all other priority should have been adjusted correctly. FOr example, if the hold you moved was 3 of 4 then the others should have adjusted priority of 1 2 3 now.

24. Turn on HoldsLog if it is disabled.
25. Move some holds, both item and record ones, and review the logs after each one. There should be a correct MODIFY entry for each move.

26. Make an item with a hold on it as damaged and turn on AllowHoldsOnDamagedItems. Try to move the hold, you should get an error telling you that the target item is damaged.

27. Now login as the non-superlibrarian patron from step 2. If they have the `alter_hold_targets` permission they should see the 'Move selected' button.
28. Revoke the `alter_hold_targets` permission. The button should not appear now.
Comment 46 Lucas Gass (lukeg) 2025-05-05 22:38:53 UTC
Created attachment 181959 [details] [review]
Bug 31698: Fix modals for item level moves
Comment 47 Lucas Gass (lukeg) 2025-05-05 22:38:57 UTC
Created attachment 181960 [details] [review]
Bug 31698: Fix modals for biblio level moves
Comment 48 Lucas Gass (lukeg) 2025-05-05 22:39:00 UTC
Created attachment 181961 [details] [review]
Bug 31698: Add unit tests
Comment 49 Lucas Gass (lukeg) 2025-05-05 22:39:04 UTC
Created attachment 181962 [details] [review]
Bug 31698: Disallow moving waiting or intransit holds
Comment 50 PTFS Europe Sandboxes 2025-05-19 21:04:31 UTC
Created attachment 182639 [details] [review]
Bug 31698: Disallow moving waiting or intransit holds

Signed-off-by: kristi <kkrueger@cuyahogalibrary.org>
Comment 51 Kristi 2025-05-19 21:09:44 UTC
Re: Step 25, I do see in the hold log a modify entry. For example, if I created a hold on bib 20, and I move it to bib 8, the log shows the create entry with 'biblionumber'=20 and the modify entry with 'biblionumber=8 for the same object number.

Re: Step 26, I think this was supposed to be set AllowHoldsOnDamagedItems to "don't allow" If this is correct, then the error message shows as expected (see attached screenshot). If it is indeed supposed to be a turn on, that is Allow for this system preference, there is no error message.

One final thing, sometimes on moving record level holds, it shows the checkbox/"Move all selected record level holds..." message twice (see attached RecordLevel_ListTwice.PNG) I didn't think this was big enough not to sign off, but I wanted to call it out.
Comment 52 Kristi 2025-05-19 21:11:12 UTC
Created attachment 182640 [details]
Error Message for Don't allow holds on damaged items
Comment 53 Kristi 2025-05-19 21:11:54 UTC
Created attachment 182641 [details]
Checkbox for record level moves sometimes shows twice
Comment 54 Lucas Gass (lukeg) 2025-06-10 21:20:51 UTC
Bug 23269 is going to conflict with this one, I'll need to rebase this on top of that one.
Comment 55 Lucas Gass (lukeg) 2025-06-16 19:44:59 UTC
(In reply to Lucas Gass (lukeg) from comment #54)
> Bug 23269 is going to conflict with this one, I'll need to rebase this on
> top of that one.

Well, maybe not. Bug 23269 has some problems and I don't want to wait.