Spesifikasjon for automatiske grupper basert på studieinformasjon

Det er ønskeleg å innføre generelle, automatiske grupper i Cerebrum basert på informasjon om studieelement frå FS. Dette er den overordna spesifikasjonen til korleis desse gruppene skal fungere. Funksjonaliteten skal vere generell nok til å kunne brukast av alle instansar som bruker Cerebrum og FS.

Spesifikasjonen er under utarbeiding, og treng tilbakemeldingar frå dei dette er relevant for. Dokumentet skal etterfølgast av ein meir teknisk spesifikasjon før utviklinga.

1   Motivasjon

Studieinformasjon frå FS hentast ut til Cerebrum og brukast til ymse formål, til dømes for Feide-tilgang, utskriftskvoter og Fronter-grupper. All slik informasjon har blitt utvikla spesifikt for sitt formål, og det er lite gjenbruk av funksjonalitet i Cerebrum. All informasjon vi får frå FS lagrast i eigne XML-filer som kan lesast inn der det er behov, men dette er rådata som ikkje er behandla, og det ligg ikkje innebygd i Cerebrum.

Cerebrum har i dag allereie funksjonalitet for å automatisk oppdatere grupper basert på informasjon frå FS. I studentautomatikken har du studconfig.xml som kan brukast for eigendefinerte grupper som baserer seg på studieinformasjon som studieprogram, emner, person-tilknyttingar og mange andre utplukk. Ulempa med denne konfigurasjonen er:

  • Det er ingen struktur i korleis gruppene definerast, sidan ein kan definere namna etter eige ønske. Dette gjer at det heller ikkje er enkelt å sjå om ei gruppe i Cerebrum vert automatisk vedlikeholdt eller ikkje.
  • Det er ikkje enkelt å forstå kven som skal vere i ei gruppe ut frå namnet. Utplukka til gruppene settast ofte opp som kombinasjonar av utplukk, og kan då fort bli kompliserte, og det vil ikkje vere intuitivt å vite dette berre ut frå gruppenamnet.
  • Endringar i automatikken vert sendt inn til Cerebrum drift, som oppdaterer konfigurasjonen manuelt. Med generelle, automatiske grupper for alle studieelementa kan instansen ta dei i bruk direkte, så lenge gruppene finnast.
  • Gruppeutmelding gjerast manuelt av Cerebrum drift omtrent ein gang i semesteret. Det at det gjerast manuelt og ikkje fortløpande fører til ein del ekstraarbeid med administrasjon og oppfølging. Det auker også risikoen ved at brukarar har fleire tilgangar enn dei skulle hatt, over ein lenger periode. Manuelle rutiner har også ein tendens til å glippe eller bli utsatt.

Det vi ser mangler er enklare struktur og meir generelle grupper. Det er også ønskeleg at administratorar må kontakte Cerebrum drift i mindre grad, men kunne ta i bruk funksjonalitet direkte etter eige ønske og behov.

2   Løysinga

Det vi treng er generelle, automatiske grupper som har forståelege namn, enkle og like utplukkskriterier og ein enkel struktur. Alle gruppene skal settast opp med ein gang, så lenge FS har informasjon som kan føre til ei gruppe. Administratorar kan då, etter eige ønske og behov, ta dei i bruk for ulike formål utan å måtte involvere Cerebrum drift.

Alle gruppene vil ha ein fast prefiks fs-, etterfulgd av kva type studieelement den inneheld. Ein må før oppstart passe på at instansen ikkje allereie har grupper med dette prefikset, som då kan stå i fare for å bli endra på.

Gruppene skal bli oppdaterte regelmessig, nye grupper skal opprettast når nye studieelement dukker opp og studentar skal meldast inn og ut av gruppene fortløpande. Løysinga liknar i stor grad på dei automatisk vedlikeholdte gruppene for ansatte, men her hentast informasjonen direkte frå FS ved oppdatering. Vi bruker ikkje XML-filene for oppdateringa.

