Tabelle utilizzate per le migrazioni della rubrica

é sempre possibile ricreare sul gestore dei db la query di migrazione andando alla pagina /admin/structure/migrate/manage/ugov/migrations

Per le unità organizzative  si utlizzano le tabelle:

v_ie_ac_uo_base_oggi: per la gestione dei cd_tipo nodo

v_ie_ac_so_attiva: per le relazioni padre figlio

v_ie_ac_uo_contatti_all: per i contatti delle uo

Per le persone si utlizzano:

v_ie_ac_pf_contatti_all: per i contatti delle persone, è una vista denormalizzata in cui su ogni riga c'è un tipo di contatto. si mette in join attraverso l'id_ab

v_ie_ru_pers_attivo: Vista che espone tutto il personale con un contratto attivo, utile per ottenere le informazioni su ruolo, profilo, inquadramento, afferenza alle uo, sede di lavoro

v_ie_ru_pf_base: usata per ottenere le informazioni sulla persona come nome e cognome

v_ie_ru_sge: Vista che espone tutta la carriera di una persona all'interno dell'ateneo, mostra quindi contratti attivi e scaduti, viene usata al posto della v_ie_ru_pers_attivo quando si vuole attivare un periodo di grazia

Possibili configurazioni

Organizational Unit

Per quanto riguarda le unità organizzative l'unica configurazione possibile consiste nell'inserire i cd_tipo nodo delle unità che si vorranno mostrare

Person

Per quanto rigurada le persone ci sono 3 possibili configurazioni:

1. Ruolo
2. Ruolo + Profilo
3. Ruolo + Inquadramento

é sempre caldamente consigliato far adottare la seconda configurazione all'ateneo

per configurare la migrazione delle persone si deve andare in admin/ugov/entities/person/migrate

Il tab filtering serve a definire quali persone saranno prese in drupal:

• va definito il Filter type in una delle configurazione sopra elecate
• import only person having these relative Organizational Units: importa solo le persone di una unità organizzativa specifica
• In base al Filter type si avranno 3 possibili scenari
  1. import only person having these combination of Role and Level
  2. import only person having these combination of Role and Profile
  3. import only person having these roles

In questi scenari va distinta la mappatura tra quelli che non avranno il periodo di grazia e quelli invece che hanno il periodo di grazia, è fondamentale che una combinazione non sia ripetuta in entrambe le form

• Person ids to not import: id_ab delle persone che non devono essere importate in rubrica, questo filtro agisce a prescindere dal ruolo che ha la persona
  
• Grace period: definisce  i mesi di periodo di grazia di tutte le combinazioni presenti nella form "<configrazione> with grace period"  NON è possibile definire periodo di grazia diversi da un ruolo all'altro
  

Il tab Importa serve a definire le mappature delle persone:

• Bundles|Roles mapping: va valorizzato in others|<any>
  
• Gender auto recognition enabled: permette di ricoscere il sesso di una persona
  

I tab Publications Import, Prize import, Cv import sono configurazioni dei vecchi moduli ad oggi non vanno MAI attivati

Il tab UniFind Link apparirà solo dopo aver installato i moduli di migrazione di unifind e va configurato settando il check di attivazione, scegliendo Url o alias url in base a cosa viene popolato dal json di unifind e inserita l'etichetta che si aspetta di vedere l'ateneo

Person Role

Questo modulo serve a recuperare le informazioni contrattuali di una persona, ad esempio ruolo e afferenza

Per configurare la migrazione delle persone si deve andare in admin/ugov/relational-entities/person-role/migrate

Il tab filtering serve a definire quali persone saranno prese in drupal:

• va definito il Filter type coerente a quello definito per person
• In base al Filter type si avranno 3 possibili scenari
  1. import only person having these combination of Role and Level
  2. import only person having these combination of Role and Profile
  3. import only person having these roles

In questi scenari va distinta la mappatura tra quelli che non avranno il periodo di grazia e quelli invece che hanno il periodo di grazia, è fondamentale che una combinazione non sia ripetuta in entrambe le form

Il tab Importa serve a definire le mappature dei ruoli sulle persone, va valorizzato solo il form corrispondente al filter type selezionato prima

Importante cliccare su Set main contract after import in modo da definire quale sia il contratto principale della persona

Decoding e place

Questi moduli non necessitano di configurazione basta installarli e migrarli

Decoding dovrebbe essere il primo modulo ad essere migrato perchè contiene le etichette delle altre entità

Place va fatto girare dopo la migrazione di ugov_ou perchè è un dettaglio delle unità organizzative

