Fix indentation

Fix indentation

Rebase

Rebase

Move code

On the keyserver, when reactionMessageCreationResponder is called, it calls createMessages which in turn calls updateRepliesCount. Do we need to do something like this for DMs?

This solution requires us to query for every message separately. This seems very inefficient. Is this necessary?

Rebase

Rebase

Rebase

Rebase

Add newline

Rename

Rename to UpdateMessageSearchIndexOperation

Rename fix

Update wasm

Update .lock files

I need to update podfile

Rename to updateMessageSearchIndex

Rename to updateMessageSearchIndex

Heads-up that I landed a different migration 48 in D12759, so you'll have to rebase this one.

Remove patch and update package.json

Rebase

Rebase

Rebase

Rebase

Rename to containingThreadIDForPossibleMemberResolution

@ashoat I think we can make the release now. Should I do anything to make that possible?

Remove manual changes in XCode. I had to rever the changes in native/ios/Comm.xcodeproj/project.pbxproj for all of them to disappear.
I ran yarn cleaninstall and install pods and checked that removing and reinstalling the iOS app still doesn't throw

Don't call determineThreadAncestry twice

Sorry about this!

Memozie

Address review

The name getCommunityThreadIDForGenesisThreads seems to suggest that this function only returns values for GENESIS subchannels. Can you confirm this doesn't break for chats in other communities?

Rebase

Address review

For now it is possible to add any user that shows up in search results. On native we handle this in the UI by showing a popup if the user wants to add someone they cannot:

Use new approach - see the discussion in ENG-8710 - we want to unify web and native

shouldSkipPushPermissionAlert should probably be updated - if I understand correctly this diff makes it impossible for totalAlerts to exceed 1, is that correct?

Thank you for fixing this!

In D12667#358976, @ashoat wrote:

On Linear, you asked whether we should check the parent or the top ancestor under GENESIS for permissions. I suggested that the top ancestor made more sense, but I probably care more about consistency with native. What do we do there?

Thank you for explaining

I see that there is no CREATE_AND_EDIT_CHANNELS permissions, which lead me to finding a bug in our current app ENG-8710. Should we be able to create a subchannel of a thick thread?

That still doesn't explain why we need to wait for some users to be updated. But I'm guessing that we want old clients, who had their accounts setup with usingCSAT=false, to update to usingCSAT=true, and get their primary device registered (a mobile device). Is this correct? How will we know that all clients have been updated?

We want to make sure clients from before the rollout can still auth. We'll revert this soon after launch, once all of the clients have been confirmed to be updated. We don't need to keep it around longer than that because this only concerned brand new users, and brand new users can be expected to have the most recent version of the app.