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

[Kathy Lussier]

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.

[Ben Shum (bshum)]

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.

[Mike Rylander (mrylander)]

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

[Kathy Lussier (klussier)]

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.

[Dan Scott (denials)]

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 :/

[Dan Scott (denials)]

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

[Dan Scott (denials)]

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.

[Michael Peters (mrpeters)]

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

[Dan Scott (denials)]

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!

[Ben Shum (bshum)]

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

[Dan Scott (denials)]

Thanks for the testing and sign-off, Ben!

Pushed to master and rel_2_2.