Prosessar og utplukksreglar for studentautomatikken

Ei beskriving av automatikken som vedlikeholder IT-tilgang for studentar i Cerebrum, i hovudsak brukarkonto og grupper, basert på studiedata frå Felles Studentsystem (FS). Dette dokumentet dekker kva brukaradministrasjonssystemet Cerebrum gjer, og ikkje kva som først skjer i FS.

Dokumentet er i utgangspunktet meint som dokumentasjon for Avdeling for fagstøtte (AF), som er dei som bestemmer korleis studentautomatikken skal fungere overordna.

Innhold

1   Introduksjon til Cerebrum

Studentautomatikken er eit sett med rutiner som gir studentar IT-tilgang til IT-tenester ved Universitetet i Oslo, som i hovudsak handler om brukarkonto og gruppemedlemskap. Automatikken tek for seg oppretting, vedlikehald og avvikling av brukarkontoar, og hentar studiedata frå Felles Studentsystem (FS).

1.1   Begrep

Nokre begrep som brukast i Cerebrum:

  • Aktiv student: Dette begrepet har to definisjonar. Internt i Cerebrum er aktive studentar alle som følger vanleg studieløp, med opptak til eit studieprogram. På nettsidene meinast aktiv student som alle studentar med IT-tilgang, som då inkluderer emnestudentar, privatistar og drgrad-studentar. Sjå sida Aktiv student.

  • Enkeltemnestudent: Studentar med opptak til det gamle studieprogrammet ENKELTEMNE. Er fasa ut, til fordel for det nyare konseptet emnestudent.

    Per i dag, 2018, har du også studieprogramma REALFAG og REALMAS, som studentar vert gitt studierett til utan sluttdato. Dessa fungerer då på samme måte som enkeltemnestudentar, men kallast kanskje ikkje det samme.

  • Emnestudent: Student utan studierett, men med vurderingsmelding til eit emne, og skal då ha IT-tilgang.

  • Ny student: Student som har blitt tildelt studierett i starten av inneverande semester. Sjå ny student for detaljar.

  • Opptak: Opptak til eit studieprogram. Er det samme som studierett.

  • Studierett: Opptak til eit studieprogram.

For fleire begrep brukt i FS, sjå FS: Brukerdok: 01 Definisjoner.

1.2   Kvifor

UiO har ein god del studentar. Det ville vore veldig ressurskrevande å bygge brukarkontoar til alle desse manuelt. Dette er utgangspunktet for å ha studentautomatikken. Etterkvart kom det fleire ønsker om meir automatisering, sm har gjort at studentautomatikken har vokse seg stor og komplisert.

Ein viktig årsak til at studentautomatikken er komplisert, er at fakulteta registrerer studentar og studiedata på ulikt vis, og har forskjellige behov for automatikk. Å tilfredstille alle behova har gått på bekostning av å ha ein automatikk som er forståeleg og oversiktleg.

Dagens studentautomatikk vart påbegynt i 2003.

1.3   Affiliations

I Cerebrum brukast ordet affiliation for kva tilknyttingar ein person eller brukarkonto har til UiO. Affiliations er viktig for å avgjere om ein person reknast som til dømes ansatt eller student. Ein affiliation kan vere av ein viss type med ein tilhøyrande status, og er tilknytta ein spesifikk stedkode. Affiliation-typen STUDENT er reservert for studentautomatikken og kan ha status:

  • drgrad: Registrert som aktiv doktorgradsstudent i FS
  • aktiv: Registrert som vanleg aktiv student i FS
  • evu: Registrert som etter- og vidareutdanningsstudent i FS
  • privatist: Registrert som privatist i FS
  • opptak: Registrert med gyldig studierett i FS.
  • emnestud: Registrert med undervisingsmelding, utan opptak til eit studieprogram (studierett) i FS. Merk: Dette er ikkje det samme som begrepet enkeltemnestudent, som reknast som dei med opptak til studieprogrammet "ENKELTEMNE".
  • ny: Student har nyleg fått opptak, og får full tilgang i ein periode, fram til studenten får semesterregistrert seg. Denne kategorien er oppretta for å kunne skille dei frå opptaksstudentar med evig studierett som ikkje skal ha full tilgang til evig tid.

I tillegg er også følgjande statusar av typen TILKNYTTET reservert for studentautomatikken:

  • fagperson Registrert som fagperson i FS, basert på roller i FS. Dette er under utfasing.

Obs: Ei komplett liste over tilknyttingar finn du med å køyre kommandoen misc affiliations i bofh.

Desse tilknyttingane styrast av utplukka frå FS, og kan ikkje settast manuelt.

