-- =====================================================================
--  TeeCup — migrasjon 012
--  Passord (valgfritt tillegg) + 2FA (ADR-021), organisasjonsinvitasjoner
--  + superadmin (ADR-022)
-- =====================================================================
--  Kjøres etter 001-011.
-- =====================================================================

\set ON_ERROR_STOP on

-- ---------------------------------------------------------------------
--  1. Passord (ADR-021 Beslutning A/B) -- Argon2id, ALDRI påkrevd.
--     NULL betyr "ikke satt" -- brukeren har da fortsatt kun magic-link.
-- ---------------------------------------------------------------------
ALTER TABLE app_user ADD COLUMN password_hash text;

-- ---------------------------------------------------------------------
--  2. 2FA (ADR-021 Beslutning C/D) -- TOTP eller e-post-engangskode,
--     brukerens eget valg. totp_secret er kun satt når metoden er 'totp'.
-- ---------------------------------------------------------------------
ALTER TABLE app_user ADD COLUMN two_factor_method text
    CHECK (two_factor_method IN ('totp', 'email'));
ALTER TABLE app_user ADD COLUMN totp_secret text;
ALTER TABLE app_user ADD CONSTRAINT app_user_totp_secret_requires_totp_method
    CHECK (totp_secret IS NULL OR two_factor_method = 'totp');

-- Engangskoder for e-post-2FA. Samme hash-og-utløp-mønster som
-- magic_link_token (004), men knyttet til user_id (identiteten er allerede
-- bevist av primær-autentiseringen på dette tidspunktet).
CREATE TABLE two_factor_code (
    id          uuid PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id     uuid NOT NULL REFERENCES app_user(id) ON DELETE CASCADE,
    code_hash   text NOT NULL,
    expires_at  timestamptz NOT NULL,
    consumed_at timestamptz,
    created_at  timestamptz NOT NULL DEFAULT now()
);
CREATE INDEX ON two_factor_code (user_id);
GRANT SELECT, INSERT, UPDATE, DELETE ON two_factor_code TO teecup_app;

-- ---------------------------------------------------------------------
--  3. Superadmin (ADR-022 Beslutning D) -- KUN manuelt DB-tildelt.
--     Bevisst INGEN API-endepunkt setter/gir dette flagget -- se ADR-022
--     for hvorfor et selvbetjent "bli superadmin"-endepunkt ville vært
--     selve sikkerhetshullet.
-- ---------------------------------------------------------------------
ALTER TABLE app_user ADD COLUMN is_super_admin boolean NOT NULL DEFAULT false;

-- ---------------------------------------------------------------------
--  4. Organisasjonsinvitasjoner (ADR-022 Beslutning B) -- e-post +
--     tiltenkt rolle. INGEN egen klikkbar token/lenke -- aksept skjer
--     automatisk ved neste innlogging med matchende e-post (samme mønster
--     som spiller-e-post-kobling, ADR-017 Beslutning B), ikke et eget
--     verifiseringstrinn.
-- ---------------------------------------------------------------------
CREATE TABLE organization_invitation (
    id               uuid PRIMARY KEY DEFAULT gen_random_uuid(),
    organization_id  uuid NOT NULL REFERENCES organization(id) ON DELETE CASCADE,
    email            citext NOT NULL,
    role             text NOT NULL CHECK (role IN ('owner', 'admin', 'member')),
    invited_by       uuid NOT NULL REFERENCES app_user(id) ON DELETE CASCADE,
    expires_at       timestamptz NOT NULL,
    consumed_at      timestamptz,
    created_at       timestamptz NOT NULL DEFAULT now()
);
-- Kun én AKTIV (uforbrukt) invitasjon per e-post per organisasjon.
CREATE UNIQUE INDEX organization_invitation_active_unique
    ON organization_invitation (organization_id, email) WHERE consumed_at IS NULL;
CREATE INDEX ON organization_invitation (email);

ALTER TABLE organization_invitation ENABLE ROW LEVEL SECURITY;
ALTER TABLE organization_invitation FORCE ROW LEVEL SECURITY;
CREATE POLICY org_isolation ON organization_invitation
    USING       (organization_id = app_current_org())
    WITH CHECK  (organization_id = app_current_org());

GRANT SELECT, INSERT, UPDATE, DELETE ON organization_invitation TO teecup_app;

-- ---------------------------------------------------------------------
--  5. accept_pending_invitations_by_email() -- femte SECURITY DEFINER-bro
--     i prosjektet (etter public_tournament_org 007, link_player_by_email
--     008, public_org_by_slug 009, public_tournament_by_code 011). Kjøres
--     på HVER innlogging (magic-link OG passord), samme idempotente,
--     "berører kun uforbrukte/gyldige rader"-mønster som
--     link_player_by_email -- gjentatte kall er en no-op.
--
--     organization_membership har INGEN RLS (se 001 -- "håndteres av
--     auth-laget"), så selve INSERT-en trenger ikke SECURITY DEFINER for
--     å krysse org-grenser -- men organization_invitation (som denne
--     leser fra) HAR RLS, og en bruker som blir invitert er per
--     definisjon IKKE medlem av org-en ennå (kan derfor ikke ha
--     app.current_org satt til den). SECURITY DEFINER løser dette
--     kontekst-problemet på nøyaktig samme måte som de fire tidligere
--     broene.
-- ---------------------------------------------------------------------
CREATE FUNCTION accept_pending_invitations_by_email(p_user_id uuid, p_email text)
RETURNS void
LANGUAGE sql
SECURITY DEFINER
SET search_path = public
AS $$
    WITH accepted AS (
        UPDATE organization_invitation
        SET consumed_at = now()
        WHERE consumed_at IS NULL
          AND expires_at > now()
          AND lower(email) = lower(p_email)
        RETURNING organization_id, role
    )
    INSERT INTO organization_membership (organization_id, user_id, role)
    SELECT organization_id, p_user_id, role FROM accepted
    ON CONFLICT (organization_id, user_id) DO NOTHING;
$$;

GRANT EXECUTE ON FUNCTION accept_pending_invitations_by_email(uuid, text) TO teecup_app;