REPLICATE: 1. Find a Biblio with many Items. 2. Set the system preference "OpacMaxItemsToDisplay" to something less than the amount of Items the Biblio has, but more than 0. 3. Go to the OPAC-details.pl -page for the Biblio. 4. Observe the notification "This record has many physical items (??). Click here to view them all." and the missing "Place hold" on the rightmost frame. 5. Clicking the "view them all"-button enables the "Place hold"-button. Quick hack is provided.
Created attachment 35656 [details] [review] Bug 13654 - Cannot place a hold for biblio with too many Items to display unless viewing them all. Certainly not a complete fix, but makes it possible to place holds on Serial Items again.
Please remember to include the bug number, description, and test plan in your patch's commit message.
Thanks for the tip Owen, but I think this patch is far from being included to the master. I am just too busy now with stuff breaking around me to provide proper unit tests etc. The status was left to "New" on purpose. Take care.
There must be some consequences to this modification I made. They shouldn't be dangerous, so I am waiting for feedback from our librarians. So far so good.
Did you get any feedback Olli?
Any chance of re-writing this since it failed QA? I'd really like to see this work.
(In reply to George Williams (NEKLS) from comment #6) > Any chance of re-writing this since it failed QA? I'd really like to see > this work. I was just opening a new report when I saw this one. I have a patch with one line more for it?
Currently, we do not show Place hold on opac-detail if there are too many items. The user can click View all items to refresh the detail page with all items. At that time we show Place hold (if possible). If we just show Place hold if there are too many items, clicking Place hold could perhaps generate a refusal but will probably most often save another click on View all items (which even seems to confuse some users).
Created attachment 82223 [details] [review] Bug 13654: Show 'Place hold' when there are too many items? Currently, we do not show Place hold on opac-detail if there are too many items. The user can click View all items to refresh the detail page with all items. At that time we show Place hold (if possible). If we just show Place hold if there are too many items, clicking Place hold could perhaps generate a refusal but will probably most often save another click on View all items (which even seems to confuse some users). Test plan: Pick a biblio with too many items or lower OpacMaxItemsToDisplay. With this patch, you now see Place hold in the side bar.
Not for purists, but highly pragmatical approach..
In the case where neither CountItemsIssued nor $biblio->has_items_waiting_or_intransit return 1, pushing AllowOnShelfHolds => 1 to the template doesn't seem enough, since the ReservableItems variable wouldn't have been initialized in opac-details.pl. On my end, at least, this means that I'm still not able to see the 'Place hold' button after applying the patch. I would suggest either also sending ReservableItems to the template, or simply setting $allow_onshelf_holds = 1. Still a bit too early to put this as Failed QA, as I'm not a QA person myself, but the patch doesn't feel quite right.
I see that this hasn't been commented on in about a year, so I wanted to mention that this bug is coming up for our library; not just with serials but also in-demand equipment (Chromebooks/hotspots) for which we have many items.
*** Bug 29756 has been marked as a duplicate of this bug. ***
Why is the status on this bug blocked?
(In reply to Christopher Brannon from comment #14) > Why is the status on this bug blocked? Comment11
This bug has been reported at least three times now. Why was it changed to WONTFIX?
(In reply to Owen Leonard from comment #16) > This bug has been reported at least three times now. Why was it changed to > WONTFIX? Good question. Seems like if it is not going to be fixed, it should be explained why. Otherwise, I'm just going to be a pest, and nobody wants that. :)
(In reply to Christopher Brannon from comment #17) > (In reply to Owen Leonard from comment #16) > > This bug has been reported at least three times now. Why was it changed to > > WONTFIX? > > Good question. Seems like if it is not going to be fixed, it should be > explained why. Otherwise, I'm just going to be a pest, and nobody wants > that. :) I'm going to guess maybe Marcel closed it because of Comment 8 and Comment 11. But I don't know either. -- One way to fix this one would be to remove the "Place hold" HTML and logic from the opac-detail.pl page and instead handle it via an API call. The template could show a loading graphic and once the async API request has determined holdability then it could render the "Place hold" or go from a disabled "Place hold" to a "Place hold" link. In theory, that should provide good usability, good page load performance, and an accurate view.
Actually... looking at this one again... It's gated off ReservableItems... which is populated based off this: my $holdable_items = $biblio->items->filter_by_for_hold->count; my $can_holds_be_placed = $patron ? 0 : $holdable_items; So actually... if you have "OpacMaxItemsToDisplay" active on a record, "Place hold" WILL appear if you're not logged in (if it's widely holdable). But if WILL NOT appear if you're logged in. Honestly, I think you could just use $holdable_items to populate $can_holds_by_placed if the threshold for "OpacMaxItemsToDisplay" is met even if you're logged in. But... technically that's wrong too. For instance, if an item is holdable for STAFF but not for the general public, and you're logged in as STAFF and "OpacMaxItemsToDisplay" is active on the record, "Place hold" won't appear even with the above "fix" since $holdable_items is based off the circ rules that don't include branch and categorycode. So to do get an accurate determination... we'd either have to loop all the items in opac-detail.pl for holdability or do the async API call. I've waffled on the performance impact of looping through a large number of items for holdability. Sometimes it seems like it's a huge performance impact and other times it seems not great but not the worst thing ever. -- Overall, all things holdings/items needs a re-work to be more scalable really...
I'd say this should be re-opened but I don't know that anyone will work on this any time soon either...
These days, the holdings in the staff interface are loaded via API. It would be great to get that in the OPAC too, so then we wouldn't need "OpacMaxItemsToDisplay" anymore. If we did that... would we do an API call for holdabilty or would we do the calculation server-side?
CLOSED was the semi-automatism we do after releases, RESOLVED WONTFIX was by Marcel, I imagine because he was not planning to work on this anymore? Reopening.