Permissions Reference
The authoritative list of every Helpdesk RBAC permission key — grouped by pillar — with its exact label, displayed action, gate level, and what it controls. Every key on this page is reproduced verbatim from modules/Helpdesk/config/permissions.php.
How Helpdesk permissions work
Helpdesk ships its entire permission surface as a module-owned config file. These keys were migrated out of application/controllers/Roles.php into modules/Helpdesk/config/permissions.php so the module owns its own RBAC rows. The keys are identical to before the migration — existing role assignments were never touched, because permission checks read the serialized keys regardless of where the definition lives.
The dual permission-check system
Two permission APIs are live simultaneously, and both read the same serialized users.permissions blob — so it does not matter which one a given controller uses; they agree.
| System | Typical calls | Where it dominates |
|---|---|---|
| Legacy permits | current_has_permit(), module_enabled(), $this->with_permission(), $this->with_module() | The Helpdesk pillar controllers (Tickets, Ticket_types, Ticket_groups, Help, Knowledge_base, Pages, Handbook) — dominant across the module. |
| Modern Guards | $this->can(), $this->guard->hasModuleAccess() | Newer code paths and API controllers. Reads the same serialized keys. |
users.permissions serialization, granting a key in the Roles UI immediately satisfies both a legacy with_permission('ticket_manage') check and a modern can('ticket_manage') check. There is no separate "guard permission" store.Access = module toggle AND permit
A user reaches a Helpdesk feature only when both conditions hold: the relevant module toggle is enabled for the tenant, and the user's role grants the permit for that feature. The pillar controllers enforce this literally — for example Tickets::__construct() calls with_module("ticket", "redirect") immediately followed by with_permission("ticket", "redirect").
Master toggle vs. pillar sub-toggles
The Helpdesk umbrella is governed by one master setting plus four pillar sub-toggles. All are keys in the per-tenant settings table.
| Setting key | Governs | Notes |
|---|---|---|
module_helpdesk | The whole Helpdesk umbrella | Master toggle. Seeded on by a core migration (settings is a shared per-tenant table). When enabled, the Helpdesk permission rows appear in the Roles UI. |
module_ticket | Tickets pillar | Checked by with_module("ticket") in the ticket controllers and by ~15 cross-app checks (dashboard widgets, settings tabs, portals). |
module_help | Internal Wiki (Help) pillar | Gates the staff-only Wiki controller. |
module_knowledge_base | Knowledge Base pillar | When on, active KB content is a public read surface (guests allowed via OptionalAuthGuard). |
module_page | Web Pages pillar | Gates the Pages controller and the public About renderer. |
with_module('ticket'/'page'/'help'/'knowledge_base')), and several cross-app checks still read module_ticket/module_page directly. Unifying everything under a single module_helpdesk gate is a tracked app-wide follow-up, not yet complete. For now, keep both the master and the relevant pillar sub-toggle enabled.Row level types in the Roles UI
Each key's default_level decides how it renders on the role editor. There are three rendered shapes:
Renders an all / specific dropdown. Picking specific lets the admin scope the permit to selected records; picking all grants it globally. Only the umbrella-style "Access" rows use this.
Renders a single Enable toggle (on/off). This is the default when default_level is omitted for a parent that has no CRUD children.
The *_create, *_update, *_delete, and *_category* keys. Declared explicitly in the config to reproduce the legacy auto-generated child rows exactly. Their displayed action is resolved by _resolve_bootstrap_permission_action() from the suffix (e.g. _create → "Create", _category_create → "Create Category").
Roles::_append_bootstrapped_permissions(), which pulls the config through the module bootstrap. They surface only when module_helpdesk is enabled — if the master toggle is off, none of the keys below appear in the UI (even though a previously-granted key remains in users.permissions).Complete permission key table
Every key defined in modules/Helpdesk/config/permissions.php, in file order. Filter by key, label, action, or pillar. The Level column shows the rendered shape; Group is the displayed category label from the config.
| Key | Label | Group / Category | Action | Level | Pillar |
|---|---|---|---|---|---|
handbook | Handbook (read) | Help Center: Handbook | Enabled | Module toggle | Handbook |
handbook_create | Upload / Import Handbook | Help Center: Handbook | Create | CRUD child | Handbook |
handbook_update | Edit Handbook Drafts | Help Center: Handbook | Edit | CRUD child | Handbook |
handbook_delete | Delete Handbook Articles | Help Center: Handbook | Remove | CRUD child | Handbook |
handbook_publish | Publish Handbook to Employees | Help Center: Handbook | Enabled | Module toggle | Handbook |
ticket | Ticket Type | Help Center: Ticket Type | Access | Specific dropdown | Tickets |
ticket_create | Create Ticket | Help Center: Ticket Type | Create | CRUD child | Tickets |
ticket_update | Edit Ticket | Help Center: Ticket Type | Edit | CRUD child | Tickets |
ticket_delete | Remove Ticket | Help Center: Ticket Type | Remove | CRUD child | Tickets |
ticket_staff | Ticket Staff | Help Center: Ticket Staff | Access | Specific dropdown | Tickets |
ticket_staff_create | Create Ticket Staff | Help Center: Ticket Staff | Create | CRUD child | Tickets |
ticket_staff_update | Edit Ticket Staff | Help Center: Ticket Staff | Edit | CRUD child | Tickets |
ticket_staff_delete | Remove Ticket Staff | Help Center: Ticket Staff | Remove | CRUD child | Tickets |
ticket_collaborator | Ticket Collaborators | Help Center: Ticket Collaborators | Access | Specific dropdown | Tickets |
ticket_manage | Manage Tickets | Help Center: Manage Tickets | Enabled | Module toggle | Tickets |
ticket_comment | Ticket Comments | Help Center: Ticket Comments | Enabled | Module toggle | Tickets |
add_ticket_label | Add Ticket Label | Help Center: Allow Adding Ticket Label | Enabled | Module toggle | Tickets |
override_ticket_due_date | Override Ticket Due Date | Help Center: Override Ticket Due Date | Enabled | Module toggle | Tickets |
override_ticket_type | Override Ticket Type | Help Center: Override Ticket Type | Enabled | Module toggle | Tickets |
ticket_groups | Ticket Groups | Help Center: Ticket Groups | Enabled | Module toggle | Tickets |
ticket_groups_create | Create Ticket Group | Help Center: Ticket Groups | Create | CRUD child | Tickets |
ticket_groups_update | Edit Ticket Group | Help Center: Ticket Groups | Edit | CRUD child | Tickets |
ticket_groups_delete | Remove Ticket Group | Help Center: Ticket Groups | Remove | CRUD child | Tickets |
help | Internal Wiki | Help Center: Internal Wiki | Enabled | Module toggle | Internal Wiki |
help_create | Create Wiki Article | Help Center: Internal Wiki | Create | CRUD child | Internal Wiki |
help_update | Edit Wiki Article | Help Center: Internal Wiki | Edit | CRUD child | Internal Wiki |
help_delete | Remove Wiki Article | Help Center: Internal Wiki | Remove | CRUD child | Internal Wiki |
help_category | Wiki Category | Help Center: Internal Wiki | Enable Category | Category child | Internal Wiki |
help_category_create | Create Wiki Category | Help Center: Internal Wiki | Create Category | Category child | Internal Wiki |
help_category_update | Edit Wiki Category | Help Center: Internal Wiki | Edit Category | Category child | Internal Wiki |
help_category_delete | Remove Wiki Category | Help Center: Internal Wiki | Remove Category | Category child | Internal Wiki |
help_categories | Internal Wiki Category | Help Center: Internal Wiki Category | Access | Specific dropdown | Internal Wiki |
knowledge_base | Knowledge Base | Help Center: Knowledge Base | Enabled | Module toggle | Knowledge Base |
knowledge_base_create | Create KB Article | Help Center: Knowledge Base | Create | CRUD child | Knowledge Base |
knowledge_base_update | Edit KB Article | Help Center: Knowledge Base | Edit | CRUD child | Knowledge Base |
knowledge_base_delete | Remove KB Article | Help Center: Knowledge Base | Remove | CRUD child | Knowledge Base |
knowledge_base_category | KB Category | Help Center: Knowledge Base | Enable Category | Category child | Knowledge Base |
knowledge_base_category_create | Create KB Category | Help Center: Knowledge Base | Create Category | Category child | Knowledge Base |
knowledge_base_category_update | Edit KB Category | Help Center: Knowledge Base | Edit Category | Category child | Knowledge Base |
knowledge_base_category_delete | Remove KB Category | Help Center: Knowledge Base | Remove Category | Category child | Knowledge Base |
knowledge_base_categories | Knowledge Base Category | Help Center: Knowledge Base Category | Access | Specific dropdown | Knowledge Base |
page | Web Pages | Web Pages | Enabled | Module toggle | Pages |
page_create | Create Page | Web Pages | Create | CRUD child | Pages |
page_update | Update Page | Web Pages | Edit | CRUD child | Pages |
page_delete | Remove Page | Web Pages | Remove | CRUD child | Pages |
default_level => 'specific'). "Module toggle" = a single Enable toggle (default_level => 'module' or omitted). "CRUD child" / "Category child" = explicitly declared child rows whose action is derived from the suffix.Per-pillar key summary
Each pillar's keys grouped together for quick scanning. Cross-link jumps to the pillar's full documentation.
Company Handbook module_helpdesk
See Company Handbook. The Handbook pillar is fully module-owned and governed only by the master module_helpdesk toggle (no separate pillar sub-toggle).
handbook— read access to published handbook content.handbook_create— upload / import a handbook document (starts the extraction + AI sectioning pipeline).handbook_update— edit handbook drafts before publishing.handbook_delete— delete handbook articles.handbook_publish— publish the drafted handbook to employees.
Tickets module_ticket
See Tickets — Lifecycle and Tickets — Email & Automation. The largest surface — it splits into ticket-type CRUD, staff-side ticket handling, collaborators, management flags, and ticket groups.
ticket/ticket_create/ticket_update/ticket_delete— the Ticket Type surface (client-facing ticket access + type CRUD).ticketuses the all/specific dropdown.ticket_staff/ticket_staff_create/ticket_staff_update/ticket_staff_delete— the staff-side ticket handling surface;ticket_staffuses the all/specific dropdown.ticket_collaborator— access to add/manage ticket collaborators (all/specific dropdown).ticket_manage— the master "Manage Tickets" flag; combined with status checks it unlocks assignment, status transitions, and staff-reply actions inTickets.php.ticket_comment— permission to post ticket comments/replies.add_ticket_label— allow adding ticket labels.override_ticket_due_date— override a ticket's computed due date.override_ticket_type— override the ticket type (used in Tickets and Ticket_groups).ticket_groups/ticket_groups_create/ticket_groups_update/ticket_groups_delete— ticket group management CRUD.
Internal Wiki (Help) module_help
See Internal Wiki. Staff-only. Article CRUD plus a full category surface (both the inline category CRUD children and a separate all/specific help_categories access row).
help— enable the Internal Wiki pillar (module toggle row).help_create/help_update/help_delete— wiki article CRUD.help_category/help_category_create/help_category_update/help_category_delete— wiki category enable + CRUD.help_categories— separate all/specific access row for scoping wiki categories.
Knowledge Base module_knowledge_base
See Knowledge Base. Mirrors the Wiki key shape. Note: KB is a public read surface when its sub-toggle is on — anonymous visitors see active (published) content, but all create/edit/delete stays behind these permits.
knowledge_base— enable the KB pillar (module toggle row).knowledge_base_create/knowledge_base_update/knowledge_base_delete— KB article CRUD.knowledge_base_category/knowledge_base_category_create/knowledge_base_category_update/knowledge_base_category_delete— KB category enable + CRUD.knowledge_base_categories— separate all/specific access row for scoping KB categories.
Web Pages module_page
See Web Pages & Help Center. The simplest pillar — a module toggle row plus straight CRUD.
page— enable the Web Pages pillar (module toggle row).page_create/page_update/page_delete— web page CRUD.
Granting & assigning permits
1. Enable the toggles first
In Settings → Manage Modules, enable module_helpdesk and the relevant pillar sub-toggle (e.g. module_ticket). Until module_helpdesk is on, the Helpdesk rows will not appear in the Roles editor.
2. Open the role
Go to the Roles module and edit (or create) the target role. Scroll to the "Help Center" and "Web Pages" permission groups.
3. Set the parent access
For a specific-dropdown row (e.g. ticket, ticket_staff, ticket_collaborator, help_categories, knowledge_base_categories) choose all or specific. For a module-toggle row (e.g. ticket_manage, help, knowledge_base, page, handbook) flip Enable on.
4. Grant the CRUD/category children
Tick the *_create / *_update / *_delete and any *_category* children the role needs. A parent access permit does not automatically include write children.
5. Save and re-test as the user
Save the role. Because permits are serialized into users.permissions, affected users pick up the change on their next request. Verify by signing in as a member of the role and confirming the feature renders (access = toggle AND permit).
users.permissions yet still be blocked because the module toggle is off — the controllers check with_module() before with_permission(). If a role "has the permission" but the feature 404s or redirects, verify the pillar sub-toggle and the master module_helpdesk are both enabled for that tenant before touching the role.Troubleshooting
The rows are appended by Roles::_append_bootstrapped_permissions() and only surface when module_helpdesk is enabled for the tenant. Enable the master toggle in Manage Modules, then reload the role editor.
Access is toggle AND permit. The pillar controller runs with_module() first — confirm the pillar sub-toggle (module_ticket / module_help / module_knowledge_base / module_page) and module_helpdesk are both on. Knowledge Base and Wiki controllers 404 (rather than 403) when disabled to hide resource existence.
Parent access (e.g. ticket, help) does not imply the write children. Grant the explicit *_create / *_update / *_delete (and *_category*) keys the workflow needs.
No. with_permission()/current_has_permit() and can()/hasModuleAccess() read the same serialized users.permissions, so a granted key satisfies both. The pillar controllers happen to use the legacy calls throughout.
modules/Helpdesk/config/permissions.php is the single source of truth for the keys, labels, categories, actions, and default_level. The same list is mirrored in the permissions array of modules/Helpdesk/module.json.
Related pages
Tickets
Lifecycle, statuses, and where each ticket permit is enforced.
Knowledge Base
Public read surface + the KB permit set.
Internal Wiki
Staff-only articles and the help_* permits.
Company Handbook
Upload, draft, publish — and the handbook_* permits.
Web Pages
Glossary & Legends
Status badges, terminology, and legends.