[Koha-bugs] [Bug 35591] New: bulkmarcimport.pl overwrites data if controlnumber eq authid

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35591

            Bug ID: 35591
           Summary: bulkmarcimport.pl overwrites data if controlnumber eq
                    authid
 Change sponsored?: ---
           Product: Koha
           Version: master
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5 - low
         Component: MARC Authority data support
          Assignee: koha-bugs at lists.koha-community.org
          Reporter: domm at plix.at
        QA Contact: testopia at bugs.koha-community.org

We had a lot of auth_header (~700.000). Then we decided to import a lot more
(10.000.000). We used --update together with a match-rule (based on 024) to
prevent duplicates. Which all worked well.

Until...

We discovered that ~30k of our old auths where overwritten with "random" data
(some other auths). What used to be "Graz" was now "Centro Editoriale
Valtortiano". After a bit of panic we were able to restore our old auths from a
backup.

But what happend?

The problem is that eg "Graz" had authid=777317. But "Valtortiano" has
001=00777317X. If you squint a bit (and ignore the leading 0s and the X at the
end) that's the same number!

And it seems that C4::AuthoritiesMarc::GuessAuthId($record) returns the value
of 001, which somehow causes the confusion. I'm not entirely sure yet, where
the X is stripped, but the effect is that auth-record 777317 is overwritten.

An easy fix would be to add a new command line param to bulkmarcimport to
either disable the call to GuessAuthId (which keeps with backwards compat, but
makes it easy for other people to also run into this problem); or to only call
GuessAuthId if the new param is set (saver, but changes behaviour)

If you agree that this is a problem, I can prepare a patch.

If we did something stupid, please enlighten us!

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are watching all bug changes.