DM does not persist my last worspace selection

[JuergeN]

As a user I find it very irritating and misleading, that DM does not persist my last workspace settings. After I log in, the DeepaMehta Workspace is always pre-selected. For a stable working environment I would very much appreciate, if my recent workspace and topicmap were stored and persistent for my next login.

[Malte]

Yes, this is especially irritating for users who are not members of the "DeepaMehta" workspace and then will not see a "Create" menu appearing. However automatically jumping into the "Private Workspace" after logging is also not what one would want so i like this proposal to keep the workspace selection across reloads. Letting the dm4-webclient react to the current workspace cookie set at client-side might just do the trick.

[jri]

This is about stability, right? That is after log in she want find herself where she left (when logged out). To achieve this remembering the last used workspace is not adequate. Instead the last used topicmap must be remembered/restored (as in the original ticket description). The workspace is implicit then.

I'll implement it this way and release DM 4.8.2 today.

Thank you for addressing this issue!

[JuergeN]

Yes, stability of the selected TopicMap? is key. In my guess, the TopicMap? will then enforce the corresponig WorkSpace?. Thank you for your quick help! Wonderful! :)

[jri]

Replying to Malte:

[...] i like this proposal to keep the workspace selection across reloads.

Note: after reload the current state is restored already (based on browser URL).

This issue is about rememberig the state between log out and log in.

[Jörg Richter <jri@…>]

In 113a7f29eb759f321a6277ed427171cb8c0fb379/deepamehta:

Webclient restores last used topicmap (#994).

When entering the Webclient through the front door (localhost:8080/de.deepamehta.webclient/) the last used topicmap is selected programatically. The last used topicmap is obtained from the "dm4_topicmap_id" browser cookie.

See #994.

[jri]

Sorry, Malte, I wasn't fully right.
Possibly my focus on the login/out moment was not appropriate. And your hint about using the existing DM cookies was actually very useful!

Meanwhile I see the problem differently:

1. When the user opens DM again (through the front door, that is localhost:8080/de.deepamehta.webclient/) she wants find herself where she left, regardless if (still) logged in or not. Note: also when not logged in the user can switch between (public) topicmaps.

2. Before a user logs in there is a (public) topicmap visible already. Once logged in that topicmap is still READable for sure. There is no need to programmatically switch to another topicmap at this point. She just stays in the topicmap which is visible already -> stableness.

So, the login moment plays no role for stableness. Its just as simple as that: when entering DM (through the front door) the last used topicmap is selected programmatically, based on the "dm4_topicmap_id" cookie. Nothing is persisted in the DB. That is what is implemented now.

From my point of view there is no need to track the "last topicmap selected while logged in" separatly (in another cookie) and to restore that topicmap once logged in again.

Thank you, Malte, for your input!

[Malte]

I needed a bit of time to wrap my head around this scenario but here are some thoughts and i am in the hope that this does to make over compliated the remote discussion on this but can help to clarify a few remarks initially made.

After I log in, the DeepaMehta Workspace is always pre-selected.

I think this just looked like it but actually the "DeepaMehta" workspace was (before the fix of today mentioned in comment:6) not always pre-selected but the selected workspaces was either the first of all available (from those you have read access to) or the first in alphabetical order (from those you currently have read access to).

After jri's fix it now should always be the workspace corresponding to your latest topicmap selection, which would be great.

For a stable working environment I would very much appreciate, if my recent workspace and topicmap were stored and persistent for my next login.

Imho this would not solve but just move the issue because then, when you log in, the topicmap you were currently browsing (while you were not logged in) would have to be exchanged with another one programmatically (the one you "last saw when you were logged in for the last time").

For now i agree here with jri that logging in should not switch the current topicmap visible.

Yes, stability of the selected TopicMap?? is key.

The thing that may be irritating is that through logging out the webclient may (depending in which map you currently are) change the topicmap (and workspace) programatically (due to your decreased permissions, and that will alter your topicmap cookie) - to anything? else - without you explicitly saying so.

@JuergeN: Do you have your browser configured to delete your cookies when it gets closed? If so, we cannot achieve a stable topicmap selection with our current approach.

As it stands, i think, DM's stableness is most complete when you do not log out of the session and when you do not delete your DM cookies.

The way it will be now with 4.8.2 is already a really good approach so thanks for your addressing and realizing this!

Up a level we might wanna talk about stableness for the very same user using DM on many devices/browsers :) - which i think would actually be different HTTP sessions, no?

Greetings!

[jri]

Malte, over the years you gained a real good check about all things DM!
That's a pleasure for me :-)
Cheers!

[jri]

Just one thing:

Replying to Malte:

@JuergeN: Do you have your browser configured to delete your cookies when it gets closed? If so, we cannot achieve a stable topicmap selection with our current approach.

All DM cookies are created without expiration date, so they are so called "session cookies". They get deleted when the browser session ends, that is when the browser is quit. Browser configuration plays no role here.

[Malte]

Just a note about that in FFOX to adapt how it treats cookies is easily possible and something i've done everytime i installed one on a blank machine.

These cookie options can be set in the "about:preferences#privacy" resource at the "History" section where i can set FFOX to "Use custom settings for history" (which is for example nice if you want to de-activate how firefox treats "third party cookies"). In that sub-menu i can surely adjust the "Clear history when firefox closes" > "Settings" (where one can also adjust how FFox deals wit "cookies" on close/quit.

When resetting a DM DB on which i previously browsed topicmaps (and still have a valid cookie) this now leads to the following client side exception.

uncaught exception: WebclientError: loading script /de.deepamehta.accesscontrol/script/plugin.js failed (parsererror: WorkspacesError: topicmap 1864 is not assigned to any workspace)

I got around this by manually deleting the cookie and this should not affect any users.

[jri]

Replying to Malte:

These cookie options can be set in the "about:preferences#privacy" resource at the "History" section where i can set FFOX to "Use custom settings for history" (which is for example nice if you want to de-activate how firefox treats "third party cookies"). In that sub-menu i can surely adjust the "Clear history when firefox closes" > "Settings" (where one can also adjust how FFox deals wit "cookies" on close/quit.

When the browser is quit DM cookies are deleted in any case.

When resetting a DM DB on which i previously browsed topicmaps (and still have a valid cookie) this now leads to the following client side exception.

uncaught exception: WebclientError: loading script /de.deepamehta.accesscontrol/script/plugin.js failed (parsererror: WorkspacesError: topicmap 1864 is not assigned to any workspace)

I got around this by manually deleting the cookie and this should not affect any users.

Ah, yes, this is a side effect of the new stability feature.
At the moment we can say: when a user resets the DM database she is supposed to restart the browser as well.
Thank you for the hint!