From 67fccd84e2b504d2f52e8dec557bff91eae22e11 Mon Sep 17 00:00:00 2001
From: LucaZanni <info@pzeta.it>
Date: Fri, 28 Aug 2026 10:40:25 +0200
Subject: [PATCH] =?UTF-8?q?=E2=9C=A8=20feat(ci):=20nessun=20modulo=20puo'?=
 =?UTF-8?q?=20dichiarare=20ruoli=20in=20auth.ruoli?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- nuovo step in quality-gates.yml: cerca INSERT INTO auth.ruoli nei file .sql di
  migrations, seeds, sql e database/migrations, e fallisce spiegando cosa fare
  invece — dichiarare un gruppo d'area con i propri permessi, scegliendo il
  livello fra i tredici di piattaforma
- il contratto esisteva dal seed 13 di node-user-profiling e prevedeva questo
  controllo, che non era mai stato scritto: nove microfrontend lo hanno
  disatteso, 21 ruoli creati e 27 su 35 senza omonimo PostgreSQL. Un ruolo cosi'
  nel claim role del JWT e' un SET ROLE che non riesce, e l'utenza di collaudo
  del timesheet ne era la prova
- il boundary dopo `ruoli` tiene fuori auth.ruolipermessi; le righe di commento
  sono ignorate perche' spesso spiegano proprio questa regola
- una-tantum e rollback sono escluse: raccolgono delta generati e script di
  ritorno, fotografie di stati passati che riscrivere falserebbe
- nuovo input owns-auth-roles (default false): solo node-user-profiling, che
  possiede lo schema, lo mette a true. Unica deroga, ed e' esplicita
- verificato su tutti i 30 frontend con migrazioni e sui backend principali:
  nessuno fallisce dopo la ripulitura dei nove repo

Fixes #7 @1h
---
 .gitea/workflows/quality-gates.yml | 60 ++++++++++++++++++++++++++++++
 1 file changed, 60 insertions(+)

diff --git a/.gitea/workflows/quality-gates.yml b/.gitea/workflows/quality-gates.yml
index 3ba62bb..1b16f25 100644
--- a/.gitea/workflows/quality-gates.yml
+++ b/.gitea/workflows/quality-gates.yml
@@ -13,6 +13,13 @@ on:
       npm-version:
         type: string
         default: ''
+      owns-auth-roles:
+        description: >-
+          Solo per il repository proprietario di auth.ruoli (node-user-profiling):
+          gli consente di dichiarare ruoli nelle proprie migrazioni. Ogni altro
+          repo deve lasciarlo a false, e il gate qui sotto glielo impedisce.
+        type: boolean
+        default: false
 
 jobs:
   quality-gates:
@@ -46,6 +53,59 @@ jobs:
           echo "@pzeta:registry=https://gitea.pzetatouch.it/api/packages/PZeta_Touch/npm/" >> ~/.npmrc
           echo "//gitea.pzetatouch.it/api/packages/PZeta_Touch/npm/:_authToken=${{ secrets.NPM_TOKEN }}" >> ~/.npmrc
 
+      - name: Nessun ruolo dichiarato fuori da node-user-profiling
+        if: ${{ !inputs.owns-auth-roles }}
+        shell: bash
+        run: |
+          # `auth.ruoli` appartiene a node-user-profiling e il suo contratto (seed
+          # 13, esteso dalla migrazione 19) vieta agli altri moduli di crearne.
+          # Non e' una formalita': il claim `role` del JWT e' 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 e' una sessione che non parte.
+          # Nove microfrontend lo avevano disatteso: 21 ruoli, 27 su 35 senza
+          # omonimo PostgreSQL. Questo controllo esiste perche' non si ripeta.
+          set -uo pipefail
+          dirs=""
+          for d in migrations seeds sql database/migrations; do
+            [ -d "$d" ] && dirs="$dirs $d"
+          done
+          if [ -z "$dirs" ]; then
+            echo "Nessuna cartella di migrazioni: controllo non applicabile."
+            exit 0
+          fi
+
+          # Il boundary dopo `ruoli` evita che auth.ruolipermessi finisca fra i
+          # match; il filtro sulle righe che iniziano per -- lascia passare i
+          # commenti, che spiegano spesso proprio questa regola.
+          # Fuori dal controllo le cartelle che non alimentano il catalogo delle
+          # migrazioni: `una-tantum` raccoglie i delta generati per riallineare a
+          # mano un tenant, `rollback` gli script di ritorno. Sono strumenti
+          # operativi, spesso fotografie di uno stato passato, e riscriverli
+          # significherebbe falsare la storia che documentano.
+          hits=$(grep -rniE --include='*.sql' \
+                   --exclude-dir=una-tantum --exclude-dir=rollback \
+                   'insert[[:space:]]+into[[:space:]]+auth\.ruoli([[:space:]]|\(|$)' \
+                   $dirs 2>/dev/null \
+                 | awk -F: '{ riga=$0; sub(/^[^:]*:[^:]*:/, "", riga); gsub(/^[[:space:]]+/, "", riga); if (riga !~ /^--/) print }' || true)
+
+          if [ -n "$hits" ]; then
+            echo "::error::Questo repository dichiara ruoli in auth.ruoli, che appartiene a node-user-profiling."
+            echo ""
+            echo "$hits"
+            echo ""
+            echo "Cosa fare invece: dichiarare un GRUPPO d'area con i permessi del modulo."
+            echo "  INSERT INTO auth.gruppi (nome, nomecompleto, descrizione, tipogruppo, idruololivello)"
+            echo "  ... poi INSERT INTO auth.gruppipermessi per collegarvi i propri permessi."
+            echo ""
+            echo "Il livello che accompagna il gruppo si sceglie fra i tredici di piattaforma"
+            echo "(manager, contabile, auditor, cfo, dipendente, viewer, operatore, cliente):"
+            echo "sono gli unici ad avere un ruolo PostgreSQL, senza il quale il SET ROLE fallisce."
+            echo "Esempio: vue-timesheet/migrations/12_gruppi_area.sql"
+            exit 1
+          fi
+          echo "Nessun INSERT INTO auth.ruoli: contratto rispettato."
+
       - name: Check outdated packages
         run: npm outdated || true