Bug 41410 - Allow definition of a period after hold creation during which the hold is only filled locally
Summary: Allow definition of a period after hold creation during which the hold is onl...
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-12-09 17:21 UTC by Andrew Fuerste-Henry
Modified: 2025-12-09 17:21 UTC (History)
3 users (show)

See Also:
GIT URL:
Initiative type: ---
Sponsorship status: ---
Comma delimited list of Sponsors:
Crowdfunding goal: 0
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Fuerste-Henry 2025-12-09 17:21:19 UTC
Currently, with local holds priority enabled the holds queue will always target an available local item if one exists; this preference is enforced before Koha consults the transport cost matrix or thinks about the Hungarian algorithm.

This dev will:
- add a new field to tmp_holdsqueue: local priority match
- add a new system preference to enable this option and set days value for local priority period
- local priority period is defined relative to when the hold was created
- when the queue targets an item, add the local priority match flag if the target item is within the local holds group of the hold pickup location
- at checkin, if the item could fill a hold Koha will check:
-- is this item within the hold pickup group? If yes, fill hold; if no, proceed to next check
-- is the hold within the local priority period? If no, fill hold; if yes, proceed to next check
-- does the queue's current target have the local priority match flag? If no, fill hold; if yes, do not fill hold (look for other holds this item could fill or check item in)