unAPI should consider copy visibility when returning copies

[Dan Wells]

EG 2.3+

The search results screen in TPAC uses unAPI to fetch the copies for the brief copy display. This fetch does not consider whether the copy is visible, so if a record has a large number of invisible copies (e.g. 'opac_visible' is false on the copy itself), it is possible that no copies get displayed on the results page. (The details page uses a different query (at this point, anyway) and is unaffected.)

We are currently ranking the volumes and copy statuses according to their level of availability, but we do not consider the availability of the copy directly. There are multiple ways to deal with this. I am working on a branch as a starting point for discussion and finding the best solution, but feel free to jump in if you feel you already know the best way, or if I am off in my analysis.

[Dan Wells (dbw2)]

Fix for this bug can be seen here:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/lp1112723_unapi_rank_cp_visibility_check

working/user/dbwells/lp1112723_unapi_rank_cp_visibility_check

Also, attaching a picture showing the before and after, for clarity:

[Dan Scott (denials)]

And in a staff client context, that will push the opac-invisible copies to the end of the list, right? Just want to ensure we have the expected behaviour covered.

[Dan Wells (dbw2)]

There are checks in opac/parts/misc_util.tt2 which hide "opac_visible=false" copies even in the staff client. Were that code modified to consider is_staff, then yes, this change would push the "opac_visible=false" copies to the bottom of the list, and I think that is reasonable behavior.

[Dan Wells (dbw2)]

Also, this code will conflict with https://bugs.launchpad.net/evergreen/+bug/1090025 (at least in the upgrade file, if not the 990 file), so I can help with any merge conflicts which occur after one or the other goes in.

[Dan Wells (dbw2)]

Bug 1090025 did go in first, so this needs to be reworked a bit, as expected. New branch forthcoming...

[Dan Wells (dbw2)]

After a long hiatus of RM&M-ing, I'm trying to catch up on neglected branches of mine. This code has been rebased and reworked for current master, and is force pushed to the same place as before:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/lp1112723_unapi_rank_cp_visibility_check

[Josh Stompro (u-launchpad-stompro-org)]

I just tested this out on an early June version of Master, and I see the same issue. I made" opac visible=false" all but 9 copies of stardust, and when I look at the search results with "show more details" selected, I'm only shown 6 out of the 9 copies that should be visible.

After I installed this branch and try the same scenario, all of the available copies are shown. So this looks like it takes care of the problem as described.

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

[Ben Shum (bshum)]

Pushed to master and backported (with minor conflict resolution for the 002.schema.sql file) to rel_2_8 and rel_2_7. Thanks for the signoff Josh.