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-30 Estimated time: 2 min 1 views
You are viewing version r1 of this guide. View the current version
Module Research Notes

Todo

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.

Report a content problem