Gate: nessun modulo può dichiarare ruoli in auth.ruoli #7

New Issue

2026-08-28T08:39:14Z

LucaZanni commented

2026-08-28 08:39:14 +00:00

Perché

auth.ruoli appartiene a node-user-profiling e il suo contratto (seed 13, esteso dalla migrazione 19) vieta agli altri moduli di crearne. Non è una formalità: il claim role del JWT è il primo ruolo applicativo dell'utente e PostgREST ci fa un SET ROLE, ma i ruoli PostgreSQL esistono solo per i tredici livelli di piattaforma. Un ruolo per-modulo in quel claim è una sessione che non parte.

Il contratto prevedeva un controllo in CI che non è mai stato scritto, e nel frattempo nove microfrontend lo hanno disatteso: 21 ruoli creati, 27 su 35 senza omonimo PostgreSQL, e un'utenza di collaudo che PostgREST respingeva. Il riassetto ha sistemato lo stato; questo gate serve perché non si ripeta.

Cosa fa

Nuovo step in quality-gates.yml, attivo per tutti i repo che usano il workflow condiviso. Cerca INSERT INTO auth.ruoli nei file .sql sotto migrations/, seeds/, sql/ e database/migrations/, e fallisce indicando cosa fare invece — dichiarare un gruppo d'area con i propri permessi, scegliendo il livello fra i tredici di piattaforma.

Dettagli di implementazione:

il boundary dopo ruoli evita che auth.ruolipermessi finisca fra i match;
le righe che iniziano per -- sono ignorate: i commenti spesso spiegano proprio questa regola;
una-tantum e rollback sono escluse: raccolgono delta generati e script di ritorno, strumenti operativi che fotografano stati passati, e riscriverli falserebbe la storia che documentano;
se il repo non ha cartelle di migrazioni lo step esce subito senza fallire.

L'eccezione

Nuovo input owns-auth-roles (default false): solo node-user-profiling lo imposta a true nel proprio ci.yml, perché è il proprietario dello schema. È l'unica deroga, ed è esplicita.

Prima di attivarlo

I nove repository che dichiaravano ruoli sono stati ripuliti: la dichiarazione è sostituita da un commento che rimanda al file dei gruppi d'area e alla migrazione 20 che li ha ritirati. Verificato su tutti e 30 i frontend con migrazioni e sui backend principali — nessuno fallisce, tranne node-user-profiling che ha la deroga.

Nota

Il tag v1, che tutti i repo referenziano, va spostato perché il gate entri in vigore.

## Perché `auth.ruoli` appartiene a node-user-profiling e il suo contratto (seed `13`, esteso dalla migrazione `19`) vieta agli altri moduli di crearne. Non è una formalità: il claim `role` del JWT è il primo ruolo applicativo dell'utente e PostgREST ci fa un `SET ROLE`, ma i ruoli PostgreSQL esistono solo per i tredici livelli di piattaforma. Un ruolo per-modulo in quel claim è una sessione che non parte. Il contratto prevedeva un controllo in CI che non è mai stato scritto, e nel frattempo **nove microfrontend lo hanno disatteso**: 21 ruoli creati, 27 su 35 senza omonimo PostgreSQL, e un'utenza di collaudo che PostgREST respingeva. Il riassetto ha sistemato lo stato; questo gate serve perché non si ripeta. ## Cosa fa Nuovo step in `quality-gates.yml`, attivo per tutti i repo che usano il workflow condiviso. Cerca `INSERT INTO auth.ruoli` nei file `.sql` sotto `migrations/`, `seeds/`, `sql/` e `database/migrations/`, e fallisce indicando cosa fare invece — dichiarare un gruppo d'area con i propri permessi, scegliendo il livello fra i tredici di piattaforma. Dettagli di implementazione: - il boundary dopo `ruoli` evita che `auth.ruolipermessi` finisca fra i match; - le righe che iniziano per `--` sono ignorate: i commenti spesso spiegano proprio questa regola; - `una-tantum` e `rollback` sono escluse: raccolgono delta generati e script di ritorno, strumenti operativi che fotografano stati passati, e riscriverli falserebbe la storia che documentano; - se il repo non ha cartelle di migrazioni lo step esce subito senza fallire. ## L'eccezione Nuovo input `owns-auth-roles` (default `false`): solo node-user-profiling lo imposta a `true` nel proprio `ci.yml`, perché è il proprietario dello schema. È l'unica deroga, ed è esplicita. ## Prima di attivarlo I nove repository che dichiaravano ruoli sono stati ripuliti: la dichiarazione è sostituita da un commento che rimanda al file dei gruppi d'area e alla migrazione `20` che li ha ritirati. Verificato su tutti e 30 i frontend con migrazioni e sui backend principali — nessuno fallisce, tranne node-user-profiling che ha la deroga. ## Nota Il tag `v1`, che tutti i repo referenziano, va spostato perché il gate entri in vigore.

LucaZanni referenced this issue from a commit

2026-08-28 08:41:03 +00:00

✨ feat(ci): nessun modulo puo' dichiarare ruoli in auth.ruoli

LucaZanni added spent time 1 hour

2026-08-28 08:41:03 +00:00

LucaZanni closed this issue

2026-08-28 08:41:03 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Total Time Spent: 1 hour

LucaZanni

1 hour

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: devops/shared-actions#7