Bug 17232 - When creating a new framework from an old one, several fields are not copied (important, link, default value, max length, is URL)
Summary: When creating a new framework from an old one, several fields are not copied ...
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Katrin Fischer
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks: 25861
  Show dependency treegraph
 
Reported: 2016-09-01 13:01 UTC by joachim.ganseman
Modified: 2021-12-13 21:08 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
20.05.00, 19.11.06


Attachments
Bug 17232: Make sure all fields are copies when creating a new framework from another (3.34 KB, patch)
2020-04-18 23:57 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 17232: Make sure all fields are copies when creating a new framework from another (3.46 KB, patch)
2020-04-20 19:27 UTC, Bernardo Gonzalez Kriegel
Details | Diff | Splinter Review
Bug 17232: Make sure all fields are copies when creating a new framework from another (3.53 KB, patch)
2020-04-27 10:22 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description joachim.ganseman 2016-09-01 13:01:06 UTC
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.
Comment 1 Katrin Fischer 2020-04-18 23:33:00 UTC
This is still valid. Tested with default values for 245$a and 952$a (valid branchcode)
Comment 2 Katrin Fischer 2020-04-18 23:57:32 UTC
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
Comment 3 Bernardo Gonzalez Kriegel 2020-04-20 19:27:37 UTC
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
Comment 4 Jonathan Druart 2020-04-27 10:22:36 UTC
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>
Comment 5 Martin Renvoize 2020-04-27 10:45:05 UTC
Nice work everyone!

Pushed to master for 20.05
Comment 6 Joy Nelson 2020-05-08 21:56:21 UTC
backported to 19.11.x for 19.11.06
Comment 7 Lucas Gass 2020-05-14 22:19:04 UTC
backported to 19.05.x for 19.05.11
Comment 8 Frédéric Demians 2020-06-16 12:40:44 UTC
(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.
Comment 9 Katrin Fischer 2020-06-16 13:14:15 UTC
Also from 19.11 I believe or adapted. the important just needs to be removed.
Comment 10 Victor Grousset/tuxayo 2020-06-20 15:45:35 UTC
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?