Gruppeutmeldingar vil skje ved kvar køyring for dei studentane som ikkje lenger skal ha tilgang, til dømes fordi dei er avregistrert frå eit emne eller fordi det er eit nytt semester. I studentautomatikken i dag køyrast utmeldingar berre ein gang i semesteret, i roligare periodar. Denne endringa er ønskeleg for å bedre tilgangskontrollen, men det gir også større konsekvensar dersom ein student er feilregistrert i FS. Risikoen for feilregistreringar må bli sett opp mot risikoen ekstra IT-tilgangar gir.

Det vil vere valfritt for ein instans å sette opp automatikken, og løysinga kan brukast også samtidig med den eksisterande studentautomatikken si gruppeoppdatering, så lenge det ikkje er kollisjonar i gruppenamna.

2.1   Begrensingar

Kva denne automatikken ikkje kan løyse:

  • Gruppenamna vil alle vere over 8 teikn, som betyr at gruppene ikkje nødvendigvis kan vere filgrupper der dette er ei begrensing. Dette kan løysast ved å melde studiegruppene inn i filgrupper, som gjer at studentane inkluderast i filgruppa.
  • Det vil ikkje vere mulig å definere sine eigne grupper med eigne utplukk med denne automatikken. Den gamle studentautomatikken vil gradvis fasast ut, så eigendefinerte, automatiske grupper vil etterkvart forsvinne med mindre det er sterke behov for dette som ikkje meir generelle grupper kan løyse.

3   Gruppene

Kvart studieelement vil føre til oppretting av ei gruppe for kvart element, og gruppa vil fyllast med studenten sin person, som vil medføre at det er primærbrukaren til studenten som vert eksportert til andre system. Gruppene vert oppretta ved behov, dvs. berre når det dukker opp informasjon i FS som krever ei ny gruppe.

3.1   Oppdatering av gruppene

Gruppene vil bli oppdaterte på bakgrunn av informasjonen vi får frå FS. Dette kan settast opp til å køyre så ofte ein vil, til dømes kvar dag.

Korleis gruppene vil bli vedlikeholdte:

  1. Automatikken henter ut all relevant informasjon frå FS.

  2. Gå gjennom kvart studieelement:

    1. Dersom gruppa for studieelementet ikkje eksisterer opprettast den. Gruppa får eit gruppenamn med ein definert prefiks, og beskrivelsen settast til kva studieelement den gjeld for.
    2. Gruppa sin expire_date vil bli fjerna om den er satt.
    3. Gruppa får trait autogroup dersom den ikkje allereie har det.
    4. Det sjekkast om gruppa har alle spreads som er definert i konfigurasjonen. Spreads som mangler leggast til, men spreads som ikkje eksisterer i konfigurasjonen vil bli beholdt.
    5. Alle studentar som i følge FS skal vere med i gruppa får person-objektet sitt lagt til.
    6. Alle andre entitetar som er medlem av gruppa vert meldt ut. Dette gjeld både personar, brukarar, grupper og andre entitetstypar.
  3. Studieelement som ikkje lenger er aktive/gyldige vil føre til at gruppa tømmast for medlem, men gruppa vil ikkje bli sletta. Dette gjerast for å skape mindre støy i endringsloggar, unngå bytte av entity_id og eventuelle GID, og ikkje minst beholde gruppa sine eventuelle manuelle medlemskap i andre grupper som instansen sjølv kan ha satt opp.

3.2   Administrasjon av gruppene

Nokre merknader til administrasjonen av gruppene:

  • Gruppene kan enten brukast direkte, ved å gje gruppa riktig tilgang, eller indirekte, ved å melde den automatiske gruppa inn i andre grupper som gir tilgang.
  • Dersom det er behov for å legge til ekstra brukarar manuelt er riktig måte å opprette ei eiga gruppe, som får den automatiske gruppa som medlem i tillegg til alle manuelle brukarar. Dette kan også brukast til å lage kombinasjonar, til dømes alle studentar på mange forskjellige emner eller studieprogram skal ha samme tilgangane.
  • Alle gruppenamn har ein fast prefiks fs- for å skille dei frå andre grupper i Cerebrum. Dersom det eksisterer eller vert oppretta grupper i Cerebrum med dette prefikset står dei i fare for å bli tatt over av automatikken. Dette bør også sjekkast opp før vi set opp automatikken.
  • Instansen kan sjølv bestemme kva spreads gruppene skal ha, som vert vedlikeholdt ved kvar køyring. Administratorar som har tilgang til det kan også legge til andre spread manuelt på dei gruppene det er ønskeleg for. Dersom ein fjerner eit spread som er definert for automatikken vil dette bli lagt til ved neste køyring.

