Page Permissions
Page Permissions is the ROOT-only control room for what each role can see and do in the panel. Every panel page and every in-page feature can be allowed, denied or left at its default, separately for ADMIN, RESELLER and USER. ROOT itself is not configurable: it always has full access.
Users → Page Permissionshttps://YOUR-SERVER-IP:8443/settings/permissionsThe model in one minute
Two layers of control, three values each:
- Page access decides whether a role can open a page at all.
- Feature access decides what a role can do inside it: every button and capability you have seen gated throughout this documentation (suspend, delete, PHP version switching, vhost editing...) is one of these keys.
Each can be Allow, Deny, or Default (inherit the built-in default for that role). When Default is selected, the effective result is shown next to it, so you always know what the role actually gets.
Working the page
Pick a role at the top (ADMIN, RESELLER or USER), then navigate the category tree on the left: twenty categories mirroring the panel sidebar, each with a status dot (green all allowed, red all denied, yellow mixed) and its page count. Selecting a page brings its detail to the right panel: the page-level Allow/Deny/Default switch on top, then the page's features grouped into collapsible sections, each with its own three-way choice. Features whose keys are destructive (delete, bulk, system-level) carry a red dangerous badge as a second look before you allow them broadly.
The search box filters pages by name, code or route path. Per page, three bulk buttons act on all its features at once: Allow All, Deny All and Reset Defaults.
Some combinations are filtered out for you: features a role could never use (for example admin-creation keys for the USER role) are hidden when that role is selected.
Saving and resetting
There is no save button: every click applies immediately. Two resets exist for cleanup, both behind confirmation dialogs: reset the selected role to its defaults, or reset everything across all roles, the latter with an explicit cannot-be-undone warning. A footer strip keeps the totals in view: pages, features and the implemented count, plus the role you are editing.
Access
The page is ROOT-only: the route itself refuses other roles, and the underlying permission APIs are ROOT-guarded server-side.