https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32722 --- Comment #1 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- You could also make them important maybe instead of mandatory. That gives a warning, but still allows to save. -- 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=32722 --- Comment #2 from Thibault Keromnès <thibault.keromnes@univ-paris8.fr> --- Hello Katrin, I'm not sure it's the best way, most mandatory subfields are just not relevant, depending on the document type. For instance: 120$a asks for the scale of a map, even if you're working on a movie. -- 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=32722 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- 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=32722 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |jonathan.druart+koha@gmail. |ity.org |com Severity|enhancement |normal --- Comment #4 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- This code is a nightmare! Thibault, can you confirm the patch works as you expect? I think it also impact "important" subfields, not sure it should... -- 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=32722 Thibault Keromnès <thibault.keromnes@univ-paris8.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |In Discussion --- Comment #5 from Thibault Keromnès <thibault.keromnes@univ-paris8.fr> --- Hey Jonathan, It does work as expected, but I've talked about it with Katerin & Aude, and it seems it would be a problem for Marc21 users. They consider a subfield to be mandatory whether the field itself is mandatory or not, so with this patch we would risk having records created without key informations. I should have started there, sorry. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32722 Thibault Keromnès <thibault.keromnes@univ-paris8.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32722 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |victor@tuxayo.net --- Comment #8 from Victor Grousset/tuxayo <victor@tuxayo.net> --- *** Bug 36576 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32722 --- Comment #9 from Victor Grousset/tuxayo <victor@tuxayo.net> --- Found via git bisect that it comes from commit: "Bug 30373: Fix visibility, authorised values and descriptions" ---- Raised severity because UNIMARC cataloguing doesn't work out of the box. It's a roadblock for small libraries that don't have a support company that has their own framework. Or don't know how to customize frameworks especially with such an unexpected default state. less severe effect: In the end, it makes impossible to setup a framework that follows the standard so one must manually enforce the mandatory subfields within an optional field. More meta issue: it's makes a pain to test UNIMARC patches. --- Current patch makes creation and edition of biblio records usable again :D Is it new the situation of mandatory subfields within an optional field? Or was there other occurrences before these IFLA UNIMARC updates? Another inconsistency in handling those cases is that even if thanks to the patch, the save isn't blocked, all the 4XX subfields have the red "Required" and are colored yellow. Undistinguishable from really mandatory ones. --- (In reply to Thibault Keromnès from comment #5)

It does work as expected, but I've talked about it with Katerin & Aude, and it seems it would be a problem for Marc21 users.

Would it work to have the change only affect UNIMARC? If MARC21 needs any change related to mandatory subfields, it could be another ticket. It's not the same impact on both standards. (In reply to Thibault Keromnès from comment #6)

