View Issue Details

IDProjectCategoryView StatusLast Update
0007072Anastasisanastasis-webuipublic2022-09-26 20:50
ReporterFlorian Dold Assigned Tosebasjm  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product VersionGit master 
Target Version0.3.0Fixed in Version0.3.0 
Summary0007072: browser history integration
DescriptionThere are various possible behaviors here:

(a) The navigation inside the anastasis SPA is independent from the browser navigation, and the back button always goes to the page visited before the anastasis SPA
(b) the browser back button always goes back "hierarchically", i.e. it's always like pressing the back button inside the SPA
(c) the browser back button always goes back "historically", i.e. when in the UI we press "next", "back", "next", the browser history will record each of these steps

We should discuss these possibilities with Belen.
TagsNo tags attached.



2021-11-09 14:49

developer   ~0018467

One simple way I can think of is allowing the user to navigate free between state, two things can happen:

1.- is loading an upcoming state before is ready: instead of showing an "invalid state" message we can assume a "preview" screen to explain what the user will do when it reaches this state and how the previous state is needed to this become available.
2.- is loading an previous state: show a readonly state with a button "jump into this state" which will call a "goto" action in the reducer and a "go back where I left" button which will sync the history with the reducer current state.

pros i can think of:
 * from (1) we use screen to show more information on how anastasis works for the curious one
 * we allow random access to any state from the side bar
 * from (2) if there is any validation to be done it can be placed into the "goto" action and add a notification "no you cannot go back into this action because XXXX"
 * free navigation through almost all screen is possible

Side note:
The screens that I'm thinking as navigable are the one that can be accessed from the sidebar, lets call them "principal screens". Others, like authorization method setup or a policy editing, are internal state from the principal screen and will be not reachable from links/history. IMHO I think this is ok for now.


2021-11-09 14:50

developer   ~0018468

@belen what do you think?

Christian Grothoff

2022-04-12 22:53

manager   ~0018864

Belen is gone. Based on what I recall, she'd suggest (b) and possibly suggest that the "Back" button be removed, as the browser already has one ;-).
But, you may keep the back button for now if you like it, but implement (b). Florian is also OK with doing (b).


2022-04-14 22:09

developer   ~0018881

fixed in bf3e0111..a2e8ab94

Issue History

Date Modified Username Field Change
2021-11-04 23:20 Florian Dold New Issue
2021-11-04 23:20 Florian Dold Status new => assigned
2021-11-04 23:20 Florian Dold Assigned To => sebasjm
2021-11-09 14:49 sebasjm Note Added: 0018467
2021-11-09 14:50 sebasjm Note Added: 0018468
2022-04-12 22:53 Christian Grothoff Note Added: 0018864
2022-04-14 21:27 Christian Grothoff Product Version => Git master
2022-04-14 21:27 Christian Grothoff Target Version => 0.4.0
2022-04-14 22:09 sebasjm Status assigned => resolved
2022-04-14 22:09 sebasjm Resolution open => fixed
2022-04-14 22:09 sebasjm Note Added: 0018881
2022-04-14 22:48 Christian Grothoff Fixed in Version => 0.3.0
2022-04-14 22:48 Christian Grothoff Target Version 0.4.0 => 0.3.0
2022-09-26 20:50 Christian Grothoff Status resolved => closed