How access is decided

The exact order the system uses to allow or deny a user — and where administrators and logged-out visitors fit in.

Whenever someone tries to use a gated ability or MCP server, the access check runs through a fixed order. Understanding it makes every setting predictable.

  1. Administrators are always allowed. Anyone with the manage_options capability passes every check, whatever the setting says.
  2. Everyone (no restriction) — if this is selected, all users are allowed, including visitors who aren’t logged in.
  3. A specific rule (Role, Users, Capability, BuddyBoss Profile Type, or MemberPress Membership) — the user must be logged in and match at least one of the items you ticked.
  4. Not logged in — when a specific rule is set, anonymous requests are denied.
  5. No user access added by admin — with no rule configured, the resource stays admin-only; everyone else is denied.

The “any of” principle

For roles, capabilities, profile types and memberships, the rule is inclusive: a user only needs one of the ticked items to be allowed. Ticking more options widens access; it never narrows it.

Fails safe: if a saved rule points at something that no longer exists — a deleted role, or an integration that’s been switched off — the check denies rather than accidentally opening the resource.

Was this page helpful?