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: Signed Off
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: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-08-07 21:17 UTC by Lisette Scheer
Modified: 2025-08-14 21:49 UTC (History)
12 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:
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

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>