Align OPAC URI display with Staff logic

[Mike Rylander]

Currently, the web staff client displays URIs in a slightly different (and arguably better/more complete) way than the OPAC. In particular, the staff client includes any 856 with an ind2 value of 0, 1, or 2, and provides a label indicating the purpose of the URI based on the ind2 value. The OPAC, on the other hand, only displays 856s with an ind2 of 0 or 1, and does not distinguish the purpose.

A branch is forthcoming with improvements for the OPAC templates (TPAC and BooPAC) to make them smarter, like the staff client.

[Mike Rylander (mrylander)]

Branch implementing this available at:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1992827-improved-opac-uri-display

[Blake GH (bmagic)]

Bugsquash week: This doesn't merge clean on master today.

[Mike Rylander (mrylander)]

I've rebased this at: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1992827-URI-display-rebase

[Timothy Means (tmeans-ncc)]

In the staff client, there doesn't seem to be any Concerto items with 2nd indicators > 1 for field 856, and you could search for ever trying to find one, so this patch can't be e2e-tested in a practical way by inspection of OPAC views.

Maybe only a unit test will do any good for this one?

And btw this seems to be a problem with displaying 2nd indicators > 1 ONLY for MARC field 856, because, for example, compare the MARC records for item "Histoire de Sainte-Barbe," between Terran (with the patch) and Tiffany (without the patch) server OPACs, both of those show a 650 field with a 2nd indicator == 6.

[Timothy Means (tmeans-ncc)]

oclc has some examples of specific works that could be given 856 2nd indicators higher than 1

https://www.oclc.org/bibformats/en/8xx/856.html

[Terran McCanna (tmccanna)]

FYI, the test servers allow editing of any of the Concerto bib records to add 856 fields with second indicators for testing purposes. For example, I copied some unrelated 856 fields out of an unrelated record on our production server and added them to 'Blueberry girl' (TCN 216) on both of the terran & tiffany test servers. I can see that a new Electronic resources section now appears under the holdings in the OPAC, but I don't know enough cataloging to test it further than that.

[Christine Morgan (cmorgan-z)]

If I am understanding this correctly, this patch only affects non-located URI's. If that is the case, it works as described. Testing on terran-master.gapines.org I changed the second indicator to 2 (in bib 208) for a non-located URI and saved the record. The link displayed with the label of Related Resource in both the staff client and the BooPAC. If I change the second indicator to 1 the label changes to "Version of Resource." If I change it to 0, the label changes to "Resource."

Assuming that this does only affect non-located URI's:

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

[Galen Charlton (gmc)]

Noting a new related bug I filed given that the MARC21 856 indicator 2 got tweaked in October 2022: bug 2021897

[Jeff Davis (jdavis-sitka)]

Also noting bug 1230380 which has some prior discussion of desired display behavior for 856s with ind2=2.

[Jane Sandberg (sandbergja)]

Adding the needsreleasenote tag. The release notes should mention that the 856 with second indicator 2 will now be much more prominent, so libraries should check to make sure that related resource links are still valid.

[Mike Rylander (mrylander)]

I've rebased this on main and added a release note to the OPAC section:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1992827-URI-display-rebase-release-notes

[Jane Sandberg (sandbergja)]

This is nice! Thanks, Mike and Christine! Merged to main for inclusion in 3.12.