Need for additional features on this patch: - an update on the database : in existing frameworks, for every mandatory subfields, make the corresponding field mandatory too (so the behaviour doesn't change by default)

Is the need of data migration only for existing libraries that didn't got installed with the recent (22.05/bug 30373) default framework? And those recently installed but with a different framework, like from their provider. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32722 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |In Discussion Assignee|jonathan.druart@gmail.com |koha-bugs@lists.koha-commun | |ity.org --- Comment #10 from Jonathan Druart <jonathan.druart@gmail.com> --- Just tell me what's needed. But be fast, I won't rebase this patch if there is a conflict. -- 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=32722 --- Comment #12 from Phil Ringnalda <phil@chetcolibrary.org> --- s/installs/UNIMARC installs/ -- 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=32722 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |30733 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30733 [Bug 30733] Simplify translatable strings -- 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=32722 --- Comment #14 from Victor Grousset/tuxayo <victor@tuxayo.net> --- (In reply to Jonathan Druart from comment #10)

Just tell me what's needed. But be fast, I won't rebase this patch if there is a conflict.

Don't do anything for now, just a question: is that a lot of changes to implement this?:

2. Enh: Add a third checkbox for subfields (in both UNIMARC and MARC21) for "Mandatory if tag is used".

Not sure but seems like we could get away with changing the condition here: https://git.koha-community.org/Koha-community/Koha/src/commit/8ab3989654b900... -- 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=32722 Mathieu Saby <mathsabypro@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mathsabypro@gmail.com --- Comment #16 from Mathieu Saby <mathsabypro@gmail.com> --- For UNIMARC, your patch is fixing our problems, except this little issue: - add data in 410$t (mandatory subfield in non mandatory field) - click on save - during 1 or 2 seconds, all the 4XX$t are colored in yellow, with no reason - but the record is saved I believe it can be fixed in a follow-up, so I add myt sign-off. BUT I cannot tell if your patch will cause problems to MARC21 installations, because I don't know well this format. Should the patch be tested and signed off also by a a member of MARC21 community ? ======================== Here is my test plan : **** Before patch : - Impossible to create a record without filling mandatory subfields in non mandatory fields Ex : create a new record with only the value "test" in 200$a Error message : "The following mandatory subfields aren't filled: Tag 020 subfield a Country Code in tab 0 Tag 021 subfield a Country Code in tab 0 etc" - Impossible to edit existing record without filling mandatory subfields in non mandatory fields Ex : - Identify a non mandatory subfield in a non mandatory field (for ex, 856$u) - Find a record with no value at all in this field - Edit the framework to make the subfield (but not the field) mandatory - Try to edit the record and to save it => Impossible, with this message : "The following mandatory subfields aren't filled:Tag 856 subfield u " **** After patch : - Identify a non mandatory subfield in a non mandatory field (for ex, 856$u) - Find a record with no value at all in this field - Edit the framework to make the subfield (but not the field) mandatory - Try to edit the record and to save it => possible, without alert Other tests : - Add data in non mandatory subfield of non mandatory field (205$a) => possible - Add data in non mandatory subfield of mandatory field (200$i) => possible - Delete data in non mandatory subfield of non mandatory field (210$c) => possible - Delete data in non mandatory subfield of mandatory field (200$f) => possible - Change data in mandatory subfield of mandatory field (200$a) => possible - Change data in mandatory subfield of non mandatory field (410$t) => possible - Delete a subfield of mandatory field but keeping the other subfields (810$b) => save - Delete all subfields of mandatory field (810$b) => impossible to save : "The following mandatory subfields aren't filled: The following fields aren't filled: Field 801 is mandatory, at least one of its subfields must be filled. " - Delete a mandatory subfield of a mandatory field (210$a) => impossible to save : "The following mandatory subfields aren't filled: Tag 200 subfield a Title Proper in tab 2 " - Add data in non mandatory subfield of non mandatory field (942$2) , but keeping blank the mandatory subfield (942$c) => impossible to save : "The following mandatory subfields aren't filled:Tag 942 subfield c Koha item type in tab 9 " -- 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=32722 Mathieu Saby <mathsabypro@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Signed Off -- 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=32722 Phil Ringnalda <phil@chetcolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |In Discussion --- Comment #19 from Phil Ringnalda <phil@chetcolibrary.org> --- MARC21 has for some time shipped defaults with 942$c, the biblioitems.itemtype, mandatory, but 942 not mandatory. Having itemtypes be mandatory is kind of a big deal, since patches that change code which assumes they are always defined to instead check for them being defined to avoid crashing will be rejected. So for MARC21 just changing the meaning of mandatory subfield in non-mandatory field wouldn't be acceptable. -- 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=32722 --- Comment #21 from Victor Grousset/tuxayo <victor@tuxayo.net> --- (In reply to Mathieu Saby from comment #20)

So the patch fixes Koha for Unimarc (I agree with Thibault), but causes problem for Marc21. What could be the solution?

comment 14 might be one. Which is a subpart of the proposal of comment 13. Which needs the addition that the advanced editor would also need to be changed to account for the "Mandatory if tag is used" switch. ----- (In reply to Phil Ringnalda (back in August) from comment #19)

So for MARC21 just changing the meaning of mandatory subfield in non-mandatory field wouldn't be acceptable.

It came in chat I think but I don't remember if there would be a problem: What about changing the MARC21 frameworks in existing installs and the installer to set to mandatory the fields containing a mandatory subfield? Then the current patch would have the basic editor behave identically to the advanced editor (and have a bit of code cleanup as bonus). And the difference of policies of the impact of mandatory subfields on fields will be managed by choosing or not to set the various fields as mandatory. Which will be already be done by the migration so current behavior wouldn't be changed. -- 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=32722 --- Comment #23 from Phil Ringnalda <phil@chetcolibrary.org> --- I happened to be reading bug 30373 again for something else, and noticed that Bernardo asked a couple of times for any input on mandatories. Shame he didn't get any then, so we wouldn't have this "OMG, they are marked as mandatory in the framework, we must support that, we can't ever revert anything that has landed!" problem. And in fact UNIMARC has a third flavor of mandatory, which he didn't include, "mandatory if another particular subfield is used." If we believe that Koha is required to enforce every use of "MA" (mandatory if applicable) in the Occurrence column of the UNIMARC spec, then along with making 036$a, 036$b, and 036$c mandatory if any 036 subfield is used, we also need to make 036$d, 036$m, and 036$2 mandatory if 036$p is used. But wait, there's more! There are also subfields which are MA because they are mandatory *unless* another subfield is used: 016$a, International Standard Recording Code, is mandatory if 016 is used unless 016$z, Erroneous ISRC, is used. And there's also mandatory content within mandatory fixed-length fields: if we are enforcing every use of the word "mandatory" in the UNIMARC spec, then we need to disallow blanks or fill characters in 100$a for positions 0-7, 22-24, and 26-29. And there's MA related to both the type of material, and whether or not you are doing FRBR cataloging: 101 is mandatory if the material has language and you aren't doing FRBR. So make my comment 13 step 2 into "Add a checkbox for 'Mandatory if any subfield is used,' a checkbox and text input for 'Mandatory if subfield [ ] is used,' a checkbox and text input for 'Mandatory unless subfield [ ] is used,' and for fixed-length fields a... Retract my comment 13 plan. The only reasonable plan is to say that "M" means mandatory and Koha should enforce it as mandatory (that's only 001, 100 and 100$a, 200 and 200$a plus local-to-Koha fields, what Thibault said we should keep in comment 0 except that 001 which is unambiguously mandatory is not mandatory in Koha's framework), and all instances of "MA" mean that catalogers should know when it is applicable, and if they create their own framework for things where it is applicable, they are free to make it mandatory in that framework. Of course, UNIMARC has so many flavors of mandatory that it has confused even them, so in the current spec (which is, amusingly, still not actually approved) they sometimes call a subfield which is mandatory if the optional field is used 'M' and most times call it 'MA', and in section 3.5.1 listing all the mandatory fields they include 801 despite the entire description of it saying that it is MA, only mandatory when it applies because you are sending your records to someone else and you need to at that point include the originating source field, because "In many cases this field will be generated automatically at the time of exchange." Of course, that's the UNIMARC equivalent of MARC21 040, where our default framework makes 040$c mandatory, though since my production install from 2014 has 040$d mandatory we apparently have had a hard time deciding just what we really should require (hint: nothing, since we don't actually use it for anything). -- 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=32722 --- Comment #25 from Phil Ringnalda <phil@chetcolibrary.org> --- And something clearly went wildly wrong with the mandatories for authorities. We have 676$b as mandatory, which is the "DDC number, End of a Range" which is utterly meaningless without the not-mandatory $a start of a range. Neither 676 nor any of its subfields have ever been mandatory in UNIMARC. We have 825$a as mandatory, which is a note saying that the current record was used as an example in a different record. That means you cannot create your first authority record, because it is required to have a note about how it was used as an example in another authority record, but this is your first. Stalemate. Anyone who remembers The Coach in Letterkenny knows how I'm feeling. -- 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=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.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32722 --- Comment #29 from Mathieu Saby <mathsabypro@gmail.com> --- Nice summary Phil! But for the issue with controlfields, I suppose that MARC21 is affected in the same way, as 000 and 003 are mandatory in default MARC21 framework, isnt it? Concerning the problem that is the subject of this ticket, it seems to me that the only reasonable action in the short to medium term is to forget the patch provided by Jonathan, and instead to edit the default UNIMARC framework in order to keep the "mandatory" flag on subfields only if the field itself is mandatory. But this course of action won't fit with the title of this bug. Should we close this one and create a new one with a better title ? -- 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=32722 --- Comment #31 from Mathieu Saby <mathsabypro@gmail.com> --- I am providing a patch removing mandatory subfields, except for 100$a and 200$a I also remove mandatory flag for 801 field. It is only mandatory in data exchange context. I don't have access to the original version of the ifla manual, but here is the french version : "Mandatory when exchanging bibliographic data. In many cases, this field will be generated automatically during the exchange." I am keeping 099 and 942 as they are. I believe they deserve their own bug, as they are not defined by UNIMARC standard, and their use need to be clarified in Koha. -- 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=32722 Mathieu Saby <mathsabypro@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |Needs Signoff -- 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=32722 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #175278|0 |1 is obsolete| | --- Comment #33 from Victor Grousset/tuxayo <victor@tuxayo.net> --- Created attachment 175340 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=175340&action=edit Bug 32722: Make several subfields and a field non mandatory in default UNIMARC biblio framework 801 should not be mandatory except in data exchange context (IFLA Manual) In UNIMARC several subfields are mandatory only if the field is used. This possibility is not available in MAR21, and Koha is currently not able to manage this information in a useful way : it blocks the validation of a record if the mandatory subfield is void, regardless of the mandatory status of the field. In consequence those subfields must be declared non mandatory in default framework. Test plan: 1/ Open a UNIMARC Koha without patch. Try to create a record with minimal information : 200$a and 100$a. A lot a alerts are displayed, preventing Koha to add the record 2/ Apply the patch 3/ Run reset_all or restart KTD (to remake a fresh koha from scratch) 4/ Try to create a record with minimal information : 200$a and a 100$a. There should only be 2 alerts, regarding 099$t and 942$c field. Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net> -- 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=32722 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off --- Comment #35 from Victor Grousset/tuxayo <victor@tuxayo.net> --- It works! :) Testing notes, when trying to save the result, I get Can't call method "metadata" on an undefined value at /kohadevbox/koha/cataloguing/additem.pl line 195 194: our $tagslib = &GetMarcStructure( 1, $frameworkcode ); 195: my $record = $biblio->metadata->record; 196: 197: output_and_exit_if_error( Given the patch changes, that doesn't look related. That will be something else to look after this >_< (In reply to Victor Grousset/tuxayo from comment #9)

More meta issue: it[the current issue] makes a pain to test UNIMARC patches.

And to test if UNIMARC cataloguing still works at all it seems 🫠 -- 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=32722 Martin Renvoize (ashimema) <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #175340|0 |1 is obsolete| | --- Comment #37 from Martin Renvoize (ashimema) <martin.renvoize@ptfs-europe.com> --- Created attachment 175589 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=175589&action=edit Bug 32722: Make several subfields and a field non mandatory in default UNIMARC biblio framework 801 should not be mandatory except in data exchange context (IFLA Manual) In UNIMARC several subfields are mandatory only if the field is used. This possibility is not available in MAR21, and Koha is currently not able to manage this information in a useful way : it blocks the validation of a record if the mandatory subfield is void, regardless of the mandatory status of the field. In consequence those subfields must be declared non mandatory in default framework. Test plan: 1/ Open a UNIMARC Koha without patch. Try to create a record with minimal information : 200$a and 100$a. A lot a alerts are displayed, preventing Koha to add the record 2/ Apply the patch 3/ Run reset_all or restart KTD (to remake a fresh koha from scratch) 4/ Try to create a record with minimal information : 200$a and a 100$a. There should only be 2 alerts, regarding 099$t and 942$c field. Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- 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=32722 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |release-notes-needed --- Comment #39 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I feel like the change turned out a bit different to what the bug title suggests. Can we get an update to communicate the change a little better? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32722 --- Comment #41 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- What about...: UNIMARC: Remove mandatory flag from some subfields and field in default bibliographic framework -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32722 --- Comment #42 from Victor Grousset/tuxayo <victor@tuxayo.net> --- Sounds good :) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32722 --- Comment #43 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Pushed for 25.05! Well done everyone, thank you! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32722 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|release-notes-needed | CC| |david@davidnind.com Text to go in the| |This updates the default release notes| |UNIMARC bibliographic | |record framework to remove | |the mandatory flag from | |some subfields and fields. | | | |For UNIMARC, several | |subfields are only | |mandatory if the field is | |actually used (MARC21 does | |not have this requirement). | | | | | |A change made to the | |default framework by bug | |30373 in Koha 22.05 meant | |that if the mandatory | |subfield was empty, and the | |field itself was optional | |(not mandatory), you | |couldn't save the record. | | | |For example, if field 410 | |(Series) is used (this is | |an optional field), then | |subfield $t (Title) is | |required. However, the way | |the default framework was | |set up (subfield $t was | |marked as mandatory) you | |couldn't save the record - | |as subfield $t was | |mandatory, even though the | |410 is optional. | | | |As Koha | |is not currently able to | |manage both the UNIMARC and | |MARC21 requirements without | |significant changes, a | |practical decision was made | |to configure the otherwise | |mandatory subfields as not | |mandatory. | | | |Important | |note: This only affects NEW | |UNIMARC installations. | |Existing installations | |should edit their default | |UNIMARC framework to make | |these changes (although, it | |is likely that they have | |already done so). --- Comment #44 from David Nind <david@davidnind.com> --- I've had a go at a release note. (I hope I got the example right.) Feel free to edit it, if I haven't correctly understood the change! (There are a lot of nuances here, but I tried not into too many details.) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32722 --- Comment #45 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Nice work everyone! Pushed to 24.11.x for 24.11.01 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32722 Fridolin Somers <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fridolin.somers@biblibre.co | |m Status|Pushed to oldstable |Needs documenting --- Comment #47 from Fridolin Somers <fridolin.somers@biblibre.com> --- I prefer not to backport to "very-old-stable" 23.11.x to avoid behavior change. -- You are receiving this mail because: You are watching all bug changes.