On the staff side search result, an item will show "No holds allowed" if the item is on hold "Waiting". See Search.pm line 1841. if( $item ->{withdrawn} || $item->{itemlost} ... || $reservestatus eq 'Waiting' <==== || ($transfertwhen ne '')) One can still place holds on the item.
Not sure this is an enhancement ... because a hold is allowed it's a bug. Nicole
Created attachment 22070 [details] No holds allowed in staff search results example
If there is only one item available to have a hold placed on it, and the item is waiting for pickup, no holds are allowed in search results, but can be placed on the detail.pl/reserves.pl pages. I can confirm this bug on 3.10.9 as well. I am attaching several screenshots examples of this situation. A particular record of 100 years of solitude has 1 item attached and is waiting for pickup. No holds are allowed from search results in both the staff and catalog sides of the system, but are allowed from the detail.pl and request.pl pages. A particular record of emerald green has 2 items attached. 1 item is waiting for pickup. 1 item is on order (but available for holds), and holds are allowed for search results.
Created attachment 22071 [details] Detail.pl holds are allowed example
Created attachment 22072 [details] Request.pl holds allowed
Created attachment 22073 [details] Catalog side no holds allowed example
Created attachment 22074 [details] Holds allowed from search results example
Created attachment 22075 [details] Detail.pl holds are allowed example (where also allowed in search results)
This appears to be a case where the message displayed in search.pl is erroneous, based on certain special cases. In addition to the cases documented by Heather, there appears to be another -- when there is a single item on the record, and it is IN TRANSIT. As Jorge noted in the original report, one CAN place holds on these items, regardless of the message displayed in search.pl.
In 3.14 this issue is no longer present.
(In reply to HB-NEKLS from comment #10) > In 3.14 this issue is no longer present. Marking FIXED, please file a new bug linked to this, if there is still a problem.