[VS-NfD] Inherit classification in the page tree; require a dedicated right to downgrade #205

New Issue

fable-5 · 2026-07-30T01:43:39+02:00

fable-5 commented

2026-07-30 01:43:39 +02:00

Plan reference: 20-massnahmenplan.md -> P1-2
ADR: ADR 0022
Effort: M (3 AT)
Depends on: #204

Context

A subpage of a classified page must not silently be unclassified — that is
how classified content escapes marking in practice. Downgrading is the
sensitive direction and needs its own right plus an audit record.

Current state

Pages nest via parentId with a max depth of 6 enforced in the service,
cycles rejected at write time (apps/api/prisma/schema.prisma:255–266);
trashed pages keep parentId and purge promotes children explicitly.
Permission decisions run centrally through apps/api/src/permissions/
(deny-wins, default-closed) — the place to add a capability rather than
an ad-hoc check.

Acceptance criteria

A new page inherits the effective classification of its parent; a
page moved under a higher-classified parent is raised.
Raising is allowed to any writer; lowering requires a dedicated
capability expressed in the central permission model, never an ad-hoc
check.
Every raise and lower is audited with old value, new value, actor and
page.
Move operations cannot lower a page's classification as a side effect
(proven by test), including the purge-promotes-children path.
Tests cover: inherit on create, raise on move, lower denied without
the capability, lower audited with the capability.
docs/architecture/permissions.md documents the capability.

Out of scope

Output marking, and a UI for bulk re-classification.

**Plan reference:** `20-massnahmenplan.md` -> P1-2 **ADR:** ADR 0022 **Effort:** M (3 AT) **Depends on:** #204 ## Context A subpage of a classified page must not silently be unclassified — that is how classified content escapes marking in practice. Downgrading is the sensitive direction and needs its own right plus an audit record. ## Current state - Pages nest via `parentId` with a max depth of 6 enforced in the service, cycles rejected at write time (`apps/api/prisma/schema.prisma:255–266`); trashed pages keep `parentId` and purge promotes children explicitly. - Permission decisions run centrally through `apps/api/src/permissions/` (deny-wins, default-closed) — the place to add a capability rather than an ad-hoc check. ## Acceptance criteria - [ ] A new page inherits the effective classification of its parent; a page moved under a higher-classified parent is raised. - [ ] Raising is allowed to any writer; **lowering** requires a dedicated capability expressed in the central permission model, never an ad-hoc check. - [ ] Every raise and lower is audited with old value, new value, actor and page. - [ ] Move operations cannot lower a page's classification as a side effect (proven by test), including the purge-promotes-children path. - [ ] Tests cover: inherit on create, raise on move, lower denied without the capability, lower audited with the capability. - [ ] `docs/architecture/permissions.md` documents the capability. ## Out of scope Output marking, and a UI for bulk re-classification.

fable-5 added this to the M26 — VS-NfD: classification metadata milestone 2026-07-30 01:43:39 +02:00

fable-5 added the

labels 2026-07-30 01:43:39 +02:00

fable-5 referenced this issue

2026-07-30 01:43:52 +02:00

[VS-NfD] Instrument read paths for classified content #222

fable-5 referenced this issue from a commit

2026-07-31 06:12:29 +02:00

#205: classification inherits down the tree; lowering is a guarded, audited act

fable-5 referenced this issue

2026-07-31 06:12:38 +02:00

#205: classification inheritance + guarded, audited lowering #264

fable-5 commented

2026-07-31 06:50:15 +02:00

Done in PR #264 (commit 488d0d0, CI run 539 green, fast-forward merged on Stefan's standing merge instruction).

Evidence:

Inherit on create: new page takes max(instance default, parent level) - test classification-inheritance.e2e.db.test.ts.
Raise on move: repositioning under a higher-classified parent raises the WHOLE moved subtree; each raised page audited (page.classification_raised, trigger move, from/to/actor/page).
Lowering: dedicated capability canLowerClassification (pond-wide Pond Admin) in the central shared permission model - editor with write gets 403 classification_lower_forbidden; Pond Admin lowers with audit page.classification_lowered (warning severity).
No move-like path lowers as a side effect: reposition under lower parent, trash-promote and purge-promote all pinned by test.
Audit catalogue bumped to v1.1 (docs/architecture/audit-events.md); permissions.md documents the capability.

Done in PR #264 (commit 488d0d0, CI run 539 green, fast-forward merged on Stefan's standing merge instruction). Evidence: - Inherit on create: new page takes max(instance default, parent level) - test classification-inheritance.e2e.db.test.ts. - Raise on move: repositioning under a higher-classified parent raises the WHOLE moved subtree; each raised page audited (page.classification_raised, trigger move, from/to/actor/page). - Lowering: dedicated capability canLowerClassification (pond-wide Pond Admin) in the central shared permission model - editor with write gets 403 classification_lower_forbidden; Pond Admin lowers with audit page.classification_lowered (warning severity). - No move-like path lowers as a side effect: reposition under lower parent, trash-promote and purge-promote all pinned by test. - Audit catalogue bumped to v1.1 (docs/architecture/audit-events.md); permissions.md documents the capability.

fable-5 closed this issue

2026-07-31 06:50:16 +02:00

Sign in to join this conversation.