# Handoff — TerManager2 Stato del progetto per chi ci mette mano dopo. Per installazione, deploy e uso quotidiano vedi [README.md](README.md); qui c'è il contesto che il README non può dare: perché le cose sono come sono, e cosa resta aperto. Ultimo aggiornamento: **21 ottobre 2026** — si riprende da [Stato attuale](#stato-attuale). --- ## Stato attuale **⚠️ 21 ottobre 2026 — PHP da aggiornare.** Produzione e demo girano su PHP 8.3.35, vulnerabile a CVE-2026-109618/109619 (esecuzione di codice da remoto). Il Dockerfile ora richiede la 8.3.36, che esce alle 14:00 UTC del 21/10; nel frattempo c'è una mitigazione nel `php.ini`. Vedi [Sicurezza: PHP](#sicurezza-php-cve-2026-109618--cve-2026-109619-21-ottobre-2026). **Produzione** (`main` → compose `termanager2-core-production`) in esercizio su Dokploy dal 19 ottobre 2026. Ultimo rilascio: `d3314a9` (proclamatori senza contatti, il link si copia o si condivide). Backup fatti prima dei rilasci in `/etc/dokploy/termanager2-backups/` sul server. **Demo** (`dev` → compose `termanager2-core-demo`, `demo-termanager.pyconetwork.it`): avanti di una ventina di commit, tutti provati con la suite sul server e pubblicati sulla demo. **Non ancora in produzione** — l'utente ha chiesto di aspettare il suo ok: - [gruppi di servizio](#gruppi-di-servizio-19-20-ottobre-2026-solo-su-dev): sorvegliante con email fittizia, pacchetto di territori, "Il mio gruppo", scioglimento; migrazioni `2026_10_20_000010` … `000040`; - priorità e filtri nel pacchetto, con la regola di priorità della Home in un metodo solo (`Territorio::ordinaPerPriorita()`); - pulsante **Rientro** nell'elenco dei territori assegnati; - storico assegnazioni in una tabella sola, con le colonne in linea; - *Assegna* aperta da "Assegna →" della Home senza l'elenco dei territori assegnati; - password del sorvegliante dal pannello *Utenti*, anteprima dal numero in "Il mio gruppo"; - [modulo pubblico delle richieste, cartacei, S-13 per email](#richieste-dal-modulo-pubblico-cartacei-s-13-per-email-21-ottobre-2026-solo-su-dev) (migrazione `2026_10_21_000010`). **Per portarli in produzione**: backup del database di produzione, merge di `dev` in `main` (dopo il rilascio di sicurezza del 21/10 non è più un fast-forward), deploy (l'autodeploy non parte: vedi [Dove gira davvero](#dove-gira-davvero)), poi controllo di migrazioni e conteggi. In produzione non ci sono gruppi né richieste: le migrazioni non hanno dati da convertire. | Aspetto | Stato | |-----------------------------|-------| | Deploy Dokploy (Compose) | ✅ produzione e demo | | Autodeploy al push | ⚠️ configurato, ma dal 19/10 il push non fa partire il deploy: si avvia a mano (`compose.deploy`) | | Primo avvio a zero-config | ✅ migrazioni + seed + admin automatici | | Redeploy senza interventi | ✅ ~25 secondi | | Sviluppo locale | ✅ stesso compose, profilo `dev` | | Backup / ripristino / azzeramento | ✅ verificati end-to-end | | Ripristino da browser in linea | ⚠️ **limitato a 100 MB da Cloudflare** — vedi [Cosa resta aperto](#cosa-resta-aperto) | | Test automatici | ✅ **577 test PHP + 13 JavaScript, verdi** (20/10/2026); copertura ancora parziale | | Prove nel browser | ⚠️ le funzioni del 19-20 ottobre sono verificate dai test e sul server; nel browser le ha usate l'utente sulla demo | La storia precedente (luglio-agosto: backup e ripristino, sotto-app Piantine, sistema visivo, prima suite di test) è in [Da dove veniamo](#da-dove-veniamo). --- ## Lavori recenti — ottobre 2026 Dal più recente. Le sezioni del 12-19 ottobre sono in produzione; quelle del 20-21 ottobre e i gruppi di servizio solo sulla demo. ### Richieste dal modulo pubblico, cartacei, S-13 per email (21 ottobre 2026, solo su dev) Dal documento `_ARCHIVE/ATTIVITA sviluppo Territori Manager 2.0.docx` (attività per la versione 2): analizzato con l'utente, che ha deciso così. - **Modulo pubblico** `/richiesta` (rotta `richiesta`, fuori dal login, `throttle:60,1`; componente `Richieste\ModuloRichiesta`, layout guest): nome e cognome, *nuovo territorio* o *riconsegna* (con numero), nota. Non mostra dati esistenti. Anti-spam: campo trappola `sito` (classe `.tm-trappola`), tempo minimo `SECONDI_MINIMI` = 3 s (in questi due casi risponde "inviata" senza salvare), `MASSIMO_ORA` = 5 per IP (chiave del RateLimiter con lo sha1 dell'IP). Il tempo si legge con `now()`, così i test possono viaggiare nel tempo. - **Tabella `richieste`** (migrazione `2026_10_21_000010`, che crea anche il permesso `richieste.gestisci` per amministratore e assistente e la colonna `assegnazioni.cartaceo`): nome e note cifrati; nel registro delle attività solo tipo, stato, numero (`richiesta_ricevuta` all'arrivo, poi i cambi di stato). `RichiesteServizio`: `registra()`, `destinatari()`, `nomiSimili()`, `assegnazioneAperta()`. - **Email di avviso** (`Notifications\RichiestaRicevuta`) a chi ha `richieste.gestisci` con l'email confermata, solo se la posta funziona (`ConfigurazionePosta::funzionante()`). Non in coda: contiene il nome. - **Conferma dalla Home** (riquadro *Richieste*, solo con il permesso): scelta dell'utente, "così non si modifica troppo il codice del form precompilato". Per un nuovo territorio la Home propone i proclamatori attivi con un nome simile (punteggio per parola: uguale 3, iniziale 2, una lettera di differenza 1; serve almeno 2) e ognuno apre *Assegna* con `?proclamatore=&richiesta=&dalla_home=1`; per una riconsegna, *Rientra* con `?richiesta=`. I due moduli leggono `richiesta` solo se aperta e se l'utente ha il permesso (`#[Locked] richiestaId`), la mostrano sopra il form e, fatta l'operazione, la segnano **evasa** (`Richiesta::evadi()`). Altrimenti *Scarta*. La Home "messaggi" del documento sono solo queste richieste. - **Pulizia**: `richieste:pulizia` ogni notte cancella le richieste gestite da più di `PuliziaRichieste::GIORNI` = 90 giorni. Le richieste non sono nell'XML né nel `.zip` (un ripristino non le tocca); l'azzeramento le cancella (passo "Richieste" di `ResetApplication`, ora 12 passi). - **Cartaceo sull'assegnazione** (scelta dell'utente: "va sull'assegnazione"): spunta su *Assegna* e in "Il mio gruppo" (`GruppiServizio::assegna(..., cartaceo:)`), etichetta "cartaceo" nell'elenco degli assegnati e in "Il mio gruppo". Nell'elenco è un'espressione, non un blocco `@if`: Livewire mette due commenti segnaposto attorno a ogni `@if`, 58 byte a riga anche quando è falso, e la riga superava i 2,6 KB del test di peso. Pagina **Cartacei** (`assegnazioni/cartacei`, `territori.assign`, voce di menu sotto *Assegnazioni*) con i territori cartacei fuori. Passa per l'XML. - **S-13 per email**: `registro:invia-s13 {--anno=}` manda `Mail\ModuloS13Mail` (PDF allegato, non in coda) agli amministratori con l'email confermata; nello scheduler `weeklyOn(0, '08:00')` con `when(settimana dopo in un altro mese)` = **ultima domenica del mese**. Senza posta non parte e lo dice. Nel registro `s13_inviato` con anno e quanti. - Informativa privacy aggiornata (dati, conteggi, posta, conservazione; revisione 21 ottobre 2026). Test in `tests/Feature/RichiesteTest.php` e `GruppiServizioTest` (cartaceo dal sorvegliante, cartaceo nell'XML). ### Sicurezza: PHP CVE-2026-109618 / CVE-2026-109619 (21 ottobre 2026) Due esecuzioni di codice da remoto nel core di PHP (CVSS v4 9.2), patch alle 14:00 UTC del 21/10/2026; versione corretta per il nostro ramo: **8.3.36**. Il progetto girava su 8.3.35. - `docker/php/Dockerfile`: `ARG PHP_VERSION=8.3.36` e `FROM php:${PHP_VERSION}-fpm`. Prima era `php:8.3-fpm`, un tag che si sposta ma che Docker tiene in cache: una ricostruzione senza `--pull` (anche su Dokploy) poteva riusare la base vulnerabile. Ora una build o prende la 8.3.36 o fallisce. Test `tests/Unit/VersionePhpTest.php` contro il ritorno a un tag mobile o a una versione inferiore. - phpredis da GitHub (`ARG PHPREDIS_VERSION=6.3.0`) invece di `pecl install`: quel giorno pecl.php.net rispondeva 504 e la build falliva. - Solo per provare in locale prima che l'immagine sia su Docker Hub: `PHP_VERSION=8.3.35 docker compose ...` (mai per un deploy). - **Mitigazione in attesa della patch** (indicata da Sansec, approvata dall'utente): `session.upload_progress.enabled = 0` e `session.use_strict_mode = 1` in `docker/php/php.ini`, da tenere anche dopo (all'applicazione non servono: Laravel ha le sue sessioni, in Redis). Nei container già in esecuzione di demo e produzione la stessa cosa va in `conf.d/zz-mitigazione-cve-2026-109618.ini` con ricarica morbida di php-fpm (USR2): si perde quando il container viene ricreato, e da lì vale il `php.ini` dell'immagine. *Stato dell'applicazione ai container: vedi sotto, aggiornato a ogni passo.* - Da fare quando `php:8.3.36-fpm` è su Docker Hub: test sulla 8.3.36, poi deploy di demo e produzione (vedi [Stato attuale](#stato-attuale)). Finché restano su 8.3.35 sono esposte. **Scelta dell'utente (21/10): in produzione solo la correzione di PHP.** I due commit di sicurezza (`db5772d` e la mitigazione nel `php.ini`) vanno su `main` con un cherry-pick (branch locale `rilascio-php`, sopra `d3314a9`); gruppi di servizio e lavori del 20 ottobre restano sulla demo, da rilasciare un altro giorno. Dopo il rilascio `main` e `dev` divergono: per portare `dev` in produzione servirà un merge (i cherry-pick sono già in `dev`, conflitti attesi solo in HANDOFF). - Il passaggio di consegne di quella sessione (`HANDOFF-chat.md`) sta nella cartella del progetto ma non nel repository (escluso in `.git/info/exclude`): contiene dettagli dell'infrastruttura. **⚠️ Demo costruita con PHP 8.3.35 in via provvisoria (21/10, 14:40 UTC).** L'utente ha chiesto il deploy della demo prima che uscisse `php:8.3.36-fpm`: nelle variabili d'ambiente del compose della demo in Dokploy c'è `PHP_VERSION=8.3.35` (con un commento "TOGLIERE subito dopo"), che il `docker-compose.yml` passa al Dockerfile. La mitigazione ora sta nell'immagine (`php.ini`). **Appena c'è la 8.3.36: togliere quella variabile e rifare il deploy della demo**, altrimenti resta su 8.3.35 anche dopo la patch. In produzione questa via non si usa. Stato al 21/10, 11:00 UTC circa: mitigazione nel `php.ini` del repository (su `dev` e nel branch di rilascio, non ancora deployabile finché manca l'immagine 8.3.36) e **applicata ai container in esecuzione** di demo e produzione, entrambi ancora su PHP 8.3.35: php-fpm ricaricato (processi di lavoro nuovi, stesso master), `php-fpm -i` riporta `session.upload_progress.enabled => Off` e `session.use_strict_mode => On`, login 200 su entrambi. ### Password del sorvegliante dal pannello Utenti (21 ottobre 2026, solo su dev) Richiesta dell'utente: poter reimpostare la password del sorvegliante dal pannello di amministrazione. Prima si poteva solo dalla pagina del gruppo; in *Utenti* la sua riga non aveva azioni. Ora ha "Nuova password temporanea" (con conferma) e "Apri il gruppo"; la password compare una volta sola in cima all'elenco, con l'email, fino a "Ho annotato la password". La logica è una sola, `GruppiServizio::nuovaPasswordTemporanea()`, usata anche da `GruppoShow`; rifiuta gli utenti che non sono sorveglianti (per loro c'è il modulo di modifica). Test in `GruppiServizioTest`. ### Anteprima dal numero in "Il mio gruppo" (21 ottobre 2026, solo su dev) Richiesta dell'utente: anche il sorvegliante deve poter vedere l'anteprima del territorio, con un popup al clic del numero. Il numero diventa un pulsante (stesso aspetto, `button.tm-assegnato-numero` in `app.css`) che apre una finestra (`tm-modale`, stato Alpine `anteprima` sulla radice della vista) con la miniatura e "Apri la piantina (PDF)". La miniatura passa da una rotta nuova, `mio-gruppo.miniatura` (`TerritorioFileController::miniaturaGruppo`, `Territorio::miniaturaGruppoUrl()`), con la stessa regola di `mio-gruppo.pdf`: solo i territori del pacchetto del gruppo che l'utente sorveglia. La rotta normale delle miniature resta chiusa al sorvegliante. Senza miniatura né PDF il numero resta testo. ### Assegna aperta dalla Home: senza l'elenco dei territori assegnati (20 ottobre 2026) Richiesta dell'utente: "quando provengo da un territorio dalla home, non mostrare lo storico assegnazioni". Avevo capito la scheda del territorio e ne avevo nascosto lo storico (commit `f1f3408`, poi annullato con un revert): intendeva la pagina *Assegna* aperta da "Assegna →" della Home, e come "storico" l'elenco "Territori Assegnati" sotto il modulo. Ora quel link porta `?dalla_home=1` e `Assegna::$elencoNascosto` toglie `ElencoAssegnati` (che così non si carica nemmeno). Dal menu o dalla scheda del territorio l'elenco c'è come prima. Non si usa il `?da=` del ritorno per capirlo: si trasmette di pagina in pagina. ### Storico assegnazioni in linea (20 ottobre 2026) Richiesta dell'utente (screenshot della scheda territorio): le colonne dello storico cambiavano posizione da un anno all'altro, perché ogni anno era una tabella a sé dimensionata sul suo contenuto. Ora, nella scheda del territorio e in quella del proclamatore, è **una tabella sola** con un'intestazione, colonne a larghezza fissa (`table-fixed`, `w-[..%]`), e l'anno come riga di separazione `tr.tm-riga-gruppo` (in `app.css`, su telefono resta un titolo e non diventa una scheda). Ordine esplicito: anni dal più recente (`sortKeysDesc`), dentro l'anno per data di assegnazione. Nella scheda del proclamatore la colonna Campagna ora dice "Sì — …" / "No" come in quella del territorio, e c'è il badge "via gruppo …". Test: `StoricoAssegnazioniTest`. ### Rientro dall'elenco dei territori assegnati (20 ottobre 2026) Richiesta dell'utente ("un tasto che va alla registrazione", dallo screenshot della pagina *Assegna* con l'elenco filtrato per proclamatore): in `ElencoAssegnati` ogni riga ha **Rientro** (solo con `territori.return`), che apre la registrazione del rientro e, con `data-ritorno`, torna all'elenco. Anche le righe senza PDF lo hanno. L'elenco ha un tetto di peso per riga (`AssegnaPrestazioniTest`, 2,6 KB) e il pulsante lo sforava di 21 byte: per starci l'indirizzo è relativo (`route(..., false)`, `data-ritorno` lo gestisce) e il pulsante sta sulla stessa riga del `
`, senza a capo né commenti dentro il ciclo (i commenti Blade spariscono, gli spazi no). ### Gruppi di servizio (19-20 ottobre 2026, solo su dev) Richiesta dell'utente: un **gruppo di servizio** con un sorvegliante che, entrato con una sua utenza, distribuisce ai membri un pacchetto di territori e non vede nient'altro. Le decisioni sono cambiate più volte in due giorni: qui sotto **com'è oggi**, in fondo la storia. **Come funziona** - **Chi**: un gruppo ha un nome (unico), un sorvegliante (proclamatore attivo) e dei membri. Un proclamatore sta in **un solo** gruppo; il sorvegliante è anche membro e assegna solo ai membri, a sé compreso. Gruppi, membri e pacchetti li gestisce **solo l'amministratore** (menu *Gruppi di servizio*). - **Utenza del sorvegliante**: nasce con il gruppo. Email **fittizia** (`GruppiServizio::emailFittizia()`: iniziale del nome e cognome, minuscoli, senza accenti, spazi né apostrofi, su `GruppiServizio::DOMINIO_EMAIL` = `termanager.it` — Francesco Fontana → `ffontana@termanager.it`, numero in coda se già presa), la stessa convenzione degli altri utenti. Password temporanea, mostrata una volta: al primo accesso la pagina del cambio dice "Password temporanea" (`users.password_temporanea`, che il ripristino e l'import XML spengono, perché lì il motivo è il ripristino). Nessuna conferma dell'email (`User::hasVerifiedEmail()` vero per il sorvegliante), e dal profilo l'email non si cambia. Ruolo `sorvegliante`, con il solo permesso `gruppo.gestisci`; non compare nella pagina *Utenti*, dove le utenze legate a un proclamatore non si modificano né si eliminano. "Nuova password temporanea" dalla pagina del gruppo o dalla riga del sorvegliante nel pannello *Utenti* (stessa logica, `GruppiServizio::nuovaPasswordTemporanea()`: password provvisoria, cambio obbligato, "ricordami" azzerato, log `password_reimpostata`; le sessioni aperte si chiudono perché cambia l'hash). In *Utenti* è l'unica azione su quell'utenza, con "Apri il gruppo". - **Cosa vede**: `LimitaSorvegliante` (gruppo `web`) lascia a chi ha **solo** quel ruolo `mio-gruppo*`, `assegnazioni.rientra` (solo per il suo gruppo: `Rientra::autorizza`), profilo, cambio password e le azioni Livewire — `*livewire.*`, perché in Livewire 3.7 la rotta si chiama `default.livewire.update` (con `livewire.*` ogni clic era un 403, e `Livewire::test()` non passa dai middleware: un test chiama la rotta vera). La Home lo rimanda al gruppo, il resto è 403. La voce di menu "Il mio gruppo" guarda il **ruolo**, non `@can`: l'amministratore passa ogni `@can` (`Gate::before`). - **Pacchetto**: **non è un'assegnazione** ("la media non deve essere alterata"): i territori sono "In gruppo …" (stato `in_gruppo`), fuori da "Da assegnare" e dalla pagina *Assegna* (`Territorio::scopeInReparto` esclude `gruppo_servizio_id`). Si aggiungono in blocco dai territori in reparto in ordine di priorità (`Territorio::ordinaPerPriorita()`, la regola della Home), con ricerca, zona, tipologia, "solo prioritari" e "Seleziona tutti quelli mostrati" (`GruppoShow`). - **"Il mio gruppo"** (`MioGruppo`): sotto il titolo nome e cognome del sorvegliante; prima i territori da dare in ordine di priorità, poi i già dati dal più vecchio; filtri stato, zona, tipologia, "solo prioritari" (nell'indirizzo). Il sorvegliante assegna, manda il link (copia o condividi: trait `Concerns\InviaLink` + partial `assegnazioni/_invio-link`, gli stessi di *Assegna*), registra i rientri, apre la piantina, rimanda in reparto quelli non dati. Il numero del territorio apre l'anteprima (finestra Alpine nella vista, miniatura e collegamento al PDF). - **Assegnazione dal pacchetto**: un'**assegnazione normale**, con `gruppo_servizio_id` e `gruppo_nome` ("via gruppo …" in registro e schede). `GruppiServizio::assegna()` rilegge territorio e membro e ricontrolla il pacchetto sotto lock. Al **rientro** il territorio esce dal pacchetto e torna in reparto (hook `updated` in `Assegnazione`, da qualunque pagina). - **Scioglimento**: "Togli il ruolo e sciogli il gruppo", oppure il sorvegliante non è più attivo — reso non attivo, nel cestino o anonimizzato (`Proclamatore::booted`, eventi `updated` su `attivo` e `deleted`; l'elenco chiede conferma, la modifica avvisa sotto "Attivo"). `GruppiServizio::sciogli()` **elimina il gruppo**: i territori solo nel pacchetto tornano in reparto; quelli già dati restano ai membri e l'assegnazione ne conserva il nome (confermato dall'utente); i membri restano senza gruppo; l'**utenza del sorvegliante si elimina** con `User::eliminaConservandoStorico()` — la stessa eliminazione della pagina *Utenti* — che passa le sue assegnazioni a chi scioglie (o al primo amministratore) e lascia le sue voci nel registro a nome "Sorvegliante del gruppo …". Il motivo va nel registro (`gruppo_sciolto`, `motivo`). Un membro non attivo resta nel gruppo ma non riceve territori; nel cestino ne esce. - **Segnalazioni**: `Proclamatore::gruppo_etichetta` ("Gruppo Zisa" / "Sorvegliante del gruppo Zisa") come badge nell'elenco dei proclamatori (filtro *In un gruppo di servizio*, `filtroStato=gruppo`) e in testa alla scheda; nelle opzioni di `` come `dettaglio` (Assegna, Registro), non come `motivo`: assegnare direttamente a un membro resta possibile. La scheda del proclamatore mostra il gruppo che guida (`GruppoServizio::riepilogo()`, email, password temporanea o no, ultimo accesso) o quello di cui è membro; il *Profilo* del sorvegliante il suo gruppo. - **Dati personali**: nel registro delle attività `User::tapActivity()` sostituisce nome ed email dell'utenza del sorvegliante con "proclamatore #id", come per tutti i proclamatori; nella tabella `users` restano in chiaro, come per ogni utente. Informativa privacy aggiornata. - **Backup**: l'XML porta gruppi, membri, pacchetto, provenienza delle assegnazioni (id e nome del gruppo) e il legame utenza ↔ proclamatore; da un file del 19-20 ottobre non si importano i gruppi con `` né le utenze con ``. L'azzeramento (*Zona pericolosa*) cancella anche i gruppi. **Dove sta** - Migrazioni: `2026_10_20_000010_gruppi_di_servizio` (tabella, colonne `gruppo_servizio_id` su proclamatori, territori e assegnazioni, `users.proclamatore_id` unico, permesso e ruolo; il seeder dà all'amministratore tutti i permessi **tranne** `gruppo.gestisci`), `000020` (`assegnazioni.gruppo_nome`, via `sciolto_at` e i gruppi sciolti), `000030` (via `users.username` e `users.disattivato_at` e le utenze disattivate, email fittizia a chi non l'aveva, email di nuovo obbligatoria), `000040` (`users.password_temporanea`). - Regole in `App\Services\GruppiServizio`; i componenti `Gruppi\GruppiIndex`, `Gruppi\GruppoShow` (amministratore) e `Gruppi\MioGruppo` (sorvegliante) le chiamano soltanto. - Test: `tests/Feature/GruppiServizioTest.php`. **Com'è cambiato** (decisioni dell'utente, in ordine) 1. 19/10 — gruppo con membri; il pacchetto non conta nelle statistiche; utenza con email e password, senza conferma; togliere il ruolo scioglie il gruppo, che restava archiviato (`sciolto_at`) con l'utenza disattivata. 2. 20/10 — sorvegliante non più attivo ⇒ gruppo sciolto; dettagli nella scheda e nel profilo; anche i membri segnalati. 3. 20/10 — il gruppo sciolto non resta nello storico (si elimina); traccia "via gruppo" sulle assegnazioni confermata. Per qualche ora il sorvegliante è entrato con un nome utente ricavato dal nome del gruppo. 4. 20/10 — al posto del nome utente l'email fittizia iniziale+cognome; sciolto il gruppo l'utenza si elimina ("torna proclamatore normale, non tenere traccia"). 5. 20/10 — "Password temporanea" al primo accesso; il 403 sulle azioni; priorità e filtri; nome del sorvegliante sotto il titolo. ### Proclamatori senza contatti; il link si copia o si condivide (19 ottobre 2026) Decisione dell'utente, dopo il rilascio: i proclamatori **non hanno più email né telefono**, e WhatsApp ed email spariscono come canali. Restano: - **Copia link**; - **Condividi…**: `navigator.share()` con il messaggio già scritto (`Assegnazione::messaggioLink()`), cioè il menu di condivisione del telefono (WhatsApp, Telegram, SMS…), da cui chi usa l'app sceglie app e contatto. Compare solo dove il browser lo offre (telefoni, alcuni computer); il canale si annota a condivisione fatta, non se la si annulla. Nell'elenco dei territori assegnati "Condividi" andato a buon fine segna il link come inviato (`ElencoAssegnati::segnaCondiviso`). Cosa è cambiato: - Migrazione `2026_10_19_000020_togli_contatti_proclamatori`: elimina le colonne `email` e `telefono`. In produzione erano vuote (0 su 111) al momento della decisione; su dev c'era un solo valore di prova. - Tolti dal form, dalla scheda e dall'elenco dei proclamatori; tolti `Proclamatore::telefonoInternazionale()/whatsappUrl()`, il componente ``, gli stili `tm-whatsapp`, la notifica `LinkTerritorio` e `Assegna::inviaEmail()`. - XML: non si esportano più; un file vecchio che li contiene si importa ignorandoli. - `Assegnazione::CANALI_ATTIVI` = copia, condividi. In `CANALI_LINK` restano anche "whatsapp" ed "email" solo per le assegnazioni già inviate così. - La posta resta, ma solo per le email agli utenti (conferma dell'indirizzo). - Informativa privacy, README e test (`InvioLinkTest`, al posto di `ContattiProclamatoriTest`) aggiornati. **In produzione dal 19 ottobre 2026, ore 17:10** (`main` = `7384a4b`). Prima: ricontrollato che email e telefono fossero vuoti (0 su 111) e backup in `/etc/dokploy/termanager2-backups/prod-20261019-150408/`. Dopo: migrazione applicata, colonne tolte, conteggi identici a prima (1130 assegnazioni, 77 aperte), 111/111 proclamatori decifrati, 272/272 PDF, 4/4 utenti confermati. L'autodeploy non era partito entro 2 minuti dal push: deploy avviato a mano. ### Allineamento di main in dev e passaggio in produzione (19 ottobre 2026) `main` è stato unito in `dev` (merge, non rebase): da `main` arrivano solo `S-12_I.pdf` nella radice e una riga di `.gitignore`. Quel PDF, copia identica di `resources/pdf/S-12_I.pdf` e non usato dal codice, è stato poi tolto su richiesta dell'utente; il modulo usato da `PiantinaPdfService` è quello in `resources/pdf/` e resta. I 5 conflitti (README, `CampagnaShow`, `Registro`, `Assegnazione`, vista della campagna) nascevano dalle correzioni sulle campagne fatte su `main` la mattina e già portate su `dev`: si è tenuta la versione di `dev`, che le contiene già (con `proclamatore_id` nel log al posto del nome). Dopo, `main` va portato avanti fino a `dev` senza un nuovo merge, così in produzione va esattamente il codice provato su dev. Analisi d'impatto per prod (fatta sui dati di prod copiati in dev): - 11 migrazioni nuove, provate sulla copia: nessun errore, conteggi identici. Due toccano dati esistenti: `nomi_proclamatori_fuori_dal_log` (irreversibile, solo da backup) e `posta_contatti_e_conferma_email`, che **azzera la conferma email di tutti gli utenti**. - In prod non c'è un server di posta: subito dopo il deploy va eseguito `php artisan utenti:conferma-email ` per ogni utente, altrimenti nessuno riesce a lavorare. La posta si configura poi dall'app. - `MAIL_SCHEME=tls` nell'ambiente di prod non è valido per Laravel 11: svuotarlo. Prod è in HTTPS con `SESSION_SECURE_COOKIE=false`: valutare `true`. - Il nuovo controllo dell'entrypoint su `APP_KEY` passa: chiave d'ambiente e `storage/app/.app_key` coincidono. - Ritorno indietro: ripristino del dump fatto prima del deploy e deploy del `main` precedente (`bde7a4a`). **Rilasciato in produzione il 19 ottobre 2026 alle 16:13** (`main` = `e4549f8`, fast-forward da `dev`). Prima: backup in `/etc/dokploy/termanager2-backups/prod-20261019-141137/` sul server (database, file, conteggi) e copia del dump sul PC dell'utente; `MAIL_SCHEME` svuotato nell'ambiente di prod. Deploy di 32 secondi, 11 migrazioni applicate senza errori, email dei 4 utenti confermata con `utenti:conferma-email`. Verifica: conteggi identici a prima del deploy, 111/111 proclamatori decifrati, 272/272 PDF presenti, campagna di settembre a 13 conteggiati (4,7%), nessun nome in chiaro rimasto nel log. Subito dopo, su decisione dell'utente, `SESSION_SECURE_COOKIE=true` nell'ambiente di prod (nuovo deploy: i cookie di sessione e XSRF ora sono `secure; httponly; samesite=lax`). Resta da fare: configurare la posta dall'app (*Impostazioni → Server di posta*) per poter usare il canale Email. Deploy: su Dokploy l'autodeploy da push è attivo (`triggerType=push`, nessun filtro di percorso) e secondo l'utente funziona. Le variabili d'ambiente invece diventano effettive solo con un nuovo deploy, che una loro modifica non avvia da sola. ### Informativa privacy aggiornata e dinamica (19 ottobre 2026) Richiesta dell'utente: aggiornare la sezione privacy con i dati attuali e prendere i parametri dalle impostazioni. Il testo era fermo a una versione precedente (solo nome e cognome, "tre ruoli: Admin, Servitore di Territorio, Proclamatore Semplificato" che non esistono). - `App\Livewire\Privacy` legge al momento: congregazione, `audit_retention_days`, `giorni_per_smarrito` (scadenza del link), `pdf_viewer_show_download`, server di posta (`ConfigurazionePosta`), `config('app.cipher')`, `config('session.lifetime')`, `APP_URL` (avvisa se non è HTTPS), i ruoli con i permessi veri (`Privacy::PERMESSI` li spiega) e quanti dati sono conservati (contati in SQL: i campi cifrati vuoti restano NULL, non serve decifrare). `Privacy::REVISIONE` è la data del testo. - Aggiunte: link alla piantina, invio dal telefono di chi assegna, mappe OpenStreetMap, conferma email, blocco dopo troppi tentativi. (Email e telefono dei proclamatori, che il primo testo citava, sono stati tolti la sera stessa; dal 20 ottobre il testo parla anche del gruppo di servizio e dell'utenza del sorvegliante.) - Titolare e base giuridica sono rimasti com'erano: sono valutazioni legali, da far rivedere a chi ne ha la competenza. - **Aperto — backup in chiaro**: il pacchetto di backup usa l'export XML, che legge i proclamatori dal modello e quindi esporta nome e cognome **decifrati**. L'informativa lo dice; valutare se cifrare l'archivio (per esempio con una password scelta al download). - `PrivacyTest` verifica che i valori cambino con le impostazioni, i ruoli, i conteggi senza nomi e l'accesso solo amministratore. ### Pagina Assegna più leggera; "Vedi tutti" in testata nella Home (19 ottobre 2026) Segnalazione dell'utente: la pagina Assegnazioni era lenta. Misurato su dev con i dati di prod (79 assegnazioni aperte): il server la genera in ~80 ms con 10 query, ma l'HTML pesava **387 KB** (299 l'elenco dei territori assegnati, di cui 58 di icone SVG ripetute; 75 le opzioni dei campi di scelta) e Livewire lo rimandava **per intero a ogni interazione**: scegliere un territorio (anteprima con `wire:model.live`), scrivere nella ricerca dell'elenco (`linkSearch`), aprire l'invio del link. Rimedi: - L'elenco è un componente a sé, `Assegnazioni\ElencoAssegnati`, **lazy**: la pagina mostra subito il form e le sue azioni non lo ridisegnano. "Invia link" nell'elenco chiede alla pagina di aprire l'invio con l'evento `apri-invio` (`Assegna::apriInvio` ha `#[On('apri-invio')]`); `toggleLinkSent` sta nell'elenco. - La ricerca nell'elenco filtra nel browser (`data-cerca` senza accenti, Alpine `elencoCercabile`): nessuna richiesta mentre si scrive. - Il territorio va a Livewire con `wire:model` (non più `.live`): l'anteprima della miniatura segue la scelta nel browser (evento `scelta` di ``, URL della miniatura nelle opzioni). - Righe compatte: icone come simboli SVG definiti una volta e richiamati con ``, classi brevi `tm-assegnato-*` in `app.css` al posto delle catene di utility, copia del link con il metodo condiviso `copia()` di `elencoCercabile`. I pulsanti restano `` (lo impone `StileUnificatoTest`). Il ramo "link scaduto" dell'elenco (solo per non autenticati, cioè mai su questa pagina) è stato tolto. - `AssegnaPrestazioniTest` tiene fermi questi punti, compreso un tetto al peso per riga dell'elenco. - Corretto anche `Assegnazione::giorni`: con Carbon 3 `diffInDays()` è un float e PHP segnalava una conversione implicita a ogni riga. Home: "Vedi tutti" di *Da assegnare* e *Da rientrare* è ora un pulsante nella testata del riquadro, accanto al PDF, invece che in fondo all'elenco. Compare alle stesse condizioni di prima (elenco troncato al limite della Home). ### Scelta di territori e proclamatori con ricerca (19 ottobre 2026) Al posto delle tendine di territorio e proclamatore (Assegna, finestra del Registro, editor delle piantine) c'è ``: si scrive e compaiono le proposte più vicine; campo vuoto o appena aperto = la tendina completa. - Ordine: uguale → inizia con → contiene → a una lettera di distanza ("forse cercavi", due lettere dalle 7 in su; mai sui numeri sotto le 4 cifre, così "35" non trova "36"). Le parole scritte valgono in qualsiasi ordine ("mario ros"); maiuscole e accenti non contano. Logica pura in `resources/js/scelta.js`, provata da `tests/js/scelta.test.mjs` (`npm run test:js`, oppure `node --test tests/js/`). - Le opzioni le prepara il server (`Territorio::opzioneScelta()`, `Proclamatore::opzioneScelta()/opzioniScelta()`). Con `motivo` un'opzione compare cercando ma non si sceglie: in Assegna i territori già assegnati ("già assegnato a …"), nel Registro territori e proclamatori disattivati. - Nomi e cognomi sono cifrati: si ordinano e si cercano decifrati, nella pagina. Prima il Registro li ordinava in SQL, cioè a caso. - Telefono: testo a 16px sotto i 640px (iOS non ingrandisce), voci alte 44px, elenco in mezzo schermo, scelta al tocco senza perdere il focus; dopo la scelta col dito il campo perde il focus e la tastiera si chiude. - Con Livewire: `wire:model` sul componente (x-modelable). `vuoto` è il valore di "nessuna scelta": `null` per le proprietà `?int` (Assegna), `''` per le stringhe. Il componente si ridisegna quando cambiano le opzioni (wire:key con l'impronta), perché x-data le legge una volta sola. - Il filtro "Filtra territori" di Assegna non serve più ed è stato tolto. ### Si torna da dove si è partiti (19 ottobre 2026) Regola dell'utente: dopo un'operazione — confermata **o annullata** — si torna alla pagina da cui il percorso era partito, con i suoi filtri, ricerca, ordinamento e pagina. Elenco filtrato → scheda → Rientra → conferma riporta all'**elenco filtrato**, non alla scheda (scelta esplicita). - Gli elenchi (territori, proclamatori, registro) tengono ricerca, filtri e ordinamento nell'indirizzo con `#[Url]`; la pagina c'era già (paginazione). - I link verso schede e operazioni hanno `data-ritorno`: `resources/js/app.js` gli aggiunge `?da=` al momento dell'uso (pointerdown/click/menu contestuale/focus, prima di wire:navigate). Se la pagina corrente ha già un `da`, passa quello: si risale sempre all'origine. - `App\Support\Ritorno::valida()` accetta solo percorsi interni (niente `https://…`, `//…`, `\`, caratteri di controllo, `/livewire/…`): il parametro non può diventare un rimando verso l'esterno. - Le pagine di scheda e operazione usano il trait `RicordaRitorno` (`$ritorno`, `destinazione()`): redirect dopo il salvataggio, "Annulla" e "Torna…" (che con un ritorno diventa "Torna indietro"). - Aperte senza `da` (menu laterale, link salvato) tutto resta com'era. - Link nuovi verso una scheda o un'operazione: metterci `data-ritorno`; pagine nuove di operazione: usare `RicordaRitorno`. ### Invio del link dopo l'assegnazione, nuovo territorio dal designer (19 ottobre 2026) Richieste dell'utente: - **Dopo l'assegnazione non si va avanti** finché non si è deciso del link: si apre una finestra che blocca la pagina (oggi trait `Concerns\InviaLink`, usato anche da "Il mio gruppo") con i canali. *Superato la sera stessa: WhatsApp ed email sono stati tolti, restano Copia link e Condividi… — vedi "Proclamatori senza contatti".* Com'era il primo giorno: - *Copia link*: sempre; - *WhatsApp*: solo se il proclamatore ha un numero utilizzabile; - *Email*: solo se ha un indirizzo **e** la posta funziona (`ConfigurazionePosta::funzionante`), inviata subito e mai in coda. Poi "Hai inviato il link?": *Sì* vuole un canale usato, *No* è sempre possibile. Solo dopo la risposta si ricarica la pagina. - **Se la procedura non si conclude** (scheda chiusa) o si risponde *No*, resta `assegnazioni.link_da_inviare = true` e compare "Link ancora da inviare" nell'elenco della pagina Assegna (con "Invia link", che riapre la finestra) e nella scheda del territorio (che rimanda a `assegnazioni/assegna?invia=`). L'avviso sparisce quando il link risulta inviato, anche dal pulsante "Non inviato / Link inviato" dell'elenco. - Colonne nuove (migrazione `2026_10_19_000010`): `link_da_inviare` (le assegnazioni già esistenti restano false: niente avvisi a posteriori su link di cui non si sa niente) e `link_canale` (oggi `copia`/`condividi`, `Assegnazione::CANALI_ATTIVI`; `whatsapp`/`email` restano in `CANALI_LINK` solo per le assegnazioni già inviate così). Entrambe nell'XML. - Nel log `link_inviato` / `link_non_inviato` con canale e `proclamatore_id`: mai nomi. - **"Nuovo territorio"** (elenco territori) apre il designer delle piantine con `?nuovo=1` (`PiantineEditor::$creaTerritorio`): la mappa parte già in disegno e la prima piantina disegnata si apre con "nuovo territorio" scelto. L'editor è solo dell'amministratore: chi ha `territori.manage` ma non `settings.manage` resta sul form `territori.create`, che esiste ancora. ### Posta, contatti dei proclamatori, conferma email (12-13 ottobre 2026) Richieste dell'utente, con le sue scelte: - **Server di posta dall'app** (Impostazioni → Server di posta, rotta `posta.edit`, `Settings\PostaElettronica`): host, porta, cifratura (automatica / SSL / nessuna), utente, password cifrata, mittente; pulsante "Invia email di prova". Se compilato prende il posto del `.env` (`ConfigurazionePosta::applica()`, agganciata alla creazione del mail manager e a ogni job della coda). Non si esporta nell'XML e l'import non la cancella (`Setting::CAMPI_POSTA`). Nel `.env.example` `MAIL_SCHEME=tls` era un valore non valido per Laravel 11: ora vuoto. - ~~Proclamatori: email e telefono facoltativi~~ — *tolti il 19 ottobre 2026, vedi "Proclamatori senza contatti" qui sotto*. - **Dopo l'assegnazione** — *rivisto il 19 ottobre 2026, vedi "Invio del link dopo l'assegnazione" qui sotto*. Il riquadro in sessione (`Assegna::DA_INVIARE`) non esiste più. - **Conferma email obbligatoria** per tutti gli utenti (tranne il sorvegliante di gruppo), anche quelli già esistenti (la migrazione `2026_10_13_000010` azzera `email_verified_at`). L'admin crea l'utente con la password come prima; parte l'email di conferma (in italiano, `VerifyEmail::toMailUsing`); il link funziona anche senza login. Cambiare email (profilo o admin) la rende da confermare e rimanda il link. In Utenti: stato "da confermare" e "Reinvia conferma". Raggiungibili senza conferma: profilo, cambio password, pagina di conferma e — per l'amministratore — il server di posta. Emergenza: `php artisan utenti:conferma-email `. Il primo admin creato da riga di comando nasce confermato. - Nei test gli utenti nascono confermati (`tests/TestCase.php`, `$confermaUtentiCreati`). Provato nel browser in locale con mailpit come server configurato dall'app: email di prova e di conferma arrivate, link aperto senza login, account sbloccato. Configurazione e dati di prova rimossi dopo. ### Modulo S-13, editor piantine, revisione (12 ottobre 2026) In produzione dal 19 ottobre 2026 (erano su `dev` dal 12): - `d433c93` — Modulo S-13 sul modulo ufficiale (regole in `app/Services/Registro/ModuloS13.php`) e blocco 1 della revisione (integrità dati). - `056d95c` — Editor piantine: bozza automatica, un solo "Pubblica" con anteprima, stati Bozza / Pubblicata / Modifiche da pubblicare. Come funziona: [Le piantine sono una sotto-app](#le-piantine-sono-una-sotto-app-renderer-esterno-agganci-minimi). - `426a952` — blocchi 2 e 3 della revisione (sotto). ### Revisione profonda: blocchi 2 e 3 chiusi | Problema | Correzione | |---|---| | Esiti delle azioni Livewire persi o mostrati alla pagina dopo (11 componenti) | trait `Avvisa` + ``; un test vieta `session()->flash()` senza redirect | | PDF, miniature e versioni scaricabili da `/storage/territori-*` senza login (nomi indovinabili, cache Cloudflare 7 giorni) | nginx risponde 404 su `/storage/territori-`; `TerritorioFileController` con permessi della pagina e cache privata; `Territorio::pdfUrl()` / `miniaturaUrl()` | | Ripristino non atomico | estrazione verificata (CRC, byte) → una transazione con import, piantine, blocco account e scambio file (`rename`, annullabile) → file vecchi cancellati solo dopo il commit | | Piantine, storico PDF, area KML fuori dal backup | formato archivio 2 (`piantine.json`, `piantine/…`, `PiantineBackup`); gli archivi di formato 1 si ripristinano lo stesso | | Blocco "una sola operazione" ignorato da import XML/PDF, e controllo+presa in due passi | `BackupOperationState::occupa()` sotto `Cache::lock`, usato da tutte le porte; rilascio anche su errore e in `failed()` | | Import PDF da cartella: `1-A` → territorio 1, `12 B` ambiguo, solo 20 file, `Thumbs.db` blocca tutto, `__MACOSX` | abbinamento "cifre + al massimo una lettera"; ambigui scartati; caricamento a lotti dal browser; file non PDF ignorati | | Import PDF e caricamento dalla scheda cancellavano il vecchio PDF prima di scrivere il nuovo | prima il nuovo, poi il vecchio nello storico (`PiantinaPdfService::archiviaCorrente`, origini `import` / `manuale`) | | L'import XML lasciava sul disco i file dei territori ricreati (nel PC: 549 file, 80 MB) | l'import elimina i file non più usati; per i vecchi c'è `php artisan territori:file-orfani` (elenca; `--elimina` cancella) — **da lanciare quando si decide** | | Azzeramento lasciava piantine orfane, area KML, anteprime | cancellate anche quelle | | `/cambia-password` senza password attuale | richiesta, tranne dopo un ripristino (cambio obbligatorio) | | Sessioni aperte altrove non chiuse al cambio password | `AuthenticateSession` nel gruppo web; il ripristino conserva l'hash di chi lo esegue, così non viene buttato fuori | | Nomi dei proclamatori in chiaro nel registro attività | si salva `proclamatore_id`, il registro mostra il nome attuale; migrazione `2026_10_12_000010` ripulisce le voci vecchie | | Export XML con `remember_token`; l'import XML non obbligava a cambiare password | token non esportato e azzerato all'import; chi riceve l'hash dal file deve cambiare password | | Campagne: sparivano l'ultimo giorno; percentuale oltre il 100% | confronto per data; si contano i territori attivi distinti | | `retry_after` 90 s con job fino a 900 s | `config/queue.php`: 960 s | | Worker ucciso dopo 10 s al riavvio | `stop_grace_period: 16m` | | Redis `allkeys-lru` poteva sfrattare i job in coda | `volatile-lru` | | Cache statica di `Setting` vecchia nel worker | svuotata a ogni job (`Queue::before`) | | Dopo un ripristino le piantine pubblicate risultavano "da pubblicare" (lo stato dipendeva dall'id del territorio) | impronta con il numero, non l'id; la piantina ricorda il PDF pubblicato (`pdf_pubblicato`, migrazione `2026_10_12_000020`) | | `corrente()` / `liberaCorrente()` potevano cancellare il puntatore di un'operazione appena avviata | `corrente()` in sola lettura; `liberaCorrente()` sotto lo stesso mutex di `occupa()` | | Pulsanti profilo/menu che non si nascondevano (barra che trabocca su telefono) | `.tm-btn` sta fuori dai layer di Tailwind e vince su `hidden`: si nasconde il contenitore | Non cambiato, di proposito: `trustProxies('*')` (commento in `bootstrap/app.php`: con `real_ip` di nginx, restringerlo romperebbe HTTPS). Suite: **429 test verdi**. Provati in browser in locale: file protetti (404 senza login, PDF e miniature con login), caricamento a lotti (25 PDF in 2 lotti, `Thumbs.db` ignorato, nessun territorio toccato, posto liberato). **Non provato / aperto:** - chiusura delle sessioni con due browser veri; coda e worker con un riavvio reale; modifica vertici al tocco su tablet vero; - l'upload Livewire ha `throttle:60,1`: oltre ~1200 file al minuto qualche lotto riceve 429 (il browser lo segnala); - numeri di territorio con lettere davanti ("A12") non si abbinano da nome file: il PDF si carica dalla scheda. --- ## Da dove veniamo Il progetto aveva un difetto strutturale nel deploy: il `Dockerfile` compilava l'applicazione in `/app-src`, ma il runtime girava da `/var/www/html`, popolato solo dal bind mount del sorgente. **L'immagine costruita non veniva mai usata.** L'entrypoint rieseguiva `composer install` e `npm run build` a ogni avvio dentro il container. Su Dokploy, senza sorgente sull'host, significava build a runtime a ogni deploy: lento, dipendente dalla rete, e capace di fallire in produzione. Da qui la ristrutturazione descritta sotto. ### Luglio-agosto 2026 **Punto in cui ci si è fermati (30/07/2026).** Su `develop` è pubblicato tutto: backup completo `.zip`, ripristino, azzeramento, cambio password forzato, barre di avanzamento reali e console di log (commit `f909791`, deploy verificato confrontando l'impronta degli asset). `MAX_UPLOAD_MB=2048` è impostato **solo** su develop; la produzione non è stata toccata e resta sul suo deploy precedente, senza quella variabile. **Il 31/07 è nata la sotto-app "Piantine"** (nuova voce nel menu Amministrazione): KML dell'area città, editor dei poligoni su OpenStreetMap, immagini HD dal container `map-renderer` e PDF sul modulo S-12 con storico versioni. Architettura e agganci sono descritti in [Decisioni architetturali](#le-piantine-sono-una-sotto-app-renderer-esterno-agganci-minimi). Al primo deploy il compose costruisce anche l'immagine del renderer; non servono variabili nuove in Dokploy. **Il 28/08 la sotto-app è stata rifatta e l'interfaccia ripassata.** Le piantine si sono staccate dai territori (una piantina vive anche scollegata, il territorio si crea dall'editor), il disegno è passato su una pagina a schermo intero, la cartolina S-12 è stata reimpaginata (confini sulla prima pagina, piantina al 98% sulla seconda) e la rigenerazione massiva è stata rimossa. In più il sistema visivo è stato ripassato su tutta l'applicazione, non solo qui: vedi [Il sistema visivo sta nei token](#il-sistema-visivo-sta-nei-token-non-nelle-viste). Nello stesso giro è emerso e corretto un guasto d'ambiente che bloccava **tutti** gli upload in sviluppo: vedi [`HTTP_HOST` a nginx deve conservare la porta](#http_host-a-nginx-deve-conservare-la-porta). Il 30/07 sono state fatte due cose. **La suite di test, che prima non esisteva**: 79 test eseguibili con un comando, senza dipendere da altri servizi. Sono **verdi** ma coprono ancora una frazione della logica di business — vedi *Cosa resta aperto*. Non fanno parte dell'immagine di produzione e non girano su un deploy: sono uno strumento locale. **La pagina "Backup e import" è stata riorganizzata**: cinque zone numerate con un indice che ci salta sopra evidenziandole, un solo sistema di pulsanti (con gli stati di focus, che prima non c'erano), e **una sola console** per tutte le operazioni, agganciata in fondo alla finestra, al posto dei cinque riquadri di log sparsi. L'azzeramento è diventato un componente a sé per poter stare in fondo alla pagina. Tutto verificato lato server dai test; **il comportamento nel browser — apertura automatica della console, scorrimento, lampeggio delle zone — non è stato provato**, perché richiede un browser: è la prima cosa da guardare aprendo la pagina. Il ripristino dall'interfaccia resta impraticabile per pacchetti grandi finché non si decide come aggirare Cloudflare: è la prima voce di *Cosa resta aperto* e l'unica che richiede una decisione, non del lavoro. --- ## Dove gira davvero Due ambienti su Dokploy, stesso progetto `TerManager2`, entrambi alimentati dal repository Gitea `francesco/termanager2` su `repository.pyconetwork.it` (il vecchio `git.pyconetwork.it` non è più la sorgente). | Ambiente | Branch | Dominio | Compose (nome / `appName` / `composeId`) | |--------------|--------|-------------------------------------|------------------------------------------| | `production` | `main` | `termanager2.pyconetwork.it` | `termanager2-core-production` / `termanager2-core-vizcxr` / `vh_NtgaPyfQintCbcB3p6` | | `develop` | `dev` | `demo-termanager.pyconetwork.it` | `termanager2-core-demo` / `termanager2-core-vbekis` / `20DoOKciTzmhlPWdcqcxz` | Conseguenze pratiche, tutte imparate sul campo: - **L'autodeploy non parte.** È attivo in Dokploy, ma dal 19 ottobre 2026 nessun push ha avviato un deploy (il webhook di Gitea è da verificare): dopo un push si aspettano un paio di minuti e, se in `deployment` non compare niente di nuovo, si avvia a mano (`compose.deploy` via API, o *Deploy* nell'interfaccia). Controllare prima di avviare, per non fare deploy doppi. - **Test sul server, prima del push.** In locale (Windows) non ci sono PHP, Docker né Node: la suite gira sul server Dokploy con una *schedule* di tipo `dokploy-server` usa e getta, che costruisce lo stage `test` del Dockerfile e lancia anche `node --test tests/js/`. Per provare un commit non ancora pubblicato (il push su `dev` lo pubblicherebbe): `git bundle create x ..dev`, bundle in base64 dentro lo script, `git clone` della checkout di Dokploy in `/tmp` e `git fetch` del bundle. La checkout di Dokploy (`/etc/dokploy/compose//code`) è **shallow** e può essere indietro rispetto a `origin/dev` (i commit di sola documentazione non la aggiornano): il bundle parte dal suo `git log -1`. La schedule gira dentro il container di Dokploy: `docker run -v /tmp/...` non vede quei file, si passano con `tar | docker run -i`. - **Il branch decide l'ambiente.** Pubblicare su `dev` non tocca la produzione, che segue `main`. È la separazione su cui contare quando si vuole provare qualcosa senza rischi. - **Un "Rebuild deployment" NON scarica il codice nuovo**: ricostruisce il checkout già presente e ci mette una ventina di secondi. Per prendere l'ultimo commit serve un deploy vero (`compose.deploy` via API, o *Deploy* nell'interfaccia). Un rebuild che finisce troppo in fretta è il segnale che si sta ricostruendo il codice di prima. - **Le variabili d'ambiente stanno in Dokploy, non nel repository.** Il `.env` dell'ambiente lo genera l'interfaccia: una variabile aggiunta a `.env.example` non arriva da sola sui deployment, va aggiunta a mano lì. È successo con `MAX_UPLOAD_MB`, presente in develop e — deliberatamente — non in produzione. - **Verifica che il codice servito sia quello giusto** confrontando l'impronta degli asset: `public/build/assets/app-*.css` e `-*.js` hanno il nome derivato dal contenuto, quindi se coincide con quello della propria build, il frontend in linea è lo stesso sorgente. È il controllo più rapido dopo un deploy, e non richiede di autenticarsi. --- ## Decisioni architetturali Le scelte non ovvie, con il motivo. Se una di queste ti sembra sbagliata, il contesto per ridiscuterla è qui. ### L'immagine è autosufficiente `vendor/` e `public/build` sono compilati in stage separati del `Dockerfile` e copiati nell'immagine finale. I container di produzione **non montano il sorgente** e non eseguono build all'avvio. Conseguenza pratica: dopo aver modificato dipendenze PHP o asset frontend, serve un rebuild dell'immagine, non un semplice restart. ### nginx e php-fpm nello stesso container Con container separati, nginx avrebbe bisogno di una copia di `public/` e del volume storage solo per servire file statici. Per questa scala è complessità senza beneficio. Sono coordinati da supervisor (`docker/supervisor/supervisord.conf`), che abbatte il container se uno dei due muore definitivamente — altrimenti resterebbe "up" senza servire nulla. ### La configurazione arriva dall'ambiente, non da `.env` riscritto Il vecchio entrypoint riscriveva `.env` con `sed` a ogni avvio. Ora Laravel legge direttamente l'ambiente di processo, e `docker-compose.yml` si limita a `env_file: .env` senza ridichiarare nulla. Il `.env` è quindi l'**unica** fonte di configurazione. Una versione precedente fissava nel compose i valori dettati dalla topologia (`DB_HOST: mariadb` e simili) perché vincessero su un `.env` sbagliato, ma richiedeva gli anchor YAML (`x-app-env`, `<<:`) ed è stata scartata a favore della leggibilità. Il rovescio della medaglia: `DB_HOST` e `REDIS_HOST` devono valere `mariadb` e `redis`, cioè i nomi dei servizi. Se qualcuno vi mette un indirizzo IP il container non trova più il database. È documentato in `.env.example` e nel README, ma è il punto fragile di questa scelta. Nota: perché la configurazione da ambiente funzioni, `www.conf` ha `clear_env = no`. Senza, php-fpm sanifica l'ambiente e Laravel non vedrebbe nessuna variabile. ### Fail-fast sulle variabili mancanti Lo stack si rifiuta di partire senza `APP_URL`, `DB_PASSWORD`, `DB_ROOT_PASSWORD`, `REDIS_PASSWORD`. Le password sono validate dall'interpolazione compose (`${VAR:?}`), `APP_URL` dall'entrypoint (dove il messaggio d'errore è più chiaro). Deliberato: un errore immediato è meglio di un database in produzione con password `secret`. ### Le piantine sono una sotto-app: renderer esterno, agganci minimi Le **Piantine** (solo amministratore) generano le mappe dei territori. Si carica il KML dell'area della città, si disegnano i confini su OpenStreetMap (Leaflet) nell'editor a schermo intero, e da ogni disegno si ottiene un'immagine ad alta definizione e — a scelta — la cartolina sul modulo ufficiale S-12 (`resources/pdf/S-12_I.pdf`, importato con FPDI) che sostituisce il PDF del territorio. Il PDF precedente finisce nella tabella `territorio_pdf_versioni` ed è ripristinabile dalla pagina di gestione. Il rendering vero e proprio **non sta nell'applicazione**: lo fa il container `map-renderer` (`docker/renderer/`, Node + sharp), che scarica le tessere OSM (cache persistente nel volume `tile_cache`, User-Agent identificante, attribuzione impressa sull'immagine come da licenza), le cuce, disegna il confine e attenua l'esterno. L'app gli parla solo via HTTP sulla rete interna (`config/piantine.php`, default `http://map-renderer:3000`: nessuna variabile da aggiungere in Dokploy). Se il container è giù, l'unica cosa che smette di funzionare è la generazione delle immagini; il resto del gestionale non lo sa nemmeno. Gli agganci al core sono deliberatamente pochi: la rotta nel gruppo `settings.manage`, la voce di menu, e l'aggiornamento di `pdf_path`/`thumbnail_path` sul territorio quando si sostituisce un PDF (stesso percorso `territori-pdf/` + `TerritorioThumbnailService` dell'upload manuale). Le geometrie vivono nella tabella separata `territorio_mappe`, l'area KML in `storage/app/piantine/`: rimuovere la sotto-app significa togliere questi pezzi, non disfare il gestionale. **Il disegno viene prima del numero.** Una piantina non ha bisogno di un territorio: `territorio_mappe.territorio_id` è nullable e il collegamento si fa (e si disfa) quando si vuole, con `nome` come etichetta finché manca. Si taglia l'area guardando le strade e solo dopo si decide di chi è — e se quel territorio non esiste, lo si crea dall'editor col solo numero. La chiave esterna è `nullOnDelete`, non più `cascadeOnDelete`: cancellare un territorio, o svuotare `territori` come fa ogni import XML, non porta più via i disegni. **Due pagine, non una.** `/piantine` è il quadro d'insieme: stato di ogni piantina con ricerca e filtri (tutte / bozze / da pubblicare / pubblicate / scollegate), area KML e storico dei PDF sostituiti (paginato). Da lì si apre, si pubblica e si elimina. `/piantine/editor` è l'editor a schermo intero, con un telaio suo (`layouts/editor`) senza barra laterale: tagliare un confine su una mappa larga un terzo di schermo vuol dire sbagliarlo. Elenco e pannello galleggiano sopra la mappa; barra strumenti e controlli Leaflet si spostano nello spazio libero (variabili `--libero-sx`/`--libero-dx`); sotto i 720px il pannello sale dal basso. Su tablet i vertici sono più grandi (`pointer: coarse`). **Bozza e pubblicazione (ottobre 2026).** Nell'editor tutto si salva da solo: il confine a ogni disegno o spostamento di vertice, nome e collegamento appena cambiano. È bozza: il PDF del territorio non si tocca. I dati del territorio (numero, zona, tipologia, confini) sono invece dati del gestionale e si salvano subito, colonna per colonna (un campo non valido non trascina gli altri). Il PDF cambia solo con **Pubblica**, uguale in editor e gestione (`Livewire\Piantine\Pubblicazione`): `PubblicazionePiantina::avvia()` mette in coda `PreparaAnteprimaPiantina` (il primo rendering può superare i 100 s di Cloudflare), che genera immagine e PDF sul disco **privato** (`storage/app/piantine-anteprime/`, stato in cache sotto un token di 40 caratteri, servito da `piantine.anteprima`); la finestra controlla ogni 2 s e mostra il PDF; solo **Conferma** lo rende ufficiale. Se nel frattempo è cambiato qualcosa di stampato, la conferma rifiuta. Gli stati (`TerritorioMappa::stato()`): **Bozza** (mai pubblicata), **Pubblicata**, **Modifiche da pubblicare**. Il confronto è sull'`impronta()`: sha256 di confine, territorio, numero, nome della zona e confini — cambia uno qualunque e la piantina torna da pubblicare anche col disegno identico. Vale "Pubblicata" solo se anche il PDF in uso è ancora uno composto da una piantina (`territori-pdf/piantina-{territorio}-…`): un ripristino dallo storico, un upload a mano o un import la riportano "da pubblicare". "Ripristina il confine pubblicato" riporta la bozza a `geojson_pubblicato`. La migrazione `2026_10_09_000010` ha segnato pubblicate le piantine esistenti solo se il PDF in vigore del territorio veniva da una piantina. Disegnare crea **sempre** una piantina nuova; per cambiare quella aperta ci sono "Modifica vertici" e "Ridisegna confine", espliciti. Con la mappa si parla per eventi: i dati di tutte le piantine li chiede il JS una volta (`datiMappa()`), poi arriva solo la piantina cambiata (`piantina-aggiornata`). Gli avvisi passano dall'evento `avviso` (trait `Livewire\Concerns\Avvisa`, componente ``): i flash di sessione nel telaio non si vedono dopo un'azione Livewire. **La cartolina e la piantina sono due pagine distinte.** Il riquadro dell'S-12 è largo sette centimetri: una mappa di quartiere lì dentro non si legge. Quindi pagina 1 è il modulo con Località, numero e i **confini scritti** nello spazio centrale (il corpo del testo si restringe da solo finché ci sta), pagina 2 è la piantina sola al 98% della pagina. **La "Località" del modulo è il nome della zona.** Era un campo globale, poi un campo della piantina, e in entrambi i casi era un doppione: la zona esiste già, dice la stessa cosa («Palermo Montepellegrino») ed è quella che si aggiorna quando la congregazione riorganizza il lavoro. Due posti dove scrivere lo stesso nome divergono prima o poi, e sulla carta finisce quello sbagliato. L'elenco marca i territori collegati senza zona: senza, l'intestazione della cartolina esce vuota e ce se ne accorge in stampa. **L'immagine è JPEG, sovracampionata e nella forma della pagina.** Tre scelte che vanno lette insieme (`config/piantine.php`, `docker/renderer/server.js`): - Il renderer compone alle tessere dello zoom più alto che entri in `max_side × 2` e poi riduce con Lanczos. Le etichette OSM sono disegnate dentro la tessera a dimensione fissa: salire di uno zoom le rende più definite, e ridurre dopo porta quella nitidezza dentro l'immagine finale. - Chiede al renderer le **proporzioni della pagina** (`aspetto`): un territorio quasi quadrato su una cartolina orizzontale, tenendo le sue proporzioni, lascerebbe due fasce bianche larghe un quinto di foglio. Allargando il ritaglio si mostrano più dintorni invece di carta vuota. - JPEG a qualità 86 invece di PNG: 0,9 MB invece di 5 per territorio. Con 274 territori è la differenza fra qualche centinaio di MB e diversi GB. L'attribuzione OSM si dimensiona sull'immagine finale, non su una misura fissa: 22 px su 3400 sarebbero meno di un millimetro stampato, cioè presenti nel file ma invisibili a chi tiene la cartolina — e la ODbL la vuole leggibile. Per lo stesso motivo il tratto del confine è espresso in pixel dell'immagine finale e riportato alla scala di composizione: deve dire dove passa il confine senza cancellare la via che ci corre sotto, che è proprio quella che serve leggere. ### Il sistema visivo sta nei token, non nelle viste `resources/css/app.css` **ridefinisce le scale `gray` e `indigo` di Tailwind** dentro `@theme`. È la cosa che sorprende di più aprendo il file, ed è deliberata: le trentasette viste sono scritte con le utility (`text-gray-600`, `bg-indigo-50`), e cambiare la scala le riallinea tutte insieme. L'alternativa — riscrivere le classi vista per vista — a ogni file dimenticato lascia in giro il grigio di prima accanto a quello nuovo, e nessuno se ne accorge finché non apre proprio quella pagina. Da qui tre conseguenze che vanno sapute prima di metterci mano: - **I grigi sono caldi.** Quelli di serie di Tailwind tirano al blu e, sommati a un accento indaco, davano all'interfaccia una dominante fredda. Questi elenchi diventano moduli di carta che passano di mano: un fondo caldo li avvicina a quello che sono. Non mescolare grigi freddi qui dentro. - **L'accento è uno.** Indaco = azione, verde = fatto, ambra = in sospeso, rosso = distrugge dati. Se una cosa non rientra in queste quattro, è grigia. Prima le tinte erano cinque e decorative. - **Il carattere è servito dall'applicazione** (`@fontsource-variable/figtree`, dipendenza npm), non da Google Fonts. Un gestionale che tiene nomi e indirizzi di persone non deve chiamare un dominio di terze parti a ogni pagina caricata, e così funziona anche senza rete. I componenti `tm-*` (pulsanti, console, card, campi, elenchi, editor) stanno tutti qui e **fuori da `@layer`**, quindi vincono sulle utility: un pulsante non si può ritoccare a metà con le classi. Chi aggiunge una schermata usa questi, non catene di utility nuove. ### `HTTP_HOST` a nginx deve conservare la porta `docker/nginx/default.conf` rimette `fastcgi_param HTTP_HOST $http_host;` dopo l'`include fastcgi_params`. Non e' ridondanza: dalla 1.26 il `fastcgi_params` di sistema usa `$host`, che la porta la butta via. Con `APP_URL` su porta non standard — cioe' lo sviluppo locale su `:8090` — Laravel ricostruisce l'URL della richiesta senza porta mentre `URL::forceRootUrl()` genera i link con, e ogni URL firmato non valida piu': **tutti** gli upload di file rispondono 401, perche' l'endpoint di Livewire aborta sulla firma. In produzione `APP_URL` non ha porta e le due forme coincidono, quindi il guasto si vede solo in locale. Inoltrare l'header grezzo e' sicuro perche' `trustHosts()` in `bootstrap/app.php` rifiuta gia' gli Host che non siano quello di `APP_URL`, `localhost` o `127.0.0.1`. ### Modifica/cancellazione delle assegnazioni: solo amministratore L'unico punto in cui un'assegnazione **esistente** si modifica o si cancella è il CRUD del Registro (`Livewire/Registro`: `openCreate`/`openEdit`/`save`/ `askDelete`/`deleteConfirmed`), blindato su `settings.manage` a due livelli — `abort_if(..., 403)` nel componente e `@can('settings.manage')` in `registro.blade.php`, che nasconde pulsanti e modali. `settings.manage` ce l'ha solo l'`amministratore`. Di conseguenza gli altri ruoli **non** possono alterare le assegnazioni: la pagina Assegna solo ne crea (`territori.assign`), la pagina Rientra solo le chiude (`territori.return`). Nello specifico l'`assistente` (`registro.view` + `territori.assign` + `territori.return`) vede il Registro, crea nuove assegnazioni e le fa rientrare, ma non le modifica né le elimina. Poiché il seeder concede in modo additivo e non revoca mai (vedi la nota su `syncPermissions()` più sotto), un permesso `settings.manage` concesso a mano all'`assistente` in passato sopravviverebbe a ogni re-seed. La migration `2026_07_25_000001_revoke_settings_manage_from_assistente_role` chiude questo drift per i database esistenti: revoca `settings.manage` dal ruolo `assistente` se presente. È idempotente (no-op sul baseline) e volutamente irreversibile — il `down()` non ripristina il permesso. Stesso principio per le **campagne**: creazione e visualizzazione restano su `campagne.manage` (che ha anche l'assistente), ma **modifica ed eliminazione sono riservate all'amministratore** (`settings.manage`). Il gate è su tre livelli: la route `campagne/{campagna}/edit` è nel gruppo `settings.manage`; `CampagnaEdit::mount()`/`save()` e `CampagnaIndex::deleteCampagna()` chiamano `$this->authorize('settings.manage')` (l'index è raggiungibile da chi ha `campagne.manage`, quindi il delete va protetto nel metodo, non solo in route); i pulsanti Modifica/Elimina in `campagna-index`/`campagna-show` sono sotto `@can('settings.manage')`. Nota: `Campagna` non ha soft delete — l'eliminazione è definitiva. Per i **territori** vale un modello leggermente diverso, perché la visualizzazione va aperta a tutti gli operativi: lista (`territori.index`) e dettaglio (`territori.show`) sono ora su `territori.assign` (che hanno admin, assistente e operatore); creazione/modifica/cestino restano su `territori.manage` (solo admin). Attenzione a due punti: - **Ordine delle rotte.** Le rotte letterali `territori/create` e `territori/cestino` devono restare registrate PRIMA del wildcard `territori/{territorio}`, altrimenti verrebbero catturate dalla rotta di dettaglio. - **`TerritorioIndex` perde la copertura del middleware persistente.** Il suo componente è ora servito da una rotta rilassata (`territori.assign`), quindi i suoi metodi di mutazione (`toggleActive`, `togglePriority`, `deleteTerritorio`) NON sono più protetti dal middleware di route e hanno un `$this->authorize('territori.manage')` interno — senza, un operativo potrebbe invocarli via `/livewire/update` col pulsante nascosto. Per difesa in profondità lo stesso check è stato aggiunto anche a `TerritorioCreate::save`, `TerritorioEdit::save`/`removePdf`, `TerritorioCestino::restore`/`forceDelete` (che restano comunque su rotte `territori.manage`). I pulsanti Modifica/toggle/Elimina/Nuovo/Cestino in `territorio-index`/`territorio-show` sono sotto `@can('territori.manage')`; il link "Dettaglio" resta visibile a tutti. Il menu laterale mostra "Territori" a chi ha `territori.assign`. ### Sola lettura per proclamatori e campagne (non-admin) Stessa impostazione dei territori estesa ad altre due sezioni: - **Proclamatori**: `index` e `show` restano su `proclamatori.manage` (l'assistente li vede in sola lettura); `create`/`edit`/`cestino` e tutte le mutazioni (`ProclamatoreIndex::toggleActive`/`deleteProclamatore`/`anonimizza`, `ProclamatoreCreate::save`, `ProclamatoreEdit::save`, `ProclamatoreCestino::restore`/`forceDelete`) richiedono `settings.manage`. `ProclamatoreIndex` è servito da una rotta rilassata, quindi i suoi metodi di mutazione hanno il check interno; i pulsanti in `proclamatore-index`/`-show`/ `-cestino` sono sotto `@can('settings.manage')`. Le rotte letterali create/cestino restano prima del wildcard `{proclamatore}`. - **Campagne**: la **creazione** è ora admin-only come già modifica/eliminazione — `CampagnaCreate::save` chiama `authorize('settings.manage')`, la rotta `campagne/create` è nel gruppo `settings.manage` (registrata prima del wildcard) e il pulsante "Nuova Campagna" è sotto `@can('settings.manage')`. `index`/`show` restano su `campagne.manage` (sola lettura per l'assistente). ### Tabelle-elenco responsive su mobile (portrait) Le liste principali usano una sola "politica" CSS invece di layout duplicati: la classe `table-cards` (in `resources/css/app.css`) sotto `640px` nasconde il `thead` e trasforma ogni riga in una scheda, con ogni cella resa come "ETICHETTA … valore" (l'etichetta viene dall'attributo `data-label` della ``). Un telefono in portrait sta sotto la soglia → schede; ruotato in landscape la larghezza supera i 640px → torna la tabella normale (per questo landscape "non ha problemi"). Convenzioni: ogni `` dati ha `data-label="..."`; la cella azioni ha classe `cell-actions` (niente label, occupa la riga a piena larghezza); le celle `colspan` (stato vuoto, form di modifica utente inline) restano `block` a piena larghezza. Applicata a tutte le liste e sottopagine con tabelle: territori, proclamatori, campagne, registro, utenti, audit-log, i due cestini, le tabelle "storico assegnazioni" di territorio-show/proclamatore-show, "territori conteggiati" di campagna-show e le due tabelle di esito import in xml-exchange (una a classi Tailwind, una a stili inline — `border:none !important` nella regola gestisce anche i bordi inline). La pagina *Assegnazioni* era già ottimizzata. ### Scadenza link PDF unificata con la soglia rientro La "Validità link PDF (mesi)" è stata rimossa: il link condivisibile ora scade esattamente quando l'assegnazione raggiunge la **soglia rientro** (`giorni_per_smarrito`), cioè `assigned_at + giorni_per_smarrito` — la stessa data di `Assegnazione::data_consegna_presunta` e del chip "Scadenza" nel viewer. `AssignmentPdfController::linkScaduto` e `ShortPdfLinkController` calcolano ora `addDays(giorni_per_smarrito)` invece di `addMonths(ttl)`; la scadenza vale solo per i non autenticati e il link muore comunque al rientro (`is_aperta`). Rimossi il campo Impostazioni e la proprietà `assignment_link_ttl_months` in `SettingsEdit`. **La colonna `assignment_link_ttl_hours` resta nel DB** (niente migration distruttiva): è ormai vestigiale per la logica ma l'export/import XML continua a leggerla/scriverla senza effetti. ### Ricerca rapida nella lista link (pagina Assegna) La sezione "Territori Assegnati" (i link PDF) ha un unico campo che filtra per numero territorio, zona e proclamatore. Il filtro è **in memoria** (proprietà `linkSearch`, collection `assegnazioniAperteVisibili`) perché nome/cognome del proclamatore sono cifrati e non filtrabili via SQL — stesso approccio del Registro. La sezione resta visibile anche a risultato vuoto (mostra "Nessun risultato"), perché l'`@if` esterno guarda la lista non filtrata. ### Assegnare un territorio ne azzera il flag "prioritario" `prioritario` è un flag **manuale**; `is_prioritario` è true se il flag è acceso *oppure* se la giacenza supera la soglia — ma la parte a soglia vale solo per i territori *in reparto* (`scopePrioritari`/`getIsPrioritarioAttribute` filtrano su `inReparto`). Quindi un territorio assegnato può risultare prioritario **solo** per via del flag manuale. Regola: alla creazione di un'assegnazione **aperta** il flag viene spento. È implementata come evento `Assegnazione::created` (in `booted()`), guardato su `returned_at === null` e `prioritario === true`, così copre ogni via di creazione (pagina Assegna, CRUD del Registro, import XML) senza duplicare la logica. Interazione con l'import XML: per i backup creati dopo questa regola è un no-op (nessun territorio assegnato è prioritario); su backup vecchi con stato contraddittorio l'import normalizza il flag anziché riprodurlo tale e quale. ### Profilo utente, viewer PDF, privacy admin-only Tre ritocchi minori ma con qualche implicazione: - **Pagina profilo** (`Profile` → rotta `profilo`, nome `profile`) accessibile a ogni utente loggato (nel gruppo `auth`, nessun permesso): l'utente corrente può modificare il proprio nome/cognome ed email (`updateProfile`) e cambiare la password (`updatePassword`, con verifica della password attuale via regola `current_password`; il cast `hashed` cifra al salvataggio). Dopo il salvataggio dei dati `updateProfile` fa `redirect(navigate:true)` sulla stessa pagina, così header (nel layout, fuori dal componente) e card mostrano subito i nuovi valori. Il link al profilo è nell'header su desktop e, su mobile, in fondo alla sidebar (`lg:hidden`, dopo un separatore) — sull'header è `hidden sm:flex`. Non esiste un campo "username" né "cognome" separato: `name` è il nome completo (etichettato "Nome e cognome") e l'email fa da identificativo. La qualifica (ruolo) non è modificabile dal profilo — resta in gestione all'admin. - **Viewer PDF pubblico**: oltre a territorio/proclamatore/data mostra ora *giorni assegnato*, *consegna prevista* e *scadenza*. Sono attributi calcolati su `Assegnazione` (`data_consegna_presunta`, `giorni_alla_scadenza`) basati sulla soglia `giorni_per_smarrito` — la stessa oltre cui `Territorio::stato` diventa `da_rientrare`. Il viewer è servito solo per assegnazioni aperte, ma gli accessor gestiscono comunque il caso `returned_at` (ritornano null). - **Privacy solo admin**: la rotta `privacy` è passata dal solo `auth` al gruppo `permission:settings.manage` e il link in sidebar è sotto `@can('settings.manage')`. ### Backup completo `.zip`, ripristino, azzeramento L'export XML da solo non ricostruisce un'installazione: `pdf_path`, `thumbnail_path` e `logo_path` sono percorsi sul disco `public`, quindi un ripristino su volumi vuoti lascia ogni territorio che punta a un file inesistente — link pubblici a 404 e miniature rotte. Il pacchetto `.zip` (`Services/BackupArchive`, `Http/Controllers/Settings/BackupController`) mette insieme `manifest.json`, `data.xml` (lo stesso XML dell'export) e `storage/…` con **tutti** i file del disco `public`. L'export XML resta, etichettato come parziale. Scelte non ovvie: - **Rotte HTTP, non Livewire.** Lo `streamDownload` di Livewire passa il file base64 dentro la risposta JSON: un archivio con i PDF dei territori non ci sta. `backup/file/{op}` e `backup/restore` sono due rotte normali nel gruppo `settings.manage`. Per lo stesso motivo `ZipArchive::addFile()` (che legge dal disco in `close()`) e gli stream in estrazione: nessun PDF passa intero per la memoria del processo. - **Tutto in coda, con avanzamento reale.** Backup, ripristino e azzeramento sono job (`Jobs/CreateBackupArchive`, `RestoreBackupArchive`, `ResetApplication`) che scrivono su `Services/BackupOperationState`, e `Livewire/Settings/BackupManager` lo interroga con `wire:poll`. In coda perché un'installazione con qualche centinaio di PDF supera i 300 secondi di `fastcgi_read_timeout` e il browser vedrebbe cadere la connessione a metà compressione, senza modo di distinguerlo da un errore. La barra conta unità di lavoro completate, non tempo. Per la compressione questo costa qualcosa: `ZipArchive` non scrive niente finché non si chiama `close()`, quindi contare le `addFile()` porterebbe al 100% in un istante per poi restare fermo per tutta la scrittura. `BackupArchive::create()` chiude e riapre l'archivio a lotti (`FLUSH_MASSIMI = 20`): si paga una ricopiatura delle entry già presenti — byte a byte, senza ricomprimerle — e in cambio ogni avanzamento corrisponde a byte davvero finiti sul disco. Il lotto è `totale/20`, così la ricopiatura resta limitata a ~10 volte la dimensione dell'archivio quanti che siano i file. Estrazione e riscrittura dei file sono cicli nostri, lì l'avanzamento è per-file senza artifici. - **L'azzeramento ha due tempi, separati dal download.** Il pulsante nella zona pericolosa (`avviaAzzeramento`) crea *solo* il backup e si ferma in `attesa-download`; la cancellazione parte da un secondo clic esplicito (`confermaAzzeramento`), che rifiuta se lo stato non registra un `servito_at` e se non riceve la password dell'amministratore. Il primo tentativo faceva partire il reset dalla coda dello `streamDownload`, "dopo l'ultimo byte" — **non funziona**: con `fastcgi_buffering on` (il default, e `docker/nginx/default.conf` non lo disattiva) nginx accetta l'intera risposta dal processo PHP, che quindi prosegue anche se il browser ha chiuso la connessione al primo byte. Un download annullato azzerava lo stesso. Il server può verificare di aver *spedito* l'archivio, non che sia arrivato: quella verifica è dell'operatore, e per questo la conferma è umana. - **La password si richiede al secondo clic, e non passa dallo snapshot.** La sessione è già autenticata, quindi la password non serve a stabilire *chi* sia: serve a stabilire che davanti allo schermo ci sia ancora quella persona — una scheda lasciata aperta su una postazione condivisa è lo scenario contro cui protegge. Viaggia come **parametro** di `confermaAzzeramento($password)`, non come proprietà `wire:model`: le proprietà pubbliche di Livewire vengono serializzate nello snapshot e rispedite al browser a ogni risposta, e una password non ha motivo di fare quel viaggio di ritorno. Attenzione al dettaglio che costa un pomeriggio: la proprietà `$passwordConferma` **esiste comunque, e resta sempre vuota**. Livewire scarta dalla risposta ogni errore la cui chiave non corrisponda a una proprietà del componente (`SupportValidation::dehydrate()` filtra su `Utils::hasProperty`), quindi senza quella riga `addError('passwordConferma', …)` sparisce in silenzio: il pulsante sembra non fare nulla, mentre il controllo sta funzionando. Non collegarla al campo con `wire:model`, o la password torna nello snapshot. Cinque tentativi sbagliati in 5 minuti bloccano l'azione (`RateLimiter`, chiave per utente). Senza, la richiesta di password su una sessione dirottata sarebbe solo un rallentamento. Il blocco è sull'operazione, non sull'account: nessuno resta chiuso fuori dall'applicazione. - **Una sola operazione alla volta, con blocco che si autoripara.** Backup, ripristino e azzeramento lavorano tutti sullo stesso database e sullo stesso disco: due in parallelo — due schede, due amministratori — non si rallentano soltanto, si sovrascrivono. `BackupOperationState::corrente()` fa da posto unico; lo controllano sia il componente Livewire sia `BackupController::upload()`, che sono due porte d'ingresso separate (la seconda risponde 409). Il blocco non è eterno: ha un TTL di un'ora, e `corrente()` lo considera libero se l'operazione puntata non esiste più o è terminata. In più i tre job hanno un `failed()` — Laravel lo chiama quando il worker uccide il job per timeout o errore fatale, cioè proprio i casi che `handle()` non può intercettare — che chiude l'operazione e libera il posto invece di lasciare una barra ferma per un'ora. - **La pagina si riaggancia all'operazione in corso.** `BackupManager::mount()` legge `corrente()`. Senza, ricaricare la pagina durante un backup lungo faceva sparire la barra, e — più grave — un azzeramento fermo in attesa di conferma diventava irraggiungibile: nessuno poteva più né confermarlo né annullarlo, e il posto restava occupato fino alla scadenza. - **L'esito del ripristino si legge senza consumarlo.** Il job non ha una sessione in cui lasciare un flash, quindi deposita il messaggio in cache a nome di chi ha avviato il ripristino e la schermata di cambio password lo mostra. Deve essere un `Cache::get` + `forget` a password cambiata, **non** un `pull`: quando è il middleware a dirottare una richiesta di Livewire, il client segue il 302 via `fetch` — ed è quella `fetch` a bruciare il messaggio — per poi rifare la stessa GET con `window.location`, che troverebbe la cache già vuota. Con il `pull` l'amministratore non vedeva **mai** il riepilogo del proprio ripristino. - **Il tetto degli upload è una variabile sola, `MAX_UPLOAD_MB`.** Prima viveva in tre posti scollegati — `client_max_body_size` in `docker/nginx/default.conf`, `upload_max_filesize`/`post_max_size` in `docker/php/php.ini`, e la regola `max:` nella validazione — e bastava che uno restasse indietro perché il più piccolo vincesse nel modo peggiore. Adesso `entrypoint.sh` genera i primi due (`conf.d/upload-limit.conf` e `conf.d/zz-upload-limit.ini`) e `config/app.php` alimenta la terza. **Non rimettere `client_max_body_size` nel blocco `server` di `default.conf`**: una direttiva lì dentro vince su quella generata a livello http e reintroduce in silenzio proprio il disallineamento che questa disposizione esiste per evitare. La validazione tiene un 2% di margine sotto il valore di nginx, così a fermare un pacchetto fuori misura è Laravel, che sa spiegarsi, e non nginx. Il sintomo, quando il limite viene superato, non assomiglia affatto a un errore di dimensione: nginx risponde **413 dopo aver accettato zero byte** e chiude. Il browser ha appena iniziato a spedire, la barra si pianta a una percentuale bassa e nessun evento utile arriva all'`XMLHttpRequest` — pagina muta, con l'aria di essersi bloccata. Da qui i tre presidi nella vista: controllo della dimensione *prima* di caricare, `xhr.timeout` con i relativi gestori di `timeout`/`abort`/`error` (senza, un caricamento fermo non produce più nulla per sempre), e il codice HTTP dentro il messaggio, perché 413 e 419 non hanno un corpo JSON da cui ricavare una spiegazione. - **La console di log non è un vezzo diagnostico.** Quasi tutti i modi in cui un caricamento muore sono muti: Cloudflare o nginx chiudono la connessione e nessun evento del browser porta con sé una spiegazione. Il pannello *Console* nella scheda di ripristino registra file scelto e dimensione, limite del server, avanzamento ogni 10%, codice HTTP della risposta, errori, timeout e interruzioni; sotto, i log lato server dell'operazione. Un battito ogni 15 secondi scrive «nessun avanzamento da N s», che è l'unico modo di distinguere *lento* da *fermo*. Il pulsante *Copia tutto* esiste perché il primo passo di ogni diagnosi è farsi mandare quel testo. - **Nell'azzeramento i file si cancellano prima del database.** Svuotare il disco è l'unico passo che può fallire per cause esterne (permessi sul volume), e fallire lì non ha ancora toccato niente. Nell'ordine inverso un errore sui file lascerebbe database azzerato e disco pieno di PDF orfani. Collegato: `svuotaDiscoPubblico()` ricontrolla il disco dopo la cancellazione e solleva se qualcosa sopravvive, invece di restituire il conteggio iniziale. Flysystem non solleva se una `unlink` fallisce, e basta un file scritto da un processo con un altro utente (l'entrypoint lavora da root, php-fpm e il worker da www-data) perché l'operazione si dichiari riuscita lasciando il disco popolato. - **L'archivio si controlla prima di consegnarlo.** Un backup è l'unico file di cui non ci si accorge che era rotto finché non serve, quindi `BackupArchive::create()` non si fida di aver scritto bene: controlla il valore di ritorno di ogni `addFile()` (che torna `false`, senza sollevare, se il file è sparito o è illeggibile — l'archivio finirebbe con un buco silenzioso), e alla fine riapre l'archivio e verifica che contenga `data.xml`, `manifest.json` e *esattamente* i file attesi. Se qualcosa non torna, l'archivio viene cancellato e l'operazione fallisce: meglio nessun backup che un backup che sembra buono. Attenzione a una trappola di `ZipArchive`: dopo un `close()` fallito l'oggetto resta inutilizzabile e ogni metodo successivo solleva `Invalid or uninitialized Zip object`. Una chiusura di cortesia dentro un `catch` sostituiva il messaggio vero con quello, e l'amministratore leggeva una stringa incomprensibile al posto di «permesso negato su questo file». Da qui `chiudi()`, che cattura `getStatusString()` prima che vada perso, e i `close()` di pulizia avvolti in un try/catch che non può mascherare l'errore originale. - **Eliminare definitivamente un territorio porta via anche i suoi file.** `TerritorioCestino::forceDelete()` cancellava la riga e lasciava mappa e miniatura sul volume: invisibili in ogni schermata, non più raggiungibili da nessuna cancellazione, e dentro ogni backup successivo. I file si rimuovono *prima* della riga, così se la cancellazione fallisce il territorio resta nel cestino e l'operazione si può ritentare. - **L'azzeramento tiene in vita l'amministratore che l'ha chiesto.** Un'installazione appena creata ha un amministratore; cancellarli tutti lascerebbe l'applicazione senza nessuno che possa accedere fino al riavvio del container (l'admin iniziale lo ricrea `entrypoint.sh` da `INITIAL_ADMIN_*`, che in esecuzione possono non esserci). Gli altri utenti si eliminano uno alla volta via Eloquent, non con un delete di massa: è il trait `HasRoles` di Spatie a staccare ruoli e permessi nell'evento `deleting`, che un delete di massa non fa scattare. Il registro attività si svuota **per ultimo** — quelle cancellazioni scrivono righe nuove — e subito dopo si scrive l'unica riga che sopravvive, quella dell'azzeramento stesso. - **Ordine del restore: verifica → una transazione → pulizia.** Dal 12/10/2026 (`RestoreBackupArchive`): si estrae e si verifica tutto (CRC, byte, il `piantine.json` del formato 2) prima di toccare qualcosa; poi una sola `DB::transaction` contiene import XML, tabelle delle piantine, blocco degli account e, per ultimo, lo scambio dei file (`BackupArchive::scambiaFile()`: solo `rename()` sullo stesso volume, annotati e annullabili). Se qualcosa fallisce si torna allo stato di prima; i file vecchi aspettano in `storage/app/backup-precedenti/` e si cancellano solo dopo il commit. Il disco `public` viene sostituito, non fuso: i percorsi vivono nelle righe appena riscritte. - **Limiti sull'archivio in ingresso.** Un `.zip` è compresso: senza tetti su numero di entry, dimensione della singola entry e totale decompresso, pochi MB possono riempire il volume (zip bomb). I nomi delle entry sono normalizzati e ogni `..` o percorso assoluto viene rifiutato (zip slip) — senza, un archivio ostile scriverebbe fuori dalla cartella di destinazione. - **Dopo un restore tutti cambiano password.** Il pacchetto contiene gli hash bcrypt di ogni utente: chi lo ha avuto in mano ha potuto tentarne il crack offline, quindi da lì in poi nessuna vecchia password è più un segreto. Il restore accende `password_change_required` su **tutte** le righe di `users` (amministratore che sta ripristinando compreso) e azzera i `remember_token`, che sono credenziali persistenti e stanno pure loro nel backup. Il middleware `RequirePasswordChange` (in coda al gruppo `web`, quindi copre anche `/livewire/update` — Livewire segue le risposte redirezionate) dirotta su `password.change` tutto tranne quella pagina, il suo invio e il logout. - **La schermata di cambio password non è Livewire e non chiede la password attuale.** Non è Livewire perché deve restare raggiungibile mentre il middleware respinge anche le POST di Livewire, e distinguere quale componente sta dietro una `/livewire/update` è fragile; due rotte HTTP si escludono per nome. Non chiede la password attuale perché il restore ha appena sovrascritto gli hash con quelli del backup: la "password attuale" di un account è quella dell'epoca del backup, che l'utente — l'amministratore per primo — può benissimo non ricordare. La garanzia è la sessione: a quella pagina ci si arriva già autenticati. ### Export/Import XML: backup completo e round-trip `Livewire/Settings/XmlExchange` esporta e reimporta **tutti** i dati gestionali, non più un sottoinsieme. L'export (`currentDataset` + `datasetToXml`) include ora: utenti (con hash password, ruoli, `email_verified_at`, `remember_token`), i campi settings prima omessi (`public_base_url`, `logo_path`, `pdf_viewer_show_download`, `setup_completed`), lo stato soft-delete (`deleted_at`) di proclamatori/territori, i path file dei territori (`pdf_path`, `thumbnail_path`), le FK di audit delle assegnazioni (`created_by`/`returned_by`, esportate come `legacy_*_id`), `link_sent`, `pdf_access_code`, e i timestamp `created_at`/`updated_at` di ogni entità. L'import (`importXmlFromContent`) legge simmetricamente tutti questi campi, così un export si reimporta senza perdite. Tre scelte non ovvie: - **`legacy_id` derivato dall'`id` reale.** Il rimappaggio delle FK in import si basa sull'attributo `legacy_id`. Prima veniva scritto solo dalla conversione SQL legacy: l'export dell'app corrente ne era privo, quindi un suo re-import **perdeva territori e assegnazioni** (riferimenti non risolti). Ora `addLegacyIdAttribute()` usa `legacy_id` se presente, altrimenti l'`id` reale. - **Gli utenti sono UPSERT per email, non azzerati.** Tutte le altre entità vengono cancellate e ricreate; gli utenti no. Azzerare la tabella `users` durante un restore rischierebbe di **estromettere l'amministratore** che sta importando (backup che precede il suo account, o file parziale). Gli account esistenti vengono aggiornati, quelli nel file (ri)creati; nessuno viene eliminato. Conseguenza: non è un mirror perfetto (utenti extra restano), ma è senza perdite e non blocca fuori nessuno. - **Hash password e timestamp scritti col query builder.** Dopo il `save()` del modello, password/`remember_token`/`email_verified_at`/`created_at`/ `updated_at` vengono scritti con `DB::table()->update()`: preserva l'hash esatto (il cast `hashed` rivaliderebbe il costo bcrypt e potrebbe rifiutare un hash generato con `BCRYPT_ROUNDS` diverso) ed evita che Eloquent sovrascriva i timestamp importati. Stessa tecnica in `applyRowMeta()` per le altre entità. ### La pagina "Backup e import": cinque zone e una sola console La pagina era cresciuta per accumulo: sette riquadri senza un ordine dichiarato, la zona pericolosa a metà strada, **cinque** aree di log separate e pulsanti che ogni sezione ridefiniva per conto proprio. È stata rimessa in ordine attorno a tre regole. **Cinque zone numerate, in ordine di quanto sono definitive.** `1 Backup`, `2 Ripristino`, `3 Import PDF`, `4 XML`, `5 Zona pericolosa`. Ognuna ha un'ancora (`id="zona-…"`) e l'indice appiccicato in cima ci salta sopra. Un test verifica che le cinque ancore esistano *e che siano in quell'ordine nel sorgente*: l'ordine è la sostanza della sistemazione, non un dettaglio estetico. **Il "focus" della pagina.** Premuto un pulsante — o scelta una voce dell'indice — la pagina si sposta sulla zona di riferimento e la fa lampeggiare (`window.tmFocusZona`). Il focus da tastiera si sposta **solo** quando la richiesta è di navigazione: spostarlo anche a ogni azione strapperebbe il cursore da sotto le dita di chi ha appena premuto. Il primo comando di ogni zona è marcato `data-zona-focus` ed è quello che lo riceve. **Una sola console, agganciata in fondo alla finestra.** Prima la stessa operazione si raccontava in tre punti diversi: un ripristino cominciava nel riquadro "Browser", proseguiva in quello "Server" e aveva un terzo "Dettaglio" richiudibile nel pannello di avanzamento, in cima. Per capire dove si era fermato bisognava guardarli tutti. Adesso c'è una cronologia sola, in ordine di tempo, con la sorgente accanto a ogni riga, e la finestra è *fissa*: quasi tutti i modi in cui un caricamento muore sono muti, e l'unico indizio è dove si è interrotto il flusso di righe — un log che esce dallo schermo appena si scorre non serve proprio nel momento in cui servirebbe. Dettagli non ovvi della console: - **Le righe del server viaggiano già scremate.** Il conto di quante ne sono state spedite lo tiene il componente Livewire (`logSpediti`), non il browser: la coda intera dentro ogni risposta significherebbe sessanta righe poco meno di due volte al secondo, e per l'import PDF — la cui coda non ha tetto — l'intera cronologia a ogni poll. - **Per ogni operazione c'è un solo componente che la racconta** (`SegueOperazioneBackup::tipiSeguiti()`). Backup e zona pericolosa guardano lo stesso stato condiviso: senza un proprietario dichiarato spedirebbero entrambi le stesse righe, e la console le mostrerebbe due volte. - **Il download automatico si ascolta in un posto solo.** `scarica-backup` è un evento su `window`: due componenti che lo ascoltassero entrambi assegnerebbero `window.location.href` due volte, e il pacchetto verrebbe scaricato due volte. L'ascolto sta nella console, che è l'unico elemento sempre presente. Per lo stesso motivo `scaricaOra()` esce subito se non è il proprietario a chiamarlo: il segno "download già inviato" sta nello stato condiviso, quindi chi segue l'operazione di riflesso lo consumerebbe per primo — l'archivio sarebbe pronto e non arriverebbe a nessuno, e per l'azzeramento è pure il passo che sblocca la cancellazione. - **Lo scorrimento automatico si sospende se si torna indietro a leggere.** Trascinare in fondo mentre si sta guardando una riga di dieci secondi prima è il modo più rapido di rendere inutile un log che scorre. Compare invece "Torna in fondo". - **Il pannello è a posizione fissa, quindi la pagina ha uno spaziatore in fondo.** Senza, coprirebbe l'ultima zona — che è quella pericolosa. - **Il JavaScript della console sta in un `