Promos Reference Public

Module Research Notes

Evidence gathered from the current Promos module files — controllers, models, configs, and migrations — before writing these user guide pages.

Guide version: r1 Module version: 0.2.0 Updated: 2026-07-22 Estimated time: 4 min 2 views
Reference

Module Research Notes

Evidence gathered from the current module files before writing the user guide pages.

Slug: promosVersion: 0.1.1Category: PromosReviewed: 2026-07-11

Research Sources Inspected

Source path

modules/Promos

Feature flags marked true

  • Controllers
  • Models
  • Views
  • Language
  • Permissions
  • Left Menu
  • Default Menu
  • Routes
  • Helpers

Evidence Summary

Manifest

module.json defines slug promos, version 0.1.1, category Promos, and the module capability flags used in this guide.

Runtime surface

1 controller file(s), 8 view file(s), and 9 route mapping(s) were found.

Data surface

1 model file(s), 4 declared table(s), and 0 migration file(s) were found.

Operations surface

17 permission key(s), 0 job(s), 1 seeder(s), and 1 test file(s) were found.

Detailed File Evidence

Controllers and methods

  • Raffle_draw

Jobs and schedules

No scheduled module jobs were found.

Routes sampled

RouteTarget
promosRaffle_draw/index
promos/rafflesRaffle_draw/index
promos/raffles/(:any)Raffle_draw/$1
promos/raffles/(:any)/(:any)Raffle_draw/$1/$2
promos/raffles/(:any)/(:any)/(:any)Raffle_draw/$1/$2/$3
raffle_drawRaffle_draw/index
raffle_draw/(:any)Raffle_draw/$1
raffle_draw/(:any)/(:any)Raffle_draw/$1/$2
raffle_draw/(:any)/(:any)/(:any)Raffle_draw/$1/$2/$3

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.
  • 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_promos is the master flag; the legacy module_raffle flag is honored as a one-release READ ALIAS (promos_module_enabled() in helpers/promos_helper.php) until the CORE seed migration (20260705221438_seed_module_promos_setting) has run everywhere. The seed copies module_raffle onto module_promos and then ZEROES module_raffle, so post-seed the Manage-Modules toggle is the single authority. Remove the alias (helper OR-branch + the 'module_raffle' setting_any entry in config/menu.php) together.
  • Roles-editor gap during the pre-seed window: Roles::_append_bootstrapped_permissions() gates strictly on module_promos (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 raffle_draw 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 Ticketing's module_epass and Marketing's module_emails aliases; a generic __setting_any meta-key in the injector is the follow-up fix for all three.
  • Permission keys are FROZEN legacy keys (raffle_draw + auto-CRUD children; raffle_draw_participants*/winners* action keys; raffle_draw_prizes + auto-CRUD children) - serialized into users.permissions/roles.permissions by name, so the relocation needed no grant migration. Do not rename them.
  • The four raffle tables (event_raffle, event_raffle_participants, event_raffle_winners, event_raffle_prizes) predate the module and are NOT yet covered by a backfill migration: they were never in the base install schema, and no live legacy DDL was reachable at relocation time (SHOW CREATE TABLE needs a production-shaped DB). Authoring that CREATE TABLE IF NOT EXISTS backfill - like modules/Ticketing's 20260705111029 does for the epass tables - is the first roadmap follow-up (see specs/).
  • Shared boundaries kept in core: ImageEditor/ImageEditorV2 ticket renderers (application/libraries/ - also consumed by Ticketing and Forms), the raffle_entry/raffle_subscription/raffle_join email template seeds + EmailTemplateVariablesTrait (system-wide registry), the raffle_entry_path/raffle_prize_path file paths (autoloaded core config.php), Check_fix's template seeding (loads Raffle_draw_model cross-module via package paths), and Events_model (owned by modules/Events, loaded cross-module via package paths).
  • Legacy data quirks preserved verbatim from the core copy: raffle QR entries link the external Syntry scan2win portal (syntry_site_link setting). Cleaning this up is roadmap work (see specs/), not part of the relocation.
Was this guide helpful?

Report a content problem