[Bug 35299] New: Allow for items with specific not for loan values to appear in the holds queue
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35299 Bug ID: 35299 Summary: Allow for items with specific not for loan values to appear in the holds queue Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: katrin.fischer@bsz-bw.de QA Contact: testopia@bugs.koha-community.org CC: clemens.tubach@kit.edu, gmcharlt@gmail.com, michaela.sieber@kit.edu We’d like to be able to specify a list of not for loan values that will be considered eligible to fill holds and appear in the holds queue and ideally the pending holds list as well. These would usually be negative not for loan values, that can be placed on hold. It should be possible to still exempt some status, like -1 = on order. Use Case: In libraries with closed stacks there are often items that are not for loan, but can be requested for use in a reading room. Staff will then get the items and fill the holds, but they won't be checked out on self checks etc. An on-site checkout might be forced. (see Library of Congress: https://ask.loc.gov/law/faq/300644) In order for this process to work the library needs the information about the requested items in order to be able to pull the items in the closed stacks. We have tested a change in Holdsqueue.pm that works, but should be made properly configurable: https://git.koha-community.org/Koha-community/Koha/src/branch/master/C4/Hold... Change: $items_query .= " WHERE items.notforloan = 0 To: $items_query .= " WHERE items.notforloan in (-2, -3, 09) -- 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=35299 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35299 hebah@bywatersolutions.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hebah@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35299 Mirjam Vantieghem <mirjam.vantieghem@etf.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mirjam.vantieghem@etf.edu --- Comment #1 from Mirjam Vantieghem <mirjam.vantieghem@etf.edu> --- +1 -- 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=35299 Katie Bliss <kebliss@dmpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kebliss@dmpl.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35299 Michaela Sieber <michaela.sieber@kit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=10591 -- 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=35299 Michaela Sieber <michaela.sieber@kit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=37022 -- 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=35299 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lisette@bywatersolutions.co | |m -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35299 Rebecca Coert <rcoert@arlingtonva.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rcoert@arlingtonva.us -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35299 --- Comment #2 from Rebecca Coert <rcoert@arlingtonva.us> --- +1 -- 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=35299 Janusz Kaczmarek <januszop@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |januszop@gmail.com --- Comment #3 from Janusz Kaczmarek <januszop@gmail.com> --- If I may comment it: I perfectly understand the use case. We solve it by assigning notforloan = 0 and restricted = 1 in such cases. The user sees then: "Available (Restricted access)" (in green) as item status. What would serve, however, would be a possibility to on-site check-out those restricted items. Wouldn't be enough? -- 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=35299 --- Comment #4 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Janusz Kaczmarek from comment #3)
If I may comment it: I perfectly understand the use case. We solve it by assigning notforloan = 0 and restricted = 1 in such cases. The user sees then: "Available (Restricted access)" (in green) as item status.
What would serve, however, would be a possibility to on-site check-out those restricted items.
Wouldn't be enough?
Restricted = 1 cannot be checked out - not even as an on-site, IRRC? -- 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=35299 --- Comment #5 from Janusz Kaczmarek <januszop@gmail.com> --- (In reply to Katrin Fischer from comment #4)
(In reply to Janusz Kaczmarek from comment #3)
If I may comment it: I perfectly understand the use case. We solve it by assigning notforloan = 0 and restricted = 1 in such cases. The user sees then: "Available (Restricted access)" (in green) as item status.
What would serve, however, would be a possibility to on-site check-out those restricted items.
Wouldn't be enough?
Restricted = 1 cannot be checked out - not even as an on-site, IRRC?
Exactly. Interestingly, only == 1, but not for other values (no idea why so). A tiny patch like: diff --git a/C4/Circulation.pm b/C4/Circulation.pm index a9f32c34e8..72aae56c69 100644 --- a/C4/Circulation.pm +++ b/C4/Circulation.pm @@ -1052,7 +1052,8 @@ sub CanBookBeIssued { $issuingimpossible{WTHDRAWN} = 1; } if ( $item_object->restricted - && $item_object->restricted == 1 ) + && $item_object->restricted == 1 + && ! $onsite_checkout ) { $issuingimpossible{RESTRICTED} = 1; } would make on-site check-outs of such materials possible. If it looks like a good idea I could prepare an official patch (I patch this in some of my installations anyway). -- 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=35299 --- Comment #6 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- There is a very old discussion about how restricted should be used and what it's supposed to do - which makes it hard to change behavior now, as we don't know how libraries have been using it so far (bug 10591) Another issue with the restricted: If you want to do a proper checkout, you can't overwrite right now. So it's really a hard block. Maybe THAT is a use case some libraries need? The behavior for 'not for loan' with the negative and positive values on the other hand is clear and it could fit in with SkipHoldTrapOnNotForLoanValue and TrapHoldsOnOrder. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org