Subfield order in bib. record changes when editing authority
Bug #712490 reported by
Marjolein Kremer
This bug affects 8 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Medium
|
Unassigned | ||
3.1 |
Fix Released
|
Undecided
|
Unassigned | ||
3.2 |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Release 2.0 RC2:
After editing an authority the order of the subfield change in the linked bibliografic record.
Example:
Step 1:
Create a bib record, from field 100: create authority immediately
100 $a Opland $e ontwerper $0 (NL-AMISG)78
Validate and save bib record.
Step 2:
Manage authorities, Edit authority
100 $a Opland, (we added a comma)
Step 3:
Searching the catalog for the linked bib record
100 $0 (NL-AMISG)78 $a Opland, $e ontwerper
Is it normal that the $0 changes position?
no longer affects: | evergreen/2.7 |
no longer affects: | evergreen/2.8 |
Changed in evergreen: | |
assignee: | nobody → Bill Erickson (berick) |
Changed in evergreen: | |
milestone: | 3.0.1 → 3.0.2 |
Changed in evergreen: | |
milestone: | 3.0.2 → 3.0.3 |
Changed in evergreen: | |
milestone: | 3.0.3 → 3.0.4 |
Changed in evergreen: | |
milestone: | 3.0.4 → 3.0.5 |
Changed in evergreen: | |
milestone: | 3.0.5 → 3.0.6 |
Changed in evergreen: | |
milestone: | 3.0.6 → 3.0.7 |
Changed in evergreen: | |
milestone: | 3.0.7 → 3.0.8 |
Changed in evergreen: | |
milestone: | 3.0.8 → 3.1.3 |
Changed in evergreen: | |
milestone: | 3.1.3 → 3.1.4 |
Changed in evergreen: | |
milestone: | 3.1.4 → 3.1.5 |
no longer affects: | evergreen/2.12 |
Changed in evergreen: | |
milestone: | 3.1.5 → 3.1.6 |
Changed in evergreen: | |
milestone: | 3.1.6 → 3.2.1 |
Changed in evergreen: | |
milestone: | 3.2.1 → 3.2.2 |
Changed in evergreen: | |
milestone: | 3.2.2 → 3.2.3 |
Changed in evergreen: | |
milestone: | 3.2.3 → 3.3-beta1 |
status: | Confirmed → New |
Changed in evergreen: | |
assignee: | nobody → Dan Wells (dbw2) |
Changed in evergreen: | |
milestone: | 3.3-beta1 → 3.3-rc |
Changed in evergreen: | |
assignee: | Dan Wells (dbw2) → Jason Stephenson (jstephenson) |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
This has been the normal behaviour since the summer of 2010 when it
was initially implemented. As the content of the $0 subfield is not
expected to be read by any humans other than to cataloguers, we didn't
think this presented a problem.
Tools that display the contents of a 650, for example, should strip
the $0 subfield out no matter where it appears in the field, right?