Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

Grafico del flusso

Descrizione

Il flusso mobilityIncoming-flow è un flusso centralizzato che consente il censimento delle Mobilità in ingresso.

Questo flusso prevede i seguenti attori nelle diverse visioni.
  • Visione completa
    • Helpdesk - HD
      Team con profilo "Profilo Helpdesk per la Mobilità in ingresso (mobilityIncoming) "
  • Visione dipartimentale
    • Organi dipartimentali - OD
      Team con la seguente naming convention "Profilo di dipartimento per XXX", dove XXX è il nome del dipartimento
  • Visione personale
    • Persona in ingresso - RS
    • Tutor - TU
Trattandosi di un flusso centralizzato, la creazione di una nuova mobilità in ingresso è consentita SOLO all' HD e OD.
Gli altri attori del flusso possono solo visionare le informazioni.

La persona in ingresso DEVE essere necessariamente censita in IRIS RM (anche se non presente la controparte sul sistema master UGOV), specificando il codice fiscale.
Nel momento in cui la persona dovesse essere censita in UGOV (a seguito della formalizzazione di un contratto) allora verrà fatta la riconciliazione delle anagrafiche basandosi sul codice fiscale.
E' pertanto importante accertarsi che il codice fiscale venga inserito correttamente.
La persona inserita sarà consultabile nell'elenco Risorse ==> Persone ==> Tutte le persone

Etichette Stati

I nomi degli stati possono essere personalizzati con la funzione di Gestione etichette.
Nella tabella sottostante vengono riportati tutti gli stati previsti dal flusso con relativa etichetta e valore di default.
Vengono anche fornite le etichette per i vari bottoni che consentono lo spostamento di stato.

Identificativo statoChiave etichetta statoValore default statoChiave etichetta bottone transizione in ingressoValore default bottone transizione in ingresso
draftwfState.inm.draftBozzabutton.forward.to.inm.draftSalva e invia in "Bozza"
validatedwfState.inm.validatedValidatobutton.forward.to.inm.validatedSalva e invia in "Validato"
reopenedwfState.inm.reopenedRiapertobutton.forward.to.inm.reopenedSalva e invia in "Riaperto"
Anchor
ModelloDati-anchor
ModelloDati-anchor

Modello Dati

Il dettaglio del modello dati associato a questo flusso è disponibile alla seguente pagina Produzione - Modello dati (mobilityIncoming - INM)

Anchor
Permessi-anchor
Permessi-anchor

Permessi

Nella seguente sezione viene riportato il dettaglio dei permessi e delle transizioni di stato possibili per tutti gli attori del flusso.
Per quanto riguarda le transizioni di stato vengono riportati gli identificativi degli stati verso i quali è possibile effettuare la transizione.
Quando viene riportato il marcatore "__PREVIOUS_STATE__" significa che la transizione di stato è consentita verso lo stato precedente.
Di seguito la legenda dei permessi:

  • c: create (disponibile solo per il primo stato del flusso)
  • r: read
  • w: write
  • d: delete
Viene, inoltre, fornito dettaglio dei TAB disponibili (quelli in sola lettura presentano il suffisso readonly)

StatoAttoriPermessiTransizioniTab
Bozza
(draft)
Helpdesk (helpdesk) c r w d validated
Responsabile/Proprietario (owner) r none
Tutor (tutor) r none
Organi dipartimentali (headOfDepartment) c r w validated
Validato
(validated)
Helpdesk (helpdesk) r reopened
Responsabile/Proprietario (owner) r none
Tutor (tutor) r none
Organi dipartimentali (headOfDepartment) r reopened
Riaperto
(reopened)
Helpdesk (helpdesk) r w d validated
Responsabile/Proprietario (owner) r none
Tutor (tutor) r none
Organi dipartimentali (headOfDepartment) r w validated

Validazioni

Nella seguente sezione viene riportato il dettaglio delle validazioni per tutte le coppie (attore, stato) del flusso.
Le validazioni sono distinte nei seguenti macrotipi e sono riferite, se non specificato altrimenti, all'oggetto radice.

  • enter: validazione applicata in ingresso nello stato
    La transizione in ingresso viene NEGATA se anche solo una validazione NON viene superata con successo.
  • save: validazione applicata ad ogni salvataggio e quindi anche per ogni spostamento di TAB
    Il salvataggio viene NEGATO se anche solo una validazione NON viene superata con successo.
  • delete: validazione applicata in fase di eliminazione di un oggetto radice
  • element: validazione applicata agli elementi figli di un oggetto radice
  • permissions: logiche di generazione dinamica dei permessi (rwfd) sull'oggetto radice che sovrascrive i permessi di flusso (rwfd)
Le validazioni sono ulteriormente distinte nei seguenti tipi.
  • required: validazione di obbligatorietà di un attributo sull'oggetto radice.
  • complex: validazione complessa applicabile sia all'oggetto radice che agli elementi.
    Per avere maggiori dettagli sulla validazione cliccare sull'identificativo della validazione
Nel caso di validazioni di tipo element, oltre all'identificativo della validazione, viene riportato anche l'identificativo dell'elemento a cui è applicata e l'azione che l'ha scatenata:
  • salvataggio (save)
  • eliminazione (delete)

Ad esempio la seguente stringa
internalOrganizationUnit:delete departmentDeleteValidator indica che la validazione "departmentDeleteValidator" è applicata in eliminazione di un elemento di tipo internalOrganizationUnit dell'oggetto radice.

Per avere maggiori dettagli sui possibili elementi fare riferimento alla definizione del modello, disponibile nella sezione Modello Dati.

Infine è possibile applicare le validazioni, condizionalmente al soddisfacimento di determinate condizioni (opzionali).
Queste condizioni sono specificate nella colonna "Applicabilità": se è specificato always, la validazione è sempre attiva.

StatoAttoriMacroTipoTipoAttributo/IdentificativoApplicabilita'
Bozza
(draft)
allenterrequiredwfItemTypeIdalways
descriptionalways
dateMap[startDate]always
personMap[owner]always
organizationUnitMap[department]always
complex checkCreationPermissionsValidator always
savecomplex sameDefinitionForGenericItemValidator always
Validato
(validated)
allenterrequireddescriptionalways
wfItemTypeIdalways
wfDictionaryMap[incomingType]always
organizationUnitMap[academicArea]always
dateMap[startDate]always
organizationUnitMap[department]always
complex ercValidatorMobilityIncoming always
startDateAndEndDateValidator always
externalOrganizationValidatorMobilityIncoming always
externalOrganizationAndRequestPendingValidatorMobilityIncoming always
savecomplex sameDefinitionForGenericItemValidator always
Riaperto
(reopened)
allsavecomplex sameDefinitionForGenericItemValidator always
deletePersonElementFromOldTutor always
Helpdesk (helpdesk) deletecomplex deleteAllPersonElementsLinkedToMobility always

Logiche (action/start)

Nella seguente sezione vengono riportate le

  • START LOGICS
    Le start logics sono le "azioni" che vengono eseguite in fase di creazione di un nuovo oggetto radice
  • ACTION LOGICS
    Le action logics sono delle "azioni" che vengono eseguite al verificarsi di determinati eventi.
    Gli eventi contemplati sono:
    • enter: ingresso in uno stato
    • save: salvataggio dell'oggetto radice
Di seguito viene riportato il dettaglio delle logiche definite per questo flusso.

START LOGICS

ACTION LOGICS