Page MenuHomePhabricator

[lib] Update `threadMemberHasPermission` to support `MinimallyEncodedRawThreadInfo`
ClosedPublic

Authored by atul on Nov 13 2023, 11:19 AM.
Tags
None
Referenced Files
F3246220: D9841.id33134.diff
Thu, Nov 14, 10:01 PM
F3246176: D9841.id33153.diff
Thu, Nov 14, 9:49 PM
Unknown Object (File)
Mon, Oct 21, 3:01 AM
Unknown Object (File)
Oct 15 2024, 1:19 AM
Unknown Object (File)
Oct 15 2024, 1:19 AM
Unknown Object (File)
Oct 15 2024, 1:19 AM
Unknown Object (File)
Oct 15 2024, 1:14 AM
Unknown Object (File)
Oct 3 2024, 4:08 AM
Subscribers

Details

Summary

Check minimally encoded permissions for permission via hasPermission in threadMemberHasPermission based on minimallyEncoded flag.

NOTE: One thing I noticed when I was making this change was that permissionLookup always checks for the threadPermissions.KNOW_OF permission during permissions checks and fails all checks where KNOW_OF isn't present. Looks like this logic was added by @ashoat in https://phab.comm.dev/D1213. If this is still relevant, should I update hasPermission to always ensure that KNOW_OF bit is set?

Depends on D9840

Test Plan

Will add unit tests in future, for now counting on Flow.

Diff Detail

Repository
rCOMM Comm
Branch
master
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

atul published this revision for review.Nov 13 2023, 11:28 AM

If this is still relevant, should I update hasPermission to always ensure that KNOW_OF bit is set?

Yes, absolutely. The default should definitely be "match existing code" – if you ever have a question like this in the future for this project, please default to matching existing code, instead of doing things differently and hoping your reviewer will notice a question in the diff summary.

This revision is now accepted and ready to land.Nov 13 2023, 12:14 PM

If this is still relevant, should I update hasPermission to always ensure that KNOW_OF bit is set?

Yes, absolutely. The default should definitely be "match existing code" – if you ever have a question like this in the future for this project, please default to matching existing code, instead of doing things differently and hoping your reviewer will notice a question in the diff summary.

Makes sense, will update hasPermission. Had previously looked at:

d6b5c5.png (918×1 px, 186 KB)

when implementing hasPermission so didn't come across the KNOW_OF requirement. I'm guessing that threadHasPermission should also be updated to "go through" permissionLookup?

I'm guessing that threadHasPermission should also be updated to "go through" permissionLookup?

Was initially guessing that's not necessary since I figured permissionLookup gets called for each individual permission on the keyserver before it's delivered to the client. So if a blob is missing KNOW_OF, on the client it should appear completely empty (no permissions).

That said, did a git grep and saw a threadHasPermission was recently introduced on keyserver. It's kind of risky to leave threadHasPermission in this weird state where it should only be used in certain places – probably best to update it as you suggest.

Before landing, can you create a task to track fixing up threadHasPermission?

Before landing, can you create a task to track fixing up threadHasPermission?

Just put up a diff real quick: D9845