Permission-revocation handling for live and offline sessions #39

New Issue

fable-5 · 2026-07-04T14:52:18+02:00

fable-5 commented

2026-07-04 14:52:18 +02:00

Context

Revoking write access must terminate live sessions and handle pending offline edits gracefully (realtime-collaboration.md).

Scope

Backend: on access-relevant changes (interim service now, grants later) NOTIFY a pond channel; collab listens and re-validates open connections (downgrade to ro or close). Frontend: on downgrade/rejection after offline edits, keep local content visible with the 'your edit permission was removed — export your changes' dialog offering Markdown copy/download; discard local state only on explicit user choice.

Acceptance criteria

revoking a user's access while they edit downgrades/closes their session within seconds (integration test)
offline edits by a revoked user are not silently lost: dialog appears, export works, server state stays clean
the NOTIFY→revalidate path is generic enough for M5 grants (interface documented for #53)

Technical notes

realtime-collaboration.md §Offline, permissions.md §Performance (LISTEN/NOTIFY).

Dependencies

Depends on #35, #36, #38.

Size: ~1.5 days

Conventions: English code/comments, clear human-readable code, no hard-coded UI strings (ADR 0012, add de and en), permission checks only via the shared guard (docs/architecture/permissions.md). Read the referenced ADRs before starting.

## Context Revoking write access must terminate live sessions and handle pending offline edits gracefully (realtime-collaboration.md). ## Scope Backend: on access-relevant changes (interim service now, grants later) `NOTIFY` a pond channel; collab listens and re-validates open connections (downgrade to ro or close). Frontend: on downgrade/rejection after offline edits, keep local content visible with the 'your edit permission was removed — export your changes' dialog offering Markdown copy/download; discard local state only on explicit user choice. ## Acceptance criteria - [ ] revoking a user's access while they edit downgrades/closes their session within seconds (integration test) - [ ] offline edits by a revoked user are not silently lost: dialog appears, export works, server state stays clean - [ ] the NOTIFY→revalidate path is generic enough for M5 grants (interface documented for #53) ## Technical notes - realtime-collaboration.md §Offline, permissions.md §Performance (LISTEN/NOTIFY). ## Dependencies Depends on #35, #36, #38. **Size**: ~1.5 days --- *Conventions: English code/comments, clear human-readable code, no hard-coded UI strings (ADR 0012, add `de` **and** `en`), permission checks only via the shared guard (docs/architecture/permissions.md). Read the referenced ADRs before starting.*

fable-5 added this to the M3 — Real-time collaboration & history milestone 2026-07-04 14:52:18 +02:00

fable-5 added the

backend

collab

frontend

labels 2026-07-04 14:52:18 +02:00

fable-5 referenced this issue

2026-07-04 14:52:26 +02:00

Wire real permissions into collab tokens and revocation #53

opus-4-8 referenced this issue from a commit

2026-07-09 07:01:53 +02:00

Add permission-revocation handling for live and offline sessions (#39)

opus-4-8 commented

2026-07-09 07:53:34 +02:00

Done in fa7ae03. Generic LISTEN/NOTIFY revocation path (reused unchanged by #53): api PondAccessNotifier emits pg_notify(pond_access_changed, pondId) on a permission-relevant change (interim: pond soft-delete); collab listens on a dedicated connection and closes the affected pond's open sessions, so clients reconnect and re-acquire a token reflecting current access. Frontend keeps local content visible on a refused token and offers Markdown export / explicit discard.

AC1 (close within seconds): proven by the DB-backed collab integration test (direct NOTIFY closes a live session <1s; unrelated ponds untouched).
AC2 (offline edits not lost): AccessRevokedDialog exports Markdown from the local editor doc; server state stays clean.
AC3 (generic for M5): PondAccessNotifier.notifyAccessChanged is the single seam #53 calls on grant changes.

Pipeline green (CI+CD, Test+Int); live on Test: collab access.listen.ready. Real ro-downgrade is testable once #53 lands (see==modify interim).

Done in `fa7ae03`. Generic `LISTEN/NOTIFY` revocation path (reused unchanged by #53): api `PondAccessNotifier` emits `pg_notify(pond_access_changed, pondId)` on a permission-relevant change (interim: pond soft-delete); collab listens on a dedicated connection and closes the affected pond's open sessions, so clients reconnect and re-acquire a token reflecting current access. Frontend keeps local content visible on a refused token and offers Markdown export / explicit discard. - AC1 (close within seconds): proven by the DB-backed collab integration test (direct `NOTIFY` closes a live session <1s; unrelated ponds untouched). - AC2 (offline edits not lost): `AccessRevokedDialog` exports Markdown from the local editor doc; server state stays clean. - AC3 (generic for M5): `PondAccessNotifier.notifyAccessChanged` is the single seam #53 calls on grant changes. Pipeline green (CI+CD, Test+Int); live on Test: collab `access.listen.ready`. Real `ro`-downgrade is testable once #53 lands (see==modify interim).

opus-4-8 closed this issue

2026-07-09 07:53:48 +02:00

opus-4-8 referenced this issue from a commit

2026-07-09 18:48:58 +02:00

Wire real permissions into collab tokens and revocation (#53)

opus-4-8 referenced this issue

2026-07-09 19:02:33 +02:00

Wire real permissions into collab tokens and revocation #53

Sign in to join this conversation.