Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Grafico del flusso

Descrizione

Il flusso contract-centralized-flow è un flusso centralizzato che modella il ciclo di vita di un contratto, dalla proposta, all'ottenimento del servizio e dei successivi risultati.
Per informazioni sul modello dati, effettuare download del file excel disponibile al livello superiore.

Questo flusso prevede i seguenti attori nelle diverse visioni.

  • Visione completa
    • Helpdesk - HD
      Team con profilo "Profilo Helpdesk per i Progetti (project)"
    • Divisione Ricerca - DR
      Team con profilo "Profilo Divisione Ricerca"
    • Contabilità - CO
      Team con profilo "Profilo Contabilità"
  • Visione dipartimentale
    • Organi dipartimentali - OD
      Team con la seguente naming convention "Profilo di dipartimento per XXX", dove XXX è il nome del dipartimento
      La completa operatività su un dato contratto è consentita solo per il dipartimento marcato come "Principale"
      I dipartimenti aggregati avranno accesso in sola lettura.
  • Visione personale
    • Responsabili scientifici - RS
      Persona appartenente al team "Utenti", che compare tra i responsabili del progetto. Cfr modello dati (TAB Soggetti interni) disponibile al livello superiore
    • Partecipante - PA
      Persona appartenente al team "Utenti", che compare tra i partecipanti del progetto. Cfr modello dati (TAB Soggetti interni) disponibile al livello superiore
    • Referente amministrativo - RA
      Persona appartenente al team "Utenti", che compare tra i referenti amministrativi del progetto. Cfr modello dati (TAB Soggetti interni) disponibile al livello superiore

Trattandosi di un flusso centralizzato, la creazione di un nuovo contratto è consentita SOLO all' HD e DR.
Questo flusso consente all'HD di effettuare qualunque transizione di stato anche senza seguire il flusso canonico: è quindi possibile anche effettuare "salti" di stato.
Nel grafico, per chiarezza, vengono riportate però solo le transizioni di stato canoniche.
Inoltre, facciamo presente che gli stati in arancione sono gli stati di sincronizzazione con UGOV-PJ

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 dadded
Inserito
(added)
Helpdesk (helpdesk)r wdraft,validated
Responsabile scientifico (owner)r wnone
Validato
(validated)
Helpdesk (helpdesk)r wadded,signed,archived
Responsabile scientifico (owner)r wnone
Stipulato
(signed)
Helpdesk (helpdesk)r wvalidated,closed
Responsabile scientifico (owner)r wnone
Organi dipartimentali (headOfDepartment)rnone
Contabilita' (accountancy)rnone
Concluso
(closed)
Helpdesk (helpdesk)r wsigned
Responsabile scientifico (owner)r wnone
Organi dipartimentali (headOfDepartment)rnone
Contabilita' (accountancy)rnone
Archiviato
(archived)
Helpdesk (helpdesk)r wvalidated
Responsabile scientifico (owner)rnone

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.
    Per avere maggiori dettagli sugli attributi fare riferimento alla definizione del modello, disponibile al livello superiore
  • 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 eliminazionoe di un elemento di tipo internalOrganizationUnit dell'oggetto radice.
Per avere maggiori dettagli sui possibili elementi fare riferimento alla definizione del modello, disponibile al livello superiore.

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

StatoAttoriMacroTipoTipoAttributo/IdentificativoApplicabilita'
Bozza
(draft)
allenterrequiredwfItemTypeIdalways
dateMap[proposalStartDate]always
descriptionalways
complexcheckCreationPermissionsValidatoralways
ownerValidatorContractalways
elementrequiredowner:save  dateMap[startDate]always
Inserito
(added)
allenterrequiredwfItemTypeIdalways
dateMap[proposalStartDate]always
descriptionalways
complexownerValidatorContractalways
organizationUnitValidatorContractalways
elementrequiredowner:save  dateMap[startDate]always
Validato
(validated)
allenterrequiredwfItemTypeIdalways
dateMap[proposalStartDate]always
descriptionalways
complexownerValidatorContractalways
organizationUnitValidatorContractalways
elementrequiredowner:save  dateMap[startDate]always
Stipulato
(signed)
allenterrequiredwfItemTypeIdalways
descriptionalways
dateMap[proposalStartDate]always
dateMap[startDate]always
dateMap[endDate]always
wfDictionaryMap[currency]always
numberMap[totalAmount]always
complexuniqueIdentifierContractalways
ownerValidatorContractalways
organizationUnitValidatorContractalways
organizationUnitRoleValidatorContractalways
startDateAndEndDateValidatoralways
ownerAndOrganizationUnitMatchValidatorContractalways
checkDateExtensionValidatoralways
contributorAndOwnerStartDateValidatoralways
contributorAndOwnerValidatorWithStartEndDatealways
customerValidatorContractalways
currencyAndTotalAmountValidatorContractalways
wfUgovPjSenderValidatorContractalways
savecomplexcheckDateExtensionValidatoralways
contributorAndOwnerStartDateValidatoralways
contributorAndOwnerValidatorWithStartEndDatealways
elementrequiredowner:save  dateMap[startDate]always
Helpdesk (helpdesk)saverequireddescriptionalways
wfItemTypeIdalways
dateMap[startDate]always
dateMap[endDate]always
wfDictionaryMap[currency]always
numberMap[totalAmount]always
complexownerValidatorContractalways
organizationUnitValidatorContractalways
organizationUnitRoleValidatorContractalways
ownerAndOrganizationUnitMatchValidatorContractalways
customerValidatorContractalways
currencyAndTotalAmountValidatorContractalways
wfUgovPjSenderValidatorContractalways
Responsabile scientifico (owner)savecomplexwfUgovPjSenderValidatorContractalways
Concluso
(closed)
allenterrequireddescriptionalways
wfItemTypeIdalways
dateMap[proposalStartDate]always
dateMap[startDate]always
dateMap[endDate]always
wfDictionaryMap[currency]always
numberMap[totalAmount]always
complexownerValidatorContractalways
organizationUnitValidatorContractalways
organizationUnitRoleValidatorContractalways
startDateAndEndDateValidatoralways
ownerAndOrganizationUnitMatchValidatorContractalways
customerValidatorContractalways
contributorAndOwnerStartDateValidatoralways
contributorAndOwnerValidatorWithStartEndDatealways
checkDateExtensionValidatoralways
currencyAndTotalAmountValidatorContractalways
wfUgovPjSenderValidatorContractalways
savecomplexcheckDateExtensionValidatoralways
contributorAndOwnerStartDateValidatoralways
contributorAndOwnerValidatorWithStartEndDatealways
elementrequiredowner:save  dateMap[startDate]always
Helpdesk (helpdesk)saverequireddescriptionalways
wfItemTypeIdalways
dateMap[startDate]always
dateMap[endDate]always
wfDictionaryMap[currency]always
numberMap[totalAmount]always
complexownerValidatorContractalways
organizationUnitValidatorContractalways
organizationUnitRoleValidatorContractalways
ownerAndOrganizationUnitMatchValidatorContractalways
customerValidatorContractalways
currencyAndTotalAmountValidatorContractalways
wfUgovPjSenderValidatorContractalways
Responsabile scientifico (owner)savecomplexwfUgovPjSenderValidatorContractalways
Archiviato
(archived)
allelementrequiredowner:save  dateMap[startDate]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