MODX User Management | OpsBlu Docs

MODX User Management

MODX permission model overview covering Context Access, Resource Groups, user groups, and admin panel access controls for analytics teams.

MODX Revolution uses a layered permission system built on Access Control Lists (ACLs) that combine User Groups, Roles, and Access Policies. Unlike flat role systems, MODX scopes every permission to a specific Context (web, manager, or custom), making it possible to run multi-site installations where editors on Site A cannot touch Site B.

Permission model

MODX structures access around three interlocking concepts:

  • User Groups -- containers that hold users. A user can belong to multiple groups. Each group gets one or more Access Policy assignments scoped to a Context or Resource Group.
  • Roles -- numeric authority ranks (Super User = 0, Member = 9999). Lower numbers outrank higher numbers. Roles determine which policies within a group actually apply to a given user.
  • Access Policies -- named bundles of individual permissions (e.g., save_document, view, publish_document, manage_metatags). MODX ships several built-in policies: Administrator, Resource, Load Only, Element, Media Source, and more.

Permissions resolve at runtime by merging all policies from every group a user belongs to. The manager checks context_access, resource_group_access, element_category_access, and media_source_access for each request.

Built-in roles and common configurations

Role / Group Typical authority Key permissions
Super User (role 0) Full system access All policies, Install Package, Flush Sessions, Purge Cache, manage ACLs
Administrator (role 1) Manager access, no package install administrator policy on mgr context, manage users within own group
Content Editor (role 5) Create/edit Resources save_document, publish_document scoped to assigned Resource Groups
Designer (role 3) Template and Element editing save_template, save_chunk, save_snippet via Element policy
Media Manager (role 6) Upload and organize assets Media Source policy with create, save, remove on assigned sources
Read-Only Reviewer (role 9999) View content tree Load Only policy -- load and view permissions only

Role numbers are conventions, not hardcoded. You define your own in Security > Access Controls > Roles.

Admin UI paths

Task Manager path
Manage users Security > Manage Users
Create/edit User Groups Security > Access Controls > User Groups
Define Roles Security > Access Controls > Roles
Edit Access Policies Security > Access Controls > Access Policies
Assign Resource Group access Security > Access Controls > User Groups > [Group] > Resource Group Access
Context access Security > Access Controls > User Groups > [Group] > Context Access
Flush permissions cache Manage > Flush Permissions

API access management

MODX provides two API surfaces relevant to user management:

REST API (modRestController):

  • Token or session-based authentication
  • Permissions enforced server-side using the same ACL system
  • Custom REST controllers can check $this->modx->hasPermission('permission_name')

MODX Processors (internal API):

  • All CRUD operations route through processors at core/model/modx/processors/security/
  • Key processors: user/create, user/update, user/getlist, usergroup/create
  • Call via $modx->runProcessor('security/user/getlist') in plugins or snippets
  • Access validated against the calling user's merged ACL

API keys and tokens are not native to MODX core. Third-party extras like modRestApiKey or custom header-based authentication in .htaccess handle service-to-service access. Rotate credentials when team members leave.

Analytics-specific permissions

MODX does not ship a built-in analytics module, so analytics access depends on how tracking is implemented:

  • Google Tag Manager / GA snippet injection -- typically placed in a Template or Chunk. Restrict editing via Element Category Access policies so only users with the analytics role can modify the <head> chunk.
  • MODX Extras (e.g., Google Analytics Dashboard, Piwik Integration) -- these register custom manager pages. Control access by adding a Policy Template entry and assigning it to the analytics user group for the mgr context.
  • Custom dashboard widgets -- MODX supports custom manager dashboard widgets. Analytics read-only users can be given a policy containing only view and dashboards permissions.
  • Tag placement auditing -- use the Manager Log (Reports > Manager Log) to track who edited templates or chunks containing tracking snippets. Filter by action:element/chunk/update.

Create a dedicated Analytics user group with a custom policy that grants view on the mgr context and read access to specific Resource Groups or Element Categories containing tracking code. Deny save_template, save_chunk, and remove to prevent accidental tag deletion.

Example: Create an analytics-only user group via MODX processors:

// Create Analytics user group with restricted policy via MODX API
$response = $modx->runProcessor('security/usergroup/create', [
    'name' => 'Analytics Team',
    'description' => 'Read-only access to analytics templates and reports'
]);

// Assign context access with Load Only policy
$groupId = $response->getObject()['id'];
$modx->runProcessor('security/access/usergroup/context/create', [
    'target'    => 'mgr',           // manager context
    'principal' => $groupId,
    'authority' => 9999,            // Member role
    'policy'    => 'Load Only'      // view and load permissions only
]);

// Add a user to the group
$modx->runProcessor('security/usergroup/member/create', [
    'usergroup' => $groupId,
    'user'      => $userId,
    'role'      => 9999             // Member authority level
]);

Sub-pages

Back to top