Erroneous "Tab may have unsaved data" message when creating new MARC record

Bug #1491875 reported by Michele Morgan
38
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Medium
Unassigned
2.11
Fix Released
Medium
Unassigned

Bug Description

Evergreen 2.8.3 and later

When creating a MARC record, users can see an erroneous pop-up message "This tab may have unsaved data. Replace it anyway?" when creating the record as follows:

Navigate to Cataloging -> Create New MARC Record.
Choose a template, click Load
Enter data in a fixed field, for example, Date1
Enter data in a MARC field such as 100
Click Create Record

The "This tab may have unsaved data. ..." pop up will appear.

Clicking OK will save the record and take the user to their default view of the record.
Clicking Cancel will save the record and return the user to the MARC Edit screen.

The behavior when clicking Cancel can lead to confusion as to whether the record has actually been saved.

The erroneous pop up only occurs if edits are made to fixed fields first, before editing other fields in the record.

Galen Charlton (gmc)
Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Galen Charlton (gmc) wrote :

Confirmed that remains an issue in 2.10; I'll debug this further.

Changed in evergreen:
assignee: nobody → Galen Charlton (gmc)
Revision history for this message
Eva Cerninakova (ece) wrote :

Confirmed still valid for 2.12. beta.

Revision history for this message
Jason Etheridge (phasefx) wrote :

This looks like the change from mangle005() not being reflected in the DOM until after the save attempt for some reason. If you Cancel, then the 005 gets updated, and a subsequent Create Record attempt succeeds. I tried segregating the code that follows with a setTimeout but something weird is still happening. Will poke some more.

Revision history for this message
Jason Etheridge (phasefx) wrote :

I was totally off on this. It has to do with multiple locks being placed on the tab in this context, not all of which are being removed upon save. I'm not sure that this interface needs to support multiple locks.. so this branch tries to do away with that: collab/phasefx/lp1491875

However, we should test locking and unlocking in all invocations of the MARC editor before accepting this. For reference, bug 1282277 and bug 1282286 touched upon this area via commit e9de9d7e1944ff0b467f204ba898b5f52073cac0

Revision history for this message
Jason Etheridge (phasefx) wrote :

I force pushed a new version of the branch; less scary yet admittedly kludgy :)

Revision history for this message
Andrea Neiman (aneiman) wrote :

Tested this in the following situations:

- created new bib record using the method described above: OK -- no warning, record created as expected
- edited bib record using method described in bug 1282277 : OK -- only got warning when expected
- created auth record (both "create immediately" and "create and edit"): OK -- only got warning when expected
- ran all 6 of Yamil's tests here https://bugs.launchpad.net/evergreen/+bug/1282286/comments/21 and all got results that I would consider normal/expected (note that test #4 on that list I think is expected behavior -- you get the warning when switching from MARC Editor to another view, but not when you close from another View *IF* you clicked "OK" on the warning. If you click "cancel" on the warning, and then try to close the tab, you are prompted again with the warning.)
- edited a record from z39.50 import -- only got warning when expected
- edited a record from Vandelay import -- only got warning when expected
- created a MFHD record -- only got warning when expected

Note that there are two cases where an existing tab-lock issue still shows up, but they were not introduced/worsened by this fix:
- edited a MFHD record -- got erroneous warning when closing the popup despite having clicked save
- edited an auth record -- after the popup is saved & auto-closes, navigating away from or closing the authority tab will generate an erroneous warning.

I have tested this code and consent to signing off on it with my name, Andrea Neiman and my email address, <email address hidden>

Andrea Neiman (aneiman)
tags: added: signedoff
Galen Charlton (gmc)
tags: added: pullrequest
Changed in evergreen:
milestone: none → 2.12.2
Revision history for this message
Galen Charlton (gmc) wrote :

I've tested as well and pushed a signoff branch to user/gmcharlt/lp1491875_signoff. Kludgy kludge is kludgy, so if anybody wants to poke at this a bit more, please feel free (although given that the XUL client is being deprecated in 3.0, probably not worth much more effort).

Since this was left without a pullrequest tag for a couple weeks, I'll hold off on merging this for a couple days in case anybody else cares to test.

Changed in evergreen:
assignee: Galen Charlton (gmc) → nobody
Revision history for this message
Galen Charlton (gmc) wrote :

Pushed to master, rel_2_12, and rel_2_11. Thanks, Jason and Andrea!

Changed in evergreen:
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
Revision history for this message
Terran McCanna (tmccanna) wrote :

Hi Dan, did you mean to add that to https://bugs.launchpad.net/evergreen/+bug/1538678 ?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.