Community Reference Public

Module Research Notes

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

Guide version: r1 Module version: 1.1.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: communityVersion: 1.1.0Category: CommunityReviewed: 2026-07-11

Research Sources Inspected

Source path

modules/Community

Feature flags marked true

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

Evidence Summary

Manifest

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

Runtime surface

4 controller file(s), 33 view file(s), and 10 route mapping(s) were found.

Data surface

11 model file(s), 10 declared table(s), and 2 migration file(s) were found.

Operations surface

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

Detailed File Evidence

Controllers and methods

  • Community
  • Community_admin
  • Community_api - categories, groups, topics, topic
  • Community_euapi - categories, groups, topics, topic

Jobs and schedules

No scheduled module jobs were found.

Routes sampled

RouteTarget
community_adminCommunity_admin/index
community_admin/(:any)/(:any)Community_admin/$1/$2
community_admin/(:any)Community_admin/$1
community/category/(:any)Community/category/$1
community/topic/(:any)Community/topic/$1
community/group/(:any)Community/group/$1
community/s/(:any)Community/share/$1
communityCommunity/index
community/(:any)/(:any)Community/$1/$2
community/(:any)Community/$1

README topics

  • What it does
  • Public-page SEO
  • Architecture
  • Install
  • Demo Seeder
  • Configuration (.env, all optional - see `.env.example`)
  • Tables (MAIN db only)

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.
  • The module has API documentation or routes, so response examples and query filters should stay aligned with user-facing screens.
  • 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