Legg merke til at det ikkje er mogleg å få meir enn ein affiliation på samme stedkoden med samme typen og status på ein person. Når det gjeld affiliations på brukarkontoar kan ein ikkje registrere meir enn ein affiliation per stedkode per type affiliation. Dette betyr at ein brukarkonto ikkje kan ha både STUDENT/opptak og STUDENT/aktiv på samme stedkoden. I slike tilfeller vert statusane samanlikna og vekta, så i dette tilfellet ville STUDENT/aktiv blitt brukarkontoen sin affiliation.

Merk at innlogging gjennom Feide krever at personen har ein gyldig affiliation frå eit kjeldesystem (FS eller SAPUiO). Studentar som ikkje er registrert som aktive lenger får difor ikkje benytta IT-system som autentiserer seg via Feide. Alle studentaffiliations lista her er gyldige for Feide, men fagperson er ikkje ein gyldig affiliation.

1.4   Studentbrukar

Cerebrum skiljer på person og brukarkonto. Ein person kan ha fleire brukarkontoar, til dømes ein eigen administratorbrukar og ein vanleg student/ansatt-brukarkonto. Vi bruker difor begrepet studentbrukar for brukarkontoar som studentautomatikken vedlikeheld.

Ein studentbrukar identifiserast på to ulike måtar, avhengig av situasjonen:

  • Dersom brukarkontoen har ein STUDENT-affiliation, uavhengig av kva disk heimeområdet ligg på.
  • Dersom personen har ein STUDENT-affiliation, i tillegg til at brukarkontoen ligg på ein disk som er definert som studentdisk i studentkonfigureringa. Dette er då uavhengig av om brukarkontoen har STUDENT-affiliation.

1.5   Primærbrukar

Ein person kan ha fleire brukarkontoar, men i enkelte system er det berre mulig å vere registrert med ein brukarkonto. I Cerebrum vil ein av personen sine brukarkonto vere satt som primærnbrukaren.

Det er berre primærbrukaren som får logge på gjennom Feide.

Merk at primærbrukaren ikkje nødvendigvis er den samme som studentbrukaren. Dersom ein student har ein eigen ansattbrukar vert denne ofte primærbrukaren til personen.

1.6   Karantener

Karantener settast på brukarkontoar i Cerebrum for å begrense IT-tilgangen, primært for å sperre brukerkontoen. Du får lista ut alle karantener med kommandoen quarantine list i bofh, men nokre er meir relevante for studentautomatikken:

  • auto_no_aff: Alle som ikkje lenger har noko affiliation på person, fordi dei til dømes har slutta å studere eller jobbe på UiO, vil få alle sine brukarkontoar sperra etter ei stund. Denne styrast av ei felles avviklingsrutine - sjå sperring av studentbrukarar for meir detaljar.
  • generell: Settast manuelt av IT-personell ved behov. Karantena fjernast automatisk dersom studentautomatikken vil gjenopprette ein tidlegare avvikla studentbrukar - sjå oppretting av studentbrukarar.

Karantener kan settast for ein gitt periode, eller utan noko tidsbegrensing, og kan også midlertidig opphevast. Eit typisk tilfelle er å midlertidig oppheve ei autopassord-karantene for at brukarkontoen kan få bytta passordet sitt.

Andre relevante karantener:

  • autopassord: Brukarkontoar som ikkje har bytta passord på lenge vil bli sperra. Eit passordskifte opphever karantena.
  • auto_inaktiv: Vart tidlegare brukt for å sperre studentar som slutta å studere, men har blitt bytta ut med ei felles avviklingsrutine. Sjå karantena auto_no_aff.
  • auto_kunepost: Vart tidlegare satt på studentbrukarar til privatistar, og gjer at studenten ikkje får tilgang til andre IT-system enn e-postsystemet, StudentWeb og Brukerinfo. Denne settast ikkje lenger automatisk, men det kan finnast gamle brukarkontoar som framleis har den.

1.7   Kjeldekoden

Studentautomatikken er ein del av brukaradministrasjonssystemet Cerebrum, som er fri programvare. Kjeldekoden ligg opent tilgjengeleg på nett, og spesielt kode relatert til dette dokumentet:

Om du ikkje har tilgang til UiO sin lokale GitHub Enterprise kan du også finne Cerebrum på GitHub.

2   Rutinene i studentautomatikken

2.1   Lagring av persondata

Merk at SAP er autoritativ for persondata, og organisasjonsstruktur, og vil difor overstyre personopplysingar frå FS.

