Webclient: Search for Copies By Barcode Doesn't Populate Author

Bug #1739644 reported by John Yorio
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Won't Fix
Medium
Unassigned

Bug Description

Observed in 3.0.2

In order to duplicate this, you'll need a record where the author does not appear in a 100 field, but does appear in the 700.

To Reproduce:

In the web staff client go to Search for Copies by Barcode for an item attached to a bib record with the above criteria.
Make sure the Author column is visible on the results list. Note that it's blank.

What I expected to happen:

In the XUL client, got to Search for Copies by Barcode.
Make sure the Author column is visible on the results list. Notice that it shows the author.

Ideally, it'd show the Author in the web client, too.

Revision history for this message
Kathy Lussier (klussier) wrote :

The author also does not display as expected for these records on the Items Out interface. I didn't check others.

It looks like the previous behavior was to use the first 700 field from the record when a 100 isn't present.

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
Cesar V (cesardv)
Changed in evergreen:
assignee: nobody → Cesar V (cesardv)
Revision history for this message
Jason Etheridge (phasefx) wrote :

I believe we used reporter.super_simple_record (so for author: tags 100a, 110a, 111a) here as a placeholder until Display Fields are ready. The XUL client is essentially using MODS via MVR's (which we want to get rid of).

Revision history for this message
Rogan Hamby (rogan-hamby) wrote :

Following up on what Jason said I think this is the correct behavior. If we had an additional fall through I'd vote for a statement of responsibility from the 245 before using added entries. Just my .02 dinars.

Revision history for this message
Elaine Hardy (ehardy) wrote :

I prefer not displaying the added entry (7xx) fields if there is no 1xx field. Many bib records with no 1xx field are visual material titles, so there really isn't a need to display a name access point. For print titles with editors, while it would be nice to display those, I don't really see it as necessary.

Displaying statement of responsibility would not be a viable solutions because of the complexity of some of the statements. A typical one for visual material: Grindstone Entertainment Group and Emmett/Furla Films present a Cheetah Vision Films production ; produced by Mark Ordesky, Jane Fleming, Randall Emmett, Curtis Jackson, Remington Chase, Jeff Rice ; written & directed by Scott Walker

Another reason not to use 245 |c when the main entry is not a 1xx field is that they often start with edited by or complied by. Or it can be flipped and have Daniel F. Boomhower, editor, depending what is on the chief source of information.

Revision history for this message
Cesar V (cesardv) wrote :

Not being an expert on MARC specs or cataloging, and given the feedback I've gotten... I'll probably just venture to say that instead of perhaps making things confusing (IMO) by stuffing 7xx field names under a label of "author" in the webclient when technically it's not an "author"... might it be more appropriate to instead maybe just add another display field or column for those names found in the 7xx...?

I'll note that the names in the 7xx are currently searchable via an 'author' search and sometimes display as "author" when a bib record doesn't have a 100 tag. So probably a more open discussion is needed to come to a consensus on what that data's behavior should be.

Changed in evergreen:
assignee: Cesar V (cesardv) → nobody
Michele Morgan (mmorgan)
tags: added: webstaffcolumns
Revision history for this message
Elaine Hardy (ehardy) wrote :

Since there can be a large number of 7xx fields, I don't know that having a column for them would help. Visual material and sound recording records can have more than 10 7xx fields.

tags: added: displayfields
removed: webstaffcolumns
tags: added: webstaffcolumns
removed: webstaffclient
Revision history for this message
Terran McCanna (tmccanna) wrote :

I asked on the catalogers' list and the feedback I got was that the existing behavior (NOT using the 700 field) is best.

Changed in evergreen:
status: Confirmed → Opinion
status: Opinion → Won't Fix
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.