eZ Platform Roles & Permissions | OpsBlu Docs

eZ Platform Roles & Permissions

eZ Platform (Ibexa DXP) role-based access control -- policies, limitations, and content tree permissions.

eZ Platform (now Ibexa DXP) uses a policy-based access control system. Roles contain policies, and policies define what actions users can perform on which content. Policies can have limitations that restrict their scope.

Permission Architecture

Roles in eZ Platform consist of Policies. Each Policy has:

  • Module -- the system area (content, section, user, etc.)
  • Function -- the action (read, create, edit, delete, etc.)
  • Limitations -- restrictions (specific content types, subtrees, sections)

Built-in Roles

Role Description
Administrator Full access to all modules and functions
Anonymous Public access (read-only for published content)
Editor Content creation and editing within assigned sections
Member Authenticated user with basic front-end access

Permission Matrix

Module/Function Administrator Editor Member Anonymous
content/read Yes Yes (limited) Yes (limited) Yes (published)
content/create Yes Yes (limited) No No
content/edit Yes Yes (limited) No No
content/remove Yes No No No
content/manage_locations Yes No No No
section/assign Yes No No No
user/login Yes Yes Yes No
role/assign Yes No No No
setup/administrate Yes No No No

Creating Custom Roles

Use the Admin UI or PHP API to define roles:

// Create a custom role via the PHP API
$roleService = $repository->getRoleService();

// Create the role
$roleCreateStruct = $roleService->newRoleCreateStruct('AnalyticsManager');
$roleDraft = $roleService->createRole($roleCreateStruct);

// Add a policy: allow editing content in the "Analytics" section
$policyCreateStruct = $roleService->newPolicyCreateStruct('content', 'edit');
$policyCreateStruct->addLimitation(
    new SectionLimitation(['limitationValues' => [5]]) // Section ID 5
);
$roleDraft = $roleService->addPolicyByRoleDraft($roleDraft, $policyCreateStruct);

// Publish the role
$roleService->publishRoleDraft($roleDraft);

Or via the Admin UI: Admin > Roles > Create new Role > Add Policies.

Analytics-Relevant Permissions

Analytics scripts are typically added via Twig templates, requiring setup/administrate or template file system access:

{# templates/themes/default/pagelayout.html.twig #}
<head>
  {% block head_style %}{{ parent() }}{% endblock %}
  <script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>
  <script>
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments);}
    gtag('js', new Date());
    gtag('config', 'G-XXXXXXXXXX');
  </script>
</head>

REST API Scopes

eZ Platform REST API uses session or JWT authentication, inheriting the authenticated user's role permissions.

# Authenticate and list roles
curl -u admin:publish \
  "https://example.com/api/ezp/v2/user/roles" \
  -H "Accept: application/vnd.ez.api.RoleList+json"

Best Practices

  1. Use Policy Limitations to restrict editors to specific content subtrees or sections
  2. Create granular custom roles rather than over-permissioning the built-in Editor role
  3. For analytics, prefer adding scripts via SiteAccess-aware design configuration over direct template edits
  4. Audit role assignments via the Admin UI under Admin > Roles
  5. Use the section/assign policy carefully -- it controls content organization access
Back to top