Bug 6650

Summary: no holds message is not always clear
Product: Koha Reporter: Nicole C. Engard <nengard>
Component: CirculationAssignee: Srdjan Jankovic <srdjan>
Status: CLOSED WORKSFORME QA Contact: Bugs List <koha-bugs>
Severity: enhancement    
Priority: PATCH-Sent (DO NOT USE) CC: chris, gmcharlt, henridamien.laurent, wizzyrea
Version: master   
Hardware: All   
OS: All   
Change sponsored?: Sponsored Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Attachments: patch

Description Nicole C. Engard 2011-07-30 12:29:41 UTC
Problem: 

On the staff side of Koha, if we try to place a hold on a Reference or Reserve
book, Koha properly denies the request with an odd message:  Cannot place hold,
patron has too many holds.  It’s the correct action, but strange. Is this one
of those built in messages? Not very informative certainly confusing.

Explanation of solution:

What Koha's doing, under the hood, is checking the CanBookBeReserved
subroutine, which is a simple boolean 'Yes/No' answer.  It's a boolean OR of
all the CanItemBeReserved answers for all the items of that title.

In the case of a title with a single reference copy, which allows 0 holds on
it, the answer is 'no, this item cannot be reserved'.  The problem is that Koha
is then setting the "maxreserves" flag, because the patron's current number of
reserves on such items (which is 0) is greater than or equal to the max allowed
(also 0).  In any other context, this would make sense:  if you were allowed
only 4 holds, say, on a Book, and you wanted to place your 5th, you'd get the
messaging saying you had too many already.

I suppose the confusion really comes in when the global "maxreserves" system
preference is also consulted, and sets the same flag.  So, you've got an
unlimited maxreserves, but you're still getting the message because 0 >= 0.

The solution, I believe, is to use a separate message for the CanBookBeReserved
check than for the overall maxreserves check.  This could be something like
"Cannot Place Hold:  <patron> cannot place any more holds on this item type". 
Still not perfect for the Reference use-case, but better.
Comment 1 Chris Cormack 2011-08-26 00:01:44 UTC
Cannot Place Hold

    No copies are available to be placed on hold



Is the message I get for an item that is marked notforloan.  I will try with the item type instead
Comment 2 Chris Cormack 2011-08-26 00:04:10 UTC
I get the same message for a reference copy at item level

Will try changing the item type at biblio level
Comment 3 Chris Cormack 2011-08-26 00:07:18 UTC
Sorry Nicole can't replicate, please reopen with more detail, including exactly how to replicate it if still occurs
Comment 4 Ian Walls 2011-08-26 14:03:43 UTC
Chris,


In your testing, is rule for limiting the holds for a Reference Copy being defined in the Circ Matrix itself (Holds Allowed = 0) or Holds policy by item type section?

I'm doing my test when Holds Allowed = 0 AND the Holds Policy by Item Type is set to deny.
Comment 5 Srdjan Jankovic 2011-11-04 01:24:41 UTC
Created attachment 6173 [details] [review]
patch
Comment 6 laurenthdl 2011-11-04 08:33:07 UTC
May I suggest that reason is not enough.
If you block CanItemBeReserved for maxreserves rules, would it not be quite interesting to have the number of reserves and the blocking issuing rule returned ?
Also, it seems to me that Having english string as ERROR Code (REASON) is quite misleading, it may lead to detailed tests in tt files
 
IF reason eq "THE REASON WHY THE CODE IS THROWING AN ERROR"

, or to untranslatable strings. Which is NOT what we would like.

I feel we will have some reason to fail to read correctly.
Moreover, could we have some pm to centralize Error codes ? or Some guidelines to place Error Codes in pm at the same zone in the PM rather than disseminating them all through the code ?
Comment 7 Owen Leonard 2011-11-04 19:59:33 UTC
> If you block CanItemBeReserved for maxreserves rules, would it not be quite
> interesting to have the number of reserves and the blocking issuing rule
> returned ?

I agree with this. Looking at the patch itself I'm not sure this goes far enough towards solving the problem. However, I'm still not clear on how to reproduce the error in question. Can we get more details?
Comment 8 Srdjan Jankovic 2012-03-06 23:33:52 UTC
We do not have complaints for this any more. If anyone feels like it should be followed up, please flip the status back again.