My understanding is that

• threadOrParentThreadHasAdminRole check was added as part of https://phab.comm.dev/D291
• That diff references discussion on the following GitHub issue: https://github.com/CommE2E/comm/issues/116#issue-729618910
• It looks like 3.i is the relevant part of the issue description:

I might be missing something obvious here, but my understanding is that this check was added to threadIsWithBlockedUserOnly before all threads were moved into communities. It appears that this check was intended to handle threads that lived "outside" any thread hierarchy that included an admin role. Specifically, PERSONAL threads and LOCAL/COMMUNITY_SECRET_SUBTHREADs where eg all but two members have left the thread?

Assuming the following are true

1. All threads must now live within a community
2. All communities must have an Admin role (?)

I believe threadOrParentThreadHasAdminRole, updated to check community root for admin role, would always return true. Consequently threadIsWithBlockedUserOnly would always return false.

I don't think this check/logic is still relevant...and if it is, it should probably be updated.

Depends on D11286

This function is consumed by threadFrozenDueToBlock and threadFrozenDueToViewerBlock.

Those are consumed by checkThreadsFrozen, getMinimallyEncodedCurrentUser, web/ChatInputBar, and native/ChatInputBar.

I will go through each of those and ensure that functions/components continue to work as expected.