Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User edits can be lost if failures occur during save #5848

Closed
3 of 7 tasks
akhenry opened this issue Oct 6, 2022 · 5 comments · Fixed by #5827 or #5971
Closed
3 of 7 tasks

User edits can be lost if failures occur during save #5848

akhenry opened this issue Oct 6, 2022 · 5 comments · Fixed by #5827 or #5971

Comments

@akhenry
Copy link
Contributor

akhenry commented Oct 6, 2022

Relates to #5802

Summary

When editing a display layout, user changes are not saved after an error has occurred unless the user makes an additional change to the layout before retrying the save.

The issue is because the previous failed save marked the object clean, so it is no longer queued to be saved. A workaround is to make another change to the object after the initial save failure. A subsequent save will then work as expected.

Steps to Reproduce

  1. Edit a display layout
  2. Open the network tab in Chrome dev tools
  3. Make some changes to the display layout (you can just move something around)
  4. In the "Throttle" dropdown in the network tab select "offline"
  5. In the display layout, click "Save and Finish Editing"
  6. Observe that an error is displayed.
  7. In the "Throttle" dropdown in the network tab select "no throttling"
  8. In the display layout, click "Save and Finish Editing" again.
  9. Observe that the save appears successful, and that the application is no longer in edit mode.
  10. Navigate away from the layout, and navigate back again
  11. Observe that the changes were not saved.

Environment

  • Open MCT Version: release/2.1.1 @ 9022d5d
  • Deployment Type: VIPER Test

Impact Check List

  • Data loss or misrepresented data?
  • Regression? Did this used to work or has it always been broken?
  • Is there a workaround available?
  • Does this impact a critical component?
  • Is this just a visual bug with no functional impact?
  • Does this block the execution of e2e tests?
  • Does this have an impact on Performance?
@akhenry
Copy link
Contributor Author

akhenry commented Oct 6, 2022

Assigning severity of critical because it's an edge case, and there is a workaround

@ozyx
Copy link
Member

ozyx commented Oct 27, 2022

Not fixed. Testathon 10/27/22

I'm still able to reproduce the issue with the given steps

@davetsay
Copy link
Contributor

Not fixed (even though I smoke tested it and it was fixed...).

@unlikelyzero unlikelyzero modified the milestones: Target:2.1.2, 2.1.3 Oct 27, 2022
@davetsay davetsay reopened this Oct 27, 2022
@jvigliotta
Copy link
Contributor

Not fixed (even though I smoke tested it and it was fixed...).

Yep! Feel ya!

@ozyx
Copy link
Member

ozyx commented Nov 11, 2022

Verified fixed Testathon 11/10/22

Following the provided instructions and changes were saved and persisted

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment