Add "limit to available" option in OPAC record view

It's possible to limit a search to show only bibs with available copies, but when you're looking at a bib record, it's not possible to limit the display of items to show only the available copies. This is a big problem for records with lots of copies with many copies checked out, like bestsellers. For example, right now in CW MARS, only 9 of 488 copies are currently available. Even using the option to page through 50 items at a time, it takes a lot of paging and scanning through items to spot the available copies. http://catalog.cwmars.org/eg/opac/record/4198697?copy_limit=50

This proposed feature has been selected as a development project by the Evergreen Community Development Initiative. The ECDI has compiled and refined a set of requirements and seeks proposals including specifications and project cost/time estimates from interested and able parties to develop this feature.

Those requirements and additional information are available at https://docs.google.com/document/d/1Ijlnp1DmyFmstZAlZM0OcnDOsRcm1WabBg5AMWLAj7Q/

Here's the branch for the newly added "limit to available" component.
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=ca1e3b3f0f01b54bde06b40218b06e7362fcdddd

Ready for review.

Hi Zavier,

I wonder if, in the adjustment to the WHERE clause added to mk_copy_query, the test should be for statuses that have the is_available flag set to true rather than testing for the id of 0 specifically?

Also, and I admit I have not confirmed it's possible, could the overwriting of the WHERE clause in its entirety be blowing away some clause added by the call of $U->basic_opac_copy_query()? I have a vague memory of a bug in that area before (and may have been the one that caused it).

Here's the updated branch:
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=495605b7ff9e4e090222dd7fc3119398f14d83d7

I don't know how to check for that bug, but I pretty much copied the WHERE clause with an added field.

Thanks, Zavier

Since you're moving part of the required logic into basic_opac_copy_query() to get the flag out, perhaps we should just move the rest into basic_opac_copy_query() and have it be driven by an optional parameter, just like the staff flag. With that change other callers can benefit from the ability to filter by copy availability in the future.

Thoughts?

Mike Rylander,

If I'm understanding you right, I kept most logic in the Record.pm to keep up consistency with the already established code. I tried to keep from changing any of the AppUtils as much as possible, just in case there is some kind of bug.

As long as the "available" parameter is in the url. It should filter by copy availability.

While not to do with the functionality, there has been some conversation about the styling of the "limit to available" feature which appears as a link. With the thought that eventual styling of the OPAC will follow in the vein of Chris Burton's work (https://bugs.launchpad.net/evergreen/+bug/1778972), it seems appropriate that the "Show Only Available Copies" might look similar to the "More Details" button in the test OPAC provided by Chris. https://test.nflibrary.ca/eg/opac/record/158047?locg=101

As well as the "Show All Copies."

I have tested this code and consent to signing off on it with my name, rfrasur, and my email address, <email address hidden>.

I also tested this code and consent to signing off on it with my name, Elaine Hardy, and my email address, <email address hidden>.

I want to note something here that was out of scope of the development but might be considered a wish list item later. When you limit to available at the results or initial search level, it does filter out any bib record with no available copies as always. You have to filter again at the bib record level to filter out unavailable copies.

I can see users wanting/expecting the filter to carry through to the bib level when set at earlier points. Again, out of scope of the development but might be something to address later. I will keep in mind in order to post as a wish list item once this is live.

Since this has already been signed off, I created a new bug for adding it to the Bootstrap OPAC: https://bugs.launchpad.net/evergreen/+bug/1908612

Noting that the patch needs to be rebased.

I've pushed a quick rebase here: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/khuckins/lp1853006-add-limit-to-available-rebase

Eh, the rebase has compilation errors:

$ perl -c Open-ILS/src/perlmods/lib/OpenILS/WWW/EGCatLoader/Record.pm
Missing right curly or square bracket at Open-ILS/src/perlmods/lib/OpenILS/WWW/EGCatLoader/Record.pm line 882, at end of line
syntax error at Open-ILS/src/perlmods/lib/OpenILS/WWW/EGCatLoader/Record.pm line 882, at EOF
Open-ILS/src/perlmods/lib/OpenILS/WWW/EGCatLoader/Record.pm had compilation errors.

Adding needsrepatch.

Thanks for the catch, erroneously kept an old version of a line in that already existed. Force pushed over the rebase

Unfortunately, after applying this patch, I get an Internal Server Error when attempting to load the TPAC.

With the recent rebase, I'm not encountering any internal server errors, I'm wondering if the branch you have loaded up is the prior rebase, which would result in said error. As it was force-pushed that could cause issues in ensuring the latest code is loaded up - this branch is, code-wise, the same as the latest rebase: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/khuckins/lp1853006-add-limit-to-available-rebase-2

This latest rebase is working for me now, adding a 'Show All Copies'/'Show Only Available Copies' toggle at the head of the item table in the TPAC.

I've pushed a signoff branch with an additional commit to allow translation of the toggle labels. Branch is here:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mmorgan/lp1853006_signoff

user/mmorgan/lp1853006_signoff

Also opened bug 1919485 to add this functionality to the Angular staff catalog.

Committed for inclusion in 3.7. Thanks, Zavier, Michele, and Kyle.