[Bug 41158] New: Field 001 replaced when importing records while using autoControlNumber system preference
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41158 Bug ID: 41158 Summary: Field 001 replaced when importing records while using autoControlNumber system preference Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs@lists.koha-community.org Reporter: anneli.osterman@koha-suomi.fi QA Contact: testopia@bugs.koha-community.org CC: m.de.rooy@rijksmuseum.nl Field 001 is replaced with records local biblionumber when importing records while using autoControlNumber system preference. This happens when using Z39.50 search/import and importing staged records. The manual tells about the system preference like this: "If set to ‘generated as biblionumber’, the control number will be filled with the biblionumber once the record is saved. This will not affect existing records that already have a value in 001. The existing value will be preserved." Replacing the 001 is not right because 001 should correspond to the value stored in field 003. The value in the field 001 is given by the cataloging agency marked in 003. Second problem is that if the 001 is replaced and the record has child records / component records, the connection between the host record and component record is lost. ShowComponentRecords system preference enables the linking component parts.
From the manual:
"Components to be displayed are found using the host record’s control number (001) in the child record’s 773$w subfield" How to reproduce the problem with staging: 1. Activate autoControlNumber system preference 2. Find or create a bibliographic record which field 001 is not the records biblionumber. 3. Export the record using the Save button at the Normal view 4. Go to Cataloging -> Stage record for import -> Find the file you just saved 5. Stage the file with a rule to find matches (for example ISBN). If you do not have record matching rules, please make one in Administration -> Record matching rules. Choose to replace the record if match is found. 6. View the batch and check from the Diff column's link that 001 looks the same at this point. 7. Import the batch into the catalog. 8. Go to the record you just updated (or replaced) and click the MARC preview 9. Notice that the 001 field is replaced with records biblionumber How to reproduce by using Z39.50 (this is not a straight forward replacing like it seems to be in staging): 1. Activate autoControlNumber system preference 2. Find or create a bibliographic record which field 001 is not the records biblionumber. 3. Choose under the Edit button "Replace record via Z39.50/SRU" 4. Search for the title from a database that has the same title and choose to import it 5. You will be transferd to the record's editing page 6. Notice that field 001 is empty 7. If the cataloger does not notice the empty field, it will be filled with biblionumber upon saving the record. You can also try both ways while the autoControlNumber is not activated to notice the difference. If the autoControlNumber system preference is deactivated, the 001 stays the same in staging and in Z39.50 the 001 field is not emptied. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41158 Lari Taskula <lari.taskula@hypernova.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lari.taskula@hypernova.fi --- Comment #1 from Lari Taskula <lari.taskula@hypernova.fi> --- We noticed this as well. An existing 001 should not be cleared upon importing the record. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41158 --- Comment #2 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Could the overlay rules help to resolve this? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41158 --- Comment #3 from Lari Taskula <lari.taskula@hypernova.fi> --- (In reply to Katrin Fischer from comment #2)
Could the overlay rules help to resolve this?
As for the Z39.50/SRU import, no, unfortunately the 001 is removed before the overlay rules take place. 001 removed at line 611 https://github.com/Koha-Community/Koha/blob/beac9eae8fc844cf1b289b0ca47bce32... overlay rules begin at line 669 https://github.com/Koha-Community/Koha/blob/beac9eae8fc844cf1b289b0ca47bce32... I didn't test if it works with a staged record import. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41158 --- Comment #4 from Lari Taskula <lari.taskula@hypernova.fi> --- It seems that during an autoControlNumber-enabled Z39.50/SRU import an existing 001 is replaced by Koha's biblionumber, but an existing 003 of the incoming record stays intact. If importing a record is configured to replace an existing 001 with biblionumber then 003 should also be replaced by MarcOrgCode. So either we retain both 001 and 003 from the incoming record, or replace them with biblionumber and MarcOrgCode. Perhaps we could have a configuration where one may select which organizations in 003 will retain their 001 control number in Koha. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon@bugs.koha-community.org