https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37738
Olli-Antti Kivilahti <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |In Discussion --- Comment #11 from Olli-Antti Kivilahti <[email protected]> --- (In reply to Caroline Cyr La Rose from comment #9) > (see for example bug 37114) This clarifies a lot, thank you. (In reply to David Cook from comment #10) > I reckon the way to do this is to have a "reference" framework that is > automatically updated with Koha releases, and cannot be modified by web > users. - How about making the default framework read-only? Well we already customize it for our clients with plugins and authorised_values and translations, so maybe not. - So maybe a new read-only -framework, titled MARC21LOC, as there are also national guidelines, such as Finnish guidelines for MARC21, and RDA-Fin. UNIMARC is needed too. This needs to be set per-system, maybe even per-record. A solution would be for the individual MARC FW to trace an origin read-only FW. - Also MARC21 authorities frameworks need to be synced (and hard-coded limits removed). - The Koha installation, as it is configured to trace a MARC-variant, and later can be changed from a syspref, needs to be told during updatedatabase.pl that new changes need to be incorporated to existing frameworks. I guess we could use DB triggers to enforce that change-log is created, even tho I personally dislike DB triggers as they put logic to the "wrong" place. A better approach is to define good Koha::MARCFramework APIs, which transparently deal with all these during CRUD-operations, embedded within SQL transactions that can be rolled back during errors. - Koha staff client mainpage.pl and a staff email notification should let the library know that there are changes that need to be synced to MARC FWs using the supplied GUI MARC FW diffing tool. - Some changes can be incorporated without user interaction, such as adding new fields/subfields, title/term renamings (I presume LOC wouldnt change the spirit of a field, but instead the letter of a field) Does this leave any situation where user interaction is needed? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. _______________________________________________ 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/
