Roles and permissions

ForumFrame's role system is live, and it's the kind of role system you'd want to use. Not "Member, Moderator, Admin, take it or leave it" — a real one, with custom roles, custom names, custom colors, and a permission grid that gates 40 distinct actions across posting, moderation, administration, and ownership.

There's a new tab at the top of admin mode called Roles. Open it on your forum and you'll see five roles already configured — Owner, Admin, Moderator, Member, Guest — with sensible defaults. Click any one to open the editor.

Identity. Each role has a name, a color (the name in chat, replies, and member cards picks up the role's color — Discord-style), an optional icon badge, and an optional display title that shows under the member's name in profile cards.

Permissions. A grid grouped by capability area: Posting, Reading, Messaging, Moderation, Administration, Member management, Ownership. Every action has a three-state toggle — allow, deny, or "not set" (treated as deny unless another role allows). Deny wins when a member holds multiple roles. That last part matters more than it looks: you can build a "Mute" role that denies posting and reacting without removing the member's normal roles, and they snap right back when you remove the Mute role.

Members. Assign members to roles from the role editor (typeahead picker, instant) or from a member's profile in admin mode (checkbox list, also instant). Members can hold any number of roles at once. Owner is locked from manual assignment — use Transfer Ownership for that.

The Why? debugger. Open any member's profile in admin mode and you'll see a "Permissions debug" accordion. It walks every permission key and shows you which roles grant it, which deny it, and what the final resolved state is. Invaluable for "why can't this member create polls" support questions.

Custom roles. Hit the New role button on the list view. Name it, color it, tick the permissions you want. Drag roles up or down to reorder them in the list — order is just a display preference, the permission resolution itself is order-independent (deny still wins).

System roles can be edited freely — recolor Moderator, give Members the ability to use polls, tighten Admin's access. The only locked thing is the system role names, because the resolver uses them to identify default roles and the Owner-only special cases.

Five weeks of work behind this. The schema landed first, then the resolver, then the editor, then a 40-file integration pass replacing the old four-role enum across every gated action in the product. The migration's been running dual-write for a week and the cutover happens after a soak window. None of that should be visible to you — your existing roles work exactly as they did, you just have more knobs to turn now.

Coming next: per-category permission overrides (V3.1), auto-promotion rules ("after 30 days and 10 posts, promote to Trusted"), and self-assignable cosmetic roles. The schema's already there for all three; the editor UI ships next.