Admin Data Repository
Component Detail
Description
Data access layer for all admin portal queries, including aggregated statistics, user lists, activity logs, and org structure. All queries are executed through Supabase RLS-enforced views to ensure org-scoped data isolation. Provides typed result models consumed by admin services.
admin-repository
Summaries
The Admin Data Repository is the data access foundation that powers all administrative reporting, user management, and organisational oversight capabilities. By routing every admin query through Supabase row-level security views, it ensures that no admin can ever retrieve data outside their permitted organisational scope, protecting member privacy and supporting compliance. This centralised data layer means that business rule changes — such as new reporting columns or revised KPI definitions — can be updated in one place rather than scattered across the codebase, reducing the cost and risk of ongoing maintenance and regulatory adaptation.
High-complexity data layer that is a dependency for virtually every admin portal feature: dashboard statistics, user management, activity logs, export generation, and org hierarchy all flow through this component. It must be designed and partially implemented before parallel feature work can begin, making it an early-sprint priority. Schema changes or Supabase view modifications will have broad blast radius — ensure database migrations are versioned and reviewed carefully. Pagination and filter support must be agreed with the UI team upfront to avoid interface mismatches late in the project.
Plan integration tests against a seeded test database to validate RLS enforcement and query correctness before connecting to feature-level components.
Data access layer implemented against Supabase, with all queries routed through RLS-enforced views to guarantee org-scoped isolation without requiring application-layer filtering in every caller. Provides typed DTOs (`DashboardStatsDto`, `UserDto`, `ActivityDto`, `OrgNodeDto`, `ExportDataDto`) consumed by admin services. `fetchDashboardStats()` executes aggregate queries (counts, sums) filtered by an org ID list. Paginated list methods (`fetchUsers`, `fetchActivityLog`) accept filter structs and page tokens.
Mutation methods (`updateUserRole`, `updateUserStatus`) operate on individual records and should be wrapped in transactions where side effects exist. No upstream service dependencies — it is the bottom of the admin dependency graph. Consumed by admin-export-service, org-hierarchy-service, and admin-statistics-service. Supabase view definitions are the source of truth for query semantics; keep view SQL and DTO field names in sync.
Responsibilities
- Execute org-scoped aggregate queries for dashboard KPIs
- Fetch paginated user and activity lists with filter support
- Query org hierarchy nodes and relationships from Supabase
- Return typed domain models for all admin data operations
Interfaces
fetchDashboardStats(orgIds: List<String>) -> DashboardStatsDto
fetchUsers(orgIds, filters, page) -> PagedResult<UserDto>
fetchActivityLog(orgIds, filters, page) -> PagedResult<ActivityDto>
fetchOrgNodes(rootOrgId) -> List<OrgNodeDto>
updateUserRole(userId, role) -> void
updateUserStatus(userId, status) -> void
fetchExportData(orgIds, config) -> ExportDataDto
Relationships
Dependents (4)
Components that depend on this component
Related Data Entities (10)
Data entities managed by this component