Define admin metrics permissions structure

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 example client-care-dashboard and shared KPI components such as src/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.