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.
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.
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)); }
Oops, not read very well.
Closed in favor of bug 18014 and bug 12722 *** This bug has been marked as a duplicate of bug 18014 ***