4   Studielement

Vidare følger ein oversikt over alle studieelement som automatikken skal lage grupper for. Det skal brukast så generelle element som mulig, og utplukka skal vere enklast mogelege.

Gerenelt skal utplukka for studielementa gjelde for inneværande semester og fram i tid, med mindre studieelementet inneheld eigne start- og sluttdatoar, som til dømes studieprogram har for kvar student. Ein konsekvens av å gå etter semester er at gruppene vil ved semesterskifte drastisk bytte ut medlemsmassen sin.

Merk at utplukka ignorerer alle personar som ikkje finnast i Cerebrum endå. Denne automatikken importerer ikkje nye personar frå FS til Cerebrum.

4.1   Studieprogram

Alle aktive studieprogram har kvar si gruppe med studentane sine. Dette kan inkluderer alle studentar med studierett. Studieprogramma inkluderer også doktorgradsstudentar og nokre variantar av privatistar der dei er registrert på eit studieprogram.

Alle studieprogramgrupper har namneformatet:

fs-studieprogram-STUDIEPROGRAMKODE

Krav til utplukket:

  • Studieprogrammet må vere aktivt.
  • Alle studentar må ha gyldig opptak til studieprogrammet for å vere med. Dette betyr bl.a. at start- og sluttidspunktet for opptaket til studenten må vere gyldig.

Merk at ein student kan vere med på fleire studieprogram så studenten vil difor kunne vere med i fleire studieprogramsgrupper.

Merk også at studentstatkode ignorerast, så gruppa vil til dømes inkludere studentar som går deltid eller som er i permisjon, så lenge dei har ein aktiv brukar.

Studieprogram reknast ikkje med semester, så desse utplukka vil ikkje endre seg ved semesterskifte.

4.2   Kull

Alle studentar på eit gitt kull vert med i si kullgruppe.

Alle kullgrupper har namneformatet:

fs-kull-STUDIEPROGRAMKODE-ÅRSTALL-TERMINKODE

Der ÅRSTALL består av fire siffer og TERMINKODE er enten VÅR eller HØST. Desse felta vil ikkje endre seg.

Krav til utplukket:

  • Kullet må ha status aktivt. Straks det ikkje er aktivt vil gruppa bli tømd.

Merk at studentstatkode ignorerast, så gruppa vil til dømes inkludere studentar som går deltid eller som er i permisjon, så lenge dei har ein aktiv brukar.

4.3   Vurderingsemner

Alle som har ei vurderingsmelding, frå gamalt kalla eksamensmelding, vert med i ei gruppe for emnet.

Alle vurderingsemner har namneformatet:

fs-vurdering-EMNEKODE

Krav til utplukket:

  • Studenten må ha ei vurderingsmelding til emnet.
  • Vurderingstidspunkt må vere i inneværande semester eller fram i tid.

TODO: Er det andre behov for fleirsemesteremner? Dersom eit emne har fleire vurderingstider vil alle studentar på dei ulike tidspunkta inkluderast i den samme gruppa for emnet, så lenge vurderingstidspunkta er i inneværande semester eller fram i tid.

Merk at versjonskoden ikkje er inkludert i gruppenamnet. Alle studentar på ulike versjonskodar vil bli inkludert i samme gruppa.

4.4   Undervisingsemner

Alle som har ei undervisingsmelding vert med i ei gruppe for emnet.

Alle undervingsmeldingar har namneformatet:

fs-undervisning-EMNEKODE

