08 — Amministrazione

L'area Amministrazione è destinata agli amministratori: account utente e controllo degli accessi, dati di riferimento, configurazione di allerte e messaggi, traduzioni, credenziali di servizio e stato di salute di PyroWISE. La maggior parte degli operatori non ne ha mai bisogno; è documentata qui per completezza e per gli amministratori che gestiscono il cockpit.

Dove si trovano queste schermate. Nella barra laterale, il gruppo Amministrazione mostra solo un paio di link cliccabili (Sign-up approvals e le voci Agentic). Le altre si raggiungono dalla barra strumenti dell'intestazione — i menu a tendina "Users & access" e "Settings" (solo per amministratori) — oppure tramite URL diretto.

Come funzionano qui i permessi. Il permesso di ogni azione è la sua route (es. /organisation/index). Il ruolo admin detiene il super-permesso (/*) e consente tutto. Alcune schermate verificano inoltre admin in modo rigido nel codice (statistiche dei visitatori del portale, l'editor del briefing del cockpit, i pannelli agentici).

Users & access

Utenti — /user/index

Crea e modifica gli account utente: nome, contatto, paese (IT / SI), reset della password e — per gli amministratori — i Ruoli dell'utente (selezione multipla). Un interruttore modalità professionale espone le preferenze di output per singolo utente (mostra sempre i riferimenti normativi, allega la bibliografia ai PDF, includi il disclaimer scientifico, esporta i dati grezzi di calibrazione). Si raggiunge dall'intestazione Users & access → Users.

La griglia (aggiornata a settembre 2026) elenca nome, cognome, e-mail, Stato (attivo / inattivo / eliminato), Struttura / sede operativa — la struttura del registro operativo a cui l'account è collegato — i ruoli RBAC, Ultimo accesso (Last login), la scadenza dell'account (rossa se già scaduta, ambra entro 30 giorni) e il telefono. Ogni intestazione tranne RBAC role ed Expire si ordina con un clic, crescente e poi decrescente; Struttura e Last login tengono in fondo, in entrambe le direzioni, gli account senza struttura o che non hanno mai effettuato l'accesso, così la lista di "chi non entra da un po'" è un clic su Last login. Last login è l'ultimo accesso riuscito registrato nel log di audit dell'autenticazione (user_auth_log), non un campo dell'account: il primo accesso di un utente appena creato compare al caricamento successivo della pagina. La colonna struttura accetta un filtro testuale (icona imbuto); gli amministratori hanno inoltre per riga l'azione Simula utente, per entrare come quella persona a fini di supporto — anch'essa registrata nello stesso audit.

Sign-up approvals — /user-approval/index

La coda di moderazione per le iscrizioni self-service — l'unico link admin sempre visibile nella barra laterale. Le schede mostrano Open (in attesa + informazioni richieste) e ciascuno stato. Apri un richiedente per vederne il profilo e i consensi GDPR, quindi:

• Approva e invia e-mail all'utente — attiva l'account, assegna i ruoli (predefinito operator), imposta una scadenza (predefinita +1 anno) e invia una nota di benvenuto via e-mail;
• Richiedi maggiori informazioni — invia una domanda obbligatoria;
• Rifiuta — con una motivazione obbligatoria.

Per contesto viene mostrato un recente log di autenticazione. Vedi 01 — Per iniziare per il lato operatore di questa procedura.

My account — /account/index

La pagina self-service di qualsiasi utente autenticato (non solo per amministratori): profilo, consensi GDPR / marketing, un link Manage API keys e un'azione GDPR Cancella account (soft-delete ora, anonimizzazione in seguito).

RBAC — ruoli, permessi, assegnazioni, route

La GUI di controllo degli accessi, sotto il menu a tendina Users & access dell'intestazione. Cinque strumenti (modulo rbac):

Dall'inizio alla fine: Route (Aggiorna → assegna per coniare i permessi di route) → Permessi (cura) → Ruoli (costruisci un ruolo dai permessi) → Assegnazioni (concedi il ruolo a un utente). I ruoli determinano ciò che ogni operatore vede e quale profilo cockpit ottiene — vedi 01 — Per iniziare → Ruoli e profili.

Reference data

Organizzazioni — /organisation/index

Organizzazioni partner/membro (tipo, paese, indirizzo, sito web, persona di contatto). Gli utenti si collegano a un'organizzazione. Si raggiunge tramite URL diretto / intestazione.

Posizioni — /location/index

Siti geografici denominati con coordinate e metadati su terreno/forestazione. L'autocompletamento delle posizioni e gli endpoint "get data" alimentano la matrice allerte e i moduli incendio/incidente, quindi mantenere questi dati puliti è importante a valle.

Non confondere queste Posizioni amministrative (geografia di riferimento) con i siti operativi delle agenzie nel registro operativo — dati diversi, scopo diverso.

Alerts & messages

Pagine CMS (modelli di messaggio) — /cms-page/index

Componi l'oggetto/corpo dell'e-mail e il messaggio breve per tipo di allerta, usando token di unione ({NAME}, {SURNAME}, {NAMESURNAME}, {ORGANISATION}, {LOCATION}, {DATETIME}, {REASON}) che vengono compilati al momento dell'invio. Si raggiunge dall'intestazione Settings → Cms Pages. Questi modelli sono consumati dalla pipeline delle allerte.

Matrice allerte — /alert-matrix/index

Il motore di regole per le notifiche: quale pagina CMS/condizione attiva un'allerta, a quale frequenza, per quali posizioni e chi viene notificato — per utente o per ruolo — su quale canale. Una regola può anche aprire automaticamente un incidente. Ogni regola ha righe Destinatario (utente · canale · attivo) e righe Ruoli (ruolo · canale · attivo).

La matrice allerte è la configurazione; le allerte live che gli operatori leggono sono in /alert/index — vedi 02 — Monitoraggio. Le consegne sono registrate nel log notifiche.

Allerte per eventi di pericolo (TerraWise): gli eventi naturali severi sincronizzati da TerraWise passano per questa stessa pipeline come tipo di allerta 26 — Evento di pericolo. Il fan-out richiede una pagina CMS per quel tipo di allerta, collegata in una regola della matrice allerte con i destinatari (una riga alert_matrix → cms_page con alert_type = 26) — lo stesso onboarding delle allerte MeteoAlarm. Senza regola l'allerta compare comunque in /alert/index; nessuno viene notificato.

Daily briefing — /cockpit-briefing/index (admin)

Componi il "Briefing del giorno" che appare sul cockpit, per data e lingua (corpo in Markdown). I briefing sono normalmente generati da un job notturno; questa schermata consente a un amministratore di scriverne o sovrascriverne uno. Si raggiunge dal link gestisci del widget di briefing del cockpit.

Localization

Traduzioni — /translation/index

L'editor i18n in-app: modifica le stringhe UI tradotte per categoria, messaggio sorgente e lingua senza un nuovo deploy (una cella modificabile in linea). È qui che le stringhe dell'aiuto e dell'interfaccia ottengono il loro testo IT / EN / SL / DE.

Service credentials

API credentials — /api-credential/index

Chiavi API personali per l'API REST di KF5 e PyroWISE (inviate come token Bearer). Genera, Ruota (il vecchio valore smette di funzionare immediatamente) e Revoca le chiavi. Il token completo viene mostrato una sola volta alla creazione/rotazione — copialo allora; successivamente viene memorizzato solo un prefisso. Gli operatori gestiscono le proprie chiavi (da Account → Manage API keys); l'accesso tra utenti è riservato agli amministratori.

PyroWISE credential — /pyrowise-credential

L'unica X-PyroWISE-Internal-Key condivisa che il cockpit usa per chiamare il simulatore (solo per amministratori). L'azione Salva e valida sonda PyroWISE /healthz prima di memorizzare — una chiave errata viene rifiutata e quella precedente mantenuta. Ri-valida ricontrolla la chiave live. Vengono mostrati un valore corrente mascherato, l'origine, lo stato dell'ultima validazione e la cronologia recente. (Il runbook di rotazione è nel README.)

Le API credentials (chiavi bearer per utente) e la PyroWISE credential (un'unica chiave interna condivisa) sono cose diverse — non confonderle.

Maintenance & legacy settings

• Manutenzione — /maintenance/index ora reindirizza al modulo unificato di manutenzione delle risorse (06 — Operazioni di campo); la griglia legacy è raggiungibile solo con ?legacy=1. (Questo è il log di manutenzione, non una "modalità di manutenzione" dell'applicazione.)
• Technology / Technology type / Technology deployment — il registro attrezzature legacy, mantenuto finché i dati non sono completamente migrati in Risorse di campo (06 — Operazioni di campo). Technology type si trova nel menu Settings dell'intestazione; il menu delle attrezzature è nascosto per impostazione predefinita. Ogni salvataggio si rispecchia nel registro unificato field_asset.

PyroWISE operations & health

Tre schermate di sola lettura riportano sul servizio PyroWISE che alimenta la simulazione, il benchmark e gli strumenti per singolo run. Tutte mostrano un banner ambra "degraded" (mai un 5xx) quando PyroWISE è irraggiungibile.

PyroWISE readiness — /pyrowise-readiness/index

La liveness e la readiness dei componenti dell'API PyroWISE. Si raggiunge dall'intestazione Settings → PyroWISE readiness. Mostra una pillola Liveness, una pillola Readiness, la versione dello schema e una tabella components — ciascuno OK / Ready (verde), Degraded (ambra) o Unavailable / Not ready (rosso).

Quando qualcosa è rosso: PyroWISE (o quel componente) è inattivo o mal configurato. Gli strumenti di simulazione, benchmark, fumo e spiegazione del run saranno degradati finché non torna verde. Verifica l'URL del servizio PyroWISE e la PyroWISE credential condivisa (sopra) ed effettua l'escalation se necessario.

PyroWISE model status — /pyrowise-model-status/index

La configurazione del modello attivo che PyroWISE sta eseguendo (URL diretto): versione di runtime e revisione git, modalità climatologia FWI, le mappature dei combustibili in uso, i priori calibrati (ambito, stagione, versione) e qualsiasi override dei priori di evento. Alcune note operatore fisse segnalano caveat noti di tipo stagionale/gating. Usala per confermare quale calibrazione ha prodotto i tuoi run.

Data inventory — /data-inventory/index

Un catalogo di sola lettura di ogni descrittore di layer AOI, unito al catalogo dataset di PyroWISE (URL diretto). Filtra per AOI, gruppo, stato, vista e readiness; la tabella elenca ogni layer con il suo tipo di rendering, lo stato (ready verde / preview ambra / planned grigio / error rosso), l'AOI e le viste applicabili, lo stato dell'artifact di build (building / stale / missing), l'id del dataset, l'ora dell'ultima build, l'hash, i flag di qualità dei dati e qualsiasi blocker. È così che vedi quali layer/dataset di mappa esistono per area e se sono stati costruiti. Un pannello in fondo riassume la copertura di mappatura EO (→ Progressione EO).

Anteprime di attivazione AOI — /aoi-profile-preview/index?aoi_profile_id=<id> (settembre 2026)

Ogni area di studio che il motore pubblica come non attiva può essere visualizzata in anteprima prima dell'attivazione. Quell'insieme lo decide il motore, non il cockpit: il 26 settembre 2026 conteneva undici profili — Veneto, Istria (Croazia), Emilia-Romagna, Trentino-Alto Adige, Toscana, Umbria, Marche, Campania, Puglia, Lazio e Sicilia — mentre i cinque attivi (Carso Italia–Slovenia, Friuli Venezia Giulia, Slovenia, Sardegna e il catch-all Mediterraneo) sono quelli offerti dal selettore. Nel frattempo la Slovenia è passata ad attiva, quindi non dare per fermo questo elenco: la pagina mostra sempre l'insieme corrente. Nel selettore AOI dell'intestazione questi profili compaiono in grigio (passa il mouse per il motivo); l'icona occhio accanto al selettore apre l'anteprima, e un selettore interno alla pagina passa da un profilo anteprima all'altro. La pagina mostra identità ed estensione del profilo, il catalogo dei layer governato, i siti operativi al suo interno, il pannello dei blocchi di attivazione letto dal vivo dall'endpoint di prontezza del motore (raggruppati per ciò che manca ancora lato motore) e un link Apri anteprima 3D governata (/map3-d?profile_preview=1) inquadrato sull'area. Le anteprime sono governate: nulla al loro interno lancia una simulazione, invia un avviso o scrive un record, e aprirne una non cambia l'AOI in cui lavora la tua sessione. La funzione è dietro un flag di host e un permesso dedicato: su alcune installazioni (l'host Carso al 26 settembre 2026) il flag è spento, e allora l'icona occhio e la pagina semplicemente non ci sono, invece di essere vuote; è un amministratore ad accenderlo. Usala per giudicare se il piano dati di un'area è completo abbastanza da chiederne l'attivazione; l'attivazione stessa è un intervento dell'operatore sul motore, tracciato in docs/IMPLEMENTATION_STATUS.md §5.

Correlati

• 09 — Assistenti PyroTwin — gli assistenti IA riservati agli amministratori e le loro code di approvazione.
• 01 — Per iniziare — ruoli e profili dal lato operatore.
• 03 — Tabelle di log — i log di audit e di notifica su cui fanno affidamento gli amministratori.