Frontend er bevisst ikke hånd-kodet denne gangen — jeg husket korrigeringen fra rundeskjermene tidligere i prosjektet, så jeg har i stedet skrevet en V0-prompt (i FEATURE_BACKLOG.md) for en ny /my-friends-side, klar til å kjøres når du vil.
57 lines
2.9 KiB
SQL
57 lines
2.9 KiB
SQL
-- Venner-kjernen (ADR-036, fase 1), 2026-07-25.
|
|
--
|
|
-- Gjensidig vennskap (forespørsel/aksept, samme grunnmønster som
|
|
-- organisasjon-invitasjoner) + en PRIVAT, ENSIDIG kategorisering i et fast
|
|
-- sett grupper -- vennen vet aldri hvilken/hvilke kategorier den andre har
|
|
-- puttet dem i (ADR-036 Beslutning A).
|
|
--
|
|
-- Ingen RLS -- samme `plain_connection()`-mønster som personlig profil/
|
|
-- HCP-historikk/frittstående runder (ADR-033 Beslutning A): autorisasjon
|
|
-- håndheves i app-laget med eksplisitt `WHERE user_id = $1`, ikke policyer.
|
|
|
|
CREATE TABLE friendship (
|
|
id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
|
|
requester_user_id uuid NOT NULL REFERENCES app_user(id) ON DELETE CASCADE,
|
|
addressee_user_id uuid NOT NULL REFERENCES app_user(id) ON DELETE CASCADE,
|
|
-- Bevisst KUN to tilstander -- en avvist/kansellert forespørsel har
|
|
-- ingen verdi å beholde som egen rad, den slettes i stedet (se
|
|
-- app/routers/friends.py). Et nytt forsøk oppretter da bare en ny rad.
|
|
status text NOT NULL DEFAULT 'pending' CHECK (status IN ('pending', 'accepted')),
|
|
created_at timestamptz NOT NULL DEFAULT now(),
|
|
responded_at timestamptz,
|
|
CHECK (requester_user_id <> addressee_user_id)
|
|
);
|
|
|
|
-- Ett vennskap PER PAR, uavhengig av hvem som ba først -- hindrer at A kan
|
|
-- be B to ganger, eller at A og B begge har en åpen forespørsel til
|
|
-- hverandre samtidig.
|
|
CREATE UNIQUE INDEX friendship_unique_pair
|
|
ON friendship (LEAST(requester_user_id, addressee_user_id), GREATEST(requester_user_id, addressee_user_id));
|
|
|
|
CREATE INDEX friendship_requester_idx ON friendship (requester_user_id);
|
|
CREATE INDEX friendship_addressee_idx ON friendship (addressee_user_id);
|
|
|
|
-- Kategori er et FAST, ikke brukerdefinerbart sett (samme mønster som
|
|
-- BAG_CLUBS/gender/stat_level ellers i appen) -- norske visningsnavn i
|
|
-- app-laget, se ADR-036: spouse=Make, close_family=Nær familie,
|
|
-- extended_family=Storfamilie, close_friends=Nære venner,
|
|
-- golf_friends=Golfvenner, colleagues=Kollegaer, business=
|
|
-- Forretningsforbindelser, classmates=Studiekamerater, acquaintances=
|
|
-- Perifere bekjente, other=Ymse. En venn kan ha FLERE rader (flere
|
|
-- kategorier samtidig).
|
|
CREATE TABLE friend_categorization (
|
|
owner_user_id uuid NOT NULL REFERENCES app_user(id) ON DELETE CASCADE,
|
|
friend_user_id uuid NOT NULL REFERENCES app_user(id) ON DELETE CASCADE,
|
|
category text NOT NULL CHECK (category IN (
|
|
'spouse', 'close_family', 'extended_family', 'close_friends',
|
|
'golf_friends', 'colleagues', 'business', 'classmates',
|
|
'acquaintances', 'other'
|
|
)),
|
|
created_at timestamptz NOT NULL DEFAULT now(),
|
|
PRIMARY KEY (owner_user_id, friend_user_id, category)
|
|
);
|
|
|
|
CREATE INDEX friend_categorization_friend_idx ON friend_categorization (friend_user_id);
|
|
|
|
GRANT SELECT, INSERT, UPDATE, DELETE ON friendship TO teecup_app;
|
|
GRANT SELECT, INSERT, UPDATE, DELETE ON friend_categorization TO teecup_app;
|