Display problem in OPAC when 856 has a $n

[Rogan Hamby]

Observed when a tag like this exists:

856 4 0.
‡nComics Plus by Library Pass ‡uhttps://foopubliclibrary.librarypass.com/product/com.iversecomics.dynamite.james.bond.twelve.english.12122016
‡zInstantly available on Comics Plus by Library Pass

The $u/$z is not displayed under the Electronic Resoures heading at the top of the page. Removing the $n resolves it. Might be related to https://bugs.launchpad.net/evergreen/+bug/1350827

[Elaine Hardy (ehardy)]

$n isn't a valid subfield for the 856 (https://www.loc.gov/marc/bibliographic/bd856.html). Would that be the issue here? Or does the code not care?

[Elizabeth Thomsen (et-8)]

Looks like it's a valid subfield now:
$n - Terms governing access [NEW, 2022]

See also:
$e - Data provenance [NEW, 2022]
$l - Standardized information governing access [NEW, 2022]
$n - Terms governing access [NEW, 2022]
$r - Standardized information governing use and reproduction [NEW, 2022]
$t - Terms governing use and reproduction [NEW, 2022]
https://www.loc.gov/marc/bibliographic/bd856.html

[Elaine Hardy (ehardy)]

THanks! Glad to see Evergreen is ahead of others for this. It still isn't in Bib formats and standards

[Garry Collum (gcollum)]

Looking at the code in misc_util.tt2, it looks like an 856 that contains an $n is purposely loop around because it's an asset.uri. I'm assuming this code was written based on $n old definition that was made obsolete in 2020 ($n - Name of location of host [OBSOLETE, 2020]).

We could remove the code above and create a new variable for subfield $n for display purposes.

It also looks like the code to display $z was commented out in summary.tt2 in the Bootstrap opac. Does anyone know why? The only reason I could think of is that it's a repeated field, that would only display one value. It's not commented out in the TPac.

[Christine Morgan (cmorgan-z)]

Confirmed based on comments.

[Garry Collum (gcollum)]

A proposed patch for the Bootstrap Opac is at https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gcollum/lp1966995-bootstrap-opac-856n

It creates an new variable for 856 $n, and removes the code that was suppressing this field.

This also partially fixes LP1919359. The only reason I could think of for the variable that displays the combination 856 $z and $3 to be commented out was that if a record had both a $z and a $3, neither would display. So I also created a new variable for 856 $3. So if a record now has both $z and $3, the both display.

A todo item = there is still an issue with repeated subfield $z's.

[Carol Witt (carolwitt)]

I tested this patch at https://terran-testbox.gapines.org/. I added the following subfields in various combinations to field 856 in TCNs 50, 51, and 52 ($z already existed):

$nTerms governing access here
$3Materials specified here

Patron view shows the following:

856$z shows the subfield's text
856$3 shows the subfield's text
856$n shows the subfield's text
856$z and $n shows both subfields' text
856$z and $3 shows both subfields' text
856$n and $3 shows both subfields' text
856$z, $n, and $3 shows all subfields' text

Like the repeatable 856$z issue per Garry's comment, the same is true of the 856$n: it is a repeatable subfield; however, no 856$n is visible if an 856 has more than one $n. This seems to be a separate issue; the patch fixes the initial bug (and perhaps 1350827?).

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

[Galen Charlton (gmc)]

Pushed down to rel_3_9. Thanks, Garry and Carol!