RM: mappatura degli stati della pratica per un utilizzo più sensato per l'utente

come sviluppatore vorrei avere una mappatura degli stati della pratica direttamente su modello dati in modo da semplificare la mappatura degli stati quando arrivano dal RM e la mappatura inversa quando si effettua una richiesta per stato

Dettagli

Sulla nuova area cittadino lo stato della pratica non assume tutti i possibili valori che può assumere nei modelli sul server. Questo è dovuto al fatto che ci sono degli stati che sono tecnici e non sono molto indicativi per il cittadino. Per migliorare l'esperienza utente nascondiamo nella UI alcuni stati accorpandoli. Per realizzare questa cosa è necessario rimappare gli stati della pratica sui nuovi stati mantenendo la coerenza. Attualmente questo mapping è fatto a front end ma genera delle complicazioni: devo fare un mapping quando il dato arriva da server e in fase di ricerca, devo assicurarmi che ci sia un mapping al contrario.

Acceptance criteria

Il mapping degli stati della pratica devono rispettare queste richieste:

• STATUS_DRAFT (1000) -> DRAFT
• STATUS_STAMPS_PAYMENT_PENDING (1400) -> PAYMENT_PENDING
• STATUS_PAYMENT_PENDING (1500) -> PAYMENT_PENDING
• STATUS_PAYMENT_OUTCOME_PENDING (1510) -> PAYMENT_PENDING
• STATUS_PAYMENT_SUCCESS se ci sono pratiche in questo stato è un errore (1520) -> SUBMITTED
• STATUS_PAYMENT_ERROR (1530) -> PAYMENT_PENDING
• STATUS_PRE_SUBMIT servito per generazione pdf esterni (1900) -> SUBMITTED
• STATUS_SUBMITTED (2000) -> SUBMITTED
• STATUS_REGISTERED (3000) -> SUBMITTED
• STATUS_PENDING presa in carico (4000) -> PROCESSING
• STATUS_REQUEST_INTEGRATION (4100) -> REQUEST_INTEGRATION
• STATUS_DRAFT_FOR_INTEGRATION (4200) -> REQUEST_INTEGRATION
• STATUS_SUBMITTED_AFTER_INTEGRATION (4300) -> REQUEST_INTEGRATION
• STATUS_REGISTERED_AFTER_INTEGRATION (4400) -> REQUEST_INTEGRATION
• STATUS_PENDING_AFTER_INTEGRATION (4500) -> PROCESSING
• STATUS_PROCESSING mai stato utilizzato (5000) -> PROCESSING
• STATUS_COMPLETE_WAITALLEGATIOPERATORE (6000) -> PROCESSING
• STATUS_COMPLETE (7000) -> APPROVED
• STATUS_CANCELLED_WAITALLEGATIOPERATORE (8000) -> PROCESSING
• STATUS_CANCELLED rifiutata (9000) -> REJECTED
• STATUS_WITHDRAW ritirata dall'utente (2000) ->0 WITHDRAW
• STATUS_REVOKED annullata dall'operatore (5000) ->0 CANCELLED

Inoltre sarà necessario

• Documentare il mapping su ???
• Aggiornare la documentazione su modello dati

Tests

I test consistono nel creare/modificare una pratica in modo da verificare stato per stato il corretto mapping su directus

È possibile verificare direttamente sulla nuova area cittadino i cambi di stato:

https://servizi.comune-nuovo.bugliano.pi.it/lang/it/pratiche/

In alto a destra nel riquadro della pratica è presente lo stato della pratica.

Per effettuare il test sarà prendere in considerazione una pratica sulla nuova area cittadino, entrare nell'area Operatore in modifica pratica (usare l'id della pratica) e modificare lo stato della pratica.

Verificare che i cambi di stato corrispondano al mapping sopra