Cerebrum oppdaterer kvar person med oppdaterte persondata:

  • Fødselsnummeret til personen må vere gyldig, elles vert personen ignorert. Det er lagt inn unntak for SO-nummer, og gamle FS-hack.

  • Det sjekkast om Cerebrum inneheld eit personobjekt med samme fødselsnummer. Legg merke til at fødselsnummer brukast som unik identifikator.

    Dersom ei endring av eit fødselsnummer ikkje er registrert korrekt i FS vil det no bli oppretta eit nytt personobjekt for studenten og dermed også ein ny studentbrukar. Dette vil kunne forvirre både personen og IT-support, og persondata må slåast saman manuelt.

  • Personen får affiliations:

    • Om personen er registrert med opptaksstatus vil han/ho få ein STUDENT-affiliation. Sjå informasjon om studentar med opptak for kriteria for å ha opptaksstatus. Deretter vil status bli satt etter dei vidare kriteria. Rutina stoppar ved første treff, så ein student kan ikkje få fleire affiliations til same opptaket:

      1. Om opptaket er registrert på ein stedkode der personen også er registrert som aktiv får personen STUDENT/aktiv registrert på stedkoden til studieprogrammet personen har opptak til. Sjå informasjon om aktive studentar for kriteriet for aktive studentar.
      2. Om studierettstatkode er satt til EVU får personen affiliation STUDENT/evu på stedkoden til studieprogrammet.
      3. Om studienivakode er høgare eller lik 900 får personen affiliation STUDENT/drgrad satt til stedkoden til studieprogrammet.
      4. Om studieretten nyleg vart tildelt (dato_studierett_tildelt) og dagens dato er tidleg i semesteret, får personen STUDENT/ny registrert på stedkoden til studieprogrammet opptaket er registrert på. Dette gjerast for å skille nye studentar frå studentar med "evig studierett". Sjå meir detaljar under Ny student.
      5. Om ingenting anna treff, får personen satt "STUDENT/opptak" til studieprogrammet sin stedkode.

      Merk: Enkelte enheter registrerer studierettar utan sluttdato, som fører til at ein del personar har opptaksstatus til evig tid. Dette gjeld blant anna studieprogramma "REALFAG" og "REALMAS". Det tidlegare studieprogrammet "ENKELTEMNE" vart avvikla.

    • Om personen er registrert med emnestud (sjå informasjon om emnestudentar for utplukkskriterier), får personen affiliation STUDENT/emnestud til emnet sin stedkode.

    • Om personen er registrert som "ekte privatist" (sjå informasjon om privatistar for utplukkskriteria), får personen affiliation STUDENT/privatist på stedkoden til studieprogrammet.

      Om personen er "uekte privatist", altså vurderingsmeldt i eit emne i eit studieprogram han ikkje har opptak til, får personen affiliation STUDENT/privatist på stedkoden der emnet er registrert.

    • Studentar som er registrert som EVU får affiliation STUDENT/evu tilknytta den ansvarlege enheten for EVU-kurset. Sjå informasjon om EVU-studentar for utplukkskriteria for desse.

  • Tidlegare affiliations skulle blitt fjerna når studenten ikkje lenger har noko aktiv registrering i FS. Studenten mister likevel ikkje si person-tilknytting før etter ein viss periode - internt kalla ein grace-periode. Dette er gjort for å la studentar få behalde sine IT-tilgangar ein periode etter at dei er ferdige å studere.

    Per august 2018 var denne grace-perioden på 180 dagar. Grace-perioden gjeld ikkje EVU-studentar og fagpersonar. Desse mister tilknyttinga si samme dag som FS seier at dei ikkje lenger er aktive.

  • Adresser til ein person vert registrert i prioritert rekkefølge.

    • For aktive studentar, doktorgradsstudentar, emnestudentar og privatistar har ein:
      1. Semesteradresse
      2. Heimstadsadresse
    • For EVU har ein:
      1. Jobbadresse
      2. Heimadresse
    • For studentar med berre opptak har ein:
      1. Heimstadsadresse

  • Samtykke for publisering på nett: Om personen er registret med samtykke vert personen lagt til i gruppa FS-aktivt-samtykke. Sjå informasjon om offentleggjering av persondata for kriteria for dette. Samtykke for publisering brukast for å markere om informasjon om personen i UiO sin elektroniske katalog skal vere synleg for alle.

2.2   Gjennomgang av studentbrukarar

Etter at person-objekta er oppdaterte går vi gjennom studentbrukarane til personar som no er studentar. Studentbrukarane vert vedlikeholdt etter kriteria som er definert i studentkonfigureringa.

Merk: Personar som har brukarkonto, men ingen brukarkonto med STUDENT-affiliation, vert personen ignorert frå vidare behandling. Vi kan ikkje vite om brukarkontoen kan brukast som studentbrukar eller ikkje. Personen må då kontakte si lokale IT-avdeling eller Houston for å enten få satt STUDENT-affiliation på brukarkontoen sin eller få oppretta ein eigen studentbrukar.

For oversikten sin del har vi her delt opp gjennomgangen i tre delar; oppretting, vedlikehold og sperring.

2.2.1   Oppretting av studentbrukarar

