Bug 20522 - Fields with only one $9 subfield are removed
Summary: Fields with only one $9 subfield are removed
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: Main
Hardware: All All
: P5 - low trivial (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 5683
Blocks:
  Show dependency treegraph
 
Reported: 2018-04-05 07:23 UTC by Frédéric Demians
Modified: 2018-06-15 09:39 UTC (History)
4 users (show)

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


Attachments
Bug 20522: Fields with only one $9 subfield are removed (2.00 KB, patch)
2018-04-05 07:56 UTC, Frédéric Demians
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Frédéric Demians 2018-04-05 07:23:31 UTC
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.
Comment 1 Frédéric Demians 2018-04-05 07:56:00 UTC
Created attachment 73676 [details] [review]
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...
Comment 2 Mark Tompsett 2018-04-10 23:31:02 UTC
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.
Comment 3 Frédéric Demians 2018-04-11 06:30:42 UTC
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.
Comment 4 Fridolin Somers 2018-04-30 15:28:11 UTC
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
Comment 5 Marcel de Rooy 2018-05-14 08:54:23 UTC
Wouldn't it be easier/safer to add the UNIMARC exception "010 with $9" instead of completely removing the code?
Comment 6 Fridolin Somers 2018-05-14 14:38:03 UTC
(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.
Comment 7 Aurélie 2018-06-15 08:14:58 UTC
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
Comment 8 Frédéric Demians 2018-06-15 09:39:37 UTC
I'm not in favor of this solution. The issue must be solved at its root rather than fixed afterward.