Bug 36054 - Don't mark MARC21 005 as mandatory in frameworks now that AddBiblio and ModBibilio will set it no matter what
Summary: Don't mark MARC21 005 as mandatory in frameworks now that AddBiblio and ModBi...
Status: Passed QA
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement
Assignee: Phil Ringnalda
QA Contact: Kyle M Hall (khall)
URL:
Keywords:
Depends on: 35993
Blocks:
  Show dependency treegraph
 
Reported: 2024-02-08 20:47 UTC by Esther Melander
Modified: 2024-09-27 13:57 UTC (History)
3 users (show)

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


Attachments
Bug 36054: Don't mark MARC21 005 as mandatory in frameworks now that AddBiblio and ModBibilio will set it no matter what (2.35 KB, patch)
2024-06-07 20:15 UTC, Phil Ringnalda
Details | Diff | Splinter Review
Bug 36054: Don't mark MARC21 005 as mandatory in frameworks now that AddBiblio and ModBibilio will set it no matter what (2.44 KB, patch)
2024-09-27 09:34 UTC, Marcel de Rooy
Details | Diff | Splinter Review
Bug 36054: Don't mark MARC21 005 as mandatory in frameworks now that AddBiblio and ModBibilio will set it no matter what (2.48 KB, patch)
2024-09-27 13:57 UTC, Kyle M Hall (khall)
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Esther Melander 2024-02-08 20:47:12 UTC
This requires having some bib records where the 005 is blank or missing.

To recreate:
1. Edit the default framework and uncheck the mandatory box for the 005 and save.
2. Find a bib record with a missing/blank 005 and edit the record in the basic editor.
3. See that the 005 is blank and is not required. Save

The record saves as it should.

4. Now edit the record again and switch to the Advanced Editor.
5. See that the 005 is missing.
6. Save.

Save fails and gives an error statement "Record structure invalid, cannot save."

Ideally records should have a 005. If this is a truly required field for Koha to function, then the ability to mark the field not mandatory should be disabled. Along with this, the ability to delete the field should be prevented (see bug 35135). Regardless, this is inconsistent behavior where it works in one place and not another.
Comment 1 Marcel de Rooy 2024-02-09 07:12:52 UTC
Please see bug 35993. This should ensure that we always store 005 in new or modified records. (Note that most records without 005 are coming from ACQ.) I guess that it will also resolve this bug.

Apart from that, you might wanna insert 005 in all catalogue records where it is missing. touch_all_biblios or some smarter approach?
Comment 2 Esther Melander 2024-02-09 16:02:54 UTC
Missing 005's are also happening with migrated dated or large batch imports.

Yes, touch all biblios can fix the missing 005.

