Glossary & Legends

ERPat's built-in AI assistant. In Helpdesk it powers the Company Handbook sectioner: after PDF text is extracted, AkbAI maps each detected section into strict JSON ({title, html, category, excerpt}) which is then sanitized and drafted. Configured via AKBAI_HOST / AKBAI_KEY; if unconfigured, uploads still extract, section and draft from the cleaned text for manual HR editing (no AI mapping).

The per-permission scope selector in the Roles editor. all grants access to every record; a "specific" access type narrows a user to only records they are related to. In the models this is the access_type option — when it is not "all" and the user is not an admin, queries are constrained (e.g. tickets to the user's own/assigned/collaborated rows; help articles to allowed_categories). See Permissions Reference.

A single knowledge item. In the Wiki/KB it is a help_articles row (with title, description, category_id, total_views). In the Handbook it is a handbook_articles row (with body, excerpt, section_hash, status).

The grouping an article belongs to. Wiki/KB categories live in help_categories (carrying the type discriminator and a status); Handbook categories in handbook_categories. Articles reference their category by category_id; category-level permits (help_category*, knowledge_base_category*) gate management.

A user added to a ticket beyond its requester and assignee, so they can follow and comment. Stored as a comma-separated list in tickets.collaborators and matched with FIND_IN_SET(...). Managing collaborators is gated by ticket_collaborator.

A reply or note on a ticket, stored in ticket_comments. Attachments are kept in the serialized ticket_comments.files column (files are removed from disk when a ticket is soft-deleted via delete_ticket_and_sub_items()). Posting comments is gated by ticket_comment.

The tenant identifier the API layer uses to resolve which tenant database to open. Integration/End-User API requests must carry it (a missing one yields a missing_company_key envelope). In public short links the tenant's company key is stored encrypted at rest (tenant_company_key) so it never appears in the URL.

The AkbAI-assisted pillar for publishing employee policies. HR uploads a born-digital PDF (or starts from a DOLE-aware template); AkbAI splits it into draft sections which HR reviews and publishes to an employees-only reader. Icon fa-magic. See Company Handbook.

The header/footer/theme wrapper borrowed from the Content (CMS) module for Helpdesk's public pages (public KB, shared pages, external ticket form) via CmsThemeService::render_partials(). It is a soft dependency — when the Content module is unavailable the surface falls back gracefully (e.g. Help_center 404s) rather than disabling all of Helpdesk.

Background jobs registered under modules/Helpdesk/jobs/ (namespace Modules\Helpdesk\Jobs) and discovered by the JobRegistry. Each has a stable slug: helpdesk_process_handbook_imports (Handbook sectioner), run_imap (email-to-ticket poll), and close_inactive_tickets (auto-close sweep). List them with php erpat cron:list.

A built-in, DOLE-aware starter handbook. Choosing "Start from DOLE Template" (handbook_start_template) seeds a set of draft articles across a 14-category taxonomy for HR to review and publish — an alternative to uploading a PDF.

The two-state publishing model for articles. draft = not yet visible to readers (awaiting review/approval); published = live. In the Handbook these are the exact handbook_articles.status values; the reader only serves published.

The self-service API surface (/v1/api/me/*) for the authenticated employee: me/help-articles (read the org KB) and me/tickets (list/create/view own tickets, post messages). Backed by the flat module controllers Helpdesk_euapi and Helpdesk_tickets_euapi, routed by euapi_routes.php. See Developer APIs.

The public, CMS-themed support landing rendered by the flat Help_center guest controller (route help-center). It soft-depends on the CMS module's CmsRouteResolver. Distinct from the in-app "Help Center" sidebar group that lists the pillars.

The unified launchpad controller (Helpdesk, route helpdesk) that links to each enabled pillar. It is the module's staff landing; the individual Help Center pillars also surface directly in the sidebar's Help Center group.

The strict HTML allow-list (ezyang/htmlpurifier) applied to Handbook article bodies. Implemented as Handbook_html_sanitizer::purify() and enforced as a single write choke point in Handbook_article_model::save() — every body write is purified so the raw-echoing employees-only reader can't become stored XSS.

Inbound email intake. The Imap library (deps ddeboer/imap + willdurand/email-reply-parser; needs ext-imap) polls a mailbox on the run_imap cron and turns messages into new tickets or replies. See Tickets — Email & Automation.

One handbook ingestion run — a handbook_imports row. It records the source_type (PDF upload vs. DOLE template), the pipeline status, an attempts counter, and an error_message when review is needed.

The read-only, server-to-server API surface (/api/v1/help/*) exposing Help Center categories and articles. Scope help:read; backed by the flat Helpdesk_api controller and api_routes.php. Endpoints: help/categories[/{id}], help/articles[/{id}].

The staff-only knowledge pillar. Articles live in help_articles discriminated by type = 'help'; managed by the Help controller and gated by the help permits. Icon fa-book. See Internal Wiki.

The stateless bearer token authenticating API callers. The End-User API expects a valid JWT for the employee (no additional permit beyond a valid session for read endpoints); the middleware pipeline (tenant + JWT + scope) runs from the base controller regardless of which URL reached the flat controller.

The public-facing knowledge pillar. Articles are help_articles rows with type = 'knowledge_base'. When module_knowledge_base is enabled, published KB content is readable by anonymous visitors (the controller uses OptionalAuthGuard); management stays permission-gated. Icon fa-lightbulb-o. See Knowledge Base.

Freeform tags applied to tickets, stored as a comma-separated list in tickets.labels and matched with FIND_IN_SET(...). In this version ticket priority is expressed through labels (there is no discrete priority column). Adding labels is gated by add_ticket_label; ticket types can also carry their own labels.

Schema changes. The Handbook's three tenant tables (handbook_imports/handbook_categories/handbook_articles) are created by module migrations under modules/Helpdesk/migrations/, tracked in migrations_helpdesk and run by php erpat migrate:modules. All other Helpdesk tables ship in the base install schema and their ALTERs remain core migrations (in application/migrations/). The master toggle module_helpdesk is seeded by a core migration because settings is a shared per-tenant table.

ERPat runs one database per tenant (dash_{company_slug}). Login validates against the primary DB; a hook switches the active DB per request. All Helpdesk pillar tables are per-tenant; only the Tools-owned short-link table is primary-DB pinned so it can resolve before tenant context exists.

Open Graph metadata (meta_title / meta_description / meta_image) emitted on a shared link so social/chat unfurls show a preview. For public short links they are auto-fetched (SSRF-guarded for external URLs) with editable overrides, then emitted by the resolver before delivering the target.

The guard (App\Guards\OptionalAuthGuard) that resolves a logged-in user when a session exists but never redirects a guest to sign-in. It powers the public Knowledge Base: guests read active/published content, while a logged-in staffer still gets their in-app experience. All write/management authorization still returns false for a guest.

A named capability stored in the serialized users.permissions and checked at runtime. Helpdesk declares its keys in config/permissions.php — e.g. ticket, ticket_manage, help, knowledge_base, page, handbook_publish. Access = the pillar's module toggle enabled AND the permit granted. Full list: Permissions Reference.

One of the distinct capabilities the Helpdesk umbrella brings together: Tickets, Internal Wiki, Knowledge Base, Web Pages and Company Handbook. Each pillar has its own controllers, permits, and (except Handbook) its own sub-toggle.

The willdurand/email-reply-parser library used by email-to-ticket to strip quoted history and signatures from an inbound email, so only the new reply text becomes the ticket comment.

The OAuth-style permission attached to Integration API tokens. The Help Center Integration API endpoints require the help:read scope and are read-only. Enforced by the API middleware pipeline before the controller runs.

A content-based idempotency key on handbook_articles — a sha1 that folds the import id, section path, PROMPT_VERSION and a sha1 of the normalized title+body. The cron uses find_by_section_hash() as a resume guard so a re-run never spawns duplicate drafts. The lookup deliberately ignores deleted=0 to match the UNIQUE index and avoid duplicate-key crashes after a soft-delete.

A logical chunk of a handbook PDF, detected by heading heuristics (Handbook_section_detector) and turned into one draft article. Sections are what AkbAI maps and what section_hash deduplicates.

Public /s/{code} links (7-char base-56 codes, an unambiguous alphabet omitting 0/O/1/l/I) resolved by the Tools module's Tools_shortlink controller from the primary-DB tool_shortlinks table. Two tools exist: a standard Sharable Link Generator and a URL Shortener — both ship active/public (free) in the current source. Helpdesk's Web Pages pillar consumes this — the capability is not owned by Helpdesk or core.

The boilerplate footer appended to outbound ticket email. Inbound, the reply parser removes signatures so quoted footers don't pollute the recorded comment.

A URL-safe identifier for a record. Public pages are served by slug via the About renderer at /about/{slug}; Handbook categories carry a slug (exposed as category_slug in article queries) for reader navigation.

The response-time window for a ticket. When a ticket has no explicit tickets.due_date, the overdue calculation falls back to its type's ticket_types.duration (measured in hours) added to created_at. Overriding a due date is gated by override_ticket_due_date.

A per-pillar on/off setting nested under the master toggle: module_ticket, module_help, module_knowledge_base and module_page. They let each pillar be enabled independently within an enabled Helpdesk. (The Handbook pillar has no separate sub-toggle in this version.)

A support request — one tickets row. Key columns: status, ticket_type_id, assigned_to, requested_by, collaborators (CSV), labels (CSV), due_date, client_id/vendor_id. Managed by the Tickets controller and the ticket* permits.

A named bundle of ticket types (ticket_groups, whose ticket_types_id is a CSV of type ids), used for routing and filtered listing. Filtering by group matches tickets whose type is in the group's set via FIND_IN_SET. Managed with the ticket_groups permits.

The ticket_logs table used for flood control / rate-limiting on public ticket submissions, guarding the external form against abuse.

A reusable, pre-written response stored in ticket_templates that an agent can insert into a comment to answer common questions consistently.

The category of a ticket (ticket_types), carrying a title, an SLA duration, points, and its own labels. A ticket references it via tickets.ticket_type_id. Overriding a ticket's type is gated by override_ticket_type.

A view counter on articles (help_articles.total_views, handbook_articles.total_views), incremented on read (increas_page_view() / increment_view()) and used to sort suggestions/popular articles.

The help_categories.type column that splits the shared help_articles/help_categories tables into two pillars: help = staff-only Internal Wiki, knowledge_base = public Knowledge Base. Queries filter by type to keep the two surfaces separate.

The single master switch module_helpdesk that gates the whole Helpdesk umbrella. Combined with each pillar's permit and sub-toggle, it determines what a user can reach. Seeded on by a core migration.

A standalone content page in the Pages pillar (the legacy Pages capability, gated by the page permits). Distinct from the CMS. Public pages render through the About controller at /about/{slug} and can be shared via a Tools-owned short link. Icon fa-file-text-o. See Web Pages & Help Center.