Dersom ein student som er med i importen frå FS ikkje har ein brukarkonto i det heile tatt, men skulle hatt dette i følge studentkonfigureringa, vert ein ny brukarkonto oppretta for personen.

Brukarnamn er reservert til ein person ut livet. I praksis vil det sei at om ein person tidlegare har vore ved UiO og kjem tilbake, vil det gamle brukarnavnet bli gjenbrukt. Dette kan endre seg i framtida.

Vanlegvis vert studentar først kategorisert som "ny student", og får då oppretta ein brukarkonto med full IT-tilgang med ein gang dei har fått studierett (opptak til eit studieprogram). Sjå ny student for meir detaljar. Alternativt får studenten først opptaksstatus, som fører til at studenten får oppretta ein reservert brukarkonto. Brukarkontoen har då berre tilgang til Feide-innlogging, primært for å kunne logge på StudentWeb for å semesterregistrere seg.

Emnestudentar får ikkje brukarkonto før dei har semesterregistrert seg.

Når ein student skal få ein brukarkonto:

  1. Om vi finn ein tidlegare brukarkonto til personen gjenoppretter vi denne ved å fjerne expire_date.
  2. Eventuelle karanter av typen generell og autopassord vert fjerna.
  3. Studenten får tilsendt ein SMS med ei velkomstmelding, og lenke til https://passord.uio.no/. Der kan studenten gå vidare for å sette seg eit passord.

Lokal IT og Student-IT kan få generert eit nytt passord til studentar, til utlevering ved fysisk henvendelse, eller ved å sende passordbrev i posten. Passordutsending bruker semesteradressa for aktive studentar, eventuelt vil adresser frå SAPUiO få prioritet. Merk at vi ikkje sender passordbrev til utlandet.

Dersom studenten oppfyller krava til å reknast som aktiv student, ny student, privatist, drgrad eller EVU vil brukarkontoen få heimeområde, e-postkonto og fleire IT-tilgangar. Studentkonfigureringa kan gje fleire tilgangar, til dømes gruppeinnmeldingar.

2.2.2   Vedlikehald av studentbrukarar

Vi går deretter gjennom og vedlikeheld studentbrukaren til kvar person vi har henta frå FS.

  • Heimeområde vert oppretta om dette ikkje eksisterer for brukarkontoen, og lagt på ein studentdisk som er definert etter krava i studkonfig. Dersom brukarkontoen allereie har eit heimeområde, vert ikkje heimeområdet flytta sjølv om studkonfig seier noko anna. Dette er bl.a. for å unngå at ansatte som også er studentar vert flytta til studentdisk.

    Studentar med berre opptaksstatus får ikkje oppretta eit heimeområde.

    Enkelte diskar er definert med kvoter. Heimeområder som ligg på ein disk med kvote vil no få dette påsatt, medan heimeområder som ikkje ligg på ein disk med kvote vil evt. få dette fjerna.

    Obs: Merk at tomme diskar vert ignorerte av studentautomatikken, som var eit designvalg når automatikken vart laga. For å ta i bruk nye studentdiskar må ein manuelt tildele heimeområdet til minst ein brukarkonto, elles vil disken forbli ignorert av automatikken.

  • Eventuelle karantener av typen auto_inaktiv og auto_kunepost vert fjerna dersom studkonfig seier at brukarkontoen ikkje skal ha dette. Dette gjer at brukarkontoar som tilhøyrer personar som er registrert som aktive studentar i FS får automatisk oppheva desse karantenene.

  • Brukarkontoen får deretter spreads etter kva studkonfig seier studenten kan ha. Spreads som allereie er satt fjernast ikkje. Spreads er definisjonen på kva IT-system som skal få vite om brukarkontoen og dermed kor brukarkontoen kan logge seg inn. Døme på IT-system er e-post, AD (Windows) og NIS (GNU/Linux).

  • Affiliations vert lagt til på studentbrukaren etter kva student-affiliations personen har. Om brukarkontoen har student-affiliations som personen ikkje har vert desse fjerna.

    Vi fjerner aldri siste STUDENT-affiliationen til brukarkontoar. Dette er for å kunne seinare vite kva brukarkonto som var personen sin studentbrukar dersom studenten seinare skulle studere ved UiO att. Dette har ingen konsekvensar for IT-tilgangen for brukarkontoen.

    Merk at det ikkje er noko automatikk for brukarkontoar der personen berre har TILKNYTTET/fagperson. Denne affiliationen må leggast til og fjernast manuelt.

    Vi sjekkar berre etter OU (stedkoden) til ein affiliation på ein brukarkonto. Vi kan berre ha ein STUDENT-affiliation per OU på ein brukarkonto (samme person kan altså ikkje til dømes ha både STUDENT/aktiv og STUDENT/drgrad ved samme stedkode).

  • Gruppe-medlemskap vert lagt til for brukarkontoar ut frå det som er definert i studkonfig. Merk at vi ikkje fjerner gruppemedlemskap midt i semesteret, dette skjer berre ein gang i starten av kvart semester. Sjå sperring av studentbrukarar for meir detaljar om dette.

