Per organized-ideas.md §8. Backend tables/RLS (diagrams, diagram_collaborators, diagram_snapshots) already existed from an earlier phase — this is the frontend for them, plus two small backend additions. Backend (supabase/migrations/20260913000000_diagram_sharing.sql): - find_user_id_by_username(text): lets any authenticated user resolve a username to an id for "share with @username" — unlike general profile browsing (blocked by profiles_select_self_or_super_admin), a username is meant to be a shareable handle, so this is deliberately not gated. - diagram_collaborator_usernames / diagram_snapshot_saved_by_usernames: same pattern as the admin-review-queue phase's submitter-username lookup — batched per diagram, gated to "can you see this diagram at all" (reusing diagrams_select's own helper functions). - prune_diagram_snapshots trigger: keeps the 50 most recent snapshots per diagram, enforced at write time rather than a scheduled job (diagram_ snapshots has no update/delete policy for regular users at all). - 14 new pgTAP tests (52/52 total). Frontend: - DiagramCollaboratorRepository/store + DiagramSharingModal: add/remove collaborators by username, per-person view/edit permission, owner-only controls. - DiagramSnapshotRepository/store + VersionHistoryModal (its own top-bar button, not nested under Share — moved there after review): periodic checkpoints (one per 5 min of active editing) written as a side effect of normal saves, list + restore. - Restore's duplicate-snapshot problem: repeatedly jumping between old versions without editing in between was writing a near-duplicate safety snapshot on every jump. Fixed by having projectStore track which snapshot the diagram was last restored from and its updatedAt at that moment (touch() always advances updatedAt on a genuine edit) — a restore skips the safety snapshot when nothing has changed since the last one, and the tracking clears on any real edit so in-progress work stays protected. - DiagramRepository gains getAccess() (owner id + your own permission for the open diagram) — surfaced in projectStore as `access`. - View-only enforcement: FlowCanvas disables drag/connect/drop (nodesDraggable/nodesConnectable + guarded handlers), DeviceInspector/ ConnectionInspector wrap their controls in a disabled <fieldset>, DevicePalette disables adding devices to the canvas, TopBar disables the rename field, and a ViewOnlyBanner makes the restriction visible instead of leaving a collaborator to discover it as controls that just don't work. Autosave itself also refuses to write for a view-only user, as a backstop behind the UI-level lockdown. Verified: tsc -b and oxlint clean; supabase db reset + 52/52 pgTAP tests pass; confirmed find_user_id_by_username works through the real REST API via a live curl call (signup, confirm, resolve). Manually tested two- account sharing (view vs. edit), restoring history, and the duplicate- snapshot fix.
124 lines
4.6 KiB
PL/PgSQL
124 lines
4.6 KiB
PL/PgSQL
-- Diagram sharing/collaborators UI support, per organized-ideas.md §8. The
|
|
-- diagrams/diagram_collaborators/diagram_snapshots tables and their RLS
|
|
-- already exist (init schema) — this migration adds the two small pieces
|
|
-- of backend those needed to actually be usable from a UI.
|
|
|
|
-- ----------------------------------------------------------------------
|
|
-- Username -> id lookup, for "share with @username". profiles_select
|
|
-- deliberately keeps a regular user from browsing other users' profiles
|
|
-- (organized-ideas.md §2/§6), but a username is meant to be a shareable
|
|
-- handle — that's the whole point of having one — so resolving it to an id
|
|
-- (and nothing else: no email, no role) is safe to expose broadly, unlike
|
|
-- the Admin-gated lookups elsewhere in this schema. Any authenticated user
|
|
-- can call this; there's no privilege check because none is needed.
|
|
-- ----------------------------------------------------------------------
|
|
|
|
create or replace function public.find_user_id_by_username(p_username text)
|
|
returns uuid
|
|
language sql
|
|
stable
|
|
security definer
|
|
set search_path = public
|
|
as $$
|
|
select id from public.profiles where username = p_username;
|
|
$$;
|
|
|
|
-- ----------------------------------------------------------------------
|
|
-- Collaborator usernames for one diagram's sharing UI. Same problem as
|
|
-- above in reverse: diagram_collaborators only stores user ids, and
|
|
-- profiles_select_self_or_super_admin blocks a regular owner from reading
|
|
-- some *other* user's profile row directly to get their username. Gated
|
|
-- to "can you see this diagram at all" — the same condition as
|
|
-- diagrams_select's USING clause, reusing its own helper functions so the
|
|
-- two can't drift apart.
|
|
-- ----------------------------------------------------------------------
|
|
|
|
create or replace function public.diagram_collaborator_usernames(p_diagram_id uuid)
|
|
returns table(user_id uuid, username text)
|
|
language plpgsql
|
|
stable
|
|
security definer
|
|
set search_path = public
|
|
as $$
|
|
begin
|
|
if not (
|
|
public.is_super_admin()
|
|
or public.diagram_owner_id(p_diagram_id) = auth.uid()
|
|
or public.diagram_collaborator_permission(p_diagram_id, auth.uid()) is not null
|
|
) then
|
|
raise exception 'insufficient_privilege' using errcode = '42501';
|
|
end if;
|
|
|
|
return query
|
|
select dc.user_id, p.username
|
|
from public.diagram_collaborators dc
|
|
join public.profiles p on p.id = dc.user_id
|
|
where dc.diagram_id = p_diagram_id;
|
|
end;
|
|
$$;
|
|
|
|
-- ----------------------------------------------------------------------
|
|
-- Rolling snapshot retention (organized-ideas.md §8: "keep a rolling
|
|
-- window of recent diagram snapshots... exact policy TBD" — settled on
|
|
-- count-based, 50 per diagram). Enforced at write time via a trigger
|
|
-- rather than a scheduled job: diagram_snapshots has no update/delete
|
|
-- policy for regular users at all (it's meant to be immutable from their
|
|
-- side), so pruning has to run as this SECURITY DEFINER function
|
|
-- regardless of whether it's trigger- or cron-driven — a trigger is
|
|
-- simpler than also standing up pg_cron for this app's scale.
|
|
-- ----------------------------------------------------------------------
|
|
|
|
create or replace function public.prune_diagram_snapshots()
|
|
returns trigger
|
|
language plpgsql
|
|
security definer
|
|
set search_path = public
|
|
as $$
|
|
begin
|
|
delete from public.diagram_snapshots
|
|
where diagram_id = new.diagram_id
|
|
and id not in (
|
|
select id from public.diagram_snapshots
|
|
where diagram_id = new.diagram_id
|
|
order by created_at desc
|
|
limit 50
|
|
);
|
|
return new;
|
|
end;
|
|
$$;
|
|
|
|
create trigger trg_prune_diagram_snapshots
|
|
after insert on public.diagram_snapshots
|
|
for each row
|
|
execute function public.prune_diagram_snapshots();
|
|
|
|
-- ----------------------------------------------------------------------
|
|
-- Who saved each snapshot, for the version-history UI. Same shape as
|
|
-- diagram_collaborator_usernames above (gated to "can you see this
|
|
-- diagram", batched per diagram rather than per snapshot).
|
|
-- ----------------------------------------------------------------------
|
|
|
|
create or replace function public.diagram_snapshot_saved_by_usernames(p_diagram_id uuid)
|
|
returns table(user_id uuid, username text)
|
|
language plpgsql
|
|
stable
|
|
security definer
|
|
set search_path = public
|
|
as $$
|
|
begin
|
|
if not (
|
|
public.is_super_admin()
|
|
or public.diagram_owner_id(p_diagram_id) = auth.uid()
|
|
or public.diagram_collaborator_permission(p_diagram_id, auth.uid()) is not null
|
|
) then
|
|
raise exception 'insufficient_privilege' using errcode = '42501';
|
|
end if;
|
|
|
|
return query
|
|
select distinct p.id, p.username
|
|
from public.diagram_snapshots s
|
|
join public.profiles p on p.id = s.saved_by
|
|
where s.diagram_id = p_diagram_id;
|
|
end;
|
|
$$;
|