We have now implemented the client side state button that is shown if a client state is found in the local storage.
This poses following issue/not perfect UX now:
A user have a local state saved in the local storage and therefore the client side state button is shown.
The user wants to login with another account and switch account.
If the user wants to navigate back or edit the identifier, the client side state button is shown again (the one that the user did not want to use)
TODOS
[ ] If a login is aborted by "back navigation" or "identifier edit" button, show the user to the conventional pre-filled login screen instead of the client side state button.
[ ] If a login is aborted, clear the client state in the local storage.
Acceptance criteria
Here you must define the acceptance criteria of this issue (what has to work, what should the developer test and so on). Use TODO checkboxes (markdown).
[ ] ...
[ ] ...
Implementation idea
Here you can write down an implementation idea how you would implement this issue (where do put this feature like in what domain, what service, what layer, naming/key of the feature in the code).
Adam3371
commented
2 weeks ago
Why
We have now implemented the client side state button that is shown if a client state is found in the local storage. This poses following issue/not perfect UX now:
TODOS
Acceptance criteria
Here you must define the acceptance criteria of this issue (what has to work, what should the developer test and so on). Use TODO checkboxes (markdown).
Implementation idea
Here you can write down an implementation idea how you would implement this issue (where do put this feature like in what domain, what service, what layer, naming/key of the feature in the code).