2.2.3   Sperring av studentbrukarar

Inaktive studentar får sine brukarkontoar automatisk sperra og avvikla. Denne automatikken går nattleg, og er felles for både studentar, tilsette, manuelle, gjestar og andre tilknytta personar. Sjå Avvikling av brukarkontoar for meir informasjon om automatisk sperring på UiO.

Med inaktive student meinast her alle personar vi ikkje lenger får informasjon om i utplukket frå FS (sjå personinformasjon for utplukkskriteria). Dersom studenten har andre, gyldige tilknyttingar til UiO, til dømes er tilsett, vil ikkje personen bli sperra.

Ein gang i semesteret går Cerebrum drift gjennom gruppene som er definert i studkonfig og melder ut dei studentbrukarane som ikkje lenger har rett på å vere medlem i gruppa. Informasjon om dette sendast ut til lokal IT.

Ein gang i semesteret går Cerebrum drift gjennom alle studentar med berre opptaksstatus, og sperrer dei som ikkje er semesterregistrerte. Dette gjerast fordi mange personar er registrert med "evig studierett". Cerebrum kan ikkje avvikle desse brukarkontoane, men gir dei berre karantena auto_inaktiv.

2.2.4   Ny student

I 2016 innførde AF ei ny kategori av studentar: "ny student". I hovudsak vart dette gjort for å kunne gje nye studentar full IT-tilgang før dei har semesterregistrert seg, utan at vi samtidig gir personar med "evig studierett" også full IT-tilgang.

Utplukk og automatikk for desse er litt komplisert, sidan det prøver å sno seg rundt ein allereie komplisert studentautomatikk, og dekker ikkje alle nye studentar. Til dømes vil ikkje studentar som kjem tilbake etter ein pause dukke opp i denne kategorien, og må få semesterregistrert seg først for å få IT-tilgangar.

Alle med opptak til studieprogram der dato for tildelt studierett (dato_studierett_tildelt) er satt i perioden:

    1. desember - 7. februar
    1. juni - 7. september

vil i samme periode få tilknyttinga STUDENT/ny, i staden for STUDENT/opptak. Dette vil føre til at studentautomatikken byggjer brukarkonto med full IT-tilgang, og tildeler heimeområde. Vanlege opptaksstudentar får til samanlikning ikkje tilgang til AD eller Exchange, eller heimeområde.

Alle studentbrukarar til nye studentar vert markert med eit trait tmp_student.

Når perioden er passert, vil alle nye studentar som ikkje har semesterregistrert seg endå bli sperra, med mindre dei har andre affiliations enn STUDENT/opptak. Dei får karantena auto_tmp_student, og traitet vert fjerna. Karantena vert automatisk fjerna når personen vert aktiv, til dømes ved ei sein semesterregistrering.

Merk: Nokre race conditions gjer at enkelte kan bli feilaktig sperra av denne automatikken. Ei løysing kan då vere å fjerne både trait og karantene frå brukarkontoen.

2.3   Eksport til FS

Etter at Cerebrum er oppdatert sendast noko data tilbake til FS:

  • Primær e-postadresse. Dette er personen sin primærbrukar si primære e-postadresse. Alle som har fått satt/endra e-postadressa si i forhold til forrige spørring vert oppdatert.

    Merk at den primære e-postadressa ikkje treng å vere studenbrukaren si e-postadresse.

  • Brukarnavnet til studenten vert oppdatert om denne har blitt satt/endra seg. Merk at dette er primærbrukaren til personen og ikkje nødvendigvis studentbrukaren.

Merk at vi berre oppdaterer informasjon som har endra seg.

2.4   Utskriftskvote

Cerebrum administrerte tidlegare kvoter for utskrifter for studentar. Dette vart i 2015 flytta ut til ei eiga utskriftsløysing, SafeCom. Cerebrum har difor ikkje lenger oversikt over utskrifter og betalingar.

Grunna tekniske begrensingar treng SafeCom å vite kven som har utskriftskvote registrert på brukaren i LDAP. Cerebrum har difor framleis kontroll på kven som skal ha utskriftskvote og ikkje, og publiserer dette i LDAP.

3   Studentkonfigureringa

For å forenkle prosessen med å gjere endringar i oppsettet for studentautomatikken har vi ei konfigurasjonsfil der dei fleste innstillingane for studentbrukarane ligg. Konfigurasjonen fungerer slik at den definerer utplukk av studentbrukarar ved å sjå etter ulike kriterier (sjå etter <select>-taggar i fila), og tildeler studentbrukarane som oppfylde kriteria gitte egenskaper, som til dømes om brukarkontoen skal få heimeområde, spread, gruppemedlemskap og kva disk som anbefalast.

