Split Client Care dashboard access from admin settings permissions

Objective

• Let supervisors use Client Care dashboard and reporting without inheriting full settings / admin capabilities.
• Support permission templates editable at the admin level and a settings array carried on user vs staff member as product defines.

Background

• Today, granting dashboard access can over-expose dangerous admin surfaces; operations need a clean split between analytics views and configuration.
• Mockups and notes in the preserved section below capture the intended direction.

Scope

Frontend

• Attik Admin client-care surfaces under attik-frontend/src/app/admin/client-care-dashboard/ (CCDashboardClient.tsx, ClientCareViewsClient.tsx, view pages) and admin landing redirects in src/app/admin/page.tsx.
• Navigation entry in src/util/data/adminNavButtons.tsx.

Backend / auth

• Staff and user permission documents in attik-backend (routes under src/routes/ and models) need a model that can express dashboard-only grants vs settings—Decision needed on schema (explicit flags vs template-derived roles).

References

• attik-frontend/src/app/admin/client-care-dashboard/CCDashboardClient.tsx
• attik-frontend/src/app/admin/client-care-dashboard/ClientCareViewsClient.tsx

---

Original description

Supervisors should be able to use dashboard and reporting views without getting full settings or admin access.

Transcript Context

The team described a gap in the current permission model: supervisors need access to core client care dashboard functionality to do their jobs, but giving them that access also exposes settings and more dangerous admin capabilities. The request was to create a clearer dividing line between front-end dashboard access and settings access so office staff can use reporting tools without full admin power.

Additional transcript detail:

The team discussed starting with a simpler permission shape such as view / edit / delete-style access instead of jumping straight to an overly broad CRUD matrix for every surface. They also talked through making permissions feature-specific, potentially using expandable sections so each feature can expose only the controls that make sense for that area.

Permission templates were also called out as important so common setups can be reused instead of rebuilding access rules for every brand or role.