Ensure that non-multi display fields do not multiply

[Galen Charlton]

Consider a customized title display field entry that uses the following XPath to ensure that parts from the 245 $n and $p are included in the displayed title:

//marc:datafield[@tag="245"]/marc:subfield[@code="a" or @code="b" or @code="n" or @code="p" or @code="k" or @code="f" or @code="g" or @code="s"]

Since this XPath expression results in a list of nodes that cannot be joined up via XPath itself, as XPath 2.0's string-join is not available to us, this can result in a title display that consists of multiple metabib.display_entry rows:

SELECT * FROM biblio.extract_metabib_field_entry( 259, ' ', '{display}', '{6}' ) where display_field;
-[ RECORD 1 ]-+--------------------------------------------------------
field_class | title
field | -6
facet_field | f
display_field | t
search_field | f
browse_field | f
source | 259
value | Under Jerusalem :
authority |
sort_value |
browse_nocase | f
-[ RECORD 2 ]-+--------------------------------------------------------
field_class | title
field | -6
facet_field | f
display_field | t
search_field | f
browse_field | f
source | 259
value | the buried history of the world's most contested city /
authority |
sort_value |
browse_nocase | f

Particularly in the Angular staff catalog, this can result in displays that either display the parts of the title out of order or, when search term highlighting is in effect, display only one of the subfields.

For display fields that are not marked as multi = TRUE in config.display_field_map, it would be better if the display entries were automatically concatenated into a single string using the joiner specified by the cmf entry. A patch is forthcoming to do this.

Evergreen 3.6+

[Galen Charlton (gmc)]

A patch is available at the tip of working/user/gmcharlt/lp1949892_join_up_display_field

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

A rel_3_7 version of the patch is available at working/user/gmcharlt/lp1949892_join_up_display_field-3.7

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

[Terran McCanna (tmccanna)]

Galen, can you offer any guidance on how to test this?

[Chrisy Schroth (cschroth)]

I don't understand 100% of the description of this bug, but I thought I could do some edits to a couple of records to add $n and $p and see how it changed the records.

On Blake's Test Server, https://bugsquash.mobiusconsortium.org/eg/staff for bug squashing week, I searched for titles with no. in them. TCN 38 had a title of:

=245 00$aViolin concerto no. 1, op. posth.

I edited the title to
=245 00$aViolin concerto.$nno. 1,$pop. posth.

After several minutes I repeated the search, and at first I couldn't find the record because it was no longer coming up on the first page of results, but once I figured out that it was still there, it displays the title in the same/correct order, highlighting the "no.". When I did the search for the $p text of "op. posth", that section was highlighted, but the display order did not change, and the whole title was again visible. In the Search Results the . at the end of the $a is not visible, but it does display in the opac when you click the Patron view button.

I changed the order to place the $p before the $n. After several minutes, and several repeats of the search, in the staff pac the title remains $a $n $p in the Search Results instead of the new order. It does highlight whichever term the search was looking for, and it displays all the terms. Opening the record and choosing Patron View causes it to display $a $p $n as is now in the record. The punctuation all displays as it appears in the bib in the opac, but not the staff pac Search Results screen.