Dei viktigaste utplukkskriteria i studentkonfigureringa er:

Alle studentar som kjem inn i desse utplukka vert påvirka av dei utplukkskriteria som ligg i fila.

Konfigurasjonsfila definerer bl.a.:

  • Disken heimeområdet til studentbrukaren kan ligge på. Kan oppgje ein pool av diskar, som gjer at ein tilfeldig disk velgast blant desse, så lenge disken ikkje er tom.
  • Grupper: kva grupper studentautomatikken kan flytte studentbrukarar inn og ut av.
  • Spreads: kva spreads studentbrukarar kan få.

Siste oppdaterte studconfig.xml finn du på https://www-int.uio.no/tjenester/it/brukernavn-passord/brukeradministrasjon/hjelp/studentautomatikk/konfigurering/studconfig.xml

3.1   Fellesinnstillingar

I studentkonfigureringa får forskjellige studieprogram og emner ulike innstillingar, men det er ein del basisinnstillingar som er felles for alle studentar.

Alle med studierett til eit studieprogram, eller registrert som privatist ved eit studieprogram får:

  • Brukardata sendast til UA (så kortsentralen kan gje studenten tilgang vha. studentkortet)

Alle registrert som privatist til eit emne får:

  • Brukardata sendast til e-postsystemet
  • Brukardata sendast til UA (så kortsentralen kan gje studenten tilgang vha. studentkortet)

Alle registrert som aktiv ved eit studieprogram, registrert som EVU eller registrert med doktorgrad til eit studieprogram får:

  • Brukardata sendast til NIS
  • Brukardata sendast til AD
  • Brukardata sendast til e-postsystemet
  • Brukardata sendast til UA (så kortsentralen kan gje studenten tilgang vha. studentkortet)
  • Heimeområde skal byggast

4   Utplukkskriterier

Cerebrum hentar ut informasjon frå UiO sitt Felles Studentsystem om alle studentar, samt informasjon om betalingar, studieprogram, enhetar, emner og aktivitetar. Vi importerer også informasjon om alle fagpersonar, men desse vert ikkje påvirka av studentautomatikken i samme grad som studentar.

Vidare kjem informasjon om alle utplukka vi køyrer mot FS, med kommentarar til kva dette innebærer for automatikken. All SQL-kode ligg i koden, sjå avsnittet Kjeldekoden.

4.1   Valg av termin

I mange av utplukka er det lagt inn avgrensingar i termin, eller semester. Cerebrum bruker terminane HØST og VÅR, i kombinasjon med årstal, og velger etter:

  • I perioden 1. januar til 30. juni er termin definert til VÅR. I nokre tilfeller inkluderer vi også forrige termin i utplukket i perioden 1. januar til 15. februar.
  • I perioden 1. juli til 31. desember er termin definert til VÅR. I nokre tilfeller inkluderer vi også forrige termin i utplukket i perioden 1. juli til 15. september.

4.2   Personinformasjon

4.2.1   Informasjon om studentar med opptak

I første omgang hentast det ut all personleg informasjon vi treng om alle studentar som har opptaksstatus, og som difor også skal ha tilgang til IT-tenester ved UiO. Utplukkskriteriet er:

  • Studenten må ha gyldig opptak i eit studieprogram.
  • Startdato for opptaket må vere maksimalt 14 dagar fram i tid, og etter 1. januar 2003, med mindre ein er doktorgradsstudent.
  • Studenten har ikkje status som privatist (desse kjem i ei eiga spørring lenger ned).
  • Alle med studienivåkode 900 og 980 inkluderast, uavhengig av startdato. Dette er drgradsstudentar.
  • I tillegg hentast også dei med gyldig opptak som har hatt ein forekomst i registerkort i løpet av fjoråret, for å få med personar som fekk opptak før 2003 men som likevel har vore aktive i det siste.

4.2.2   Informasjon om aktive studentar

For å få tilgang til dei øvrige IT-tenestene ved UiO må ein vere aktiv student. Kravet for å vere aktiv student:

  • Studenten må ha gyldig registerkort, dvs. at status_reg_ok = J, status_bet_ok = J og status_ugyldig = N eller er ikkje satt.

    I tillegg må studenten:

    1. Enten
      • Ha gyldig studierett på studieprogram utan krav om utdanningsplan, og
      • Vere meldt til vurdering i eit emne som kan inngå i dette studieprogrammet.
    2. Eller
      • Ha gyldig studierett på studieprogram med krav om utdanningsplan, og
      • Ha bekrefta utdanningsplan for inneværande semester.
    3. Eller
      • Ha gyldig opptak til enkeltemne, og
      • Ha gyldig vurderingsmelding i eit emne som kan inngå i eit vilkårlig studieprogram.
    4. Eller
      • Ha avlagt eksamen i eit emne som kan inngå i et studieprogram ein har, eller har hatt, opptak til i inneværande semester.

