Village Reference Public

Module Research Notes

Evidence gathered from the current Village 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: 3 min 1 views
Reference

Module Research Notes

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

Slug: villageVersion: 0.2.0Category: CommunityReviewed: 2026-07-11

Research Sources Inspected

Source path

modules/Village

Feature flags marked true

  • Controllers
  • Models
  • Views
  • Language
  • Permissions
  • Left Menu
  • Default Menu
  • Routes
  • Migrations
  • Dashboard Widgets
  • Helpers

Evidence Summary

Manifest

module.json defines slug village, version 0.2.0, category Community, and the module capability flags used in this guide.

Runtime surface

22 controller file(s), 46 view file(s), and 46 route mapping(s) were found.

Data surface

26 model file(s), 26 declared table(s), and 8 migration file(s) were found.

Operations surface

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

Detailed File Evidence

Controllers and methods

  • Village
  • Village_amenities
  • Village_announcements
  • Village_credentials
  • Village_documents
  • Village_dues
  • Village_emergency_contacts
  • Village_governance
  • Village_homes
  • Village_households
  • Village_improvements
  • Village_incidents
  • Village_memberships
  • Village_pets
  • Village_portal
  • Village_reports
  • Village_residents
  • Village_security
  • Village_settings
  • Village_vehicles
  • Village_violations
  • Village_zones

Jobs and schedules

No scheduled module jobs were found.

Routes sampled

RouteTarget
villageVillage/index
village/(:any)Village/$1
village_homes/(:any)/(:any)Village_homes/$1/$2
village_homes/(:any)Village_homes/$1
village_homesVillage_homes/index
village_zones/(:any)/(:any)Village_zones/$1/$2
village_zones/(:any)Village_zones/$1
village_residents/(:any)/(:any)Village_residents/$1/$2
village_residents/(:any)Village_residents/$1
village_residentsVillage_residents/index
village_households/(:any)Village_households/$1
village_memberships/(:any)Village_memberships/$1
village_vehicles/(:any)Village_vehicles/$1
village_pets/(:any)Village_pets/$1
village_credentials/(:any)Village_credentials/$1
village_emergency_contacts/(:any)Village_emergency_contacts/$1
village_security/(:any)Village_security/$1
village_securityVillage_security/index
village_incidents/(:any)Village_incidents/$1
village_incidentsVillage_incidents/index
26 additional route(s) omitted for readability.

README topics

  • Overview
  • Purpose
  • Who This Module Is For
  • Key Features
  • How It Works in ERPat
  • Permissions
  • Related Modules
  • Important Notes
  • Setup and Configuration
  • Demo Seeder
  • Support
  • Version Information

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.
  • The module has a public or portal-facing surface, so privacy review and logged-out testing are required.
  • 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

  • Dues & Finance integration maps a village_home to a core clients row (village_homes.client_id) and READS balances via the core Invoices_model + Finance aging; raising an assessment/fine as an invoice (write-back) is gated on the Sales AND Finance modules being installed & enabled (invoice creation lives in Sales; Invoice_payments.php hard-requires module_sales). When Sales is off, the Dues screen degrades to read-only status with a notice rather than failing.
  • Incidents reuse the Helpdesk Tickets module (Tickets_model->save() + save_custom_fields('tickets',...)) - a village_home/resident context is stored as ticket custom fields + client_id + labels because the tickets table has no native context column. Village incidents therefore require the Helpdesk module installed & enabled.
  • Multi-tenant migration behavior: module-owned tables run per-tenant via migrations_village and must be validated on every tenant DB before production cutover.
  • Foundation pass: Improvements/ARC, Violations, Amenities, Governance, Documents and Reports are registered in nav + permissions but render an honest 'Planned' panel; their workflows/tables ship in follow-up phases B-J.
Was this guide helpful?

Report a content problem