Page MenuHomePhabricator

[lib] reduce currentUserInfo on identity login/register
ClosedPublic

Authored by inka on Feb 22 2024, 12:44 AM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Nov 7, 1:44 AM
Unknown Object (File)
Tue, Nov 5, 1:12 AM
Unknown Object (File)
Fri, Nov 1, 10:42 PM
Unknown Object (File)
Oct 15 2024, 5:54 PM
Unknown Object (File)
Oct 15 2024, 5:54 PM
Unknown Object (File)
Oct 15 2024, 5:54 PM
Unknown Object (File)
Oct 15 2024, 5:54 PM
Unknown Object (File)
Oct 15 2024, 5:53 PM
Subscribers

Details

Summary

issue: ENG-6416
We want to set the new currentUserInfo after successful with with identity

Test Plan

Dispatched identity login action and checked that the currentUserInfo is set in redux

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

inka requested review of this revision.Feb 22 2024, 12:59 AM
tomek added inline comments.
lib/reducers/user-reducer.js
63–66 ↗(On Diff #37425)

By doing this we're going to have an empty avatar. This will eventually get fixed by https://linear.app/comm/issue/ENG-4210/handle-avatars-in-currentuserinfo, but in the meantime we can set the avatar on successful keyserver auth from the authoritative keyserver.

This revision is now accepted and ready to land.Feb 22 2024, 2:35 AM
lib/reducers/user-reducer.js
63–66 ↗(On Diff #37425)

Is making sure that the authoritative keyserver populates the avatar tracked anywhere? Or is this already done? If it's already done, do we have code to make sure ONLY the authoritative keyserver populates the avatar, or is that tracked somewhere?

Set avatar and settings on keyserver auth

lib/reducers/user-reducer.js
63–66 ↗(On Diff #37425)

I will amend this diff

keyserverAuth action has a defined currentUserInfo only if it was sent by the authoritative keyserver

lib/reducers/user-reducer.js
77 ↗(On Diff #37482)

We should check if it is an auth to the authoritative keyserver.

lib/reducers/user-reducer.js
77 ↗(On Diff #37482)

Like I said, keyserverAuth action has a defined currentUserInfo only if it was sent by the authoritative keyserver.
Moreover the auth action can be performed for multiple keyservers at once. And in this reducer we know the list of these keyservers, but we get only one user info - from the authoritative keyserver, not a list. So this is handled in the action, and we don't need to check it here

authoritativeKeyserverID may not be present. The types already handle this correctly