https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32722
--- Comment #34 from Victor Grousset/tuxayo <[email protected]> --- Thanks a lot Phil for the analysis, now it's very very clear to me that the full issue is way beyond the pieces here and there that I understand about cataloging π΅βπ«π΅βπ«π΅βπ«π΅βπ«π΅βπ«π΅βπ«π΅βπ«π΅βπ«π΅βπ«π΅βπ«π΅βπ« (In reply to Phil Ringnalda from comment #22) > (In reply to Victor Grousset/tuxayo from comment #21) > > 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? > > That's comment 7: you cannot tell the difference between an existing install > which has a mandatory subfield in a non-mandatory field because it works > fine to make the field mandatory in the basic editor which is all they use, > and an existing install which has it that way because it works fine to make > the subfield mandatory only if the field has any other subfield used in the > advanced editor, which is all they use. Oh no, gone the hope of keeping the patch to finally have both editors behaving consistently. T_T I wonder how that didn't cause problems immediately to introduce the advanced editor with a different behavior than the basic one. (Perfect behavior actually IIUC. If "only" at the same time migrating the frameworks so MARC21 and UNIMARC have both their conformant handling of mandatory stuff) And having incompatibilities with the default frameworks and the preferred handling of mandatory subfields of the MARC flavors. Frameworks need to be in line with the editor to be fully in line with the MARC flavor. But it's not possible to be in line with both editors at the same time. π΅βπ« So now the advanced editor has been used long enough and frameworks have been tuned to it so it's not possible to easily fix the issue. aaaaah >_< Given this: > Unlike the basic editor, the advanced editor already does exactly > what you want: if 120$a is mandatory > but 120 is not mandatory, then if you have no 120 in the > advanced editor you are free to save, > but if you have 120$b you are required to have $a. And given this: (In reply to Thibault KeromnΓ¨s from comment #5) > 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. We really have the default framework buggy with the advanced editor π±. Because the same problematic thing that would happen with the 1st patch to the basic editor is happening since a long time with the advanced editor. ---------------------- (In reply to Phil Ringnalda from comment #23) > 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. Is that really what happened here? I get that there can be that impression from part of the situation[1]. But is the cause of the blocking here so overwhelmingly that? (without other significant factors) And the blocking reasons are so strong that it can be described with pretty much the strongest wording possible. Really? What about trying to get the basic editor and the advanced editor in line in how they handle mandatory fields? Maybe I totally misunderstood that there is this issue and that Jonathan's patch would get us most of the way there. Of course after some time, if there is no one that has the skills and availability to expand on that patch. (To make it switch behavior between UNIMARC and MARC21.) Then the fallback is to revert the changes in the default UNIMARC framework and resign about the 1st patch. [1] I think I feel it for different reasons. About how we are stuck with frameworks that can't work well with both editors at the same time and work well with standard usage of MARC21 and UNIMARC. Because stuff has landed and instances have modified their framework and it's not possible to fix without giving them trouble when they upgrade. Wait, thinking about it again, I don't get how until now for MARC21 and until bug 30373 for UNIMARC, the status quo wasn't already trouble. Which has to be weighed against making an framework migration that will cause some manual work for a not that big share of instances. For which a big part of these customized their framework so there is reasonable hope most will not have much trouble doing adjustments again. Does that makes sense? (for a follow-up ticket) (keeping in mind the preface of this comment, there are big chances it doesn't make sense ^^") -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