For å dekke over alle aktive studentar køyrer vi fire spørringar med mindre variasjonar. Dette kjem av at studentar vert registrert litt forskjellig hos ulike enhetar. Felles rutiner for å registrere studentar på ville gjort utplukka meir forståelege.

4.2.3   Informasjon om emnestudentar

Emnestudentar er studentar som ikkje har studierett, altså ikkje noko opptak til studieprogram. Dei har likevel fått undervisingsmelding til eit eller fleire emner.

Emnestudent er noko anna enn enkeltemnestudent, som var benemninga på dei som hadde opptak til eit eige studieprogram "ENKELTEMNE". Dette er fasa ut.

Utplukkskriteria er:

  • Gyldig semesterregistrert i inneverande semester (status_reg_ok og status_bet_ok må begge vere J).
  • Undervisingsmelding med status_opptatt.

4.2.4   Informasjon om forkurs

Cerebrum importerer alle studentar som har vurdkombmelding til emnet med emnekoden "FORGLU". Dette gjerast utan andre sjekkar.

4.2.5   Informasjon om doktorgradsstudentar

Hentar info om aktive doktorgradsstudentar. Aktive er definert til å vere dei som har ein studierett til eit program som har nivåkode lik 900 eller 980, og der datoen studieretten er gyldig til ikkje er passert. Merk at nivåkodar mellom 900 og 980 ikkje vert teke med.

4.2.6   Informasjon om privatistar

Som privatistar reknar vi med dei som har gyldig studierett med startdato tidlegast 14 dagar fram i tid, men med status satt til privatist i FS.

For å dekke over at privatistar er registrert forskjellig henter vi ut både dei med studierett og dei med registerkort. Dette er analogt med uthentinga av opptak. I tillegg må vi også hente ut dei med vurderingsmelding til eit emne i eit studieprogram dei ikkje har opptak til - kallast gjerne uekte privatistar. Desse får privatist-status med tilknytting til der studieprogrammet høyrer heime. Dette utplukket treff ikkje heilt nøyaktig, så fleire vert registrert utan at dei er privatistar.

4.2.7   Informasjon om fagpersonar

Vi hentar ut fagpersonane for inneværande og forrige semester.

Dette er under utfasing. Cerebrum vil ikkje importere fagpersonar etter at Fronter er fasa ut og Canvas har teke over.

4.2.8   Informasjon om personroller knytta til utvalde studieelement

Vi hentar ut alle roller til alle personar frå fs.personrolle.

Sidan personrolletabellen brukar ulike attributtar for å registrere ulike tilknyttingar for roller (til dømes undervisingsenhet, undervisingsaktivitet og studieprogram), men det er ikkje noko som seier kva type rolle det er snakk om. Vi finn difor ut kva som er gyldige roller og kva tilknytting dei er ved å sjå på kva attributtar som er definerte for rolla:

  • Sted: institusjonsnr, faknr, instituttnr, gruppenr
  • Emne: institusjonsnr, emnekode, versjonskode
  • Undervisingsenhet: institusjonsnr, emnekode, versjonskode, terminkode, arstall, terminnr
  • Undervisingsaktivitet: institusjonsnr, emnekode, versjonskode, aktivitetkode, terminkode, arstall, terminnr
  • Timeplan: institusjonsnr, emnekode, versjonskode, aktivitetkode, terminkode, arstall, terminnr, undplanlopenr
  • Studieprogram: studieprogramkode
  • Kull: studieprogramkode, terminkode, arstall
  • Kullklasse: studieprogramkode, terminkode, arstall, klassekode
  • EVU: etterutdkurskode, kurstidsangivelsekode
  • Kursaktivitet: aktivitetkode, etterutdkurskode, kurstidsangivelsekode

Dei attributtane som ikkje er nevnd i tabellen har ikkje noko å sei for rolla si tilknytting. Roller som oppfyller krava til fleire av tilknyttingstypane vert ignorert. Roller som ikkje oppfyller krava til nokon av tilknyttingane vert ignorert.

4.2.9   Informasjon om offentleggjering av persondata

Hentar informasjon om studentar skal publiserast i nettkatalogen eller ikkje, altså nettpublisering. Om ein student ikkje kjem ut frå denne spørringa vert ikkje informasjon om personen publisert. Det er tre forskjellige tilstandar for ein student:

  1. Det finnes ingen rad i tabellen med AKSEPTANSETYPEKODE='NETTPUBL'.

    Informasjon om studenten vert ikkje publisert.

  2. Det finnes en rad i tabellen med AKSEPTANSETYPEKODE='NETTPUBL' og STATUS_SVAR='N'.

    Informasjon om studenten vert ikkje publisert.

  3. Det finnes en rad i tabellen med AKSEPTANSETYPEKODE='NETTPUBL' og STATUS_SVAR='J'.

    Informasjon om studenten vert publisert.

