When using a transportation cost matrix where some branches have the same cost, the hold will be assigned to the lowest item number. This can cause uneven distribution of holds if one branch is cataloging items before they arrive and another catalogs them once they arrive, the first branch will always be targeted first.
Thanks, Lisette! One additional note for those who are affected. In this situation, a hold will get stuck if a library doesn't take the time to mark an item missing.
(In reply to Steve, OSLRI, USA from comment #1) > In this situation, a hold > will get stuck if a library doesn't take the time to mark an item missing. Isn't that always the case?
No, typically, randomization will move the hold around to other available copies from libraries that share the same cost in the transport cost matrix.
Assuming I'm understanding this properly... This is extremely problematic and defeats the purpose of setting the matrix to have equal, randomized distribution. I'm really disappointed this was not caught sooner during testing. It likely explains why one of the larger, faster at processing member libraries within our organization is feeling the brunt of fulfilling more holds since the migration to Koha. All of the multi-library consortia/cooperatives using the transport cost matrix should be made aware of this ASAP.
Created attachment 185355 [details] [review] Bug 40620: Holds Queue will assign to the lowest item number if multiple branches have the same transport cost To Test: Before applying: 1. Turn on the UseTransportCostMatrix system preference 2. Create holds on a record with multiple items. (I used Lanark in KTD) 3. Set the item location to all be the same (I used MID) 4. Set the holds to pickup at Centerville, Fairfield, and Pleasant Valley 5. Set the transport cost matrix to Centerville\fairfield 1 Centerville\Midway 1 Fairfield\Centerville 1 Fairfield\Midway 1 Midway\Centerville 1 Midway\Fairfield 1 Midway\Pleasant Valley 4 6. Build the holds queue (either turn on realtime hold queue and then edit the bib to update or run the cron on the command line) 7. Run a report: select * from hold_fill_targets where biblionumber=9 order by borrowernumber; 8. Rebuild the hold queue 9. Run the report again, the results should be the same. 10. Apply the patch 11. Run the hold queue again 12. Observe the results should now be different. 13. Try a few more times and ensure the numbers are changing, create some more items at midway and try again to see more variety in numbers.
Hi Lisette, I tried the test plan yesterday but failed. I still got the same result after every holds queue build. Could you disambiguate certain things in the test plan, like the number of holds you placed and what exact changes you made to the items?
(In reply to Paul Derscheid from comment #6) > Hi Lisette, I tried the test plan yesterday but failed. > > I still got the same result after every holds queue build. > > Could you disambiguate certain things in the test plan, like the number of > holds you placed and what exact changes you made to the items? Hi Paul, It looks like there's an issue with the transport cost matrix not allowing you to disable checkboxes on main? It doesn't save, I just had to do it in koha-mysql kohadev using: update transport_cost set disable_transfer = 0 where cost !=0.00; I'm also going to attach a custom sql which sets everything, but then you need to hit "save" on the transport cost matrix page (to generate all the ones we don't care about because they're all 0 and disabled) and then update the sql, then it should work. I'll see if I can find a bug for this/file one if I can't.
Created attachment 185427 [details] Custom sql to put in your Koha directory in a folder named 'shared' If you put this file in koha/shared and then spin up your box or reset_all it should make most of the changes you'll need (also just more clear about what's needed maybe?)
Created attachment 185431 [details] [review] Bug 40620: Holds Queue will assign to the lowest item number if multiple branches have the same transport cost To Test: Before applying: 1. Turn on the UseTransportCostMatrix system preference 2. Create holds on a record with multiple items. (I used Lanark in KTD) 3. Set the item location to all be the same (I used MID) 4. Set the holds to pickup at Centerville, Fairfield, and Pleasant Valley 5. Set the transport cost matrix to Centerville\fairfield 1 Centerville\Midway 1 Fairfield\Centerville 1 Fairfield\Midway 1 Midway\Centerville 1 Midway\Fairfield 1 Midway\Pleasant Valley 4 6. Build the holds queue (either turn on realtime hold queue and then edit the bib to update or run the cron on the command line) 7. Run a report: select * from hold_fill_targets where biblionumber=9 order by borrowernumber; 8. Rebuild the hold queue 9. Run the report again, the results should be the same. 10. Apply the patch 11. Run the hold queue again 12. Observe the results should now be different. 13. Try a few more times and ensure the numbers are changing, create some more items at midway and try again to see more variety in numbers. Signed-off-by: David Flater <flaterdavid@gmail.com>
Created attachment 185622 [details] [review] Bug 40620: Holds Queue will assign to the lowest item number if multiple branches have the same transport cost To Test: Before applying: 1. Turn on the UseTransportCostMatrix system preference 2. Create holds on a record with multiple items. (I used Lanark in KTD) 3. Set the item location to all be the same (I used MID) 4. Set the holds to pickup at Centerville, Fairfield, and Pleasant Valley 5. Set the transport cost matrix to Centerville\fairfield 1 Centerville\Midway 1 Fairfield\Centerville 1 Fairfield\Midway 1 Midway\Centerville 1 Midway\Fairfield 1 Midway\Pleasant Valley 4 6. Build the holds queue (either turn on realtime hold queue and then edit the bib to update or run the cron on the command line) 7. Run a report: select * from hold_fill_targets where biblionumber=9 order by borrowernumber; 8. Rebuild the hold queue 9. Run the report again, the results should be the same. 10. Apply the patch 11. Run the hold queue again 12. Observe the results should now be different. 13. Try a few more times and ensure the numbers are changing, create some more items at midway and try again to see more variety in numbers. Signed-off-by: David Flater <flaterdavid@gmail.com> Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Passing QA here as it's considered to be a bug, works as described and does not cause any tests to fail that I can see. Having said that, I think we should add tests here that prove that this behavior is working the way it is by design.
Thanks to everyone working on this bug. It's important to us rascally consortia types. Is there a possibility that this could be backported to 25.05 when complete?
Nice work everyone! Pushed to main for 25.11
This one should be backported to all maintained versions, in my opinion.
Nice work everyone! Pushed to 25.05.x
Pushed to 24.11.x for 24.11.10