abbiamo attivato il nuovo portale sviluppatori per le API di avvisi e preferenze, stiamo ancora aggiungendo contenuti e lo stiamo rendendo più fruibile, ma le funzionalità di base ci sono tutte.
ogni feedback e suggerimento è il benvenuto, in particolare relativamente alla sezione “funzionalità” e “FAQ”, fateci sapere se ci sono informazioni che mancano così le aggiungiamo.
Ciao
come concordato, riportiamo l’elenco di alcune funzionalità che sono di interesse per Regione del Veneto e che potrebbero arricchire le API di messaggistica:
possibilità per l’ente mittente di avere anche un feedback relativo all’apertura della comunicazione da parte del destinatario
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
e di conseguenza: possibilità di avere i feedback relativi a più comunicazioni con una sola chiamata
possibilità per una amministrazione mittente di specificare anche un logo/tema e template del messaggio inviato
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
avere un metodo che torna la “version” di un profilo utente, per capire se è cambiato
possibilità per un ente “aggregante” di mandare messaggio in nome e per conto delle amministrazioni “aggregate”
possibilità in ambiente di test di avere più di un solo codice fiscale destinatario per fare le prove
Volevo anche chiedere se era possibile tracciare una pianificazione di maggior dettaglio dei prossimi sviluppi relativi al sistema di messaggistica, ai canali che verranno via via implementati, al profilo/preferenze e all’eventuale app
grazie per il contributo, trovi una roadmap di massima qui, la roadmap potrà cambiare nei prossimi mesi in base alle esigenze delle PA e dei servizi che si integreranno col sistema. Utilizzeremo questo forum per confrontarci con le PA e valutare assieme quali funzionalità sviluppare e con che priorità.
Sarebbe molto utile se potessi condividere:
quali servizi la Regione Veneto sta lanciando o ha in programma di lanciare nei prossimi mesi
per ogni servizio, in che modo il sistema di avvisi e preferenze può contribuire al successo e all’adozione di quel servizio da parte dei cittadini
per ogni servizio, quanti cittadini si prevede lo utilizzeranno e quale potrebbe essere il volume di avvisi sui vari canali
per ogni servizio, che beneficio possono dare le funzionalità che hai elencato
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
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.
abbiamo voluto lanciare questa prima versione del portale developer il prima possibile per iniziare il processo di onboarding delle PA sul sistema - per raggiungere questo obiettivo senza ritardi abbiamo dovuto decidere cosa implementare prima e cosa poi, il supporto SPID è molto importante per noi ed in futuro sicuramente verrà supportato come opzione di login ma per ora non è una funzionalità indispensabile di questo progetto.
Grazie @gunzip,
ti rispondo sotto per i vari punti.
avere un feedback sulla lettura del messaggio sarebbe ovviamente utile per qualsiasi canale che offra un meccanismo atto allo scopo. Ok sull’informare l’utente dell’invio del feedback, si rischierebbe però di inficiarlo se lo si vincolasse all’approvazione dell’utente stesso.
in merito alle liste di distribuzione, nel caso si volessero prendere in considerazione, dovrebbero essere configurate non da AgID ma presso AgID, ovvero si potrebbe pensare ad un’interfaccia per la PA con cui poter aggregare utenti destinatari secondo un qualche criterio. Nel caso RVE questa interfaccia potrebbe venir invocata dal fascicolo del cittadino in conseguenza di azioni di configurazione/sottoscrizione fatte dal cittadino stesso.
Si potrebbe pensare che questa interfaccia dia la possibilità di “taggare” l’utente (un attributo nel profilo utente di AgID?). In tal modo la PA potrebbe chiamare una sola volta il sistema di avvisi di AgID, passando messaggio e tag, e AgID potrebbe asincronamente consegnare i messaggi, in modalità batch, a tutti i cittadini “taggati” in quel modo dalla PA mittente.
Giusto per fare un’ipotesi come caso d’uso di esempio, i tag potrebbero essere della forma <CODICE_IPA_MITTENTE>-<NOME_TAG>, es: “C_123-scuola” e C_123 potrebbe mandare una comunicazione destinata a “scuola”, identificando in tal modo tutti i cittadini che si sono sottoscritti a questa categoria di avvisi.
feedback relativi a più utenti: ok
logo/tema: ok, bene
preferenze nel profilo per tipo di messaggio e tipo di canale: es il caso d’uso del punto 2 per le preferenze sul tipo di messaggio, o, per il tipo di canale, potremmo pensare ad un cittadino che preferisce essere contattato sulla posta aziendale nei giorni lavorativi e sul cellulare nei festivi
version del profilo: ok
ente aggregante: ok
per i nostri test sarebbero al momento sufficienti 3 - 4 codici fiscali destinatari.
ciò dovrebbe dare un’idea precisa dell’avanzamento delle attività e mettere in condizione amministrazioni (e fornitori) di decidere se le funzionalità da implementare sono dirimenti per aderire al servizio (considerando la fase “pilota”).
per tracciare le proposte di nuove funzionalità non contemplate nella roadmap consigliamo di aprire una issue sul GitHub del progetto:
oltre alla proposta di funzionalità in sé, sarebbe molto utile capire quali benefici questa potrebbe apportare e in base a quali elementi scaturisce la necessità.
ad esempio, in merito alla possibilità di liste di distribuzione (che meriterebbe un topic / issue a sé), mi sembra di capire che l’esigenza sia di inviare lo stesso identico messaggio a n-destinatari. in questa prima fase vogliamo concentrarci sul caso d’uso “messaggio personalizzato” per il singolo destinatario (es. un avviso di pagamento), il che non si sposa con il concetto di lista di destinatari.