Bug 12734 - Authority 001 should be set to authid in AddAuthority()
Summary: Authority 001 should be set to authid in AddAuthority()
Status: CLOSED DUPLICATE of bug 18014
Alias: None
Product: Koha
Classification: Unclassified
Component: MARC Authority data support (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Galen Charlton
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-08 03:14 UTC by David Cook
Modified: 2017-01-31 08:56 UTC (History)
1 user (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Cook 2014-08-08 03:14:44 UTC
In AddBiblio() (and other Biblio functions), we use _koha_marc_update_bib_ids() to set/reset the 999$c and 999$d to the biblionumber and biblioitemnumber.

In AddAuthority(), there is some handling for adding the authid to the 001, but it only happens if no $authid is supplied to the function, or if an $authid is provided and the record to be added doesn't have a 001.

Most of the time, this doesn't seem to matter...because the auth_header.authid value is used a lot of the time in Koha.

Moreover, rebuild_zebra.pl will reset the 001 for a record to auth_header.authid or zebraqueue.biblio_auth_number (depending on how the record is being indexed), so searching Zebra using the authid value will still work.

However, that means that the 001 in the MARC in the MySQL database can be different from the 001 in MARC the Zebra database.

This is a common scenario if you upload authorities using "bulkmarcimport.pl -keepids=035a". The 001 from the record will be moved to the 035$a leaving the record without a 001.

The authid (whether it's from a matched record or a newly calculated value) will be set in the database column and in the 001 in Zebra...but not in the MARC in MySQL.
Comment 1 David Cook 2014-08-08 03:31:32 UTC
This would be an easy fix after the fact as well.

We could have a little utility script that iterates through all authorities, checks if the 001 matches the authid. If it does, next record. If it doesn't, move the current 001 to something like the 035$a, then change the 001 to the authid. Easy!

It could be time and I/O intensive for large authority databases, but...it could be run in off hours, and it would only need to be done once after we normalize how we handle the 001 in authority records.
Comment 2 Marcel de Rooy 2017-01-14 11:12:56 UTC
From AddAuthority:

unless ($record->field('001') && $record->field('001')->data() eq $authid){
        $record->delete_field($record->field('001'));
        $record->insert_fields_ordered(MARC::Field->new('001',$authid));
}
Comment 3 Marcel de Rooy 2017-01-14 11:15:46 UTC
Oops, not read very well.
Comment 4 Marcel de Rooy 2017-01-31 08:56:13 UTC
Closed in favor of bug 18014 and bug 12722

*** This bug has been marked as a duplicate of bug 18014 ***