XiriGo Admin DocsRoles & Permissions
Understand the role-based access control (RBAC) system that governs who can do what in the Admin Panel.
Roles & Permissions
The XiriGo Admin Panel uses a Role-Based Access Control (RBAC) system to ensure that administrators only have access to the features and data they need. Every action in the panel is governed by permission checks.
Role Hierarchy
| Role | Access Level | Description |
|---|---|---|
| Super Admin | Full platform access | Unrestricted access to all modules, settings, and administrative actions. Can create and manage other admin accounts. |
| Operations Manager | Marketplace + Finance | Manage vendors, orders, products, customers, commissions, and payouts. Cannot modify system settings or manage admin users. |
| Content Manager | Content + Marketing | Manage banners, announcements, campaigns, coupons, and loyalty program. Read-only access to marketplace data. |
| Support Agent | Disputes + Orders (read) | Handle disputes, moderate reviews and Q&A, view orders and customers. Cannot modify financial settings. |
| Analyst | Analytics (read-only) | View dashboards, reports, and search analytics. Export data. No write access to any module. |
The Super Admin role is the default for the initial platform setup. Additional roles can be configured as your team grows.
Permission Scopes
Permissions are organized by module and action type. Each role is assigned a set of permission scopes that define what they can access.
Permission Structure
Permissions follow the pattern module:action. Available actions are:
| Action | Description |
|---|---|
read | View data and listings |
create | Create new records |
update | Modify existing records |
delete | Remove records |
manage | Full control (includes all above actions) |
Module Permissions
| Module | Permission Scopes |
|---|---|
| Vendors | vendors:read, vendors:create, vendors:update, vendors:manage (includes approve/suspend/ban) |
| Orders | orders:read, orders:update, orders:manage (includes returns, claims) |
| Products | products:read, products:update, products:manage (includes moderation) |
| Customers | customers:read, customers:update, customers:manage |
| Finance | finance:read, finance:manage (includes commission rules, payout actions) |
| Disputes | disputes:read, disputes:update, disputes:manage |
| Content | content:read, content:create, content:update, content:delete |
| Campaigns | campaigns:read, campaigns:create, campaigns:update, campaigns:manage |
| Loyalty | loyalty:read, loyalty:manage |
| Search | search:read, search:manage (includes synonyms, redirects, merchandising) |
| Analytics | analytics:read, analytics:export |
| Settings | settings:read, settings:manage |
| Audit | audit:read, audit:manage (includes admin user management) |
Role-Permission Matrix
The following table shows which permissions are granted to each built-in role:
| Permission | Super Admin | Ops Manager | Content Manager | Support Agent | Analyst |
|---|---|---|---|---|---|
vendors:manage | Yes | Yes | - | - | - |
orders:manage | Yes | Yes | - | Read only | - |
products:manage | Yes | Yes | - | - | - |
customers:manage | Yes | Yes | - | Read only | - |
finance:manage | Yes | Yes | - | - | - |
disputes:manage | Yes | - | - | Yes | - |
content:manage | Yes | - | Yes | - | - |
campaigns:manage | Yes | - | Yes | - | - |
loyalty:manage | Yes | - | Yes | - | - |
search:manage | Yes | - | - | - | - |
analytics:read | Yes | Yes | Yes | - | Yes |
analytics:export | Yes | Yes | - | - | Yes |
settings:manage | Yes | - | - | - | - |
audit:manage | Yes | - | - | - | - |
Managing Roles
Go to System > Audit > Admin Users in the sidebar.
Click Create Admin to add a new administrator, or click on an existing user to edit their role.
Select the appropriate role from the dropdown. The permission scopes are automatically applied based on the selected role.
Click Save. The user's permissions take effect immediately on their next page load or API call.
Only Super Admin users can create, modify, or delete other admin accounts. This prevents privilege escalation by lower-level roles.
Permission Enforcement
Permissions are enforced at two levels:
- Frontend (UI) — Sidebar items, buttons, and pages are conditionally rendered based on the logged-in user's permissions. Unauthorized modules are hidden from navigation entirely.
- Backend (API) — Every API endpoint validates the caller's JWT token and checks permission scopes before processing the request. Even if a user bypasses the UI, the backend rejects unauthorized actions with a
403 Forbiddenresponse.
All permission checks and access denials are logged in the Audit Log for security monitoring.