Page MenuHomePhabricator

[keyserver/lib] introduce MANAGE_FARCASTER_CHANNEL_TAGS permission
ClosedPublic

Authored by ginsu on May 15 2024, 7:28 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Nov 15, 6:06 PM
Unknown Object (File)
Tue, Nov 12, 11:17 AM
Unknown Object (File)
Fri, Nov 1, 5:30 PM
Unknown Object (File)
Oct 13 2024, 5:22 AM
Unknown Object (File)
Oct 13 2024, 5:22 AM
Unknown Object (File)
Oct 13 2024, 5:22 AM
Unknown Object (File)
Oct 13 2024, 5:22 AM
Unknown Object (File)
Oct 13 2024, 5:22 AM
Subscribers

Details

Summary

We need this permission to create + update + remove farcaster channel tags

Linear task: https://linear.app/comm/issue/ENG-7648/introduce-a-new-permission-for-updatingmanaging-connecting-farcaster

Depends on D12400

Test Plan

Tested new clients:
Set the code version to current code version, created a new community and threads, confirmed that when an admin opened up the manage roles screen the manage farcaster channel tags permission was shown to the user and they could use it to create a new role.

Also was logging out the value of stateCheckStatus and confirmed that I always got
{ status: 'state_validated' }

Tested old clients + state sync mechanism:
Followed @inka's test plan in D12235 and confirmed that the value of stateCheckStatus was

{ status: 'state_validated' }

Screenshot 2024-06-12 at 5.01.20 PM.png (1×3 px, 2 MB)

Also confirmed that when the user opened the community drawer that the manage farcaster channel tag permission was not shown for existing communities and newly created communities

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

ginsu added reviewers: tomek, kamil, ashoat.
ginsu added inline comments.
lib/types/thread-permission-types.js
272–273 ↗(On Diff #40264)

This copy needs to be reviewed

ginsu requested review of this revision.May 15 2024, 7:44 PM
ashoat requested changes to this revision.May 16 2024, 10:18 AM
ashoat added a subscriber: inka.
ashoat added inline comments.
keyserver/src/database/migration-config.js
826 ↗(On Diff #40264)

This is a very expensive operation, and can cause my keyserver to be down for 15-60 minutes. After you land this, I'll need to make sure that the new keyserver deploy I perform happens late at night.

I think @inka is going to need to do something similar soon (see here) – I wonder if we could just run this migration once for both of those projects, instead of needing to run it twice.

lib/types/thread-permission-types.js
272 ↗(On Diff #40264)

Farcaster needs to be capitalized... it's a proper noun...

native/redux/persist.js
1293–1299 ↗(On Diff #40264)

Why don't we have an equivalent migration on web?

In this case we probably need a real migration since we're gating on web codeVersion above. But even if we didn't, I think @tomek's recent changes require each native migration to have a corresponding web migration (and vice versa). (Not sure if these changes have been landed yet.)

This revision now requires changes to proceed.May 16 2024, 10:18 AM
native/redux/persist.js
1293–1299 ↗(On Diff #40264)

My changes aren't landed yet - this will happen probably on Tuesday. I'll add a comment here if I land my changes before this diff is landed. (even if the corresponding web migration is added, we would need to maintain the same stare versions on both platforms)

Adding a dependency on the diff that will also require the migrations: D12235

inka requested changes to this revision.Jun 4 2024, 4:39 AM

Can we split this diff into two - one with migrations and one with the rest? The reason is we are supposed to run these migrations for both this code and my code in D12235. And I will need the diff with migrations to also change my FUTURE_CODE_VERSION to NEXT_CODE_VERSION flag.

native/redux/persist.js
1293–1299 ↗(On Diff #40264)

I landed diffs with the new approach to migrations. After rebasing, this migration should be placed in migrations instead of the legacyMigrations. Also, it should return all the DB ops instead of executing them.

In D12062#349869, @inka wrote:

I will need the diff with migrations to also change my FUTURE_CODE_VERSION to NEXT_CODE_VERSION flag.

The FUTURE_CODE_VERSION that @inka references here is in keyserver/src/fetchers/thread-fetchers.js and was introduced in D12235. We should update this diff to change those FUTURE_CODE_VERSIONs to NEXT_CODE_VERSIONs.

I will be absent next 1.5 weeks, so remove me from review if needed. I just need this FUTURE_CODE_VERSION/NEXT_CODE_VERSION flag change

update + address comments

keyserver/src/fetchers/thread-fetchers.js
297–300 ↗(On Diff #41259)

This change should address @inka's feedback

lib/types/thread-permission-types.js
283–284 ↗(On Diff #41259)

This copy was introduced and should be reviewed

ashoat added inline comments.
lib/types/thread-permission-types.js
283–284 ↗(On Diff #41259)

Let's go with this:

Allows members to associate your community with a Farcaster channel, or to delete the association.

This revision is now accepted and ready to land.Jun 13 2024, 8:00 AM
lib/types/thread-permission-types.js
283–284 ↗(On Diff #41259)

All the other permission descriptions don't have a period at the end, so to keep this permission consistent with the rest, I dropped the period here too

Thanks, my bad on that

lib/types/thread-permission-types.js
285 ↗(On Diff #41308)

Please keep lines to 80 chars

keyserver/src/fetchers/thread-fetchers.js
297–300 ↗(On Diff #41259)

Thank you!