Tilbakemeldingar til AF sitt utkast til Cerebrum sine behov frå FS

2.1   Aktiv student

Ein grace-periode på eit halvt år skaper ikkje tekniske hindringar, men Cerebrum har fått refs frå IT-sikkerhetssjef for at vi bygde inn ein grace-periode i Cerebrum. Det kan hende IT-sikkerhet ønsker ein kortare periode.

Med tanke på gjenbruk, så andre klientar også kan dra nytte av tenesten, kan det vere greit å ta ein runde på kva som er riktig definisjon av aktiv student. Ein grace-periode kan vi løyse på andre måtar, dersom den berre er tenkt for Cerebrum. Dersom det ikkje finnast ein, fast definisjon av kven som er aktiv student for dei fleste tenester, ønsker vi å ta ein runde på kor filtreringa av studentar skal skje. AF eig definisjonen av aktiv student, men med tanke på gjenbruk kan det vere ein fordel om FS heller gir ut eit opnare, generelt utplukk, som kvar enkelt klient, som Cerebrum, kan sjølv filtrere på. Cerebrum ønsker å diskutere dette med AF.

I forslaget til uthenting av aktive studentar er det kommentert at utplukket gir eit resultat på 40000. Cerebrum har færre studentar enn dette per i dag.

I Cerebrum har vi per 3. mai:

• 23000 vanleg aktive studentar
• 3300 som drgrad
• 5000 som emnestud
• 454 som evu
• 2200 som privatist

Summert har vi 34000 studentar. Det riktige talet er litt lågare, sidan studentar kan vere i fleire av kategoriane samtidig.

Nytt utplukk for aktive studentar medfører difor at vi vil kunne få 6000 fleire studentar. Det er eit forbehold at tala som er samanlikna er frå ulike tidspunkt. Sei frå, så kan vi hente ut nye tal frå Cerebrum.

2.2   Opptak

Cerebrum har i dag 13000 studentar med opptak. Nytt utplukk vil kunne føre til at ein del fleire studentar får opptaksstatus. Dette talet kan fort bli lågare om ein rydder opp i td. REALFAG.

2.3   Person/studentinfo

• Kva meinast med "aktive emner"? Vurderings- eller undervisingsmelding?
• Vi treng brukarnamn og e-postadresse (fs.person.emailadresse), for å kunne samanlikne før Cerebrum oppdaterer FS med nye verdiar. Vi henter i dag ikkje privat e-postadresse, så denne treng vi ikkje.
• Ja, vi vil ha adresser, for at lokal IT og student-IT skal kunne sende ut passordbrev ved behov. Vi kan heller evt. fjerne denne informasjonen seinare. Dette kan evt. skillast ut som ein eigen teneste, for å gjere det enklare å sperre ned tilgangen til Cerebrum for denne tenesta, når vi ikkje lenger treng den.
• Ja, vi vil ha fagperson-info. Dette for at vi skal kunne samanlikne og oppdatere informasjon som ikkje samsvarer med data frå SAPUiO.
• Generelt ser vi det som ein fordel å skille ut personinfo-uthentinga i meir atomære uthentingar. Dette for å enklare skape gjenbruk. Vi er usikre på om AF ser på dette punktet som ein IT-teneste, eller om det er ei samling av tenester og er samla for å gje oversikt.
• Ønsker å skille ut informasjon om studieprogram (namn, stedkode, studienivå, og studieprogramkode) og emner som eigne tenester (utlistingar), og ikkje som ein del av uthentinga av person-informasjon. I persondata-uthentinga er det då nok å peike til studieprogramkode og emnekode. Dette for å gjere tenestene meir atomære, i henhold til ny arkitektur. Dette auker også sjansen for at andre klientar enn Cerebrum vil kunne ta i bruk tenestene utan å eksponere for mykje data til klientar som ikkje treng det.
• For studieprogram ønsker vi også informasjon om namn på studieprogrammet og studieprogramkoden.
• For emner ønsker vi også emnekode. Vi henter i dag versjonskode, men er usikker på om vi treng denne.
• Dersom vi skal vite om tilhørighet til EVU-studentar, treng vi også informasjon om deira kurs. Dette kan sikkert bli slått saman med utlistinga av emner.

Vi treng å sjekke ut meir om kva datafelt brukast til i Cerebrum. Denne lista er difor ikkje komplett heilt endå. Utredning av dette skjer i CRB-1607.

