Undisplayed authority entries can cause the wrong entry to be highlighted in a browse list
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
New
|
Medium
|
Unassigned |
Bug Description
Evergreen version: all
Seen on two production systems that have linked authority records to each other and are displaying cross-references in the browse list.
When using authority records in the browse list, it's possible for pivot to match against an authority entry that, for some reason, does not display in the browse list. As a result, the browse list will highlight the wrong entry as the closest match to the entered search terms.
As an example, when doing an author browse for 'patter' on the C/W MARS catalog, the catalog is highlighting Pattengale, Kenneth as the browse entry that is the closest match when the expectation is that it would highlight Patterdale, Tom.
See the screenshot at http://
When running the following query for C/W MARS:
select * from metabib.
We found that the pivot was matching on patter bruce van, which does not display in the browse list.
Because the pivot term is not displayed in the list, the system chose to highlight the earlier term.
This particular example is also related to bug 1358392. The Patter, Bruce Van entry came from the 400 field of the authority record for Van Patter, Bruce. Ideally, this 400 field would display in the browse list with a See reference to Van Patter, Bruce, in which case, the proper entry would be highlighted in the list.
However, even when bug 1358392 is fixed, there may be other instances where an undisplayed authority entry is the pivot for a browse search (e.g. authority records that are not linked to any bib records). Consequently, I think we need to ensure that the pivot is an entry that displays in the list.
Changed in evergreen: | |
assignee: | nobody → Dan Wells (dbw2) |
tags: |
added: cat-authority opac-browse removed: browse |
Changed in evergreen: | |
assignee: | Dan Wells (dbw2) → nobody |
This may also be related to bug 1307632