99 lines
2.8 KiB
Markdown
99 lines
2.8 KiB
Markdown
# Anagrafe Condominiale, Portale e Posta
|
|
|
|
## Obiettivo
|
|
|
|
Questa implementazione introduce la base web per tre esigenze operative:
|
|
|
|
- aggiornamento self-service della scheda anagrafica da parte di condomini e inquilini;
|
|
- gestione di piu recapiti email e recapiti differenziati per servizio e unita immobiliare;
|
|
- prima integrazione esplicita tra email in ingresso e ticket da seguire.
|
|
|
|
## Portale condomino/inquilino
|
|
|
|
Nuovi percorsi:
|
|
|
|
- `/condomino/anagrafe`
|
|
- `/condomino/anagrafe/modulo`
|
|
- `/condomino/unita`
|
|
- `/condomino/unita/{unitaImmobiliare}`
|
|
|
|
Funzioni disponibili:
|
|
|
|
- aggiornamento dati anagrafici base del profilo digitale associato;
|
|
- gestione di email multiple;
|
|
- definizione recapiti email di default per servizio e unita immobiliare;
|
|
- download PDF del modulo anagrafe da stampare o firmare manualmente;
|
|
- richiesta strutturata di aggiornamento catastale come servizio aggiuntivo.
|
|
|
|
## Tracciabilita
|
|
|
|
Le modifiche dirette della scheda anagrafica vengono registrate in `persone_audit` con:
|
|
|
|
- campo modificato;
|
|
- valore precedente;
|
|
- valore nuovo;
|
|
- utente che ha eseguito la modifica;
|
|
- IP e timestamp.
|
|
|
|
I recapiti per servizio vengono tracciati come campi audit del tipo:
|
|
|
|
- `unita_recapito:{unita_id}:{servizio}`
|
|
|
|
## Modello dati nuovo
|
|
|
|
Tabella introdotta:
|
|
|
|
- `unita_recapiti_servizio`
|
|
|
|
Scopo:
|
|
|
|
- salvare, per una specifica unita e una specifica persona, l'indirizzo email da usare come default per:
|
|
- comunicazioni generali
|
|
- convocazioni
|
|
- ticket
|
|
- solleciti
|
|
- contabilita
|
|
- amministrazione
|
|
- anagrafe
|
|
|
|
## Resolver recapiti
|
|
|
|
Servizio applicativo:
|
|
|
|
- `App\Services\Comunicazioni\RecapitiServizioResolver`
|
|
|
|
Ordine logico di risoluzione:
|
|
|
|
1. override esplicito su `unita_recapiti_servizio`;
|
|
2. fallback sui soggetti attivi collegati all'unita tramite `persone_unita_relazioni`;
|
|
3. email principale e email multiple attive della persona.
|
|
|
|
## Ticket e posta
|
|
|
|
Durante l'import EML da ticket (`Admin\TicketController::storeEmailMessage`) ora vengono creati entrambi:
|
|
|
|
- il documento EML archiviato;
|
|
- il `TicketMessage` interno;
|
|
- una `CommunicationMessage` collegata al ticket.
|
|
|
|
Questo prepara il terreno per una gestione futura di mailbox multiple e collegamento messaggio -> ticket senza passare solo da allegati manuali.
|
|
|
|
## Deploy e staging
|
|
|
|
Dopo aver copiato i file in staging eseguire sempre:
|
|
|
|
```bash
|
|
php artisan migrate --force
|
|
php artisan optimize:clear
|
|
```
|
|
|
|
La migration da applicare e:
|
|
|
|
- `2026_03_18_090000_create_unita_recapiti_servizio_table.php`
|
|
|
|
## Limiti attuali
|
|
|
|
- il collegamento portale -> persona avviene solo quando l'utente autenticato e riconoscibile con sicurezza tramite email principale o email multipla della persona e una relazione attiva con le unita accessibili;
|
|
- la gestione completa di mailbox Google/IMAP non e ancora automatizzata;
|
|
- il servizio catastale e registrato come richiesta strutturata, non ancora come workflow economico/fatturabile completo.
|