Merk at studentar som også er registrert i SAPUiO må også vere godkjend for nettpublisering i SAPUiO for at informasjon om personen skal publiserast.

4.2.10   Informasjon om EVU-studentar

EVU-studentar skal vere registrert i EVU-modulen i tabellen fs.deltaker. Vi hentar alle som er knytta til kurs som tidligast vart avslutta for 30 dagar sidan.

4.2.11   Informasjon om studentar i permisjon

Vi bruker ikkje permisjonsdata til noko per i dag. Dei vert rekna som vanlege opptaksstudentar, så lenge dei har eit gyldig opptak. Om dei semesterregistrerer seg reknast dei som heilt vanlege, aktive studentar.

4.3   Informasjon om studieelement

4.3.1   Informasjon om studieprogram

Vi hentar ut alle studieprogram frå fs.studieprogram. Vi har dessverre ikkje bra nok datagrunnlag til å avgrense spørringa på utgåtte studieprogram. Vi har studentar som framleis er aktive, men som kan vere registrert på utgåtte studieprogram. Vi stoler på at FS har rutiner for å avslutte desse riktig.

4.3.2   Informasjon om emner

Vi henter inn alle emner som har vore aktive siste året (arstall_eks_siste >= fjoråret).

4.3.3   Informasjon om kull

Vi hentar inn alle aktive kull. Vi avgrenser til kull sidan 2002.

4.4   Informasjon om undervisingselement

4.4.1   Informasjon om undervisingsenheter

Vi henter inn undervisingsenheter for å få registrert emner, studentar og anna på riktig enhet. Dette hentast frå fs.undervisningsenhet, og vi henter berre inn undervisingsenheter for dette året og framtidige semester, og som er registrert med minst eit emne.

4.4.2   Informasjon om undervisingsaktivitetar

Vi hentar ut alle undervisingsaktivitetar for dette og framtidige semester. Enkelte verdiar, som partiløpenummer og disiplinkode, må vere satt før vi importerer aktiviteten.

4.4.3   Informasjon om EVU-kurs

Vi hentar ut alle aktive EVU-kurs, som tidlegast vart avslutta for 30 dagar sidan.

4.4.4   Informasjon om EVU-kursaktivitetar

Vi hentar alle kursaktivitetar for aktive EVU-kurs, og kurs som vart avslutta for tidlegast 30 dagar sidan.

4.5   Informasjon om deltaking i undervising

4.5.1   Informasjon om undervisingsmeldingar

Vi hentar ut undervisingsmeldingar for alle studentar meldt til undervising frå og med inneværande år.

4.5.2   Informasjon om deltaking i undervisingsaktivitetar

Vi henter ut alle studentar på alle undervisingsaktivitetar - undervisingsparti - for inneværande og framtidige år.

4.5.3   Informasjon om vurderingsmeldingar

Vi hentar ut alle vurderingsmeldingar for studentar i inneværande semester.

4.5.4   Informasjon om deltaking i EVU-kursaktivitetar

Vi henter inn alle deltakarar på alle EVU-kursaktiviteter.

4.6   Informasjon om kopiavgift

Kopiavgifta må vere betalt for at ein student skal få skrive ut ved UiO. Vi henter difor inn alle dei som semesterregistrert for inneværande semester, og som har betalt faktura med status OPPGJORT og type KOPIAVG. Vi inkluderer også dei som er semesterregistrert og har betalingsform satt til FRITATT eller EKSTERN.

4.6.1   Informasjon om utskriftsbetaling

Oversikt over utskriftsbetalingar er flytta over til utskriftsløysinga, så dette brukast ikkje lenger i Cerebrum.

4.7   Informasjon om endringar i fødselsnummer

Når FS melder frå at ein person har fått endra sitt fødselsnummer, gjer vi det samme for personen i Cerebrum. Dette gjerast aller først ved import, sidan fødselsnummer er ein sentral identifikatorar.

Dersom eit nytt fødselsnummeret allereie finnast på ein annan person i Cerebrum ignorerast endringa og det må behandlast manuelt. Dette er for å unngå at to ulike personar vert slått saman.

Cerebrum har ei liste over fødselsnummer som skal ignorerast frå FS sin oversikt over fødselsnummerendringar. Dette er for å unngå trøbbel med feilregistreringar. Denne lista vert oppdatert i samråd med AF.

Av jokim
Publisert 30. aug. 2022 10:31 - Sist endret 2. des. 2022 10:57
Del på e-post