Importregler for DFØ

Feilhåndtering

Hvis en oppgave feiler av ulike grunner (f.eks. ingen kontakt med API, feil i datafelter), vil importoppgaven avbrytes, og vi vil forsøke å gjøre den på nytt senere.

Importoppgaver fra DFØ vil forsøkes på nytt til den har feilet 20 ganger, og vi venter litt lenger før neste forsøk hver gang den feiler. Siste forsøk vil skje litt over en uke etter det første.

Utføring av oppgaver

Oppgavekøen behandles mer eller mindre fortløpende. Dersom mange endringer ligger i kø, kan det imidlertid oppstå en liten forsinkelse før alle oppgavene blir utført. Normalt sett skjer en oppdatering i løpet av et par minutter, men vi har opplevd forsinkelser på et par timer på det meste. Det meste av forsinkelse ligger i kommunikasjonen med DFØ sine API-er.

Kriterier

Ved oppdatering av en ansatt vil det først gjøres et valg om hva som skal gjøres, og for at en person skal inn i Cerebrum fra DFØ, må et par kriterier være oppfylt:

1. Den ansatte må være aktiv - altså ha en start- og sluttdato som indikerer at personen er ansatt nå.
2. Personen må ha en aktiv tilsettelse i DFØ. Det betyr at det finnes en hovedstilling eller tilleggsstilling av en type som Cerebrum kjenner til, og som er påbegynt og ikke avsluttet.
3. Personen må ikke være registrert som død i Cerebrum (eller noen av kildesystemene som sender slik informasjon til Cerebrum - dette er i praksis bare FS).

Merk at vi har litt slakk i sjekk av start- og sluttdato. Det vil si at vi også aksepterer startdatoer som ligger opptil 6 dager frem i tid eller sluttdatoer som har inntruffet for én dag siden.

Matching mot Cerebrum

Ved import vil vi forsøke å finne en tilsvarende personforekomst i Cerebrum. Dette gjøres ved oppslag på DFØ-ID (ansattnummer), fødselsnummer, og passnummer. Dersom det skulle finnes flere personer som oppfyller disse, vil importen feile/stanses, med mindre ett av personobjektene alt har en DFØ-ID.

På bakgrunn av dette vil en av følgende skje:

1. Vi oppretter et nytt personobjekt - ved aktiv ansettelse i DFØ, ingen match i Cerebrum.
2. Oppdaterer et eksisterende personobjekt - ved aktiv ansettelse i DFØ, match i Cerebrum.
3. Fjerner DFØ-informasjon fra eksisterende personobjekt - ved ikke aktiv ansettelse i DFØ, match i Cerebrum.
4. Ignorerer endring - ved ikke aktiv ansettelse i DFØ, ingen match i Cerebrum.

Stillinger og tilknytninger

Aktive tilsettelseser er stillinger som kan oversettes til en tilknytning i Cerebrum.

Dersom den ansatte har en start- eller sluttdato som er utenfor aktuelt tidsrom (seks dager siden, en dag i fremtiden), vil ingen av stillingene regnes som aktive.

Videre må Cerebrum kjenne til hver enkelt stilling. Det skjer ved å:

1. Ignorere stillinger som har stillingsId 99999999.
2. Ignorere stillinger som ikke er aktive ihht. start- og sluttdato
3. Oversette stilling til tilknytning

Tilknytning i Cerebrum styres i hovedsak av stillingskategori:

• 50078118 → ANSATT/tekadm
• 50078119 → ANSATT/tekadm
• 50078120 → ANSATT/vitenskapelig

For hovedstilling (stilling med stillingsId i personobjekt) vil vi eventuelt overstyre resultatet med MG/MUG fra personobjekt, dersom MG/MUG er en av:

• 8 / 50 → ANSATT/bilag
• 9 / 90 → TILKNYTTET/ekst_partner
• 9 / 91 → TILKNYTTET/ekst_partner
• 9 / 93 → TILKNYTTET/emeritus
• 9 / 94 → TILKNYTTET/ekst_partner
• 9 / 95 → TILKNYTTET/gjesteforsker

Personinformasjon

Når vi først har bestemt at en person er aktivt ansatt og beslutter å oppdatere informasjon i Cerebrum fra DFØ, vil følgende oppdatering skje:

Navn

Ved import fra DFØ legger vi inn:

• fornavn → FIRST
• etternavn → LAST

Navn lagres for hvert kildesystem, og når man henter et navn fra Cerebrum, får man navnet fra det systemet som har høyest prioritet. Det er mulig å overstyre dette i Cerebrum, men normalt sett får man navnet fra det høyest prioriterte kildesystemet, som er DFØ.

Fødselsdato og kjønn

Ved import fra DFØ legger vi inn:

• fdato → fødselsdato
• kjonn → kjønn

Fødselsdato og kjønn lagres ikke for hvert kildesystem — personer har én fødselsdato og ett kjønn. Person-objekter i Cerebrum må ha en fødselsdato:

