Catalog record no longer displays full subject heading

Bug #1770453 reported by Kathy Lussier on 2018-05-10
This bug affects 10 people
Affects Status Importance Assigned to Milestone

Bug Description

Evergreen version 3.1

Prior to the use of display fields in the catalog, the record used to display a full subject heading with all subfields. The resulting search when the subject link was clicked would then depend on where the user clicked the link, allowing them to choose to search just the subfield a piece of the subject heading or getting more specific by searching the entire heading.

In 3.1, we see at least three changes in behavior/appearance:

1. We aren't displaying the full subject heading. Looking at record 28 in the Concerto dataset, for example, we are missing the subfield t information from the Ludwig van Beethoven subject headings. This also makes it appear as if we have duplicate subject headings on the record (see attached screenshot)

2. When clicking the subject link, we no longer have the option to click just the subfield a portion of the heading if we want a broader search. Looking at record 28 once again, if I click the Overtures - Analysis appreciation link, I can only search that entire subject heading. I can't choose to just click the Overtures portion of the heading to make my search broader.

3. The previous subject headings used > as a separator between some subfields. It's not using a hyphen. The > was previously used as a visual indicator that there was a hierarchy to these subject headings.

Kathy Lussier (klussier) on 2018-05-10
tags: added: displayfields
Changed in evergreen:
status: New → Confirmed
Eva Cerninakova (ece) wrote :

After we have upgraded to 3.1.4 it turned out that the behavior of the uncontrolled subject term links in the field 653 has changed similarly to behavior described above.

In our previous Evergreen version (2.12) when the individual term in the field 653 $a had been clicked on, the individual term was used as the search query link.
In 3.1.4 when clicking the individual term, all term of all $a subfield are used as search query link.

For example: If the field 653 has following subfields: ‡aetika ‡amorální hodnoty ‡aetické principy ‡aAristoteles ‡aAristotle ‡aVirtue ‡aEthics ‡aValues
- in 2.12 when clicking on link „Ethics“ in the "Search for related items by subject" section , the created search query used to be "Ethics";
- in 3.1 when clicking on link „Ethics“ in the "Search for related items by subject" section, the search query created is no more „Ethics, but "etika morální hodnoty etické principy Aristoteles Aristotle Virtue Ethics" instead (see e.g. The query end up with only one result returned - the same record that has been used for clicking on the subject term link even if there are over 200 records returned when searched for subject "Ethics" ).
(As we have many older records in the library catalog with no other subject terms than those in field 653,I find this to be quite serious problem for us.)

Linda Jansova (skolkova-s) wrote :

I suppose it may have something to do with code changes in /templates/opac/parts/record/subjects.tt2 file which were made to add the highlighting feature, e.g.:

    BLOCK render_hl_subject;
        total_term = s.value;
        IF s.facet;
            total_term = s.facet _ '[' _ s.value _ ']';

        '<span property="about"><!-- highlighted -->';
        %]<a href="[%-
               mkurl(ctx.opac_root _ '/results', {qtype=>'subject', query=>total_term}, stop_parms.merge(expert_search_parms, general_search_parms, browse_search_parms, facet_search_parms))
        -%]">[% s.$f %]</a> [%-

Attached is the diff file comparing subjects.tt2 file from 2.12 to the one from 3.1. It may be helpful for determining the cause of the display change.

Linda Jansova (skolkova-s) wrote :

One more comment - looking closely at, it seems that while clicking on the first keyword results in the correct URL (;qtype=subject), the link from th second keyword unexpectedly combines the first and the second keyword in the query (;query=etika%20mor%C3%A1ln%C3%AD%20hodnoty), the link from the third keyword then combines the first three keywords etc.

Strangely, some of the URLs have ";qtype=subject" at the very end of it while others have it right after "results?".

Jason Stephenson (jstephenson) wrote :

The behavior that Linda Jansova describes in comment #3 is, I believe, the expected behavior. These are not keywords, but subject terms. The idea is that you are doing a subject search and getting more specific as you go to the right.

As for the ordering of the qtype=subject parameter, it is unimportant. The parameters are split into keyword/value pairs when given to the back end. The order that they appear in the URL's query string is therefore irrelevant. The order quite likely varies because these keyword/value pairs are being put in Perl hashes by the back end and then reconstructed. Modern Perl 5 has code in it to randomize the order of hash keys, so that could explain why the qtype appears in different places in the query string.

Kathy Lussier (klussier) wrote :

Looking at Linda's example, it does appear that the subject links are behaving the same as previous Evergreen releases when separate subjects are listed in different subfield a's. I created a sample record on a 3.0 system where I used multiple subfield a's for the 650 field, and we also see the hierarchy that Jason describes in his comment.

However, I want to point out that we are not looking at the display field data in Linda's example. When there is no query included in the link, I believe the record display falls back to the previous method of displaying subject headings. I'm not sure the 653 is configured yet as a display field on this system, because, even if I use search terms, the display is the same and there is no highlighting.

When I create a similar record on my 3.1 test system, you'll see similar behavior to what I described in #2 of the bug description. Even when I click the first subject heading, the entire string is included in the search.

See the screencast at

I would love it if it behaved the way Jason described when the display data is in use. I fear our users are going to be very disappointed in the new behavior when we ultimately upgrade to 3.1.

I'm also unclear as to way we are not using the display field data in all instances where we display the record, and not just when there is a query included in the URL.

Eva Cerninakova (ece) wrote :