2.4   Fødselsnummer-endringar

Forslaget er ok. Utplukket Cerebrum køyrer i dag inneheld akkurat det som er opplista: gamalt og nytt fnr, og dato for endringa.

2.5   Stedkoder

Det ser ut til at vi ikkje treng å hente ut stedkodestruktur, med unntak av for Fronter, sidan vi får strukturen frå SAPUiO. Vi treng å vite kva stedkode kvart studieelement høyrer til.

2.6   Oppdatering av person og fagperson

Vi må ha mulighet til å hente ut brukarnamn og e-postadresse, for å kunne samanlikne. Vi rekner med at dette berre mangler i avsnittet om uthenting av person-informasjon.

Vi vurderte den eksisterande BAS-tenesten, men den vil ikkje dekke dagens behov. Kva Cerebrum gjer i dag:

1. Alle som er registrert som tilsett frå SAP vil bli oppretta i FS, i tabellen fs.person, med attributta fodselsdato, personnr, fornavn, etternavn, fornavn_uppercase, etternavn_uppercase, emailadresse, kjonn, dato_fodt og ansattnr. Etter oppretting endrer vi ingen annan informasjon enn ansattnr.

   Personar som er registrert som tilknytta personar i SAPUiO vil ikkje bli overførd til FS.

2. Alle som er registrert som vitskapleg tilsett frå SAP vil bli oppretta i FS, i tabellen fs.fagperson, med ein del attributtar:

   • fodselsdato, personnr settast til fødselsnummeret registrert i Cerebrum.
   • institusjonsnr_ansatt, faknr_ansatt, instituttnr_ansatt, gruppenr_ansatt settast til personen si primære tilknytting, evt den første enheten over som er kjend i FS. Merk at personar kan ha tilknytting til fleire stedkodar, så dette vil ikkje alltid vere korrekt enhet.
   • stillingstittel_norsk settast til arbeidstittel frå SAPUiO.
   • status_aktiv settast til N, men berre ved oppretting.

   Enkelte andre attributtar settast til tomme verdiar.

   Vi oppdaterer også eksisterande fagpersonar med dei samme attributtane.

Den eksisterande tenesten som AF nemner har manglande:

• Den omhandlar berre fagpersonar og ikkje personar.
• Vi fann ingen spesifikasjon på kva parameter vi kan gje, og kva som er påkrevd. I dømet stod det ingenting om korleis vi td. oppdaterer brukarnamn, og kan <kommune/> utelatas?

3.1   Studieelement

Cerebrum henter i dag informasjon om studieelement, i hovudsak for tilgangsstyring, men også noko for å styre kva studentar skal ha tilgang til (studentautomatikken sin studconfig) og eventuelt også for e-postlister.

Vi sender informasjonen vidare til Fronter, men andre brukar dette også. Vortex har ein oversikt over kva kursdata som brukast, på https://www.uio.no/vrtx/tmp/bruk-av-course.uio.no-grupper.txt. Vi veit at Fronter-gruppene i Cerebrum også vert brukt av lokal IT. I tillegg har det kome inn ønsker om automatiske studierelaterte grupper som granulerer heilt ned på studieaktiviteter og personroller, til dømes gruppelærer for ein gitt aktivitet.

Data vi bruker:

• Fagpersonar sine aktive roller, for granulert tilgangsstyring. Til dømes Hovudlærar for eit emne. Vi treng å vite namnet eller koden på rolla, kva enhet og kva emne/kurs/studieprogram/aktivitet rolla er knytta til. Vi treng også framtidige roller.
• Emner, med attributta studienivåkode, kva enhet det tilhøyrer, namn på emnet og versjonskode. Vi treng også framtidige emner.
• Kurs, med attributta termin og år. Vi treng også framtidige kurs.
• Studieprogram, med attributta studieprogramkode, enhet det tilhøyrer og fullt namn. TODO: Ser ikkje ut til at vi treng studienivåkode.
• Undervisingsenheter. TODO: Det er usikkert kva attributt vi bruker.
• Undervisingsaktiviteter, med attributta kva emne og versjonskode den tilhøyrer, termin og årstal. Vi inkluderer også framtidig element. TODO: Har ikkje sjekka om vi bruker løpenr og anna for aktivitetane.
• Det kan hende vi ønsker informasjon om kull, dersom det er ønskeleg å ha tilgangsstyring og lister for alle på samme kull.