Priorità 0: visibilità per organizzazione

Regola di accesso

Il backend ricava user_id dal token, risolve membership e organization_id attiva tramite i servizi di identità, quindi esegue ogni operazione con quello scope. Il browser non è una fonte attendibile per organization_id o user_id.

Il verticale Bandi fornisce il pattern di riferimento: organizzazione risolta server-side, scope obbligatorio nelle query, permessi runtime e controlli di membership. Rendicontazione deve adottare lo stesso principio, adattandolo al fatto che oggi ogni utente appartiene a una sola organizzazione.

Modifiche dati

1. Usare backbone_auth.organization(id) come fonte autorevole; non creare una seconda identità tenant indipendente.
2. Aggiungere organization_id text alle entità radice e operative: dipendenti, cataloghi configurabili, progetti, finanziatori, tariffe, import, presenze, allocazioni, run, audit e stato operativo.
3. Rendere tenant-aware le unicità, per esempio UNIQUE (organization_id, code).
4. Impedire associazioni cross-tenant con foreign key composite, trigger mirati o repository transaction guard; preferire vincoli DB dove sostenibile.
5. Aggiungere indici con organization_id come primo campo sui principali pattern di lettura.
6. Rendere actual_through_month e delivered_through_month stati per organizzazione.

Migrazione senza interruzione

Passo A — inventario e tenant legacy

• L'organizzazione destinataria dei dati POC è Consorzio Italbiotec in DEV, TEST e PROD (alias accettati: nome Italbiotec/Consorzio Italbiotec, slug italbiotec/consorzio-italbiotec).
• La migrazione deve risolvere l'ID tramite backbone_auth.organization usando esclusivamente questi alias espliciti, senza hardcodare un ID condiviso tra ambienti.
• La migrazione deve fallire esplicitamente se Italbiotec non esiste o se la risoluzione non è univoca; non deve usare Vinova Lab come fallback.
• Produrre un report di record orfani, duplicati e relazioni incoerenti.
• Creare una mapping table/manifest di migrazione versionato.

Passo B — expand

• Aggiungere organization_id nullable e nuovi indici senza cambiare il comportamento esistente.
• Aggiornare scritture e job perché valorizzino sempre il tenant.
• Introdurre metriche/alert per scritture prive di tenant.

Passo C — backfill

• Assegnare tutti i dati legacy a Italbiotec in ciascun ambiente.
• Propagare lo scope sulle tabelle figlie per join controllati.
• Verificare conteggi, checksum e assenza di record null/cross-tenant.

I dati correnti sono dati di test e possono essere eliminati se impediscono una migrazione coerente. L'eventuale pulizia deve comunque essere esplicita, limitata allo schema rendicontazione, eseguita tramite procedura di rollout e verificata prima di applicare i vincoli NOT NULL.

Passo D — enforce

• Rendere organization_id NOT NULL.
• Attivare vincoli, chiavi uniche e filtri obbligatori.
• Rimuovere ogni fallback a query globali.

Passo E — contract cleanup

• Eliminare colonne/tabelle placeholder non allineate a backbone_auth.
• Rendere impossibile per i client scegliere arbitrariamente il tenant.

API e autorizzazione

Creare un unico OrganizationContext interno con almeno userId, organizationId, membership e permessi. Repository e use case devono richiederlo esplicitamente; nessun metodo di dominio deve poter interrogare tabelle tenant senza scope.

Permessi iniziali consigliati:

Permesso	Capacità
rendicontazione.read	Leggere dati dell'organizzazione
rendicontazione.manage_hr	Gestire anagrafiche, ruoli, società e costi
rendicontazione.manage_projects	Gestire progetti e associazioni
rendicontazione.manage_actuals	Importare/correggere consuntivi
rendicontazione.deliver_period	Marcare un mese come consegnato
rendicontazione.manage_forecast	Modificare input ed eseguire forecast
rendicontazione.self_leave	Gestire il proprio piano ferie
rendicontazione.admin	Configurazioni e procedure eccezionali

Criteri di accettazione del gate P0

• Due utenti della stessa organizzazione vedono e aggiornano gli stessi dipendenti/progetti secondo i rispettivi permessi.
• Un utente di organizzazione B non può leggere, dedurre, esportare, modificare o collegare ID di A.
• List, detail, search, export, import, job asincroni, calcoli e websocket rispettano lo scope.
• Nessuna tabella operativa contiene organization_id nullo.
• Un cambio dell'ID nell'URL non produce data leakage (404 o 403 coerente con la policy).
• Test automatici coprono almeno due organizzazioni e relazioni cross-tenant.
• Log, metriche e audit includono organization_id senza esporre dati personali non necessari.

Gate di sviluppo

Le feature successive possono essere preparate su branch, ma non devono essere rilasciate al committente finché questi criteri non sono soddisfatti.