ModuleRegistryService
Component Detail
Description
Infrastructure service that maintains the canonical list of feature modules available to each organisation and exposes an API for querying which modules are currently enabled. It is consulted at dashboard assembly time so that only capabilities relevant to the organisation's configuration are included in the response. Centralising module state here prevents scattered feature-flag checks across multiple services.
module-registry-service
Sources & reasoning
The source explicitly defines role-specific home content as a named screen type and specifies Peer Mentor and Coordinator as the two mobile roles. The module registry pattern described at lines 307-308 requires a home surface that assembles dynamically at runtime. Blueprint marks this feature MVP; Fase 1 core mobile scope confirms role-aware navigation must ship at launch.
-
docs/source/likeperson.md · line 291Role-specific home content (peer mentor vs coordinator variants)
-
docs/source/likeperson.md · line 287Bottom nav with 5 tabs: Home, Contacts, Add (modal launcher for Activity and Event wizards), Work, Notifications
-
docs/source/likeperson.md · line 256On mobile, an Org Admin is surfaced as a Coordinator - they use the same mobile experience as coordinators without a separate UI path.
Responsibilities
- Store and manage per-organisation module enable/disable state
- Expose a query API returning the enabled module set for a given organisation ID
- Invalidate and refresh cached module state when an administrator changes configuration
- Provide a typed registry of all known module keys to prevent string-literal drift
- Log module state changes for audit purposes
Interfaces
getEnabledModules(orgId: string): Promise<ModuleKey[]>
isModuleEnabled(orgId: string, moduleKey: ModuleKey): Promise<boolean>
setModuleEnabled(orgId: string, moduleKey: ModuleKey, enabled: boolean): Promise<void>
getAllModuleKeys(): ModuleKey[]
Related Data Entities (4)
Data entities managed by this component