To replicate: 1. Ensure there is a complete default framework and a brief framework like fast add. 2. Find a bibliographic record where there are many fields used (so it is obvious whether the fast add framework has been applied or not). 3. Edit the record in the advanced editor. 4. Take note of the fields. Go to settings and select Fast Add as the framework. 5. Notice nothing happens, all the fields are still showing. 6. Save the record, see all the fields are retained. 7. Click on View to view the bibliographic detail and see the record appears unchanged. 8. Notice the bibliographic detail shows the framework as Fast Add, even though it displays all the fields. 9. Edit the record again in the advanced editor, check framework setting and save. Notice no changes. 9. Edit the record again in the advanced editor and see all the fields. Switch to the basic editor. See that the fast add framework is now applied and fields that shouldn't be there are now removed. The basic editor applies framework changes immediately upon changing. This is problematic if a framework is applied in the Advanced Editor and the changes are not properly applied. It could be a bit of surprise if the example record is edited in the future and data disappears when the basic editor opens. While the basic editor is doing what it is supposed to do, the advanced editor should also replicate the behavior when applying a new framework.
Instead of a bug to have the advanced editor mimic an undocumented feature that only happens because it's the easy way for the code to create the basic editor, how about a bug to have the basic editor not cause undocumented dataloss? The basic editor doesn't delete tags which are not in the framework. What it does is create a form by looping through the tags in the framework, creating an empty input for ones which don't exist in the record and a filled input for ones which do exist in the record. It doesn't even know that it didn't include all the tags that were in the record, since it only looks for "got anything for 364 subfield a?" rather than "got anything else I didn't ask about?" And then when *you* save the record, *you* delete them. Since the manual tells you not to edit the default framework, that plus the misfeature of deleting things not in the framework means that if you follow the instructions, and you import records from an external source, within six months of the time you install Koha the default framework becomes a dataloss trap that you have to somehow know to completely avoid.
I can see how the problem could be addressed through the Basic Editor. However, it is confusing in the Advanced Editor. If one can change or set the framework in the Advanced Editor, then there needs to be some kind visual representation or interaction to inform the user. For example if a framework does not include tag 500 and the user tries to add it, there should be a warning when the record is saved about data loss. The tag should not be retained nor displayed, otherwise why be able to select the framework in the Advanced Editor at all?
Why be able to select it? Because frameworks do other things besides the undocumented behavior of deleting tags from existing records in the basic editor.
I would think, that for anyone who does cataloging, that ANY unwarned data loss is a huge deal. I think this is more noticed by ByWater team because we work with a lot of libraries that have multiple levels of catalogers, and work is done in both advanced and basic editors, and often by different people, so we pay particular attention when a partner points out that they are losing data. This has nothing to do with editing the default framework and how you should do it. It is about being able to add non-retained fields when working in a framework in the advanced editor. There absolutely should be a warning that the field being added is not part of the framework and the data will be lost. I'm not sure why a bug aimed at preventing data loss is the cause for such a strong and negative reaction - what would be the issue with correcting this?
Sorry. Being a ByWater partner in a consortium where catalogers range from full-time advanced editor users to elementary school library aides whose training is handed down third-hand at best, you would think I would have recognized the data loss potential. It's filed as an enhancement, which is a bit low for a data loss bug, which ought to at least be major. And I still don't see what thing it's actually aiming to fix, only one possible fix presented not as a fix for a particular problem, but as something which must be done because it's self-evident that doing it is the right thing to do. Is it "the Fast Add framework is alphabetically right next to one we use all the time, and if we accidentally pick the wrong one then when someone opens it in the basic editor and saves, everything but the Fast Add fields are gone"? Or is it "when our advanced editor users need to upgrade a Fast Add record, even though it opens in the basic editor they will switch over to the advanced editor, and then if they forget to switch the framework away from Fast Add, a later edit in the basic editor will wipe out their upgrade"? Both of those could be fixed by just not showing the Fast Add framework in the framework chooser (and either refusing to open an FA record, or automatically switching frameworks, if someone tries to open an existing one), since Koha goes to great lengths already to avoid having you ever edit one there. Or is it something other than one of those?