Page MenuHomePhabricator
Differential D13547

[lib] Make sure we set isViewer in useExistingThreadInfoFinder
ClosedPublic
Actions

Authored by ashoat on Sep 30 2024, 10:06 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Apr 17, 1:05 AM
Unknown Object (File)
Wed, Apr 16, 10:40 PM
Unknown Object (File)
Wed, Apr 16, 9:54 PM
Unknown Object (File)
Wed, Apr 16, 5:23 AM
Unknown Object (File)
Mon, Apr 14, 3:10 PM
Unknown Object (File)
Thu, Apr 3, 11:09 PM
Unknown Object (File)
Tue, Mar 25, 6:31 PM
Unknown Object (File)
Mar 9 2025, 5:27 PM
View All 54 Files
Subscribers
None

Details

Reviewers
tomek
kamil
inka
Commits
rCOMM332eeeba691e: [lib] Make sure we set isViewer in useExistingThreadInfoFinder
Summary

When we call createPendingThread in useExistingThreadInfoFinder, we need to include isViewer in order to make sure a PRIVATE thread is rendered as eg. "ashoat" instead of "just you". This is because the naming is based on ifJustViewer, which only applies if the members list only includes the viewer.

Depends on D13546

Test Plan

Confirm that I see eg. "ashoat" instead of "just you" for PRIVATE thread uiName

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Revision Contents
Changeset List

PathSize
lib/
shared/
5 lines

Diff 44728

View Options

lib/shared/thread-utils.js

Show First 20 Lines • Show All 573 Lines • ▼ Show 20 Lines async keyserverAuthInfo => {
const responses: { +[string]: ClientLogInResponse } = const responses: { +[string]: ClientLogInResponse } =
await callKeyserverEndpoint( await callKeyserverEndpoint(
'keyserver_auth', 'keyserver_auth',
requests, requests,
keyserverAuthCallSingleKeyserverEndpointOptions, keyserverAuthCallSingleKeyserverEndpointOptions,
); );
const userInfosArrays = [];
let threadInfos: RawThreadInfos = {}; let threadInfos: RawThreadInfos = {};
const calendarResult: WritableCalendarResult = { const calendarResult: WritableCalendarResult = {
calendarQuery: keyserverAuthInfo.calendarQuery, calendarQuery: keyserverAuthInfo.calendarQuery,
rawEntryInfos: [], rawEntryInfos: [],
}; };
const messagesResult: WritableGenericMessagesResult = { const messagesResult: WritableGenericMessagesResult = {
messageInfos: [], messageInfos: [],
truncationStatus: {}, truncationStatus: {},
Show All 21 Lines for (const keyserverID in responses) {
messagesResult.currentAsOf = { messagesResult.currentAsOf = {
...messagesResult.currentAsOf, ...messagesResult.currentAsOf,
[keyserverID]: responses[keyserverID].serverTime, [keyserverID]: responses[keyserverID].serverTime,
}; };
updatesCurrentAsOf = { updatesCurrentAsOf = {
...updatesCurrentAsOf, ...updatesCurrentAsOf,
[keyserverID]: responses[keyserverID].serverTime, [keyserverID]: responses[keyserverID].serverTime,
}; };
userInfosArrays.push(responses[keyserverID].userInfos);
userInfosArrays.push(responses[keyserverID].cookieChange.userInfos);
} }
const userInfosArrays = [
responses[authoritativeKeyserverID()].userInfos,
responses[authoritativeKeyserverID()].cookieChange.userInfos,
tomekUnsubmitted
Not Done
Inline Actions

I don't think it is guaranteed that there will always be a response from the authoritative keyserver, e.g. when adding a new keyserver. We probably should add a condition here and extend a test plan to verify a non-auth keyserver auth.

tomek: I don't think it is guaranteed that there will always be a response from the authoritative…
];
const userInfos = mergeUserInfos(...userInfosArrays); const userInfos = mergeUserInfos(...userInfosArrays);
return { return {
threadInfos, threadInfos,
currentUserInfo: responses[authoritativeKeyserverID()]?.currentUserInfo, currentUserInfo: responses[authoritativeKeyserverID()]?.currentUserInfo,
calendarResult, calendarResult,
messagesResult, messagesResult,
userInfos, userInfos,
▲ Show 20 Lines • Show All 526 Lines • Show Last 20 Lines