View Issue Details

IDProjectCategoryView StatusLast Update
0007072Anastasisanastasis-webuipublic2022-09-26 18:50
ReporterFlorian Dold Assigned Tosebasjm Due Date
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.

Activities

sebasjm

2021-11-09 13: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.

sebasjm

2021-11-09 13:50

developer   ~0018468

@belen what do you think?

Christian Grothoff

2022-04-12 20: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).

sebasjm

2022-04-14 20:09

developer   ~0018881

fixed in bf3e0111..a2e8ab94

Issue History

Date ModifiedUsernameFieldChange
2021-11-04 22:20Florian DoldNew Issue
2021-11-04 22:20Florian DoldStatusnew => assigned
2021-11-04 22:20Florian DoldAssigned To => sebasjm
2021-11-09 13:49sebasjmNote Added: 0018467
2021-11-09 13:50sebasjmNote Added: 0018468
2022-04-12 20:53Christian GrothoffNote Added: 0018864
2022-04-14 19:27Christian GrothoffProduct Version => Git master
2022-04-14 19:27Christian GrothoffTarget Version => 0.4.0
2022-04-14 20:09sebasjmStatusassigned => resolved
2022-04-14 20:09sebasjmResolutionopen => fixed
2022-04-14 20:09sebasjmNote Added: 0018881
2022-04-14 20:48Christian GrothoffFixed in Version => 0.3.0
2022-04-14 20:48Christian GrothoffTarget Version0.4.0 => 0.3.0
2022-09-26 18:50Christian GrothoffStatusresolved => closed