Versions Compared

Old Version 292

changes.mady.by.user proiris01@cineca.it proiris01@cineca.it

Saved on

compared with

New Version 293

changes.mady.by.user proiris01@cineca.it proiris01@cineca.it

Saved on

Key

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

Grafico del flusso

Descrizione

Il flusso equipment-flow è un flusso con validazione per il censimento di Grandi Attrezzature.

Questo flusso prevede i seguenti attori nelle diverse visioni.
  • Visione completa
    • Helpdesk - HD
      Team con profilo "Profilo Helpdesk per le Grandi Attrezzature (equipment)"
  • Visione dipartimentale
    • Organi dipartimentali - OD
      Utenti appartenenti al team con la seguente naming convention "Profilo di dipartimento per XXX", dove XXX è il nome del dipartimento
      Sono abilitati a questa visione tutti i dipartimenti presenti nella sezione "Dipartimenti di afferenza"
      Cfr modello dati TAB Informazioni generali
  • Visione personale
    • Responsabili scientifici - RS
      Persona appartenente al team "Utenti", che compare tra i responsabili delle Grandi Attrezzature.
      Cfr modello dati TAB Informazioni generali
    • Delegati - RD
      Persona appartenente al team "Utenti", che compare tra i delegati alla compilazione delle Grandi Attrezzature.
      Cfr modello dati TAB Informazioni generali

E' previsto un automatismo che aggiunge automaticamente il dipartimento a partire dall'afferenza del responsabile scientifico.
Per maggiori dettagli fare riferimento alla logica di start wfStartLogicMultipleOwners
Questo dipartimento può essere eventualmente rimosso e non viene effettuato, volutamente, nessun check di coerenza di afferenza del responsabile e relativo dipartimento.

Per la creazione dell'oggetto non è obbligatoria la presenza di un dipartimento per il responsabile scientifico a meno che non venga specificato il contrario tramite variabili di configurazione.
Per maggiori dettagli fare riferimento alla logica di validazione ownerPositionStartValidator

E' possibile configurare l'identificativo generato.
Per maggiori dettagli fare riferimento alla logica di start wfStartLogicIdentifier

Di default è consentita la creazione in visione personale per il responsabile (owner) con gestione Bottom-up, è possibile disabilitare questa funzione settanddo a false la variabile di cofigurazione ap.equipment-flow.owner.create con gestione Top-Down.
Per maggiori dettagli fare riferimento alla logica di start wfIdentityLogicOwnerSimplePermissionsJs

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.
Di default venegono utilizzate le etichette dei bottoni per lo stato successivo, è possibile configurare il flusso in maniera tale da utlizzare anche le etichette dei bottoni per lo stato precedente.
Esempio di utilizzo: l'oggetto si trova nello stato in attesa di essere validato, i possibili stati di cambio sono bozza e operativo. Il bottone per lo stato operativo utilizzerà l'etichetta per lo stato successivo, mentre il bottone per lo stato bozza utilizzerà l'etichetta per lo stato precedente.

Identificativo statoChiave etichetta statoValore default statoEtichetta del bottone stato successivoEtichetta del bottone stato precedenteValore etichetta del bottone stato successivoValore etichetta del bottone stato precedente
draftwfState.eqp.draftBozzabutton.forward.to.eqp.draftbutton.backward.to.eqp.draftSalva e invia in "Bozza"Salva e invia in "Bozza"
submittedwfState.eqp.submittedIn Validazionebutton.forward.to.eqp.submittedbutton.backward.to.eqp.submittedSalva e invia in "In Validazione"Salva e invia in "In Validazione"
rejectedwfState.eqp.rejectedNon Ammessobutton.forward.to.eqp.rejectedbutton.backward.to.eqp.rejectedSalva e invia in "Non Ammesso"Salva e invia in "Non Ammesso"
approvedwfState.eqp.approvedApprovatobutton.forward.to.eqp.approvedbutton.backward.to.eqp.approvedSalva e invia in "Approvato"Salva e invia in "Approvato"
reopenedwfState.eqp.reopenedRiapertobutton.forward.to.eqp.reopenedbutton.backward.to.eqp.reopenedSalva e invia in "Riaperto"Salva 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 (equipment - EQP)

Anchor
Permessi-anchor
Permessi-anchor

Configurazioni

Le configurazioni associate a questo flusso sono disponibili alla seguente pagina: Produzione - IRIS AP-RM Configurazioni: Grandi attrezzature (equipment - EQP)

Anchor
Configuration-anchor
Configuration-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
  • f: forward
