Moderator system
What a moderator can see and do day to day
RKHM's Moderator role gives someone real admin-panel access without making them a full Admin — and it's the same generic mechanism whichever admin screens you're granting access to, whether that's your catalogue, comments, or anything else with an admin screen. This is not the same thing as the Manager system, which is about client-facing creator roles (Artist Manager, Podcast Manager) getting a slice of the admin panel for their own content — Moderator is a plain admin-area role with no client-facing side.
Roles, not just one Moderator
A role has a type: Guest, User, Moderator, or Admin. Guest and Admin are fixed — there's exactly one Admin role and it can't even be edited. Moderator and User are the two types you can create more of: you can define any number of separate Moderator roles, each with its own independent set of permissions, and assign different staff to different ones. The "4 default roles" mentioned elsewhere in these docs are just what a fresh install ships with, not a hard limit.
Two access modes
| Mode | What it means |
| All | Create, read, update and delete on every list screen in the admin panel — content, users, payments, comments and the rest. Settings pages, statistics, Page Builder and Menu Builder, plugin and theme management, and updates stay Admin-only whatever the mode. |
| Only checked | A per-screen grid: independent Create / Read / Update / Delete checkboxes for every object that has an admin screen, plus that screen's own existing filters reused to scope which rows the moderator can even see (for example, limiting them to one category, one status, or similar — whatever filters that screen already offers to any admin). |
If a person holds more than one Moderator role, RKHM merges them: holding even one "All" role grants everything outright; otherwise, the permissions and filters from every "Only checked" role they hold are combined together.
How access is actually enforced
Every admin action — viewing a list, creating, editing, deleting — checks this permission model at the moment it happens, not just by hiding a button in the interface (though the interface also never shows a button a moderator's role doesn't cover). An Admin, or a Moderator role set to "All", passes immediately. A Moderator role set to "Only checked" must have that specific screen and that specific action ticked, or the action is refused.
A refused attempt is logged as a Firewall privilege event, not silently dropped — the reasoning being that a legitimate user is never shown a button for something they can't do, so someone actually triggering a permission denial is worth a record of. This ties moderator enforcement directly into RKHM's built-in Firewall.
Why a Moderator can't use the client app on its own
Signing into the Admin panel checks whether your roles include an Admin-type role, and if not, whether they include a Moderator-type role — that's what gives you an admin session at all. Signing into the client app (as a regular visitor/customer) is a completely separate thing, gated on holding a User-type role. A Moderator role only ever grants an admin session; it does nothing for the client app. That's exactly why a Moderator needs a separate User-type role too if they also want to use the platform as a regular user — the two are unrelated permission checks.
There's no separate "moderation queue" — granting access IS the workflow
There isn't a dedicated moderation inbox distinct from the admin panel itself. Take comment moderation as the clearest example: a comment has an "approved" flag, with an admin filter to find unapproved ones and an approve/reject action — exactly the same shape as any other admin screen. Giving a Moderator role edit access to comments is the entire comment-moderation workflow; there's no separate system layered on top. The same is true for anything else you'd think of as "moderation" — if it has an admin screen, granting (or withholding) access to that screen is how you moderate it.
What this system does not do
- No built-in user ban/suspend action exists as a dedicated feature — user-level restrictions go through whatever admin access you've granted for the user object itself, not a separate "ban" button.
- No row-level ownership scoping beyond a screen's existing filters — you can't currently say "this moderator may only edit comments on their own uploads" unless that specific screen already has a filter that expresses it.
- No dedicated audit log of moderator actions beyond the Firewall's privilege-denial logging above — a moderator's successful actions aren't separately logged as "moderator activity."