Not possible. The only editable roles are custom roles. 

I was asking the same question, @Nina. 

@DannyPancratz maybe you can help with my use case. We’re using our (B2C) forum for private/hidden staff groups. We don’t want them to be able to post in the non-staff areas including the public categories. 

But every custom role also has a primary role. If we can’t create a primary role, how can I configure the permissions for each category so that X custom role can’t post. As the primary role permissions starts with access to all public areas, and then the permissions only build on top of that. Without a primary role with less permissions I can’t figure out a way to do it...

@timcavey I do something like that for our Ideation. 

The solution isn’t great, but probably should be easier for your use case. 

1. Toggle permissions OFF for Registered Users primary role (and other primary roles non-staff might have). 
2. Toggle permissions ON for the custom role
   1. Ensure all staff have the custom role (user overview has option for bulk add/remove of custom role)
   2. You can automate adding the custom role on sign up with Zapier
      1. Trigger on new user registration
      2. Filter by email for includes staff email domain
      3. Add custom role

Just saying but I am starting feel sad that Zapier is mentioned so many times here in inSpired. We should be able to do so much more just with the platform, without any third party tools and workarounds.

Maybe Gainsights next aqcuire is Zapier and they embeds it’s features to the community platform

Sorry OT.

Thanks @DannyPancratz. 

Safe to assume I should ensure all non-staff have a custom role that ends up turning permissions on, and leaving it off for the staff that already have the custom role applied? 

@timcavey If I understand your use case correctly (staff have access, others don’t), it’s the reverse. 

• All Staff users should have a specific custom role (ex. Staff role)
• Staff-only forums use these permissions:
  • Primary Roles: 
    • Registers Users - OFF for Visibility, Create Topics, Create Comments
    • Super Users and Moderators - OFF (if you have non-staff with these primary roles)
  • Custom Roles: 
    • ON for Staff to view, create topics and create comments

Your earlier comment is not quite correct

But every custom role also has a primary role.

Every user has to have a primary role, but primary roles and custom roles are not tied together. So, in the permissions outlined above, the custom Staff role having permissions ON overwrites their primary role being off. Custom roles serve as a way for allowing extra permissions. 

It may seem antithetical or contradictory that the custom role supersedes the “primary” role, but that’s how it works. 

Thanks again, @DannyPancratz. 

I’ve achieved access to the hidden staff-only group by manual invites. So whilst it’s not the best process, that problem has been solved. 

The problem that needs solving is how to prevent staff members being able to post in any other areas. I want a safeguard against it. Based on your advice, I could achieve this by:

1. Removing comment and topic posting permissions from the ‘registered user’ primary role
2. Automating a custom role that gets added to all registered users primary role
3. Removing this custom role from staff members
4. Making sure the staff custom role (which is already set up) allows for staff members to post in their hidden group. 

Have I got that right and is this version of your advice what you would recommend? 

@timcavey that looks right to me! Thanks for clarifying your scenario.

On the staff-only area, I didn’t quite catch you were using a group. It seems like you have the right solution for groups, although it’s not as easy to automate as a category (at least to my knowledge).