From 44deeab35db2b92aa2eecc759db7fb606a02ba48 Mon Sep 17 00:00:00 2001
From: Julien Gautier <julien.gautier@apf.asso.fr>
Date: Fri, 8 May 2026 20:55:55 +0200
Subject: [PATCH] fix(infra): grant audit roles to current_user, not hardcoded
 portal
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The bootstrap SQL ended with:

    GRANT audit_owner, audit_writer, audit_reader, audit_archiver TO portal;

which assumed POSTGRES_USER is `portal`. The compose file (and the
.env.example) document POSTGRES_USER as overridable — anyone who
changed it to something else (e.g. `apf_portal`) hit:

    ERROR: role "portal" does not exist
    psql: .../01-init.sql:48: ERROR: role "portal" does not exist

`current_user` resolves at script execution to whoever is running
the init SQL — that is, the superuser Postgres just created from
POSTGRES_USER, regardless of its name. Use it instead of hard-coding
`portal`.

Recovery for anyone hit by the original bug:

    cd infra/local
    docker compose -f dev.compose.yml down -v   # wipes the
                                                # half-initialised
                                                # postgres-data volume
    docker compose -f dev.compose.yml up -d     # bootstrap re-runs
                                                # cleanly
---
 infra/local/init/postgres/01-init.sql | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/infra/local/init/postgres/01-init.sql b/infra/local/init/postgres/01-init.sql
index ebccf5a..0f7a528 100644
--- a/infra/local/init/postgres/01-init.sql
+++ b/infra/local/init/postgres/01-init.sql
@@ -41,8 +41,17 @@ ALTER DEFAULT PRIVILEGES FOR ROLE audit_owner IN SCHEMA audit
   GRANT DELETE ON TABLES TO audit_archiver;
 
 -- ---------------------------------------------------------------- Dev convenience
--- The default `portal` superuser bypasses these grants anyway, but
--- granting the audit roles explicitly lets us test role-based access
--- with `SET ROLE audit_writer;` etc. from a psql session against the
--- dev DB. Production never grants all four to one user.
-GRANT audit_owner, audit_writer, audit_reader, audit_archiver TO portal;
+-- The dev superuser (created by Postgres from POSTGRES_USER, default
+-- `portal` but overridable in infra/local/.env) bypasses these grants
+-- anyway, but granting the audit roles explicitly lets us test
+-- role-based access with `SET ROLE audit_writer;` etc. from a psql
+-- session against the dev DB.
+--
+-- `current_user` resolves at script execution time to whoever is
+-- running the init SQL — i.e. the superuser created from POSTGRES_USER,
+-- whatever its name happens to be. Hard-coding `portal` here was
+-- wrong: it broke any setup where the contributor changed
+-- POSTGRES_USER in their .env.
+--
+-- Production never grants all four roles to one user.
+GRANT audit_owner, audit_writer, audit_reader, audit_archiver TO current_user;