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.
Depends on D12259
Paths
| Differential D12265 Authored by atul on Jun 1 2024, 9:21 PM.
Details Summary 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 Test Plan flow
Diff Detail
Event Timeline
Harbormaster completed remote builds in B29342: Diff 40822.Jun 1 2024, 9:38 PM2024-06-01 21:38:46 (UTC-7) 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?
atul retitled this revision from [DRAFT][lib] Remove `permissions` field from `ThreadInfo.members[memberID].permissions` to [lib] Remove `permissions` field from `ThreadInfo.members[memberID].permissions`. Comment Actions
invariant gets removed in D12292 Comment Actions Please make sure to consider your "note to self" above before landing:
This revision is now accepted and ready to land.Jun 12 2024, 8:49 AM2024-06-12 08:49:17 (UTC-7) Harbormaster completed remote builds in B29635: Diff 41258.Jun 12 2024, 3:42 PM2024-06-12 15:42:15 (UTC-7) Harbormaster completed remote builds in B29694: Diff 41347.Jun 15 2024, 2:43 PM2024-06-15 14:43:12 (UTC-7) Harbormaster completed remote builds in B29695: Diff 41348.Jun 15 2024, 3:30 PM2024-06-15 15:30:18 (UTC-7) 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. Closed by commit rCOMM56ba0de13be0: [lib] Remove `permissions` field from `ThreadInfo.members[memberID].permissions` (authored by atul). · Explain WhyJun 15 2024, 6:17 PM2024-06-15 18:17:01 (UTC-7) This revision was automatically updated to reflect the committed changes.
Revision Contents
Diff 41258 lib/permissions/minimally-encoded-thread-permissions-validators.js
lib/selectors/user-selectors.js
lib/shared/thread-utils.js
lib/types/minimally-encoded-thread-permissions-types.js
|