[Bug 41410] New: Allow definition of a period after hold creation during which the hold is only filled locally
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Bug ID: 41410 Summary: Allow definition of a period after hold creation during which the hold is only filled locally Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: andrew@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, lisette@bywatersolutions.com, tomascohen@gmail.com 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) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 trevor.diamond@mainlib.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |trevor.diamond@mainlib.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Michelle Spinney <mspinney@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mspinney@clamsnet.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Donna <bwsdonna@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bwsdonna@gmail.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Danielle M. <dmeininger591@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dmeininger591@gmail.com --- Comment #1 from Danielle M. <dmeininger591@gmail.com> --- It would be helpful if this preference could be enabled independent of having local holds priority enabled. Meaning, we want the local item to fill the local hold but not at the expense of the holds priority order. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #2 from trevor.diamond@mainlib.org --- (In reply to Danielle M. from comment #1)
It would be helpful if this preference could be enabled independent of having local holds priority enabled. Meaning, we want the local item to fill the local hold but not at the expense of the holds priority order.
There shouldn't be muchm if any, interaction between this setting and priority. The idea is not to skip patrons, but that if there is a copy on the shelf, don't fill with a copy from elsewhere until the local staff have a chance to actually pull the holds queue. Current "Bad" Workflow 1) Patron Places hold for pickup at Branch A 2) There is a copy available at Branch A 3) Another eligible copy gets checked in at Branch B when staff clear the book drop, Koha traps that item for the patron. 4) Now the patron has to wait until that copy comes in from Branch B. Target Workflow 1) Patron Places hold for pickup at Branch A 2) There is a copy available at Branch A 3) For 24 hours, only the item on the shelf at branch A will fill the hold. 4) IF there are no copies "available" or the staff subsequently mark the item missing (or any status that prevent hold fulfillment), then the request will move on to a wider pool of items. The idea is to prevent unnecessary item transit. Generally "a book in the hand is worth two on the shelf" is a great rule since it ensures that Koha is filling patron requests with items that are already in staff hands and the item definitely is useable/findable. However, the pickup location can provide much faster service, they just need a chance to actually go to the shelf and actually look for the item. This development is designed to give them that chance. If the patron isn't next in line, then they won't be the patron on the holds queue. Also, if there are multiple patrons waiting, then it is unlikely there would be a copy on the shelf anyway (barring unusual circumstances where an item's eligibility changes due to a batch modification or something like that). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #3 from Danielle M. <dmeininger591@gmail.com> --- (In reply to trevor.diamond from comment #2)
(In reply to Danielle M. from comment #1)
It would be helpful if this preference could be enabled independent of having local holds priority enabled. Meaning, we want the local item to fill the local hold but not at the expense of the holds priority order.
There shouldn't be muchm if any, interaction between this setting and priority. The idea is not to skip patrons, but that if there is a copy on the shelf, don't fill with a copy from elsewhere until the local staff have a chance to actually pull the holds queue.
Current "Bad" Workflow 1) Patron Places hold for pickup at Branch A 2) There is a copy available at Branch A 3) Another eligible copy gets checked in at Branch B when staff clear the book drop, Koha traps that item for the patron. 4) Now the patron has to wait until that copy comes in from Branch B.
Target Workflow 1) Patron Places hold for pickup at Branch A 2) There is a copy available at Branch A 3) For 24 hours, only the item on the shelf at branch A will fill the hold. 4) IF there are no copies "available" or the staff subsequently mark the item missing (or any status that prevent hold fulfillment), then the request will move on to a wider pool of items.
The idea is to prevent unnecessary item transit. Generally "a book in the hand is worth two on the shelf" is a great rule since it ensures that Koha is filling patron requests with items that are already in staff hands and the item definitely is useable/findable. However, the pickup location can provide much faster service, they just need a chance to actually go to the shelf and actually look for the item. This development is designed to give them that chance. If the patron isn't next in line, then they won't be the patron on the holds queue. Also, if there are multiple patrons waiting, then it is unlikely there would be a copy on the shelf anyway (barring unusual circumstances where an item's eligibility changes due to a batch modification or something like that).
That makes perfect sense and is a good idea. Another comment I wanted to pass on is, will this be a global setting or could different libraries have unique time frames? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #4 from trevor.diamond@mainlib.org --- How will hyperholds affect this? (Ability to fill a group of requests by the first available individual requests). https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42006 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |martin.renvoize@openfifth.c |ity.org |o.uk CC| |martin.renvoize@openfifth.c | |o.uk -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Small patch Status|NEW |Needs Signoff Sponsorship status|--- |Sponsored Comma delimited| |Main Library Alliance list of Sponsors| |<https://www.mainlib.org/> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #5 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197438 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197438&action=edit Bug 41410: Add local_holdgroup_match column and exclusivity period syspref Adds groundwork for a time-bounded local holds exclusivity feature: - Adds a local_holdgroup_match flag (tinyint, default 0) to both hold_fill_targets (consulted by CheckReserves/_Findgroupreserve at checkin) and tmp_holdsqueue (so queue/pull-list reports can display it). The flag will be set by the queue builder when a local-group match is made. - Adds a new system preference LocalHoldsPriorityExclusivityPeriod (Integer, default 0 = disabled) specifying the number of days from hold creation during which only locally-targeted items may fill a hold with a local queue target. - Provides an atomicupdate that guards both ALTERs with column_exists and INSERT IGNOREs the new syspref. Test plan: 1. Apply atomicupdate: perl installer/data/mysql/updatedatabase.pl 2. Verify both columns exist: SHOW COLUMNS FROM hold_fill_targets LIKE 'local%'; SHOW COLUMNS FROM tmp_holdsqueue LIKE 'local%'; 3. Verify syspref row: SELECT variable, value FROM systempreferences WHERE variable = 'LocalHoldsPriorityExclusivityPeriod'; 4. Confirm default value is 0 and type is Integer. Sponsored-by: Main Library Alliance <https://www.mainlib.org/> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #6 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197439 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197439&action=edit Bug 41410: DBIx::Class schema update Regenerated via `dbic --force` after adding the local_holdgroup_match column to hold_fill_targets and tmp_holdsqueue in the previous patch. Test plan: 1. Inspect Koha/Schema/Result/HoldFillTarget.pm and TmpHoldsqueue.pm and confirm the new local_holdgroup_match accessor is defined above the `DO NOT MODIFY` marker. 2. Confirm custom content below the marker (koha_object_class, +item_level_request is_boolean) is preserved. Sponsored-by: Main Library Alliance <https://www.mainlib.org/> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #7 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197440 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197440&action=edit Bug 41410: Add local holds priority exclusivity period When LocalHoldsPriority is enabled, the holds queue picks a local-group item for eligible holds. Until now there was nothing to reserve that priority at checkin time: if a non-local item was returned first, it would happily fill the hold and the local-priority decision was lost. This patch adds a time-bounded exclusivity window so that, for a configurable number of days after a hold is placed, a hold whose queue target is a local-group item will not be filled by a non-local item. Changes: - C4/HoldsQueue.pm: in MapItemsToHoldRequests, flag %item_map entries that matched on local library (GiveLibrary/GiveLibraryAndGroup) or local hold group (GiveLibraryGroup/GiveLibraryAndGroup) with local_holdgroup_match => 1, and propagate that into both the tmp_holdsqueue and hold_fill_targets INSERTs. - C4/Reserves.pm: in the CheckReserves loop, when LocalHoldsPriorityExclusivityPeriod is set, the hold is still within that window, and the item being evaluated is not itself a local match, skip the reserve if its hold_fill_targets row has local_holdgroup_match = 1. Missing hold_fill_targets row means "no information" -- fall through so holds are never trapped between queue runs. - circulation.pref: expose the new LocalHoldsPriorityExclusivityPeriod preference next to the existing LocalHoldsPriority* entries. The feature is a no-op unless both LocalHoldsPriority is set to something other than "Don't give" AND LocalHoldsPriorityExclusivityPeriod is > 0. Test plan: 1) Apply the patches and run the atomicupdate. 2) Set up a library group flagged as a local hold group containing two libraries (call them A and B). Add a third library C that is NOT in the group. 3) Add one item to each library (itemA, itemB, itemC) on the same biblio. 4) Administration -> System preferences -> Circulation: - Set LocalHoldsPriority to "Give library group". - Set LocalHoldsPriorityPatronControl to "home library". - Set LocalHoldsPriorityItemControl to "home library". - Set LocalHoldsPriorityExclusivityPeriod to 7. 5) As a patron whose home library is A, place a title-level hold with pickup at A. 6) Run the holds queue (misc/cronjobs/holds/build_holds_queue.pl). -> The queue should target itemA (or itemB) for this hold. -> Confirm in the database: SELECT reserve_id, itemnumber, local_holdgroup_match FROM hold_fill_targets; The targeted row must have local_holdgroup_match = 1. -> Holds to pull / holds queue report should also show the flag (tmp_holdsqueue.local_holdgroup_match = 1). 7) At library C, check in itemC (the non-local item). -> The hold must NOT be captured -- itemC simply goes back on the shelf. 8) At library A, check in itemA (the local item). -> The hold IS captured for the patron. 9) Cancel and re-place the hold, run the queue again. Manually age the hold past the window: UPDATE reserves SET reservedate = DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY) WHERE reserve_id = <id>; Now check in itemC again. -> The hold IS captured (exclusivity window has expired). 10) Re-place the hold but do NOT run the queue. With no hold_fill_targets row for the reserve, check in itemC. -> The hold IS captured (we never trap holds between queue runs). 11) Flip LocalHoldsPriorityExclusivityPeriod back to 0 and repeat step 7. -> The hold IS captured; the feature is fully disabled. 12) Run: prove t/db_dependent/Holds/LocalHoldsPriority.t \ t/db_dependent/HoldsQueue.t \ t/db_dependent/Reserves.t \ t/db_dependent/Koha/Hold.t -> All tests pass. Sponsored-by: Main Library Alliance <https://www.mainlib.org/> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #8 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197441 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197441&action=edit Bug 41410: Unit tests Covers the new LocalHoldsPriorityExclusivityPeriod behaviour and keeps existing tests working with the schema change: - t/db_dependent/Holds/LocalHoldsPriority.t: new subtest exercising all four cases -- pref disabled, pref active on a fresh hold, pref active past the window, and pref active with no hold_fill_targets row (queue hasn't run). - t/db_dependent/HoldsQueue.t: assert that after CreateQueue() with a local-group match, both tmp_holdsqueue and hold_fill_targets rows carry local_holdgroup_match = 1. - t/db_dependent/Reserves.t, t/db_dependent/Koha/Hold.t: qualify the two direct "INSERT INTO hold_fill_targets VALUES (...)" statements with explicit column names so they continue to work now that hold_fill_targets has one extra column. Test plan: prove t/db_dependent/Holds/LocalHoldsPriority.t \ t/db_dependent/HoldsQueue.t \ t/db_dependent/Reserves.t \ t/db_dependent/Koha/Hold.t All tests should pass. Sponsored-by: Main Library Alliance <https://www.mainlib.org/> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #9 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- This worked as described and all tests pass! It should not be connected to LocalHoldsPriority. These two features are adjacent but distinct and each should be usable without the other. LocalHoldsPriority alters which patron's hold will be filled first while LocalExclusivity alters which items can be used to fill a hold. Desired changes: - Rename LocalHoldsPriorityExclusivityPeriod to LocalHoldsExclusivityPeriod - Flag hold fill targets as local_holdgroup_match regardless of LocalHoldsPriority value I believe that will require sysprefs for LocalHoldsExclusivityPatronControl and LocalHoldsExclusivityItemControl in order to determine how to check for matches. I think it's ok for exclusivity to always be enforced by library hold group, if one is defined (unlike LocalHoldsPriority, which can be set to work only by library, ignoring groups). -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #197438|0 |1 is obsolete| | Attachment #197439|0 |1 is obsolete| | Attachment #197440|0 |1 is obsolete| | Attachment #197441|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #10 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197476 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197476&action=edit Bug 41410: Add local_holdgroup_match column and exclusivity period syspref Adds groundwork for a time-bounded local holds exclusivity feature: - Adds a local_holdgroup_match flag (tinyint, default 0) to both hold_fill_targets (consulted by CheckReserves/_Findgroupreserve at checkin) and tmp_holdsqueue (so queue/pull-list reports can display it). The flag will be set by the queue builder when a local-group match is made. - Adds a new system preference LocalHoldsPriorityExclusivityPeriod (Integer, default 0 = disabled) specifying the number of days from hold creation during which only locally-targeted items may fill a hold with a local queue target. - Provides an atomicupdate that guards both ALTERs with column_exists and INSERT IGNOREs the new syspref. Test plan: 1. Apply atomicupdate: perl installer/data/mysql/updatedatabase.pl 2. Verify both columns exist: SHOW COLUMNS FROM hold_fill_targets LIKE 'local%'; SHOW COLUMNS FROM tmp_holdsqueue LIKE 'local%'; 3. Verify syspref row: SELECT variable, value FROM systempreferences WHERE variable = 'LocalHoldsPriorityExclusivityPeriod'; 4. Confirm default value is 0 and type is Integer. Sponsored-by: Main Library Alliance <https://www.mainlib.org/> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #11 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197477 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197477&action=edit Bug 41410: DBIx::Class schema update Regenerated via `dbic --force` after adding the local_holdgroup_match column to hold_fill_targets and tmp_holdsqueue in the previous patch. Test plan: 1. Inspect Koha/Schema/Result/HoldFillTarget.pm and TmpHoldsqueue.pm and confirm the new local_holdgroup_match accessor is defined above the `DO NOT MODIFY` marker. 2. Confirm custom content below the marker (koha_object_class, +item_level_request is_boolean) is preserved. Sponsored-by: Main Library Alliance <https://www.mainlib.org/> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #12 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197478 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197478&action=edit Bug 41410: Add local holds priority exclusivity period When LocalHoldsPriority is enabled, the holds queue picks a local-group item for eligible holds. Until now there was nothing to reserve that priority at checkin time: if a non-local item was returned first, it would happily fill the hold and the local-priority decision was lost. This patch adds a time-bounded exclusivity window so that, for a configurable number of days after a hold is placed, a hold whose queue target is a local-group item will not be filled by a non-local item. Changes: - C4/HoldsQueue.pm: in MapItemsToHoldRequests, flag %item_map entries that matched on local library (GiveLibrary/GiveLibraryAndGroup) or local hold group (GiveLibraryGroup/GiveLibraryAndGroup) with local_holdgroup_match => 1, and propagate that into both the tmp_holdsqueue and hold_fill_targets INSERTs. - C4/Reserves.pm: in the CheckReserves loop, when LocalHoldsPriorityExclusivityPeriod is set, the hold is still within that window, and the item being evaluated is not itself a local match, skip the reserve if its hold_fill_targets row has local_holdgroup_match = 1. Missing hold_fill_targets row means "no information" -- fall through so holds are never trapped between queue runs. - circulation.pref: expose the new LocalHoldsPriorityExclusivityPeriod preference next to the existing LocalHoldsPriority* entries. The feature is a no-op unless both LocalHoldsPriority is set to something other than "Don't give" AND LocalHoldsPriorityExclusivityPeriod is > 0. Test plan: 1) Apply the patches and run the atomicupdate. 2) Set up a library group flagged as a local hold group containing two libraries (call them A and B). Add a third library C that is NOT in the group. 3) Add one item to each library (itemA, itemB, itemC) on the same biblio. 4) Administration -> System preferences -> Circulation: - Set LocalHoldsPriority to "Give library group". - Set LocalHoldsPriorityPatronControl to "home library". - Set LocalHoldsPriorityItemControl to "home library". - Set LocalHoldsPriorityExclusivityPeriod to 7. 5) As a patron whose home library is A, place a title-level hold with pickup at A. 6) Run the holds queue (misc/cronjobs/holds/build_holds_queue.pl). -> The queue should target itemA (or itemB) for this hold. -> Confirm in the database: SELECT reserve_id, itemnumber, local_holdgroup_match FROM hold_fill_targets; The targeted row must have local_holdgroup_match = 1. -> Holds to pull / holds queue report should also show the flag (tmp_holdsqueue.local_holdgroup_match = 1). 7) At library C, check in itemC (the non-local item). -> The hold must NOT be captured -- itemC simply goes back on the shelf. 8) At library A, check in itemA (the local item). -> The hold IS captured for the patron. 9) Cancel and re-place the hold, run the queue again. Manually age the hold past the window: UPDATE reserves SET reservedate = DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY) WHERE reserve_id = <id>; Now check in itemC again. -> The hold IS captured (exclusivity window has expired). 10) Re-place the hold but do NOT run the queue. With no hold_fill_targets row for the reserve, check in itemC. -> The hold IS captured (we never trap holds between queue runs). 11) Flip LocalHoldsPriorityExclusivityPeriod back to 0 and repeat step 7. -> The hold IS captured; the feature is fully disabled. 12) Run: prove t/db_dependent/Holds/LocalHoldsPriority.t \ t/db_dependent/HoldsQueue.t \ t/db_dependent/Reserves.t \ t/db_dependent/Koha/Hold.t -> All tests pass. Sponsored-by: Main Library Alliance <https://www.mainlib.org/> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #13 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197479 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197479&action=edit Bug 41410: Unit tests Covers the new LocalHoldsPriorityExclusivityPeriod behaviour and keeps existing tests working with the schema change: - t/db_dependent/Holds/LocalHoldsPriority.t: new subtest exercising all four cases -- pref disabled, pref active on a fresh hold, pref active past the window, and pref active with no hold_fill_targets row (queue hasn't run). - t/db_dependent/HoldsQueue.t: assert that after CreateQueue() with a local-group match, both tmp_holdsqueue and hold_fill_targets rows carry local_holdgroup_match = 1. - t/db_dependent/Reserves.t, t/db_dependent/Koha/Hold.t: qualify the two direct "INSERT INTO hold_fill_targets VALUES (...)" statements with explicit column names so they continue to work now that hold_fill_targets has one extra column. Test plan: prove t/db_dependent/Holds/LocalHoldsPriority.t \ t/db_dependent/HoldsQueue.t \ t/db_dependent/Reserves.t \ t/db_dependent/Koha/Hold.t All tests should pass. Sponsored-by: Main Library Alliance <https://www.mainlib.org/> -- You are receiving this mail because: You are watching all bug changes.
Circulation: LocalHoldsExclusivityPeriod, LocalHoldsExclusivityPatronControl, LocalHoldsExclusivityItemControl
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #14 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 197480 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=197480&action=edit Bug 41410: (follow-up) Decouple exclusivity from LocalHoldsPriority LocalHoldsExclusivity and LocalHoldsPriority are adjacent but distinct features: priority alters *which patron's hold* gets filled first, while exclusivity restricts *which items* may fill a hold during a time window. Each should be usable independently of the other. Changes: - Rename LocalHoldsPriorityExclusivityPeriod to LocalHoldsExclusivityPeriod - Add LocalHoldsExclusivityPatronControl (PickupLibrary/HomeLibrary) - Add LocalHoldsExclusivityItemControl (homebranch/holdingbranch) - HoldsQueue: add _flag_local_holdgroup_matches() that flags local_holdgroup_match on allocated items using hold-group matching and the new exclusivity control prefs, regardless of LocalHoldsPriority - Reserves: CheckReserves exclusivity check now computes its own "is this item local" using the new prefs and hold-group siblings, independent of the LocalHoldsPriority matching variables - Atomicupdate handles both fresh install and rename-from-old-pref paths - Pref UI note clarifies independence from LocalHoldsPriority Test plan: 1. Apply patch, run updatedatabase.pl 2. Verify three new sysprefs exist in Administration > System preferences 3. Set LocalHoldsPriority to "Don't give" (None) 4. Create a library hold group with at least two libraries (e.g. Lib-A, Lib-B) 5. Create a third library (Lib-C) NOT in the hold group 6. Create an item at Lib-B 7. Place a hold for a patron at Lib-A (pickup at Lib-A) 8. Set LocalHoldsExclusivityPeriod to 7, PatronControl to HomeLibrary, ItemControl to homebranch 9. Run the holds queue builder (misc/cronjobs/holds/build_holds_queue.pl) 10. Verify hold_fill_targets.local_holdgroup_match = 1 for that hold (item at Lib-B is in the same hold group as patron at Lib-A) 11. Check in the item at Lib-C — it should NOT fill the hold (exclusivity blocks the non-local item within the 7-day window) 12. Check in the item at Lib-B — it SHOULD fill the hold (local match) 13. Reset: delete the hold, create a new one with a patron at Lib-C (pickup at Lib-C). Run the queue again. 14. Verify hold_fill_targets.local_holdgroup_match = 0 for this hold 15. The item at Lib-B should now fill this hold at Lib-C checkin (non-local patron, no exclusivity protection) 16. Set LocalHoldsExclusivityPeriod to 0 — verify non-local items can fill holds normally regardless of hold_fill_targets flag 17. prove t/db_dependent/Holds/LocalHoldsPriority.t — passes 18. prove t/db_dependent/HoldsQueue.t — passes 19. prove t/db_dependent/Reserves.t — passes -- You are receiving this mail because: You are watching all bug changes.
Circulation: LocalHoldsExclusivityPeriod, LocalHoldsExclusivityPatronControl, LocalHoldsExclusivityItemControl
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #15 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Test plan: 1. Apply patch, run updatedatabase.pl 2. Verify three new sysprefs exist in Administration > System preferences 3. Set LocalHoldsPriority to "Don't give" (None) 4. Create a library hold group with at least two libraries (e.g. Lib-A, Lib-B) 5. Create a third library (Lib-C) NOT in the hold group 6. Create an item at Lib-B 7. Place a hold for a patron at Lib-A (pickup at Lib-A) 8. Set LocalHoldsExclusivityPeriod to 7, PatronControl to HomeLibrary, ItemControl to homebranch 9. Run the holds queue builder (misc/cronjobs/holds/build_holds_queue.pl) 10. Verify hold_fill_targets.local_holdgroup_match = 1 for that hold (item at Lib-B is in the same hold group as patron at Lib-A) 11. Check in the item at Lib-C — it should NOT fill the hold (exclusivity blocks the non-local item within the 7-day window) 12. Check in the item at Lib-B — it SHOULD fill the hold (local match) 13. Reset: delete the hold, create a new one with a patron at Lib-C (pickup at Lib-C). Run the queue again. 14. Verify hold_fill_targets.local_holdgroup_match = 0 for this hold 15. The item at Lib-B should now fill this hold at Lib-C checkin (non-local patron, no exclusivity protection) 16. Set LocalHoldsExclusivityPeriod to 0 — verify non-local items can fill holds normally regardless of hold_fill_targets flag 17. prove t/db_dependent/Holds/LocalHoldsPriority.t — passes 18. prove t/db_dependent/HoldsQueue.t — passes 19. prove t/db_dependent/Reserves.t — passes Extending the test plan a little to demonstrate more circumstances: * Holds will fill with any item when no local item is available* 20: Set LocalHoldsExclusivityPeriod back to 7 22: Create a 4th library, LIB-D, NOT in hold group 21: Have a bib with items from LIB-A (in hold group), LIB-C (not in hold group), LIB-D (not in hold group) 22: Check the LIB-A item out to some patron 23: Place a bib-level hold for a patron from LIB-A 24: run the queue 25: confirm the queue targets either the LIB-C or LIB-D items and is not flagged as a local_holdgroup_match in the db 26: confirm either the LIB-C or LIB-D item will fill the hold when checked in *Holds will fill with any item when reservedate is outside the exclusivity period* 27: cancel your hold 28: check in your LIB-A item (all items now available) 29: place a new bib-level hold for patron from LIB-A 30: run the queue, confirm it targets LIB-A item and flags it as a local_holdgroup_match in the db 31: in the database, update your hold to set reservedate to a date more than 7 days ago 32: run the queue again 33: confirm it still targets the LIB-A item but does not get flagged as a local_holdgroup_match 34: confirm your hold will capture the LIB-A, LIB-C, or LIB-D items -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42490 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #16 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- It's possible to have the holds queue target an item that does not match the conditions defined for Local Holds Exclusivity but nonetheless gets flagged as a local_holdgroup_match. When this happens, staff are told via the queue to pull an item that will not trigger the hold at checkin. To reproduce: - Set LocalHoldsExclusivity to match hold pickup and item holdingbranch - Set LocalHoldsPriority to match patron home to item home - Make a hold group containing Fairfield and Fairview - Have a bib with 1 item at Fairview (both home and holding) and 1 item at Midway (both home and holding) - Place a hold on your bib for Henry Acevedo (patron home Midway) for pickup at Fairfield - build holds queue LocalHoldsPriority tells the queue to target the Midway item. That target gets erroneously marked as a local holdgroup match. If I turn off LocalHoldsPriority and use the transport cost matrix to make Koha target the Midway item instead of the Fairview item, it does not get marked as a local holdgroup match. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|Small patch |Medium patch Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #197476|0 |1 is obsolete| | Attachment #197477|0 |1 is obsolete| | Attachment #197478|0 |1 is obsolete| | Attachment #197479|0 |1 is obsolete| | Attachment #197480|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #17 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 200242 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200242&action=edit Bug 41410: Add local_holdgroup_match column and exclusivity period syspref Adds groundwork for a time-bounded local holds exclusivity feature: - Adds a local_holdgroup_match flag (tinyint, default 0) to both hold_fill_targets (consulted by CheckReserves/_Findgroupreserve at checkin) and tmp_holdsqueue (so queue/pull-list reports can display it). The flag will be set by the queue builder when a local-group match is made. - Adds a new system preference LocalHoldsPriorityExclusivityPeriod (Integer, default 0 = disabled) specifying the number of days from hold creation during which only locally-targeted items may fill a hold with a local queue target. - Provides an atomicupdate that guards both ALTERs with column_exists and INSERT IGNOREs the new syspref. Test plan: 1. Apply atomicupdate: perl installer/data/mysql/updatedatabase.pl 2. Verify both columns exist: SHOW COLUMNS FROM hold_fill_targets LIKE 'local%'; SHOW COLUMNS FROM tmp_holdsqueue LIKE 'local%'; 3. Verify syspref row: SELECT variable, value FROM systempreferences WHERE variable = 'LocalHoldsPriorityExclusivityPeriod'; 4. Confirm default value is 0 and type is Integer. Sponsored-by: Main Library Alliance <https://www.mainlib.org/> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #18 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 200243 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200243&action=edit Bug 41410: DBIx::Class schema update Regenerated via `dbic --force` after adding the local_holdgroup_match column to hold_fill_targets and tmp_holdsqueue in the previous patch. Test plan: 1. Inspect Koha/Schema/Result/HoldFillTarget.pm and TmpHoldsqueue.pm and confirm the new local_holdgroup_match accessor is defined above the `DO NOT MODIFY` marker. 2. Confirm custom content below the marker (koha_object_class, +item_level_request is_boolean) is preserved. Sponsored-by: Main Library Alliance <https://www.mainlib.org/> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #19 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 200244 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200244&action=edit Bug 41410: Add local holds priority exclusivity period When LocalHoldsPriority is enabled, the holds queue picks a local-group item for eligible holds. Until now there was nothing to reserve that priority at checkin time: if a non-local item was returned first, it would happily fill the hold and the local-priority decision was lost. This patch adds a time-bounded exclusivity window so that, for a configurable number of days after a hold is placed, a hold whose queue target is a local-group item will not be filled by a non-local item. Changes: - C4/HoldsQueue.pm: in MapItemsToHoldRequests, flag %item_map entries that matched on local library (GiveLibrary/GiveLibraryAndGroup) or local hold group (GiveLibraryGroup/GiveLibraryAndGroup) with local_holdgroup_match => 1, and propagate that into both the tmp_holdsqueue and hold_fill_targets INSERTs. - C4/Reserves.pm: in the CheckReserves loop, when LocalHoldsPriorityExclusivityPeriod is set, the hold is still within that window, and the item being evaluated is not itself a local match, skip the reserve if its hold_fill_targets row has local_holdgroup_match = 1. Missing hold_fill_targets row means "no information" -- fall through so holds are never trapped between queue runs. - circulation.pref: expose the new LocalHoldsPriorityExclusivityPeriod preference next to the existing LocalHoldsPriority* entries. The feature is a no-op unless both LocalHoldsPriority is set to something other than "Don't give" AND LocalHoldsPriorityExclusivityPeriod is > 0. Test plan: 1) Apply the patches and run the atomicupdate. 2) Set up a library group flagged as a local hold group containing two libraries (call them A and B). Add a third library C that is NOT in the group. 3) Add one item to each library (itemA, itemB, itemC) on the same biblio. 4) Administration -> System preferences -> Circulation: - Set LocalHoldsPriority to "Give library group". - Set LocalHoldsPriorityPatronControl to "home library". - Set LocalHoldsPriorityItemControl to "home library". - Set LocalHoldsPriorityExclusivityPeriod to 7. 5) As a patron whose home library is A, place a title-level hold with pickup at A. 6) Run the holds queue (misc/cronjobs/holds/build_holds_queue.pl). -> The queue should target itemA (or itemB) for this hold. -> Confirm in the database: SELECT reserve_id, itemnumber, local_holdgroup_match FROM hold_fill_targets; The targeted row must have local_holdgroup_match = 1. -> Holds to pull / holds queue report should also show the flag (tmp_holdsqueue.local_holdgroup_match = 1). 7) At library C, check in itemC (the non-local item). -> The hold must NOT be captured -- itemC simply goes back on the shelf. 8) At library A, check in itemA (the local item). -> The hold IS captured for the patron. 9) Cancel and re-place the hold, run the queue again. Manually age the hold past the window: UPDATE reserves SET reservedate = DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY) WHERE reserve_id = <id>; Now check in itemC again. -> The hold IS captured (exclusivity window has expired). 10) Re-place the hold but do NOT run the queue. With no hold_fill_targets row for the reserve, check in itemC. -> The hold IS captured (we never trap holds between queue runs). 11) Flip LocalHoldsPriorityExclusivityPeriod back to 0 and repeat step 7. -> The hold IS captured; the feature is fully disabled. 12) Run: prove t/db_dependent/Holds/LocalHoldsPriority.t \ t/db_dependent/HoldsQueue.t \ t/db_dependent/Reserves.t \ t/db_dependent/Koha/Hold.t -> All tests pass. Sponsored-by: Main Library Alliance <https://www.mainlib.org/> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #20 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 200245 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200245&action=edit Bug 41410: Unit tests Covers the new LocalHoldsPriorityExclusivityPeriod behaviour and keeps existing tests working with the schema change: - t/db_dependent/Holds/LocalHoldsPriority.t: new subtest exercising all four cases -- pref disabled, pref active on a fresh hold, pref active past the window, and pref active with no hold_fill_targets row (queue hasn't run). - t/db_dependent/HoldsQueue.t: assert that after CreateQueue() with a local-group match, both tmp_holdsqueue and hold_fill_targets rows carry local_holdgroup_match = 1. - t/db_dependent/Reserves.t, t/db_dependent/Koha/Hold.t: qualify the two direct "INSERT INTO hold_fill_targets VALUES (...)" statements with explicit column names so they continue to work now that hold_fill_targets has one extra column. Test plan: prove t/db_dependent/Holds/LocalHoldsPriority.t \ t/db_dependent/HoldsQueue.t \ t/db_dependent/Reserves.t \ t/db_dependent/Koha/Hold.t All tests should pass. Sponsored-by: Main Library Alliance <https://www.mainlib.org/> -- You are receiving this mail because: You are watching all bug changes.
Circulation: LocalHoldsExclusivityPeriod, LocalHoldsExclusivityPatronControl, LocalHoldsExclusivityItemControl
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #21 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 200246 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200246&action=edit Bug 41410: (follow-up) Decouple exclusivity from LocalHoldsPriority LocalHoldsExclusivity and LocalHoldsPriority are adjacent but distinct features: priority alters *which patron's hold* gets filled first, while exclusivity restricts *which items* may fill a hold during a time window. Each should be usable independently of the other. Changes: - Rename LocalHoldsPriorityExclusivityPeriod to LocalHoldsExclusivityPeriod - Add LocalHoldsExclusivityPatronControl (PickupLibrary/HomeLibrary) - Add LocalHoldsExclusivityItemControl (homebranch/holdingbranch) - HoldsQueue: add _flag_local_holdgroup_matches() that flags local_holdgroup_match on allocated items using hold-group matching and the new exclusivity control prefs, regardless of LocalHoldsPriority - Reserves: CheckReserves exclusivity check now computes its own "is this item local" using the new prefs and hold-group siblings, independent of the LocalHoldsPriority matching variables - Atomicupdate handles both fresh install and rename-from-old-pref paths - Pref UI note clarifies independence from LocalHoldsPriority Test plan: 1. Apply patch, run updatedatabase.pl 2. Verify three new sysprefs exist in Administration > System preferences 3. Set LocalHoldsPriority to "Don't give" (None) 4. Create a library hold group with at least two libraries (e.g. Lib-A, Lib-B) 5. Create a third library (Lib-C) NOT in the hold group 6. Create an item at Lib-B 7. Place a hold for a patron at Lib-A (pickup at Lib-A) 8. Set LocalHoldsExclusivityPeriod to 7, PatronControl to HomeLibrary, ItemControl to homebranch 9. Run the holds queue builder (misc/cronjobs/holds/build_holds_queue.pl) 10. Verify hold_fill_targets.local_holdgroup_match = 1 for that hold (item at Lib-B is in the same hold group as patron at Lib-A) 11. Check in the item at Lib-C — it should NOT fill the hold (exclusivity blocks the non-local item within the 7-day window) 12. Check in the item at Lib-B — it SHOULD fill the hold (local match) 13. Reset: delete the hold, create a new one with a patron at Lib-C (pickup at Lib-C). Run the queue again. 14. Verify hold_fill_targets.local_holdgroup_match = 0 for this hold 15. The item at Lib-B should now fill this hold at Lib-C checkin (non-local patron, no exclusivity protection) 16. Set LocalHoldsExclusivityPeriod to 0 — verify non-local items can fill holds normally regardless of hold_fill_targets flag 17. prove t/db_dependent/Holds/LocalHoldsPriority.t — passes 18. prove t/db_dependent/HoldsQueue.t — passes 19. prove t/db_dependent/Reserves.t — passes -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #22 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 200247 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200247&action=edit Bug 41410: (follow-up) Fix local_holdgroup_match set incorrectly by LocalHoldsPriority local_holdgroup_match was being hardcoded to 1 in the two LocalHoldsPriority allocation paths (GiveLibrary and GiveLibraryGroup), regardless of whether the chosen item actually satisfied the LocalHoldsExclusivity conditions. This caused staff to be directed to pull an item that would not trigger the hold at checkin when the two features used different patron/item controls. The fix removes the premature local_holdgroup_match => 1 from both LHP paths and lets _flag_local_holdgroup_matches evaluate all allocated items using the correct LocalHoldsExclusivity* sysprefs. Also fixes a pre-existing missing bind-variable placeholder in the INSERT INTO tmp_holdsqueue statement (17 columns, only 16 ?). Test updates: - Existing local_holdgroup_match test gains the matching LocalHoldsExclusivity sysprefs so the flag is set via the correct code path. - New subtest reproduces the reported bug: LHP (HomeLibrary/homebranch) targets a non-local item while exclusivity (PickupLibrary/holdingbranch) should not flag it — confirms local_holdgroup_match is 0 after the fix. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #200242|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #200243|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #200244|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #200245|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #200246|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #200247|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #23 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 200339 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200339&action=edit Bug 41410: Add local_holdgroup_match column and exclusivity period syspref Adds groundwork for a time-bounded local holds exclusivity feature: - Adds a local_holdgroup_match flag (tinyint, default 0) to both hold_fill_targets (consulted by CheckReserves/_Findgroupreserve at checkin) and tmp_holdsqueue (so queue/pull-list reports can display it). The flag will be set by the queue builder when a local-group match is made. - Adds a new system preference LocalHoldsPriorityExclusivityPeriod (Integer, default 0 = disabled) specifying the number of days from hold creation during which only locally-targeted items may fill a hold with a local queue target. - Provides an atomicupdate that guards both ALTERs with column_exists and INSERT IGNOREs the new syspref. Test plan: 1. Apply atomicupdate: perl installer/data/mysql/updatedatabase.pl 2. Verify both columns exist: SHOW COLUMNS FROM hold_fill_targets LIKE 'local%'; SHOW COLUMNS FROM tmp_holdsqueue LIKE 'local%'; 3. Verify syspref row: SELECT variable, value FROM systempreferences WHERE variable = 'LocalHoldsPriorityExclusivityPeriod'; 4. Confirm default value is 0 and type is Integer. Sponsored-by: Main Library Alliance <https://www.mainlib.org/> Signed-off-by: Trevor Diamond <trevor.diamond@mainlib.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #24 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 200340 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200340&action=edit Bug 41410: DBIx::Class schema update Regenerated via `dbic --force` after adding the local_holdgroup_match column to hold_fill_targets and tmp_holdsqueue in the previous patch. Test plan: 1. Inspect Koha/Schema/Result/HoldFillTarget.pm and TmpHoldsqueue.pm and confirm the new local_holdgroup_match accessor is defined above the `DO NOT MODIFY` marker. 2. Confirm custom content below the marker (koha_object_class, +item_level_request is_boolean) is preserved. Sponsored-by: Main Library Alliance <https://www.mainlib.org/> Signed-off-by: Trevor Diamond <trevor.diamond@mainlib.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #25 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 200341 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200341&action=edit Bug 41410: Add local holds priority exclusivity period When LocalHoldsPriority is enabled, the holds queue picks a local-group item for eligible holds. Until now there was nothing to reserve that priority at checkin time: if a non-local item was returned first, it would happily fill the hold and the local-priority decision was lost. This patch adds a time-bounded exclusivity window so that, for a configurable number of days after a hold is placed, a hold whose queue target is a local-group item will not be filled by a non-local item. Changes: - C4/HoldsQueue.pm: in MapItemsToHoldRequests, flag %item_map entries that matched on local library (GiveLibrary/GiveLibraryAndGroup) or local hold group (GiveLibraryGroup/GiveLibraryAndGroup) with local_holdgroup_match => 1, and propagate that into both the tmp_holdsqueue and hold_fill_targets INSERTs. - C4/Reserves.pm: in the CheckReserves loop, when LocalHoldsPriorityExclusivityPeriod is set, the hold is still within that window, and the item being evaluated is not itself a local match, skip the reserve if its hold_fill_targets row has local_holdgroup_match = 1. Missing hold_fill_targets row means "no information" -- fall through so holds are never trapped between queue runs. - circulation.pref: expose the new LocalHoldsPriorityExclusivityPeriod preference next to the existing LocalHoldsPriority* entries. The feature is a no-op unless both LocalHoldsPriority is set to something other than "Don't give" AND LocalHoldsPriorityExclusivityPeriod is > 0. Test plan: 1) Apply the patches and run the atomicupdate. 2) Set up a library group flagged as a local hold group containing two libraries (call them A and B). Add a third library C that is NOT in the group. 3) Add one item to each library (itemA, itemB, itemC) on the same biblio. 4) Administration -> System preferences -> Circulation: - Set LocalHoldsPriority to "Give library group". - Set LocalHoldsPriorityPatronControl to "home library". - Set LocalHoldsPriorityItemControl to "home library". - Set LocalHoldsPriorityExclusivityPeriod to 7. 5) As a patron whose home library is A, place a title-level hold with pickup at A. 6) Run the holds queue (misc/cronjobs/holds/build_holds_queue.pl). -> The queue should target itemA (or itemB) for this hold. -> Confirm in the database: SELECT reserve_id, itemnumber, local_holdgroup_match FROM hold_fill_targets; The targeted row must have local_holdgroup_match = 1. -> Holds to pull / holds queue report should also show the flag (tmp_holdsqueue.local_holdgroup_match = 1). 7) At library C, check in itemC (the non-local item). -> The hold must NOT be captured -- itemC simply goes back on the shelf. 8) At library A, check in itemA (the local item). -> The hold IS captured for the patron. 9) Cancel and re-place the hold, run the queue again. Manually age the hold past the window: UPDATE reserves SET reservedate = DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY) WHERE reserve_id = <id>; Now check in itemC again. -> The hold IS captured (exclusivity window has expired). 10) Re-place the hold but do NOT run the queue. With no hold_fill_targets row for the reserve, check in itemC. -> The hold IS captured (we never trap holds between queue runs). 11) Flip LocalHoldsPriorityExclusivityPeriod back to 0 and repeat step 7. -> The hold IS captured; the feature is fully disabled. 12) Run: prove t/db_dependent/Holds/LocalHoldsPriority.t \ t/db_dependent/HoldsQueue.t \ t/db_dependent/Reserves.t \ t/db_dependent/Koha/Hold.t -> All tests pass. Sponsored-by: Main Library Alliance <https://www.mainlib.org/> Signed-off-by: Trevor Diamond <trevor.diamond@mainlib.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #26 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 200342 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200342&action=edit Bug 41410: Unit tests Covers the new LocalHoldsPriorityExclusivityPeriod behaviour and keeps existing tests working with the schema change: - t/db_dependent/Holds/LocalHoldsPriority.t: new subtest exercising all four cases -- pref disabled, pref active on a fresh hold, pref active past the window, and pref active with no hold_fill_targets row (queue hasn't run). - t/db_dependent/HoldsQueue.t: assert that after CreateQueue() with a local-group match, both tmp_holdsqueue and hold_fill_targets rows carry local_holdgroup_match = 1. - t/db_dependent/Reserves.t, t/db_dependent/Koha/Hold.t: qualify the two direct "INSERT INTO hold_fill_targets VALUES (...)" statements with explicit column names so they continue to work now that hold_fill_targets has one extra column. Test plan: prove t/db_dependent/Holds/LocalHoldsPriority.t \ t/db_dependent/HoldsQueue.t \ t/db_dependent/Reserves.t \ t/db_dependent/Koha/Hold.t All tests should pass. Sponsored-by: Main Library Alliance <https://www.mainlib.org/> Signed-off-by: Trevor Diamond <trevor.diamond@mainlib.org> -- You are receiving this mail because: You are watching all bug changes.
Circulation: LocalHoldsExclusivityPeriod, LocalHoldsExclusivityPatronControl, LocalHoldsExclusivityItemControl
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #27 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 200343 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200343&action=edit Bug 41410: (follow-up) Decouple exclusivity from LocalHoldsPriority LocalHoldsExclusivity and LocalHoldsPriority are adjacent but distinct features: priority alters *which patron's hold* gets filled first, while exclusivity restricts *which items* may fill a hold during a time window. Each should be usable independently of the other. Changes: - Rename LocalHoldsPriorityExclusivityPeriod to LocalHoldsExclusivityPeriod - Add LocalHoldsExclusivityPatronControl (PickupLibrary/HomeLibrary) - Add LocalHoldsExclusivityItemControl (homebranch/holdingbranch) - HoldsQueue: add _flag_local_holdgroup_matches() that flags local_holdgroup_match on allocated items using hold-group matching and the new exclusivity control prefs, regardless of LocalHoldsPriority - Reserves: CheckReserves exclusivity check now computes its own "is this item local" using the new prefs and hold-group siblings, independent of the LocalHoldsPriority matching variables - Atomicupdate handles both fresh install and rename-from-old-pref paths - Pref UI note clarifies independence from LocalHoldsPriority Test plan: 1. Apply patch, run updatedatabase.pl 2. Verify three new sysprefs exist in Administration > System preferences 3. Set LocalHoldsPriority to "Don't give" (None) 4. Create a library hold group with at least two libraries (e.g. Lib-A, Lib-B) 5. Create a third library (Lib-C) NOT in the hold group 6. Create an item at Lib-B 7. Place a hold for a patron at Lib-A (pickup at Lib-A) 8. Set LocalHoldsExclusivityPeriod to 7, PatronControl to HomeLibrary, ItemControl to homebranch 9. Run the holds queue builder (misc/cronjobs/holds/build_holds_queue.pl) 10. Verify hold_fill_targets.local_holdgroup_match = 1 for that hold (item at Lib-B is in the same hold group as patron at Lib-A) 11. Check in the item at Lib-C — it should NOT fill the hold (exclusivity blocks the non-local item within the 7-day window) 12. Check in the item at Lib-B — it SHOULD fill the hold (local match) 13. Reset: delete the hold, create a new one with a patron at Lib-C (pickup at Lib-C). Run the queue again. 14. Verify hold_fill_targets.local_holdgroup_match = 0 for this hold 15. The item at Lib-B should now fill this hold at Lib-C checkin (non-local patron, no exclusivity protection) 16. Set LocalHoldsExclusivityPeriod to 0 — verify non-local items can fill holds normally regardless of hold_fill_targets flag 17. prove t/db_dependent/Holds/LocalHoldsPriority.t — passes 18. prove t/db_dependent/HoldsQueue.t — passes 19. prove t/db_dependent/Reserves.t — passes Signed-off-by: Trevor Diamond <trevor.diamond@mainlib.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #28 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 200344 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200344&action=edit Bug 41410: (follow-up) Fix local_holdgroup_match set incorrectly by LocalHoldsPriority local_holdgroup_match was being hardcoded to 1 in the two LocalHoldsPriority allocation paths (GiveLibrary and GiveLibraryGroup), regardless of whether the chosen item actually satisfied the LocalHoldsExclusivity conditions. This caused staff to be directed to pull an item that would not trigger the hold at checkin when the two features used different patron/item controls. The fix removes the premature local_holdgroup_match => 1 from both LHP paths and lets _flag_local_holdgroup_matches evaluate all allocated items using the correct LocalHoldsExclusivity* sysprefs. Also fixes a pre-existing missing bind-variable placeholder in the INSERT INTO tmp_holdsqueue statement (17 columns, only 16 ?). Test updates: - Existing local_holdgroup_match test gains the matching LocalHoldsExclusivity sysprefs so the flag is set via the correct code path. - New subtest reproduces the reported bug: LHP (HomeLibrary/homebranch) targets a non-local item while exclusivity (PickupLibrary/holdingbranch) should not flag it — confirms local_holdgroup_match is 0 after the fix. Signed-off-by: Trevor Diamond <trevor.diamond@mainlib.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #200339|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #200340|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #200341|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #200342|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #200343|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #200344|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #29 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 200345 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200345&action=edit Bug 41410: Add local_holdgroup_match column and exclusivity period syspref Adds groundwork for a time-bounded local holds exclusivity feature: - Adds a local_holdgroup_match flag (tinyint, default 0) to both hold_fill_targets (consulted by CheckReserves/_Findgroupreserve at checkin) and tmp_holdsqueue (so queue/pull-list reports can display it). The flag will be set by the queue builder when a local-group match is made. - Adds a new system preference LocalHoldsPriorityExclusivityPeriod (Integer, default 0 = disabled) specifying the number of days from hold creation during which only locally-targeted items may fill a hold with a local queue target. - Provides an atomicupdate that guards both ALTERs with column_exists and INSERT IGNOREs the new syspref. Test plan: 1. Apply atomicupdate: perl installer/data/mysql/updatedatabase.pl 2. Verify both columns exist: SHOW COLUMNS FROM hold_fill_targets LIKE 'local%'; SHOW COLUMNS FROM tmp_holdsqueue LIKE 'local%'; 3. Verify syspref row: SELECT variable, value FROM systempreferences WHERE variable = 'LocalHoldsPriorityExclusivityPeriod'; 4. Confirm default value is 0 and type is Integer. Sponsored-by: Main Library Alliance <https://www.mainlib.org/> Signed-off-by: Trevor Diamond <trevor.diamond@mainlib.org> Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #30 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 200346 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200346&action=edit Bug 41410: DBIx::Class schema update Regenerated via `dbic --force` after adding the local_holdgroup_match column to hold_fill_targets and tmp_holdsqueue in the previous patch. Test plan: 1. Inspect Koha/Schema/Result/HoldFillTarget.pm and TmpHoldsqueue.pm and confirm the new local_holdgroup_match accessor is defined above the `DO NOT MODIFY` marker. 2. Confirm custom content below the marker (koha_object_class, +item_level_request is_boolean) is preserved. Sponsored-by: Main Library Alliance <https://www.mainlib.org/> Signed-off-by: Trevor Diamond <trevor.diamond@mainlib.org> Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #31 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 200347 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200347&action=edit Bug 41410: Add local holds priority exclusivity period When LocalHoldsPriority is enabled, the holds queue picks a local-group item for eligible holds. Until now there was nothing to reserve that priority at checkin time: if a non-local item was returned first, it would happily fill the hold and the local-priority decision was lost. This patch adds a time-bounded exclusivity window so that, for a configurable number of days after a hold is placed, a hold whose queue target is a local-group item will not be filled by a non-local item. Changes: - C4/HoldsQueue.pm: in MapItemsToHoldRequests, flag %item_map entries that matched on local library (GiveLibrary/GiveLibraryAndGroup) or local hold group (GiveLibraryGroup/GiveLibraryAndGroup) with local_holdgroup_match => 1, and propagate that into both the tmp_holdsqueue and hold_fill_targets INSERTs. - C4/Reserves.pm: in the CheckReserves loop, when LocalHoldsPriorityExclusivityPeriod is set, the hold is still within that window, and the item being evaluated is not itself a local match, skip the reserve if its hold_fill_targets row has local_holdgroup_match = 1. Missing hold_fill_targets row means "no information" -- fall through so holds are never trapped between queue runs. - circulation.pref: expose the new LocalHoldsPriorityExclusivityPeriod preference next to the existing LocalHoldsPriority* entries. The feature is a no-op unless both LocalHoldsPriority is set to something other than "Don't give" AND LocalHoldsPriorityExclusivityPeriod is > 0. Test plan: 1) Apply the patches and run the atomicupdate. 2) Set up a library group flagged as a local hold group containing two libraries (call them A and B). Add a third library C that is NOT in the group. 3) Add one item to each library (itemA, itemB, itemC) on the same biblio. 4) Administration -> System preferences -> Circulation: - Set LocalHoldsPriority to "Give library group". - Set LocalHoldsPriorityPatronControl to "home library". - Set LocalHoldsPriorityItemControl to "home library". - Set LocalHoldsPriorityExclusivityPeriod to 7. 5) As a patron whose home library is A, place a title-level hold with pickup at A. 6) Run the holds queue (misc/cronjobs/holds/build_holds_queue.pl). -> The queue should target itemA (or itemB) for this hold. -> Confirm in the database: SELECT reserve_id, itemnumber, local_holdgroup_match FROM hold_fill_targets; The targeted row must have local_holdgroup_match = 1. -> Holds to pull / holds queue report should also show the flag (tmp_holdsqueue.local_holdgroup_match = 1). 7) At library C, check in itemC (the non-local item). -> The hold must NOT be captured -- itemC simply goes back on the shelf. 8) At library A, check in itemA (the local item). -> The hold IS captured for the patron. 9) Cancel and re-place the hold, run the queue again. Manually age the hold past the window: UPDATE reserves SET reservedate = DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY) WHERE reserve_id = <id>; Now check in itemC again. -> The hold IS captured (exclusivity window has expired). 10) Re-place the hold but do NOT run the queue. With no hold_fill_targets row for the reserve, check in itemC. -> The hold IS captured (we never trap holds between queue runs). 11) Flip LocalHoldsPriorityExclusivityPeriod back to 0 and repeat step 7. -> The hold IS captured; the feature is fully disabled. 12) Run: prove t/db_dependent/Holds/LocalHoldsPriority.t \ t/db_dependent/HoldsQueue.t \ t/db_dependent/Reserves.t \ t/db_dependent/Koha/Hold.t -> All tests pass. Sponsored-by: Main Library Alliance <https://www.mainlib.org/> Signed-off-by: Trevor Diamond <trevor.diamond@mainlib.org> Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #32 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 200349 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200349&action=edit Bug 41410: Unit tests Covers the new LocalHoldsPriorityExclusivityPeriod behaviour and keeps existing tests working with the schema change: - t/db_dependent/Holds/LocalHoldsPriority.t: new subtest exercising all four cases -- pref disabled, pref active on a fresh hold, pref active past the window, and pref active with no hold_fill_targets row (queue hasn't run). - t/db_dependent/HoldsQueue.t: assert that after CreateQueue() with a local-group match, both tmp_holdsqueue and hold_fill_targets rows carry local_holdgroup_match = 1. - t/db_dependent/Reserves.t, t/db_dependent/Koha/Hold.t: qualify the two direct "INSERT INTO hold_fill_targets VALUES (...)" statements with explicit column names so they continue to work now that hold_fill_targets has one extra column. Test plan: prove t/db_dependent/Holds/LocalHoldsPriority.t \ t/db_dependent/HoldsQueue.t \ t/db_dependent/Reserves.t \ t/db_dependent/Koha/Hold.t All tests should pass. Sponsored-by: Main Library Alliance <https://www.mainlib.org/> Signed-off-by: Trevor Diamond <trevor.diamond@mainlib.org> Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
Circulation: LocalHoldsExclusivityPeriod, LocalHoldsExclusivityPatronControl, LocalHoldsExclusivityItemControl
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #33 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 200351 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200351&action=edit Bug 41410: (follow-up) Decouple exclusivity from LocalHoldsPriority LocalHoldsExclusivity and LocalHoldsPriority are adjacent but distinct features: priority alters *which patron's hold* gets filled first, while exclusivity restricts *which items* may fill a hold during a time window. Each should be usable independently of the other. Changes: - Rename LocalHoldsPriorityExclusivityPeriod to LocalHoldsExclusivityPeriod - Add LocalHoldsExclusivityPatronControl (PickupLibrary/HomeLibrary) - Add LocalHoldsExclusivityItemControl (homebranch/holdingbranch) - HoldsQueue: add _flag_local_holdgroup_matches() that flags local_holdgroup_match on allocated items using hold-group matching and the new exclusivity control prefs, regardless of LocalHoldsPriority - Reserves: CheckReserves exclusivity check now computes its own "is this item local" using the new prefs and hold-group siblings, independent of the LocalHoldsPriority matching variables - Atomicupdate handles both fresh install and rename-from-old-pref paths - Pref UI note clarifies independence from LocalHoldsPriority Test plan: 1. Apply patch, run updatedatabase.pl 2. Verify three new sysprefs exist in Administration > System preferences 3. Set LocalHoldsPriority to "Don't give" (None) 4. Create a library hold group with at least two libraries (e.g. Lib-A, Lib-B) 5. Create a third library (Lib-C) NOT in the hold group 6. Create an item at Lib-B 7. Place a hold for a patron at Lib-A (pickup at Lib-A) 8. Set LocalHoldsExclusivityPeriod to 7, PatronControl to HomeLibrary, ItemControl to homebranch 9. Run the holds queue builder (misc/cronjobs/holds/build_holds_queue.pl) 10. Verify hold_fill_targets.local_holdgroup_match = 1 for that hold (item at Lib-B is in the same hold group as patron at Lib-A) 11. Check in the item at Lib-C — it should NOT fill the hold (exclusivity blocks the non-local item within the 7-day window) 12. Check in the item at Lib-B — it SHOULD fill the hold (local match) 13. Reset: delete the hold, create a new one with a patron at Lib-C (pickup at Lib-C). Run the queue again. 14. Verify hold_fill_targets.local_holdgroup_match = 0 for this hold 15. The item at Lib-B should now fill this hold at Lib-C checkin (non-local patron, no exclusivity protection) 16. Set LocalHoldsExclusivityPeriod to 0 — verify non-local items can fill holds normally regardless of hold_fill_targets flag 17. prove t/db_dependent/Holds/LocalHoldsPriority.t — passes 18. prove t/db_dependent/HoldsQueue.t — passes 19. prove t/db_dependent/Reserves.t — passes Signed-off-by: Trevor Diamond <trevor.diamond@mainlib.org> Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #34 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 200353 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=200353&action=edit Bug 41410: (follow-up) Fix local_holdgroup_match set incorrectly by LocalHoldsPriority local_holdgroup_match was being hardcoded to 1 in the two LocalHoldsPriority allocation paths (GiveLibrary and GiveLibraryGroup), regardless of whether the chosen item actually satisfied the LocalHoldsExclusivity conditions. This caused staff to be directed to pull an item that would not trigger the hold at checkin when the two features used different patron/item controls. The fix removes the premature local_holdgroup_match => 1 from both LHP paths and lets _flag_local_holdgroup_matches evaluate all allocated items using the correct LocalHoldsExclusivity* sysprefs. Also fixes a pre-existing missing bind-variable placeholder in the INSERT INTO tmp_holdsqueue statement (17 columns, only 16 ?). Test updates: - Existing local_holdgroup_match test gains the matching LocalHoldsExclusivity sysprefs so the flag is set via the correct code path. - New subtest reproduces the reported bug: LHP (HomeLibrary/homebranch) targets a non-local item while exclusivity (PickupLibrary/holdingbranch) should not flag it — confirms local_holdgroup_match is 0 after the fix. Signed-off-by: Trevor Diamond <trevor.diamond@mainlib.org> Sponsored-by: Main Library Alliance <https://www.mainlib.org/> Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |andrew@bywatersolutions.com |y.org | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pedro.amorim@openfifth.co.u | |k Severity|normal |new feature --- Comment #35 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Hi guys this is a new feature, correct? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41410 --- Comment #36 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- (In reply to Pedro Amorim (ammopt) from comment #35)
Hi guys this is a new feature, correct?
Yes, thanks! -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org