Krav til utplukket:

  • Studenten har gyldig opptak til emnet, dsv. gyldig undervisingsmelding.
  • Undervisingstidspunktet må vere i inneværande semester eller fram i tid.

TODO: Er det andre behov for fleirsemesteremner?

Merk at versjonskoden ikkje er inkludert i gruppenamnet. Alle studentar på ulike versjonskodar vil bli inkludert i samme gruppa.

4.5   Undervisingsaktiviteter

Alle som er registrert på ein undervisingsaktivitet vert inkludert i gruppa for aktiviteten.

Alle undervisingsaktiviteter har namneformatet:

fs-undervisningsaktivitet-EMNEKODE-AKTIVITETKODE

Krav til utplukket:

  • Studenten må vere registrert på undervisingsaktiviteten i inneværande år eller fram i tid.

4.6   EVU-kurs

Alle som er registrert på eit EVU-kurs vert med i evukurs-gruppa.

Alle EVU-kurs har namneformatet:

fs-evukurs-ETTERUTDKURSKODE

Krav til utplukket:

  • Etterutdanningskurset må vere gyldig, dvs. sluttdatoen må ikkje ha passert for meir enn 30 dagar sidan.

4.7   Ikkje inkluderte studieelement

Nokre studielement er ikkje inkludert av automatikken, då vi vurderte dei til å ikkje vere nødvendige. Vi nemner dei likevel her, for å få eventuelle tilbakemeldingar på element som likevel bør vere med.

  • Fagperson: Fagpersonar er ansatte, og vert dekka ved at dei er registrert i ansattsystemet. Dei kan vere registrert til aktivitetar, men dei vert ikkje teke med i første runden.
  • Privatist: Privatistar er registrert på eit studieprogram, og er oppmeldt til vurdering i emner, så dei er allereie med i fleire grupper. Vi såg difor ikkje behovet for å skille desse ut som ei eiga gruppe, men tok dei heller med der dei er med.

5   Framgangsplan

Utgangspunktet for planen framover.

Merk: Grunna andre prioriteringar har vi måtte utsette denne aktiviteten. Vi har difor ikkje fulgt framgangen, men håper på å ta opp att aktiviteten i 2014.

Opprinneleg framgangsplan, som ikkje vart fulgd:

  1. 17. juni til 28. juni: Cerebrum tek i mot tilbakemeldingar på initielt dokument om studiegruppene.
  2. 1. juli til 1. august: Cerebrum utvikling utarbeider ein spesifikasjon for studiegruppene. Dersom tilbakemeldingane vi har fått ikkje har påført for mykje kompleksitet vil funksjonaliteten kunne bli utført allereie i denne perioden.
  3. 5. august til 16. august: Cerebrum tek i mot tilbakemeldingar på spesifikasjonen.
  4. 19. august til 26. september: Funksjonaliteten utviklast og settast i produksjon for dei det er ønskeleg.
  5. Seinare: Vi utvider funksjonaliteten med fleire detaljar.

6   Vidare arbeid

Det vil kunne dukke opp behov for fleire grupper, ønsker om andre krav til utplukka og eventuelt også anna automatikk rundt gruppene. Det vi i første omgang kjem på av detaljar som vil kunne bli sett på etter første versjon:

  • Grupper for fagpersonar, som er knytta til undervising, vurdering og aktiviteter.
  • Gruppemedlemskap, for enklare strukturering og bruk av gruppene. Med dette meinast automatikk for at dei automatiske gruppene vert medlem av andre automatiske grupper. Eit døme er å kunne lage ei samlegruppe for alle aktivitetar for eit gitt emne, der alle aktivitetsgruppene vert medlem av samlegruppa. Dette er likevel berre noko som gjerast dersom det er reelle behov.

7   Bakgrunnsdata

Litt informasjon om kva som finnast av løysingar i Cerebrum i dag, og som har blitt brukt i utarbeidinga av spesifikasjonen.

7.1   Studconfig sine muligheter

