Bug 20747 - Allow LocalHoldsPriority to fill by hierarchical groups system rather than individual library
Summary: Allow LocalHoldsPriority to fill by hierarchical groups system rather than in...
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement with 5 votes (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 11126 16735
Blocks:
  Show dependency treegraph
 
Reported: 2018-05-09 16:36 UTC by Lisette Scheer
Modified: 2024-02-01 19:50 UTC (History)
9 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lisette Scheer 2018-05-09 16:36:51 UTC
It would be great if the LocalHoldsPriority could be used within a district in a consortium. 


>>Christopher expressed concern, adding on “grouping” – some libraries may not >>want to be effected.  Typically this is all or nothing or on or off.  Example, >>the circulation of Mobile Hotspots; hotspots are popular outside of CDA but CDA >>patrons get priority, Rathdrum is pushed down.  Consider an “Item type” or “Item >>level” opt out which would be similar to how suppression works.  If the >>modification increased features and flexibility, there may be more interest from >>the larger group in supporting the enhancement.  Group structure for settings, a >>hierarchy based system, and refinement is needed.
Comment 1 Tomás Cohen Arazi 2019-03-02 13:08:50 UTC
Lisette, could you please explain a bit further?
Also, can you take a look  at bug 22284 and see how it fits?
Comment 2 Lisette Scheer 2019-03-05 15:29:36 UTC
LocalHoldsPriority currently looks only at home library.
We would like if it could look at groups and look first at the whole group then outside the group for priority. 
Example: MOS and TRO are in group together and LAP is not in the same group. 
MOS has the only copy of a new book and the holds are:
1. MOS patron
2. LAP patron1
3. LAP patron2
4. TRO patron

We would like it to fill:
1. MOS Patron
2. TRO Patron
3. LAP patron1
4. LAP patron2 

Assuming no additional holds were place by MOS or TRO patrons before it got to LAP. 

Another Example might be if LAP also had a copy but the order of holds was:
1. MOS patron
2. LAP patron1
3. TRO patron
4. LAP patron2

The 2 copies could bounce around between the 3 branches taking extra courier time (LAP to TRO has to take 3 different courier routes, LAP to MOS 2) but with what we would like, the MOS copy would fill for MOS and then TRO (1 courier route) then go out to the consortium and the LAP one could stay in LAP (or its group) before going out to the consortium, potentially cutting down wait time for branches where their group has purchased copies. 


I may have it wrong, but it looks like bug 22284 would prevent the holds from going out of the groups? That isn't what we would want, as we still want our items to be able to go out of the district once holds for our district have been filled.
Comment 3 Joy Nelson 2019-03-26 14:42:26 UTC
Lisette-
The way that Bug 22284 would work includes functionality for 'non local/group' holds to be filled after all the local holds have been satisfied.

joy

> I may have it wrong, but it looks like bug 22284 would prevent the holds
> from going out of the groups? That isn't what we would want, as we still
> want our items to be able to go out of the district once holds for our
> district have been filled.
Comment 4 Lisette Scheer 2019-03-26 19:52:13 UTC
Joy, 
In that case, it looks like bug 22284 would work for our purposes here at Valnet. Thanks for the clarification! 
Lisette 
(In reply to Joy Nelson from comment #3)


> Lisette-
> The way that Bug 22284 would work includes functionality for 'non
> local/group' holds to be filled after all the local holds have been
> satisfied.
> 
> joy
Comment 5 Tomás Cohen Arazi 2019-04-15 23:05:07 UTC

*** This bug has been marked as a duplicate of bug 22284 ***
Comment 6 Lisette Scheer 2021-12-21 17:53:27 UTC
But 22284 did not fix this issue. 

It only limited completely to the group, rather than prioritizing the group and then going out of the group, similarly to Bug 12004 but to allow just group prioritization and not branch prioritization. 

The reason that using just the transportation cost matrix doesn't just do this has to do with when an item is already checked out and returned, it'll send the item far away and then when the copy for the far away branch comes in, it gets routed up to us. 

Lisette
Comment 7 Michelle Spinney 2023-07-27 13:55:29 UTC
This is really important for consortia, or any network with branches. We need this for our network as we have 2 islands that use their own intra-island delivery as well as our state delivery service. Not having this ability has caused a lot of issues during our busy summer tourist season. The transport cost matrix has been no help.
Comment 8 Eileen Chandler 2023-07-27 15:53:03 UTC
CLAMS wants 
1. individual library
2. Hierarchical group
3. larger group.
We don't want to cut out the individual library as the first choice. 
New bug perhaps? 
Cutting out the individual library and preferring a group as the first option will not work for us.