possibilità per l’ente mittente di avere anche un feedback relativo all’apertura della comunicazione da parte del destinatario
lato tecnico è prevista, per i canali che lo permettono, la possibilità di associare lo stato di apertura (ovvero, lettura) dei messaggi. tuttavia sarebbe più trasparente, nei confronti di chi riceve i messaggi, che la condivisione di tale informazione avvenisse in maniera consapevole e non automatica. il meccanismo utilizzato nelle email (aggiunta di link per il tracking) non soddisfa questo requisito. è dirimente per l’amministrazione conoscere lo stato di lettura a prescindere e per ogni canale ?
possibilità di inviare comunicazioni in multicast, specificando più di un CF destinatario o una eventuale “lista di distribuzione” che dovrebbe però essere configurata lato AgID
è prevista l’implementazione di una modalità di invio batch (ovvero, specificando più di un CF destinatario).
tuttavia per quanto riguarda le liste di distribuzione andrebbe esplorato più in dettaglio il requisito. che si intende esattamente con “configurata da AgID” ? che tipo di liste di distribuzione ? (es. liste tematiche con messaggi broadcast uguali per tutti i destinatari ?) come dovrebbero venire popolate ?
il caso d’uso sul quale vorremmo focalizzarci in questa fase iniziale è l’invio di comunicazioni destinate a un particolare individuo (es. avvisi di pagamento, comunicazioni di cambiamento di stato su pratiche già inoltrate, …) piuttosto che una comunicazione broadcast generalista che è spesso veicolata più efficacemente tramite altri canali (es. twitter o il sito istituzionale)
e di conseguenza: possibilità di avere i feedback relativi a più comunicazioni con una sola chiamata
questo caso d’uso rientra nella modalità di invio batch. un possibile modello è quello di “Gov.uk Notify” che permette di associare ai messaggi inviati un “reference_id”, ovvero un identificativo opaco al sistema di avvisi, che serve all’amministrazione per recuperare i batch di invio.
possibilità per una amministrazione mittente di specificare anche un logo/tema e template del messaggio inviato
per il logo è previsto in roadmap. per quanto riguarda il canale email, è opportuno evitare di linkare immagini esterne al sistema nel contenuto delle email: potrebbero venire eliminate / sostituite o utilizzate per la tracciatura. l’idea è quella di permettere alle PA di caricare un logo al momento della sottoscrizione del servizio.
per quanto riguarda i template vorremmo limitarli a un set predefinito da scegliere in fase di invio dei messaggi. ognuno può proporre un proprio layout es. Servizio di invio avvisi al cittadino - n°9 da oggrob
possibilità di gestire anche altri attributi nel profilo utente in AgID, non solo l’indirizzo e-mail, ad esempio preferenze per tipo di messaggio/canale
questo è interessante, ma servirebbe dettagliare che tipo di preferenze messaggio/canale.
avere un metodo che torna la “version” di un profilo utente, per capire se è cambiato
requisito ragionevole, si tratta di aggiungere il campo ‘version’ (già esistente, ma “nascosto” nell’API) all’output della chiamata a getProfile
possibilità per un ente “aggregante” di mandare messaggio in nome e per conto delle amministrazioni “aggregate”
tecnicamente è già possibile ottenendo un API-key per ogni ente. per quanto riguarda il lato burocratico stiamo lavorando a una convenzione sul modello di quella di pagoPA tramite il quale un soggetto aggregante può operare per diversi enti. vedi anche
possibilità in ambiente di test di avere più di un solo codice fiscale destinatario per fare le prove
possiamo generare più codici fiscali di test (nell’ordine di ?), tuttavia per questioni di sicurezza il destinatario sarebbe comunque limitato all’email verificata al momento dell’iscrizione.