-
Notifications
You must be signed in to change notification settings - Fork 351
Description
This is a sub-issue of #716. Quoting from there, for background:
For the most part the users we actually encounter will be users we do have data on: for example, a guest user still has permission to know about users that are subscribed to any of the same streams they are, which means that most of the messages they see there will be sent by users they know about. But there could be older messages by users who've since unsubscribed, and other scenarios. So we will sometimes encounter a user ID that doesn't exist in store.users.
The get-messages response contains an avatar_url field for the sender. If store.getUser gives null, that field can be used as a fallback, so we don't have to show just a blank square.
Implementation
Our AvatarUrl class has a factory AvatarUrl.fromUserData method. If that doesn't give the right behavior, perhaps it should grow a factory AvatarUrl.fromMessageData for this.
We should see about handling client_gravatar and user_avatar_url_field_optional (does the get-messages endpoint not have a param for the latter?); see:
Metadata
Metadata
Assignees
Labels
Type
Projects
Status