Bug 6650

Summary:	no holds message is not always clear
Product:	Koha	Reporter:	Nicole C. Engard <nengard>
Component:	Circulation	Assignee:	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:	Main
Hardware:	All
OS:	All
Change sponsored?:	Sponsored	Patch complexity:	---
Documentation contact:		Documentation submission:
Text to go in the release notes:		Version(s) released in:
Circulation function:
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.