Logiche condivise tra i vari flussi di AP ed RM
In questa pagina è presente la documentazione delle possibili logiche che si applicano ai flussi dei moduli di IRIS RM, AP e WF.
Consentono l'esecuzione automatica di operazioni di vario genere durante il flusso, ad esempio per impostare in automatico dei valori sull'item.
A seconda del loro utilizzo, queste logiche si dividono in diverse famiglie:
- Validation logics : controllano la consistenza dei dati inseriti prima di un salvataggio e/o una transizione di stato;
- Apply logics : definiscono sotto quali condizioni possono essere o non essere applicati i controlli generici di cui sopra;
- Start logics : possono essere invocate alla creazione di un nuovo oggetto, quindi alla partenza del relativo flusso;
- Action logics : possono essere invocate al salvataggio e/o in una transizione di stato;
Validate Logics
Elenco delle logiche che controllano la consistenza dei dati inseriti
linkedProjectTypeValidator
Questa validzione verifica che il campo "Tipo progetto associato" sia valorizzatoDal punto di vista del modello dati si tratta dell'attributo stringMap[linkedProjectType]
Per maggiori dettagli cfr. excel modello dati dell'entità Progetto
uniqueCodeValidator
Questa validazione controlla l'unicità del campo Codice bando.Dal punto di vista del modello dati si tratta dell'attributo stringMap[code].
Per maggiori dettagli cfr. excel modello dati dell'entità Bando di finanziamento.
checkHierarchyValidator
Questa logica controlla che la gerarchia dei Bandi sia consistente.Deve esserci un solo bando radice. Un bando radice non può avere un padre.
Un bando foglia non può avere a sua volta figli. Un bando figlio può essere orfano se non gerarchico.
configurationPresentValidatorFCO
Questa validazione controlla che sia valorizzata la configurazione rm.orgunit.external.myOrganization sia valorizzata.Nel caso in cui non lo sia, impedisce la creazione del Corso di Formazione Continua.
Essa deve essere valorizzata con l'ID Iris della Organizzazione Esterna che rappresenta l'Ateneo
Configurazioni della ValidateLogic:
continuousTrainingOrganizationUnitRoleValidator
Questa validazione controlla cheogni Dipartimento (internalOrganizationUnit) abbia un ruolo associato
solo un Dipartimento o Soggetto terzo abbia il ruolo di Coordinatore
Per maggiori dettagli cfr. modello dati dell'entità in questione.
continuousTrainingFinancingValidator
Questa validazione controlla che la somma dei vari finanziamenti inserita(calcolata) sia quella effettivamente corretta.I dati che sono presi in considerazione sono:
- Eventuale importo percepito per la convenzione (receivedFinancing)
- Eventuali quote totali di iscrizione al corso (totalSubscriptionFees)
- Eventuali altre entrate (otherFinancing)
- Introiti complessivi (totalIncome)
continuousTrainingParticipantsValidator
Questa validazione controlla che la somma dei vari partecipanti 'inserita'(calcolata) sia quella effettivamente corretta.I dati che sono presi in considerazione sono:
Numero Istituzioni Pubbliche (numberOfPublicInstitutions)
Numero di Imprese (numberOfCompanies)
Numero di imprese del Terzo Settore (numberOfThirdSector)
Numero di altri partecipanti (numberOfOtherParticipants)
Numero totali di partecipanti al corso (totalNumberOfParticipants)
Per maggiori dettagli cfr. modello dati dell'entità in questione.
continuousTrainingNumberOfInternalTeachersValidator
Questa validazione verifica che la somma dei docenti inserita (Numero dei docenti interni coinvolti nel corso - numberOfInternalTeachers) sia quella effettivamente corretta.Se una persona viene inserita sia nei Responsabili scientifici e nei Componenti interni viene contata come una unica persona.
Per maggiori dettagli cfr. il modello modello dati dell entità in questione.
continuousTrainingMultipleYearValidator
Questa validazione verifica che gli "Anni solari di svolgimento del corso" siano coerenti con le date di inizio e fine inserite.Se c'è almeno un elemento, devono essere obbligatoriamente presenti gli anni estratti dalla data di inizio e di fine del corso.
Gli anni inseriti devono essere all'interno del range delle date di inizio e di fine del corso.
Se la data di fine non è valorizzata, gli anni inseriti devono essere maggiori o uguali dell'anno estratto dalla data di inizio.
Se la data di inizio non è valorizzata (nonostante sia un campo obbligatorio), gli anni inseriti devono essere minori o uguali dell'anno estratto dalla data di fine.
Per maggiori dettagli cfr. il modello modello dati dell entità in questione.
currencyAndTotalAmountValidatorContract
Questa validazione controlla che nel tab "Corrispettivi", nel caso di selezione di valuta diversa da EURO, vengano specificati- importo in valuta originaria
- tasso di cambio
- data rilevazione tasso di cambio
Dal punto di vista del modello dati si tratta degli attributi:
- totalAmountOriginalCurrency
- exchangeRate
- exchangeRateDate
wfUgovPjSenderValidatorContract
Questa logica, effettua check di consistenza sulle mappature degli oggetti IRIS/UGOV e, se superati, invia il contratto verso UGOV PJ rispettando le regole di NON SOVRASCRITTURA lato UGOV PJ.Per maggiori dettagli su queste regole consultare il team di UGOV PJ.
Le controparti dei contratti IRIS vengono create su UGOV con le regole di mappature delle tassonomie che vengono condivise in fase di attivazione.
Se in corso d'opera dovesse nascere l'esigenza di censire delle nuove tipologie è possibile contattare l'HD.
Di seguito vengono riportate le informazioni inviate ad UGOV PJ, con la specifica dell'attributo del modello dell'entità Contratto IRIS
- Codice contratto: identifier
- Nome contratto: description troncata a 255 caratteri per limitazioni lato UGOV PJ
- Importo contratto totalAmount
L'invio viene effettuato se l'importo è non nullo e maggiore di zero. - Data inizio validità: startDate.
- Data fine validità: endDate.
- Data proroga uffciale:
Viene usato l'attributo endDate se sono prensenti delle proroghe (elementi di tipo extension).
Viene inviato null se non sono prensenti delle proroghe (elementi di tipo extension). - Data fine validità: endDate
- Riferimento Data Management System (Sistema Documentale): externalDmsIdentifier
Inviato l'identifier del contratto se valorizzata a true la variabile di configurazione ap.con.externalDmsIdentifier.autogenerated, di default questa NON è definita.
In tutti gli altri casi viene inviato externalDmsIdentifier. - Responsabili scientifici: owner
Inviate anche date di inizio e fine se valorizzata a true la variabile di configurazione ap.con.owner.starDate.required, di default questa NON è definita.
La data di fine viene inviata SOLO se minore della data recuperata dalla configurazione ap.<wfItemType>.contributorAndOwner.validator.date.end.discriminator. - Partecipanti: contributor
Inviate anche date di inizio e fine se valorizzata a true la variabile di configurazione ap.con.contributor.starDate.required, di default questa NON è definita.
La data di fine viene inviata SOLO se minore della data recuperata dalla configurazione ap.<wfItemType>.contributorAndOwner.validator.date.end.discriminator. - Referenti interni: administrativeOwner
Inviati se valorizzata a true la variabile di configurazione ap.con.administrativeOwner.send2ugov.enabled.
In caso di invio viene valuatata anche la configurazione ap.con.administrativeOwner.role.ugov.default in cui bisogna specificare l'identificativo del ruolo PJ.
Inviate anche date di inizio e fine se valorizzata a true la variabile di configurazione ap.con.administrativeOwner.starDate.required.
La data di fine viene inviata SOLO se minore della data recuperata dalla configurazione ap.<wfItemType>.contributorAndOwner.validator.date.end.discriminator. - Unità organizzative interne: internalOrganizationUnit
- Enti Committenti: customer
Inviato se valorizzata a true (che è anche il valore di default) la variabile di configurazione ap.con.customer.send2ugov.enabled. - Tipo contratto: come da mappatura tassonomia ap-item-type.xls
- Schema di finanziamento: come da mappatura tassonomia ap-item-type.xls
- Stato contratto: come da mappatura tassonomia ap-item-type.xls
Per maggiori dettagli cfr. excel modello dati dell'entità Contratto
Configurazioni della ValidateLogic:
- ap.con.customer.send2ugov.enabled
- ap.con.cup.send2ugov.enabled
- ap.con.externalDmsIdentifier.autogenerated
- ap.con.administrativeOwner.starDate.required
- ap.con.contributor.starDate.required
- ap.TIPOLOGIA.contributorAndOwner.validator.date.end.discriminator
- ap.con.administrativeOwner.role.ugov.default
- ap.con.administrativeOwner.send2ugov.enabled
deleteRmItemEquipmentValidator
Questa validazione va a cancellare i dati relativi al'rmItem equipment quando viene cancellato l'oggetto padre wfItem.Per maggiori dettagli cfr. il modello dati dell'entità in questione.
purchaseValueInventoryGoodValidator
Questa validazione verifica che, se il calcolo automatico è attivato, il valore di acquisto totale sia la somma dei singoli valori di acquisto dei beni di inventario che sono stati importati da UGOV.Il messaggio di errore è contenuto nell'etichetta error.equipment.autocalculatedInventoryGoodsTotalValue.inconsistent.
Per maggiori dettagli cfr. il modello modello dati dell'entità in questione.
Configurazioni della ValidateLogic:
inventoryGoodValidator
Questa validazione verifica che, sia presente almeno un bene di inventario recuperato da UGOV.Se non ce n'è nemmeno uno viene chiesto all'utente conferma a procedere e se viene fornita conferma viene chiesta la motivazione per la quale non sia possibile recuperare beni di inventario da UGOV.
Configurazioni della ValidateLogic:
deleteAllPersonElementsLinkedToMobility
Questa logica si occupa di eliminare dai profili personali del tutor/persona in ingresso (CV Scientifico) il collegamento tra le due persone.Questa logica viene triggerata in fase di eliminazione.
externalOrganizationAndRequestPendingValidatorMobilityIncoming
Questa validazione controlla che non sia presente sia una istituzione esterna (da anagrafica) che la richiesta di inserimento.Per maggiori dettagli cfr. modello dati della Mobilità in ingresso
inheritanceElementPatentValidator
Questa validazione verifica che le seguenti sezioni siano compilate (sia presente almeno un elemento per ciascuna di esse):- Domanda di Deposito (application)
- Technology Readiness Level (trl)
- Area Tematica (ipTopic)
Se è presente un brevetto padre collegato (è una estensione), controlla se il corrente brevetto o il padre hanno gli elementi indicati sopra.
Per maggiori dettagli cfr. il modello modello dati dell'entità in questione.
cupInheritanceValidator
Questa validazione verifica che sia inserito il CUP (cup).Controllo prima se ho un brevetto padre collegato
Se non ne ho, sono un prioritario e controllo se ho degli elementi "miei"
Se ne ho, sono una estensione, controllo prima gli elementi "miei" e poi quelli di mio padre
Per maggiori dettagli cfr. il modello modello dati dell'entità in questione.
priorityExtensionLinkDeleteValidator
Questa è una validazione che viene chiamata nel flusso dei Brevetti quando si prova ad eliminare un Brevetto prioritario.Essa impedisce che si possa eliminare l'oggetto se è collegato ad uno o più Brevetti figli.
In caso la logica trovasse questi collegamenti, verrà presentato un messaggio di errore che avviserà dei link presenti e inviterà ad eliminarli per procedere.
Il messaggio di errore viene ricavato dall'etichetta con chiave error.patent.priorityExtensionLink.toDelete
Per maggiori dettagli cfr. modello dati dell'entità specifica.
intellectualPropertyApplicantValidator
Questa validazione controlla le percentuali di titolarità.Verifica che sia presente almeno un titolare.
Verifica che se almeno un titolare ha la percentuale di titolarità, allora anche gli altri devono avere una percentuale.
Questa validazione scatta sempre, per disattivarla bisogna settare a false la configurazione ap.pat.ownership.percentage.enabled.
Se la configurazione ap.pat.ownership.percentage.enabled è settata a false nel fragment della titolarità non verrà visualizzato il campo relativo alla percentuale.
Per maggiori dettagli cfr. excel modello dati dell'entità Proprietà Intellettuali.
intellectualPropertyOwnershipValidator
Questa validazione controlla che la somma delle percentuali di titolarità sia 100.Questa validazione scatta sempre, per disattivarla bisogna settare a false la configurazione ap.pat.ownership.percentage.enabled.
Se la configurazione ap.pat.ownership.percentage.enabled è settata a false nel fragment della titolarità non verrà visualizzato il campo relativo alla percentuale.
Per maggiori dettagli cfr. excel modello dati dell'entità Proprietà Intellettuali.
uniquePatentValidator
Validator che controlla che non esista un'altra Proprietà Intellettuale con lo stesso Numero di Deposito.Dal punto di vista del modello dati si tratta dell'attributo stringMamp[applicationNumber].
Per maggiori dettagli cfr. excel modello dati dell'entità Progetto
bookEntryTotalPatentValidator
Questa validazione verifica la somma dei Costi inseriti.In particolare verifica che il valore dell'attributo numberMap[bookEntryTotal] sia uguale alla somma degli attributi numberMap[amount] presenti nella sezione "Costi".
Dal punto di vista del modello dati si tratta degli attributi numberMap[bookEntryTotal], numberMap[amount] e l'elemento bookEntry.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
lastLegalStatusCalculatorPatent
Questa validazione si occupa, ad ogni salvataggio, di a cercare l'ultimo Status Legale valido basandosi sulla Data di Registrazione e salvarne la voce in un metadato nascosto.In particolare va a cercare tra gli elementi con discriminator legalStatus e ne va a valutare la data all'interno di dateMap[registrationStatus].
La voce di dizionario presente in wfDictionaryMap[status] viene poi salvata all'interno di wfItem.wfDictionaryMap[lastLegalStatus].
Per maggiori dettagli cfr. modello dati dell'entità in questione.
startPatentValidator
Questa validazione viene eseguita in fase di creazione di un Brevetto e verifica:- Verifica che sia compilato il campo "Titolo" SOLO se l'utente ha deciso di NON recuperare i metadati da EPO
- Verifica che sia compilato il campo "Data di deposito" SOLO se l'utente ha deciso di NON recuperare i metadati da EPO.
- Verifica che sia compilato il campo "PI Prioritaria" SOLO se l'utente ha deciso di NON recuperare i metadati da EPO e che il corrente Brevetto NON è prioritario
Per maggiori dettagli cfr. modello dati dell'entità in questione.
priorityExtensionLinkPatentValidator
Questa validazione viene effettuata durante il salvataggio di un Brevetto mentre è nello stato Bozza.Essa controlla se al Brevetto Estensione corrente si sta cancellando il link verso il Prioritario.
Nel caso l'utente lo stia eliminando, chiede di confermare la scelta.
Se l'utente non conferma, la validazione continua a bloccarlo fino a quando non inserisce un collegamento ad un Prioritario.
Se l'utente conferma, a quel punto il Brevetto Estensione corrente viene trasformato in Prioritario.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
familyIdentifierPriorityExtensionPatentValidator
Questa validazione viene effettuata durante il salvataggio di un Brevetto.Essa controlla se al Brevetto Estensione corrente si sta aggiungendo un Identificativo Famiglia uguale a quello del Prioritario.
Nel caso in cui succeda, verrà segnalato attraverso un messaggio di errore che chiederà di andare ad attivare il prelievo del dato dal Prioritario.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
projectDepartmentFundCreateValidator
Questa validazione viene eseguita in ingresso allo stato draft per i progetti per il fondo di Ateneo (ATE).Viene consentita la creazione di una nuova scheda solo nell'intervallo previsto per la campagna in corso.
Questo intervallo viene definito con le configurazioni:
- DEPARTMENT_FUND_START_DATE
- DEPARTMENT_FUND_END_DATE
projectDepartmentFundTeamValidator
Questa validazione viene eseguita in ingresso allo stato draft per i progetti per il fondo di Ateneo (ATE).Viene avviata una nuova scheda solo se il responsabile è contenuto nell apposito team denominato:
Team docenti e ricercatori per i progetti di Ateneo.
La validazione consente la creazione della scheda solo se la persona selezionata ha un utente agganciato censito nel team con id presente nella conf ap.project.departmentFund.team.start
La validazione usa anche le seguenti conf:
- DEPARTMENT_FUND_POSITION_SERVICE_DATE
- DEPARTMENT_FUND_POSITION_LAST_DATE
projectDepartmentFundCheckDateEnterValidator
Questa validazione viene eseguita in ingresso ad ogni stato per i progetti per il fondo di Ateneo (ATE).Vengono controllate le date delle fasi successive prima di procedere con lo spostamento di stato per evitare
di portare troppo in avanti nel flusso il progetto rispetto alle date previste dalla campagna.
grantorUniquenessValidator
Questa validazione controlla:- in fase di aggiunta di un Ente finanziatore che NON sia già censito lo stesso Ente finanziatore con lo stesso Numero contratto PER TUTTI GLI ITEM
- in fase di salvataggio/spostamento del Progetto che NON siano presenti più di una volta gli stessi Enti finanziatori con gli stessi Numeri contratto PER TUTTI GLI ITEM
La validazione necessità di:
- discriminator dell'elemento
- flag booleano che specifica o meno se elementi duplicati sono ammessi all'interno dello stesso wfItem
- un numero arbitrario di attributi che possono essere scelti nelle mappe organizationUnitMap e stringMap
Dal punto di vista del modello dati si tratta degli elementi di tipo grantor e degli attributi organizationUnitMap[grantorId], stringMap[grantNumber].
La validazione è disattivata di default tramite configurazione standard (ap.prj.validation.grantorUniquenessValidator.enabled è settata a false) perché non è detto che tutte le istanze abbiano dati puliti per passare la validazione o che abbiano visibile il metadato grantNumber
Per abilitare la validazione è necessario settare a true la conf indicata prima.
Per maggiori dettagli cfr. excel modello dati dell'entità Progetto.
grantorCallValidatorProject
Questa validazione controlla in fase di inserimento dell Ente finanziatore, SOLO se il Bando collegato viene compilato, che sia presente tale bando nella sezione Bandi del Progetto (callProjectLink).La variabile di configurazione ap.<wfItemType>.callProjectLink.inheritFromGrantor (valore di default false) guida il comportamento della validazione.
Se è false o non presente e non è presente in nessun aggancio fra i Bandi del Progetto (callProjectLink) viene sollevato errore.
Se è true allora se il Bando associato all Ente è presente viene inserito automaticamente il link in callProjectLink (se non già presente)
Il validator esegue sempre lo stesso controllo di consistenza ma nel caso di configurazione a true inserisce il dato necessario.
Dal punto di vista del modello dati si tratta degli elementi di tipo grantor con attributo wfItem[callId], e dei link di tipo callProjectLink.
Per maggiori dettagli cfr. excel modello dati dell'entità Progetto.
Configurazioni della ValidateLogic:
checkInconsistentGrantorCallValidatorProject
Questa validazione controlla che, per ogni Bando di Finanziamento associato a un Ente finanziatore,ci sia il corrispondente Bando collegato nella scheda Progetto.
Dal punto di vista del modello dati si tratta degli elementi di tipo grantor con attributo wfItem[callId], e dei link di tipo callProjectLink.
Per maggiori dettagli cfr. excel modello dati dell'entità Progetto.
Configurazioni della ValidateLogic:
callProjectLinkDeleteValidatorProject
Questa validazione controlla che non si sia uno specifico Bando associato a un Ente Finanziatore quando si prova ad effettuare la cancellazionedi un collegamento Progetto-Bando.
Dal punto di vista del modello dati si tratta degli elementi di tipo grantor con attributo wfItem[callId], e dei link di tipo callProjectLink.
Per maggiori dettagli cfr. excel modello dati dell'entità Progetto.
wfUgovPjSenderValidatorProject
Questa logica, effettua check di consistenza sulle mappature degli oggetti IRIS/UGOV e, se superati, invia il progetto verso UGOV PJ rispettando le regole di NON SOVRASCRITTURA lato UGOV PJ.Per maggiori dettagli su queste regole consultare il team di UGOV PJ.
Le controparti dei progetti IRIS vengono create su UGOV con le regole di mappature delle tassonomie che vengono condivise in fase di attivazione.
Se in corso d'opera dovesse nascere l'esigenza di censire delle nuove tipologie è possibile contattare l'HD.
Di seguito vengono riportate le informazioni inviate ad UGOV PJ, con la specifica dell'attributo del modello dell'entità Progetto IRIS
- Codice progetto: identifier
- Nome progetto
Viene valutata la variabile di configurazione ap.prj.descriptionAndGrantNumberConcatenationEnabled.
Se valorizzata a true allora vengono usati gli attributi concatenati stringMap[grantNumber]-description. Se stringMap[grantNumber] è nullo allora viene usato solo l'attributo description (senza nemmeno il trattino), se description è nullo allora viene usato solo l'attributo stringMap[grantNumber] (senza nemmeno il trattino).
Se NON valorizzata a true allora viene usato l'attributo description.
In ogni caso la stringa verrà troncata a 255 caratteri per limitazioni lato UGOV PJ (se il numero di caratteri sarà maggiore). - Importo progetto
Configurazione per invio a PJ classica:
Viene valutata la variabile di configurazione ap.prj.financing.internalCost.send2ugov.forced.
Se valorizzata a true allora viene usato l'attributo internalCost
Se NON valorizzata a true allora- Se l'ateneo è capofila allora viene inviato il risultato della seguente formula globalContribution+internalCofinancing+manHoursCofinancing.
E' possibile disabilitare questa verifica su una determinata tipologia di progetti (itemType), e di conseguenza non verrà inviato il risultato della seguente formula globalContribution+internalCofinancing+manHoursCofinancing (per la Ricerca non competitiva), settando a false la variabile di configurazione ap.PARAMETRIC_TYPE_LOWER_CASE.partner.main.required.
Esempio variabile: ap.prj.research.int.partner.main.required. In tutti gli altri casi il controllo verrà fatto. - Se l'ateneo NON è capofila allora viene inviato internalCost
Configurazione per invio a PJ con switchToContribution attivo (il default è false, non attivo):
Viene valutata la variabile di configurazione ap.prj.financing.switchToContribution.enabled.
Se valorizzata a true e anche ap.prj.financing.internalCost.send2ugov.forced è valorizzata a true viene usato l'attributo internalContribution.
Se valorizzata a true e invece ap.prj.financing.internalCost.send2ugov.forced è valorizzata a false, allora viene valutato se l'ateneo è capofila.- Se l'ateneo è capofila allora viene inviato l'attributo globalContribution .
- Se l'ateneo NON è capofila allora viene inviato internalContribution
Una tabella riassuntiva:
FORCED = configurazione ap.prj.financing.internalCost.send2ugov.forced
SWITCH = configurazione ap.prj.financing.switchToContribution.enabled
CAPOFILA = possibili valori nella tabellina dei Partner, per capofila si intende che l’Ateneo è CoordinatoreL'invio viene effettuato se l'importo è non nullo e maggiore di zero.FORCED SWITCH con CAPOFILA impPj (PJ importo progetto) ContrTotOttenuto false false No internalCost internalContribution false false Sì globalContribution
+internalCofinancing
+manHoursCofinancinginternalContribution false true No internalContribution internalCost false true Sì globalContribution internalCost true false Indiff. internalCost internalContribution true true Indiff. internalContribution internalCost - Se l'ateneo è capofila allora viene inviato il risultato della seguente formula globalContribution+internalCofinancing+manHoursCofinancing.
E' possibile disabilitare questa verifica su una determinata tipologia di progetti (itemType), e di conseguenza non verrà inviato il risultato della seguente formula globalContribution+internalCofinancing+manHoursCofinancing (per la Ricerca non competitiva), settando a false la variabile di configurazione ap.PARAMETRIC_TYPE_LOWER_CASE.partner.main.required.
- Data inizio validità:
Viene usato l'attributo startDate. - Data fine validità:
Viene usato l'attributo endDate. - Data inizio validità del progetto dal punto di vista contabile:
Viene usato l'attributo expenditureStartDate. - Data fine validità del progetto dal punto di vista contabile:
Viene usato l'attributo expenditureEndDate. - Data proroga uffciale:
Viene usato l'attributo endDate se sono prensenti delle proroghe (elementi di tipo extension).
Viene inviato null se non sono prensenti delle proroghe (elementi di tipo extension). - CUP: cup
Inviato se valorizzata a true la variabile di configurazione ap.prj.cup.send2ugov.enabled.
Se l'invio del CUP è abilitato e UGOV PJ restituisce l'errore Attenzione: CUP XXXXXXX non trovato vuol dire che il CUP che IRIS AP sta tentando di inviare a UGOV PJ non è stato trovato su UGOV CO.
E' necessario quindi inserire quel CUP in UGOV CO prima di potere effettuare invio, oppure è possibile disatttivare l'invio settando ap.prj.cup.send2ugov.enabled al valore false - Riferimento Data Management System (Sistema Documentale): externalDmsIdentifier
Inviato l'identifier del progetto se valorizzata a true la variabile di configurazione ap.prj.externalDmsIdentifier.autogenerated, in tutti gli altri casi viene inviato externalDmsIdentifier. - Responsabili scientifici: owner
Inviate anche date di inizio e fine se valorizzata a true la variabile di configurazione ap.prj.owner.starDate.required.
La data di fine viene inviata SOLO se minore della data recuperata dalla configurazione ap.<wfItemType>.contributorAndOwner.validator.date.end.discriminator.
Per i Responsabili scientifici, nella scheda, può essere visibile il Ruolo (visibilità pilotata da configuration standard di tipo hidden)
E' buona cosa inserire prima nel flusso, in caso di attivazione dei ruoli, la validazione ownerRoleSend2UgovValidatorProject, a cui è delegata la correttezza dei dati. - Partecipanti: contributor
Inviate anche date di inizio e fine se valorizzata a true la variabile di configurazione ap.prj.contributor.starDate.required.
La data di fine viene inviata SOLO se minore della data recuperata dalla configurazione ap.<wfItemType>.contributorAndOwner.validator.date.end.discriminator. - Referenti interni: administrativeOwner
Inviati se valorizzata a true la variabile di configurazione ap.prj.administrativeOwner.send2ugov.enabled.
In caso di invio viene valuatata anche la configurazione ap.prj.administrativeOwner.role.ugov.default in cui bisogna specificare l'identificativo del ruolo PJ.
Inviate anche date di inizio e fine se valorizzata a true la variabile di configurazione ap.prj.administrativeOwner.starDate.required.
La data di fine viene inviata SOLO se minore della data recuperata dalla configurazione ap.<wfItemType>.contributorAndOwner.validator.date.end.discriminator. - Unità organizzative interne: internalOrganizationUnit
- Finanziatori: grantor
Inviato se valorizzata a true la variabile di configurazione ap.prj.grantor.send2ugov.enabled.
Se valorizzata a true la configurazione ap.prj.grantor.financingQuota.send2ugov.enabled le quote di finanziamento vengono inviate a PJ. - Partner: partner
Inviato se valorizzata a true la variabile di configurazione ap.prj.partner.send2ugov.enabled. - Tipo progetto: come da mappatura tassonomia ap-item-type.xls
- Schema di finanziamento: come da mappatura tassonomia ap-item-type.xls
- Stato progetto: come da mappatura tassonomia ap-item-type.xls
Per maggiori dettagli cfr. excel modello dati dell'entità Progetto
Configurazioni della ValidateLogic:
- ap.TIPOLOGIA.partner.main.required
- ap.prj.administrativeOwner.role.ugov.default
- ap.prj.grantor.send2ugov.enabled
- ap.prj.partner.send2ugov.enabled
- ap.TIPOLOGIA.FRAGMENT.role.main
- rm.orgunit.external.myOrganization
- ap.prj.financing.internalCost.send2ugov.forced
- ap.prj.descriptionAndGrantNumberConcatenationEnabled
- ap.prj.cup.send2ugov.enabled
- ap.prj.externalDmsIdentifier.autogenerated
- ap.prj.contributor.starDate.required
- ap.prj.administrativeOwner.send2ugov.enabled
- ap.prj.owner.starDate.required
- ap.prj.grantor.financingQuota.send2ugov.enabled
externalAccountancyProjectValidator
Questa validazione viene eseguita SOLO se la conf ap.accountancy.enabled è settata a true e serve per gestire l'aggancio con sistemi di contabilità esterni e le regole di generazione degli identificativi contabili.E' attiva SOLO per UNICATT e NON VA ATTIVATA per altri Atenei: quindi NON INSERIRE la conf ap.accountancy.enabled con valore true.
La validazione è montata SOLO sul flusso project-centralized-flow in enter e save dallo stato operative in poi. La validazione controlla la coerenza degli attributi grantor ed in particolare quelli attivati dalla conf ap.accountancy.enabled. Per maggiori dettagli fare riferimento alla descrizione presente nel modello dati di grantor. La validazione verifica anche che
- se progetto è da bando esterno allora tutte le tranche di finanziamento devono avere lo stesso stringMap[accountancyIdentifier]
- se progetto da bando interno allora le tranche di finanziamento erogate da bandi dello stesso tipo devono avere lo stesso stringMap[accountancyIdentifier]
Questo check è pleonastico perché per le linee interne il check viene fatto in fase di import da PICA
- ap.<wfItemType>.accountancy.grantor.accountancyIdentifier.generation
I valori possibili sono- project
Indica che per la tipologia di progetto in oggetto la generazione dell'identificativo contabile si basa sul progetto stesso - call
Indica che per la tipologia di progetto in oggetto la generazione dell'identificativo contabile si basa sul bando collegato al progetto corrente
- project
- ap.<wfItemType>.accountancy.grantor.accountancyIdentifier.sameValueEnforcedForCallType.csv
Indica le tipologie di call per le quali deve essere verificata univocità degli identificativi contabili (applicabile se ap.<wfItemType>.accountancy.grantor.accountancyIdentifier.generation valorizzata con call) - ap.<wfItemType>.accountancy.grantor.accountancyIdentifier.differentValuesAllowed
Indica se è consentito avere identificativi contabili differenti (applicabile se ap.<wfItemType>.accountancy.grantor.accountancyIdentifier.generation valorizzata con project)
Configurazioni della ValidateLogic:
- ap.accountancy.enabled
- ap.TIPOLOGIA.accountancy.grantor.accountancyIdentifier.generation
- ap.TIPOLOGIA.accountancy.grantor.accountancyIdentifier.sameValueEnforcedForCallType.csv
- ap.TIPOLOGIA.accountancy.grantor.accountancyIdentifier.differentValuesAllowed
externalAccountancyIdentifierGrantorValidator
Questa validazione è la gemella di externalAccountancyProjectValidator.A differenza di externalAccountancyProjectValidator, questa opera sul singolo elemento grantor
Configurazioni della ValidateLogic:
- ap.accountancy.enabled
- ap.TIPOLOGIA.accountancy.grantor.accountancyIdentifier.generation
- ap.TIPOLOGIA.accountancy.grantor.accountancyIdentifier.sameValueEnforcedForCallType.csv
- ap.TIPOLOGIA.accountancy.grantor.accountancyIdentifier.differentValuesAllowed
ethicCommiteeDeleteInconsistentDataProject
Questa validazione controlla che se non sono previste attività di ricerca che prevedono sperimentazioni passibili di giudizio da parte del Comitato Etico e che se non è stata presentata la richiesta di parere all'OPBA o al Comitato Etico di Ateneo di riferimento o al Comitato Etico di un Ente Terzo che ha facoltà di concedere questo tipo di autorizzazioni.I dati particolari di queste sottosezioni vengono svuotati se viene selezionato NO.
Dal punto di vista del modello dati si tratta degli elementi di tipo ethicCommiteeTopic.
Per maggiori dettagli cfr. excel modello dati dell'entità Progetto.
ownerRoleSend2UgovValidatorProject
Questa validazione opera sugli elementi owner (responsabile scientifico) figli dell'oggetto radice.Viene verificato che esista almeno un responsabile scientifico da inviare ad UGOV PJ, e che il loro numero non superi un valore massimo configurabile.
Il parametro per il numero massimo è ap.prj.owner.send2ugov.number, che se valorizzato deve essere un numero maggiore di 0: se non valorizzato non c'è limite.
Per i Responsabili scientifici, nella scheda, può essere visibile il Ruolo (visibilità pilotata da configuration standard di tipo hidden).
In tal caso è possibile limitare il conteggio ad una lista di ruoli da sincronizzare con PJ, mediante il parametro ap.prj.owner.send2ugov.roles (formato: comma separated dei codici di dizionario).
Configurazioni della ValidateLogic:
internalOrganizationUnitCostRequiredValidatorProject
Questa validazione controlla la sezione "Strutture Interne" presente nel tab "Finanziamento" e valuta le configurazioni ap.prj.internalOrganizationUnitCost.requireOneForEveryInternalOrganizationUnit.enabled e ap.prj.internalOrganizationUnitCost.notMandatoryIfOnlyOneInternalOrganizationUnit.enabled.Le strutture selezionabili sono solo quelle presenti nella sezione "Strutture Interne" nel tab "Soggetti interni".
In base alla casistica è necessario customizzare l'etichetta label.prj.internalOrganizationUnitCost.warning con i valori indicati di seguito, il contenuto di questa etichetta viene visualizzato nel tooltip del punto interrogativo di finaco al nome della sezione "Strutture Interne" presente nel tab "Finanziamento"
requireOneForEveryInternalOrganizationUnit | notMandatoryIfOnlyOneInternalOrganizationUnit | Controllo | Testo etichetta |
---|---|---|---|
true | true |
|
Se viene inserita più di una struttura nella sezione "Strutture interne" del TAB "Soggetti interni" è necessario che ognuna di queste sia riportata in questa sezione, viceversa se viene inserita solo una struttura nella sezione "Strutture interne" del TAB "Soggetti interni" NON è necessario compilare questa sezione, in quanto si presume che tutto il finanziamento vada all'unica struttura. |
false/non presente | false/non presente |
|
NON NECESSARIO (viene utilizzata l'etichetta di default) |
true | false/non presente |
|
E' necessario che ognuna delle strutture inserite nella sezione "Strutture interne" del TAB "Soggetti interni" sia riportata in questa sezione. |
false/non presente | true |
|
Se viene inserita più di una struttura nella sezione "Strutture interne" del TAB "Soggetti interni" è necessario che una di queste sia riportata in questa sezione, viceversa se viene inserita solo una struttura nella sezione "Strutture interne" del TAB "Soggetti interni" NON è necessario compilare questa sezione, in quanto si presume che tutto il finanziamento vada all'unica struttura. |
Dal punto di vista del modello dati si tratta degli elementi di tipo internalOrganizationUnitCost (elemento della sezione "Strutture Interne" presente nel tab "Finanziamento") e internalOrganizationUnit (elemento della sezione "Strutture Interne" presente nel tab "Soggetti interni")
Per maggiori dettagli cfr. excel modello dati dell'entità Progetto
Configurazioni della ValidateLogic:
- ap.prj.internalOrganizationUnitCost.requireOneForEveryInternalOrganizationUnit.enabled
- ap.prj.internalOrganizationUnitCost.notMandatoryIfOnlyOneInternalOrganizationUnit.enabled
ethicCommiteeValidatorProject
Questa validazione controlla la coerenza delle informazioni relative al Comitato etico.In particolare controlla:
- Che esista almeno un Comitato Etico nel tab "Comitato Etico"
- Che deve essere stata presentata la richiesta di parere all'OPBA o al Comitato Etico di Ateneo di riferimento o al Comitato Etico di un Ente Terzo che ha facoltà di concedere questo tipo di autorizzazioni nel tab "Comitato Etico"
- Deve essere anche presente il relativo numero identificativo nel tab "Comitato Etico" (altrimenti non verrà richiesto)
- Deve essere anche presente la relativa data di concessione nel tab "Comitato Etico" (altrimenti non verrà richiesto)
- Deve essere anche presente l'ente che l'ha concessa nel tab "Comitato Etico" (altrimenti non verrà richiesto)
E' possibile disattivare i singoli controlli settando a false la relativa variabile di configurazione:
- ap.prj.validation.ethicCommiteeValidatorProject.ethicCommiteeTopic.enabled
- ap.prj.validation.ethicCommiteeValidatorProject.ethicCommiteeSubmitted.enabled
Ricordando che le ultime tre variabili dipendono comunque dal campo "Autorizzazione" che deve avere valore "Concessa":
- ap.prj.validation.ethicCommiteeValidatorProject.ethicCommiteeAuthorizationNumber.enabled
- ap.prj.validation.ethicCommiteeValidatorProject.ethicCommiteeAuthorizationDate.enabled
- ap.prj.validation.ethicCommiteeValidatorProject.ethicCommiteeAuthorizationOrganization.enabled
Di default queste variabili non vengono previste, e se non sono presenti o settate con un valore diverso da false, i singoli controlli vengono effettuati.
Dal punto di vista del modello dati si tratta degli elementi di tipo ethicCommiteeTopic.
Per maggiori dettagli cfr. excel modello dati dell'entità Progetto
Configurazioni della ValidateLogic:
- ap.prj.validation.ethicCommiteeValidatorProject.ethicCommiteeTopic.enabled
- ap.prj.validation.ethicCommiteeValidatorProject.ethicCommiteeSubmitted.enabled
- ap.prj.validation.ethicCommiteeValidatorProject.ethicCommiteeAuthorizationNumber.enabled
- ap.prj.validation.ethicCommiteeValidatorProject.ethicCommiteeAuthorizationDate.enabled
- ap.prj.validation.ethicCommiteeValidatorProject.ethicCommiteeAuthorizationOrganization.enabled
pnrrCallAndProjectInconsistencyValidator
Questa validazione controlla la scelta effettuata relativa al flag PNRR.Viene abilitata SOLO se la configurazione ap.prj.create-by-call.enabled è valorizzata con true.
Verifica se tale scelta è concorde alla scelta effettuata al Bando agganciato, se dovesse essere discorde verrà sollevata un'eccezione, in tal caso l'utente potrà proseguire SOLAMENTE se sceglie di voler ignorare tale ambiguità.
Dal punto di vista del modello dati si tratta degli attributi booleanMap[pnrr] e booleanMap[pnrrInconsistencyConfirmation].
Per maggiori dettagli cfr. modello dati dell'entità in questione.
Configurazioni della ValidateLogic:
grantorValidatorProject
Questa validazione controlla che esista almeno un ente finanziatore nel tab "Dati generali".Dal punto di vista del modello dati si tratta degli elementi di tipo grantor
Se la variabile di configurazione ap.prj.grantor.withoutGrantorConfirmation.enabled è valorizzata con true viene consentito di procedere senza ente finanziatore dopo avere confermato di volere procedere con dati NON completi.
Questo scenario viene consentito per evitare di bloccare la sottomissione della scheda qualora non venga trovato in anagrafica centralizzata l'ente finanziatore e non si voglia attendere l'inserimento in anagrafica centralizzata.
A posteriori è possibile, per operatori interni di Ateneo, filtrare i progetti marcati come ente finanziatore mancante e procedere alla bonifica dei dati.
Configurazioni della ValidateLogic:
grantorFinancingQuotaRequiredValidatorProject
ap.prj.hidden Se- l'attributo grantor.numberMap[financingQuota] è visibile (non è quindi presente nella conf ap.prj.hidden)
currencyAndInternalContributionValidatorProject
Questa validazione controlla che nel tab "Finanziamento", nel caso di selezione di valuta diversa da EURO, vengano specificati- importo in valuta originaria
- tasso di cambio
- data rilevazione tasso di cambio
Dal punto di vista del modello dati si tratta degli attributi:
- internalContributionOriginalCurrency
- exchangeRate
- exchangeRateDate
checkPartnerValidatorProject
Questa validazione controlla la coerenza delle informazioni inserite nel tab "Partner".Precisamente viene verificato che:
- sia presente un partner
- ci sia uno ed un solo partner marcato come Coordinatore (ad eccezione del caso in cui l'Ateneo sia Partner Unico)
- nel caso in cui l'Ateneo sia Partner Unico non devono essere presenti altri partner
- l'Ateneo sia presente una ed una sola volta tra i partner
- per ogni partner sia selezionato il ruolo
Non è sempre presente in tutti gli Atenei la voce di dizionario "Partner Unico";
Il Partner Unico (abilitato di default) è gestito dalla variabile di configurazione ap.prj.partner.role.uniquePartner.enabled
e il suo valore di dizionario dalla variabile ap.prj.partner.role.uniquePartner.code. Di default sono tutti attivi i check elencati.
E' possibile rilassarne alcuni settando a false le variabili indicate di seguito:
- Deve esistere un Partner marcato come Coordinatore ==> ap.<itemType>.partner.main.required
- Devono essere inseriti altri partner se esiste un "Coordinatore" ==> ap.<itemType>.partner.coordinatorAndPartnerRoleCheck.enabled
- Non devono esistere altri partner oltre a quello marcato come "Partner Unico" ==> ap.<itemType>.partner.coordinatorAndPartnerRoleCheck.enabled
Esempio di variabile: ap.prj.research.int.partner.main.required.
Nei casi in cui le variabili non ci siano o non siano valorizzate a false il relativo check verrà effettuato.
La variabile ap.<itemType>.partner.main.required pilota anche il finanziamento che viene inviato a UGOV. Per maggiori informazione controllare wfUgovPjSenderValidatorProject
Questa validazione si aspetta obbligatoriamente che siano definite le seguenti variabili di configurazione:
- rm.orgunit.external.myOrganization: identificativo dell'unità organizzativa relativa all'Ateneo con mappatura verso UGOV AC
Questa validazione si aspetta obbligatoriamente che sia definito il seguente dizionario:
- partnerRole.main: dizionario relativo al ruolo partner "Coordinatore"
Configurazioni della ValidateLogic:
- rm.orgunit.external.myOrganization
- ap.TIPOLOGIA.partner.main.required
- ap.TIPOLOGIA.partner.coordinatorAndPartnerRoleCheck.enabled
- ap.TIPOLOGIA.partner.uniquePartnerAndPartnerRoleCheck.enabled
- ap.prj.partner.role.uniquePartner.enabled
- ap.prj.partner.role.uniquePartner.code
partnerAndRequestedGlobalCostValidatorProject
Nel caso in cui l'Ateneo risulti Coordinatore viene imposto che siano compilati i seguenti attributi nel fieldset "Dati finanziamento richiesto" del tab "Finanziamento" se la configurazione ap.prj.financing.requested.enabled è true (default true) e la configurazione ap.prj.financing.internalCost.send2ugov.forced è false (default false):- Contributo globale del Progetto per tutto il partenariato (EURO) - requestedGlobalContribution
- Costo globale del Progetto per tutto il partenariato (EURO) - requestedGlobalCost
Questa validazione si aspetta che siano definite le seguenti variabili di configurazione:
- rm.orgunit.external.myOrganization: identificativo dell'unità organizzativa relativa all'Ateneo con mappatura verso UGOV AC
Questa validazione si aspetta che sia definito il seguente dizionario:
- partnerRole.main: dizionario relativo al ruolo partner "Coordinatore"
Configurazioni della ValidateLogic:
- ap.prj.financing.requested.enabled
- rm.orgunit.external.myOrganization
- ap.prj.financing.internalCost.send2ugov.forced
partnerAndGlobalCostValidatorProject
Questa validazione viene abilitata SOLO se la configurazione ap.prj.financing.internalCost.send2ugov.forced è settata a false o NON è presente.Nel caso in cui l'Ateneo risulti Coordinatore viene imposto che siano compilati i seguenti attributi nel fieldset "Dati finanziamento assegnato" del tab "Finanziamento":
- Contributo globale del Progetto per tutto il partenariato (EURO) - globalContribution
- Costo globale del Progetto per tutto il partenariato (EURO) - globalCost
- Costo globale del Progetto per tutto il partenariato (NON EURO) - globalCostOriginalCurrency
- Contributo globale del Progetto per tutto il partenariato (NON EURO) - globalContributiontOriginalCurrency
Questa validazione si aspetta che siano definite le seguenti variabili di configurazione:
- rm.orgunit.external.myOrganization: identificativo dell'unità organizzativa relativa all'Ateneo con mappatura verso UGOV AC
Questa validazione si aspetta che sia definito il seguente dizionario:
- partnerRole.main: dizionario relativo al ruolo partner "Coordinatore"
Configurazioni della ValidateLogic:
checkInconsistentFundingValidatorProject
Questa validazione controlla la coerenza delle informazioni di finanziamento assegnato sia per le internalOganizationUnit (unità organizzative interne) che per i partner (Partner)Viene controllato che le somme dei costi, contributi e cofinanziamenti per internalOrganizationUnit e partner coincidano con i totali specificati a livello di progetto.
Vengono valutate le seguenti configurazioni (che hanno tutte default a true)
- ap.prj.financing.internalOrganizationUnitCost.consistence.assigned.validation.enabled
Se true viene verificato che la somma degli importi assegnati per singola struttura di Ateneo coincidano con il totale a livello di progetto - ap.prj.financing.partnerCost.consistence.assigned.validation.enabled
Se true viene verificato che la somma degli importi assegnati per singolo partner coincidano con il totale a livello di progetto - ap.prj.financing.requested.enabled
Se true significa che è stato abilitato anche la gestione del finanziamento richiesto globale - ap.prj.financing.internalOrganizationUnitCost.requested.enabled
Se true significa che è stato abilitato anche la gestione del finanziamento richiesto per singola struttura di Ateneo - ap.prj.financing.internalOrganizationUnitCost.consistence.requested.validation.enabled
Se true viene verificato che la somma degli importi richiesti per singola struttura di Ateneo coincidano con il totale a livello di progetto
La validazione viene effettuata solo se anche ap.prj.financing.internalOrganizationUnitCost.requested.enabled e ap.prj.financing.requested.enabled sono a true - ap.prj.financing.partnerCost.requested.enabled
Se true significa che è stato abilitato anche la gestione del finanziamento richiesto per singolo partner - ap.prj.financing.partnerCost.consistence.requested.validation.enabled
Se true viene verificato che la somma degli importi richiesti per singolo partner di Ateneo coincidano con il totale a livello di progetto
La validazione viene effettuata solo se anche ap.prj.financing.partnerCost.requested.enabled e ap.prj.financing.requested.enabled sono a true
- ap.prj.internalOrganizationUnitCost.notMandatoryIfOnlyOneInternalOrganizationUnit.enabled
Se- la configurazione è valorizzata a true
- esiste una sola struttura censita (internalOrganizationUnit)
- non ci sono elementi di suddivisione del finanziamento (internalOrganizationUnitCost)
Questo perché si suppone che, nel caso di una singola struttura, tutto il finanziamento venga attribuito a quella struttura. - ap.prj.partnerCost.notMandatoryIfOnlyOnePartner.enabled
Se- la configurazione è valorizzata a true
- esiste un solo partner censita (partner)
- non ci sono elementi di suddivisione del finanziamento (partnerCost)
Questo perché si suppone che, nel caso di un singolo partner, tutto il finanziamento venga attribuito a quel partner.
Per maggiori dettagli cfr. excel modello dati dell'entità Progetto.
Configurazioni della ValidateLogic:
- ap.prj.financing.requested.enabled
- ap.prj.financing.internalOrganizationUnitCost.requested.enabled
- ap.prj.financing.internalOrganizationUnitCost.consistence.requested.validation.enabled
- ap.prj.financing.internalOrganizationUnitCost.consistence.assigned.validation.enabled
- ap.prj.financing.partnerCost.requested.enabled
- ap.prj.financing.partnerCost.consistence.requested.validation.enabled
- ap.prj.financing.partnerCost.consistence.assigned.validation.enabled
- ap.prj.internalOrganizationUnitCost.notMandatoryIfOnlyOneInternalOrganizationUnit.enabled
- ap.prj.partnerCost.notMandatoryIfOnlyOnePartner.enabled
requestedFinancingSumProjectValidator
Questa validazione è abilitata solo se i Fianziamenti Richiesti della scheda progetti sono visibili (ap.prj.financing.requested.enabled = true OPPURE non specificata).Controlla che la somma dei campi Contributo totale Ateneo Richiesti (requestedInternalContribution), Cofinanziamento Ateneo in risorse Richiesto (requestedInternalConfinancing) e Cofinanziamento Ateneo in personale Richiesto (requestedManHourConfinancing) coincida con il valore del Costo totale del progetto per l'Ateneo Richiesto (requestedInternalCost).
In altre parole requestedInternalCost = requestedInternalContribution + requestedInternalConfinancing + requestedManHourConfinancing
Configurazioni della ValidateLogic:
financingSumProjectValidator
Questa validazione controlla che la somma dei campi Contributo totale Ateneo (internalContribution), Cofinanziamento Ateneo in risorse (internalConfinancing) e Cofinanziamento Ateneo in personale (manHourConfinancing) coincida con il valore del Costo totale del progetto per l'Ateneo (internalCost).In altre parole internalCost = internalContribution + internalConfinancing + manHourConfinancing
Inoltre, se
- l'attributo grantor.numberMap[financingQuota] è visibile (non è quindi presente nella conf ap.prj.hidden)
- la conf ap.prj.autocalculate.numberMap[internalContribution].enabled è valorizzata a true
Negli altri casi questo check NON viene effettuato.
Quest'ultimo check sembra essere un duplicato di grantorFinancingQuotaRequiredValidatorProject
Configurazioni della ValidateLogic:
internalOrganizationUnitCostEditValidator
Questa validazione consente l'inserimento delle sole strutture censite nella sezione "Soggetti interni"
internalOrganizationUnitCostRequestedEditValidator
Questa validazione controlla la presenza degli importi richiesti se le conf ap.prj.financing.requested.enabled e ap.prj.financing.internalOrganizationUnitCost.requested.enabled sono trueConfigurazioni della ValidateLogic:
partnerEditValidator
Questa validazione impedisce la modifica del Partner in partnerse tale Partner è presente in partnerCost (finanziamenti associati a partner).
Agisce in caso di modifica dei valori del fragment.
partnerDeleteValidator
Questa validazione impedisce l'eliminazione di un elemento in partnerse il Partner associata è presente in partnerCost (finanziamenti associati a partner).
Agisce in caso di eliminazione dei valori del fragment.
partnerCostEditValidator
Questa validazione impedisce la modifica del Partner in partnerCost (finanziamenti associati a partner)se tale Partner è presente in partner.
Agisce in caso di modifica dei valori del fragment.
callStartValidator
Questa validazione viene triggerata solo in fase di creazione di un progetto, se la conf ap.prj.create-by-call.enabled è valorizzata con true.In questo caso significa che è stata abilitata per l'utente la doppia scelta
- creazione del progetto specificando il bando
- creazione del progetto specificando il tipo del progetto
Se l'utente sceglie di creare il progetto a partire dal bando vengono scatenati i seguenti controlli:
- viene verificata l'effettiva selezione di un bando da parte dell'utente
- se la configurazione ap.prj.create-by-call.only-approved-call.enabled è valorizzata a true, viene consentita solo la selezione di bandi in stato approved
- viene verificato che il bando selezionato specifichi il tipo del progetto da associare al progetto in fase di creazione.
Si tratta del metadato linkedProjectType che deve essere presente nel bando.
Esempio di un poteziale valore è PRJ.NAZ.PRIN - se la configurazione ap.prj.create-by-call.grantor.required.enabled è valorizzata a true viene consentita solo la selezione di bandi che specificano l'ente finanziatore promotore da anagrafica degli enti esterni (grantor)
Al momento attuale, comunque, se l'utente sceglie di creare un progetto a partire dal bando, come spiegato in precedenza, viene SEMPRE verificato che il bando selezionato abbia il tipo di progetto agganciato altrimenti viene bloccato il processo di creazione e di fatto il valore della configurazione ap.prj.create-by-call.default-project-type serve solo per avviare il processo di creazione ma comunque il tipo del progetto effettivo sarà quello del bando
Pertanto basta inserire un tipo di progetto qualsiasi
Configurazioni della ValidateLogic:
- ap.prj.create-by-call.enabled
- ap.prj.create-by-call.only-approved-call.enabled
- ap.prj.create-by-call.grantor.required.enabled
- ap.prj.create-by-call.default-project-type
callValidatorProject
Questa validazione controlla che esista almeno un bando nel tab "Dati generali".Dal punto di vista del modello dati si tratta degli elementi di tipo callProjectLink
Se la variabile di configurazione ap.prj.call.withoutCallConfirmation.enabled è valorizzata con true viene consentito di procedere senza bando dopo avere confermato di volere procedere con dati NON completi.
Questo scenario viene consentito per evitare di bloccare la sottomissione della scheda qualora non venga trovato in anagrafica centralizzata il bando.
A posteriori è possibile, per operatori interni di Ateneo, filtrare i progetti marcati come bando mancante e procedere alla bonifica dei dati.
Configurazioni della ValidateLogic:
childCallValidatorProject
Questa validazione verifica che i bandi agganciati siano marcati come figli.Dal punto di vista del modello dati si tratta degli elementi di tipo callProjectLink
publicEngagementElementPrepopulateLogic
Questa logica effettua l'inizializzazione della data di versionamento per gli elementi degli oggetti Public engagement dove è iniettata:- externalFinancingTypeActual
La data versionamento viene prevalorizzata con la data in cui è stato aperto il monitoraggio.
phdStudentsSumValidatorPublicEngagement
Questa validazione va a controllare che il valore del campo Dottorandi coinvolti corrisponsa a quelli effettivamente censiti nella sezione Partecipanti.La validazione viene abilitata SOLO se la configurazione ap.pen.phdStudent.structured.enabled è presente e settata a true.
Dal punto di vista del modello dati si tratta degli elementi di tipo contributor e degli attributi di tipo integerMap{phdStudents].
Per maggiori dettagli cfr. modello dati dell'entità publicEngagement.
Configurazioni della ValidateLogic:
myOrganizationCheckValidatorPublicEngagement
Questa validazione va a controllare una delle due seguenti casistiche:- tipologia PEN.INSTITUTION e l'ateneo NON è presente tra le strutture interne
- tipologia DIVERSA da PEN.INSTITUTION e l'ateneo è presente tra le strutture interne
La validazione viene abilitata SOLO se la configurazione ap.pen.copy-myOrganization-inside-orgUnit.enabled NON è presente o settata a true.
Dal punto di vista del modello dati si tratta degli attributi di tipo booleanMap[ambiguityOrganizationConfirmation].
Per maggiori dettagli cfr. modello dati dell'entità publicEngagement.
Configurazioni della ValidateLogic:
financingTotalBudgetValidator
Questa validazione verifica che il totale del Budget complessivo sia maggiore o uguale al totale dei Finanziamenti esterni.Per maggiori dettagli cfr. il modello modello dati dell'entità in questione.
ownerTimeReportingValidator
Questa validazione verifica che ogni responsabile (owner) abbia valorizzato il campo Giornate/uomo o Ore/uomo.Vengono valutati gli attributi element.integerMap[manDay], element.integerMap[manHour].
Vengono valutate le configurazioni ap.pen.manDay.enabled e ap.pen.manHour.enabled.
- Configurazione manDay settata a true e configurazione manHour settata a true
Viene richiesto che almeno uno dei due attributi manDay o manHour sia compilato - Configurazione manDay settata a true e configurazione manHour settata a false o non presente
Viene richiesto che l'attributo manDay sia compilato - Configurazione manDay settata a false o non presente e configurazione manHour settata a true
Viene richiesto che l'attributo manHour sia compilato - Configurazione manDay settata a false o non presente e configurazione manHour settata a false o non presente
Viene sollevato un messggio di errore in cui viene indicato di settare almeno una delle due configurazioni a true
Per maggiori dettagli cfr. il modello modello dati dell'entità in questione.
Configurazioni della ValidateLogic:
publicInvolvedValidatorPublicEngagement
Questa validazione valuta la configurazione ap.pen.publicInvolved.required.onlyTraining-communication.enabled.Se la configurazione è presente e valorizzata a true allora attiva il controllo SOLO se la tipologia dell'iniziativa è "PEN.FORMAZIONE-COMUNICAZIONE" ("Giornate organizzate di formazione alla comunicazione - rivolta a PTA o docenti"): viene controllato che esista almeno un elemento di tipo publicInvolved e viene controllato che vengano aggiunti solo i seguenti Pubblici coinvolti (code dei dizionari):
- publicInvolvedPublicEngagement.other-professors
- publicInvolvedPublicEngagement.other-administratives
- publicInvolvedPublicEngagement.other-unstructored-research-staff
- publicInvolvedPublicEngagement.other-students-phd
Dal punto di vista del modello dati si tratta degli elementi publicInvolved.
Per maggiori dettagli cfr. modello dati dell'entità publicEngagement.
Configurazioni della ValidateLogic:
checkDatePublicEngagement
Questa validazione verifica la coerenza delle informazioni temporali dell'iniziativa di PE.Vengono applicate le regole esplicitate dalla seguente tabella.
Nella colonna note viene riportato "NON NECESSARIO" nel caso in cui la validazione NON viene implementata perché già prevista una validazione di obbligatorietà per un campo.
Ad esempio la validazione "C" non è necessaria perché la combinazione valida il caso in cui knownEndDate sia vuoto.
Questa condizione però non si potrà mai verificare perché l'attributo è sempre obbligatorio.
Ragionamento analogo per le altre validazioni non necessarie.
periodicEvent | oneDayOnlyEvent | knownEndDate | CONDIZIONE DI ERRORE | NOTE | |
---|---|---|---|---|---|
A | SI | SI | SI | endDate is null or numTotalDay<>1 | |
B | SI | SI | NO | endDate is not null or numTotalDay<>1 | |
C | SI | SI | EMPTY | endDate is not null or numTotalDay<>1 | NON NECESSARIA |
D | SI | NO | SI | endDate is null or numTotalDay=1 | |
E | SI | NO | NO | endDate is not null or numTotalDay=1 | |
F | SI | NO | EMPTY | endDate is not null or numTotalDay=1 | NON NECESSARIA |
G | SI | EMPTY | * | knownEndDate is not null or endDate is not null | NON NECESSARIA |
H | NO | SI | SI | endDate is null or numTotalDay<>1 or endDate-startDate+1<>1 | |
I | NO | SI | NO | la configurazione è di suo un errore | |
L | NO | SI | EMPTY | la configurazione è di suo un errore | NON NECESSARIA |
M | NO | NO | SI | endDate is null or numTotalDay=1 or numTotalDay is null or endDate-startDate<>numTotalDay+1 | |
N | NO | NO | NO | endDate is not null or numTotalDay is not null | |
O | NO | NO | EMPTY | endDate is not null or numTotalDay is not null | NON NECESSARIA |
P | NO | EMPTY | * | knownEndDate is not null or endDate is not null | NON NECESSARIA |
Oltre ai campi riportati in tabella viene verificata anche:
- la coerenza degli attributi numHoursIfLessThanOneDay (valore ammesso tra 1 e 7 solo con iniziative di un solo giorno)
- periodicity (necessario se evento periodico)
- periodicity (se presente numTotalDay) rispetti i seguenti vincoli
periodicity check messaggio di errore publicEngagementPeriodicity.continued numTotalDay==null La periodicità è continuativa e la durata in giorni quindi deve essere vuota publicEngagementPeriodicity.continued periodicEvent==true and oneDayOnlyEvent==false La periodicità è continuativa e la durata in giorni quindi deve essere vuota publicEngagementPeriodicity.weekly numTotalDay<7 La periodicità è settimanale e la durata in giorni quindi deve essere inferiore a 7 publicEngagementPeriodicity.monthly numTotalDay<31 La periodicità è mensile e la durata in giorni quindi deve essere inferiore a 31 publicEngagementPeriodicity.annual numTotalDay<366 La periodicità è annuale e la durata in giorni quindi deve essere inferiore a 366 - numTotalDay (se presente sia <=36600)
secondaryCategoryDifferFromType
Questa validazione va a controllare che tra le Categorie Secondarie inserite non sia presente:- La tipologia del PublicEngagement (wfItemType) SOLO SE NON si sta utilizzando una tipologia di APEnet (configurazione ap.pen.create-apenet.enabled settata a false o non presente)
- La tipologia prevalente (wfDictionary[mainCategory]) SOLO SE si sta utilizzando una tipologia di APEnet (configurazione ap.pen.create-apenet.enabled settata a true)
Dal punto di vista del modello dati si tratta degli attributi wfDictionary[mainCategory] e wfItemType.
Dal punto di vista del modello dati si tratta degli elementi di tipo secondaryCategory.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
researchCentreRenewalValidator
Questa validazione esegue tutta una serie di controlli validi ai fini del Rinnovo del Centro di ricerca/Piattaforma tecnologica, di seguito i controlli:- Verifica che sia specificato al massimo un collegamento come padre del rinnovo
- Verifica che il collegamento del rinnovo abbia la data di fine settatata e che questa sia minore della attuale data di inizio del corrente centro/piattaforma
- Verifica che il collegamento del rinnovo non abbia già altri collegamenti (figli) come rinnovi
Questa validazione viene eseguita SOLO se la configurazione ap.rsc.renewal.enabled è settata a true.
Dal punto di vista del modello dati si tratta degli elementi di tipo renewalLink.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
Configurazioni della ValidateLogic:
researchCentrePartnerValidator
Validator per controllare:-se la tipologia selezionata è un qualsiasi figlio della tipologia estratta dalla variabile ap.rsc.interuniversity.rootType, la presenza dell'Ateneo inserito tra i Partner con un ruolo settato; se diverso da "Sede principale" deve essere compilato il campo Referenti esterni
-se la tipologia selezionata è un qualsiasi figlio della tipologia estratta dalla variabile ap.rsc.interuniversity.rootType, la presenza di almeno un altro Partner inserito con un ruolo diverso da "Sede principale"
-la presenza di un solo Partner marcato con ruolo "Sede principale"
Dal punto di vista del modello dati si tratta degli attributi partner
Per maggiori dettagli cfr. modello dati dell'entità in questione
Configurazioni della ValidateLogic:
inKindOtherContributionCheckValidatorResearchInfrastructure
Questa validazione va a controllare che nella sezione Altro (inKindOtherContribution), qualora per un determinato anno viene censita almeno una tipologia:- NON devono essere censite più volte le stesse tipolgie per lo stesso anno
Dal punto di vista del modello dati si tratta degli elementi di tipo inKindOtherContribution.
Per maggiori dettagli cfr. modello dati dell'entità Infrastrutture di ricerca.
spinoffActiveValidator
Questa validazione esegue tutta una serie di controlli validi ai fini del Monitoraggio, di seguito i controlli:- Verifica che tutti i membri nella Compagine sociale hanno la data di inizio validità settata
- Verifica che tutti i membri nella Compagine sociale hanno valorizzato uno dei due campi (e non entrambi) integerMap[ownershipShareNumber] - numberMap[ownershipPercentage]
Dal punto di vista del modello dati si tratta degli elementi di tipo owner.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
spinoffCheckCopyContributorAndExternalOrganizationUnitInsideOwnerValidator
Questa validazione chiede all'operatore se vuole portare i Proponenti, Membri interni/esterni e l'ateneo (SE la tipoliga della Spin-off è SPI.UNI-PARTECIPATION) nella Compagine.Da interfaccia verrà proposta questa possibilità tramite flag booleano.
Questa operazione viene proposta SOLO se NON è già stata censita la Compagine sociale.
Dal punto di vista del modello dati si tratta degli elementi di tipo booleanMap[copyContributorAndExternalOrganizationUnitInsideOwner], booleanMap[copyConstitutionDateInsideOwner], dateMap[constitutionDate].
Per maggiori dettagli cfr. modello dati dell'entità in questione.
spinoffOwnershipElementValidator
Questa validazione controlla che in fase di salvataggio del fragment owner sia valorizzato uno dei seguenti valori (e non entrambi):integerMap[ownershipShareNumber]
numberMap[ownershipPercentage]
Dal punto di vista del modello dati si tratta degli elementi di tipo owner.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
spinoffOwnerTypeElementValidator
Questa validazione controlla che in fase di salvataggio del fragment owner sia valorizzato uno dei seguenti valori:personMap[ownerId]
organizationUnitMap[ouId]
stringMap[otherOwner]
Dal punto di vista del modello dati si tratta degli elementi di tipo owner.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
spinoffBoardUniversityMemberRemunerationElementValidator
Questa validazione controlla che in fase di salvataggio del fragment boardUniversityMember sia presente almeno un elemento dal fragment remuneration SOLO SE l'utente ha selezionato Sì sul campo Con remunerazione?.Viceversa SE l'utente ha selezionato No sul campo Con remunerazione? la validazione controlla che NON sia presente alcun elemento dal fragment remuneration.
Dal punto di vista del modello dati si tratta degli elementi di tipo boardUniversityMember.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
spinoffCompanyPositionPersonSpinOffElementValidator
Questa validazione controlla che in fase di salvataggio del fragment companyPosition sia valorizzato uno dei seguenti valori:personMap[personId]
stringMap[externalPerson]
Dal punto di vista del modello dati si tratta degli elementi di tipo companyPosition.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
spinoffIntellectualPropertyTypeCheckConsistencyElementValidator
Questa validazione controlla che in fase di salvataggio del fragment Proprietà Intellettuale NON sia presente o che si tenti di aggiungere la tipologia N/A (non applicabile) insieme ad altre tipologie.Dal punto di vista del modello dati si tratta degli elementi di tipo intellectualPropertyType.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
spinoffCheckElementDateBetweenMonitoringDateElementValidator
Questa validazione controlla la coerenza delle date di Inizio e Fine in fase di salvataggio dei fragment Personale, Gender equality, Bilancio e Proprietà Intellettuali (conteggi).Se NON è presente alcun monitoraggio pregresso (la Costituzione NON viene valutata) verifica che la data di Inizio dell'elemento sia maggiore o uguale della data data di Costituzione
Se NON è presente alcun monitoraggio pregresso (la Costituzione NON viene valutata) verifica che la data di Inizio dell'elemento sia maggiore della data dell'ultimo Monitoraggio, in caso di rettifica verifica che sia maggiore della data del penultimo Monitoraggio.
Verifica che la data di Inizio dell'elemento sia minore o uguale della data del corrento Monitoraggio.
Verifica che la data di Fine dell'elemento sia minore o uguale della data del corrento Monitoraggio.
Dal punto di vista del modello dati si tratta degli attributi dateMap[startDate] e dateMap[endDate].
Dal punto di vista del modello dati si tratta degli elementi di tipo staff, genderEquality, balance e intellectualPropertySummary.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
spinoffRequirementCheckDateElementValidator
Questa validazione controlla che in fase di salvataggio del fragment requirement la data di verifica sia compilata se l'operatore ha specificato che il requisito è stato verificato.Dal punto di vista del modello dati si tratta degli elementi di tipo requirement.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
spinoffItemLinkParentElementValidator
Questa validazione controlla che in fase di salvataggio dei fragment di collegamento ad altre entità l'oggetto che si sta cercando di collegare abbia la data di inizio settata e che ci sia un minimo di sovrapposizione di date tra lo Spin-off e l'oggetto collegato.Dal punto di vista del modello dati si tratta degli elementi di tipo projectSpinoffLink, contractSpinoffLink e agreementSpinoffLink.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
spinoffIntellectualPropertyValidator
Questa validazione controlla che sia compilata la sezione delle Proprietà intellettuali.Controlla che ALMENO uno dei due fragment intellectualPropertySpinoffLink e intellectualPropertyType sia valorizzato con ALMENO un valore.
Dal punto di vista del modello dati si tratta degli elementi di tipo intellectualPropertySpinoffLink e intellectualPropertyType.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
spinoffRequirementValidator
Questa validazione controlla che sia compilata la sezione delle Validazione Requisiti.Controlla che sia presente ALMENO un valore nel fragment requirement e che ogni requisito sia stato validato, quindi che ogni elemento abbia settato a true il campo validated.
Dal punto di vista del modello dati si tratta degli elementi di tipo requirement.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
spinoffHeadquartersValidator
Questa validazione controlla che sia compilata la sezione Sedi legali e operative.Controlla che sia presente ALMENO un valore nel fragment headquarters e che almeno uno di questi sia marcato come Sede Legale.
Dal punto di vista del modello dati si tratta degli elementi di tipo headquarters.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
spinoffVatAndCfValidator
Questa validazione controlla la consistenza degli attributi Partita IVA e Codice Fiscale.Verifica che i valori inseriti siano di 11 carattari SOLO numerici.
Dal punto di vista del modello dati si tratta degli attributi stringMap[vatNumber] e stringMap[cf].
Per maggiori dettagli cfr. modello dati dell'entità in questione.
spinoffVersionDateAndVersionSelectorValidator
Questa logica verifica inizialmente che i campi Operazione monitoraggio e Data monitoraggio siano valorizzati.Successivamente in base alla scelta dell'Operazione monitoraggio verifica che:
- Scelta Nuovo: viene verificato che la data di Monitoraggio corrente sia successiva all'ultima data di Monitoraggio se presente, se non presente viene verificato che sia successiva alla data di Costituzione.
- Sceelta Rettifica ultimo presente: viene verificato che effettivamente esista un monitoraggio precedente (ATTENZIONE, non viene considerata la Costituzione) e viene verificato che la data di Monitoraggio sia uguale alla data del Monitoraggio da rettificare.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
spinoffVersionMoreInformationValidator
Questa validazione esegue una serie di operazioni al fine della Costituzione, del Monitoraggio, della Cessassione e della Liquidazione.In caso di Costituzione:
- La data di monitoraggio viene settata con la data di Costituzione
- Il commento del monitoraggio viene settato con la dicitura "Costituzione"
- La data di monitoraggio viene settata con la data scelta dall'utente
- Il commento del monitoraggio viene settato con la dicitura "Monitoraggio alla data + DATA DI MONITORAGGIO"
- La data di monitoraggio viene settata con la data scelta dall'utente
- La data di cessione viene settata dall'utente
- Il commento del monitoraggio viene settato con la dicitura "Monitoraggio alla data + DATA DI MONITORAGGIO"
- La data di monitoraggio viene settata con la data scelta dall'utente
- La data di liquidazione viene settata dall'utente
- Il commento del monitoraggio viene settato con la dicitura "Monitoraggio alla data + DATA DI MONITORAGGIO"
- La data di monitoraggio viene settata con la data scelta dall'utente
- La data di scadenza viene settata dall'utente
- Il commento del monitoraggio viene settato con la dicitura "Monitoraggio alla data + DATA DI MONITORAGGIO"
Dal punto di vista del modello dati si tratta degli attributi wfDictionaryMap[versionSelector], dateMap[versionDate].
Per maggiori dettagli cfr. modello dati dell'entità in questione.
spinoffFullTransferQuoteValidator
Questa validazione controlla che l'ateneo non abbia più quote di finanziamento associate SE la tipologia è spinOff non partecipata dall'Ateneo o se si sta tentando di portare la Spin-off nello stato Ceduto (sold).Dal punto di vista del modello dati si tratta degli elementi di tipo owner.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
Configurazioni della ValidateLogic:
spinoffMonitoringIntervalDatesValidator
QUESTA VALIDAZIONE NON DEVE ESSERE DISABILITATAQuesta validazione controlla la coerenza degli elementi inseriti nelle sezioni Personale, Gender equality, Bilancio e Proprietà Intellettuali (conteggi).
Verifica che ogni elemento inserito abbia le date di inzio e fine valorizzate.
Verifica che NON ci siano sovrapposizioni di date, per ogni tipologia SE PRESENTE.
Se presente una configurazione di questo tipo ap.spi.DISCRIMINATOR_ELEMENT.endDateMonitoring.required settata a true (es: ap.spi.balance.endDateMonitoring.required = true) verifica che ci sia almeno un elemento con la data di fine settata uguale alla data del corrente Monitoraggio.
Dal punto di vista del modello dati si tratta degli attributi dateMap[startDate] e dateMap[endDate].
Dal punto di vista del modello dati si tratta degli elementi di tipo staff, genderEquality, balance e intellectualPropertySummary.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
Configurazioni della ValidateLogic:
spinoffMemberAuthorizationCheckValidator
Questa validazione controlla le autorizzazioni.Verifica che tutte le persone interne della Compagine sociale con ruolo Socio operativo abbiano l'autorizzazione per il periodo corrente nella sezione Autorizzazioni.
Verifica che tutte le persone con Cariche Societarie abbiano l'autorizzazione per il periodo corrente nella sezione Autorizzazioni.
Per periodo corrente si intende che le startDate e endDate di operatività della persona rientrino nell'intervallo delle startDate e endDate della autorizzazione.
Nel caso in cui la persona non abbia la data di fine settata, mentre l'autorizzazione si, viene verificato che la data di fine dell'autorizzazione sia successiva o uguale alla data corrente.
Dal punto di vista del modello dati si tratta degli elementi di tipo memberAuthorization, owner, companyPosition.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
spinoffPartecipationCheckValidator
Questa validazione controlla in base alla tipologia della Spin-off se l'ateneo è presente nella Compagine sociale- Se la tipologia è spinOff partecipata dall'Ateneo viene verificato che l'ateneo sia presente nella Compagine sociale
- Se la tipologia è spinOff non partecipata dall'Ateneo viene verificato che l'ateneo NON sia presente nella Compagine sociale
Per maggiori dettagli cfr. modello dati dell'entità in questione.
Configurazioni della ValidateLogic:
spinoffOwnershipValidator
Questa validazione controlla in base alla Forma giuridica della Spin-off, se questa NON è di tipo SPA.In tal caso verifica che venga raggiunto il 100% di Misura della partecipazione (in %) tra i membri della Compagine sociale attivi alla corrente data di Costituzione o ultima data di monitoraggio.
Dal punto di vista del modello dati si tratta degli attributi numberMap[ownershipPercentage] e wfDictionaryMap[companyType].
Dal punto di vista del modello dati si tratta degli elementi di tipo owner.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
spinoffRestoreConstitutionValidator
Questa validazione ha il compito di chiedere all'utente la conferma di voler riavviare tutto il processo costitutivo.In caso di conferma la Spin-off verrà riportata allo stato In costituzione, verranno annullati TUTTI i Monitoraggi e la Costituzione.
Dal punto di vista del modello dati si tratta degli attributi booleanMap[restoreConstitution].
Per maggiori dettagli cfr. modello dati dell'entità in questione.
spinoffElementPrepopulateLogic
Questa logica effettua l'inizializzazione delle date di inizio e fine (se presente la configurazione) per gli elementi degli oggetti spinoff dove è iniettata:- owner
- companyPosition
- memberAuthorization
- publiclyControlled
- body
- boardUniversityMember
- staff
- genderEquality
- balance
- intellectualPropertySummary
- agreement
- project
- contract
- universityInfrastructureUseApproval
La data di inizio viene valorizzata alternativamente con:
- Data dell'ultimo monitoraggio+1: se disponibile monitoraggio precedente
- Data recuperata dalla configurazione: ap.spi.ELEMENTO.validator.date.start.discriminator
- Nessun valore se non viene trovata nessuna delle due informazioni precedenti
Il segnaposto DISCRIMINATOR deve essere sostituito con il nome dell'elemento.
Ad esempio ap.spi.prepopulate.monitoring.genderEquality.endDate.enabled valorizzata a true causa l'inizializzazione anche della data di fine con la data di riferimento del monitoraggio corrente.
Configurazioni della ValidateLogic:
- ap.spi.ELEMENTO.validator.date.start.discriminator
- ap.spi.prepopulate.monitoring.ELEMENTO.endDate.enabled
checkDateExtensionValidator
Questa validazione controlla la coerenza delle date inserite.Precisamente, viene controllato che:
- startDate minore o uguale a endDate relativi all'oggetto radice
- durationInMonth maggiore o uguale a 0 relativo all'oggetto radice
- gli elementi di tipo extension abbiano una data maggiore della startDate dell'oggetto radice
Per maggiori dettagli cfr. modello dati dell'entità in questione.
Questa validazione viene attivata SOLO se ap.checkDateExtensionValidator.enabled=true.
Configurazioni della ValidateLogic:
checkDateApprovalValidator
Questa validazione controlla che gli elementi di tipo approval abbiano una data maggiore della startDate dell'oggetto radicePer maggiori dettagli cfr. modello dati dell'entità in questione.
La configurazione ap.(PRJ-CON).approval.approvalDateAfterStartDate.enabled (una per i progetti e una per i contratti), permette l'inserimento di una data di approvazione successiva alla data effettiva di inizio del progetto/contratto.
In particolare per la configurazione ap.(PRJ-CON).approval.approvalDateAfterStartDate.enabled :
- se viene impostata con valore true, la logica di validazione è ATTIVATA e quindi verrà scatenato l'errore sulla coerenza delle due date
- se viene impostata con valore false, la logica di validazione è DISATTIVATA e non verrà effettuato il controllo
Quest'ultima configurazione disabilita il controllo del validator relativo alla data di approvazione se è maggiore della data di inizio, può essere utile come nel caso in cui per qualche motivo interno il progetto è partito perché ufficiosamente è stato approvato ma l'approvazione ufficiale è arrivata dopo (ad esempio con decreto rettorale).
Nel caso di inserimento di data di approvazione successiva all'inizio del progetto/contratto, verrà visualizzato un warning NON bloccante in ogni caso
Configurazioni della ValidateLogic:
- ap.prj.approval.approvalDateAfterStartDate.enabled
- ap.con.approval.approvalDateAfterStartDate.enabled
extensionDeleteValidator
Questa validazione opera sull'elemento extension figlio dell'oggetto radice.Se l'utente tenta di eliminare una proroga, viene controllato che questa sia la più recente, in caso contrario viene sollevato un errore.
Per maggiori dettagli cfr. modello dati delle entità in questione (progetti e contratti)
approvalOrganizationUnitValidator
Questa validazione controlla le approvazioni inserite, cercando quelle con strutture agganciate.In tal caso verifica che tutte le strutture siano censite anche nella sezione Strutture.
Dal punto di vista del modello dati si tratta degli elementi di tipo approval e internalOrganizationUnit.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
ownerAndOrganizationUnitMatchValidator
Questa validazione controlla che esista per ogni responsabile scientifico dell'oggetto, una unità organizzativa che sia interna nel momento della data di avvio dell'oggetto (startDate) oppure se non c'è questa data in questo momento.Dal punto di vista del modello sono dei dati di tipo: internalOrganizationUnit, owner.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
uniqueIdentifierValidator
Questa validazione controlla l'unicità dell'identificativo dell'oggetto.Questa verifica viene fatta per i casi di generazione di codice "parlante" con possibile collisione con identificativi già presenti.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
inheritInternalOrganizationUnitFromTeamOfLoggedUserValidator
Questa validazione viene attivata solo in fase di creazione dell'oggetto.Viene triggerata SOLO in visione dipartimentale e se la configurazione ap.<macrotype>.internalOrganizationUnit.inheritFromTeamOfLoggedUser.enabled è valorizzata con true
Questa validazione controlla che sia stata selezionata la struttura alla quale agganciare l'oggetto che si sta creando
Configurazioni della ValidateLogic:
- ap.TIPOLOGIA.internalOrganizationUnit.inheritFromTeamOfLoggedUser.enabled
- ap.TIPOLOGIA.internalOrganizationUnit.inheritFromTeamOfLoggedUser.role
integerMapYearConsistencyValidator
Questa validazione verifica la coerenza del valore del metadato integerMap[year] rispetto alle date di inizio e fine dell'oggetto.In particolare verifica che l'anno inserito NON sia minore dell'anno della data di inizio e che NON sia maggiore dell'anno della data di fine.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
dateCoverageAndOverlapValidator
Questa validazione controlla la coerenza delle date inserite per i possibili elementi: owner, contributor, internalRepresentative, internalOrganizationUnit, historicalDescription, publiclyControlled.Vengono valutati gli attributi element.dateMap[startDate], element.dateMap[endDate], e confrontati con le date di validità dell'item dateMap[startDate], dateMap[endDate], se non diversamente configurate.
Vengono valutate le seguenti configurazioni (che di default NON sono presenti), se non è presente ALCUNA configurazione la logica NON effettuerà alcun controllo.
- Overlap: ap.<macrotype>.<elementDiscriminator>.overlap
Se settata a true viene verificato che per gli elementi con quel discriminator non ci sia ALCUNA sovrapposizione di date.
Se settata con qualsiasi altro valore o non presente non viene fatto alcun controllo.
E' possibile specificare i ruoli degli elementi a cui effettuare i controlli sopra indicati, per farlo bisogna introdurre la configurazione ap.<macrotype>.<elementDiscriminator>.role.overlap.csv in cui bisogna specificare l'elenco dei code dei ruoli (quello che si vede da interfaccia dei dizionari alla colonna Codici). - Coverage: ap.<macrotype>.<elementDiscriminator>.coverage
Se settata a true viene verificato che per gli elementi con quel discriminator ci sia continuità degli intervalli temporali.
Se settata a true viene verificato che per gli elementi con quel discriminator esista un intervallo in cui sia previsto un elemento con la data di inizio dell'oggetto.
Se settata a true viene verificato che per gli elementi con quel discriminator se nel caso in cui la data di fine sia popolata, esista un intervallo in cui sia previsto un elemento con la data di fine dell'oggetto.
Se settata con qualsiasi altro valore o non presente non viene fatto alcun controllo.
E' possibile specificare i ruoli degli elementi a cui effettuare i controlli sopra indicati, per farlo bisogna introdurre la configurazione ap.<macrotype>.<elementDiscriminator>.role.coverage.csv in cui bisogna specificare l'elenco dei code dei ruoli (quello che si vede da interfaccia dei dizionari alla colonna Codici).
E' possibile specificare che tutti gli elementi abbiano la data di fine valorizzata, settando a true la configurazione ap.<macrotype>.<elementDiscriminator>.endDate.required. Questa viene valutata SOLO se la configurazione ap.<macrotype>.<elementDiscriminator>.coverage è settata a true.
- configurazione ap.prj.owner.overlap = true e configurazione ap.prj.owner.role.overlap.csv = ownerRole.administrative, si sta indicando che per i Responsabili scientifici marcati con il ruolo Amministrativo NON ci devono essere sovrapposizioni di intervalli
- configurazione ap.prj.owner.coverage = true e configurazione ap.prj.owner.role.coverage.csv NON presente, si sta indicando che ci deve essere una copertura completa per tutto il periodo di attività dell'oggetto da parte dei Responsabili scientifici e che vengono valutati TUTTI
- configurazione ap.prj.owner.coverage = true e configurazione ap.prj.owner.overlap = true, si sta indicando che ci deve essere una copertura completa per tutti il periodo di attività dell'oggetto, che NON ci siano sovrapposizioni di intervalli da parte dei Responsabili scientifici e che vengono valutati TUTTI
Se assenti, per owner e contributor vengono cercate le ap.<macrotype>.contributorAndOwner.validator.date.<start|end>.discriminator
(le medesime configurazioni pilotano anche le validazioni sulle date per owner e contributor: cfr checkElementDateBetweenItemDateValidator) Per maggiori dettagli cfr. modello dati dell'entità in questione
Configurazioni della ValidateLogic:
- ap.TIPOLOGIA.xxxx.overlap
- ap.TIPOLOGIA.xxxx.coverage
- ap.TIPOLOGIA.xxxx.role.coverage.csv
- ap.TIPOLOGIA.xxxx.role.overlap.csv
- ap.TIPOLOGIA.xxx.validator.date.start.discriminator
- ap.TIPOLOGIA.xxx.validator.date.end.discriminator
- ap.TIPOLOGIA.contributorAndOwner.validator.date.start.discriminator
- ap.TIPOLOGIA.contributorAndOwner.validator.date.end.discriminator
multipleContributorValidator
Questa validazione verifica che esista almeno un elemento di tipo contributor.Se la variabile di configurazione ap.<sourceItemType>.<contributor.withoutContributorConfirmation.enabled è valorizzata con true viene consentito di procedere senza l'inserimento dopo avere confermato di volere procedere con dati NON completi.
Dal punto di vista del modello dati si tratta degli elementi di tipo contributor.
Per maggiori dettagli cfr. il modello modello dati dell'entità in questione.
startDateAndEndDateValidator
Questa validazione controlla che la date di inizio preceda la data di fine.Dal punto di vista del modello dati si tratta degli attributi startDate e endDate.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
wfIdentityLogicOwnerSimplePermissionsJs
Questa è una permissions logic che costruisce dinamicamente i permessi per gli item per gli owner.Se la variabile di configurazione ap.xxxx-flow.owner.create è settata a true o non è valorizzata allora vengono assegnati all'owner i seguenti permessi:
- crwfd
- rwfd
Se la variabile di configurazione ap.xxxx-flow.owner.create dove xxxx è il nome del flusso è settata a true o non è valorizzata allora viene consentita la creazione di nuovi item agli owner.
Se la variabile di configurazione ap.xxxx-flow.owner.create dove xxxx è il nome del flusso è settata a false allora NON viene consentita la creazione di nuovi item agli owner.
In caso di modifica di queste variabili di configurazione procedere, nell'ordine, con
- reload delle configurazioni
- nuovo upload della tassonomia anche se non è stato modificato nulla (serve per forzare aggiornamento delle risorse su DB)
- reload delle autorizzazioni
Configurazioni della ValidateLogic:
checkElementDateBetweenItemDateValidator
Questa validazione controlla la coerenza delle date di inzio e fine in fase di salvataggio del fragment.Verifica la coerenza degli intervalli tra le date dell'elemento corrente (wfItemElement) e quelle dell'oggetto (wfItem).
Come date dell'elemento corrente vengono recuperate le due date presenti negli attributi dateMap[startDate] e dateMap[endDate].
Come data di inizio dell'oggetto viene recuperata la data presente nell'attributo element.dateMap[discriminator], il discriminator viene recuperato dalla configurazione specifica ap.<sourceItemType>.<discriminatorElement>.validator.date.start.discriminator, se non presente viene valutata la configurazione più generale ap.<sourceItemType>.contributorAndOwner.validator.date.start.discriminator.
Come data di fine dell'oggetto viene recuperata la data presente nell'attributo element.dateMap[discriminator], il discriminator viene recuperato dalla configurazione specifica ap.<sourceItemType>.<discriminatorElement>.validator.date.end.discriminator, se non presente viene valutata la configurazione più generale ap.<sourceItemType>.contributorAndOwner.validator.date.end.discriminator.
Vengono effettuati i seguenti controlli se presenti le relative configurazione:
- Se la data di inzio dell'oggetto è presente e se la data di inizio dell'elemento corrente è presente
Viene verificato che la data di inizio dell'elemento corrente sia successiva alla data di inizio dell'oggetto. - Se la data di fine dell'oggetto è presente e se la data di fine dell'elemento corrente è presente
Viene verificato che la data di fine dell'elemento corrente sia precedente della data di fine dell'oggetto.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
Configurazioni della ValidateLogic:
- ap.TIPOLOGIA.xxxx.validator.date.start.discriminator
- ap.TIPOLOGIA.contributorAndOwner.validator.date.start.discriminator
ownerPositionStartValidator
Questa validazione viene triggerata SOLO se la configurazione ap.<tipologia>.owner.internalOrganizationUnit.mandatory è settata a true.Se questa configurazione non viene trovata la validazione NON viene eseguita.
Verifica che l'owner (responsabile scientifico) inserito in fase di creazione abbia una afferenza dipartimentale.
La data alla quale estrarre l'afferenza dipartimentale del responsabile è quella contenuta nel metadato con il nome recuperabile dalla configurazione ap.<tipologia>.owner.position.date.
Se questa configurazione
- NON è presente, viene usato la data inserita nel metadato startDate
- è presente ed ha valore uguale a CURRENT viene usata la data corrente
- è presente ed ha valore uguale a CURRENT_OR_LAST viene usata l'ultima afferenza dipartimentale disponibile (attiva o cessata)
- è presente ed NON ha un valore tra quelli elencati allora viene usata la data presente nel metadato con il nome specificato
E' inoltre possibile stabilire quali siano i contesti all'interno dei quali cercare l'afferenza dipartimentale per il responsabile scientifico.
Questo viene pilotatao dalla configurazione ap.<tipologia>.owner.position.context.
Se questa configurazione
- NON è presente, viene usato il solo contesto di ricerca (docenti, ricercatori, dottorandi, ...)
- è uguale a research allora viene usato il solo contesto di ricerca (docenti, ricercatori, dottorandi, ...)
- è uguale a support allora viene usato il solo contesto di supporto (TA)
- è uguale a ALL allora vengono usati entrambi i contesti
Con <tipologia> viene inteso il codice a tre lettere in minuscolo che indica la tipologia radice dell'oggetto in questione come ad esempio : lab, eqp, inm, prj, ...
Per un elenco esaustivo fare riferimento all'"Alberatura tipologie RM/AP"
Configurazioni della ValidateLogic:
- ap.TIPOLOGIA.owner.internalOrganizationUnit.mandatory
- ap.TIPOLOGIA.owner.position.date
- ap.TIPOLOGIA.owner.position.context
addOrgUnitFromNewOwnerValidator
Questa logica, ogni volta che viene aggiunto o aggiornato un owner (responsabile scientifico) o contributor(partecipante), ne ricava il dipartimento e lo aggiunge alle strutture di afferenza, se non già presente.La data alla quale estrarre l'afferenza dipartimentale del responsabile è quella contenuta nel metadato con il nome recuperabile dalla configurazione ap.<tipologia>.owner.position.date.
Se questa configurazione
- NON è presente, viene usata la data inserita nel metadato startDate
- è presente ed ha valore uguale a CURRENT viene usata la data corrente
- è presente ed ha valore uguale a CURRENT_OR_LAST viene usata l'ultima afferenza dipartimentale disponibile (attiva o cessata)
- è presente ed NON ha un valore tra quelli elencati allora viene usata la data presente nel metadato con il nome specificato
E' inoltre possibile stabilire quali siano i contesti all'interno dei quali cercare l'afferenza dipartimentale per il responsabile scientifico.
Questo viene pilotatao dalla configurazione ap.<tipologia>.owner.position.context.
Se questa configurazione
- NON è presente, viene usato il solo contesto di ricerca (docenti, ricercatori, dottorandi, ...)
- è uguale a research allora viene usato il solo contesto di ricerca (docenti, ricercatori, dottorandi, ...)
- è uguale a support allora viene usato il solo contesto di supporto (TA)
- è uguale a ALL allora vengono usati entrambi i contesti
E' possibile infine definire le mappature tra ruolo dell'owner|contributor e il ruolo del dipartimento che deve essere aggiunto.
Questo viene pilotato dalla variabile di configurazione ap.<tipologia>.[owner|contributor].role.<codice_dizionario>.inheritedInternalOrganizationUnit.role
Il valore di questa configurazione indica il code del dizionario (visibile da interfaccia di gestione dei dizionari) associato al ruolo del dipartimento per quello specifico ruolo dell'[owner|contributor]
Tipicamente queste mappature vengono gestite a livello di sistema.
Qualora l'owner|contributor non preveda il ruolo, è possile lo stesso effettuare l'aggiunta della struttura con il ruolo. In questo caso viene attribuito alla struttura il ruolo presente nella configurazione ap.<tipologia>.internalOrganizationUnit.role.default, se non dovesse essere presente NON viene aggiunto il ruolo.
Accanto al meccanismo descritto di estrazione del dipartimento dalle afferenze delle persone, è possibile avere anche un'altra configurazione (al momento SOLO per le entità PRJ).
Per i PRJ, è possibile richiedere all'utente, direttamente nell'elemento dell'owner, di specificare il dipartimento associato (se questo campo NON viene nascosto).
Questo dipartimento NON è necessario che sia quello di afferenza ma potrebbe essere una struttura qualsiasi con la quale la persona sta svolgendo il progetto.
Se questa variabile è presente, la struttura che verrà riportata nella sezione delle strutture interne sarà quella specificata direttamente nell'elemento owner.
E' possibile, infine, definire la variabile ap.<tipologia>.internalOrganizationUnit.fullyInferredFromPeopleType.csv
Questa variabile abilita il ricalcolo completo delle unità organizzative a partire dalle strutture di afferenza delle persone.
Questa variabile deve contenere l'elenco, separato da virgola, degli elementi del modello associati alle persone (owner, contributor, ....) dalle estrarre le info delle strutture.
E' comunque sempre possibile operare in edit sulle strutture inferite.
questo significa che
- se viene settata a true la variabile ap.<tipologia>.internalOrganizationUnit.fullyInferredFromPeopleType.csv
- se viene modificata/eliminata/aggiunta direttametne una struttura nella sezione delle strutture
- se viene modificata/eliminata/aggiunta una persona
Nel caso dei PRJ è presente un ulteriore meccanismo che, se la variabile ap.<tipologia>.internalOrganizationUnit.fullyInferredFromPeopleType.csv è definita, impedisce l'edit diretto delle strutture a tutti tranne agli utenti che hanno la visione completa e i diritti di edit sulle strutture.
Questa validazione considera anche la configurazione ap.<tipologia>.internalOrganizationUnit.inferredChid.csv.
Questa configurazione consente di creare automaticamente un'altro elemento di modello associato alla struttura estratta dalla persona.
Per i dettagli della configurazione fare riferimento alla descrizione presente in deleteOrgUnitAssociatedToOldOwnerValidator
Qualora venga fatto un edit di un elemento struttura (direttamente a partire dall'elemento struttura o a partire dagli elementi delle persone), tale edit verrà consentito se sarà possibile eliminare gli eventuali elementi inferiti agganciati.
Con <tipologia> viene inteso il codice a tre lettere in minuscolo che indica la tipologia radice dell'oggetto in questione come ad esempio : lab, eqp, inm, prj, ...
Per un elenco esaustivo fare riferimento all'"Alberatura tipologie RM/AP"
Configurazioni della ValidateLogic:
- ap.TIPOLOGIA.owner.position.context
- ap.TIPOLOGIA.[owner|contributor].role.COD_DIZIONARIO.inheritedInternalOrganizationUnit.role
- ap.TIPOLOGIA.internalOrganizationUnit.fullyInferredFromPeopleType.csv
- ap.TIPOLOGIA;.internalOrganizationUnit.inferredChid.csv
deleteOrgUnitAssociatedToOldOwnerValidator
Questa logica, ogni volta che viene ELIMINATA una persona ne ricava il dipartimento ed elimina anche questo dalle strutture interne (se non esiste un'altra persona con lo stesso dipartimento)Qualora sia definita anche la variabile ap.<tipologia>.internalOrganizationUnit.inferredChid.csv viene effettuata anche la cancellazione degli elementi elencati come associati all'unità organizzativa.
Ad esempio nel caso di progetti esiste nel modello l'elemento internalOrganizationUnitCost,
Se la variabile ha questo valore, verrà eliminato anche l'elemento associato alla struttura che si sta eliminando.
Gli unici elementi di modello che possono essere inseriti in questa variabile sono quelli che prevedono nel modello dati l'attributo ouId
Continuando con l'esempio internalOrganizationUnitCost nei progetti, è possibile definire anche la variabile ap.<tipologia>.internalOrganizationUnit.inferredChid.<elemento>.jsValidator e cioè ap.prj.internalOrganizationUnit.inferredChid.internalOrganizationUnitCost.jsValidator
Questa configurazione deve contenere un javascript che deve ritornare true o false in base al fatto che l'elemento possa o meno essere cancellato.
Questo javascript ha in input wfItemElement che è l'elemento per il quale verificare l'eliminabilità.
Tipicamente l'oggetto può essere eliminato se non sono stati inserite informazioni da un operatore.
Se la configurazione non è presente allora l'elemento viene considerato eliminabile, indipendentemente dalla presenza di dati.
Configurazioni della ValidateLogic:
- ap.TIPOLOGIA.internalOrganizationUnit.inferredChid.csv
- ap.TIPOLOGIA.internalOrganizationUnit.inferredChid.ELEMENTO.jsValidator
- ap.TIPOLOGIA.[owner|contributor].role.COD_DIZIONARIO.inheritedInternalOrganizationUnit.role
addElementInferredFromOrgUnitElementValidator
Questa logica, ogni volta che viene inserito o modificato una struttura aggiunge degli elementi figli collegati.Questi elementi vengono definiti in nella configurazione ap.<tipologia>.internalOrganizationUnit.inferredChid.csv che riporta l'elenco separato da virgole degli elementi figli.
Ad esempio nel caso di progetti esiste nel modello l'elemento internalOrganizationUnitCost,
Se la variabile ha questo valore, verrà aggiunto un elemento internalOrganizationUnitCost (se non già presente) per la struttura che si sta aggiungendo/aggiornando.
Gli unici elementi di modello che possono essere inseriti in questa variabile sono quelli che prevedono nel modello dati l'attributo ouId
Configurazioni della ValidateLogic:
internalOrganizationUnitEditLinkedElementValidator
Questa validazione impedisce la modifica della Struttura in internalOganizationUnit se tale struttura è presente in internalOganizationUnitCost (finanziamenti associati a unità organizzative interne) e contiene dei valori compilati.Agisce in caso di edit dei valori del fragment internalOganizationUnit.
internalOrganizationUnitDeleteLinkedElementValidator
Questa logica, ogni volta che viene ELIMINATA una struttura elimina gli eventuali elementi figli collegati.Questi elementi vengono definiti in nella configurazione ap.<tipologia>.internalOrganizationUnit.inferredChid.csv che riporta l'elenco separato da virgole degli elementi figli.
Ad esempio nel caso di progetti esiste nel modello l'elemento internalOrganizationUnitCost,
Se la variabile ha questo valore, verrà eliminato anche l'elemento associato alla struttura che si sta eliminando.
Gli unici elementi di modello che possono essere inseriti in questa variabile sono quelli che prevedono nel modello dati l'attributo ouId
Continuando con l'esempio internalOrganizationUnitCost nei progetti, è possibile definire anche la variabile ap.<tipologia>.internalOrganizationUnit.inferredChid.<elemento>.jsValidator e cioè ap.prj.internalOrganizationUnit.inferredChid.internalOrganizationUnitCost.jsValidator
Questa configurazione deve contenere un javascript che deve ritornare true o false in base al fatto che l'elemento possa o meno essere cancellato.
Questo javascript ha in input wfItemElement che è l'elemento per il quale verificare l'eliminabilità.
Tipicamente l'oggetto può essere eliminato se non sono stati inserite informazioni da un operatore.
Se la configurazione non è presente allora l'elemento viene considerato eliminabile, indipendentemente dalla presenza di dati.
Configurazioni della ValidateLogic:
- ap.TIPOLOGIA.internalOrganizationUnit.inferredChid.csv
- ap.TIPOLOGIA.internalOrganizationUnit.inferredChid.ELEMENTO.jsValidator
notEmptyResearchPositionValidatorTutor
Questa validazione si applica alla selezione di un tutor per una mobilità in ingresso.Viene controllato se il tutor inserito abbia una posizione di ricerca presso un dipartimento alla data di inizio.
ownerWithSameDepartmentAsHeadValidator
Questa validazione viene triggerata in fase di creazione di un nuovo oggetto solo se l'utente è in visione dipartimentale.Verifica che l'utente che sta creando un nuovo oggetto a livello dipartimentale, specifichi come responsabile scientifico una persona che afferisce al proprio dipartimento.
Se non viene specificato nessun responsabile scientifico, questa validazione verrà ignorata.
Se presente il campo booleanMap[customizedInternalOrganization] ed è stato valorizzato a true, questa validazione verrà ignorata.
La data alla quale estrarre l'afferenza dipartimentale del responsabile è quella contenuta nel metadato con il nome recuperabile dalla configurazione ap.<tipologia>.owner.position.date.
Se questa configurazione
- NON è presente, viene usato la data inserita nel metadato startDate
- è presente ed ha valore uguale a CURRENT viene usata la data corrente
- è presente ed ha valore uguale a CURRENT_OR_LAST viene usata l'ultima afferenza dipartimentale disponibile (attiva o cessata)
- è presente ed NON ha un valore tra quelli elencati allora viene usata la data presente nel metadato con il nome specificato
E' inoltre possibile stabilire quali siano i contesti all'interno dei quali cercare l'afferenza dipartimentale per il responsabile scientifico.
Questo viene pilotatao dalla configurazione ap.<tipologia>.owner.position.context.
Se questa configurazione
- NON è presente, viene usato il solo contesto di ricerca (docenti, ricercatori, dottorandi, ...)
- è uguale a research allora viene usato il solo contesto di ricerca (docenti, ricercatori, dottorandi, ...)
- è uguale a support allora viene usato il solo contesto di supporto (TA)
- è uguale a ALL allora vengono usati entrambi i contesti
Con <tipologia> viene inteso il codice a tre lettere in minuscolo che indica la tipologia radice dell'oggetto in questione come ad esempio : lab, eqp, inm, prj, ...
Per un elenco esaustivo fare riferimento all'"Alberatura tipologie RM/AP"
Configurazioni della ValidateLogic:
departmentChangeRoleValidator
Questa validazione opera sull'elemento internalOrganizationUnit figlio dell'oggetto radice.Se l'utente è in visione dipartimentale per il dipartimento X e tenta di modificare il ruolo del dipartimento X nell'oggetto radice, viene sollevato un warning se il nuovo ruolo prevede diritti inferiori.
Se l'utente è in visione dipartimentale per il dipartimento X e tenta di aggiungere un nuovo dipartimento, viene sollevato un warning se il nuovo ruolo del nuovo dipartimento prevede diritti superiori rispetto al suo dipartimento x.
Ad esempio se un utente accede in visione dipartimentale ad un progetto e cambia il ruolo del suo dipartimento da "Principale" ad "Aggregato", l'operazione viene segnalata perché il ruolo "Aggregato" prevede diritti inferiori.
Questa operazione è consentita in visione completa per i team abilitati.
Di default è possibile modificare il ruolo del proprio dipartimento con presentazione di un messaggio di warning e di conferma da parte dell'utente se la modifica dovesse casuare la perdita di diritti di scrittura. E' possibile disabilitare la modifica in caso di riduzione di permessi settando a false la variabile di configurazione generale ap.HIERACHICAL_ITEM_TYPE_IDENTIFIER_LOWERCASE.validation.departmentChangeRoleValidator.parameters.allowRoleChangeWithConsequentWritePermissionsDenied.enabled o la variabile di configurazione specifica ap.HIERACHICAL_ITEM_TYPE_IDENTIFIER_LOWERCASE.validation.[enter|save|element:element_discriminator:save|delete].departmentChangeRoleValidator.parameters.allowRoleChangeWithConsequentWritePermissionsDenied.enabled.
Se la variabile di configurazione non è presente (default) o è settata a true è possibile effettuare la modifica.
Per maggiori dettagli cfr. modello dati dell'entità in questione
Configurazioni della ValidateLogic:
departmentDeleteValidator
Questa validazione opera sull'elemento internalOrganizationUnit figlio dell'oggetto radice.Se l'utente è in visione dipartimentale per il dipartimento X e tenta di eliminare il dipartimento X dall'oggetto radice, viene sollevato un errore in quanto cancellando questa associazione, l'utente non potrebbe più operare su quell'oggetto.
Questa operazione è consentita in visione completa per i team abilitati.
Per maggiori dettagli cfr. modello dati dell'entità in questione
contributorAndOwnerValidatorWithStartEndDate
Questa validazione opera sugli elementi owner (responsabile scientifico) e contributor (partecipante) figli dell'oggetto radice.Viene verificato che l'intervallo di validità degli oggetti figli siano compresi all'interno della validità dell'oggetto padre.
Gli attributi per le date di inizio e fine sono startDate e endDate per gli elementi owner e contributor.
Sono di default gli stessi anche per l'oggetto padre, a meno che non venga inserita la configurazione gerarchica opportuna, ad es. "ap.prj.contributorAndOwner.validator.date.end.discriminator", che definisce il discriminator del metadato di tipo data dell'oggetto padre.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
Configurazioni della ValidateLogic:
- ap.TIPOLOGIA.contributorAndOwner.validator.date.start.discriminator
- ap.TIPOLOGIA.contributorAndOwner.validator.date.end.discriminator
uniquePeopleValidator
Questa validazione controlla che NON ci siano nominativi con intervalli di date che si sovrappongono in base a come viene configurata.Viene valuatata la configurazione ap.<itemType>.uniquePeople.csv.
Il valore della configurazione deve avere il seguente formato (ogni parametro deve essere separato dalla virgola):
- elenco di discriminator degli elementi da valutare separati dal carattere "|"
- true/false per indicare se sono consentiti elementi duplicate su intervalli temporali disgiunti
- true/false per indicare se sono consentiti elemente duplicate su ruoli distinti
Per maggiori dettagli cfr. excel modello dati dell'entità in questione.
Configurazioni della ValidateLogic:
transitionCommentValidator
Questa validazione, restringe solo ad alcuni attori l'obbligo di inserire la motivazione, per riportare allo stato di bozza (draft).Viene valuatata la configurazione ap.<itemType>.transitionComment.actor.discriminator.csv.
Se non presente o vuota il controllo viene effettuato per TUTTI gli attori, quindi per qualsiasi persona che tenta di riporare l'oggetto in bozza.
Se presente allora il controllo viene fatto SOLO per gli attori indicati nella configurazione.
La configurazione deve essere popolata con i discriminator degli attori interessati tutti separati da virgola, i valori degli attori disponibili sono visibili su Wiki nel modello dati per ogni singolo flusso alla colonna Attori (è il valore contenuto tra le parentesi tonde).
Esempio: ap.prj.transitionComment.actor.discriminator.csv = helpdesk,helpdesk/research,administrativeOwner,department si sta indicando che la motivazione per la transizione di stato deve essere motivata per le seguenti persone: Helpdesk, Divisione Ricerca, Referente amministrativo, Organi dipartimentali.
Per maggiori dettagli cfr. modello dati dell'entità in questione
Configurazioni della ValidateLogic:
attachmentValidator
Questa validazione valuta la configurazione ap.<wfItemType>.attachment.<state> dove wfItemType rappresenta la tipologia gerarchica e state rappresenta lo stato di arrivo (in fase di spostamento) o di salvataggio (in fase di salvataggio) in base a dove è stata messa la validazione.Se la configurazione è presente viene controllato che siano presenti gli allegati con le tipologie presenti nella configurazione.
Se la configurazione NON è presente viene controllato che sia presente ALMENO un allegato (indipendentemente dalla tipologia).
La configurazione deve essere popolata con l'elenco dei "code" delle voci di dizionario (ossia le tipologie) separati dal carattere virgola (per recuperare i code è possibile andare alla pagina di gestione dizionari e valutare i risultati nella colonna Codice).
Esempio: ap.spi.attachment.inquiry=spinoffAttachmentType.business-model,spinoffAttachmentType.commission-minutes: si sta indacando che per andare nello stato inquiry deve essere presente ALMENO un allegato di tipo business-model e ALMENO un allegato di tipo commission-minutes.
E' possibile anche valutare il fatto che deve essere presente ALMENO una delle tipologie, ossia si può indicare che tra le tipologie ABC.. deve essere presente almeno UNA delle tre. Per farlo basta separare le tipologie interessate dal carattere pipe.
Esempio: ap.spi.attachment.active=spinoffAttachmentType.business-model,spinoffAttachmentType.service-agreement,spinoffAttachmentType.commission-minutes|spinoffAttachmentType.senate-deliberation: si sta indacando che deve essere presente ALMENO un allegato di tipo business-model, deve essere presente ALMENO un allegato di tipo service-agreement, deve essere presente ALMENO un allegato di tipo commission-minutes o senate-deliberation.
Per rendere più leggibile il valore della configurazione è possibile anche sostituire i caratteri virgola con il carattere a capo.
Dal punto di vista del modello dati si tratta degli elementi di tipo attachment.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
Configurazioni della ValidateLogic:
approvalValidator
Questa validazione valuta la configurazione ap.<wfItemType>.approval.<state> dove wfItemType rappresenta la tipologia gerarchica e state rappresenta lo stato di arrivo (in fase di spostamento) o di salvataggio (in fase di salvataggio) in base a dove è stata messa la validazione.Se la configurazione è presente viene controllato che siano presenti le approvazioni con le tipologie presenti nella configurazione.
Se la configurazione NON è presente viene controllato che sia presente ALMENO una approvazione (indipendentemente dalla tipologia).
La configurazione deve essere popolata con l'elenco dei "code" delle voci di dizionario (ossia le tipologie) separati dal carattere virgola (per recuperare i code è possibile andare alla pagina di gestione dizionari e valutare i risultati nella colonna Codice).
Esempio: ap.prj.approval.inquiry=approvalType.department,approvalType.board: si sta indacando che per andare nello stato inquiry deve essere presente ALMENO una approvazione di tipo approvalType.department e ALMENO una approvazione di tipo approvalType.board.
E' possibile anche valutare il fatto che deve essere presente ALMENO una delle tipologie, ossia si può indicare che tra le tipologie ABC.. deve essere presente almeno UNA delle tre. Per farlo basta separare le tipologie interessate dal carattere pipe.
Esempio: ap.prj.approval.active=approvalType.universitySignature,approvalType.grantSignature,approvalType.contractCommitee|approvalType.spinoffCommitee: si sta indacando che deve essere presente ALMENO una approvazione di tipo approvalType.universitySignature, deve essere presente ALMENO una approvazione di tipo approvalType.grantSignature, deve essere presente ALMENO una approvazione di tipo approvalType.contractCommitee o approvalType.spinoffCommitee.
Per rendere più leggibile il valore della configurazione è possibile anche sostituire i caratteri virgola con il carattere a capo.
Dal punto di vista del modello dati si tratta degli elementi di tipo approval.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
Configurazioni della ValidateLogic:
notAllowedValidator
Questa logica scatena un errore e blocca l'azione sulla quale è collegata.
currentUserCannotEditHimself
Questa validazione viene scatenata in visione personale.Impedisce che l'utente sostituisca se stesso dalla sezione in cui è implementata la validazione, le sezioni disponibili sono:
- owner
Se l'operazione fosse consentita, dopo il salvataggio, l'utente non avrebbe più i diritti per accedere all'oggetto.
Per poter utilizzare questa validazione è necessario che nel modello dati sia presente l'attributo DISCRIMINAOR_ELEMNT + IdPreviousValue, che contiene l'id della persona precedente.
currentUserCannotDeleteHimself
Questa validazione viene scatenata in visione personale.Impedisce che l'utente elimini se stesso dalla sezione in cui è implementata la validazione, le sezioni disponibili sono:
- internalRepresentative
- administrativeOwner
- owner
checkCreationPermissionsValidator
Questa validazione viene scatenata in fase di creazione dell'oggetto.Controlla che l'utente corrente abbia i permessi per creare la tipologia di oggetto in questione.
Anche se agli utenti viene presentata sempre la lista dei tipi di oggetto che possono creare, questo ulteriore check serve per prevenire eventuali "hacking" di utenti che modificano volutamente il markup del form inserendo un tipo di oggetto per il quale non hanno le autorizzazioni.
sameDefinitionForGenericItemValidator
Questa validazione viene scatenata in fase di cambio della tipologia dell'oggetto.Controlla che la nuova tipologia selezionata abbia agganciato lo stesso flusso della tipologia precedente.
changeItemTypeForNotSynchronizedItemValidator
Questa validazione viene scatenata in fase di cambio di Tipo dell'oggetto.Non è possibile cambiare la tipologia, SE la scheda è già stata sincronizzata con U-GOV o l'utente non possiede i permessi sulla nuova tipologia selezionata.
Il cambio di tipologia è concesso se la configuration ap.<wfItemType>.itemTypeChange.enabled è uguale a true.
Introdotta la possibilità di cambio tipologia per Assitenza Tecnica (anche con scheda già sincronizzata con UGOV PJ e senza valutare la configurazione di cui sopra) in caso di scheda con flag legacy attivo.
Configurazioni della ValidateLogic:
changeItemTypeForSynchronizedItemValidator
Questa validazione viene scatenata in fase di cambio di Tipo dell'oggetto in un determinato stato del flusso.Non è possibile cambiare la tipologia in questo stato del flusso in quanto non compatibile con la sincronizzazione già avvenuta.
Introdotta la possibilità di cambio tipologia per Assitenza Tecnica in caso di scheda con flag legacy attivo.
roleElementValidator
Questa validazione controlla i ruoli per i possibili elementi: owner (Responsabili interni), internalOrganizationUnit (Unità organizzative interne), partner (Partner).Viene valutato l'attributo element.wfDictionaryMap[roleId].
Viene valutata anche la configurazione ap.<HIERACHICAL_ITEM_TYPE_IDENTIFIER_LOWERCASE>.<elementDiscriminator>.role.required.
Se true o non definita viene supposta obbligatorietà del ruolo
Se false il ruolo non è obbligatorio
Vengono valutate anche le seguenti configurazioni (che di default NON sono presenti).
Se non è presente ALCUNA configurazione la logica NON effettuerà alcun controllo.
- Uniqueness: ap.<HIERACHICAL_ITEM_TYPE_IDENTIFIER_LOWERCASE>.<elementDiscriminator>.role.uniqueness.csv
Se presente, viene controllato che ogni ruolo sia presente al massimo una volta.
Se non presente non viene fatto alcun controllo.
E' necessario specificare i ruoli degli elementi a cui effettuare il controllo sopra indicato, per farlo bisogna valorizzare la configurazione con l'elenco dei code dei ruoli (quello che si vede da interfaccia dei dizionari alla colonna Codici) separati da virgola. - Required: ap.<HIERACHICAL_ITEM_TYPE_IDENTIFIER_LOWERCASE>.<elementDiscriminator>.role.required.csv
Se presente, viene controllato che ogni ruolo elencato sia presente almeno una volta.
Se non presente non viene fatto alcun controllo.
E' necessario specificare i ruoli degli elementi a cui effettuare il controllo sopra indicato, per farlo bisogna valorizzare la configurazione con l'elenco dei code dei ruoli (quello che si vede da interfaccia dei dizionari alla colonna Codici) separati da virgola.
Alcuni esempi:
- configurazione ap.prj.owner.role.uniqueness.csv = ownerRole.administrative, si sta indicando che per i Responsabili scientifici dei Progetti deve essere presente al massimo un responsabile marcato con il ruolo Responsabile Scientifico e Amministrativo
- configurazione ap.rsc.internalOrganizationUnit.role.required.csv = researchCentreRole.main-seat,researchCentreRole.other-seats-involved, si sta indicando che per i Dipartimenti del Centro di ricerca devono essere presenti almeno due dipartimenti: uno marcato con il ruolo Sede principale e l'altro marcato con il ruolo Altre strutture coinvolte
Dal punto di vista del modello dati si tratta degli attributi owner, internalOrganizationUnit e partner.
Per maggiori dettagli cfr. modello dati dell'entità in questione
Configurazioni della ValidateLogic:
- ap.HIERACHICAL_ITEM_TYPE_IDENTIFIER_LOWERCASE.ELEMENTO.role.uniqueness.csv
- ap.HIERACHICAL_ITEM_TYPE_IDENTIFIER_LOWERCASE.ELEMENTO.role.required.csv
requiredAndUniquenessElementValidator
Questa validazione controlla i dati inseriti per gli elementi di tipo: internalOrganizationUnit (Unità organizzative interne).Vengono valutate le seguenti configurazioni (che di default NON sono presenti), se non è presente ALCUNA configurazione la logica NON effettuerà alcun controllo.
- Uniqueness: ap.<HIERACHICAL_ITEM_TYPE_IDENTIFIER_LOWERCASE>.<elementDiscriminator>.uniqueness
Se presente e valorizzata a true, viene controllato che ogni elemento NON sia presente più di una volta.
In tutti gli altri casi non verrà effettuato alcun controllo. - Required: ap.<HIERACHICAL_ITEM_TYPE_IDENTIFIER_LOWERCASE>.<elementDiscriminator>.required
Se presente e valorizzata a true, viene controllato che per ogni tipo di elemento sia presente almeno un elemento.
In tutti gli altri casi non verrà effettuato alcun controllo.
Alcuni esempi:
- configurazione ap.prj.internalOrganizationUnit.uniqueness = true, si sta indicando che per le Unità organizzative interne dei Progetti NON può essere inserita più volte la stessa Unità organizzativa
- configurazione ap.rsc.internalOrganizationUnit.required = true, si sta indicando che per le Unità organizzative interne dei Centri di Ricerca DEVE essepre presente ALMENO una Unità organizzativa
Dal punto di vista del modello dati si tratta degli attributi internalOrganizationUnit.
Per maggiori dettagli cfr. modello dati dell'entità in questione
Configurazioni della ValidateLogic:
- ap.HIERACHICAL_ITEM_TYPE_IDENTIFIER_LOWERCASE.ELEMENTO.role.uniqueness.csv
- ap.HIERACHICAL_ITEM_TYPE_IDENTIFIER_LOWERCASE.ELEMENTO.role.required.csv
contactEmailElementValidator
Questa validazione controlla che in fase di salvataggio del fragment contact che il formato della mail sia corretto.Dal punto di vista del modello dati si tratta degli attributi stringMap[description]
Dal punto di vista del modello dati si tratta degli elementi di tipo contact.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
contactTypeMainElementValidator
Questa validazione controlla che in fase di salvataggio del fragment contact che non venga marcato più di un contatto per tipologia.Dal punto di vista del modello dati si tratta degli attributi gaDictionaryMap[contactType]
Dal punto di vista del modello dati si tratta degli elementi di tipo contact.
Per maggiori dettagli cfr. modello dati dell'entità in questione.
itemTypeNotWithdrawnValidator
Questa validazione controlla che in fase di salvataggio non venga selezionata come tipologia di un item, una tipologia che è stata ritirata (ovvero per le quali non è possibile più creare nuovi item).E' possibile mantenere un item che è già presente in quella tipologia.
childAndParentDetectorDeleteValidator
Questa è una validazione che viene chiamata in ogni flusso di Laboratori, Grupppi di Ricerca, Grandi Attrezzature, Public-Engagement, Bandi di finanziamento e di Progetti quando si prova ad eliminare l'oggetto collegato.Essa impedisce che si possa eliminare l'oggetto se è collegato (sia da parte di padre, sia da parte di figlio) ad un altro item indicato qui sopra.
In caso la logica trovasse questi collegamenti, verrà presentato un messaggio di errore che mostrerà un elenco con tutti gli oggetti collegati.
Il messaggio di errore viene ricavato dall'etichetta con chiave error.delete.link.childAndParentDetected.
Per maggiori dettagli cfr. modello dati dell'entità specifica.
linkEntitiesAllowedStateValidator
Validazione che controlla il collegamento tra oggetti, in particolare verifica che gli oggetti collegati si trovino in determinati stati.Viene valutata la configurazione parametrica: ap.HIERACHICAL_ITEM_TYPE_IDENTIFIER_LOWERCASE.link.entities.csv.
Qualora la configurazione NON sia presente o NON sia valorizzata la validazione NON effettuerà alcun controllo.
La configurazione deve seguire il seguente standard:
- Concatenazione dei seguenti parametri con il carattere "|"
- discriminatorLink
- child o parent
- elenco degli stati accetabili separati dal carettere ";"
- concatenazione del carattere "," e degli attributi riportati sopra per il collegamento ad un altra entità
- per maggiore leggibilità è possibile utilizzare il carattere "a capo" dopo il carattere ","
Per maggiori dettagli cfr. modello dati dell'entità specifica.
wfItemAttributeSumOrConcatCoherenceValidator
Validazione che controlla la coerenza del valore di un attributo radice.Viene valutata la conf ap.<wfItemType>.coherence.<rootField>
Al momento come rootField è supportato solo numberMap[totalAmount]
- Se la configurazione non è presente, la validazione non effettua nessun controllo
- Se la configurazione è valorizzata allora deve avere il formato <ELEMENT>.<ATTRIBUTE> e la validazione controlla che la "somma" degli attributi specificati sia uguale al valore contenuto in *rootField*
Se viene definita la configurazione DEVE anche essere definita l'etichetta per il messaggio di errore.
L'etichetta deve avere il seguente formato: error.<wfItemType>.coherence.<rootField>.inconsistent
Continuando con l'esempio di prima l'etichetta sarà error.con.coherence.numberMap[totalAmount].inconsistent
In caso di inconsistenza, il messaggio di errore verrà riportato sia nella sezione dove ci sono gli elementi ripetibili (tabella degli elementi internalOrganizationUnitCost continuando con l'esempio precedente) sia sull'attributo radice (numberMap[totalAmount] continuando con l'esempio precedente).
Per questi motivi il messaggio deve essere molto specifico come ad esempio:
L'"Importo imponibile (EURO)" deve essere uguale alla somma dei valori "Corrispettivo per singola struttura di Ateneo coinvolta (EURO)" della sezione "Strutture interne"
dove ovviamente i vari nomi riportano le eventuali etichette customizzate
Nei prossimi rilasci verrà effettuato estensione della funzinoalità per prevedere anche ulteriori attributi
Configurazioni della ValidateLogic:
elementStartDatePrepopulateLogic
Questa logica effettua l'inizializzazione della data di inizio dove iniettata e SOLO se presente e valorizzata a true la configurazione ap.TYPE.prepopulate.ELEMENT_DISCRIMINATOR.startDate.enabled (ad esempio ap.prj.prepopulate.owner.startDate.enabled).La data di inizio viene valorizzata con la data di inizio dateMap[startDate] recuperata dall'oggetto radice.
Inoltre la logica effettua l'inizializzazione SOLO se il campo NON viene nascosto dalla logica standard per nascondere i campi/sezioni.
La logica viene eseguita in fase di creazione dell'oggetto (wfItemElement).
Configurazioni della ValidateLogic:
elementRolePrepopulateLogic
Questa logica effettua l'inizializzazione del ruolo del Dipartimento di afferenza SOLO se presente e valorizzata a true la configurazione ap.TYPE.prepopulate.ELEMENT_DISCRIMINATOR.role.enabled (ad esempio ap.prj.prepopulate.internalOrganizationUnit.role.enabled) e se esiste anche la configurazione ap.TIPOLOGIA.ELEMENT_DISCRIMINATOR.role.default.Il ruolo viene valorizzato con il valore presente nella configurazione ap.TIPOLOGIA.ELEMENT_DISCRIMINATOR.role.default.
Inoltre la logica effettua l'inizializzazione SOLO se il campo NON viene nascosto dalla logica standard per nascondere i campi/sezioni.
La logica viene eseguita in fase di creazione dell'oggetto (wfItemElement).
Istruzioni per sanare il pregresso
Le seguenti operazioni vanno fatte nel caso in cui questa logica venga abilitata in un ambiente in cui siano già presenti degli item della entità in questione.
Lanciare la seguente query su AP
Questa query aggiunge il ruolo di default agli elementi già creati
Le seguenti parole chiave vanno sostituite con i valori corretti
- CODICE_RUOLO -> Valore della configurazione ap.TIPOLOGIA.FRAGMENT.role.default (es: ouRoleEquipment.other)
- CODICE_ENTITÀ_TO_UPPER_CASE -> Codice dell'entità (es: EQP)
- DISCRIMINATOR_ELEMENT -> Discriminator dell'elemento/sezione (es: internalOrganizationUnit)
DECLARE vcount NUMBER (10); BEGIN SELECT count(*) INTO vcount FROM ap_dictionary WHERE external_identifiers LIKE 'code=CODICE_RUOLO'; IF (vcount = 1) THEN SELECT id INTO roleId FROM ap_dictionary WHERE external_identifiers LIKE 'code=CODICE_RUOLO'; FOR item_element in ( select ie.id from ap_item i LEFT JOIN ap_item_type it ON it.id = i.fk_item_type AND it.identifier LIKE 'CODICE_ENTITÀ_TO_UPPER_CASE.%' LEFT JOIN ap_item_element ie ON ie.fk_item = i.id AND ie.discriminator = 'DISCRIMINATOR_ELEMENT' LEFT JOIN ap_item_element_data ied ON ied.fk_item_element = ie.id AND ie.discriminator = 'roleId' WHERE ied.fk_dictionary_value is null ) LOOP INSERT INTO ap_item_element_data (discriminator, fk_item_element, fk_dictionary_value) VALUES('roleId', item_element.id, roleId); END LOOP; END IF; END;
Fare una resync full solr
La resync permette di aggiorna i dati su solr, quindi di averli aggiornati anche sui servizi rest
https://irisbuild01.private.cineca.it:9090/etl/job/ap-target-job-wfItem-entities/build?delay=0sec
Configurazioni della ValidateLogic:
Apply Logics
Elenco delle logiche di applicabilità delle validazioni di cui sopra.
Queste logiche definiscono in quali condizioni possono essere applicate le logiche di validazione a cui sono assegnate (di tipo: ValidateLogic).
Le logiche di validazione, se non sono associate ad alcuna applicabilità, sono sempre attive di default:
in caso contrario, la logica di applicabilità fa scattare o meno la validazione in base ai parametri che le vengono passati.
Per fare un esempio, in questo modo è possibile disabilitare una validazione (vincolante) in base ad un parametro di configurazione, oppure in base al valore di un'altro campo dell'item.
L'assegnazione ad una specifica logica di validazione di una applicabilità con determinati parametri è definita nel flusso stesso.
booleanFieldFalse
Questa ApplyLogic considera l'attributo associato al discriminator (primo parametro).Se questo attributo non è presente viene valutato il valore di default (secondo parametro opzionale: di default FALSE).
L'ApplyLogic viene soddisfatta SOLO se il valore valutato è FALSE.
Parametri supportati:
- discriminator - Nome del campo di tipo booleano
- defaultValue - Valore da considerare se il campo non è valorizzato
booleanFieldTrue
Questa ApplyLogic considera l'attributo associato al discriminator (primo parametro).Se questo attributo non è presente viene valutato il valore di default (secondo parametro opzionale: di default TRUE).
L'ApplyLogic viene soddisfatta SOLO se il valore valutato è TRUE.
Parametri supportati:
- discriminator - Nome del campo di tipo booleano
- defaultValue - Valore da considerare se il campo non è valorizzato
configFalse
Questa ApplyLogic considera il valore della configurazione con la chiave impostata (primo parametro).Se questa configurazione non è presente viene valutato il valore di default (secondo parametro opzionale: di default FALSE).
L'ApplyLogic viene soddisfatta SOLO se il valore valutato è FALSE.
Parametri supportati:
- key - Chiave del parametro di configurazione di tipo booleano
- defaultValue - Valore da considerare se la configurazione non è impostata
configTrue
Questa ApplyLogic considera il valore della configurazione con la chiave impostata (primo parametro).Se questa configurazione non è presente viene valutato il valore di default (secondo parametro opzionale: di default TRUE).
L'ApplyLogic viene soddisfatta SOLO se il valore valutato è TRUE.
Parametri supportati:
- key - Chiave del parametro di configurazione di tipo booleano
- defaultValue - Valore da considerare se la configurazione non è impostata
createByCloning
Questa è un'applicability rule che viene valutata prima di eseguire altre validazioni.Se ritorna true allora vengono eseguite le altre validazioni, altrimenti no.
Questa regola considera l'attributo copyFrom, tipicamente con etichetta "Copia da esistente" e la configurazione ap.TIPOLOGIA.create-by-cloning.enabled.
Per tutti gli oggetti che hanno questo attributo valorizzato a true e la configurazione valorizzata a true vengono disattivate le validazioni.
Configurazioni utilizzate:
dateFieldGreaterEqualThan
Questa è un'applicability rule che viene valutata prima di eseguire altre validazioni.Se ritorna true allora vengono eseguite le altre validazioni altrimenti no.
Verifica che la data nel campo dell'oggetto (wfItemData) in questione sia riferita ad una data maggiore o uguale a quella indicata
Parametri supportati:
- discriminator - Nome del campo di tipo Calendar
- dateValue - Data con cui fare il confronto in formato dd/MM/yyyy
dateFieldLessThan
Questa è un'applicability rule che viene valutata prima di eseguire altre validazioni.Se ritorna true allora vengono eseguite le altre validazioni altrimenti no.
Verifica che la data nel campo dell'oggetto (wfItemData) in questione sia riferita ad una data minore a quella indicata
Parametri supportati:
- discriminator - Nome del campo di tipo Calendar
- dateValue - Data con cui fare il confronto in formato dd/MM/yyyy
dictionaryFieldValue
Questa ApplyLogic considera l'attributo associato al discriminator (primo parametro) e il codice del dizionario a cui effettuare il match (secondo parametro).Nel caso in cui l'attributo sia collegato ad un Element (fragment) viene valutato il discriminator del fragment (terzo parametro opzionale).
L'ApplyLogic viene soddisfatta SOLO se il codice del dizionario dell'attributo corrisponde al codice del dizionario indicato.
Parametri supportati:
- discriminator - Nome del campo con valore a scelta
- dictinaryCode - Codice del dizionario da confrontare
- fragmentDiscriminator - Eventuale nome del fragment contenente il campo
isNewElement
Questa ApplyLogic considera l'attributo associato al discriminator (primo parametro).Se questo attributo non è presente viene valutato il valore di default (secondo parametro opzionale: di default FALSE).
L'ApplyLogic viene soddisfatta SOLO se il valore valutato è FALSE.
Parametri supportati:
- discriminator - Nome del campo di tipo booleano
- defaultValue - Valore da considerare se il campo non è valorizzato
isNotNewElement
Questa ApplyLogic considera l'attributo associato al discriminator (primo parametro).Se questo attributo non è presente viene valutato il valore di default (secondo parametro opzionale: di default FALSE).
L'ApplyLogic viene soddisfatta SOLO se il valore valutato è FALSE.
Parametri supportati:
- discriminator - Nome del campo di tipo booleano
- defaultValue - Valore da considerare se il campo non è valorizzato
isNotNull
Questa ApplyLogic considera l'attributo associato al discriminator (primo parametro).L'ApplyLogic viene soddisfatta SOLO se l'attributo è presente.
Parametri supportati:
- discriminator - Nome del campo da controllare
isNotWfState
Questa ApplyLogic abilita una validazione solo agli oggetti in uno stato specifico.Parametri supportati:
- description - Descrizione dello stato sul quale è attivo il controllo
isNull
Questa ApplyLogic considera l'attributo associato al discriminator (primo parametro).L'ApplyLogic viene soddisfatta SOLO se l'attributo NON è presente.
Parametri supportati:
- discriminator - Nome del campo da controllare
isVisible
Questa ApplyLogic considera l'attributo o elemento associato al discriminator (primo parametro).L'ApplyLogic viene soddisfatta SOLO se l'attributo è visibile, quindi non è nascosto tramite configurazioni standard di tipo hidden.
Parametri supportati:
- discriminator
isWfItemType
Questa ApplyLogic abilita una validazione solo agli oggetti di una specifica tipologia.Se la tipologia indicata è generica, è possibile specificare se abilitarla anche per le tipologie discendenti.
Parametri supportati:
- identifier - Codice identificativo della tipologia sulla quale è attivo il controllo
- hierarchical - Flag per estendere la ricerca all'intera gerarchia di tipologie (default: true)
isWfState
Questa ApplyLogic abilita una validazione solo agli oggetti in uno stato specifico.Parametri supportati:
- description - Descrizione dello stato sul quale è attivo il controllo
warningEnabled
Questa è un'applicability rule che pilota i messaggi di warning.Se ritorna true allora vengono eseguite le altre validazioni altrimenti no.
Se la variabile ap.TIPOLOGIA.warningAcknowlegement.validation.enabled è settata a true o non è valorizzata i messaggi di warning sono abilitati, altrimenti NON sono abilitati.
Configurazioni utilizzate:
yearGreaterOrEqualThanConfiguration
Questa è un'applicability rule che viene valutata prima di eseguire altre validazioni.Se ritorna true allora vengono eseguite le altre validazioni altrimenti no.
Verifica che l'oggetto in questione sia relativo ad un anno maggiore o uguale a quello definito nella configurazione ap.TIPOLOGIA.year.validation.threashold (es: ap.con.year.validation.threashold).
Se la configurazione NON è definita o non può essere convertita in un numero intero valido viene settato uguale a 0. Come default NON viene definita nel sistema.
Questo approccio serve per evitare lo scatenarsi delle validazioni su vecchi oggetti che non rispettano nuove e più stringenti validazioni, ed evitare quindi di dovere fare una bonifica a tappeto.
Configurazioni utilizzate:
Start Logics
Elenco delle logiche che possono essere eseguite all'avvio di un nuovo flusso
wfStartLogicInferLinkedProjectTypeFromSiblingCalls
Questa logica viene eseguita in fase di creazione di un nuovo bando se attiva la funzione di creazione del progetto a partire dalla selezione del bando.La logica è abilitata solo se
- la variabile di configurazione ap.prj.create-by-call.enabled è valorizzata a true
Configurazioni della StartLogic:
wfStartLogicParentCall
Questa logica viene eseguita in fase di creazione di un nuovo bando.Se attiva la creazione con associazione a un bando radice, tramite la variabile di configurazione
ap.prj.create-by-call.enabled valorizzata a true, la logica effettua il collegamento del Bando al Bando radice
SOLO nel caso in cui si scelga una gestione gerarchica del bando (metadato isHierarchical).
Se la gestione NON è gerarchica o la configurazione NON è true, verrà creato un figlio senza padre.
(cfr dettaglio delle altre configurazioni disponibili)
Configurazioni della StartLogic:
wfStartLogicContinuousTraining
Questa logica viene eseguita in fase di creazione di un nuovo oggetto.In base alla visione in cui è stato creato l'oggetto, viene effettuato un setup diverso:
-Visione completa:
-Viene estratto il dipartimento dal Direttore del Corso e viene inserito tra i Dipartimenti con ruolo di Organizzatore
-Viene estratto l'Ateneo dalla configurazione OBBLIGATORIA rm.orgunit.external.myOrganization e viene inserito tra i Soggetti terzi, con ruolo di Coordinatore
Visione dipartimentale:
-Viene estratto il dipartimento dal Direttore del Corso e viene inserito tra i Dipartimenti, con ruolo di Coordinatore
Per maggiori dettagli cfr. modello dati dell'entità continuousTraining
wfStartLogicEquipment
Questa logica viene eseguita in fase di creazione di una nuova attrezzatura.Effettua il setup dei seguenti attributi con i valori tra parentesi
- publicCalendar (false)
- internalOwnership (true)
- autocalculatedInventoryGoodsTotalValue (true)
Il setting viene effettuato se la configurazione ap.eqp.ugovpj.inventory.enabled è valorizzata a true
Per maggiori dettagli cfr. modello dati dell'entità equipment.
Configurazioni della StartLogic:
wfStartLogicPatent
Questa logica viene eseguita in fase di creazione di una nuova proprietà intellettuale.
wfStartLogicProjectDepartmentFundYear
Questa logica viene eseguita in fase di creazione di un progetto per il fondo di Ateneo (ATE).Viene impostato il valore dell anno della campagna in corso.
wfStartLogicProjectDepartmentFundPositionLastDate
Questa logica viene eseguita in fase di creazione di un progetto per il fondo di Ateneo (ATE).Viene impostato il valore del dipartimento di riferimento per ogni singola scheda avviata.
wfStartLogicProjectTypeFromCall
Questa logica viene eseguita in fase di creazione di un nuovo progetto se attiva la creazione del progetto a partire dalla selezione del bando.La logica è abilitata solo se
- la variabile di configurazione ap.prj.create-by-call.enabled è valorizzata a true
- l'attributo booleano isCreationByCall, specificato in fase di creazione, è valorizzato a true
Questa logica va sempre usata congiuntamente alla validazione callStartValidator (cfr dettaglio delle altre configurazioni disponibili)
Configurazioni della StartLogic:
wfStartLogicPnrrProject
Questa logica viene eseguita in fase di creazione di un nuovo Progetto/Bando.La logica verifica se nel Progetto/Bando è specificato che vengono utilizzati fondi PNRR.
- Se è già specificato (Sì/No) non viene effettuata alcuna modifica
- Se NON è già specificato (Sì/No) viene valutata la configurazione ap.HIERACHICAL_ITEM_TYPE_IDENTIFIER_LOWERCASE.pnrr.enabled, se è presente e settata a true viene specificato che per quel Progetto/Bando vengono utilizzati fondi PNRR, in tutti gli altri casi verrà specificato che per quel Progetto/Bando NON vengono utilizzati fondi PNRR
Configurazioni della StartLogic:
wfStartLogicCopyFromPublicEngagement
Questa logica viene eseguita in fase di creazione di un nuovo oggetto.Effettua la clonazione da una iniziativa esistente specificata nel form di start.
Per eseguire questa logica deve essere messa a true la configurazione ap.pen.create-by-cloning.enabled.
Nel caso in cui ci siano più flussi attivi per la stessa entità (qualora sia attiva la declinazione) tutti devono avere le stesse configurazioni di flavours e declinazioni, altrimenti non si garantisce il corretto funzionamento.
Per maggiori dettagli cfr. modello dati dell'entità publicEngagement.
Configurazioni della StartLogic:
wfStartLogicPublicEngagement
Questa logica viene eseguita in fase di creazione di un nuovo oggetto.Effettua il setup dei seguenti attributi con i valori tra parentesi SOLO per le iniziative che NON utilizzano il flusso di APEnet
- evaluationEnable (false)
- externalFinancing (0)
- totalBudget (0)
Se la tipologia di iniziativa è di tipo istituizione (tipologia PEN.INSTITUTION) e la configurazione ap.pen.copy-myOrganization-inside-orgUnit.enabled non è presente o è settata a true, l'ateno verrà aggiunto nella sezione delle strutture interne.
Inoltre è possibile specificare con quale ruolo l'ateneo deve essere censito, per farlo è necessario introddure la configurazione ap.pen.myOrganization.role.autopopulate.code specificando il code del ruolo interessato. Se questa configurazione NON è presente NON verrà specificato il ruolo.
Per maggiori dettagli cfr. modello dati dell'entità publicEngagement.
Configurazioni della StartLogic:
- ap.pen.create-apenet.enabled
- ap.pen.copy-myOrganization-inside-orgUnit.enabled
- ap.pen.myOrganization.role.autopopulate.code
- rm.orgunit.internal.root
wfStartLogicAcademicAreaFromOwner
Questa logica viene eseguita in fase di creazione di un nuovo oggetto (solo se non sono già presenti metadati relativi all'Area Accademica).Recupera l'Area Accademica del Responsabile Scientifico (owner) ed estrae la sua Area Accademica, aggiungendo quindi un nuovo elemento "Aree scientifiche coinvolte"(scientificAreasInvolved)
La data alla quale estrarre l'Area Accademica del responsabile è quella contenuta nel metadato con il nome recuperabile dalla configurazione ap.<tipologia>.owner.position.date.
Se questa configurazione
- NON è presente, viene usato la data inserita nel metadato startDate
- è presente ed ha valore uguale a CURRENT viene usata la data corrente
- è presente ed ha valore uguale a CURRENT_OR_LAST viene usata l'ultima Area Accademica disponibile (attiva o cessata)
- è presente ed NON ha un valore tra quelli elencati allora viene usata la data presente nel metadato con il nome specificato
E' possibile decidere se settare in automatico il metadato startDate per il responsabile.
Se la configurazione ap.<tipologia>.owner.startDate.enabled:
- NON è presente, allora NON viene abilitato l'automatismo di recupero della startDate
- è uguale a false allora NON viene abilitato l'automatismo di recupero della startDate
- è uguale a true allora viene inserita come startDate lo stesso valore recuperato con le logiche descritte al punto prima
- altrimenti NON viene abilitato l'automatismo di recupero della startDate
E' inoltre possibile stabilire quali siano i contesti all'interno dei quali cercare l'Area Accademica per il responsabile scientifico.
Questo viene pilotato dalla configurazione ap.<tipologia>.owner.position.context.
Se questa configurazione
- NON è presente, viene usato il solo contesto di ricerca (docenti, ricercatori, dottorandi, ...)
- è uguale a research allora viene usato il solo contesto di ricerca (docenti, ricercatori, dottorandi, ...)
- è uguale a support allora viene usato il solo contesto di supporto (TA)
- è uguale a ALL allora vengono usati entrambi i contesti
Con <tipologia> viene inteso il codice a tre lettere in minuscolo che indica la tipologia radice dell'oggetto in questione come ad esempio : lab, eqp, inm, prj, ...
Per maggiori dettagli cfr. modello dati dell'entità publicEngagement
Configurazioni della StartLogic:
- ap.TIPOLOGIA.owner.position.date
- ap.TIPOLOGIA.owner.startDate.enabled
- ap.TIPOLOGIA.owner.position.context
wfStartLogicResearchCentre
Questa logica, in caso di creazione di un centro di ricerca figlio della tipologia estratta dalla variabile ap.rsc.interuniversity.rootType crea come partner di default l'Ateneo.L'unità organizzativa associata all'Ateneo viene estratta dalla variabile rm.orgunit.external.myOrganization
Viene infine associato di default a questo partner il ruolo principale (researchCentrePartnerRole.main-seat)
Dal punto di vista del modello dati si tratta di partner
Per maggiori dettagli cfr. modello dati dell'entità in questione
Configurazioni della StartLogic:
wfStartLogicIdentifier
Questa logica viene eseguita in fase di creazione di un nuovo oggetto.Viene effetuata la costruzione dell'identificativo utilizzando la logica definita nella variabile di configurazione ap.<wfItemType>.identifier.logic configuration.
Se questa non è definita viene supposto l'utilizzo di wfStartLogicStandardIdentifier
Le logiche utilizzabili al momento sono:
- wfStartLogicStandardIdentifier
- wfStartLogicYearFromProposalStartDateIdentifier
- wfStartLogicOwnerDependentItemTypeFirstIdentifier
- wfStartLogicOwnerDependentLastNameFirstIdentifier
- wfStartLogicOwnerDependentLastNameFirstIdentifierAndAcronym
- wfStartLogicDepartmentAndOwnerDependentIdentifier
- wfStartLogicProjectWithYearCallIdentifier
Configurazioni della StartLogic:
wfStartLogicStandardIdentifier
Questa logica viene eseguita in fase di creazione di un nuovo oggetto.Viene effetuata la costruzione dell'identificativo dell'oggetto seguendo le seguenti regole:
<CODE_TIPOLOGIA>-<PROGRESSIVO>
- CODE_TIPOLOGIA: come da campo CODE da tassonomia scaricata dalla sezione "Alberatura tipologie RM/AP"; se si applica questa logica di costruzione identificativo evitare che il CODE abbia il carattere -, non può essere creata su DB la sequenza corrispondente per il progressivo
- PROGRESSIVO: numero progressivo
Per maggiori dettagli cfr. modello dati dell'entità Progetto e l'alberatura delle tipologie.
wfStartLogicYearFromProposalStartDateIdentifier
Questa logica viene eseguita in fase di creazione di un nuovo progetto.Viene effetuata la costruzione dell'identificativo dell'oggetto seguendo le seguenti regole:
<ANNO>-<CODICE>-<PROGRESSIVO>
- ANNO: estratto dalla Data di avvio pratica (proposalStartDate)
- CODICE: come da tassonomia ap-item-type.xls; se si applica questa logica di costruzione identificativo evitare che il CODE abbia il carattere trattino -, non può essere creata su DB la sequenza corrispondente per il progressivo
- PROGRESSIVO: numero progressivo contestuale all'anno e codice
Per maggiori dettagli cfr. modello dati dell'entità Progetto e l'alberatura delle tipologie.
wfStartLogicYearFromStartDate
Questa logica viene eseguita in fase di creazione di un nuovo oggetto.L'anno viene calcolato solo se il metadato è ancora nullo.
Viene recuperato l'anno dalla configurazione fatta nel seguente modo: ap.+"rootWfItemType"+owner.position.date e viene salvato nel metadato year
Esempio: ap.prj.owner.position.date
Configurazioni della StartLogic:
wfStartLogicOwnerDependentItemTypeFirstIdentifier
Questa logica effettua la costruzione dell'identificativo dell'oggetto seguendo le seguenti regole:<CODE_TIPOLOGIA>-<ANNO>-<PRIMA_LETTERA_NOME>-<PRIME_QUATTRO_LETTERE_COGNOME>-<PROGRESSIVO>
- CODE_TIPOLOGIA: come da campo CODE da tassonomia scaricata dalla sezione "Alberatura tipologie RM/AP"
- ANNO: anno in due cifre estratto dalla data di inizio
- PRIMA_LETTERA_NOME: prima lettera del nome del responsabile
- PRIME_QUATTRO_LETTERE_COGNOME: prime quattro lettere del cognome del responsabile
- PROGRESSIVO: numero progressivo
Per maggiori dettagli cfr. modello dati dell'entità Progetto e l'alberatura delle tipologie.
wfStartLogicOwnerDependentLastNameFirstIdentifierAndAcronym
Questa logica effettua la costruzione dell'identificativo dell'oggetto seguendo le seguenti regole:<PRIME_QUATTRO_LETTERE_COGNOME>_<PRIMA_LETTERA_NOME>_<ANNO>_<CODE_TIPOLOGIA>_<ACRONIMO>_<PROGRESSIVO>
- PRIME_QUATTRO_LETTERE_COGNOME: prime quattro lettere del cognome del responsabile
- PRIMA_LETTERA_NOME: prima lettera del nome del responsabile
- ANNO: anno in due cifre estratto dalla data di inizio
- CODE_TIPOLOGIA: come da campo CODE da tassonomia scaricata dalla sezione "Alberatura tipologie RM/AP"
- ACRONIMO: acronimo dell'oggetto (può non essere presente)
- PROGRESSIVO: numero progressivo
Per maggiori dettagli cfr. modello dati dell'entità Progetto e l'alberatura delle tipologie.
Configurazioni della StartLogic:
wfStartLogicDepartmentAndOwnerDependentIdentifier
Questa logica effettua la costruzione dell'identificativo dell'oggetto seguendo le seguenti regole:<VALORE_PERSONALIZZABILE>-<CODICE_TIPO_PROGETTO>-<ULTIME_DUE_CIFRE_ANNO>-<PRIME_5_LETTERE_COGNOME>_<PROGRESSIVO>
- VALORE_PERSONALIZZABILE:
- CODICE_CSA_DEL_DIPARTIMENTO: codice del dipartimento recuperato nel metadato orgUnit.stringMap[idCsa]
- CODICE_IDAB_DEL_DIPARTIMENTO: codice del dipartimento recuperato nel metadato orgUnit.stringMap[idAb]
- ID_DEL_DIPARTIMENTO: identificativo univoco del dipartimento recuperato nel metadato orgUnit.id
- CODICE_ACRONYM_DEL_DIPARTIMENTO: codice del dipartimento recuperato nel metadato orgUnit.stringMap[acronym]
- CODICE_TIPO_PROGETTO: come da campo CODE da tassonomia scaricata dalla sezione "Alberatura tipologie RM/AP"
- ULTIME_DUE_CIFRE_ANNO: anno in due cifre estratto dalla data di inizio
- PRIME_5_LETTERE_COGNOME: prime cinque lettere del cognome del responsabile
- PROGRESSIVO: numero progressivo
Se la variabile di configurazione è valorizzata con:
- csa verrà utilizzato il metadato orgUnit.stringMap[idCsa]
- ugov verrà utilizzato il metadato orgUnit.stringMap[idAb]
- iris verrà utilizzato il metadato orgUnit.id del dipartimento
- acronym verrà utilizzato il metadato orgUnit.stringMap[acronym]
Configurazioni della StartLogic:
wfStartLogicOwnerDependentLastNameFirstIdentifier
Questa logica effettua la costruzione dell'identificativo dell'oggetto seguendo le seguenti regole:<CODE_TIPOLOGIA>-<ANNO>-<PRIMA_LETTERA_NOME>-<PRIME_QUATTRO_LETTERE_COGNOME>-<PROGRESSIVO>
- PRIME_QUATTRO_LETTERE_COGNOME: prime quattro lettere del cognome del responsabile
- PRIMA_LETTERA_NOME: prima lettera del nome del responsabile
- CODE_TIPOLOGIA: come da campo CODE da tassonomia scaricata dalla sezione "Alberatura tipologie RM/AP"
- ANNO: anno in due cifre estratto dalla data di inizio
- PROGRESSIVO: numero progressivo
Per maggiori dettagli cfr. modello dati dell'entità Progetto e l'alberatura delle tipologie.
wfStartLogicProjectWithYearCallIdentifier
Questa logica effettua la costruzione dell'identificativo dell'oggetto seguendo le seguenti regole:<CODE_TIPOLOGIA>_<ANNO>_<ACRONIMO>_<PRIME_SEI_LETTERE_COGNOME>_<PRIMA_LETTERA_NOME>_<PROGRESSIVO>
- CODE_TIPOLOGIA: come da campo CODE da tassonomia scaricata dalla sezione "Alberatura tipologie RM/AP" recuperata a partire dal Bando di finanziamento o direttamente da selezione in fase di creazione
- ANNO: anno in quattro cifre estratto dalla data di inizio del Bando di finanziamento collegato (se non presente verrà inserito "XX")
- ACRONIMO: acronimo dell'oggetto (può non essere presente)
- PRIME_SEI_LETTERE_COGNOME: prime sei lettere del cognome del responsabile
- PRIMA_LETTERA_NOME: prima lettera del nome del responsabile
- PROGRESSIVO: numero progressivo
Per maggiori dettagli cfr. modello dati dell'entità Progetto e l'alberatura delle tipologie.
wfStartLogicAcademicFieldPrefill
Questa logica viene eseguita in fase di creazione di un nuovo oggetto.Recupera il responsabile scientifico (owner), estrae il SSD relativo all'ultimo rapporto di lavoro valido prioritario relativo al contesto ricerca ed aggancia questa informazione all'oggetto radice.
Nel caso in cui la Data di Avvio Pratica (proposalStartDate) sia precedente o uguale al 24-06-2024 verranno estratti gli SSD2000, altrimenti se è posteriore verranno estratti gli SSD2024.
wfStartLogicMultipleOwners
Questa logica viene eseguita in fase di creazione di un nuovo oggetto.SE l'attributo "Struttura capofila diversa da afferenza del responsabile?" (booleanMap[customizedInternalOrganization]) è settato a true la logica recupera la Struttura presente nel relativo campo (organizationUnitMap[internalOrganizationUnit]) e l'aggiunge alle Strutture interne (all'oggetto radice internalOrganization).
SE l'attributo "Struttura capofila diversa da afferenza del responsabile?" (booleanMap[customizedInternalOrganization]) è settato a in qualsiasi altro caso la logica effettua il setup del responsabile scientifico (owner) ed estrae la sua afferenza dipartimentale (se presente) che aggancia alle Strutture interne (all'oggetto radice internalOrganization).
Il ruolo assegnato alla Struttura interna viene valorizzato di default, e viene preso dalla configurazione ap.<tipologia oggetto radice>.<tipologia oggetto fragment>.role.main.
La data alla quale estrarre l'afferenza dipartimentale del responsabile è quella contenuta nel metadato con il nome recuperabile dalla configurazione ap.<tipologia>.owner.position.date.
Se questa configurazione
- NON è presente, viene usato la data inserita nel metadato startDate
- è presente ed ha valore uguale a CURRENT viene usata la data corrente
- è presente ed ha valore uguale a CURRENT_OR_LAST viene usata l'ultima afferenza dipartimentale disponibile (attiva o cessata)
- è presente ed NON ha un valore tra quelli elencati allora viene usata la data presente nel metadato con il nome specificato
E' possibile decidere se settare in automatico il metadato startDate per il responsabile.
Se la configurazione ap.<tipologia>.owner.startDate.enabled:
- NON è presente, allora NON viene abilitato l'automatismo di recupero della startDate
- è uguale a false allora NON viene abilitato l'automatismo di recupero della startDate
- è uguale a true allora viene inserita come startDate lo stesso valore recuperato con le logiche descritte al punto prima
- altrimenti NON viene abilitato l'automatismo di recupero della startDate
E' inoltre possibile stabilire quali siano i contesti all'interno dei quali cercare l'afferenza dipartimentale per il responsabile scientifico.
Questo viene pilotato dalla configurazione ap.<tipologia>.owner.position.context.
Se questa configurazione
- NON è presente, viene usato il solo contesto di ricerca (docenti, ricercatori, dottorandi, ...)
- è uguale a research allora viene usato il solo contesto di ricerca (docenti, ricercatori, dottorandi, ...)
- è uguale a support allora viene usato il solo contesto di supporto (TA)
- è uguale a ALL allora vengono usati entrambi i contesti
Questa variabile, se definita, contiene l'elenco, separato da virgola, degli elementi (recuperabili dal modello dati) da creare agganciati alla struttura estratta dal responsabile.
Consideriamo questo esempio.
Se la variabile ap.prj.internalOrganizationUnit.inferredChid.csv è valorizzata con internalOrganizationUnitCost questo vorrà dire che verrà creato un elemento di questo tipo associato alla struttura del responsabile scientifico.
Fare attenzione che per usare questa funzione l'elemento inferito (nell'esempio internalOrganizationUnitCost) deve prevedere nel suo modello dati l'attributo ouId che è l'attributo che lega questo elemento alla struttura del responsabile.
Con <tipologia> viene inteso il codice a tre lettere in minuscolo che indica la tipologia radice dell'oggetto in questione come ad esempio : lab, eqp, inm, prj, ...
Per un elenco esaustivo fare riferimento all'"Alberatura tipologie RM/AP"
Configurazioni della StartLogic:
- ap.prj.internalOrganizationUnit.inferredChid.csv
- ap.prj.owner.customizableAutomaticInternalOrganizationExtractionInCreationPhase.enabled
- ap.TIPOLOGIA.FRAGMENT.role.main
- ap.TIPOLOGIA.owner.position.context
wfStartLogicPartner
Questa logica viene eseguita in fase di creazione di un nuovo progetto.Viene eseguito l'inserimento dell'Ateneo tra i partner.
La variabile di configurazione ap.prj.partner.role.autopopulate.enabled, attiva di default, gestisce l'inserimento del ruolo associato al Partner.
La voce di dizionario che definisce il ruolo da inserire è specificata nella variaible ap.prj.partner.role.autopopulate.code.
Per maggiori dettagli cfr. excel modello dati dell'entità di riferimento
Configurazioni della StartLogic:
wfStartLogicMultipleInternalOrganizationUnits
Questa logica viene eseguita in fase di creazione di un nuovo oggetto.Aggiunge l'unità organizzativa (internalOrganizationUnit) all'oggetto che si sta creando utilizzando l'unità organizzativa specificata in fase di creazione (organizationUnitMap[ouId]).
Aggiunge anche, se previsto il ruolo di default dell'unità organizzativa e se viene trovata la configurazione ap.<tipologia>.internalOrganizationUnit.role.main, dove <tipologia> indica il codice della tipologia. che è navigabile fino alla radice.
Ad esempio se la configurazione ap.pen.formazione-comunicazione.internalOrganizationUnit.role.main è settata come 'ouRolePublicEngagement.manager', vuol dire che il ruolo con codice 'ouRolePublicEngagement.manager' è quello che verrà associato all'unità organizzativa selezionata nel caso di iniziative di public engagement di formazione e comunicazione.
Se la configurazione fosse ap.pen.internalOrganizationUnit.role.main (e non esistesse quella più specifica presentata sopra) e fosse settata a 'ouRolePublicEngagement.manager', vuol dire che il ruolo con codice 'ouRolePublicEngagement.manager' è quello che verrà associato all'unità organizzativa selezionata nel caso di tutte le iniziative di public engagement
Configurazioni della StartLogic:
wfStartLogicAdministrativeOwnerFromUser
Questa logica viene eseguita in fase di creazione di un nuovo oggetto.Aggiunge il referente amministrativo all'oggetto che si sta creando.
Precisamente:
- Viene recuperata la macrotipologia dell'oggetto che si sta creando (macrotype)
- Viene recuperata la variabile di configurazione ap.<macrotype>.administrativeOwner.inheritFromLoggedUserIfResourcePresent
- Questa configurazione, se presente, contiene le risorse relative ai profili per i quali inserire come referente amministrativo dell'oggetto, l'utente corrente.
Questo vuol dire che se un utente che appartiene a un team con profili dipartimentali o divisione ricerca effettua la creazione di un oggetto, verrà inserito lui stesso come referente amministrativo. Per maggiori dettagli cfr. modello dati dell'entità in questione.
Configurazioni della StartLogic:
wfStartLogicInheritInternalOrganizationUnitFromTeamOfLoggedUser
Questa logica viene eseguita in fase di creazione di un nuovo oggetto in visione dipartimentale.Precisamente:
- viene recuperata la variabile di configurazione ap.<macrotype>.internalOrganizationUnit.inheritFromTeamOfLoggedUser.enabled
- SOLO se la configurazione è valorizzata con true allora
- nel form di creazione viene presentata una tendina per consentire la scelta della struttura alla quale agganciare l'oggetto che si sta creando
- alla nuova struttura viene associato il ruolo definito nella variabile ap.<macrotype>.internalOrganizationUnit.inheritFromTeamOfLoggedUser.role, se definita
Supponiamo un operatore in visione dipartimentale profilato nei team
- Profilo di dipartimento per Dipartimento di Matematica
- Profilo di dipartimento per Dipartimento di Fisica
- ap.prj.internalOrganizationUnit.inheritFromTeamOfLoggedUser.enabled valorizzata a true
- ap.prj.internalOrganizationUnit.inheritFromTeamOfLoggedUser.role valorizzata a ouRole.main (Principale)
Questo vuol dire che l'operatore, una volta cliccato sul bottone "Nuovo" vedrà una tendina con la lista delle strutture in cui è profilato (Dipartimento di Matematica e Dipartimento di Fisica)
Una volta scelta la struttura, verrà creato l'oggetto agganciato a quella specifica struttura marcata con il ruolo ouRole.main (Principale)
Attenzione che tipicamente questa logica viene eseguita dopo quella standard che estrae la struttura dal responsabile.
Qualora la struttura estratta dal responsabile sia la stessa dell'operatore che sta facendo la creazione, NON verrà aggiunta un'altra struttura ma verrà mantenuto l'elemento già presente con il relativo ruolo.
Per uniformità con il comportamento della start logic wfStartLogicMultipleOwners viene replicato il funzionamento pilotato da ap.<tipologia>.internalOrganizationUnit.inferredChidCsv.
Questa variabile, se definita, contiene l'elenco, separato da virgola, degli elementi (recuperabili dal modello dati) da creare agganciati alla struttura.
Consideriamo questo esempio.
Se la variabile ap.prj.internalOrganizationUnit.inferredChidCsv è valorizzata con internalOrganizationUnitCost questo vorrà dire che verrà creato un elemento di questo tipo associato alla struttura selezionata dall'operatore.
Fare attenzione che per usare questa funzione l'elemento inferito (nell'esempio internalOrganizationUnitCost) deve prevedere nel suo modello dati l'attributo ouId che è l'attributo che lega questo elemento alla struttura del responsabile.
Configurazioni della StartLogic:
- ap.TIPOLOGIA.internalOrganizationUnit.inheritFromTeamOfLoggedUser.enabled
- ap.TIPOLOGIA.internalOrganizationUnit.inheritFromTeamOfLoggedUser.role
wfStartLogicInternalRepresentativeFromUser
Questa logica viene eseguita in fase di creazione di un nuovo oggetto e aggiunge l'elemento delegato (internalRepresentative) all'oggetto che si sta creando.La logica è abilitata solo se
- la variabile di configurazione ap.<macrotype>.personal-view.create-for-other-people.enabled è valorizzata a true, dove <macrotype> indica la macrotipologia dell'oggetto che si sta creando.
- l'attributo booleano isCreatorOwner, specificato in fase di creazione, è valorizzato a false
Configurazioni della StartLogic:
wfStartLogicLegacy
Questa logica viene eseguita in fase di creazione di un nuovo oggetto e setta l'attributo legacy a false (Legacy - disabilitare validazioni ed invio ad UGOV PJ).Settandolo di default a false NON verrà disattivata alcuna validazione/invio.
Dal punto di vista del modello dati si tratta dell'attributo booleanMap[legacy].
Per maggiori dettagli cfr. modello dati dell'entità in questione.
wfStartLogicVisibileOnPortal
Questa logica viene eseguita in fase di creazione di un nuovo oggetto e solo se il metadato non è ancora popolato.Viene effetuata la valorizzazione dell'attributo "Visibile su portale pubblico"(booleanMap[visibleOnPortal]) utilizzando il valore definita nella variabile di configurazione ap.<wfItemType>.visibleOnPortal.default.
Per esempio per utilizzarla nei Gruppi di Ricerca (workgroup) la configurazione dovrà essere "ap.wkg.visibleOnPortal.default".
Questa configurazione è trasversale su tutti i flussi di quella entità.
I possibili casi sono:
- Se la config è popolata è ha valore true (indipendentemente dal case) allora viene presettato il valore booleano a true
- Se la config è popolata è ha valore false (indipendentemente dal case) allora viene presettato il valore booleano a false
- Se la config non è presente o non è popolata o il valore è diverso da true/false allora non viene fatto nessun preset
Si riporta una query di esempio che integra gli item di tipo PRJ con il metadato visibleOnPortal settato a true per i soli item che non hanno il metadato: la query è quindi safe e può essere rilanciata.
insert into ap_item_data (fk_item, discriminator, boolean_value) select ai.id, 'visibleOnPortal', 1 from ap_item ai join ap_item_type ait on ait.id=ai.fk_item_type left join ap_item_data aid on aid.fk_item=ai.id and aid.discriminator='visibleOnPortal' where ait.identifier like 'PRJ.%' and aid.fk_item is null
Dopo l'avvenuta modifica su DB è necessario procedere ad una resync su SOLR con la relativa procedura (DS6 - Core Entities SOLR)
Configurazioni della StartLogic:
wfStartLogicIntegerMapYearFromStartDate
Questa logica viene eseguita in fase di creazione di un nuovo oggetto.L'anno del metadato integerMap[year] viene recuperato (SOLO se ancora nullo) dalla Data di inizio (metadato dateMap[startDate]).
Action Logics
Elenco delle logiche che possono essere eseguite durante una modifica o una transizione di stato
spinoffWfActionLogicBalancePreviousYear
Questa logica si occupa di gestire il fatturato e utile degli anni precedenti.Viene eseguita ogni volta che viene congelata una versione della Spin-off, creando un riepilogo del fatturato e utile dei 3 anni precedenti (se presenti).
Viene creato un elemento sia per il fatturato che per l'utile per ognuno dei 3 anni precedenti alla data di riferimento del monitoraggio, nel caso ci siano più fatturati/utili di riferimento per un singolo anno viene preso l'elemento con la data più recente.
NON viene creato l'elemento se per quel determinato anno NON c'è alcun fatturato/utile.
Viene creato l'elemento SE per quel determinato anno di riferimento è presente un fatturato/utile contentente nella data di fine (attributo dateMap[endDate]) l'anno in questione.
Per maggiori dettagli cfr. modello dati dell'entità in oggetto.
spinoffWfActionLogicCopyContributorAndExternalOrganizationUnitInsideOwner
Questa logica serve per autopopolare la Compagine sociale con tutti i Proponenti e Membri interni/esterni in fase di inizio Costituzione.Viene eseguita SE l'operatore esprime il consenso a copiare tutti i Proponenti e Membri interni/esterni nella Compagine sociale e se questa non è popolata.
In caso di consenso viene riportato anche l'ateneo nella Compagine sociale SOLO SE la tipologia della Spin-off è SPI.UNI-PARTECIPATION.
A tutti i partecipanti della Compagine sociale viene impostata come data di inizio validità quella della data di Costituzione SE l'operatore ha espresso il consenso in merito.
Dal punto di vista del modello dati si tratta degli elementi di tipo contributor, externalOrganizationUnit e owner.
Per maggiori dettagli cfr. modello dati dell'entità in oggetto.
Configurazioni utilizzate:
spinoffWfActionLogicOwnerSummary
Questa logica serve per il conteggio degli elementi di tipo owner.Viene eseguita ogni volta che viene congelata una versione della Spin-off, eseguendo il contegggio degli elementi per ogni tipologia della Compagine Sociale.
Per ogni tipologia con ALMENO un elemento viene creato il relativo elemento di tipo ownerSummary. Per maggiori dettagli cfr. modello dati dell'entità in oggetto
spinoffWfActionLogicRestoreConstitution
Questa logica serve per ripristinare la Spin-off con i dati presenti quando è stata costituita e per rimuovere tutti i monitoraggi e la costituzione.Questa logica viene attivata SOLO se l'utente conferma di voler eseguire tale operazione.
Tutti monitoraggi e la costituzione verranno settati con withdrawn = true.
Dal punto di vista del modello dati si tratta degli attributi di tipo booleanMap[restoreConstitution].
Per maggiori dettagli cfr. modello dati dell'entità in oggetto.
wfActionDeletePersonElementFromOldTutor
Questa logica si occupa di eliminare dal profilo personale del tutor/persona in ingresso (CV Scientifico) il collegamento tra le due persone.Questa logica viene triggerata in fase di uscita dallo stato riaperto.
wfActionLogicCreatePersonElementIncoming
Questa logica viene triggerata in ingresso nello stato validated.Crea un nuovo elemento nella sezione della mobilità in ingresso all'interno del profilo personale (CV Scientifico)
Se esiste già allora lo aggiorna.
wfActionLogicCreateRmItem
Questa logica viene chiamata in ingresso nello stato approved e crea un nuovo rmItem a partire da quello di AP.Se esiste già, allora lo aggiorna.
Questo è collegato all'item di AP essendo il suo identificativo presente fra i suoi metadati (e viceversa).
Vengono aggiunti/aggiornati anche i dipartimenti associati all'item.
wfActionLogicDeleteRmItem
Questa logica viene chiamata in ingresso nello stato submitted (In Validazione) ed elimina il rmItem agganciato precedentemente (se presente) a quello di AP.Questo è collegato all'item di AP essendo il suo identificativo presente fra i suoi metadati (e viceversa).
Vengono eliminati anche i dati dei dipartimenti associati all'item.
wfActionLogicEnterMailSender
Questa action logic effettua l'invio di segnalazioni via mail ai vari attori del flusso.L'invio delle segnalazioni viene pilotato dalle configurazioni abilitate.
Cfr. Configurare le notifiche di RM
wfActionLogicEnterVersionDate
Questa logica salva la data corrente nel metadato dateMap[versionDate]
wfActionLogicGenerateArchiveNumberOnlyOnce
Questa logica effettua la creazione una tantum di un identificativo univoco per il metadato archiveNumberConfigurazioni utilizzate:
wfActionLogicHandleLinkedProjectType
Questa logica di sistema gestisce il metadato linkedProjectType.Per maggiori dettagli fare riferimento al modello dati dell'entità Bando
wfActionLogicManufacturerCsv
Questa logica viene invocata in ingresso nello stato approved se la variabile di configurazione ap.eqp.ugovpj.inventory.enabled è settata a true.La configurazione menzionata è quella che abilita il recupero dei beni di inventario da UGOV.
La logica crea o aggiorna il metadato manufacturerCsv con l'elenco delle denominazioni dei produttori dei singoli beni di inventario che fanno parte dell'attrezzatura.
Nel caso in cui una grande attrezzatura sia composta da beni di cui una parte prodotti da una stessa azienda, questa verrà presentata una sola volta.
Stante la natura aggregata del metadato, NON sarà possibile risalire a quale azienda abbia prodotto quale bene.
A questo scopo è sempre possibile utilizzare, a partire dell'identificativo del singolo bene di inventario, il servizio di UGOV Inventario per il recupero dell'informazione.
Configurazioni utilizzate:
wfActionLogicSaveCallFromGrantor
Questa logica recupera i bandi specificate negli elementi grantor (callId) e inserisce degli elementi callProjectLink L'operazione viene effettuata SOLO se la conf ap.<wfItemType>.callProjectLink.inheritFromGrantor è valorizzata a trueConfigurazioni utilizzate:
WfActionLogicSaveContextVision
Questa action logic serve per generare i task necessari per rendere visibile l'oggetto in visione dipartimentale.I task vengono generati in automatico in fase di transizione da uno stato ad un altro.
Nei casi in cui le informazioni vengono modificate senza effettuare nessuna transizione è necessario procedere ad una rigenerazione dei task.
Ad esempio se viene aggiunto un nuovo dipartimento ad un progetto e viene effettuato un salvataggio (senza transizione di stato), questa logica, agganciata in salvataggio, genera i task per rendere visibile l'oggetto anche in visione dipartimentale del nuovo dipartimento.
wfActionLogicSaveElementStartDate
Questa logica effettua l'inizializzazione della data di inizio dove iniettata e SOLO se presente e valorizzata a true la configurazione ap.TYPE.prepopulate.[owner|contributor|administrativeOwner].startDate.enabled (ad esempio ap.con.prepopulate.owner.startDate.enabled).La data di inizio viene valorizzata con la data di inizio dateMap[startDate] recuperata dall'oggetto radice.
Inoltre la logica effettua l'inizializzazione SOLO se il campo NON viene nascosto dalla logica standard per nascondere i campi/sezioni.
La logica viene eseguita in fase di salvataggio dell'oggetto (wfItem).
Configurazioni utilizzate:
wfActionLogicSaveFieldAutocalculate
Questa logica calcola il fieldName (indicato come primo parametro) come somma o concatenazione degli elementi multipli indicati nella configurazione ap.TIPOLOGIA.autocalculate.ROOT_FIELD_NAME Il contenuto della conf deve avere il seguente formato <ELEMENT>.<ATTRIBUTE>Configurazioni utilizzate:
wfActionLogicSaveFieldReset
Questa logica resetta il valore del campo individuato dal fieldName (primo parametro, anche element multitipo) se la condizione specificata nel secondo parametro è veraParametri supportati:
- fieldName - Nome del campo da sbiancare
- condition - Condizione da valutare (in codice SPEL)
wfActionLogicSaveHierarchicalCall
Questa logica di sistema gestisce il metadato isParent e isHierarchical.Quando un bando figlio viene sganciato da un padre, viene aggiornato un flag (isHierarchical) che lo
identificherà come bando senza gerarchia.
Quando un bando figlio viene agganciato ad un padre, viene aggiornato un flag (isHierarchical) che lo
identificherà come bando con gerarchia.
Per maggiori dettagli fare riferimento al modello dati dell'entità Bando
Configurazioni utilizzate:
wfActionLogicSaveInternalContributionInferenceFromGrantor
Questa logica serve per il calcolo del metadato internalContribution come somma di grantor.numberMap[financingQuota] Il calcolo automatico viene fatto se la conf ap.prj.autocalculate.numberMap[internalContribution].enabled è settata a true Oltre a internalContribution, viene anche calcolato internalCost con la seguente regola internalCost = internalContribution + internalCofinancing + manHoursCofinancingATTENZIONE!!! Se viene attivata la conf indicata in precedenza QUALUNQUE VALORE PRESENTE in internalContribution e internalCost verranno sovrascritti!!!
Configurazioni utilizzate:
wfActionLogicSaveNewIdentifier
Questa logica serve per il ricalcolo dell'identificativo della scheda in caso di cambio di tipologia.Il ricalcolo viene effettuato SOLO se la variabile di configurazione ap.<wfItemType>.identifier.recalculation.enabled è settata a true o non è valorizzata.
Configurazioni utilizzate:
wfActionLogicSaveNewNextStates
Questa logica serve per l'aggiornamento degli stati successivi in caso di cambio tipologia a tutti i task dell'oggetto corrente.L'aggiornamento viene effettuato se viene rilevato un cambio di tipologia.
wfActionLogicSaveNewYear
Questa logica serve per l'aggiornamento dell'anno della scheda in caso di cambio di data.L'aggiornamento viene effettuato se viene recuperata una data e se l'anno della data è diverso dal valore presente nel campo anno (year).
La data viene recuperata dalla configurazione ap.<wfItemType>.owner.position.date,
dove può essere indicata direttamente (esempio: startDate), OPPURE:
se la configurazione viene valorizzarta con CURRENT o CURRENT_OR_LAST,
verrà effettuato un recupero della data presente nel metadato startDate,
se non presente verrà recuperata la data presente nel metadato proposalStartDate,
se non presente verrà recuperata la data presente nel metadato applicationDate.
Configurazioni utilizzate:
wfActionLogicSavePersonalVision
Questa action logic serve per generare i task necessari per rendere visibile l'oggetto nella visione personale.I task vengono generati in automatico in fase di transizione da uno stato ad un altro.
Nei casi in cui le informazioni vengono modificate senza effettuare nessuna transizione è necessario procedere ad una rigenerazione dei task.
wfActionLogicTransitionLogger
Questa logica serve per la gestione del logging delle transizioni di stato nel metadato transitionLog.Se il metadato NON è presente nel modello dati, non sarà visibile nell'interfaccia web.
Questa logica viene inserita come enter action logic per tutti gli stati nei flussi per i quali si vuole abilitare il logging delle transizioni di stato.
Se necessario, è possibile richiedere all'utente che sta effettuando la transizione di stato di inserire un messaggio che giustifichi la transizione di stato: questo messaggio verrà conservato nel log.
La gestione del messaggio opzionale è gestito con il metadato transitionComment che deve essere configurato come metadato @Required. per la validazione di enter.
wfActionLogicVersionize
Questa action logica crea una snapshot per l'oggetto in questione e lo conserva tra versioni precedenti. Negli stati dove viene applicata è fondamentale che non vi siano permessi di modifica (w) e che non vengano aggiunti tali permessi tramite nuove configurazioni di tipo permissions
wfActionLogicWarningHandler
Questa logica serve per la gestione dei messaggi di warning.Serve a resettare l'attributo booleano warningAcknowlegement dopo che l'utente l'ha usato per confermare la transizione di stato.
Per maggiori dettagli cfr. modello dati dell'entità in oggetto