Ticketing
Evidence gathered from the current module files before writing the user guide pages.
Research Sources Inspected
Source path
modules/Ticketing
Feature flags marked true
- Controllers
- Models
- Views
- Language
- Permissions
- Left Menu
- Default Menu
- Routes
- Migrations
- Helpers
Evidence Summary
Manifest
module.json defines slug ticketing, version 0.1.0, category Ticketing, and the module capability flags used in this guide.
Runtime surface
4 controller file(s), 15 view file(s), and 25 route mapping(s) were found.
Data surface
4 model file(s), 4 declared table(s), and 1 migration file(s) were found.
Operations surface
4 permission key(s), 0 job(s), 1 seeder(s), and 1 test file(s) were found.
Detailed File Evidence
Controllers and methods
Epass_AreaEpass_BlockEpass_SeatEventPass- overrideSeatsAllocation
Jobs and schedules
No scheduled module jobs were found.
Routes sampled
| Route | Target |
|---|---|
ticketing | EventPass/index |
ticketing/passes | EventPass/index |
ticketing/passes/(:any) | EventPass/$1 |
ticketing/passes/(:any)/(:any) | EventPass/$1/$2 |
ticketing/areas | Epass_Area/index |
ticketing/areas/(:any) | Epass_Area/$1 |
ticketing/areas/(:any)/(:any) | Epass_Area/$1/$2 |
ticketing/blocks | Epass_Block/index |
ticketing/blocks/(:any) | Epass_Block/$1 |
ticketing/blocks/(:any)/(:any) | Epass_Block/$1/$2 |
ticketing/seats | Epass_Seat/index |
ticketing/seats/(:any) | Epass_Seat/$1 |
ticketing/seats/(:any)/(:any) | Epass_Seat/$1/$2 |
mcs/epass | EventPass/index |
mcs/epass/(:any) | EventPass/$1 |
mcs/epass/(:any)/(:any) | EventPass/$1/$2 |
mcs/epass_area | Epass_Area/index |
mcs/epass_area/(:any) | Epass_Area/$1 |
mcs/epass_area/(:any)/(:any) | Epass_Area/$1/$2 |
mcs/epass_block | Epass_Block/index |
| 5 additional route(s) omitted for readability. | |
README topics
- Overview
- Purpose
- Who This Module Is For
- Problems This Module Solves
- Key Features
- How It Works in ERPat
- Common Use Cases
- User Roles and Access
- Permissions
- Related Modules
- Important Notes
- Data Handled by This Module
Operating Implications
- Permission coverage is part of the module contract, so every workflow should be tested with a role-limited user and an administrator.
- The module has migrations, so fresh installs and tenant databases need migration validation before go-live.
- Seeders exist for sample or starter data; operators should know whether seeded records are demo-only or operational defaults.
Known Risks from the Manifest
- Umbrella toggle: module_ticketing is the master flag; the legacy module_epass flag is honored as a READ ALIAS for one release (ticketing_module_enabled() in helpers/ticketing_helper.php) until the CORE seed migration (20260705111528_seed_module_ticketing_setting) has run everywhere. The seed copies module_epass onto module_ticketing and then ZEROES module_epass, so post-seed the Manage-Modules toggle is the single authority. Remove the alias (helper OR-branch + the 'module_epass' setting_any entry in config/menu.php) together.
- Roles-editor gap during the pre-seed window: Roles::_append_bootstrapped_permissions() gates strictly on module_ticketing (no setting_any support in the injector), so on a tenant DB where the seed has not run yet the feature is live via the alias but the event_epass rows are absent from the RBAC editor (grants are NOT lost on save - save_permissions merges into the existing blob). Same transient window exists for Marketing's module_emails alias; a generic __setting_any meta-key in the injector is the follow-up fix for both.
- Permission keys are FROZEN legacy keys (event_epass + event_epass_create/update/delete) - serialized into users.permissions/roles.permissions by name, so the relocation needed no grant migration. Do not rename them.
- The epass tables predate the module and were NEVER in the base install schema - the module migration creates them with CREATE TABLE IF NOT EXISTS and a documented no-op down() (dropping could destroy legacy production data). The legacy tables lack the created_by/created_at audit columns; preserved as-is.
- Shared boundaries kept in core: ImageEditor/ImageEditorV2 ticket renderers (application/libraries/ - also consumed by raffle and Forms), the event_pass/epass_confirm email templates + EmailTemplateVariablesTrait (system-wide registry), the event_epass_path/event_epass_ticket_path file paths (autoloaded core config.php), and Events_model (owned by modules/Events, loaded cross-module via package paths).
- Legacy data quirks preserved verbatim from the core copy: EventPass_model helpers default to event_id=103, add_override_epass() hardcodes event 103 / seat 8837, and sendEpassConfirm() links the external events.brilliantskinessentials.ph companion portal. Cleaning these up is roadmap work (see specs/), not part of the relocation.