When creating a new bibliographic MARC21 framework from an old one, any default values set for subfields in the old framework are not ported to the newly created framework. They have to be reset. To reproduce: - Set a default value in an existing bibliographic MARC21 framework, e.g. 040$a to your institution's MARC code. - Create a new framework based on that one - Create a new record using that new framework: the default value is not set. - Upon checking the database table marc_subfield_structure (e.g. WHERE tagfield = 40 and tagsubfield = 'a'), notice there is no defaultvalue set in that subfield in the new framework. This issue occurs in a package install of version 16.05 on Debian.
This is still valid. Tested with default values for 245$a and 952$a (valid branchcode)
Created attachment 103207 [details] [review] Bug 17232: Make sure all fields are copies when creating a new framework from another Some digging revealed that when you create a new framework and use an old framework as the base, some information would not be copied to the new framework as they were missing from the SQL command used here. - Tag: Important - Subfield: - Important - Default value - Max length - Is a URL - Link To test: - Pick one of the existing frameworks and change the fields listed above. Take note of what you changed. - Create a new framework - Go to "Marc structure" of the new framework - You are offered the option to copy an existing framework - Use your prepared framework - Verify the fields weren't copied - your config was lost - Apply patch - Create another new framework - Repeat the duplication and tests - Verify that now all fields have been copied correctly
Created attachment 103314 [details] [review] Bug 17232: Make sure all fields are copies when creating a new framework from another Some digging revealed that when you create a new framework and use an old framework as the base, some information would not be copied to the new framework as they were missing from the SQL command used here. - Tag: Important - Subfield: - Important - Default value - Max length - Is a URL - Link To test: - Pick one of the existing frameworks and change the fields listed above. Take note of what you changed. - Create a new framework - Go to "Marc structure" of the new framework - You are offered the option to copy an existing framework - Use your prepared framework - Verify the fields weren't copied - your config was lost - Apply patch - Create another new framework - Repeat the duplication and tests - Verify that now all fields have been copied correctly Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> Good test plan, problem verified and fixed. Used ACQ fw
Created attachment 103746 [details] [review] Bug 17232: Make sure all fields are copies when creating a new framework from another Some digging revealed that when you create a new framework and use an old framework as the base, some information would not be copied to the new framework as they were missing from the SQL command used here. - Tag: Important - Subfield: - Important - Default value - Max length - Is a URL - Link To test: - Pick one of the existing frameworks and change the fields listed above. Take note of what you changed. - Create a new framework - Go to "Marc structure" of the new framework - You are offered the option to copy an existing framework - Use your prepared framework - Verify the fields weren't copied - your config was lost - Apply patch - Create another new framework - Repeat the duplication and tests - Verify that now all fields have been copied correctly Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> Good test plan, problem verified and fixed. Used ACQ fw Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Nice work everyone! Pushed to master for 20.05
backported to 19.11.x for 19.11.06
backported to 19.05.x for 19.05.11
(In reply to Lucas Gass from comment #7) > backported to 19.05.x for 19.05.11 Backporting this wasn't that good of an idea. This patch break duplicating subfields from another framework because it uses a field marc_subfield_structure.important and marc_tag_structure.important that doesn't exist yet in 19.05. The patch should be reverted in 19.05.
Also from 19.11 I believe or adapted. the important just needs to be removed.
Reverted from 19.05.x branch for 19.05.12 > it uses a field marc_subfield_structure.important and marc_tag_structure.important that doesn't exist yet in 19.05. That means no data fix needed because it just causes a crash right?