From 259f6fb3164b4fb1b9972abe568367748a158324 Mon Sep 17 00:00:00 2001 From: Till JS Date: Fri, 24 Apr 2026 14:46:48 +0200 Subject: [PATCH] fix(shared-privacy): default all new records to 'space', not 'private' MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Regression reported in testing: tasks and calendar events created via the Workbench homepage widgets appeared there but vanished from their respective module sub-routes (/todo, /calendar). Root cause: my M4.b + M4.a shipped `defaultVisibilityFor('personal') → 'private'` based on the original plan ("personal space default is private"). That collides with the pre-existing 2-tier visibility filter in `apps/mana/apps/web/src/lib/data/scope/visibility.ts`, which treats 'private' records as "only the authorId sees them, even inside the same space". Its applyVisibility() drops any 'private' record whose authorId doesn't exactly match getCurrentUserId() — and the homepage- widget cross-app queries in cross-app-queries.ts don't run that filter while /todo/useAllTasks() does, creating the asymmetry the user saw. Why the match can fail in practice: during auth bootstrap, getEffectiveUserId() returns the 'guest' sentinel (which the Dexie creating-hook stamps onto authorId), while getCurrentUserId() can already resolve to the real user id by the time /todo's query runs. authorId='guest' !== currentUserId= → record filtered out. Fix: defaultVisibilityFor() now returns 'space' regardless of space type. Rationale: - In a personal space there's exactly one member, so 'space' and 'private' are effectively equivalent — both mean "only the owner sees it". - In a multi-member space, 'space' is the desired default (otherwise every collaborative record would need a manual toggle). - 'private' becomes an *active* user decision for drafts in shared spaces — click the VisibilityPicker to enable it. - The parameter is retained (as `_spaceType`) for forward-compat so future space types can differentiate without touching call sites. Impact on shipped modules: all 8 consumers (Library, Picture, Calendar, Todo, Goals, Places, Recipes, Wardrobe) call defaultVisibilityFor(activeSpace.type) at create time — they inherit the fix automatically. No store edits required. Existing records with visibility='private' from the testing window stay as they are; user can flip them to 'Bereich' via the VisibilityPicker, or reset the local Dexie to pick up the new default. Plan doc updated with the full rationale (docs/plans/ visibility-system.md §Entscheidung). Verified: - pnpm test @mana/shared-privacy: 15/15 (defaults.test.ts updated) - pnpm check (web): 7464 files, 0 errors Co-Authored-By: Claude Opus 4.7 (1M context) --- docs/plans/visibility-system.md | 18 ++++++---- packages/shared-privacy/src/defaults.test.ts | 17 +++++---- packages/shared-privacy/src/defaults.ts | 36 +++++++++++++------- 3 files changed, 45 insertions(+), 26 deletions(-) diff --git a/docs/plans/visibility-system.md b/docs/plans/visibility-system.md index 040d9c95b..84f4914b5 100644 --- a/docs/plans/visibility-system.md +++ b/docs/plans/visibility-system.md @@ -47,10 +47,13 @@ export type VisibilityLevel = 'private' | 'space' | 'unlisted' | 'public'; | `unlisted` | Wer den Direct-Link + Token hat; nicht gelistet, nicht indexiert | Event-Einladungen mit Nicht-Member-Gästen | | `public` | Beliebig — sichtbar auf Website-Embeds, für AI-Agent referenzierbar | Ein aktiv als "für die Öffentlichkeit" markiertes Item | -**Default bei Record-Create:** leitet sich vom Space-Typ ab. -- Personal-Space → `private` -- Team/Club-Space → `space` (sonst müssten User bei jedem Task manuell "meine Space-Mitglieder dürfen das sehen" setzen — unrealistisch) -- Nie `public` oder `unlisted` als Default. +**Default bei Record-Create:** **immer `space`**, unabhängig vom Space-Typ. + +Ursprünglich war Personal-Space → `private` geplant. Nach der ersten Integration (M4.b Todo) stellte sich heraus: das existierende 2-Stufen-System in `scope/visibility.ts` behandelt `'private'` als "nur der Author sieht es, auch innerhalb des gleichen Space" — und filtert solche Records im `applyVisibility()`-Aufruf der Modul-Queries. Das fightet mit dem "Personal-Space default = private"-Plan: neu angelegte Tasks/Events erschienen im Homepage-Widget (das keinen Filter nutzt), verschwanden aber auf `/todo` (Filter schlägt zu). Der `authorId`-Check in `applyVisibility` versagt während des Auth-Bootstraps, wenn der Hook `'guest'` als authorId stempelt aber `getCurrentUserId()` bereits den echten User zurückgibt. + +Der robuste Fix: `defaultVisibilityFor()` returnt immer `'space'`. Im Personal-Space (1 Member) ist das semantisch äquivalent zu `'private'`. In Multi-Member-Spaces ist `'space'` der erwünschte Default (sonst müssten User jeden Task manuell für ihre Mitglieder freischalten). `'private'` wird zur **aktiven User-Entscheidung** für Drafts in geteilten Spaces — Klick im VisibilityPicker. + +- Nie `public` oder `unlisted` als Default (deny-by-default-Regel bleibt). **Begründung der Namen:** `visibility` + 4-Stufen-Enum ist das vertraute Google-Drive/YouTube-Mental-Model. Alternativ diskutiert: `sharingLevel`, `audience`. Verworfen — `visibility` ist breiter bekannt und technischer neutral (keine "Zuhörerschaft"-Assoziation). @@ -68,8 +71,11 @@ export type VisibilityLevel = 'private' | 'space' | 'unlisted' | 'public'; export const VisibilityLevelSchema = z.enum(['private', 'space', 'unlisted', 'public']); // defaults.ts -export function defaultVisibilityFor(spaceType: SpaceType): VisibilityLevel { - return spaceType === 'personal' ? 'private' : 'space'; +export function defaultVisibilityFor(_spaceType: SpaceType | null | undefined): VisibilityLevel { + // Always 'space' — compatible with the existing 2-tier applyVisibility + // filter, and semantically equivalent to 'private' in personal spaces + // (only one member). Users flip to 'private' explicitly for drafts. + return 'space'; } // predicates.ts diff --git a/packages/shared-privacy/src/defaults.test.ts b/packages/shared-privacy/src/defaults.test.ts index 43e6e5864..4f20cc63b 100644 --- a/packages/shared-privacy/src/defaults.test.ts +++ b/packages/shared-privacy/src/defaults.test.ts @@ -2,8 +2,11 @@ import { describe, it, expect } from 'vitest'; import { defaultVisibilityFor } from './defaults'; describe('defaultVisibilityFor', () => { - it('returns private for personal space', () => { - expect(defaultVisibilityFor('personal')).toBe('private'); + // 'space' everywhere so the default stays compatible with the + // existing 2-tier `applyVisibility` filter in scope/visibility.ts. + // See the function's doc comment for the full rationale. + it('returns space for personal space', () => { + expect(defaultVisibilityFor('personal')).toBe('space'); }); it('returns space for multi-member types', () => { @@ -12,13 +15,13 @@ describe('defaultVisibilityFor', () => { expect(defaultVisibilityFor('firma')).toBe('space'); }); - it('returns space for unknown multi-member types (safe assumption)', () => { + it('returns space for unknown types', () => { expect(defaultVisibilityFor('band')).toBe('space'); }); - it('falls back to private when space type is missing', () => { - expect(defaultVisibilityFor(null)).toBe('private'); - expect(defaultVisibilityFor(undefined)).toBe('private'); - expect(defaultVisibilityFor('')).toBe('private'); + it('returns space when space type is missing', () => { + expect(defaultVisibilityFor(null)).toBe('space'); + expect(defaultVisibilityFor(undefined)).toBe('space'); + expect(defaultVisibilityFor('')).toBe('space'); }); }); diff --git a/packages/shared-privacy/src/defaults.ts b/packages/shared-privacy/src/defaults.ts index 690547810..66d2a26df 100644 --- a/packages/shared-privacy/src/defaults.ts +++ b/packages/shared-privacy/src/defaults.ts @@ -1,20 +1,30 @@ import type { VisibilityLevel } from './types'; /** - * Default visibility for newly-created records, derived from the space - * type. Personal spaces stay `private` so a fresh note or task doesn't - * accidentally leak to cohabitants of a team space; multi-member spaces - * (team, club, firma, …) default to `space` so collaboration works - * without requiring a manual toggle on every write. + * Default visibility for newly-created records — always 'space'. * - * Accepts `null`/`undefined`/unknown strings and treats them as personal - * — the safer direction. Callers that know the space type pass it - * directly; callers that don't (e.g. during sync-apply) fall back to - * 'private'. + * Why not 'private' for personal spaces even though the original plan + * read "personal → private": it would fight the existing 2-tier + * visibility filter in `apps/mana/apps/web/src/lib/data/scope/ + * visibility.ts`, which treats `'private'` records as "only the author + * sees them, even inside the same space". That's the semantic the + * broader codebase already depends on — queries like `useAllTasks()` + * apply it at read time. Stamping `'private'` as the default here + * causes records to disappear from module sub-routes during auth + * bootstrap (authorId stamped with the guest-sentinel, later filtered + * out once the real user id resolves). + * + * In a personal space there's only one member, so 'space' and 'private' + * are equivalent in effect — both mean "only you see it". In + * multi-member spaces, 'space' means "fellow members can see it" + * which is the desired default for collaboration. Users who want a + * genuine "draft, hide from fellow members" state flip explicitly + * to `'private'` via the VisibilityPicker. + * + * The parameter is retained for forward-compatibility — a future + * space type (e.g. 'restricted' invite-only) might want a different + * default without changing every call site. */ -export function defaultVisibilityFor(spaceType: string | null | undefined): VisibilityLevel { - if (!spaceType) return 'private'; - if (spaceType === 'personal') return 'private'; - // team, club, firma, or any future multi-member type. +export function defaultVisibilityFor(_spaceType: string | null | undefined): VisibilityLevel { return 'space'; }