[Bug 20522] New: Fields with only one $9 subfield are removed
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20522 Bug ID: 20522 Summary: Fields with only one $9 subfield are removed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs@lists.koha-community.org Reporter: frederic@tamil.fr QA Contact: testopia@bugs.koha-community.org There is a sort of cleaning functionnality in Koha when saving a biblio record. If a field contains only a $9 subfield, the whole field is removed. There is a logic there since $9 is generally used in Koha for storing authority record ID. However there may exist fields perfectly valid containing only a $9 subfield. This is a case in Unimarc 010 field. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20522 --- Comment #1 from Frédéric Demians <frederic@tamil.fr> --- Created attachment 73676 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=73676&action=edit Bug 20522: Fields with only one $9 subfield are removed There is a sort of cleaning functionnality in Koha when saving a biblio record. If a field contains only a $9 subfield, the whole field is removed. There is a logic there since $9 is generally used in Koha for storing authority record ID. However there may exist fields perfectly valid containing only a $9 subfield. This is a case in Unimarc 010 field. To test in Unimarc: 1. Add a $9 sufield to 010. You can name it "ISBN d'une livraison de publication en série" 2. Create a new biblio record. Fill 010 $a and $9 subfields. Save the record. => Everything is fine: $a et $9 are properly stored. 3. Modify the previous record, and remove $a subield. Save the record. => 010 field is removed 4. Apply the patch. Repeat 2-3 steps. Observe that a 010 field containing only a $9 subfield can be saved properly. To test in MARC21: Replace 010 filed by any other field... -- 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=20522 Frédéric Demians <frederic@tamil.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- 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=20522 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20522 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mtompset@hotmail.com Depends on| |5683 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5683 [Bug 5683] link_bibs_to_authorities.pl can corrupt records -- 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=20522 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |In Discussion --- Comment #2 from M. Tompsett <mtompset@hotmail.com> --- The question is whether this is a correction of a prior mistake or is this the wrong solution for some reason and if so what. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20522 --- Comment #3 from Frédéric Demians <frederic@tamil.fr> --- Thanks for the link to bug 5683. My patch equals to revert it. I'm totally unable to evaluate the consequences. I even don't understand in the first place why an empty field (a field with no subfield) or $9 only field would be an issue. -- 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=20522 Fridolin SOMERS <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fridolin.somers@biblibre.co | |m --- Comment #4 from Fridolin SOMERS <fridolin.somers@biblibre.com> --- We at Biblibre have the same issue for our libraries wanting 010$9. Note that when creating a new records, AddBiblio is called and it does not contain this code that removes $9. Bug 5683 says : " It seems that running link_bibs_to_authorities.pl can corrupt records in cases where there is a heading with only subfield 9 populated, since the script automatically removes all subfield 9s. " So I understand that link_bibs_to_authorities.pl must handle the case where field has no subfield anymore, not ModBiblio that is also used by cataloguing page. I'd say it must be fixed in LinkBibHeadingsToAuthorities(). PS : we must also revert tests in t/db_dependent/Biblio.t -- 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=20522 --- Comment #5 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Wouldn't it be easier/safer to add the UNIMARC exception "010 with $9" instead of completely removing the code? -- 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=20522 --- Comment #6 from Fridolin SOMERS <fridolin.somers@biblibre.com> --- (In reply to Marcel de Rooy from comment #5)
Wouldn't it be easier/safer to add the UNIMARC exception "010 with $9" instead of completely removing the code?
Or maybe code must check that field is linked to an authority type. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20522 Aurélie <aurelie.berut@enssib.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aurelie.berut@enssib.fr --- Comment #7 from Aurélie <aurelie.berut@enssib.fr> --- The French Bibliographic Agency (Abes) advocates that the use of $8 is not recommended. If a temporary sub-field for these data must be choosen, the best is to choose a letter, as the use of letters in UNM is free - contrary to the numbers sub-fields. It could be $y. Context : Earlier this year, the PUC made this subfield $8 a generic to all fields of the Unimarc B format. Its meaning is very precise: "Part of the resource concerned by the data recorded in the field" ("Reserved for Materials specified"); it is in practice especially applicable to certain descriptive fields even if it may be also used for identifiers. Do you agree with $y ? Enssib Team -- 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=20522 --- Comment #8 from Frédéric Demians <frederic@tamil.fr> --- I'm not in favor of this solution. The issue must be solved at its root rather than fixed afterward. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org