Does bug 35993 prevent the ability to delete the tag in the framework configuration or allow the tag to not be marked mandatory? Perhaps indirectly. It may be helpful to make the control tags more explicitly required in frameworks, in general.
Comment 3 Marcel de Rooy 2024-02-12 07:05:01 UTC
(In reply to Esther Melander from comment #2)
> Missing 005's are also happening with migrated dated or large batch imports.

These also go via AddBiblio and ModBiblio. So should be fine with 35993.

> Does bug 35993 prevent the ability to delete the tag in the framework
> configuration or allow the tag to not be marked mandatory? Perhaps
> indirectly. It may be helpful to make the control tags more explicitly
> required in frameworks, in general.

No, thats not in the scope of 35993. You might open a new report for it. But note that it does not matter much for 005 now actually. It will be updated always regardless of editor settings. But would be good to not allow what you say.
Comment 4 Phil Ringnalda 2024-04-05 18:28:36 UTC
(In reply to Esther Melander from comment #0)
> This requires having some bib records where the 005 is blank or missing.
> 
> To recreate:
> 1. Edit the default framework and uncheck the mandatory box for the 005 and
> save.

For this step, to get the described behavior, you must have unchecked the mandatory box for 005's single subfield, @, rather than the mandatory box for 005 itself.

In general in the basic editor, a mandatory field without any mandatory subfield means "Field nnn is mandatory, at least one of its subfields must be filled" even if it only has one defined subfield, but it makes an exception for control fields, and treats a mandatory control field without the @ subfield as mandatory as being... not mandatory. That makes no sense.

In the advanced editor, a mandatory field without any mandatory subfields means that you must have the field, and because you can't have a field with no subfields, you must have a subfield, so if 005 is mandatory you have to have it and the only subfield it has.

Going the other way, making 005 not mandatory but its only subfield mandatory, would have put you in the difference between bug 25962 and bug 32722 since the advanced editor thinks mandatory subfield in non-mandatory tag means it's mandatory only if you add the field, and the basic editor thinks the subfield is mandatory and since you have no way to remove the tag, that means both are mandatory, so you would have been able to save in the advanced editor but not the basic editor.

Unchecking both just works: both editors will save without error if you don't touch it, both will add it if you choose to, and once bug 35993 lands both will create it when you save without it.
Comment 5 Phil Ringnalda 2024-04-26 16:36:24 UTC
Bug 26820 was about the way that the mandatory/important framework flags are ignored at the field level for 000-009, though it didn't quite realize it at first.

Rather than a duplicate, it wouldn't be unreasonable to make this dependent on bug 35993 and then stop shipping frameworks with 005 as mandatory, since with bug 35993 it will be filled out no matter what you do or don't do with it (and whatever you do with it will be overwritten, but having one read-only field just because it will be overwritten seems excessive).
Comment 6 Phil Ringnalda 2024-06-07 20:15:25 UTC
Created attachment 167588 [details] [review]
Bug 36054: Don't mark MARC21 005 as mandatory in frameworks now that AddBiblio and ModBibilio will set it no matter what

With bug 35993, both AddBiblio and ModBiblio will add a missing 005 or update
an existing 005 to the current timestamp. That makes setting it as mandatory in
bib frameworks pointless: whether you remove it, blank it, or set it, what you
do doesn't matter because it will be set, and set to something different than
what you set.

Test plan:
1. Apply patch, reset_all
2. Administration - MARC bibliographic framework
3. In the Default framework row, Actions - MARC structure
4. In the 005 row, verify the Mandatory column says No
5. 005 row, Actions - View subfields
6. For the @ subfield, verify constraints says Not mandatory

Extra credit: Set EnableAdvancedCatalogingEditor to Enable and in both editors
try to save a record without a 005 or with one set to your choice of value, and
then in the MARC preview verify that no matter what there is always a 005 with
a value other than yours. Bonus for exporting a record, editing it with an
external editor to remove the 005, reimporting it, and verifying that the
imported record has a 005.
Comment 7 Marcel de Rooy 2024-09-27 09:34:22 UTC
Created attachment 172102 [details] [review]
Bug 36054: Don't mark MARC21 005 as mandatory in frameworks now that AddBiblio and ModBibilio will set it no matter what

With bug 35993, both AddBiblio and ModBiblio will add a missing 005 or update
an existing 005 to the current timestamp. That makes setting it as mandatory in
bib frameworks pointless: whether you remove it, blank it, or set it, what you
do doesn't matter because it will be set, and set to something different than
what you set.

Test plan:
1. Apply patch, reset_all
2. Administration - MARC bibliographic framework
3. In the Default framework row, Actions - MARC structure
4. In the 005 row, verify the Mandatory column says No
5. 005 row, Actions - View subfields
6. For the @ subfield, verify constraints says Not mandatory

Extra credit: Set EnableAdvancedCatalogingEditor to Enable and in both editors
try to save a record without a 005 or with one set to your choice of value, and
then in the MARC preview verify that no matter what there is always a 005 with
a value other than yours. Bonus for exporting a record, editing it with an
external editor to remove the 005, reimporting it, and verifying that the
imported record has a 005.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Comment 8 Kyle M Hall (khall) 2024-09-27 13:57:50 UTC
Created attachment 172115 [details] [review]
Bug 36054: Don't mark MARC21 005 as mandatory in frameworks now that AddBiblio and ModBibilio will set it no matter what

With bug 35993, both AddBiblio and ModBiblio will add a missing 005 or update
an existing 005 to the current timestamp. That makes setting it as mandatory in
bib frameworks pointless: whether you remove it, blank it, or set it, what you
do doesn't matter because it will be set, and set to something different than
what you set.

Test plan:
1. Apply patch, reset_all
2. Administration - MARC bibliographic framework
3. In the Default framework row, Actions - MARC structure
4. In the 005 row, verify the Mandatory column says No
5. 005 row, Actions - View subfields
6. For the @ subfield, verify constraints says Not mandatory

Extra credit: Set EnableAdvancedCatalogingEditor to Enable and in both editors
try to save a record without a 005 or with one set to your choice of value, and
then in the MARC preview verify that no matter what there is always a 005 with
a value other than yours. Bonus for exporting a record, editing it with an
external editor to remove the 005, reimporting it, and verifying that the
imported record has a 005.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>