tpac does not display publisher when there are multiple subfield b's in the 260 field

Bug #1009980 reported by Kathy Lussier
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Medium
Unassigned

Bug Description

Evergreen version: 2.2

If a record has multiple subfield b's in the 260 field, tpac will not display the publisher or publication date in the record details page and will not display the publisher on the search results page. I have verified issue this in several tpac catalogs (C/W MARS, NOBLE, Bibliomation.)

A sample record can be seen at http://bark.cwmars.org/eg/opac/record/2461346.

It looks like jspac displayed the first subfield b in these situations.

Revision history for this message
Ben Shum (bshum) wrote :

Bleh, confirmed. Never noticed this but it happens in search results too, if you have publisher showing as a field there.

My guess is that we need some extra logic applied in the marc extraction script for publisher data. I think that's in a file like misc_util.tt2.

Changed in evergreen:
status: New → Confirmed
milestone: none → 2.2.0
importance: Undecided → Medium
Revision history for this message
Mike Rylander (mrylander) wrote :

Perhaps this may lend some weight to the idea I and others have floated to codify in configuration those fields that should be extracted for display. That idea was given some flesh with a topic branch from Dan Scott:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbs/ttopac-metabib-display-field

Changed in evergreen:
milestone: 2.2.0 → 2.2.1
Revision history for this message
Kathy Lussier (klussier) wrote :

We just found that this also happens with multiple 505 fields, and I would guess any other repeatable field that we might want to display in the search results or record detail page.

Revision history for this message
Dan Scott (denials) wrote :

See user/dbs/lp1009980 in working for a completely untested stab in the direction of just making the current approach more robust.

I think Liam Whalen actually had built a branch that went so far as to grab the definitions for the various fields from the database and use them in the TPAC, at the TPAC hackfest at Windsor, but I'm having trouble tracking that down :/

Revision history for this message
Dan Scott (denials) wrote :

Ah, Liam's branch is at user/ldw/ttopac-metabib-display-field in the working repo - thanks Liam!

Revision history for this message
Dan Scott (denials) wrote :

Also, I've tested my branch and force-pushed some changes. I think my branch is probably the right approach for a bug-fix for 2.2.x (it tries to leave the underpinnings the same, and just fixes the identified bugs) and something closer to Liam's approach (so that we define our XPaths in one place) is the right way to go for 2.3.x.

Dan Scott (denials)
tags: added: pullrequest
Revision history for this message
Michael Peters (mrpeters) wrote :

Which branch is the pullrequest for? Not sure which needs a test and signoff.

Revision history for this message
Dan Scott (denials) wrote :

Hi Michael:

Sorry, to be clear I think my branch should be applied against both master and rel_2_2. Something better/smarter may come along for master/rel_2_3 later, but for now it would make sense to fix the known bugs and keep master and rel_2_2 in sync. In my opinion, anyway. Thanks for testing this stuff!

Revision history for this message
Ben Shum (bshum) wrote :

Tested denials code for user/dbs/lp1009980 and it appears to be working.

Pushing sign off at: user/bshum/lp1009980

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/lp1009980

Revision history for this message
Dan Scott (denials) wrote :

Thanks for the testing and sign-off, Ben!

Pushed to master and rel_2_2.

Changed in evergreen:
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.