When it comes to the system where the Linda's example comes from, we have customized the record display adding the 653 field to subject.tt2 template (line 6) as it is the only topical description present in some records. - Kathy, I am not quite sure, what you mean by "I'm not sure the 653 is configured yet as a display field on this system". Is there anything else that should be set when adding the field to subject.tt2 template?
As for the highlighting: The search term in the system are not highlighted because we unfortunately must have switched it off due to bug 1762363. (tji) wrote :

Re Kathy's reported issue #1: partially displayed subject headings (missing $t), we received a report on it. The missing subfield is 610$t in our examples. We found that if we refresh the screen (use the browser's function key), the subfield will show up.

Tina Ji

Meg Stroup (mstroup) wrote :

Related to Tina's comment: we have found that refreshing the screen will make the separators (part #3 of original report) appear.

It is an extra step, though, and library users will not know that the need to refresh to correct the display. Lengthy subject entries are not user-friendly and give no indication that you *could* click on a subfield-- because it looks like there are no subfields, just long subject strings. Example attached.

it also impairs catalogers' ability to scan a MARC record for completeness and correctness.

Reporting for SCLENDS, 3.1, Chrome.

Meg Stroup (mstroup) wrote :

Corresponding flat-text for screenshot:

Just confirming that we are seeing this in 3.1 here in SCLENDS. Example attached: as you can see, it can get pretty difficult to read when the subject headings are complex.

Here's the flat-text copy-paste that corresponds to the screenshot:

=650 \0$aRoads$xEconomic aspects$zUnited States$xHistory.
=650 \0$aRoads$xGovernment policy$zUnited States$xHistory.
=650 \0$aRoads$zUnited States$xMaintenance and repair$xHistory.
=650 \0$aRoads$zUnited States$xHistory.
=650 \0$aInterstate Highway System$xHistory.
=650 \0$aInfrastructure (Economics)$zUnited States$xHistory.
=651 \0$aUnited States$xEconomic conditions$y1945-$0(SC LENDS)495976
=650 \7$aTECHNOLOGY & ENGINEERING$xHistory.$2bisacsh
=650 \7$aPOLITICAL SCIENCE$xPublic Policy$xGeneral.$2bisacsh

Hello, I just noticed this issue also, on 3.3.3. Here is an example from our test system.;detail_record_view=0;page=0;sort=pubdate.descending;query=nora%20roberts;expand=marchtml#marchtml

The 650's look like this.
=650 \0$aFamily violence$vFiction.$0(LARL_NWRL_CONSORTIUM)164976
=650 \0$aAdult child abuse victims$vFiction.$0(LARL_NWRL_CONSORTIUM)170357
=650 \7$aFICTION / Romance / Suspense.$2bisacsh
=650 \7$aFICTION / Thrillers / Domestic.$2bisacsh
=650 \7$aAdult child abuse victims.$2fast$0(LARL_NWRL_CONSORTIUM)178912
=650 \7$aFamily violence.$2fast$0(LARL_NWRL_CONSORTIUM)19960

Subjects in the detail page look like:
Family violence Fiction
Family violence Fiction
Family violence Fiction
Adult child abuse victims Fiction
Adult child abuse victims Fiction
Adult child abuse victims Fiction
FICTION / Romance / Suspense
FICTION / Romance / Suspense
FICTION / Romance / Suspense
FICTION / Thrillers / Domestic
FICTION / Thrillers / Domestic
FICTION / Thrillers / Domestic
Adult child abuse victims
Adult child abuse victims
Adult child abuse victims
Family violence
Family violence
Family violence

metabib.display_entry contains
select, mde.* from metabib.display_entry mde join config.display_field_map cdfm on cdfm.field=mde.field where mde.source=311994 and mde.field in (16,12,13,14) order by value;
     name | id | source | field | value
 subject_topic | 7430085 | 311994 | 14 | Adult child abuse victims
 subject_topic | 7430088 | 311994 | 14 | Adult child abuse victims
 subject | 7430094 | 311994 | 16 | Adult child abuse victims
 subject | 7430091 | 311994 | 16 | Adult child abuse victims Fiction
 subject | 7430092 | 311994 | 16 | FICTION / Romance / Suspense
 subject_topic | 7430086 | 311994 | 14 | FICTION / Romance / Suspense
 subject_topic | 7430087 | 311994 | 14 | FICTION / Thrillers / Domestic
 subject | 7430093 | 311994 | 16 | FICTION / Thrillers / Domestic
 subject_topic | 7430084 | 311994 | 14 | Family violence
 subject_topic | 7430089 | 311994 | 14 | Family violence
 subject | 7430095 | 311994 | 16 | Family violence
 subject | 7430090 | 311994 | 16 | Family violence Fiction
(12 rows)

I don't really get why it is showing all the duplicates.

The physical description also shows strange duplicate results.

Physical Description: print
436 pages ; 25 cm
436 pages ; 25 cm
436 pages ; 25 cm

Viewing the non search result based, non display field record detail view and everything looks fine.

Family violence > Fiction.
Adult child abuse victims > Fiction.
FICTION / Romance / Suspense.
FICTION / Thrillers / Domestic.
Adult child abuse victims.
Family violence.

Physical Description: 436 pages ; 25 cm

Hello, I was trying to figure out the duplicates, and it looks like the display fields are provided by the sql function search.highlight_display_fields_impl(), and that uses a query that joins with search.best_tsconfig, and we have multiple entries for each display field id in search.best_tsconfig from setting up multiple synonym dictionaries. So I think our duplicate display fields entries are a different issue, not related to this bug. I'll start a new one.


Duplicate display field bug already exists at #1806724, sorry for the noise here.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers