Summary: | On order items still available for item level holds with TrapHoldsOnOrder | ||
---|---|---|---|
Product: | Koha | Reporter: | Katrin Fischer <katrin.fischer> |
Component: | Hold requests | Assignee: | Bugs List <koha-bugs> |
Status: | CLOSED INVALID | QA Contact: | Testopia <testopia> |
Severity: | major | ||
Priority: | P5 - low | CC: | gmcharlt, kyle |
Version: | 20.11 | ||
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: |
Description
Katrin Fischer
2022-03-28 12:32:51 UTC
I don't think this is a bug. This syspref is not related to whether an item may be placed on hold or not. It is specifically constrained to only deciding if on order items can be trapped to filled existing holds. (In reply to Kyle M Hall from comment #1) > I don't think this is a bug. This syspref is not related to whether an item > may be placed on hold or not. It is specifically constrained to only > deciding if on order items can be trapped to filled existing holds. Hi Kyle, I am still confused a bit by placing holds on items that will not trap... but for on order it probably makes the most sense as they will someday probably 'trap' when they become available. Thx. In case you know: How to handle it if libraries don't want the on order items to be already holdable? Using an itemtype is not really nice there, but the only thing I can think of right now. |