[ ] Checked the logs and have uploaded a log file and provided a link because I found something suspicious there. Please do not post the log file in the topic because very often something important is missing.
I’m submitting a…
[ ] Regression (a behavior that stopped working in a new release)
[ x ] Bug report
[ ] Performance issue
[ ] Documentation issue or request
Current behavior
When I view an entity twice and in between the API has performed an update, Squidex suggests to overwrite old data over new data when no changes have been made. (i.e. “You have unsaved changes. Do you want to load them now?”)
Expected behavior
When I view an entity twice and in between the API has performed an update, Squidex recognises that I have not made changes that needed saving and does not suggest overwriting API changes with older versions
Minimal reproduction of the problem
save changes to an entity (causing an API to update the entity)
open the entity again
you should see a dialogue asking if you want to save unsaved changes
Environment
[ ] Self hosted with docker
[ ] Self hosted with IIS
[ ] Self hosted with other version
[ x ] Cloud version
Version: [VERSION]
Browser:
[ x ] Chrome (desktop)
[ ] Chrome (Android)
[ ] Chrome (iOS)
[ ] Firefox
[ ] Safari (desktop)
[ ] Safari (iOS)
[ ] IE
[ ] Edge
Others:
the bug also occurs if I log out right after saving changes and the API perform changes while I’m logged out (i.e. when I log back in I am still asked to load “unsaved” changes that have already been saved)
I cannot reproduce it. Squidex stores your changes in the local store and when they differ it shows the dialog. Perhaps your change is not 100% the same as the API version?
My changes are not the same as the API version for sure. Here is a clarification of what happened:
Change #1 (by me) - affects field A, leaves field B untouched
Change #2 (by the API) - affects field B, field A kept as is
Change #3 (by me, after loading supposed “unsaved” changes) - reinstates change #1, as if it had never been saved. Change #2 is overwritten, so API changes are wiped.
It’s a pity you can’t reproduce.(Note: Your action of saving an entity should trigger API changes. You can log out immediately after saving, let the API do its changes, log back in and open that entity again)
Unfortunately the arrow button (2) is at the wrong place right in the Cloud and not shown like in the screenshot. This is a bug and will be fixed. But you can compare field by field where the difference is, so that you do not loose changes.
Another improvement could be that we also store the current version when saving the current content to the local store. Then we could show a more precise message.
Such as “You have unsaved changes for an previous version of the content. Do you want to load them now?”
Hi Sebastian, It seems that you’re the one doing all the changes on that entity (no API interference). API is what’s causing the version mashup on squidex.
The problem is that I get told there are unsaved changes when there aren’t. Other users of the CMS are getting induced in error and following squidex advice to load and save “unsaved” changes, and they are accidentally reinstating an older version of the entity.
Now I get it. After you made Change #1, the version should be removed from your local store. This does not seem to work. Therefore the wrong hint, I guess.
