Objective
- Establish a permissions model for admin-facing metrics in Attik Admin so new dashboard numbers can ship without over-exposing data.
- Clarify who can see which metric categories before UI work lands.
Background
- Stakeholders want specific admin metrics soon; the blocker is not charting alone but access control at the Attik Admin layer.
- The requirement is to decide whether to extend current admin permission patterns or introduce more granular controls, and to leave room for follow-on dashboard implementation.
Scope
Frontend (Attik Admin)
- Future metrics UI will likely live alongside existing admin dashboard patterns under
attik-frontend/src/app/admin/(for exampleclient-care-dashboardand shared KPI components such assrc/app/admin/client-care-dashboard/_components/KPIStatsGrid.tsx).
Backend
- Metric APIs and aggregations will need authorization checks consistent with whatever model is defined (search
attik-backend/src/routes/for admin or internal report endpoints—Decision needed on exact routes and role keys).
References
attik-frontend/src/app/admin/client-care-dashboard/attik-frontend/src/app/admin/client-care-dashboard/_components/KPIStatsGrid.tsx
Original description
A permissions structure is needed for admin-facing metrics in Attik Admin before simple dashboard metrics can be added safely.
Monday kickoff context:
- Stakeholders are asking for specific metrics in admin.
- The team wants to add simple internal dashboard metrics soon.
- The blocker is defining permissions for Attik Admin so access can be structured correctly before metrics are exposed.
Scope:
- Define the permissions model for admin-facing metrics and related admin surfaces.
- Clarify which roles can view which categories of metrics.
- Decide whether this should extend existing admin permissions or introduce more granular controls.
- Leave room for follow-on dashboard work once the permissions foundation is in place.
Additional transcript detail:
The team explicitly discussed avoiding a one-size-fits-all CRUD table if it becomes too hard to implement and maintain. A likely direction is a feature-by-feature permissions model where each area can expose the specific controls that matter there, with a simpler starting set such as view / edit / delete-style access where appropriate.
Permission templates should be part of the design so repeated admin access patterns can be applied consistently.
