Summary: | Holds to pull should show item level holds only if available | ||
---|---|---|---|
Product: | Koha | Reporter: | Minna Kivinen <minna.kivinen> |
Component: | Hold requests | Assignee: | Bugs List <koha-bugs> |
Status: | RESOLVED DUPLICATE | QA Contact: | Testopia <testopia> |
Severity: | normal | ||
Priority: | P5 - low | CC: | andrew, gmcharlt |
Version: | 21.05 | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: | |||
Bug Depends on: | 29148 | ||
Bug Blocks: | |||
Attachments: | Bug 29161: POC |
Description
Minna Kivinen
2021-10-04 05:34:40 UTC
Changing this from Enhancement to Normal, as it is legitimately a bug rather than an enhancement. As an added point of confusion, if your item-level hold is on an unavailable item and Koha shows it on the Holds to Pull anyway, it will be shown as an item-level hold for some copy that is available (though Koha rightly will refuse to fill the hold with the item its sent you to pull). Created attachment 128171 [details] [review] Bug 29161: POC This is messy - our listing of holds only grabs the first, so we cannot tell whether we have both itemnumber and biblionumber holds. This patch removes the limit on priority one, then checks in get_items_that_can_fill for both item level and title level holds. I don't know how this affects the grouping for display We also only deal with one hold at a time on this report - if there are several title level holds, we only see it once, I guess fine, you fill that, run the report, fill the second Test plan below fails To test: 1 - Place an item level hold on a biblio with multiple items 2 - Run Holds to pull 3 - The hold shgows - okay 4 - Checkout the item with the hold to another patron 5 - The holds shows - not okay 6 - Apply patch 7 - The hold no longer shows 8 - Place a title level hold 9 - That hold shows |