issue: ENG-5823
We don't want to change those values on keyserver login, but we do want to change them on identity login
Details
Details
Dispatched the action, checked that globalThemeInfo and dataLoaded get updated
Tested with combination of setting currentUserInfo on this action, as is supposed to happen. The reason is that dataLoaded is used to hide / show the logged out screen, using this function:
const isLoggedIn = (state: BaseAppState<>): boolean =>
!!(
state.currentUserInfo &&
!state.currentUserInfo.anonymous &&
state.dataLoaded
);The app looked like this if no keyserver was yet connected:
The app works, it's possible to go to settings ans for example log out. We might want to update the UI some day, but it's imporatant that the user can see that they are logged in if they managed to log in to identity, and be able to log out.
Some discussion on this is in ENG-4211
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
Comment Actions
At some point, we'll want to prevent the keyserver login actions (logInActionTypes.success and siweAuthActionTypes.success) from resetting this state if usingCommServicesAccessToken is set. Is that tracked anywhere?
Comment Actions
Will it be possible to both have usingCommServicesAccessToken be set and be using the old login actions? I though those exclude each other
Comment Actions
Will it be possible to both have usingCommServicesAccessToken be set and be using the old login actions? I though those exclude each other
Ah, I think I misunderstood the plan. Based on your response, it sounds like we'll be introducing new keyserver login actions, which will replace the old ones when usingCommServicesAccessToken is set. Thanks for the clarification!
Comment Actions
So this app state without keyservers will be visible to the users right? Do other features work or at least they don't crash the app? E.g. "Create new chat" and "create community" buttons, thread search, calendar view?
Comment Actions
Yes, it will be visible for a moment. I clicked around the app, it doesn't crash. The only behaviour that is weird is that it is possible to start creating a new chat, because it is possible to search for users. The creation fails (seding the message fails) showing the retry button, and when the user logs in to Ashoat's keyserver the message disappears. This is caused by the fact that currently on keyserver login we clear the message store. I think this will be fixed when I refactor the message store ENG-5821. I created a task to check this after the refactor: ENG-6391
Comment Actions
There will be some time even after the multi-keyserver launch where my keyserver will continue to be necessary for things like sending DMs due to the GENESIS hacks.
I wonder if we should avoid setting dataLoaded on tempIdentityLoginActionTypes.success. We could instead wait until the user completes auth with my keyserver before setting dataLoaded. @inka, what do you think?
Comment Actions
I wonder if we should avoid setting dataLoaded on tempIdentityLoginActionTypes.success. We could instead wait until the user completes auth with my keyserver before setting dataLoaded. @inka, what do you think?
I feel like if the user managed to log in with identity on a device, they should be able to log out, even if all keyservers are not responding. Otherwise they could think they didn't manage to log in, and walk away from the device. Then if another person got access to the device, and the keyserver had responded in the mean time, they would get the access to the first persons account.
The app doesn't crash in this state. The UI could probably be better, but I don't think it's terrible. And I really feel like the user should be informed that they managed to log in, and should be able to log out.
Comment Actions
I'd like to avoid showing the user the app when there is no data and message sending is broken.
Maybe the solution should be:
- Don't set dataLoaded until auth with my keyserver is complete
- Add a special case to the keyserver connection handlers for my keyserver. If it fails (either due to error or timeout), then we log the user out (delete "sensitive data", clear "Comm services auth metadata", clear currentUserInfo, etc.)
That way, the user isn't stuck in a loading screen.
Comment Actions
I created ENG-6400 to implement the handler part of this. I will update the diff to set dataLoded to true on successful login to Ashoat's keyserver, instead of identity
Comment Actions
Set dataLoaded on successful login to Ashoat's keyserver
Tested that when tempIdentityLoginActionTypes.success is dispatched the app still shows the logout screen.
Tested that (if currentUserInfo was set on tempIdentityLoginActionTypes.success) when keyserverAuthActionTypes.success is dispatched for Ashoat's keyserver, the logout screen hides
| lib/reducers/data-loaded-reducer.js | ||
|---|---|---|
| 36–39 | I think this would be more performant and simpler | |