- Sciolto, il gruppo non resta nello storico: si elimina (via sciolto_at;
la migrazione elimina anche quelli gia' sciolti). I territori solo nel
pacchetto tornano in reparto; quelli gia' dati restano ai membri, e
l'assegnazione conserva il nome del gruppo (assegnazioni.gruppo_nome).
- Creando il gruppo non si chiede l'email: users.username dal nome del
gruppo ("Gruppo Zisa" -> gruppo.zisa), users.email facoltativa. Login con
"Email o nome utente". Nome del gruppo unico.
- Sciolto il gruppo il nome utente si libera (l'utenza disattivata prende
ex.sorvegliante.<id>). XML: nome utente e gruppo_nome.
- Profilo, testata, cambio password e Utenti mostrano il nome utente dove
manca l'email. Informativa privacy, README, HANDOFF e test aggiornati.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Badge "Gruppo ..." / "Sorvegliante del gruppo ..." nell'elenco dei
proclamatori (con il filtro "In un gruppo di servizio") e in testa alla
scheda; nella scelta del proclamatore (Assegna, Registro) la nota
"gruppo ..." accanto al nome, che resta sceglibile.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Proclamatore::booted: reso non attivo, spostato nel cestino o
anonimizzato, il sorvegliante scioglie il gruppo (territori non dati in
reparto, membri liberi, utenza disattivata); il motivo va nel registro.
L'elenco chiede conferma, la modifica avvisa sotto "Attivo". Un membro
nel cestino esce dal gruppo.
- Scheda del proclamatore: gruppo guidato con membri, pacchetto, da dare,
assegnazioni dal gruppo, utenza e ultimo accesso; oppure gruppo di cui
e' membro; gruppi sciolti guidati in passato.
- Profilo del sorvegliante: il suo gruppo con gli stessi numeri.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Un ex sorvegliante puo' guidare un gruppo nuovo: si riattiva la sua
utenza. Il sorvegliante di un gruppo attivo non si cestina ne' si
anonimizza; anonimizzando un ex sorvegliante si anonimizza anche
l'utenza. Nel registro delle attivita' nome ed email dell'utenza del
sorvegliante diventano "proclamatore #id". La voce "Il mio gruppo"
dipende dal ruolo: l'amministratore passa ogni @can.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Il gruppo ha un sorvegliante (proclamatore con utenza: email e password
temporanea, senza conferma dell'email) e dei membri; l'amministratore
mette in blocco dei territori nel pacchetto del gruppo. Il pacchetto non
e' un'assegnazione e non tocca le statistiche; quando il sorvegliante da'
un territorio a un membro nasce un'assegnazione normale con
gruppo_servizio_id. Al rientro il territorio torna in reparto. Sciogliere
il gruppo libera pacchetto e membri e disattiva l'utenza.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Migrazione: tolte le colonne email e telefono dei proclamatori (vuote
in produzione). Tolti da form, scheda, elenco, XML (un file vecchio si
importa ignorandoli).
- Invio del link: solo "Copia link" e "Condividi…" (menu di condivisione
del telefono, navigator.share): il destinatario lo sceglie chi usa
l'app. Via WhatsApp diretto, canale email, notifica LinkTerritorio,
componente x-whatsapp.
- Elenco assegnati: "Condividi" al posto di WhatsApp; a condivisione
fatta il link risulta inviato.
- Informativa privacy, README, HANDOFF e test aggiornati.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Dati trattati attuali: email e telefono cifrati, link alla piantina,
stato dell'invio, conferma email, log senza nomi.
- Valori letti al momento: congregazione, conservazione del log, scadenza
del link, download del PDF, server di posta, cifratura, durata della
sessione, indirizzo/HTTPS, ruoli con i permessi veri, conteggi dei dati.
- Servizi esterni: WhatsApp, posta, OpenStreetMap.
- Dichiarato che backup ed export XML contengono i dati in chiaro.
README e HANDOFF aggiornati.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assegna pesava 387 KB e Livewire li rimandava a ogni interazione.
- Elenco dei territori assegnati in un componente lazy a sé
(ElencoAssegnati): il form compare subito e non lo ridisegna.
- Ricerca nell'elenco e anteprima della miniatura nel browser: nessuna
richiesta al server mentre si scrive o si sceglie il territorio.
- Icone SVG come simboli richiamati con <use>.
- Assegnazione::giorni: cast a int (Carbon 3 restituisce un float).
Home: "Vedi tutti" diventa un pulsante nella testata dei riquadri.
README e HANDOFF aggiornati.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Dettaglio campagna: mostra tutti i territori conteggiati (stessa base
della percentuale), non solo quelli assegnati dopo l'inizio.
- Rientro: se più campagne corrispondono propone la più recente invece
della prima creata; testo del banner chiarito.
- Dettaglio campagna: nuova sezione "In corso" con i territori fuori
durante la campagna e non ancora rientrati.
- README: regola di conteggio documentata.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Le porte erano legate a 127.0.0.1, quindi l'applicazione non era raggiungibile
per IP: andava bene solo accedendo da un dominio via Traefik. Ora interfaccia
e porta si decidono separatamente nel .env, per ogni servizio.
APP_BIND=0.0.0.0 APP_PORT=8080 app esposta (default)
DB_BIND=127.0.0.1 DB_PORT_HOST=3306 database solo da localhost
MAILPIT_BIND=127.0.0.1 solo col profilo dev
Il database resta su localhost per due motivi: ci si arriva comunque con un
tunnel SSH senza esporlo a Internet, e su un host con piu' progetti la 3306
va spesso in conflitto (per questo e' cambiabile con DB_PORT_HOST).
Redis non pubblica nulla: non serve da fuori.
SESSION_SECURE_COOKIE passa a false come default, perche' ora l'accesso
tipico e' in HTTP per IP. Con true il cookie di sessione e' marcato "secure"
e il browser non lo rimanda su HTTP: verificato, il login risponde 419 Page
Expired e si torna alla schermata di accesso. Il tranello e' che provandolo
su localhost non si manifesta, perche' i browser considerano localhost un
contesto sicuro: emerge solo accedendo per IP. E' documentato in
.env.example insieme al sintomo esatto.
Verificato: app raggiungibile dall'IP di rete, porta del database chiusa
dall'esterno e aperta da localhost, login e pagine funzionanti via IP.
Nota: senza dominio il traffico e' in chiaro. Il README segnala il passaggio
a HTTPS come consigliato, con le tre variabili da cambiare.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
I due file compose andavano tenuti allineati a mano, e gli anchor
(x-app-env, <<:) sono sintassi che va conosciuta per riuscire a leggere il
file. Per un deploy che deve restare semplice era complessita' non
giustificata.
Ora c'e' un solo docker-compose.yml, esplicito, che copre produzione e
sviluppo:
- ogni servizio dichiara quello che usa, senza merge key
- mailpit e' dietro il profilo "dev", quindi non parte mai in produzione
- la porta e' legata a 127.0.0.1 per default: in produzione il traffico
arriva da Traefik sulla rete interna, in locale basta localhost:8080.
Per esporla davvero: APP_PORT=0.0.0.0:8080
- .env diventa l'unica fonte di configurazione, senza valori ridichiarati
Compromesso accettato: sparendo i valori fissati nel compose, DB_HOST e
REDIS_HOST devono contenere i nomi dei servizi (mariadb, redis) e non un
indirizzo. E' segnalato in .env.example, nel README e in HANDOFF.md.
Per le modifiche al codice senza ricostruire l'immagine il README documenta
un docker-compose.override.yml, che Compose applica da solo ed e' gia'
ignorato da git.
Verificato: sei servizi healthy, login e pagine a 200, redeploy idempotente,
porta esposta solo su localhost, mailpit assente senza il profilo dev.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Il Dockerfile compilava l'applicazione in /app-src mentre 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, questo significava build a runtime a ogni deploy.
Ora vendor/ e public/build sono compilati in stage separati e copiati
nell'immagine finale. I container di produzione non montano il sorgente e
non eseguono build all'avvio: un redeploy e' build, migrazioni, online.
- Dockerfile multi-stage (composer, node, runtime)
- nginx e php-fpm nello stesso container via supervisor: con container
separati nginx avrebbe bisogno di una copia di public/ e del volume
storage solo per servire file statici
- clear_env = no in www.conf, senza cui php-fpm nasconde a Laravel tutte
le variabili d'ambiente
- configurazione da ambiente di processo invece di .env riscritto con sed;
il compose fissa solo i valori dettati dalla topologia
- fail-fast su APP_URL, DB_PASSWORD, DB_ROOT_PASSWORD, REDIS_PASSWORD
- servizio scheduler dedicato: schedule:work non veniva mai eseguito,
quindi la pulizia dell'audit log non e' mai partita
- solo il container app esegue le migrazioni, per evitare che due
container in gara lascino uno schema applicato a meta'
- healthcheck separati per worker e scheduler, che non espongono HTTP
- docker-compose.dev.yml per lo sviluppo locale
- documentazione unificata in README.md e HANDOFF.md
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
