Alternative Identifier and Notes overwriting in record duplicated
|Assignee:||Kelly Stewart||% Done:|
|Target version:||Release 2.4.0|
|Google Code Legacy ID:||Tested version:||2.1, 2.2, 2.3|
When we duplicate an Item Level description and change the identifier field in the Title note area the new Identifier overwrites the Identifier in the record that was duplicated. Our work around it to leave this field blank and return to the record later to fix the problem. We are using version 2.1.0
#1 Updated by Dan Gillean about 7 years ago
- Tested version 2.1, 2.2 added
Reproduced in qa/2.2.x:
- Navigate to a fonds with lower-level descriptions, e.g. items.
- Enter edit mode and add an alternative identifier: FOO, then save
- Duplicate the item description
- In the duplicated description's edit page, change the alternative id to BAR, and save
- No alternative identifier is saved and present on the duplicated description
- The alternative identifier for the original description is changed from FOO to BAR
- Alternative id BAR is saved on the duplicated description
- Original description's alternative id is not affected by changes made to duplicated record.
#2 Updated by Dan Gillean over 5 years ago
- File rad-ead-crosswalk-2.3.xml added
- Subject changed from Alternative Identifier overwriting in record duplicated to Alternative Identifier and Notes overwriting in record duplicated
- Tested version 2.3 added
Updated to reflect most current information - this affects notes as well. First reported in the user forum here and reproduced in 2.3.
This affects all repeatable notes fields, e.g. General notes in ISAD; all the title note types and other note types in RAD, etc.To reproduce:
- Create or import a record with all notes fields populated and with some alternative IDs added. I've attached a fully filled-out RAD EAD XML file for testing
- In the button block at the bottom, Duplicate the record.
- Before saving, change every existing note field in the new duplicated record to FOO
- Change one of the alternative ID identifier values
- Save the new duplicate record.
- Navigate back to the original source record.
- Notes in the source record have been overwritten with "FOO"
- Alternative identifiers in the source record have been overwritten
- Edits made to the duplicate record before saving ONLY apply to the new record - they should not affect the source record
- Adding new notes in the duplicate record will not write those notes back to the original. It only affects edits.
#5 Updated by Mike Gale over 5 years ago
- Status changed from New to Code Review
- Assignee changed from Mike Gale to Steve Breker
Hi Steve, if you get a minute this week and someone else hasn't jumped into CR my PR, can you do it please? https://github.com/artefactual/atom/pull/523
It took me something like 8-9 hours to fully understand the code paths when duplicating records and copying over the notes / alt ids. They're truly terrifying code paths that go through multiple levels of inheritance and span several files. They even had a bunch of update code that was a red herring and dead code! I'm very glad to get this bug done (I hope) :)
#10 Updated by Kelly Stewart almost 5 years ago
- Status changed from QA/Review to New
- Assignee set to Nick Wilkinson
While QAing this ticket noticed that if I duplicate a record the date field duplicates. So, 1 duplication = 2 dates. Duplicate again and you have 4 dates. And again, 8 dates. And again, 16 dates.
#12 Updated by Mike Gale almost 5 years ago
- Status changed from New to Feedback
- Assignee changed from Mike Gale to Kelly Stewart
Which date field was duplicating, dates of creation? I also tried recreating the issue (assuming I was testing the right field) on the same test site you did and didn't see anything out of the ordinary. The 'repeat-5' record you directly linked above seems to have been deleted as well, so I can't check that to verify I'm testing this properly. Can you take another look and expand on how to reproduce this if the bug is still present?