Barangay Governance Reference Public

Module Research Notes

Evidence gathered from the current Barangay Governance 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: 3 min 2 views
Reference

Module Research Notes

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

Slug: barangayVersion: 1.0.0Category: GovernanceReviewed: 2026-07-11

Research Sources Inspected

Source path

modules/Barangay

Feature flags marked true

  • Controllers
  • Models
  • Views
  • Language
  • Permissions
  • Left Menu
  • Default Menu
  • Routes
  • Migrations
  • Cron Jobs
  • Helpers
  • Libraries
  • Seeders
  • Public Pages
  • Dashboard Widgets
  • User Guides
  • Tests

Evidence Summary

Manifest

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

Runtime surface

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

Data surface

40 model file(s), 37 declared table(s), and 9 migration file(s) were found.

Operations surface

38 permission key(s), 4 job(s), 4 seeder(s), and 6 test file(s) were found.

Detailed File Evidence

Controllers and methods

  • Barangay
  • Barangay_blotter
  • Barangay_charter
  • Barangay_documents
  • Barangay_drrm
  • Barangay_finance
  • Barangay_health
  • Barangay_households
  • Barangay_ids
  • Barangay_kiosk
  • Barangay_kp
  • Barangay_officials
  • Barangay_portal
  • Barangay_public
  • Barangay_puroks
  • Barangay_records
  • Barangay_reports
  • Barangay_residents
  • Barangay_settings
  • Barangay_treasury
  • Barangay_vaw
  • Barangay_verify

Jobs and schedules

  • Barangay BPO expiry sweep (0 6 * * *) - Auto-expires Barangay Protection Orders past their 15-day window and notifies issuing officers of BPOs expiring within 3 days (bpo_no + expiry date only - no identities).
  • Barangay document SLA sweep (15 * * * *) - Flags barangay document requests whose ARTA working-day deadline has lapsed (sla_breached).
  • Barangay FDP compliance sweep (30 6 * * *) - Creates missing FDP posting rows for elapsed periods, flags unposted ones overdue, and notifies the responsible staff.
  • Barangay KP deadline sweep (45 5 * * *) - Auto-finalizes settlements past the 10-day repudiation window and notifies case creators of KP deadlines within 3 days.

Routes sampled

RouteTarget
barangayBarangay/index
barangay/residentsBarangay_residents/index
barangay/residents/(.+)Barangay_residents/$1
barangay/householdsBarangay_households/index
barangay/households/(.+)Barangay_households/$1
barangay/puroksBarangay_puroks/index
barangay/puroks/(.+)Barangay_puroks/$1
barangay/officialsBarangay_officials/index
barangay/officials/(.+)Barangay_officials/$1
barangay/settingsBarangay_settings/index
barangay/settings/(.+)Barangay_settings/$1
barangay/documentsBarangay_documents/index
barangay/documents/(.+)Barangay_documents/$1
barangay/treasuryBarangay_treasury/index
barangay/treasury/(.+)Barangay_treasury/$1
barangay/kpBarangay_kp/index
barangay/kp/(.+)Barangay_kp/$1
barangay/blotterBarangay_blotter/index
barangay/blotter/(.+)Barangay_blotter/$1
barangay/vawBarangay_vaw/index
27 additional route(s) omitted for readability.

README topics

  • Layout
  • Make it visible
  • Citizen Surface (Phase 3)
  • Katarungang Pambarangay + Peace & Order (Phase 4)
  • KP - the statutory deadline engine (RA 7160 Secs 399-422)
  • Blotter / Peace & Order
  • Confidential VAW Desk / BPO (Phase 5)
  • Security model
  • Barangay Protection Order (RA 9262 Secs 5/14/15)
  • Reports
  • Cron
  • DRRM + Health & Social Services (Phase 6)

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.
  • 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