Bug 12734

Summary: Authority 001 should be set to authid in AddAuthority()
Product: Koha Reporter: David Cook <dcook>
Component: MARC Authority data supportAssignee: Galen Charlton <gmcharlt>
Status: CLOSED DUPLICATE QA Contact: Testopia <testopia>
Severity: normal    
Priority: P5 - low CC: m.de.rooy
Version: Main   
Hardware: All   
OS: All   
See Also: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12722
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8579
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:

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 ***