Studentautomatikken i dag bruker ei fil med namn studconfig.xml for å definere kva grupper som skal oppdaterast basert på informasjon frå FS. Denne kan konfigurerast til å vedlikeholde grupper ut frå ein god del kriterier:

  • Tilbud Alle som har mottatt tilbud om opptak til et gitt studieprogram. Baserer seg på studieprogramkoden.

  • Studierett: Alle som har studierett til et gitt studieprogram. Baserer seg på studieprogramkode.

  • Aktiv: Alle som er aktive i et gitt studieprogram. Aktiv medfører opptak til studieprogrammet (ikke 'PRIVATIST') og en semesterregistrering hvor man enten har meldt seg til eksamen i et emne som kan inngå i studieprogrammet eller en bekreftet utdanningsplan innen studieprogrammet. Baserer seg på studieprogramkode.

  • Privatist studieprogram: Alle som har opptak lik 'PRIVATIST' til et studieprogram som emnene de er meldt til kan inngå i, og som ikke har noen annen form for opptak til andre studieprogram som de sammen emnene kan inngå i. Baserer seg på studieprogramkode.

  • Emne: Alle som er meldt til eksamen i et gitt emne, og som har opptak (ikke PRIVATIST) til et studieprogram som emne kan inngå i. Baserer seg på emnekode, og ein kan spesifisere om også vurderingsmeldingar for framtidige semester også skal tellast med, men dette er truleg ikkje blitt implementert.

  • Privatist emne: Alle som er meldt til et emne uten å ha opptak. Baserer seg på emnekode.

  • Aktivt sted: Sted der studenten er aktiv, dvs der

    1. Et av de aktive kursene til vedkommende hører hjemme.
    2. Hvis ingen aktive kurs; hvor aktivt studieprogram hører hjemme.

    Se '`aktiv`'-elementet over for definisjon av "aktivt studieprogram".

    Utplukket baserer seg på ein gitt stedkode, og du kan definere om steder under gitt stedkode skal inkluderast i utplukket.

  • Emnestud sted: Sted der studenten er tar et emne, dvs emnet studenten er undervisningsmeldt til.

    Utplukket baserer seg på ein gitt stedkode, og du kan definere om steder under gitt stedkode skal inkluderast i utplukket.

  • Medlem av gruppe: Sjekker opp mot medlemskap i grupper. Brukt primært for å lage unntakslister for printerkvoter.

  • EVU sted: Sted der EVU-studenten er aktiv, dvs der et av de aktive EVU - kursene til vedkommende hører hjemme.

    Utplukket baserer seg på ein gitt stedkode, og du kan definere om steder under gitt stedkode skal inkluderast i utplukket.

  • Person-tilknytting: Affiliation til personen som eier brukeren. Kan treffe både tilknytting, til dømes. ANSATT og statustype, til dømes TILKNYTTET/gruppelaerer.

Merk at alle kriteria som brukast for studentautomatikken bruker informasjon som ligg lagra i XML-filer med FS-data. XML-filene importerast mellom ein til tre ganger i døgnet frå FS.

Som oftast køyrast ikkje gruppeutmeldingar meir enn ein gang i semesteret, og settast i gang ved at Cerebrum drift starter jobben manuelt med opsjon for gruppeutmeldingar.

Konfigurasjonsfila til studentautomatikken støtter også fleire gjeremål enn berre gruppeadministrering, til dømes kva brukaren skal ha av heimeområde, spread, karantene og utskriftskvote. Alt dette vert ikkje dekka av denne automatikken.

7.2   Semester

Cerebrum henter ut semester frå FS etter kva tid det er på året:

  • Frå 1. januar til 30. juni: VÅR.
  • Frå 1. juli til 31. desember: HØST.

Merk at det for nokre utplukk også er behov for å inkludere forrige og neste semester. Utvidinga av utplukka gjerast då i periodane:

  • Frå 1. januar til 15. februar: Inkluder også fjoråret sitt semester HØST.
  • Frå 1. juli til 15. september: Inkluder også forrige semester, altså VÅR med samme årstal.
Av jokim
Publisert 26. juni 2014 09:34