Assignment

Questo modulo serve a recuperare gli incarichi delle persone, legge dalla tabella  v_ie_ru_organico_cop

Per configurare la migrazione delle persone si deve andare in /admin/ugov/relational-entities/assignment/migrate

Il tab filtering serve a definire quali funizione saranno recuperate e va indicato un elenco di cd_tipo_posizorg, se non si valorizza il form verrano estratti tutti gli incarichi

Purpose

Questo modulo serve a recuperare le funzioni delle persone, legge dalla tabella  v_ie_ru_inc_funzioni

Per configurare la migrazione delle persone si deve andare in /admin/ugov/relational-entities/purpose/migrate

Il tab filtering serve a definire quali funizione saranno recuperate e va indicato un elenco di funzione, se non si valorizza il form verrano estratte tutte le funzioni

Unifind

Questo modulo serve ad ottenere il link della persona verso il prodotto unifind di ateneo

Per configurare correttamente questo modulo è necessario andare in admin/config/services/http-client-manager cliccare su impostazioni e inserire nel form Override quello che è contenuto nel suggerimento "Valore predefinito" infine su salva configurazione

Una volta che è stato configurato il giusto sito unifid occore cliccare su HTTP Services API e nella riga di unifind_services andare su "View Commands"

Una volta aperta la nuova finestra bisogna configurare una nuova richiesta cliccando  su "Configured Request" poi su "+ Add Http Config Request"

La richiesta dovrà avere:

Etichetta: GET_UNIFIND_LINKS

Accept: application/json

Infine salvare la richiesta e testarla

Passi da svolgere per analizzare un bug

Rubrica

Per una corretta analisi del bug è molto importante conoscere tutto il ciclo della rubrica.

In prima analisi è fondamentale analizzare il db sorgente oracle in modo da capire quali sono i dati autoritativi e approfindere se il dato mostrato è un comportamento atteso dal modulo o se effettivamente si tratta di un bug

SE il dato presente sul db Oracle NON è quello che si aspetta l'ateneo allora si può rispondere che il problema è alla fonte e non possiamo farci nulla

SE il dato presente sul db Oracle è quello che si aspetta l'ateneo allora si verica se il db Mysql è allineato correttamente. potrebbe essere un problema di sync kettle.

Analisi del db Mysql:

SE il dato sul db Mysql NON è allineato all'oracle va verificata la sync

SE il dato sul db Mysql è allineato all'oracle vanno prese le seguenti informazioni:

id_ab, ruolo, profilo, inqudramento per i casi:

• Persona non presente in rubrica
• Persona presente ma con ruolo sbagliato

id_ab, id_ab_aff_org, sede per i casi:

• Persona con afferenza sbagliata
• Persona con sede sbagliata

Una volta ottenute le informazioni è importante verificare che le configurazioni siano corrette andando a verificarle puntualmente sulla base delle informazioni appena recuperate.

Backoffice

