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?

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.

(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.

(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.

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).

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.

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>

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>

Pushed for 24.11!

Well done everyone, thank you!

Enhancement, no 24.05.x backport