It would be nice if updated frameworks were available for download in some way. As frameworks are periodically updated in Koha to stay up-to-date with Library of Congress changes. it becomes difficult for existing installations to know about/receive those updates. While it is possible for existing installations to monitor bugs and see what the changes are, they don't receive those updates in the frameworks with an upgrade. This requires a library to seek out the bugs and do manual updates. There may be a number of ways to alert a library that updates are available and/or provide a download of the new framework. Perhaps there could be an alert in Administration that says updates are available, with a link to download the new framework from somewhere. This way a library can choose whether to overlay or manually update a framework as needed.
Conversation on Mattermost with various ideas https://chat.koha-community.org/koha-community/pl/jc5b4dp9x3rsmxbtayson9wxrc
I would totally love this! Our default framework (the only we use) is very out of date--I just manually update them when I think to do it, with fields I know we'll use, etc., etc. It would be simple for me to take the time to compare my existing to the latest available, document what I've changed that I want to keep, import the latest framework and then modify as needed. If it were possible to protect tags and/or subfields upon overlay, that would be the dream!!
Created attachment 170746 [details] [review] Bug 37738 - Framework update accessibility for existing installations See misc/maintenance/marc_framework_diff.pl --help
Hi! I just a few days ago implemented a similar (or maybe the same) feture you just requested. We use this for our clients to first diff our marc frameworks (compare them side-by-side for differences) and synchronize the framework definitions. It would be utterly painful to deal with a dozen marc frameworks without tooling like this. See the attachment for the perldoc on how to use it and what features are available. I was thinking of making this a Koha-plugin, but since there is some desire for the feature, maybe it could get into the Koha-core even. Any funding/help would help us get there. See also the picture for how the diff currently looks like. It would be better as a HTML table.
Created attachment 170747 [details] MARC framework diff in action
Created attachment 170754 [details] [review] Bug 37738 - Framework update accessibility for existing installations See misc/maintenance/marc_framework_diff.pl --help
I do like the ability to compare frameworks and I think this should be incorporated. This does require terminal access to use it, which is perhaps not as accessible to the average user. It also doesn't alert the user through the staff interface a framework update is available. So while this is a good start, perhaps doesn't quite answer the primary question of accessibility.
(In reply to Esther Melander from comment #7) > I do like the ability to compare frameworks and I think this should be > incorporated. This does require terminal access to use it, which is perhaps > not as accessible to the average user. It also doesn't alert the user > through the staff interface a framework update is available. So while this > is a good start, perhaps doesn't quite answer the primary question of > accessibility. You are 100% correct. Could you specify a bit more in-depth, what you mean with a "MARC framework update"?
(In reply to Olli-Antti Kivilahti from comment #8) > (In reply to Esther Melander from comment #7) > > I do like the ability to compare frameworks and I think this should be > > incorporated. This does require terminal access to use it, which is perhaps > > not as accessible to the average user. It also doesn't alert the user > > through the staff interface a framework update is available. So while this > > is a good start, perhaps doesn't quite answer the primary question of > > accessibility. > > You are 100% correct. > > Could you specify a bit more in-depth, what you mean with a "MARC framework > update"? Hi Olli-Antti, we're talking about the MARC21 updates that are done on the default framework (see for example bug 37114). These are done only in the installer files. Since we don't know if existing libraries have customized their frameworks, we don't update existing frameworks. We're looking for a way for libraries to be able to choose to update their frameworks or not.
This is a topic I've been interested in over the years. 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. -- With this patch, if a lot of this code was moved into modules, then it would be easy to show the diff on the web or on the command line.
(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?