Skip to main content

Permission calculation

How Root combines roles, access rules, and overlays to determine what a member can do.

Root calculates permissions differently depending on the situation:

  1. Community Full Control: Members with this permission bypass all calculations and have full access everywhere.
  2. Community-wide permissions: Permissions like Manage Roles or Create Bans are determined only by roles.
  3. Channel permissions: Permissions like Send Messages or Delete Messages depend on roles, access rules, and permission overlays.

Community Full Control

If any of the member's roles has Community Full Control enabled, the member has every permission everywhere and bypasses all access rules and permission overlays. This is the most powerful permission. Use it sparingly.

When a member has Community Full Control:

  • All community-wide permissions are granted
  • All channels are visible (access rules are bypassed)
  • All channel permissions are granted (permission overlays are bypassed)

The rest of this article describes how permissions are calculated for members who do not have Community Full Control.

Community-wide permissions

Community-wide permissions (like Manage Community, Manage Roles, or Create Bans) are determined only by roles. Access rules and permission overlays do not apply.

How it works

Root combines all of the member's roles using OR logic: if any role grants a permission, the member has it.

Example:

PermissionEVERYONE roleModerator roleCombined result
Invite Users
Manage Roles
Manage Bans

The member can invite users (both roles allow it), manage roles (Moderator allows it), but cannot manage bans (neither role allows it).

Flowchart

Channel permissions

Channel permissions (like Send Messages, Delete Messages, or Stream Video) depend on both roles and access rules.

Step 1: Check access

First, Root checks whether the member has an access rule granting them visibility to the channel. Without an access rule (through a role or as an individual), the member cannot see the channel at all.

Step 2: Combine role permissions

The member's base channel permissions come from their roles, combined using OR logic: if any role grants a permission, the member has it.

Example:

PermissionEVERYONE roleModerator roleCombined result
Send Messages
Delete Messages
Manage Pinned Messages

Step 3: Apply permission overlays from channel group

Root checks if the channel group's access rules include any permission overlays. Permission overlays use tri-state values to adjust role permissions for that specific location:

StateEffect
AllowGrants the permission, regardless of role settings
DenyRemoves the permission, regardless of role settings
InheritNo change; uses the role permission

Example:

A member with the Moderator role wants to send a message in the "Announcements" channel group. The Moderator role has "Send Messages" enabled.

The channel group has an access rule for the Moderator role. Depending on what the overlay says for "Send Messages":

If the overlay is set to...ResultWhy
Inherit✓ AllowedThe overlay doesn't override anything, so the role's "Send Messages" permission applies.
Deny✗ DeniedThe overlay explicitly denies the permission, overriding what the role allows.
Allow✓ AllowedThe overlay explicitly allows it (same result as the role, but the overlay would win even if the role denied it).

Now consider a different member with only the EVERYONE role, which does not have "Send Messages" enabled:

If the overlay is set to...ResultWhy
Inherit✗ DeniedThe overlay doesn't override anything, and the role doesn't grant the permission.
Deny✗ DeniedThe overlay explicitly denies it (same result, but now enforced by the overlay).
Allow✓ AllowedThe overlay explicitly allows the permission, overriding what the role would normally deny.

Step 4: Apply permission overlays from channel

Finally, Root checks the specific channel for permission overlays. This step only applies if the channel does not sync permissions to its channel group.

  • If Sync permissions is enabled (the default), the channel uses the channel group's permission overlays
  • If Sync permissions is disabled, the channel's own permission overlays override everything

The deny-wins rule

When multiple permission overlays apply to the same member (for example, through different roles), Deny always wins.

Example:

A member has both the "Moderator" and "Trial Moderator" roles. Two access rules with permission overlays exist on a channel:

Role"Delete Messages" overlay
ModeratorAllow
Trial ModeratorDeny

Result: The member cannot delete messages. The Deny from "Trial Moderator" overrides the Allow from "Moderator."

important

Deny always wins. If any permission overlay that applies to a member denies a permission, they won't have it, even if another overlay or role allows it.

Member-specific access rules

Access rules can target individual members, not just roles. A member-specific access rule grants that person access to the channel. If the rule includes permission overlays, they are evaluated alongside role-based overlays, and the same deny-wins logic applies.

Example:

The "Moderator" role allows "Delete Messages" in a channel. However, an access rule specifically denies "Delete Messages" for the member "Alex."

Result: Alex cannot delete messages in that channel, even though they're a Moderator.

Flowchart

Examples

Private admin channel

Goal: Only admins can see and use the "Admin Planning" channel.

Setup:

  1. Remove the EVERYONE access rule from the channel (or channel group)
  2. Add an access rule for the "Admin" role

Result: Only members with the Admin role can see the channel. No permission overlays are needed—the Admin role's permissions apply automatically.

Read-only announcements channel

Goal: Everyone can read announcements, but only moderators can post.

Setup:

  1. Keep the EVERYONE access rule (so all members can see the channel)
  2. Add a permission overlay to EVERYONE with "Send Messages" set to Deny
  3. Add an access rule for "Moderator" with a permission overlay setting "Send Messages" to Allow

Result: All members can view the channel and read messages. Only moderators can post new messages.

Temporary restriction

Goal: Restrict a specific member from posting in one channel while investigating an issue.

Setup:

  1. Add a member-specific access rule for that member on the channel
  2. Add a permission overlay with "Send Messages" set to Deny

Result: The member can still see the channel but cannot post. Their permissions in other channels are unaffected.