mirror of
https://github.com/MBombeck/HealthLog.git
synced 2026-11-08 12:32:43 +00:00
Marc-André Bombeck
33c879dd6b
An account grant is one account's standing permission to read another account's record. The row is also the consent record for the act that created it: there is no second receipt table, because two records of one act drift and then nobody can say which is true. That shapes the table. Revocation stamps revoked_at and revoked_by instead of deleting, so the record can still answer who had access, from when to when, and who ended it. The uniqueness constraint is therefore partial — one live grant per (owner, delegate), with history accumulating underneath — otherwise a re-invitation would either be refused or would overwrite the first grant's acceptance. Both foreign keys cascade: a grant naming a user who no longer exists is an authorization nobody can resolve and nobody can revoke. The state machine lives in src/lib/sharing/grants.ts and only there. The acting-account resolver and the grant surfaces both read these rows, and if each carried its own idea of "active" the drift would be silent in exactly one direction: the resolver admitting a grant the panel shows as ended. Pending confers nothing, expiry is checked against the clock of the request that reads the row, and every transition is a conditional update so two concurrent accepts cannot both win. The access column carries READ or WRITE and only READ is ever written. It exists from day one so that delegated writes become enforcement work rather than migration work. Three lifecycle paths, each proven against the real route: - Delete All Data removes grants from either side. The wipe loop asks every model for "this account's rows", and a table relating two accounts has no user_id to answer with, so wipe-plan.ts now declares the owner columns and translates. Wiping only the grantor side would leave the account still holding access to other people's records. - Account deletion removes them in both directions. - An admin restore leaves them exactly as it found them. Grants are classified NOT_IN_BACKUP: rolling data back is a decision an admin makes, but rolling an authorization back is a decision nobody makes, and a grant revoked on Tuesday must not come back alive out of Monday's file. After a restore, sharing is off and both people re-consent. The backup classification guard was reading a user relation by field name, so a model naming its account relations grantor and grantee read as instance-scoped and was excused from having a verdict at all. It now reads the type. That surfaced InviteToken, classified here too.
prisma/
The database layer. HealthLog runs PostgreSQL 16 via Prisma 7. This directory holds the single schema file and the forward-only migration history; the generated client is emitted elsewhere.
Contents
schema.prisma— 61 models, one file.cuid()primary keys,snake_casecolumns via@map(...), encrypted columns mostly suffixed*Encrypted(search the file; there are 24 encrypted column references). Thegenerator clientblock emits to../src/generated/prisma(imported as@/generated/prisma).migrations/— numbered, forward-only SQL migrations (0001_…upward).migration_lock.tomlpins the provider topostgresql.
Migration workflow
# author a migration from a schema edit
pnpm dlx prisma migrate dev --name <short_snake_case_name>
# regenerate the client after any schema change
pnpm dlx prisma generate
Number a new migration with the next free prefix. The production entrypoint runs prisma migrate deploy on boot, so every migration must apply cleanly forward — there is no down-migration path. Always include the migration file in the same change as the schema edit.
Conventions
- Encryption is fail-closed:
*Encryptedcolumns are written through@/lib/crypto(AES-256-GCM, versioned key ids); never store plaintext in an encrypted column. Key rotation isscripts/rotate-encryption-key.ts+docs/ops/encryption-key-rotation.md. - The generated client under
src/generated/prismais build output — do not edit it. - Schema-touching changes that affect the API surface must regenerate
docs/api/openapi.yaml(see../CLAUDE.md).
Related: ../src/lib/README.md (db.ts, rollups/), ../docs/ops/ (migrations + backup runbooks).