Viene, inoltre, fornito dettaglio dei TAB disponibili (quelli in sola lettura presentano il suffisso readonly)

StatoAttoriPermessiTransizioniTab
Bozza
(draft) 		Helpdesk (helpdesk) c r w d f approved
Organi dipartimentali (department) c r w d f approved
Responsabile/Proprietario (owner) c r w d f submitted
Delegato (internalRepresentative) r w f submitted
In Validazione
(submitted) 		Helpdesk (helpdesk) r w f draft,rejected,approved
Organi dipartimentali (department) r w f draft,rejected,approved
Responsabile/Proprietario (owner) r none
Delegato (internalRepresentative) r none
Non Ammesso
(rejected) 		Helpdesk (helpdesk) r f submitted
Organi dipartimentali (department) r f submitted
Responsabile/Proprietario (owner) r none
Delegato (internalRepresentative) r none
Approvato
(approved) 		Helpdesk (helpdesk) r f submitted,reopened
Organi dipartimentali (department) r f submitted,reopened
Responsabile/Proprietario (owner) r f reopened
Delegato (internalRepresentative) r f reopened
Riaperto
(reopened) 		Helpdesk (helpdesk) r w d f approved
Organi dipartimentali (department) r w d f approved
Responsabile/Proprietario (owner) r w d f approved
Delegato (internalRepresentative) r w f approved

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.
Per avere maggiori dettagli sulle possibili condizioni di applicabilità e dei relativi parametri, fare riferimento alla lista completa nella sezione Definizione Apply Logic condivise.

