Attribution du super-admin : écrire contre le schéma réel de user_roles

[THIOYE97]

Le symptôme

En production, sur le shell Render :

psycopg.errors.UndefinedColumn: column "id" of relation "user_roles" does not exist

La cause

La table de production vaut exactement :

CREATE TABLE public.user_roles (
    user_id uuid NOT NULL,
    role    public.user_role NOT NULL,   -- ENUM, pas varchar
    PRIMARY KEY (user_id, role)
);

Le modèle app/models/user_role.py déclare en plus id, tenant_id et created_at. Comme le schéma de test est construit depuis les modèles (Base.metadata.create_all), l'écart est invisible en test : le code passait les 152 tests et ne pouvait qu'échouer en production. C'est exactement le piège déjà documenté en tête de app/models/screening_db.py.

Bon à savoir : SUPER_ADMIN est une valeur de l'ENUM, et user_id/role existent bien — la modification de auth_service.py livrée en PR #5 tourne donc sans risque en production. C'est ce que confirme le 401 propre observé sur /auth/login.

Le correctif

• l'INSERT est construit d'après information_schema : valable sur le schéma de production comme sur celui des modèles ;
• le ON CONFLICT (tenant_id, user_id, role) supposait une contrainte unique absente en production → remplacé par un contrôle d'existence explicite ;
• les comparaisons sur role sont castées en texte, pour valoir contre l'ENUM comme contre le varchar ;
• --list ne réclame plus created_at quand la colonne n'existe pas ;
• le modèle porte désormais un avertissement en tête : il ne décrit pas la table de production.

Vérifications

Exécuté sur base jetable contre les deux schémas — attribution, idempotence, listage, retrait, compte introuvable :

===== SCHÉMA PRODUCTION (user_id, role enum) =====      OK
===== SCHÉMA MODÈLES (id, tenant_id, user_id, role) =====  OK

Plus un test unitaire sur la construction de l'INSERT, pour que la CI protège les deux cas — c'est le seul niveau où le test peut voir l'écart, puisque la base de test ne connaît que le schéma des modèles.

Reste ouvert

Le vrai assainissement serait d'aligner le modèle sur la base par une migration dédiée, ou d'aligner la base sur le modèle. Tant que les deux divergent, tout code écrit d'après le modèle est un piège. Hors périmètre de ce correctif.