Bug 36346 - CheckReserves sometimes lead to bad behavior
Summary: CheckReserves sometimes lead to bad behavior
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Thibaud Guillot (thibaud_g)
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-03-18 14:57 UTC by Thibaud Guillot (thibaud_g)
Modified: 2024-04-01 11:03 UTC (History)
3 users (show)

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


Attachments
Bug 36346 : Prevent moving to the next object on 'not_allowed' rule (1.72 KB, patch)
2024-03-18 15:07 UTC, Thibaud Guillot (thibaud_g)
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Thibaud Guillot (thibaud_g) 2024-03-18 14:57:47 UTC
Hi @ll,

Some options in the circulation rules may lead to incorrect returns from CheckReserves. 

When you enabled AllowHoldPolicyOverride, you can forcing a hold, even when it is not authorized in the "Default holds policy by item type" rule table. 

Let me explain: when a hold is forced on an item whose itemtype has a holdallowed rule set to "not_allowed", if you return the item, the hold will not be detected.

Similarly, when you perform a checkout, the pop-up indicating that a hold has been placed is not displayed. It's possible that in other places in the code this would cause other inconveniences, but I haven't counted them all.
Comment 1 Thibaud Guillot (thibaud_g) 2024-03-18 15:07:34 UTC
Created attachment 163339 [details] [review]
Bug 36346 : Prevent moving to the next object on 'not_allowed' rule

Test plan:

1) Enable AllowHoldPolicyOverride
2) Set a new circulation rule on "Default holds policy by item type":
For example, an item type called "Comics" with Hold policy set on "No
holds allowed"
3) Go to an item related to this item type and force a hold :)
4) Try to perform a check-in on this item, no pop up
5) Try to perform a check out for another patron, no pop up again
6) Apply this patch
7) Repeat step 4 and 4, normally now there is a pop up with hold
   information

Sponsored by : BibLibre
Comment 2 Nick Clemens (kidclamp) 2024-03-18 20:54:58 UTC
I am not sure this is a bug - librarians sometimes want to be able to force a hold that will only fill later - for example a book on the display shelves might not fill holds, but it can fill holds after it moves, and they could use an itemtype for this control - new books are a similar example
Comment 3 Thibaud Guillot (thibaud_g) 2024-03-19 08:20:56 UTC
I was thinking that if we have the possibility of forcing a hold even if it is not authorized in the rules, the hold should still be found if it exists in certain cases (those I list in the test plan).
Comment 4 Katrin Fischer 2024-04-01 11:03:56 UTC
I think this would just fix one case of forced holds, but the problem is a wider one. There are some bugs around this that could be interesting to have a look at. Entry point is:

Bug 31169 - [OMNIBUS] Problems with forced holds (AllowHoldPolicyOverride) 

I think Nick is right in that some libraries expect this behavior, but it would be nice if we could work out a way that we can make this a bit more flexible for libraries which would like things to work differently. But as it is with holds, things tend to be complex :)