StatoAttoriMacroTipoTipoAttributo/IdentificativoApplicabilita'
Bozza
(draft) 		allenterrequiredwfItemTypeId always
description always
dateMap[startDate] always
personMap[owner]
isNull ( id )
element:owner
isNotNull ( id )
complex checkCreationPermissionsValidator always
ownerPositionStartValidator always
ownerWithSameDepartmentAsHeadValidator always
transitionCommentValidator always
savecomplex purchaseValueInventoryGoodValidator always
sameDefinitionForGenericItemValidator always
deletecomplex childAndParentDetectorDeleteValidator always
elementrequiredowner:save  addOrgUnitFromNewOwnerValidator always
complexinternalOrganizationUnit:save  wfDictionaryMap[roleId] always
Organi dipartimentali (department) elementcomplexinternalOrganizationUnit:delete  departmentDeleteValidator always
Responsabile/Proprietario (owner) elementcomplexowner:save  notAllowedValidator
configTrue ( ap.equipment-flow.owner.create, false )
owner:delete  notAllowedValidator
configTrue ( ap.equipment-flow.owner.create, false )
internalOrganizationUnit:save  notAllowedValidator
configTrue ( ap.equipment-flow.owner.create, false )
internalOrganizationUnit:delete  notAllowedValidator
configTrue ( ap.equipment-flow.owner.create, false )
owner:save  currentUserCannotEditHimself
configTrue ( ap.equipment-flow.owner.create )
configFalse ( ap.eqp.personal-view.create-for-other-people.enabled )
owner:delete  currentUserCannotDeleteHimself
configTrue ( ap.equipment-flow.owner.create )
configFalse ( ap.eqp.personal-view.create-for-other-people.enabled )
permissionscomplex wfIdentityLogicOwnerSimplePermissionsJs always
Delegato (internalRepresentative) elementcomplexowner:save  notAllowedValidator always
owner:delete  notAllowedValidator always
internalOrganizationUnit:save  notAllowedValidator always
internalOrganizationUnit:delete  notAllowedValidator always
internalRepresentative:delete  currentUserCannotDeleteHimself always
permissionscomplex wfIdentityLogicOwnerSimplePermissionsJs always
In Validazione
(submitted) 		allenterrequiredwfItemTypeId always
description always
dateMap[startDate] always
clobMap[abstract] always
booleanMap[visibleOnPortal] always
booleanMap[inUse] always
stringMap[building] always
stringMap[room] always
numberMap[purchaseValue] always
stringMap[urlPublicCalendar]
booleanFieldTrue ( publicCalendar, false )
wfDictionaryMap[repairability]
booleanFieldFalse ( inUse, true )
organizationUnitMap[externalOrganizationOwner]
booleanFieldFalse ( internalOwnership, true )
stringMap[tariff]
dictionaryFieldValue ( application, applications.tariff, applications )
element:userType always
element:cpv always
element:multipleArchibusId always
element:internalOrganizationUnit always
element:owner always
element:esfriClassification always
element:equipmentCustomClassification always
complex inventoryGoodValidator always
dateCoverageAndOverlapValidator always
purchaseValueInventoryGoodValidator always
roleElementValidator always
savecomplex purchaseValueInventoryGoodValidator always
sameDefinitionForGenericItemValidator always
elementrequiredowner:save  addOrgUnitFromNewOwnerValidator always
complexinternalOrganizationUnit:save  wfDictionaryMap[roleId] always
Organi dipartimentali (department) elementcomplexinternalOrganizationUnit:delete  departmentDeleteValidator always
Non Ammesso
(rejected) 		allenterrequiredwfItemTypeId always
description always
dateMap[startDate] always
clobMap[abstract] always
booleanMap[visibleOnPortal] always
booleanMap[inUse] always
stringMap[building] always
stringMap[room] always
numberMap[purchaseValue] always
stringMap[urlPublicCalendar]
booleanFieldTrue ( publicCalendar, false )
wfDictionaryMap[repairability]
booleanFieldFalse ( inUse, true )
organizationUnitMap[externalOrganizationOwner]
booleanFieldFalse ( internalOwnership, true )
stringMap[tariff]
dictionaryFieldValue ( application, applications.tariff, applications )
element:internalOrganizationUnit always
element:owner always
element:esfriClassification always
complex purchaseValueInventoryGoodValidator always
savecomplex sameDefinitionForGenericItemValidator always
elementrequiredowner:save  addOrgUnitFromNewOwnerValidator always
complexinternalOrganizationUnit:save  wfDictionaryMap[roleId] always
Approvato
(approved) 		allenterrequiredwfItemTypeId always
description always
dateMap[startDate] always
clobMap[abstract] always
booleanMap[visibleOnPortal] always
booleanMap[inUse] always
stringMap[building] always
stringMap[room] always
numberMap[purchaseValue] always
stringMap[urlPublicCalendar]
booleanFieldTrue ( publicCalendar, false )
wfDictionaryMap[repairability]
booleanFieldFalse ( inUse, true )
organizationUnitMap[externalOrganizationOwner]
booleanFieldFalse ( internalOwnership, true )
stringMap[tariff]
dictionaryFieldValue ( application, applications.tariff, applications )
element:userType always
element:cpv always
element:multipleArchibusId always
element:internalOrganizationUnit always
element:owner always
element:esfriClassification always
element:equipmentCustomClassification always
complex inventoryGoodValidator always
dateCoverageAndOverlapValidator always
purchaseValueInventoryGoodValidator always
roleElementValidator always
savecomplex sameDefinitionForGenericItemValidator always
elementrequiredowner:save  addOrgUnitFromNewOwnerValidator always
complexinternalOrganizationUnit:save  wfDictionaryMap[roleId] always
Riaperto
(reopened) 		allenterrequiredwfItemTypeId always
description always
dateMap[startDate] always
savecomplex purchaseValueInventoryGoodValidator always
sameDefinitionForGenericItemValidator always
deletecomplex deleteRmItemEquipmentValidator always
childAndParentDetectorDeleteValidator always
elementcomplexowner:save  addOrgUnitFromNewOwnerValidator always
Organi dipartimentali (department) elementcomplexinternalOrganizationUnit:delete  departmentDeleteValidator always
Responsabile/Proprietario (owner) elementcomplexowner:save  notAllowedValidator
configTrue ( ap.equipment-flow.owner.create, false )
owner:delete  notAllowedValidator
configTrue ( ap.equipment-flow.owner.create, false )
internalOrganizationUnit:save  notAllowedValidator
configTrue ( ap.equipment-flow.owner.create, false )
internalOrganizationUnit:delete  notAllowedValidator
configTrue ( ap.equipment-flow.owner.create, false )
owner:save  currentUserCannotEditHimself
configTrue ( ap.equipment-flow.owner.create )
configFalse ( ap.eqp.personal-view.create-for-other-people.enabled )
owner:delete  currentUserCannotDeleteHimself
configTrue ( ap.equipment-flow.owner.create )
configFalse ( ap.eqp.personal-view.create-for-other-people.enabled )
permissionscomplex wfIdentityLogicOwnerSimplePermissionsJs always
Delegato (internalRepresentative) elementcomplexowner:save  notAllowedValidator always
owner:delete  notAllowedValidator always
internalOrganizationUnit:save  notAllowedValidator always
internalOrganizationUnit:delete  notAllowedValidator always
internalRepresentative:delete  currentUserCannotDeleteHimself always
permissionscomplex wfIdentityLogicOwnerSimplePermissionsJs 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