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.
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
I get the same message for a reference copy at item level Will try changing the item type at biblio level
Sorry Nicole can't replicate, please reopen with more detail, including exactly how to replicate it if still occurs
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.
Created attachment 6173 [details] [review] patch
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 ?
> 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?
We do not have complaints for this any more. If anyone feels like it should be followed up, please flip the status back again.