Nel caso in cui ci sia una persona che lamenta il problema di non riuscire ad entrare nei nostri backoffice il primo passo da fare è andare sul sito unifind di ateneo (Es. https://unior.unifind.cineca.it/) e cercare la persona nel motore di ricerca.

SE la persona non c'è non ha diritto di entrare quindi non è un problema

SE la persona c'è allora bisogna andare a cercare all'interno del back office se la persona c'è o meno al percorso /admin/ugov/entities/person/list cercando la persona

Anche in questo caso ci sono due possibili scenari

1.  la persona è assente
2.  la persona è presente

SE la persona è assente va fatto il giro come se fosse un problema sulla rubrica, quindi va cercato sull'oracle poi mysql e tutti i passaggi sopra elencati

SE la persona è presente va verificata la configurazione del BO al percorso /admin/bod/auth/settings 

Il tab Identification type può assumere 3 valori Email, Serial Number, Id code

Valutare quindi il valore ricevuto nella mail con quello della persona spesso la mail che ci arriva è quella personale e non quella istituzionale

Teoria

unità organizzative struttura dell'università ha dei concetti di gerarchia tipo albero con altre parti dell'università
unità di afferenza bridge tra ou e persone struttura che ha in carico il costo dello stipendio della persona
purpose è la funzione
place sono le sedi

è sempre presente un filtro per ruolo

Scheda professore

è un'entità che contiente le informazioni relative alla persona
è una pagina che possa mostare una serie di info sulle persone: ruolo, afferenza organizzativa, contatti (dati relativi alla loro occupazione in università).
spessso si può trovare la biografia, curriculum.

Le info arrivano da varie fonti

C'è sempre un primo gestionale di riferimento (essenziale) che è UGOV ci fornisce le anagrafiche e info riguardo alle persone contatti, afferenze e ruolo
Ovviamente può cambiare il metodo di esposizione
Fase 1 prendere i dati da ugov e trasformarli in entità drupal
Fase 2 interpretare i problemi di prelievo dei dati sul gestionale
campi ugov usati a sproposito
non è possibile in alcun modo modifica i dati forniti dalla sorgente perchè in questo caso diventeremmo noi gruppo portali la fonte autoritativa
il portale non deve sostituire il gestionale noi siamo una vetrina
Le info provengono dal gestionale di contabiltà dell'ateneo

ruolo
ad ogni codice è associata una descrizione per noi questa info così come ci arriva dal gestionale è illegibile
l'ateneo quindi ci chiede di raggurappare i ruoli in una macro struttura chiamata tipo di ruolo
Viene fatta una mappatura tra ruolo e tipo di ruolo fornita dall'ateneo
Spesso gli atenei chiedono di mostrare un determinato sottoinsieme di ruoli (è sempre una configurazione ad hoc)
sul gestionale ci potrebbe essere una mappatura ma spesso non soddisfa al top l'ateneo

Cosa può andare storto

persona con ruolo diverso rispetto alle aspettative

burrocraticamente parlando è un ricercatore ma nella vita reale ha anche compiti di docenza quindi l'ateneo ci chiede di poterlo esporre come docente
l'estrazione viene fatta sui contratti attivazione

alcune persone possono avere più posizioni attivazione

in questi casi tramite un algoritmo su pesi viene ricavato il contrattto principale sulla persona e quindi il ruolo e l'afferenza organizzativa

in alcuni casi l'ateneo non è comunque contento
bisogna quindi identificare la persona su più attributi es RUOLO + PROFILO o RUOLO + INQUADRAMENTO
ruolo -> identifica le caratterische funzionali della persona
inquadramento -> è una sorta di classificazione ulteriore del ruolo a livello contrattuale Es ruolo PTA potrebbe avere vari inquadramenti

select CD_TIPO_RUOLO, DS_TIPO_RUOLO, DS_INQUADR, DS_PROFILO from v_ie_ru_pers_attivo virpa group by CD_TIPO_RUOLO

separare info anagrafiche dalle info di contratto

creare due entità

person -> informazioni sulla persona
person_role -> informazioni sul contratto
Entità collegate e quindi utente finale non si accorge di nulla
Person_role gestisce i contratti multipli si possono censire tutti i contratti attivi di quella persona e permette di gestire la priorità del contratto direttamente da interfaccia di drupal o applicando un criterio definito con l'ateneo (non più algoritmo basato su pesi)
la person_role sarà comunque mappata con la decodifica ruolo e tipo di ruolo

persona non compare in rubrica
in alcuni casi l'elenco dei ruoli non sia esaustivo e quindi la persona ha un ruolo non presente nella lista
amplio il numero di ruoli da importare
si può applicare il criterio RUOLO + 2° ATTRIBUTO sia per l'esposizione che per l'importazione

persona che compare con ruolo sbagliato perchè ha il contratto scaduto

bisogna spostarci sulla tabella di anagrafica che fornisce tutti le persone a prescindere dal fatto che abbiano o meno un contratto attivo

bisogna pescare solo le persone ancora valide PERIODO DI GRAZIA

bisogna mettere in join

pers_attivo con persone_tutte
pers_contratto scaduto con persone_tutte

filtrando il contratto scaduto da non più di XXX mesi
In futuro sarà probabile chiedere vari pdg per ogni tipologia di ruolo

Cose da definire nell'incontro conoscitivo

le nostre info sono basate su contratti

trovare la configurazione per il modulo
spiegare all'ateneo differenze delle combinazioni
inquadramento non lo citiamo se non necessario

Elenco delle etichette che sono gruppi di ruolo cioè qualcosa di più fine rispetto al raggruppamento in rubrica
Esempio esistono vari ruoli per i docenti professore I fascia e II fascia ma si mostrano entrambi come docenti

spiegare oltre al ruolo si possono andare a prendere anche i profili

unità organizzativee hanno lo stesso problema

chiarire il concetto del periodo di grazia (contratti scaduti da un po' di tempo per alcuni ruoli) e della gestione del multiruolo

spiega i contratti multiroulo cioè dare la priorità dei contratti e mostrare quindi il ruolo principale.

contratto attivo batte contratto scaduto

a parità di contratto attivo si combinano diversi valori per discirminare il ruolo principale