menu di navigazione del network

Nuovo portale sviluppatori per le API di avvisi e preferenze

Salve a tutti,

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.

Il portale si trova al nuovo indirizzo: https://developer.cd.italia.it/

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.

a presto!

2 Likes

Nella pagina https://teamdigitale.github.io/digital-citizenship/api.html il link interfaccia grafica genera un errore di “elemento non trovato”.

1 Like

Ciao @cremasco,

grazie per la segnalazione, il link corretto è https://developer.cd.italia.it/docs/services/digital-citizenship-api

ora sistemiamo la documentazione,

a presto

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:

  1. possibilità per l’ente mittente di avere anche un feedback relativo all’apertura della comunicazione da parte del destinatario
  2. 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
  3. e di conseguenza: possibilità di avere i feedback relativi a più comunicazioni con una sola chiamata
  4. possibilità per una amministrazione mittente di specificare anche un logo/tema e template del messaggio inviato
  5. 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
  6. avere un metodo che torna la “version” di un profilo utente, per capire se è cambiato
  7. possibilità per un ente “aggregante” di mandare messaggio in nome e per conto delle amministrazioni “aggregate”
  8. 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

Salve @fabiorak,

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

Grazie!

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.

Come mai per accedere bisogna fare un account tramite un portale microsoft?
Sinceramente mi sarei aspettato SPID…

ciao Daniele,

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.

  1. 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.
  2. 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.
  3. feedback relativi a più utenti: ok
  4. logo/tema: ok, bene
  5. 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
  6. version del profilo: ok
  7. ente aggregante: ok
  8. per i nostri test sarebbero al momento sufficienti 3 - 4 codici fiscali destinatari.

Grazie

@fabiorak abbiamo riorganizzato i task sui quali stiamo lavorando
recependo i primi feedback dalle PA:
https://www.pivotaltracker.com/n/projects/2088623

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.