Events Reference Public

Module Research Notes

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

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

Module Research Notes

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

Slug: eventVersion: 1.0.0Category: GeneralReviewed: 2026-07-11

Research Sources Inspected

Source path

modules/Events

Feature flags marked true

  • Controllers
  • Models
  • Views
  • Permissions
  • Left Menu
  • Default Menu
  • Routes
  • Cron Jobs
  • Dashboard Widgets

Evidence Summary

Manifest

module.json defines slug event, version 1.0.0, category General, and the module capability flags used in this guide.

Runtime surface

2 controller file(s), 8 view file(s), and 4 route mapping(s) were found.

Data surface

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

Operations surface

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

Detailed File Evidence

Controllers and methods

  • Events
  • Google_api

Jobs and schedules

  • Sync Google Calendar events (* * * * *) - Pulls events from connected Google Calendars into the application.

Routes sampled

RouteTarget
eventsEvents/index
events/(:any)Events/$1
google_apiGoogle_api/index
google_api/(:any)Google_api/$1

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.
  • Scheduled jobs can change statuses, notifications, or summaries after users leave the screen; support should check cron status during troubleshooting.
  • Dashboard widgets summarize module state and should be verified against the source list before management reporting.
  • Seeders exist for sample or starter data; operators should know whether seeded records are demo-only or operational defaults.

Known Risks from the Manifest

No explicit known_risks list was found in the module manifest. Keep normal module controls in place and validate permissions, data, and public surfaces during QA.

Was this guide helpful?

Report a content problem