https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32722 --- Comment #27 from Phil Ringnalda <phil@chetcolibrary.org> --- Three more things for whoever patches this to be wary of: Because bug 26820 exists, for fields below 010 the subfield has to be mandatory to have it enforced. For UNIMARC bibliographic frameworks that means that right now the mandatory "000" (the leader) and 001, the Record indentifier, are not being enforced. UNIMARC authority frameworks are not affected, because both the "000" field and its "@" subfield are marked mandatory, and 001 and its "@" subfield are correctly not marked mandatory because in authority records Koha will replace anything present in 001 with its own authid no matter what you do. Authority records don't have the same "collapsed" feature that bibliographic records do, so the only subfields that are visible when you first open the editor are mandatory subfields. That means that even for a mandatory field which has only one subfield, like 100, you should make both the field and the subfield mandatory, so that it is open for editing from the start. Currently it feels like a trap when you are told you skipped the mandatory field 100, and even when the error message sends you to the field, there's still no open place to edit it. The 099 versus 942 thing is confusing, but critical. In the default framework both 099$t and 942$c are mapped to biblioitems.itemtype; 942$c uses the authorized value itemtypes, which is correct, while 099$t uses the authorized value TYPEDOC which has no values. In the Fast Add framework, 099$t is mapped to biblioitems.itemtype but 942 and 942$c do not exist, and 099$t uses the authorized value TYPEDOC, which gives an error in "MARC bibiliographic framework test" because a framework has to have something mapped to bibilioitems.itemtype which uses the authorized value itemtypes. Given that the name of 099 is "local dates" and it is the only place that there is something mapped to biblio.datecreated and biblio.timestamp, it's a reasonable guess that it was created to have those two things, and then someone stuck in some but not all of the things from 942, and then things escalated with bug 30373 using the wrong authorized value for itemtypes, and now since 22.05 we've created an AV with no values in both UNIMARC and MARC21 installs. If you alter the AV for 099$t to itemtypes, and then select a different one than you select for 942$c, you get biblioitems.itemtype "BK | CF" which I bet blows up pretty spectacularly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.