1. Pass in an isEmpty flag instead of the entire selectedPermissions array in the clearPermissionsText memo

2. Pass a function to the setter in onEnumValuePress

3. Add the defintion of configurableCommunityPermissions in this diff since this is where it is used

In D8391#248457, @ashoat wrote:

After our discussion over chat, I think the new conclusion is that the client code for creating / managing roles shouldn't think about threadPermissions at all, and should instead use a new enum that reflects the list of user-facing permissions. The keyserver will handle converting from the new enum of user-facing permissions to threadPermissions... so some version of this data structure will likely still be necessary, but it will probably be keyserver-specific, and the format of the data structure might be different given differing requirements. Does that sound right to you @rohan?

Yes this sounds right, if we don't want the client to have to be aware of / think of threadPermissions, we could do the following:

1. On the client, only use configurableCommunityPermissionsOptions (this is the Set created from configurableCommunityPermissions, with the user-selectable options, instead of using configurableCommunityPermissions which is a mapping of threadPermissions / threadPermissionPropagationPrefixes + threadPermissions to user-facing selectable options.

2. Pass in all selected options as an array of ConfigurableCommunityPermissionOption, instead of a list of strings representing threadPermissions to the keyserver. Essentially, the keyserver would receive an array of:

[
   {
     title: 'React to messages',
     description: 'Allows members to add reactions to messages'
    },
    {
      title: 'Add members',
      description: 'Allows members to add other members to channels',
    }
]

3. In role-creator.js, we use configurableCommunityPermissions to derive all of the associated permissions with these selected options using the new helper getKeysByValue, i.e [react_to_message, descendant_react_to_message, add_members, descendant_add_members].

This would address the separation of client-side interaction and thread permissions, but also use a predefined enum to create the mapping and validate the input on the keyserver. Does this approach address your concerns?

2. Pass in all selected options as an array of ConfigurableCommunityPermissionOption, instead of a list of strings representing threadPermissions to the keyserver. Essentially, the keyserver would receive an array of:

[
   {
     title: 'React to messages',
     description: 'Allows members to add reactions to messages'
    },
    {
      title: 'Add members',
      description: 'Allows members to add other members to channels',
    }
]

This doesn't make sense to me. Why are you passing user-facing copy in an API request? Why aren't you using the aforementioned new enum instead?

In D8391#248474, @ashoat wrote:

This doesn't make sense to me. Why are you passing user-facing copy in an API request? Why aren't you using the aforementioned new enum instead?

Currently, I have one new enum (configurableCommunityPermissions), and a set derived from that enum (configurableCommunityPermissionsOptions). configurableCommunityPermissions like we discussed is in the format of one permission -> one user-facing option.

As of right now, I'm mapping over each user-facing option in the create-roles screen with configurableCommunityPermissionsOptions, and then when one is selected, using the configurableCommunityPermissions enum to get the associated permissions. Once the 'Create' button is clicked, I pass all selected permissions derived from the enum to the keyserver, validate it, and then insert into the DB.

Per our discussion / your feedback, you mentioned "The keyserver will handle converting from the new enum of user-facing permissions to threadPermissions". So my understanding of your request is to gather the selected user-facing options and use the new enum configurableCommunityPermissions to map from selected options --> specific threadPermissions on the keyserver rather than the client.

I skimmed through the last comment, as it's been a lot of back-and-forth recently and I want to move quickly here. Please keep that in mind, as I might've missed something.

But overall it seems like we're still not on the same page. Today we have an enum called threadPermissions. You seem to want to use that enum for client / keyserver communication. Instead, we want to make sure we don't use threadPermissions for client / keyserver communication, and instead use a new enum. It's important that you don't confuse "enum" with "data structure"... you seem to think the new structures you've introduced count as an enum, but that's not how I'm using the term "enum".

We need a new enum that is separate and distinct from threadPermission, is defined in a similar way, and does NOT reference threadPermissions in any way, and does NOT have some sort of data structure or something. It's just a simple enum.

Great work testing!