Permissions Phase 1: capability matrix + admin editor + page gates (behavior-neutral)

Open
  • Is something wrong?
#307 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
38/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Domain
authorization, database, full-stack, internationalization

Research direction

Start by reading types/permissions.ts, middleware/01.permission.global.ts, and the current computePermissions/pageAccessMap behavior before mapping the database model and admin page at /roles or /permissions. Done means seeded access is unchanged, editable role capabilities take effect after session refresh, ADMIN remains protected, unknown capabilities fail closed, and build, eslint, prettier, i18n parity, and endpoint-auth checks pass.

Written by the indexing model from the issue text.

Description

area: auth enhancement P1: high security

Part of #306 — Phase 1.

Goal

Introduce the capability model + DB-backed role matrix + admin editor, seeded to exactly match today's behavior (behavior-neutral until a toggle is flipped). Migrate page gates to capabilities.

Scope

  • Capability list — a fixed, code-defined set (page/action to start): e.g. manage_employees, manage_therapy_types, manage_schedule, manage_appointment_requests, assign_specialists, process_intake, create_referrals, write_therapy_notes, view_therapy_notes, manage_contact_forms, view_patients, view_schedule_all, … (finalize during build).
  • RoleCapability model (role: UserType, capability: string, @@id([role, capability])) + migration + seed from current defaults (derive grants from today's computePermissions + pageAccessMap so nothing changes).
  • computePermissions() reads the matrix for the user's role and returns the capability set (plus relationship-derived PATIENT/PARENT as today). Capabilities travel in the session via customSession.
  • Page gates: migrate types/permissions.ts pageAccessMap values from role → capability; middleware/01.permission.global.ts resolves the required capability from the session set.
  • Admin "Roles & Permissions" page (/roles or /permissions, ADMIN-gated, sidebar-linked): a roles × capabilities checkbox grid; save writes RoleCapability. i18n (en/es).
  • Guardrail: the ADMIN column is all-capabilities, locked/non-editable; API refuses any change that would leave ADMIN without full access or zero admins.

Out of scope (later phases)

Endpoint access migration + PHI/data capabilities + scope toggle (Phase 2); audit log + session invalidation + PHI warnings (Phase 3).

Acceptance criteria

  • With the seeded matrix, app behavior is identical to today (page access unchanged).
  • An admin can toggle a page capability for a role in the grid and it takes effect (after session refresh).
  • ADMIN cannot be de-privileged / locked out.
  • Fail-closed: a page with an unknown/missing capability denies.
  • build + eslint + prettier + i18n parity + endpoint-auth check pass.
Dominant language
Vue
Stars
0
Forks
1
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from UTDallasEPICS/connected-care

All issues in UTDallasEPICS/connected-care

Similar issues

More Security issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.