Editing Ordered Lists - losing data when adding items
Description
When users add items to pre-existing ordered lists, the new items overwrite 1 or more previously saved items. This may be related to enumeration dropdown (if selecting ‘arabic’ new items added to end of list without data loss).
EXAMPLES
See examples from the archivesspace sandbox. This is also happening in our AS 2.2.2 , in production and in test.
http://sandbox.archivesspace.org/resources/1/edit#notes
Example 1 = Created list abcde. Saved. Then edited to add a new item (should append after E). Instead, I lose item D.
Example 2 = Created list abcde. Saved. Then edited to add 3 new items (should append to list) . Instead, I lose multiple items (D,E).
I was able to avoid data loss – if I pick an enumeration.
Example 3 = Repeat above. BUT this time set enumeration to arabic. New item adds successfully to the end of the list.
Environment
Activity
This has to be the worst bug I’ve encountered in ASpace (not sure how long it’s been around, though, as it's possible that changes to the application impacted how the functionality originally worked – as you mention, , it’s complicated!). Hopefully there aren’t any others like it but I’d like to suggest that the TAC and UAC label these types of bugs as critical issues and alert the community to their presence. You cannot avoid what you don’t know about, and everyone wants to avoid making edits that can silently overwrite existing data. : I’d be curious to know how you identified what needed to be fixed? I’m not sure what else to do aside from creating a report of all of our lists and having each reviewed. Would still be hard to know when something was intentionally deleted, though, vs. unintentionally
Without wanting to dive too much into the jQuery selectors, I think I have a patch that addresses the issue (see ), though I still need to test further. Regardless, it would be good to have a JavaScript expert investigate and make sure there aren’t any updates needed / better ways to address this particular issue.
Thank you - exciting about a possible fix for this. We discovered the work through the painstaking efforts of Sally Kent who is cataloguing court rolls in detail- we are quite new to AS and she was very conscientiously going back and checking the records she had produced in lockdown and spotted the gaps. We are very lucky to have her!
Sally adds: I only spotted the errors in my lists because I published the catalogue to check the display of text on the public interface; it was just lucky that I spotted a missing number in one entry and then checked through all the others. For my purposes, I still think the lists are very useful and will probably continue to use them when I return to cataloguing, albeit with more checking.
An even older silent data loss issue is , which was actually reported by .
Thank you have just tested and replicated that- will add a comment to ANW-138
Oh yeah, is quite nasty as well (that one was discovered by Sandra Markham, and I still remember the day that she discovered it, and the steps that we took to figure out what exactly was going on). Luckily it can be avoided once you know that the bug exists, whereas this bug can only be avoided by skipping the staff interface altogether and using the API, I think. Not an easy workaround.
That said, moving forward, I think that any type of bug that silently causes data loss (whether to existing data or data that you’re trying to add) should be categorized as critical blockers and advertised widely and loudly. But fixing anything that impacts staff data-entry workflows as fast as possible is best, because folks do forget the warnings (and the bugs) over time. Hopefully these are the only… two?
Assignee
Reporter
Fix versions
Priority
