webstaff bib editor errors when more than one authority control set is defined

Bug #1677245 reported by Galen Charlton
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
New
Medium
Unassigned

Bug Description

bibFieldByTag() in cat/services/tagtable.js currently acts as if there can never be more than one control set defined. As a consequence, if you load a bib record in a database that has multiple control sets, all bib fields display the link-to-authority button and the following error is logged to the browser console:

TypeError: Cannot read property 'bib_fields' of undefined
    at service.authorityControlSet.kwargs.bibFieldByTag (tagtable.js:388)
    at m.$scope.isAuthorityControlled (marcedit.js:483)
    at fn (eval at compile (angular.js:15126), <anonymous>:4:324)
    at m.$digest (angular.js:17828)
    at angular.js:18033
    at f (angular.js:6045)
    at angular.js:6324

Evergreen 2.11+

Tags: cataloging
Galen Charlton (gmc)
Changed in evergreen:
milestone: none → 2.12.1
importance: Undecided → Medium
Galen Charlton (gmc)
tags: added: cataloging webstaffclient
Changed in evergreen:
milestone: 2.12.1 → 2.12.2
Changed in evergreen:
milestone: 2.12.2 → 2.12.3
Changed in evergreen:
milestone: 2.12.3 → 2.12.4
Changed in evergreen:
milestone: 2.12.4 → 2.12.5
Kyle Huckins (khuckins)
Changed in evergreen:
assignee: nobody → Kyle Huckins (khuckins)
Revision history for this message
Bill Erickson (berick) wrote :

Can someone confirm these assumptions? More than one authority.control_set_bib_field can be used to control a given MARC tag? The control set in question, when checking to see if a given bib field is under authority control, is an attribute of the bib field itself? Would that be indicator 2?

Does bibFieldByTag() need to support an optional second controlSetId parameter indicating which control set the caller is interested in, in cases where there may be multiple control sets?

Revision history for this message
Mike Rylander (mrylander) wrote :

Bill,

That assumption is, currently, unfortunately, incorrect. There are cases where we don't have access to either a definitive control set id, or thesaurus (which is a proxy for control set). If the code where that's the case can be taught find (or maybe prompt for?) a thesaurus or control set, then the assumption can be made true. I suspect we may be able make it work by teaching some code to look at the field-local thesaurus subfield (IIRC that there is such a thing on the bib side), but that will require the cooperation of the cataloger...

HTH.

Changed in evergreen:
milestone: 2.12.5 → 2.12.6
Revision history for this message
Kyle Huckins (khuckins) wrote :

Removing myself as assigned as this task is starting to seem like it'll be a much larger task than initially expected.

Changed in evergreen:
assignee: Kyle Huckins (khuckins) → nobody
Revision history for this message
Mike Rylander (mrylander) wrote :

As an update to my earlier comment, we can, of course, assume a control set when only one exists for the instance. And, as a step toward fixing the general situation of context-less (heh) uses that we may want to prompt the user to resolve, we could globally load the list of context sets and if there's one and only one, do the right thing and use it.

Changed in evergreen:
milestone: 2.12.6 → 2.12.7
Changed in evergreen:
milestone: 2.12.7 → 2.12.8
Changed in evergreen:
milestone: 2.12.8 → 2.12.9
Changed in evergreen:
milestone: 2.12.9 → 2.12.10
Changed in evergreen:
milestone: 2.12.10 → 2.12.11
Kathy Lussier (klussier)
Changed in evergreen:
milestone: 2.12.11 → none
tags: removed: webstaffclient
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.