### Problema Il recupero automatico dei dati anagrafici — da **PDND** e, in fallback, dai dati già forniti in passato dall'utente (**once-only**) — era gestito dentro `widget-formio` con la logica sparsa in più punti. Questo impediva di riutilizzarlo in altri contesti senza duplicare codice, e di attivare la PDND solo in casi specifici (per certe persone, o a certe condizioni del modulo). ### Soluzione Un'unica funzione riutilizzabile gestisce l'intero processo: individua da sola i blocchi da precompilare, recupera i dati da PDND e, quando non disponibili, propone quelli di una compilazione precedente. I campi popolati da PDND restano sempre in sola lettura, con un'indicazione visiva della provenienza e della data di aggiornamento del dato. Rispetto a prima, la precompilazione può attivarsi **in modo condizionato**: attende che un blocco nascosto diventi visibile prima di chiedere i dati (senza ricaricare la pagina), e può richiedere i dati del soggetto corretto quando il modulo riguarda più persone (es. richiedente e familiare). I moduli già configurati continuano a funzionare come prima. ## Configurazione dei blocchi PDND Un "blocco profilo" si configura in **due modalità alternative**, tramite le custom property del componente. | | Legacy | SDK | |--|--------|-----| | Property | `profile_block: true` | `profile_block: true` + `enable_pdnd_sdk: true` | | Cosa fa partire il recupero | il sistema, in automatico al caricamento e a ogni modifica | solo la chiamata esplicita nel Calculated Value | | Quando usarla | il recupero deve avvenire sempre e subito | il recupero dipende da una scelta dell'utente o da logica specifica | Nella modalità SDK la chiamata da scrivere nel Calculated Value (o Custom Default Value) dello stesso componente è: ```js window.FormioHelper.getPdndByUser(instance, fiscalCode); ``` dove `fiscalCode` è il codice fiscale del soggetto di cui servono i dati: quello del richiedente, oppure quello di un familiare scelto in un campo precedente (lo script può contenere un if/else che decide quale passare). > :warning: `enable_pdnd_sdk: true` esclude il blocco dalla gestione automatica: se le due property ci sono ma nessuno script chiama `getPdndByUser`, il blocco non recupera nulla e non segnala alcun errore. ## Autorizzazione della chiamata PDND Il Bearer token JWT ricevuto in autenticazione contiene lo `username` (il codice fiscale dell'utente) e il ruolo. Il controllo è lato server: | Ruolo | Codici fiscali richiedibili | |-------|-----------------------------| | `admin`, `operator`, `manager` | qualsiasi, nessun controllo | | `user` | il proprio, verificato contro lo `username` del JWT, o quelli del proprio stato di famiglia | Per gli scope legati allo stato di famiglia (es. `OC_CONIUGE`) la richiesta viaggia comunque con il CF del titolare del nucleo: è la PDND a restituire i dati del familiare. Per gli altri scope, un CF diverso da quello dell'utente autenticato viene rifiutato. ## Rischi di sicurezza L'issue tocca il recupero di dati anagrafici per un codice fiscale che può essere diverso da quello dell'utente autenticato: sono coinvolti l'autorizzazione della chiamata e il trattamento di dati personali non aggregati. - **Accesso a dati di terzi** — mitigato dal controllo lato server descritto sopra, che è **già in produzione e non viene modificato da questa issue**: il refactoring agisce sul lato client, l'autorizzazione resta quella esistente. - **CF manipolabile dal client** — nella modalità SDK il `fiscalCode` è calcolato nel browser, quindi va trattato come input non fidato: non è una misura di sicurezza, autorizza solo il controllo lato server. - **Regressione sui percorsi legacy** — il percorso di autorizzazione è comune alle due modalità; la retrocompatibilità è coperta dai test di regressione sui quattro servizi elencati sotto. - **Dati personali (GDPR)** — i dati once-only proposti in fallback sono salvati lato server e recuperati dalle pratiche già inviate dallo stesso utente: non viene creata una nuova raccolta di dati, si riusano quelli già trattati nell'ambito delle pratiche presentate. L'utente può eliminare i set di dati salvati dall'elenco proposto. I dati provenienti da PDND restano in sola lettura in ogni punto del flusso. ## Criteri di accettazione - Con un blocco in modalità legacy, l'utente autenticato trova i campi PDND compilati, in sola lettura e con provenienza e data del dato. - Con un blocco in modalità SDK condizionale, scegliendo un beneficiario diverso da sé stesso tra quelli del proprio nucleo, il blocco si popola con i dati di quel soggetto. - Un blocco nascosto da una condizione richiede i dati nel momento in cui diventa visibile, senza ricaricare la pagina. - Un utente con ruolo `user` non ottiene dati per un codice fiscale fuori dal proprio stato di famiglia. - Se PDND non è disponibile, l'utente può riutilizzare o eliminare i dati di una compilazione precedente. - La provenienza dei dati PDND resta visibile su riepilogo, PDF e dettaglio della pratica dopo l'invio. ## Casi d'uso | Caso | Modalità | Soggetto dei dati | Servizio | |------|----------|-------------------|----------| | Residenza del richiedente | legacy | richiedente | `pdnd-residenza-archetipo` | | Beneficiario del servizio | legacy | richiedente | `pdnd-oc-beneficiario` | | Figli a carico | legacy | figli | `pdnd-oc-figli-test-hardcoded-array` | | Coniuge (label legacy) | legacy, scope `OC_CONIUGE` | coniuge | `pdnd-oc-coniuge` | | Coniuge scelto dall'utente | SDK condizionale | familiare scelto nel modulo | `pdnd-oc-coniuge` (variante) | | PDND non disponibile | fallback once-only | richiedente | qualsiasi servizio con blocco profilo | Dettaglio completo: [foglio casi d'uso](https://docs.google.com/spreadsheets/d/14-DiKe_kQymi1Nc39w02D9UBd-SCaTbIPjh88Ju7Yi8/edit?gid=0#gid=0) ## Documentazione * [PR Gitbook — PDND condizionale](https://app.gitbook.com/o/-MRQtav6dxPB0RkAwAX7/sites/site_j0AUY/s/rdV0mwA7iy2c3I7wu5BX/~/edit/~/changes/259/creare-un-servizio/utilizzo-di-dati-certificati-da-pdnd/integrare-pdnd-condizionale) ## Test ### Test di retrocompatibilità legacy - [x] Residenza: i campi si precompilano in sola lettura e la provenienza resta visibile fino al dettaglio pratica - Autenticarsi come Michelangelo, aprire la [schermata di test](https://servizi.comune-nuovo.bugliano.pi.it/lang/it/servizi/pdnd-residenza-archetipo) e cercare il servizio `pdnd-residenza-archetipo` - Verificare che i campi PDND abbiano l'icona di check verde e siano in sola lettura - Compilare e inviare il form - Verificare che l'icona sia presente su riepilogo, PDF e dettaglio della pratica - [x] Beneficiario: stesso comportamento sul servizio beneficiario - Autenticarsi come Michelangelo, aprire la [schermata di test](https://servizi.comune-nuovo.bugliano.pi.it/lang/it/servizi/pdnd-oc-beneficiario) e cercare il servizio `pdnd-oc-beneficiario` - Verificare che i campi PDND siano in sola lettura con l'icona di check verde - Compilare, inviare e ricontrollare l'icona su riepilogo, PDF e dettaglio - [x] Figli: ogni riga dell'array riporta i dati del figlio corretto - Autenticarsi come Michelangelo, aprire la [schermata di test](https://servizi.comune-nuovo.bugliano.pi.it/lang/it/servizi/pdnd-oc-figli) e cercare il servizio `pdnd-oc-figli-test-hardcoded-array` - Verificare che ogni riga dell'array sia in sola lettura e riporti i dati del figlio corretto - Compilare, inviare e ricontrollare l'icona su riepilogo, PDF e dettaglio - [x] Coniuge in configurazione legacy: il blocco si precompila senza alcuna scelta dell'utente - Autenticarsi come Michelangelo, aprire la [schermata di test](https://servizi.comune-nuovo.bugliano.pi.it/lang/it/servizi/pdnd-oc-coniuge) e cercare il servizio `pdnd-oc-coniuge` nella configurazione legacy (solo `profile_block: true`) - Verificare che i dati del coniuge arrivino senza nessuna interazione dell'utente - Compilare, inviare e ricontrollare l'icona su riepilogo, PDF e dettaglio ### Test PDND condizionale (modalità SDK) - [x] Il beneficiario scelto dall'utente determina i dati recuperati - Autenticarsi come Michelangelo, aprire la [schermata di test](https://servizi.comune-nuovo.bugliano.pi.it/lang/it/servizi/pdnd-oc-coniuge) e cercare il servizio `pdnd-oc-coniuge` nella variante condizionale - Selezionare il coniuge nel campo di scelta del beneficiario - Verificare che il blocco si popoli con i dati del coniuge e non con quelli del richiedente - Cambiare la scelta e verificare che i dati si aggiornino - Compilare, inviare e ricontrollare l'icona su riepilogo, PDF e dettaglio - [x] Un blocco nascosto richiede i dati solo quando diventa visibile - Aprire la [schermata di test](https://servizi.comune-nuovo.bugliano.pi.it/lang/it/servizi/pdnd-oc-coniuge) e cercare un servizio con blocco PDND soggetto a condizione di visibilità - A blocco nascosto, verificare nel tab Rete del browser che non parta nessuna chiamata PDND - Soddisfare la condizione che rende visibile il blocco - Verificare che i dati si precompilino senza ricaricare la pagina ### Test fallback once-only - [x] Con PDND non disponibile l'utente riutilizza i dati di una compilazione precedente - Autenticarsi con un utente che ha già inviato una pratica con gli stessi dati, con il servizio PDND disattivato (o simulando l'errore della chiamata) - Aprire la [schermata di test](https://servizi.comune-nuovo.bugliano.pi.it/lang/it/servizi/test-residenza-once-only) e cercare un servizio con blocco profilo - Verificare la comparsa del pulsante di riutilizzo dei dati precedenti - Aprire l'elenco, selezionare un set di dati e verificare che il blocco si compili - Eliminare un set di dati salvati e verificare che non venga più proposto ### Test di sicurezza - [x] Un utente `user` non ottiene dati per un codice fiscale fuori dal proprio stato di famiglia - Autenticarsi con un utente con ruolo `user` - Aprire la [schermata di test](https://servizi.comune-nuovo.bugliano.pi.it/lang/it/servizi/pdnd-oc-coniuge), cercare un servizio in modalità SDK e forzare la chiamata con un CF non riconducibile all'utente né al suo nucleo (es. da console) - Verificare che la risposta sia un rifiuto e che nessun dato anagrafico compaia nel form - [x] I campi PDND non sono modificabili in nessun punto del flusso - Compilare uno dei servizi sopra dalla [schermata di test](https://www.comune-qa.bugliano.pi.it/bootstrapitalia/widget/service-form?service_id=e9bd035a-2127-4a01-b022-e1e405cd2ae8&mode=test) - Verificare che i campi precompilati restino in sola lettura anche dopo modifiche ad altri campi del modulo che ne provochino il ricalcolo ### Test cross-browser e mobile - [x] La compilazione con blocchi PDND funziona su mobile - Ripetere il test "Residenza" su Chrome Android (dispositivo reale o emulatore), sempre dalla [schermata di test](https://servizi.comune-nuovo.bugliano.pi.it/lang/it/servizi/pdnd-residenza-archetipo) - Ripetere lo stesso test su Safari iOS - Verificare che l'icona di provenienza e lo stato di sola lettura siano resi correttamente e che il pulsante di riutilizzo dati once-only sia raggiungibile