Roles, Views and access
A WordPress role determines native capabilities. A PanelKind View determines presentation. PanelKind access rules can restrict supported resources but cannot grant a native capability the user lacks. A menu's visibility is separate from permission to access its destination.
View selection
Protected owners and recovery retain native administration. For other users, a specific user assignment wins, otherwise the assigned role with the highest priority wins, otherwise the site's default View is used. Role priorities must be unique. New/changed individual assignments require Pro; assigning the same Free client View to several existing roles is allowed.
Access precedence
The user must be signed in. Protected owners/recovery bypass PanelKind restrictions; essential Profile access remains reachable. Native WordPress capability checks still apply. For other resources, policy resolves in this order:
- Mandatory site restrictions deny access.
- An explicit individual rule applies before role rules.
- Explicit role rules apply; Deny wins among conflicting role rules.
- Role defaults apply; Deny wins among conflicting defaults.
- The site default applies when nothing more specific decides.
The access inspector explains the source of a decision. Role and mandatory policies are available in both editions. New or changed individual exceptions require Pro. Hiding a menu alone does not protect a direct URL. Conversely, an Allow rule cannot grant missing native capabilities.
Linked custom roles
Under Roles & Permissions → Create role, choose a name, an existing WordPress/plugin permission base and a starting View. Default creation can make a separate View, so on Free reuse the existing client View rather than create capacity beyond its allowance.
The role editor has Sidebar & View, Permissions, Members and Role settings. Custom roles inherit native capabilities from their base, excluding PanelKind management capabilities beginning with wpa_. They do not inherit that base's PanelKind View, audiences or access rules, and the user does not become a member of the base role. Linked custom roles cannot be permission bases for other linked roles.
Base changes synchronise on subsequent requests while PanelKind is active; an occupied write lock can defer this. If a base disappears, the role falls back to account access until an owner repairs it. A role assigned to an agency owner cannot have its base changed until that owner is reassigned.
Creating, renaming, changing the base or deleting a native role is immediate and owner-only. Workspace Views and policies remain draft/publish settings. Publish the intended configuration before assigning users to a newly created role through WordPress Users. Delegated access managers do not gain authority to alter native role grants.
Only PanelKind-created custom roles are editable/deletable through this role editor. Delete a role only after removing members, default-registration use, published/draft assignments, policies and widget/page audience references. Native role definitions are outside revisions and configuration exports. Deactivation stops synchronisation; assigned/default roles retained on uninstall become ordinary roles with their last native permissions.
Management delegation
Both editions can delegate separate permissions for View management, access rules, content, settings, publication and export. Delegates remain subject to edition limits and authorisation for each changed configuration area. Publishing a shared draft requires authority for all its changes, including changes staged by another manager. Agency-owner recovery, native-role mutations and license management have additional owner requirements. Preview starts are owner-only.
Discovered third-party screens may have only screen coverage. Separate REST, AJAX, admin-post, XML-RPC or other handlers require native permission checks and appropriate tested adapters. Full administrators may be able to deactivate the plugin; native least-privilege roles remain the permission boundary.