Differential D12265
[lib] Remove `permissions` field from `ThreadInfo.members[memberID].permissions` Authored by atul on Jun 1 2024, 9:21 PM. Tags None Referenced Files
Subscribers None
Details We're no longer using member permissions anywhere on client (or anywhere ThreadInfo is used which includes eg send.js), so it can be removed. NOTE: Marked this as DRAFT because I think we can do better than the invariant in memberHasAdminRole, but I think it would require some flow refactoring which I want to defer for now until I get rest of migration stack up.
Depends on D12259 flow
Diff Detail
Event Timeline
Comment Actions Agree we can do better than the invariant. It seems like memberHasAdminPowers should not be called with RelativeMemberInfo anymore, since permissions is missing there. Are there current callsites that pass RelativeMemberInfo into memberHasAdminPowers?
Comment Actions Please make sure to consider your "note to self" above before landing:
Comment Actions
There is one use of relativeMemberInfoValidator and it's in threadInfoValidator. threadInfoValidator is used in
webNavInfoValidator is only consumed by initialReduxStateValidator which validates ServerWebInitialReduxStateResponse. webNavInfoValidator is of type TInterface<WebNavInfo> and threadInfoValidator is consumed within to validate pendingThread: ... pendingThread: t.maybe(threadInfoValidator), ... My understanding is the WebNavInfo.pendingThread is a client concept and can only exist for the client representation of WebNavInfo and can't be included in response from keyserver since they aren't persisted or stored anywhere. To double check this, looked at getInitialReduxStateResponder which calls navInfoFromURL which takes in urlInfo and backupInfo and returns WebNavInfo. Nowhere in navInfoFromURL is a pendingThread field included:  As a result, I think this diff is safe to land. Please let me know if there's something I'm missing/misunderstanding and I will revert. | ||||||||||||||||||||||||||||||||||||||||||||||||||||