1. Dersom DFØ mangler fødselsdato, vil vi ikke kunne opprette et nytt Person-objekt i Cerebrum.
2. Dersom DFØ mangler fødselsdato, men vi alt har et tilsvarende Person-objekt i Cerebrum, vil vi bare beholde den eksisterende fødselsdatoen, og alt fortsetter som normalt.
3. Hvis DFØ har en fødselsdato, vil denne overstyre det som finnes i Cerebrum.

fdato må enten være tom eller innehode en gyldig dato på format ISO-8601. Andre verdier vil feile.

Personer i Cerebrum må ha en verdi for kjønn. DFØ vil alltid overstyre/sette kjønn ved oppdatering av person.

Mapping av kjønn:

• M → mann
• F → kvinne
• X → ukjent
• tom verdi → ukjent

Andre verdier i kjonn vil feile.

TODO

Denne delen av integrasjonen burde endres. Dersom kjønn eller fødselsdato alt er satt i Cerebrum, burde verdiene i DFØ ignoreres. Dette i hovedsak fordi vi ikke skiller på ulike verdier mellom ulike kildesystemer.

Dersom en og samme person finnes i f.eks. både i DFØ og FS, og disse to systemene har ulik fødselsdato, vil fødselsdato i Cerebrum bytte frem og tilbake mellom disse to ulike verdiene ved import.

I andre integrasjoner, som f.eks. Greg, oppdateres bare fødselsdato og kjønn dersom personen blir opprettet fra data i dette kildesystemet.

Kontaktinfo

Ved import fra DFØ legger vi inn:

• telefonnummer → PHONE
• mobilnummer → MOBILE
• mobilPrivat → PRIVATEMOBILE

Telefonnummer blir kun overført hvis de er på et gyldig format - et eventuelt ugyldig telefonnummer blir ignorert.

Eksempler på gyldige format:

• +4722855050 - Internasjonalt prefiks (+) og landkode (47), ihht. ITU-T E.123/E.164
• 004722855050 - Oppringingsprefiks (00) og landkode (47), som man ville ringt fra Norge
• 22855050 (nummer uten prefiks/landkode antas å være norske)
• +47 228-55-050, +47 22 85 50 50 - mellomrom og --separatorer ignoreres.

Valideringen er myk — vi sjekker i praksis bare at nummeret kan parses (består av nummer, og et gyldig prefiks).

TODO

Vi sjekker aldri is_possible eller is_valid? Burde nok som minimum gjøre validering med phonenumbers.is_possible().

Dette burde nok også standardiseres på tvers av importer. Cerebrum.utils.phone kunne nok også forenkles litt - vi trenger vel egentlig bare en parse_number(value) som enten returnerer et normalisert nummer eller gir ValueError.

Identifikatorer

Ved import fra DFØ legger vi inn:

• id → DFO_PID
• fnr → NO_BIRTHNO
• annenId[].Type = 02 → PASSNR

Merk:

• fnr: Vi ignorerer fødselsnummer med personnummer 00000, 00100, eller 00200. Vi validerer ikke førselsnummeret (sjekksum).
• Passnummeret i Cerebrum bygges opp av de to første tegnene av idLand + idNr. F.eks.: {"Type": "02", "idLand": "NO", "idNr": "123"} → NO123.

Hvis det ikke finnes en person med det aktuelle ansattnummeret i Cerebrum, og DFØ mangler både passnummer og fødselsnummer, så vil vi heller ikke opprette noen ny person.

Dersom en person alt finnes i Cerebrum med det aktuelle ansattnummeret, så går importen som normalt selv om det skulle mangle både fødselsnummer og passnummer.

Tittel

Stillingstittel oppdateres ut fra informasjon i:

• tittel → PERSONALTITLE
• stillingstittel på hovedstillingen fra person → WORKTITLE

Dersom Cerebrum har en PERSONALTITLE, vil denne overstyre en eventuell WORKTITLE i de fleste systemer som får tittel fra Cerebrum.

I begge tilfeller så blir verdien fra DFØ kun brukt som en oppslagsverdi i vår egen konfigurasjon/oppslagsverk med personlige titler og stillingstitler. Dette er blitt gjort for å komme rundt grense for makslengde på tittelfelter i DFØ, samt for å gi tittel på både norsk og engelsk.

Oppslagsverket vi bruker er https://www.uio.no/for-ansatte/arbeidsstotte/profil/sprak/stillingsbetegnelser/, som også eksponeres via et API for stillingsbetegnelser. Ved eventuelle endringer må det interne oppslagsverket i Cerebrum oppdateres fra en av disse kildene manuelt.

Tilknytning

Tilknytninger oppdatertes. Merk at dette steget kan feile dersom personen er tilknyttet en organisasjonsenhet som Cerebrum ikke kjenner til. Dette kan f.eks. skje dersom personen er ansatt ved en organisasjonsenhet i DFØ som ikke har blitt lagt inn i Orgreg.

Opprydding

Dersom der blir besluttet å fjerne informasjon fra DFØ i Cerebrum, vil man ta bort:

• Navn
• Kontaktinfo
• Tittel
• Tilknytninger

Vi beholder identifikatorer (DFØ-ID, fødselsnummer, passnummer) slik at personobjektet kan bli funnet igjen dersom samme person skulle bli aktiv igjen i DFØ, eller et annet kildesystem som FS eller Greg.