Todo Reference Public

Module Research Notes

Evidence gathered from the current Todo 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 2 views
Reference

Module Research Notes

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

Slug: todoVersion: 1.0.0Category: ProductivityReviewed: 2026-07-11

Research Sources Inspected

Source path

modules/Todo

Feature flags marked true

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

Evidence Summary

Manifest

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

Runtime surface

1 controller file(s), 7 view file(s), and 2 route mapping(s) were found.

Data surface

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

Operations surface

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

Detailed File Evidence

Controllers and methods

  • Todo

Jobs and schedules

  • Generate recurring to-dos (50 2 * * *) - Creates new to-do entries from recurring templates whose next_recurring_date has arrived.
  • Remind to-do list owners (* * * * *) - Sends due-today and overdue notifications to owners of pending to-do items.

Routes sampled

RouteTarget
todoTodo/index
todo/(:any)Todo/$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
  • Demo Seeder

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

  • Multi-tenant migration behavior: module migrations run per-tenant database via the migrations_todo table and must be validated on every tenant before production cutover.
Was this guide helpful?

Report a content problem