Server permissions

The permissions page#

The dashboard's Permissions page is a read-only view. It renders the access rules stored for your server so you can audit who can run what; editing happens on Discord with the management commands or through a KAL command's own permission clause.

Rule structure#

Rules nest with the command hierarchy:

server rule       <- applies to every command
  module rule     <- applies to the module's commands
    command rule  <- applies to one command

Each rule is an allow-list with three lists:

• allowed channels — where the command may run,
• allowed roles — which roles may run it,
• allowed users — specific members who always may.

Each list holds at most 25 entries. A rule with all three lists empty permits everyone.

How a command is gated#

When someone runs a command, Kharat walks from the most specific rule to the broadest and checks the caller against the active lists. Two outcomes exist:

• Silent failure — an ordinary command blocked by a switch simply does nothing (no reply), which keeps channels clean.
• Explicit reason — management commands and permission-rule denials answer with a short explanation, so you always know why something refused to run.

KAL command permissions#

Custom commands gate themselves at the source level: a WHEN COMMAND trigger can carry a permission clause checked against the calling member:

WHEN COMMAND cleanup [permission: "ManageMessages"] {
    ...
}

The member is told exactly which permission is missing. This is independent of the rule lists above and is documented in Triggers.