mirror of
https://github.com/MBombeck/HealthLog.git
synced 2026-11-10 05:12:14 +00:00
Marc-André Bombeck
5199de78af
Settings gains one section for one concept: who else can open this health record, whose this account may open, and when they were opened. Split across two pages it would be two half-answers. An invitation confers nothing until the other person accepts it, and the card says so above the field rather than after the submit — that is the part somebody needs to know before they type a name. Refusals are named from the stable errorCode, because "no account with that name" and "that person already has access" are different situations with different next steps. Ended grants stay in the list. The row is the consent record, and "who had access, from when to when, and who ended it" is the question the panel exists to answer; a list that dropped them could not. Revoking asks once and then does it: reducing access must never be harder than granting it was. `GET /api/account/activity` answers the owner's other question. One row per person per day with a count, not one per request — a hundred identical lines is a way of answering nothing. The window is published with the rows rather than assumed: audit history is purged on a schedule the operator sets, so the view prints the number the server resolved from the same setting the purge job reads. An instance running ninety days says ninety. Six locales ship with it.
44 lines
1.8 KiB
TypeScript
44 lines
1.8 KiB
TypeScript
"use client";
|
|
|
|
import { GrantInviteCard } from "@/components/settings/access/grant-invite-card";
|
|
import { GrantsGivenCard } from "@/components/settings/access/grants-given-card";
|
|
import { GrantsReceivedCard } from "@/components/settings/access/grants-received-card";
|
|
import { RecordActivityCard } from "@/components/settings/access/record-activity-card";
|
|
|
|
/**
|
|
* v1.36.0 — Settings → "Shared access".
|
|
*
|
|
* One section for one concept: who else can open this health record, and whose
|
|
* this account may open. Split across two pages it would be two half-answers —
|
|
* the settings IA rule this repository keeps rediscovering — so both directions
|
|
* and the activity that follows from them live in one column, in the order
|
|
* somebody reads them:
|
|
*
|
|
* 1. Invite — the act.
|
|
* 2. Who has access — the standing state, and the way to end it.
|
|
* 3. What I can open — the same, from the other side.
|
|
* 4. When it was opened — what actually happened.
|
|
*
|
|
* Distinct from Settings → "Health record" → sharing links, which mints a
|
|
* time-boxed read-only link to a REPORT for a clinician. This section is about
|
|
* another ACCOUNT on this instance being able to open the live record, which is
|
|
* a standing relationship rather than a document handed over once.
|
|
*
|
|
* Every card here reads and writes routes that refuse while the browser is
|
|
* acting on somebody else's record, and the section is unreachable in that
|
|
* state because the whole Settings entry drops out of the nav. Grant management
|
|
* is the one surface a delegate must have no reach into at all: a delegate who
|
|
* could invite, widen or transfer would be re-delegating access nobody granted
|
|
* them.
|
|
*/
|
|
export function AccessSection() {
|
|
return (
|
|
<div className="space-y-4">
|
|
<GrantInviteCard />
|
|
<GrantsGivenCard />
|
|
<GrantsReceivedCard />
|
|
<RecordActivityCard />
|
|
</div>
|
|
);
|
|
}
|