Bug 10456 - z3950NormalizeAuthor and z3950AuthorAuthFields cause problems for MARC21 (and are sloppily written)
Summary: z3950NormalizeAuthor and z3950AuthorAuthFields cause problems for MARC21 (and...
Status: CLOSED INVALID
Alias: None
Product: Koha
Classification: Unclassified
Component: Z39.50 / SRU / OpenSearch Servers (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Galen Charlton
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-13 05:17 UTC by David Cook
Modified: 2023-12-28 20:42 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Cook 2013-06-13 05:17:07 UTC
Currently, if you've turned on z3950NormalizeAuthor and you have MARC21 records, you're going to get errors in the sub MARCfindbreeding in addbiblio.pl.

It's because...

1) Koha checks the imported MARC record for a field nominated by biblio.author (which is 100$a in most MARC21 installs). If that nominated tag is found in the imported MARC record, it will try to create a new empty field with the same tag (and no indicators).

2) Then, regardless of the outcome, it will try deleting that old field from the record.

3) Then, for each of the tags in z3950AuthorAuthFields, it will try taking the new $field (without checking to see if it's actually already been created) and filling it with a re-arrangement of subfield values from the old field. 

4) Then, after it has tried adding all the subfields, it will try to insert the $field back into the $record (again, without checking to see if there is even a valid $field MARC object in the first place). 

Steps 3 and 4 cause Koha to get upset. 

Personally, I don't see the utility of "normalizing" the author, but I'm not familiar with UNIMARC. 

From a coding point of view, I think this section of code could benefit from some error-checking.

From the point of view of a MARC21 user, I'm tempted to just wrap it with a MarcFlavour check, and ignore it since it should never be used by MARC21 users.
Comment 1 David Cook 2013-06-13 07:02:52 UTC
Silly me...I should've checked master more thoroughly. There is already a check to make sure that the marcflavour is UNIMARC.

However, I think it would still be a good idea to re-visit this bit of code. There are no checks to make sure that $field is initialized as a MARC object before creating it. 

It seems to be a bizarre bit of code...
Comment 2 David Cook 2022-12-06 06:27:09 UTC
Closing this due to age