Display problem in PAC when subfields $3 and $z are both present in the 856 tag

[Don Butterworth]

In 2.5.2, when an 856 tag is present that includes $3, $u and $z only the $u displays in the Electronic Resources area of the Record Summary screen. Preferably all subfields would be visible.

[Kathy Lussier (klussier)]

Confirming this behavior with non-located URI's. Located URI's behave a little differently. $3 is a label in a Located URI and $z, $2 and $n are notes. If you use both a $2 and $z in one record with a Located URI, the system will display the note in $z. I don't know if this is a good thing (maybe we should be displaying all use notes?), but it's better than displaying nothing.

What I really would like to see here is some consistency in how non-located and located URI's display.

* The non-located URI's should be displaying $3 as a label, not as a note.
* The non-located URI's should be displaying $2 as a note. I'm not sure we should be concerned about $n here since my reading of the code says that URL's with a subfield $n should be displayed as Located URI's (I wouldn't mind some confirmation on this)
* The non-located URI's should display in ind1 is a 1 (not sure how often this happens in practice, but it would make it consistent with located URI's
* We should have an order of $y then $3 for the display of labels and $z then $2 for the display of notes.

On that last bullet point, Mike Rylander offered the following tips in e-mail:

Related, you can adjust the xpath for unadorned 856 tags to pull just the first of y, z, or 3 by appending [1] to the end, like this:

    label = node.findnodes('./*[@code="y"][1]');
    notes = node.findnodes('./*[@code="z" or @code="3"][1]');

[Kathy Lussier (klussier)]

Below is a working branch that does what I described above:
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp1350827-non-located-uri-display

In the case of Don's URLs, the subfield 3 would display as the label and the subfield z would display as the note. My only concern is if there are sites out there that are using subfield 3 as a note in unadorned 856 tags, they will suddenly display as labels or, in cases where subfield y is in use, they will not display at all. I'm not sure how often this happens in practice.

[Kathy Lussier (klussier)]

Removing pullrequest on this based on the discussion at http://irc.evergreen-ils.org/evergreen/2014-08-01#i_114776.

When I have some spare time, I can take a stab at displaying multiple note fields when applicable and removing the display of subfield 2. It's probably best to stick with just displaying the first label.

[Robert J Jackson (rjackson-deactivatedaccount)]

Just encountered an example from Jocelyn Lewis, Cataloging Supervisor at ISL where an 856 with two z subfields displays neither field. Removal of one of the two results in display of the other. According to standards the $z is repeatable.

This is on 2.7.2.

[Don Butterworth (don-butterworth)]

Here is another issue with the display of 856 subfields. Per our "best practices" discussion on the list, Asbury Seminary is attempting to use $w and $9 to suppress visibility from other libraries in our Consortium, electronic records that are only accessible by our library patrons. Here is an example (subfields have spaces before and after only to make them easier to see in the examples):

=856 40 $3 Electronic copy from Cambridge Books Online $u http://dx.doi.org/10.1017/CBO9780511814631 $y Online access for Asbury Seminary students, faculty and staff. $w ATS $9 ATS

In this example the $y text does not display. We want is to display for the sake of consistency, especially when there are other hot links on the bib record, e.g.

=856 41 $3 Table of contents $u http://catdir.loc.gov/catdir/toc/cam041/2002041245.html $y Online access.
=856 42 $3 Publisher description $u http://catdir.loc.gov/catdir/description/cam041/2002041245.html $y Online access.

[Jane Sandberg (sandbergja)]

Another bug related to unexpected display of 856 subfields: https://bugs.launchpad.net/evergreen/+bug/1697771

[Jennifer Pringle (jpringle-u)]

Confirmed this is still an issue in 3.7