menu di navigazione del network

uniTicket - Ticket System e Gestore flussi documentali

Ciao a tutti,
qui la repo del software in oggetto https://github.com/UniversitaDellaCalabria/uniTicket.
Desidero condividere, insieme al collega Giuseppe De Marco, l’opportunità di confrontarci su una piattaforma in fase di rilascio che abbiamo denominato “uniTicket”.
Siamo aperti alla discussione su eventuali features e casi d’uso comuni al contesto della PA.
Ci riteniamo disponibili, fin da ora, a ricevere idee, contributi e indicazioni.
Trovate la documentazione ufficiale qui: https://uniticket.readthedocs.io/it/latest/index.html.

1 Like

Ciao, complimenti per il rilascio, una domanda sugli stati del ticket: non vi capita mai di avere dei ticket a cui avete dato risposta ma non sono ancora pronti per essere chiusi?
A noi capita tantissimo e ci è estremamente utile lo stato in attesa di risposta, che separa i ticket da quelli a cui c’e’ ancora da rispondere ma allo stesso tempo non sono ancora ticket chiusi. Con uno stato intermedio di quel tipo una funzionalità molto comoda è “Chiudi automaticamente i ticket in stato in attesa di risposta dopo X ore”.

Ciao @lorello,

La logica che abbiamo implementato prevede un flusso, uno scambio di informazioni, che può avvenire più volte nel tempo, fino alla chiusura ovvero alla risoluzione del ticket.

Nello specifico il ticket rimane aperto fino a quando la richiesta non risulti essere stata evasa, oppure viene chiuso con una motivazione. Non è possibile secondo questo approccio chiudere un ticket senza motivazione o addirittura delegare il sistema a chiudere ticket che non hanno ricevuto risposta per tempo.

L’operatore se ritiene che il ticket sia inconsistente/inutile lo chiude con una motivazione. Se ritiene invece di aver dato corretta risposta o indicazione, lo chiude motivando questo. Se ritiene invece che l’utente abbia aperto un ticket errato, presso un ufficio per la quale non vi risulti essere alcuna competenza in merito, può decidere se:

  • chiudere motivando l’assenza di competenza;
  • trasferirlo ad un altro ufficio per competenza o conoscenza, mantenendone traccia (può partecipare al thread);
  • trasferirlo ad un altro ufficio per competenza, mantenendo il thread in sola lettura (rimanendo in conoscenza);
  • trasferirlo ad un altro ufficio per competenza, abbandonando il thread.

tutte queste azioni di “stato” possono essere svolte più volte durante la vita di un ticket.
I ticket inoltre possono essere interdipendenti tra di loro, con il vincolo massimo di una dipendenza (per evitare di generare troppa complessità o interdipendenze “circolari” assai note negli assett organizzativi della PA!).

Speriamo di aver fornito una visione complessiva e pertinente al tuo intervento,
Grazie per la partecipazione e a presto per ulteriori scambi

Grazie @peppelinux, sei stato davvero esauriente. Leggendo la documentazione ho letto un’altra cosa davvero interessantissima: il controllo dei PDF Firmati e la verifica dei file p7m. Anche in uno dei nostri prodotti abbiamo la stessa esigenza e ora facciamo un controllo molto lasco, da migliorare sicuramente, mi guarderò la vostra implementazione, magari la libreria che avete usato ci rende il lavoro molto semplice. Grazie ancora!

@lorello grazie per aver notato questa feature.

@francesco.filicetti ha creato un FormField al di sopra di questa app:

Questa è un semplice wrapper al di sopra di poppler. Attualmente vi è una unica limitazione, la firma viene verificata per la valutazione dell’integrità dell’allegato MA NON per la validità della stessa. Ovvero dovremmo aggiornare le CA e aggiungere le verifiche su queste ad ogni validazione. Ovviamente questo riguarda il tool FileSignatureValidator e non uniTicket.

Siamo aperti ad accettare eventuali issues nella pagina dedicata, implementarlo non costerebbe troppo. Massima apertura nel ricevere eventuali PR, è inteso!