Alcune proposte evolutive

Ciao a tutti! Finora ho beneficiato del supporto della community ed ora è il momento di dare qualche piccolo contributo! Ho fatto una discreta sessione di test soprattutto per capire come si comporta il tool visto con gli occhi dello user finale e, a parte qualche bug, ci sono alcune cose che io credo potrebbero essere utili (alcune banali, altre decisamente meno …) e che vado ad elencare per titoli in ordine sparso e sulle quali possiamo approfondire:

  • persistenza dei messaggi: andrebbe richiesta la realizzazione di un’api con la possibilità di scaricare da app io i messaggi inviati visto che dalla dashboard del backoffice si vedono. Non ho trovato indicazioni su quanto tempo rimangono sulla piattaforma. Probabilmente a tendere sarà necessaria una notifica di avvenuta lettura in ottica evolutiva.
  • ID messaggio impostabile dall’esterno o comunque previsto come campo da accoppiare all’id assegnato da ioapp
  • verifica messaggi già inviati tramite ID ovvero riscontro messaggi inviati attraverso il connettore (json o db) o export xls stesso formato dell’input
  • un editor visuale per il testo dei messaggi non sarebbe male
  • possibilità di modificare il messaggio in caso di reinvio (ho sbagliato un dato)
  • gestione multiente
  • erogazione saas: gestione del tool (a questo punto non sarebbe più un sdk …) senza la parte IDE da usare come servizio di invio messaggi
  • se il messaggio ha lo stesso numero avviso (notice_number) il messaggio inviato passa senza alcun controllo. Non mi piace per niente ma temo sia un problema del backend dell’app io

Questo in estrema sintesi, ma credo ce ne sia per lavorarci un bel po’!

1 Mi Piace

Ho messo un project “upstream” da dove poi lo splittiamo in cose da fare su noiopen

1 Mi Piace

Ciao… io avevo pensato che sarebbe interessante dare la possibilità di fare un “invia a tutti” (ad esempio i cittadini di un comune) magari utilizzando le API di ANPR per recuperare la lista.
Sarebbe ancora più bello se si potessero personalizzare i messaggi con dei placeholder per il nome e cmq informazioni che sono restituite da ANPR.
Ma ammetto che non ho ben chiaro come realizzare questa cosa (ci vorrebbe un servizio a parte per dialogare con ANPR? ovviamente servirebbe l’abilitazione per accedere ai dati…)

Guarda stavo discutendo di questo: il fatto è che tu devi avere la lista delle persone a cui sei autoizzato a inviare e a “monte” la api key ti consente di mandare messaggi solo a quelli.

I placeholder ovviamente son funzioni interesanti. Non so se sia possibile dialogere con ANPR…

Si esatto, è un po’ restrittivo dover avere a priori la lista, soprattutto se si parla di voler sviluppare delle semplici notifiche con filtro per comune o cose simili…
So che ANPR espone delle API (credo SOAP) , qui c’è la documentazione tecnica https://www.anpr.interno.it/portale/documentazione-tecnica, almeno quella che sono riuscita a trovare.

Sicuramente ci vorrebbe l’accesso, e se non sbaglio si tratta di avere una card quindi forse diventa un po’ antipatico se non parliamo dell’ufficio anagrafe che già ne deve essere provvisto…

Non sono sicura sia così semplice, si protrebbe salvare le persone su un db, ma a quel punto interverrebbero i problemi di privacy immagino…

PS: forse il top sarebbe che le stesse API di IO prevedessero degli invii multipli con filtri di ricerca (es per comune, per età, ecc…)

Beh la cosa non è banale nel senso che di mezzo c’è anche l’autorizzazione ad usare il dato e l’ok dell’utente a essere “disturbato” su un certo canale (la faccio proprio breve eh!). Per quel che vedo al momento la generazione delle liste ha natura molto eterogenea, non so se deve appartenere a iosdk ma è solo un mio punto di vista.

Interagire con ANPR si può fare, ma il servizio mi rende solo i dati dei residenti mentre spesso potrei avere utenti di provenienza diversa. L’accesso alle API deve essere fatto da software/postazione certificata ma se serve approfondisco.
Altro problema è che l’impianto app-io, per quel che è emerso in una riunione recente, prevede la definizione di template e servizi da “richiamare” nelle comunicazioni e quindi difficilmente allo stato è possibile pensare ad una notifica generica anche se, ad esempio pe un’interruzione stradale o per la protezione civile, potrebbe avere un senso!

che servisse una postazione certificata lo sapevo, e annoverato fra gli aspetti problematici…
per quanto riguarda l’ok dell’utente ad essere disturbato, su IO si possono bloccare le notifiche puntualmente per ogni servizio…
più che altro è una questione di salvarsi una cache dei dati in un DB, questo comporterebbe problemi di privacy che penso siano scollegati dall’ok alla ricezione delle notifiche…
per quanto riguarda la questione “avvisi generici” si, sicuramente addirittura pensare a notifiche per posizione attuale dell’utente in caso di eventi di varia natura sarebbe tanta roba (di nuovo, privacy a parte), ma quello a cui pensavo io erano cose molto più easy tipo: “ricordatevi che c’è da pagare la tari entro il giorno X”, o il pass auto per le ZTL… insomma cose molto generiche basate sulla residenza…

E hai ragione!
Approfondirei il discorso del blocco della notifica: se ti mando un messaggio e (in futuro) il messaggio ha valore di notifica (legal), non potrai bloccarlo! Altrimenti cade il palco.Ma questo sarà dopodomani :slight_smile:
Il problema più grosso è per me ora definire dei template di messaggi sufficientemente generici (ma non troppo) per poter affrontare le varie necessità comunicative di un ente (penso all’ente locale per ora) e al momento faccio davvero fatica a immaginarle. Da notare che ogni template si porta dietro il servizio e quindi un API KEY! Non ho ancora iniziato a lavorarci …

1 Mi Piace