Bug 40620 - Holds Queue will assign to the lowest item number if multiple branches have the same transport cost
Summary: Holds Queue will assign to the lowest item number if multiple branches have t...
Status: Pushed to oldstable
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: All All
: P5 - low major
Assignee: Lisette Scheer
QA Contact: Pedro Amorim
URL:
Keywords: rel_22_11_candidate, rel_23_11_candidate, rel_24_05_candidate, rel_24_11_candidate, rel_25_05_candidate
Depends on:
Blocks:
 
Reported: 2025-08-07 21:17 UTC by Lisette Scheer
Modified: 2025-09-26 13:25 UTC (History)
15 users (show)

See Also:
GIT URL:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
25.11.00,25.05.03,24.11.10
Circulation function:


Attachments
Bug 40620: Holds Queue will assign to the lowest item number if multiple branches have the same transport cost (2.03 KB, patch)
2025-08-12 21:09 UTC, Lisette Scheer
Details | Diff | Splinter Review
Custom sql to put in your Koha directory in a folder named 'shared' (1.57 KB, application/sql)
2025-08-14 20:01 UTC, Lisette Scheer
Details
Bug 40620: Holds Queue will assign to the lowest item number if multiple branches have the same transport cost (2.08 KB, patch)
2025-08-14 21:48 UTC, David Flater
Details | Diff | Splinter Review
Bug 40620: Holds Queue will assign to the lowest item number if multiple branches have the same transport cost (2.13 KB, patch)
2025-08-21 10:23 UTC, Pedro Amorim
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Lisette Scheer 2025-08-07 21:17:29 UTC
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.
Comment 1 Steve, OSLRI, USA 2025-08-08 01:06:55 UTC
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.
Comment 2 Owen Leonard 2025-08-08 12:41:40 UTC
(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?
Comment 3 Steve, OSLRI, USA 2025-08-08 12:44:33 UTC
No, typically, randomization will move the hold around to other available copies from libraries that share the same cost in the transport cost matrix.
Comment 4 Phillip Berg 2025-08-12 20:07:44 UTC
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.
Comment 5 Lisette Scheer 2025-08-12 21:09:55 UTC
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.
Comment 6 Paul Derscheid 2025-08-14 08:19:00 UTC
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?
Comment 7 Lisette Scheer 2025-08-14 19:59:41 UTC
(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.
Comment 8 Lisette Scheer 2025-08-14 20:01:10 UTC
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?)
Comment 9 David Flater 2025-08-14 21:48:47 UTC
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>
Comment 10 Pedro Amorim 2025-08-21 10:23:21 UTC
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>
Comment 11 Pedro Amorim 2025-08-21 10:24:57 UTC
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.
Comment 12 Alex Carver 2025-08-22 13:40:37 UTC
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?
Comment 13 Lucas Gass (lukeg) 2025-08-22 13:48:12 UTC
Nice work everyone!

Pushed to main for 25.11
Comment 14 Lucas Gass (lukeg) 2025-08-22 13:53:34 UTC
This one should be backported to all maintained versions, in my opinion.
Comment 15 Paul Derscheid 2025-08-26 18:50:25 UTC
Nice work everyone!

Pushed to 25.05.x
Comment 16 Fridolin Somers 2025-09-26 13:25:47 UTC
Pushed to 24.11.x for 24.11.10