Inconsistent behaviour related to views list state

[antobenve]

This issue has been reported by Antoine Lafitte from PlanBleu personally to me.

The views list state of the WESR: Mediterranean project seems to have lost latest edits (saved in db through "Save views list state") twice recently.

Background situation:

• project has multiple collaborators that can save list state.
• new views have been added to the project between the time when the state was saved and the time when the problem was encountered

Possible idea to develop further:

• One collaborator could have started editing the views list state using a locally available state as starting point (saved to its browser) rather than the state stored in db. This action can easily erase changes that were made by the previous editor and can result in the feeling that the changes were lost while they were simply overwritten by someone else unvoluntarily.

[antobenve]

I tested the idea indicated initially and I confirm that a user that loads a local list state can make edits and save online so far overwriting the edits that other users previously saved online not knowing that. A solution should be proposed to help the user understand if the list state in use is different than the online one.

Reproductible steps are indicated [issue occurs at step 5]

1. U1 saves views list state at t0.
2. U2 opens the project and sees list state t0 and makes progressive changes and save locally at each time. Last local save is at t1.
3. U2 makes last change and saves directly online at t2.
4. U1 opens the project and sees list state t2. He makes changes at t3.
5. U2 opens the project and sees list state t1. He makes changes at t4. Changes remove all edits from t2 to t3.
6. U1 opens the project and sees list state t4 and realizes its edits at t3 have been lost.

This test has allowed to discover another glitch that is still related to the use of local list state over the online state:

• When a user makes changes online, he will still load the project using a local list state if this is present (see 5. U2 opens the project and sees list state t1). This causes the user to think its last change was not correctly saved online. -> This could be corrected by saving locally as well when saving online or by removing the local state when saving online.

[fxi]

Thanks. It crossed my mind when implementing this, but I thought : admins with the same right level on the project can indeed alter the project as they want and can communicate how to split their work outside the app. Not infaillible.

Saving intermediate state locally avoid losing everything, but could be converted to a recovery system, like story maps, style, etc.   Message like this :

Your local state differs from the remote one, which one you want to load ? 

But,  states could differ in content between users : some views do exist in one, but not in the other. 

This is inherent to the "folder / group / category" approach chosen. With subproject - my recommended choice – this could have been solved in a better way, as access to subproject are easy to control, as it inherit project's logic.

[antobenve]

I don't have a solution in my hands and I agree with you that it is difficult to find one given the current fonctionalities we want to guarantee (save locally, multiple users saves...) but I think that if we solve the last point of the issue we already decrease the probability of encountering the problem.

In few words, if the user that finally saves online has its local state removed, he will load the project using the online list state and will not have the chances to miss an update in the future. Another solution that will decrease the chances to have these problems would be having a pop-up that let the user knows when the list state is updated online and an option to load the changes over its local status.

However, the problem can still occur and must be solved in a more solid way. My preference is to separate the local environment from the online one in the catalogue based on a switch but I haven't thought about its implications yet.

[thomaspiller]

@antobenve Is this still relevant considering the latest developments in MapX?

[antobenve]

Yes, the indicated behavior hasn't been improved and still applies to the current version of MapX