Utviklingsønsker med begrunnelser 2019

Avdeling for studieadministrasjon ved UiOs kontaktperson for FS (Lena Finseth) sender FS-utviklingsønskene UiO er enige om til de nasjonale FS-utviklerne i Unit på deres nettskjema. Begrunnelsen og løsningsforslagene føres opp på denne siden.

Unit=Direktoratet for IKT og fellestjenester i høyere utdanning og forskning

Ønske 1/2019 Flere tegn i feltene for "Navn" i vurderingskombinasjon samlebilde

Ønsket av Det medisinske fakultet, RT#3242973. Sendt Unit 11.1.2019 (RT#331077)

Modul: Vurderingsmodulen

Beskrivelse av problemstilling

Det medisinske fakultet har behov for ytterligere tegn i feltene for "Navn" i vurderingskombinasjon samlebilde for å kunne dekke det faglige innholdet i sine eksamener til fremvisning på karakterutskrifter og vitnemål. I dag er det plass til 120 tegn, men fakultetet ønsker at denne økes til minst 200.

Et eksempel: Det faglige innholdet i skriftlig eksamen i MED5600 er "Written exam in gynaecolocy / obstetrics, pediatrics, pathology, community medicine, general practice, ethics, pharmacology, behavioral science, biochemistry, genetics, and psychiatry"

Slik det er i dag, så kan vi ikke skrive dette fullt ut, og er nødt til å bruke ustandard forkortelser og triksing for å få plass. Dette ser ikke pent ut på vitnemålet.

Endringsønsket er basert på å kunne legge inn de allerede vedtatte navnene / faginnholdet på eksamenene i medisinstudiet.

Løsningsforslag

Øke antallet mulige tegn i feltene for "Navn" på bokmål, nynorsk og engelsk i vurderingskombinasjon samlebilde fra 120 til minst 200.

Vurdering i Avdeling for studieadministrasjon

Vi forstår det som fakultetsadministrasjonen har forsøkt å finne andre løsningsalternativet  i dialog med det mediske fagmiljøet, uten å lykkes. Avdeling for studieadministrasjon har gjort fakultetet oppmerksom på at 200 tegn i vurderingskombinasjonen ikke nødvendigvis ser særlig lekkert ut Studentweb, på semestersidene, på karakterutskrift og på vitnemål. Men, det gjør heller ikke dagens forkortelser.

Status 8. oktober 2019

UiO purret Unit på en løsning 7.10.2019 og fikk svar 8.10.2019:

Det er en ganske stor jobb, da den vil påvirke mange bilder, rapporter og rutiner, i tillegg til en applikasjonene, EPN, studentweb, fagpersonweb, vitnemålsportalen, intergrasjoner mot eksamens og undervisningssystemer og muligens andre integrasjoner. Særlig karakterutskrifter og vitnemål vil bli berørt, da en slik endring vil kreve mye mer plass. Vi må være sikker på at ikke en slik endring gjør at noen av applikasjonene kneler.

Har planer om å få tatt et møte i vurderingsgruppen i løpet av høsten. Ikke bestemt når ennå.

 

Ønske 2/2019 Nytt FS-API. Til BAS-integrasjon: vurderingsdata og tillegg i person-tjenesten

Ønsket av studieavdelingen. Sendt Unit 23.01.2019 i deres RT#331993

Begrunnelse

Vi trenger i første omgang vurderingsdata og et par mindre tillegg i person-tjenesten, som skal brukes til BAS-integrasjon.

Løsningsforslag

* Oppsummert ønsker vi følgende:

- Vurderingsenheter med vurderingskombinasjonsinformasjon
- Studentvurderinger
- Mulighet for å poste til persons lånenummer
- To nye filter i person-tjenesten

Senere ønsker vi mer data på undervisning og post-muligheter for vurdering, se fullstendig spesifikasjon med detaljer på nettsiden vår om Nytt FS-API.
 

Ønske 3/2019 Studienivå i FS408.002 og FS508.002

Ønsket av SV i RT#3246987 9. januar 2019. Sendt til Unit 4.2.2019 i deres RT#332955.

Gjelder FS408.002 Undervisningsenhet og FS508.002 Vurderingsenhet

Beskrivelse av problemstilling

Fakultetene våre holder gjerne orden på alle undervisningsenhet og vurderingsenhet ved å fordele kontrollen på studienivå.

Fakultetene vil gjerne kunne ta ut Excel-oversikter fra FS408.002 og FS508.002 fordelt på studienivå slik at hver medarbeider som skal sjekke "sine" emner lett får oversikt. Hos oss er det slik at noen fordeler denne arbeidsoppgaven på studienivå innenfor hver stedkode.

Løsningsforslag

Primært, få et valg for studienivå i FS408.002 og FS508.002 som blir med dersom man lagrer rapportene i Excel.

Dersom det er kinkig å få til i rapportvisningen, at studienivå blir med ved Excel-lagring.

 

Ønske 4/2019 Resultatutveksling og sletterutiner for ubrukte resultater

Ønsket av studieavdelingen. Sendt Unit 20.03.2019 i deres RT#337034

Modul: Person eksternstudium, resultater

Begrunnelse

Mellom FS-institusjonene i Norge har vi mulighet til å hente inn til UiOs FS eksamensresultater fra alle de andre FS-institusjonene. Løsningen er slik at når den brukes, henter den alle personens resultater fra alle FS-institusjonene. Resultatutveksling brukes dersom en person søker opptak til studieprogram, enten via Samordna opptak eller via Søknadsweb på UiO. Resultatutveksling brukes også dersom en student søker om å få godkjent at utdanning fra andre FS-institusjoner kan inngå i studieprogrammet studenter går på på UiO eller til å erstatte forkunnskaper for opptak til emner. Til nå har resultatutveksling vært samtykkebasert. Samtykket har vært avgitt i Samordna opptaks portal, i Søknadsweb eller i Studentweb.

Samtykket til resultatutveksling blir fjernet i Søknadsweb og Studentweb med FS versjon 8.2 i mars/april 2019. Unit og Avdeling for studieadministrasjon ved UiO har vurdert det slik at samtykke ikke lenger er nødvendig for behandling av resultater fra universiteter og høyskoler. Dette betyr at alle som søker opptak eller som får behandlet en søknad om godkjenning av utdanning, automatisk får resultatene sine oversendt til UiO.

Beskrivelse av problemstilling

Vi mener at det trengs et sletteopplegg som gjør at resultater som verken har dannet opptaksgrunnlag til UiO og som heller ikke har blitt lagt inn i en utdanningsplan på UiO eller er brukt i kvalifikasjon rutinemessig blir slettet. Vi foreslår med dette at vi starter en dialog og diskusjon om hvordan kriteriene for sletting skal være.

Det trengs også en sjekk på om og hvilke eksterne resultater som har blitt brukt til å dekke forkunnskapskrav for UiO-emner. Her ser vi ikke helt hvordan det er synlig i FS at slik kobling finnes mellom Person eksternstudium og Godkjenningssak samlebilde, fanen Forkunnskapskrav. Ofte vil det eksterne emnet inngå i utdanningsplanen, men det gjelder ikke alltid, og gjelder ikke for enkeltemnestudenter og privatister som ikke har utdanningsplan.

Løsningsforslag

Vi foreslår eksempelvis en nattjobb i FS som sletter ubrukte eksterne resultater. Vi har ikke nøyaktig klart for oss hva kriteriene bør være, og nøyaktig hva som er lov. En person som etter noen år søker om nytt opptak eller ny innpassing vil vi hente inn resultater på nytt for i forbindelse med den nye søknaden.

For opptak ville nok det beste være om resultatene ble slettet ett år etter at periode opptak for siste registrerte søknad var utløpt, og at det ikke er knyttet til tidspunkt for innhenting av resultater. Siden noen søkere registrerer søknader nærmest fortløpende kan resultatene være hentet inn for lenge siden, da de kan ha hatt kontinuerlig aktive søknader over tid.

For selvfinansierende mastersøkere (SFM-opptak), starter søkeperioden tidlig, og det kan potensielt hentes inn resultater for et opptak allerede i oktober året før studiestart. Det er ikke sikkert det er noen krise om disse blir slettet ganske kjapt etter studiestart, men vi vil i så fall måtte ha rutiner for å være ekstra kjappe med originaldoksjekk for de som har norsk utdanning. Slettetidspunkt knyttet til periode opptak vil her også løse den utfordringen, da periode opptak for høstopptakene normalt er til 1. september.

Når det gjelder godkjenningssaker tenker vi f.eks. sletting ett år etter at en godkjenningssak er satt til BEHANDLET. Men som nevnt over blir det nok noen utfordringer knyttet til å se hvilke eksterne resultater som har blitt brukt til å dekke forkunnskapskrav for UiO-emner.

Vurdering av juridiske forhold og henvisning til sentrale og lokale regler

Med personvernforordningen har krav om dataminimering blitt tydeligere. Vi må ha på plass sletterutiner for personopplysninger vi ikke har behandlingsgrunnlag for. Vi kan ikke se at vi har behandlingsgrunnlag for å beholde eksterne resultater som vi ikke har benyttet i opptak eller godkjenningssaker. Resultatutveksling mellom FS-institusjonene ble innført flere år før personvernforordningen, mens den nye funksjonaliteten i resultatutvekslingen er kommet nå etter at personvernforordningen har trådte i kraft i 2018. Med innføring av slik ny funksjonalitet må vi ta stilling til behandlingsgrunnlag og sletterutiner.

 

Ønske 5/2019 FS226.003: Inkludere kullbegrensning

Ønsket av SV i RT#3387011. Sendt Unit 09.05.2019 i deres RT#341999.
Løst FS8.2.5 (revisjon 3): FS226.003: Ny kolonne for kullbegrensning. For emner vises også siste undervisningstermin.

Modul: Studieelementer FS226.003 Emnekombinasjoner emne/emnekombinasjoner inngår i

Begrunnelse

UiO har robuste emner og emnekombinasjoner og gjenbruker dem år etter år på ulike studieprogrammer. Etter som årene går, trenger fakultetene likevel jevnlig å justere på innholdet. Da trenger vi kontroll og oversikt når emner og emnekombinasjoner i emnekombinasjoner må justeres og oppdateres.

Beskrivelse av problemstilling

Vi bruker FS226.003 for å kartlegge hvilke emnekombinasjoner som må oppdateres når emner/ emnekombinasjoner legges ned, samt for å påse at jobben er gjort.

Eksempelvis skulle 40-gruppen i demografi (40-DEMO) legges ned. Den måtte kullbegrenses i mange ulike emnekombinasjoner på fem ulike fakulteter. Illustrasjon vedlagt ‘fs226-003-40-demo.PNG’

For å dobbeltsjekke og påse at alle kombinasjoner har blitt oppdatert må vi gå inn igjen på alle emnekombinasjoner i emnekombinasjon samlebilde og sjekke at det er registrert kullbegrensning. Det hadde vært enklere om registrert kullbegrensning kom frem rapport FS226.003.

Vi gjør tilsvarende for emner - for eksempel ECON1730. Da legges emnet ned i emnekombinasjonen, enten ved kullbegrensning eller ved siste semester. For eksempel i 40-DEMO har vi lagt inn siste semester 2018-HØST. Hvis emnet hadde vært obligatorisk i en emnekombinasjon hadde jeg lagt til kullbegrensning. For å se at alt er registrert lagt ned hadde det vært nyttig å se det i FS226.003.

Løsningsforslag

Nye kolonner for kullbegrensing i FS226.003 «Emnekombinasjoner emne/emnekombinasjoner inngår i»:

  • Utplukk Emnekombinasjon: vise data fra "Studenter med startperiode kull" fra Emnekombinasjon samlebilde, fanen Emnekombinasjon. Se illustrasjon i rød skrift på vedlegget ‘fs226-003-40-demo.PNG’
  • Utplukk Emne, vise: "Studenter med startperiode kull" og siste semester for emne.

Kost/nyttevurdering for egen institusjon

Får bedre kontroll på at studenter får riktige utdanningsplaner med riktige valgmuligheter.

Ønske 6/2019 Utvidelse av FS-API om emner

Ønsket av studieavdelingen. Sendt Unit 21.05.2019 i deres RT#343200

Bilde/rutine/rapport/annet det gjelder

Informasjon om emner på: https://api.fellesstudentsystem.no/emner/{id}

Resultat av tidligere behandling

Se tidligere sak om nye ønsker til nytt FSAPI: Unit RT#331993

Begrunnelse

Vi skal begynne å publisere emnebeskrivelser fra FS og ut på nettsidene våre. Da har vi behov for at FS-API tar med flere felter fra FS

Beskrivelse av problemstilling

*https://api.fellesstudentsystem.no/emner/{id} Denne viser litt for lite data om emner i forhold til våre behov.

Løsningsforslag

1) Vi ønsker at https://api.fellesstudentsystem.no/emner/{id} også tar med følgende data direkte fra emnetabellen:
 - studiepoeng
 - periode vurdering
 - periode undervisning
 - fag sortering
 - antall forsøk lovlig (eks + und)
 
2) Vi ønsker i tillegg at alle data fra følgende undertabeller til emne blir tilgjengelig som undertjenester:
 - emneoverlapp (VEKTREDREGEL,VEKTREGELEMNE)
 - vurderingstermin (VURDKOMBTID)
 - undervisningstermin (UNDTERMIN_EMNE)
 - infotekst (EMNEINFO)
 - infotermin (INFOTERMIN_EMNE)
 - språk (EMNE_SPRAKVALG)
 - forkunnskapskrav (FORKUNNSKAPSKRAV/KRAVELEMENT_FORUTSATT/EMNE_FORUTSATT/LISENS_FORUTSATT)
 - emnekjede (EMNESAMLING/EMNE_I_EMNESAMLING)

 

Ønske 7/2019 Utveksling: Endre avtaleid – inkludere eksternt sted

Ønsket av studieavdelingen. Sendt Unit 23.5.2019 i RT#343507

Navn på bilde/rutine/rapport/annet det gjelder

Funksjonen «Endring av avtalelid eller fradato i periode for utvekslingspeson [sic!]»

Begrunnelse og beskrivelse av problemstilling

Unngå manuelle operasjoner. Unngå feilrapportering av eksternt sted.

Gjelder bildet Utvekslingsperson: Bruk av knappen ‘Endre id / fra-dato’ endrer id i feltet Avtaleid, men ikke data i feltet Eksternt sted. 
Eksempel: En utreisende student skal bytte fra avtale-id 409 (Valencia) til avtale 2000 (Cádiz). Vi bruker funksjonen under knappen ‘Endre id / fra-dato’, og legger inn id 2000. I feltet Avtaleid blir ny id rettet til 2000, men eksternt sted blir fremdeles liggende med 13700062 (Valencia), selv etter å ha hentet inn opplysningene på nytt. Saksbehandler må da endre eksternt sted manuelt, til 13700042 (Cádiz).

Løsningsforslag

Det hadde vært fint om endringsfunksjonen også kunne oppdatere eksternt sted samtidig som endring av avtaleid. Men, det ikke nødvendigvis entydig hvilken ekstern institusjon det skal endres til, da en utvekslingsavtale kan være tilordnet mange institusjoner. Vi foreslår derfor å et ekstra endringsfelt for ekstern institusjon i endringsbildet, der man angir ekstern institusjon.

Kost/nyttevurdering for egen institusjon

Unngår manuelle operasjoner i et annet bilde enn der endringen tilsynelatende gjøres, altså i endringsbildet Endring av avtalelid eller fradato i periode for utvekslingsperson. Da unngår vi feilrapportering av eksternt sted dersom saksbehandler overser nødvendigheten av også å oppdatere eksternt sted manuelt.

 

Ønske 8/2019 FS214.001 Send e-post: Knapp for ‘Sett som default’

Ønsket av studieavdelingen. Sendt Unit 23.5.2019 i RT#343509

Navn på bilde/rutine/rapport/annet det gjelder

FS214.001 Send e-post

Begrunnelse og beskrivelse av problemstilling

Vi sender sjelden/aldri e-post fra egen e-postadresse, og har faste rutiner for hvilken adressetype som skal benyttes.

Det er tungvint å måtte skrive inn avsender-e-postadresse og gjøre valg for adressetype hver gang vi benytter FS214.001.

Løsningsforslag

Knapp for ‘Sett som default’, tilsvarende som i bildet Meldingsinformasjon.

Kost/nyttevurdering for egen institusjon

Vil gjøre utsendelse av eposter fra FS214.001 mer smidig og mindre risiko for å sende fra/til feil epostadresse.

Ønske 9/2019 SW3: Endre veivalg: ikke slette meldinger

Ønsket av FS-nettverket i møte 3. juni 2019, sak 6. Sendt Unit 04.06.2019 i RT#344673

Status 21.02.2023: Funksjonaliteten er ikke endret slik UiO ønsker.

Tidligere behandling

Saker til Unit i 2016: RT#209143 og RT#2072264 (i gammel RT-instans), FS-møtet 5.desember 2016

Begrunnelse

Med Studentweb3, som UiO tok i bruk i april 2016, ble det slik at en student som endrer veivalg i utdanningsplanen samtidig får slettet undervisnings- og eksamensmeldingene knyttet til det veivalget studenten går bort fra. Studenten får et varsel om at meldingene vil bli slettet, og velger således å gjøre et aktivt valg ved å klikke "lagre" og gjennomføre endringen av veivalget. Men, det betyr at samtidig som man endrer veivalg, må man velge bort alle undervisnings- og eksamensmeldingene knyttet til det gamle veivalget. Studenten kan ikke velge å beholde noen av meldingene. Fakultetene våre er ikke fornøyd med den automatiske slettingen.

Beskrivelse av problemstilling

Noen ganger innebærer endring av veivalg at studenten skal ta de samme emnene, bare i en annen emnekombinasjon. Det gjelder for eksempel dersom studenten skal endre fra en støttegruppe på 40 studiepoeng og heller vil fordype seg inne samme fagområde i en fordypningsgruppe på 80 studiepoeng i stedet. I slike tilfeller vil flere av emnene være de samme, og studenten trenger å beholde noen eller alle undervisnings- og eksamensmeldingene.
Når undervisnings- og eksamensmeldinger blir slettet utenfor aktiv semester-registreringsperiode, er det samtidig ikke mulig for studentene å melde seg til emnene på nytt for det inneværende semesteret. Fakultetene våre har dermed manuelt merarbeid med å gjenopprette undervisnings- og eksamensmeldinger for studenter som har endret veivalg. Enda mer manuelt merarbeid blir det i de tilfellene studenten først lenge etterpå oppfatter at undervisnings- og eksamensmeldingene er slettet. Ved sletting av eksamensmeldinger, slettes all informasjon knyttet til vurderingsmeldingen, inklusive kandidatnummer og tilrettelegging. Det blir fort feil i manuell gjenoppretting fordi studenten er blitt meldt opp igjen, men da med annet kandidatnummer/ ikke har fått kandidatnummer. Den semestervise tilretteleggingen blir fjernet i sin helhet og saksbehandler må da sjekker søknadspapirer på nytt – sum: Mange ansatte må involveres for å få rettet opp i feilen.

Løsningsforslag

Studentene får oversikt over hvilke undervisnings- og vurderingsmeldinger som knytter seg til det gamle veivalget og får samtidig mulighet til å angi hvilke undervisnings- og vurderingsmeldinger som skal beholdes dersom man endrer veivalg.

Vi ser at løsningen kan bli komplisert, samtidig som den skal være intuitiv, så vi ser at ønsket kan bli vanskelig å innfri uten å gå tilbake til Studentweb2 løsningen der undervisnings- og eksamensmeldinger ikke ble slettet samtidig som man endret veivalg. Studenten måtte selv gå til oversiketn over undervisnings- og eksamensmeldinger og slette.

Inntil dette endringsønsket vårt eventuelt kommer på plass i Studentweb, ber om at Unit hindrer studenter i å endre veivalg utenfor aktiv semesterregistreringsperiode. Dette løsningsforslaget smerter, da vi tenker utdanningsplanen som en digital dialog mellom studieprogrammet og studenten, der studenten ved selvbetjening i Studentweb hele året kan gjøre de valgene som studieprogrammet tillater, dvs. at studenten kan endre retning i studieløpet hvis ønskelig og det er mulig i studieprogrammet og planlegge studieløpet sitt frem i tid alle dager.

 

Ønske 10/2019 Maksgrense for antall emner en student får melde seg til per semester? 

Notat fra september 2017

Sendt Unit 4.6.2019 i RT#344683. Avvist i FS planleggingsgruppe juni 2019. Begrunnelse:

UiO presenterte problemstillingen som et endringsønske i den nasjonale FS planleggingsgruppe 18. og 19. juni 2019. Ingen andre institusjoner hadde uttalte behov for slik begrensing. Ønsket ble unisont avvist av samtlige møtedeltakere, unntatt UiB. UiB anerkjente problemet fra ett og annet institutt, uten at det var et uttalt problem for UiB som helhet. Svært få andre institusjoner har undervisningsopptak. Planleggingsgruppen syntes ikke det var riktig å prioritere å finne en god nok FS/Studentweb-løsning for én institusjon når det er så mye annet i FS-sfæren som er mer prekært å få løst.

 

Ønske 11/2019: Emnekombinasjon samlebilde: Felt for siste semester for emnegruppeEmnekombinasjon samlebilde: Felt for siste semester for emnegruppeEmnekombinasjon samlebilde: Felt for siste lovlige semester å velge inn emnegruppe

Ønsket av HF og SV 20.6.2019 i RT#3459672 og RT#3439195. Sendt Unit 9.7.2019 i RT#356327

Problemstilling. Behovet og hvordan det løses i dag

HF og SV har en del 40-grupper som utfases og legges ned. Som regel blir ikke slike endringer vedtatt så lenge før de trer i kraft, det er kanskje bare snakk om semesteret før. Endringene henger ofte sammen med endringer i emne og/eller programporteføljer. Ved slike nedlegginger av 40-grupper ønsker vi å forhindre at flere studenter velger 40-gruppen, mens de som allerede har valgt 40-gruppen skal få fullføre den (med en overgangsordning hvis nødvendig). I noen tilfeller kan det være aktuelt å flytte studentene over til en ny (og omtrent identisk) emnegruppe, men som regel må studentene få fullføre emnegruppen de startet på.

Når vi skal legge ned 40-grupper i FS, sjekker vi først FS226.003 for å se hvilke programmer/studieretninger som tilbyr 40-gruppen. Deretter sjekker vi FS727.003 og ser hvilke studenter på disse programmene/studieretningene som har 40-gruppen i sin utdanningsplan. På bakgrunn av dette legger vi inn kullbegrensning i feltene «Studenter med startperiode kull» for den aktuelle emnegruppen/emnekombinasjonen i fanen «Emnekombinasjon» i Emnekombinasjon samlebilde for de programmene som tilbyr 40-gruppen. Hvis det f.eks. bare er studenter med kull 2018-HØST på et program som har valgt 40-gruppen, legger vi inn 2018-HØST – 2018 HØST.

En slik kullbegrensning medfører imidlertid at alle på kullet/kullene som det er begrenset til får opp 40-gruppen i Studentweb og får mulighet til å velge den. Tanken har vært at studentene skal se på nettsiden at 40-gruppen er lagt ned og dermed ikke velge denne 40-gruppen likevel. Det viser seg imidlertid at noen studenter velger slike 40-grupper som utfases likevel. Det er vanskelig og tidkrevende å skulle følge med på om det er noen nye studenter som velger 40-gruppen etter at den egentlig er lagt ned.

Et alternativ vi har tenkt på er å kullbegrense til et kull langt bakover i tid, slik at studenter ikke får opp 40-gruppen i Studentweb. Dette vil imidlertid medføre at 40-gruppen vises med rød markering i utdanningsplanen i FS for studenter som allerede har denne 40-gruppen i utdanningsplanen siden de går på et kull som faller utenfor kullbegrensningen. En slik markering vil trolig mange saksbehandlere stusse over og tenke at er ugyldig/feil. Vi synes derfor ikke dette alternativet er hensiktsmessig å bruke.

Løsningsforslag og hvordan dette vil forenkle/forbedre arbeidet

I tillegg til kullbegrensning ønsker vi å kunne registrere det siste semesteret studenter kan velge en 40-gruppe (emnekombinasjonen) i Studentweb. Denne funksjonaliteten finnes i dag på emnenivå (i fanen «Emne» i Emnekombinasjon samlebilde).

Vi ønsker derfor å få et «Siste semester»-felt i fanen «Emnekombinasjon» i Emnekombinasjon samlebilde, eller en annen løsning som gjør at vi kan registrere når studentene på et gitt studieprogram/studieretning skal kunne velge en emnegruppe siste gang.

En slik endring vil medføre en enklere og mer korrekt FS-registrering av de vedtakene som fattes om nedlegging av emnegrupper. Det vil også bli enklere for studentene ved at de vil kunne se direkte i Studentweb om de kan eller ikke kan velge en 40-gruppe, fordi den enten er valgbar via utdanningsplanen deres eller ikke. Dermed vil vi ikke i så stor grad være avhengige av at studentene får med seg nødvendig informasjon på programsidene og emnegruppepresentasjonen. I tillegg vil vi spare tid på å følge med på om studenter feilaktig har valgt emnegrupper som er under utfasing og skal legges ned.
Hvordan er endringsønsket vurdert lokalt?

Er endringsønsket behandlet i dialog med enkeltbrukere eller i et større forum?

SV og HF er enige om at det vil være nyttig og arbeidsbesparende å få en slik endring, og vi melder inn dette ønsket sammen.

Studieavdelingens vurdering av ønsket

Studieavdeling har syns dette er et godt begrunnet utviklingsønske, og sender det til Unit.

 

Ønske 12/2019 Synliggjøre påloggingsalternativene for Studentweb o.l.

Ønsket av Houston (RT#3516771) og studieavdelingen, sendt Unit 8.8.2019 (deres RT#362169)

Gjelder påloggingssiden til Studentweb, pluss Søknadsweb, Fagpersonweb osv.
UiO sendte nok inn noe for mange år siden om mer begripelig teksten på Feide-innloggingsalternativet, men fikk avslag.

Beskrivelse

(Særlig nye) brukere av Studentweb oppfatter ikke at de har ulike påloggingsalternativer og hva de innebærer.
De ulike påloggingsalternativene ligger som arkfaner. Det betyr at det ikke er umiddelbart synlig for den som skal logge på hva de ulike arkfanene innebærer. Dette er uheldig, både fordi ordvalgene ikke er umiddelbart begripelig for førstegangsbrukere, og at de brukerne som må bruke ID-porten ikke ser denne muligheten. Når brukere fra flere land etter hvert kan ta i bruk eIDAS, blir det enda viktigere at de ulike brukergruppene oppfatter de ulike påloggingsalternativene.

Løsningsforslag

1. Lamelløsning
2. Mer begripelig tekst tilpasset den aktuelle applikasjonen

Se bildeforslag i png som illustrerer forslaget bedre enn ord.

Ønske 13/2019 Endringslogg fra und.akt. samlebilde om to LMS-felt

Ønsket av studieavdelingen. Sendt Unit 20.9.2019 i deres RT#366397

Modul: Undervisningsaktivitet samlebilde og Undervisningsenhet-logg

Begrunnelse og beskrivelse av problemstilling

Når vi støtter fakultetene våre knyttet til feil i forbindelse med Canvas, trenger vi jevnlig å kartlegge om årsaken til et problem er at bakgrunnsdata i FS nylig er endret, eller om årsaken ligger andre steder.

Vi har derfor behov for mer logging av endringer i undervisningsaktivitet samlebilde, feltene for LMS: J/N og LMS Rom-mal.

Løsningsforslag

Hente ut to nye felter til Undervisningsenhet-logg:

  1. Endringer i LMS: J/N (tabell UNDAKTIVITET, kolonne STATUS_EKSPORT_LMS)
  2. Endringer i LMS Rom-mal (tabell UNDAKTIVITET, kolonne LMSROMMALKODE)

Kost/nyttevurdering

Raskere å avdekke hvor årsaken til feil eller stopp i LMS-et kan ligge.

 

Ønske 14/2019 Ph.d.: Vise godkjent opplæringsdel

Ønsket av UV i RT#3587751 27.9.2019

Behovet og hvordan det løses i dag

Hver kandidat skal ha et skriv om at opplæringsdel phd. er godkjent. Denne skrives i dag i Word.

Løsningsforslag og hvordan dette vil forenkle/forbedre arbeidet

Legge malen i FS og koble den til utdanningsplanen. Konsulentene slipper å lage dette i word og utdanningsplanen blir mer aktiv brukt.

Hvordan er endringsønsket vurdert lokalt?

I fane-nettverket ved UV.

Vurdering i Avdeling for studieadministrasjon

Dette burde være overflødig nå når ph.d.-kandidatene har har utdanningsplan i FS og Studentweb. Hvis det er absolutt nødvendig å ta ut et skriv, så kan f.eks. FS-rapport 727.001 dekke behovet. 

Videre er prosessen rundt innlevering av avhandling under gjennomgang i BOTT-Sak og arkiv-prosjektet. Dette dokumentkravet, og andre lokale dokumentkrav, er i den forbindelse oppe til vurdering. Studieavdelingen vurderer derfor at det ikke bør prioriteres ressurser på dette på UiO eller hos Unit.

Ønske 15/2019 Emner med både seminarvariant og selvstudiumsvariant. Sperre vedr. eksamensvariant

Ønsket av SV i RT#3588054 27.9.2019

Behovet og hvordan det løses i dag

På SVEXFAC03 er det både en seminarvariant og en selvstudiumvariant (seminargruppe 99).
Når studenter søker seg til emnet i Studentweb er det jo slik at de formelt først søker om undervisningsplass, får svar på søknaden, og deretter (hvis positivt svar) melder seg til eksamen.

Hvert semester er det studenter som åpenbart ønsker å melde seg til selvstudium, men fordi de trykker feil, eller fordi det ikke er plass på seminargruppe 99 (selvstudium), melder de seg til undervisning i seminarvarianten og til eksamen i selvstudiumvarianten.

SQL-en som kjøres etter 1.9./1.2. gjør at studenter med undervisningsmelding i én av variantene og eksamensmelding i den andre får harmonisert meldingene sine, og siden undervisningsmeldingen da er førende kommer studenter og lurer på hvorfor de nå er meldt til eksamen i seminarvariant, når de ønsker å ta selvstudiumvarianten.

Løsningsforslag og hvordan dette vil forenkle/forbedre arbeidet

Er det mulig å lage en sperre i FS/Studentweb, slik at studenter som får opptak til undervisning i et seminar også kun kan melde seg til eksamen i seminarvarianten? Og selvsagt også for dem som får opptak til undervisning i selvstudium (seminargruppe 99), en sperre slik at de kun kan melde seg til eksamen i selvstudiumvarianten?
Hvis ikke en sperre, er det mulig å lage en beskjed som dukker opp når studenten har fått innvilget undervisningsplass, om at hen må melde seg til eksamen i samme variant?

Dette vil være arbeidsbesparende da det er tydeligere for studentene hvilken vurderingsform de er meldt til, og kan minske trykket på førstelinje. Og behovet for å kjøre en SQL to ganger i året utgår.

Hvordan er endringsønsket vurdert lokalt?

Ønsket er behandlet i dialog med enkeltbrukere siden dette gjelder et fåtall emner.

Vurdering i Avdeling for studieadministrasjon

Studieavdelingen forstår behov for mindre manuell håndtering av slike emner, men vi er usikre på om det er hensiktsmessig å be om en endring på en utfordring som per i dag omfatter tre emner.

 

Ønske 16/2019 Håndtere obligatorisk fremmøte i FS

Ønsket av MF i RT#3588116 og RT#3588103, sendt inn 27.9.2019

Viderebehandlet i 2020 og sendt Unit 24.11.2020 jf Ny rutine for behandling av oppmøtedata, Unit RT#409251

Behovet og hvordan det løses i dag

Vi mangler funksjonalitet i FS for å håndtere de store mengder data som genereres av fremmøteregistrering. Gjennom Fagpersonweb har vi fått et godt system for å registrere fremmøte, men løsningen kan ikke tas bredt i bruk all den tid man manuelt må sjekke at studentene faktisk oppfyller kravene til fremmøte. Uten en bedre måte å håndtere disse blir det vanskelig å ta ut gevinsten av å gå over fra papirskjema og oppmøtebøker til digitale løsninger. Vi ønsker oss derfor et system lar oss lagre fremmøteregler, koble sammen fremmøtedata og nevnte regler ved hjelp av rutiner, og som til slutt kan sette at fremmøtet er godkjent.

Forslag til videreutvikling av løsning for håndtering av obligatorisk fremmøte

Våren 2017 ble det gjennomført en høring om hvilke regler for obligatorisk fremmøte som fantes ved utdanningsinstitusjonene. Dette som ledd i at man hadde utviklet løsningen for registrering av fremmøte via Fagpersonweb, og at en naturlig videreutvikling ville være å implementere rutiner for å håndtere ulike typer av dette i FS. Så vidt vi vet har det ikke skjedd noe utvikling i etterkant av denne høringen.

Nettopp mangelen på verktøy for å håndtere fremmøtedata forhindrer videre utrulling av noe som er blitt en god løsning for selve registreringen av tilstedeværelse. Slik løsningen fremstår i dag, så mangler det rutiner eller automatikk som kan håndtere den store mengden data som systemet genererer. Vi ønsker derfor å komme med et ønske om og et forslag til hvordan et slikt system kan fungere, slik at systemet kan tas i bruk for fullt.

Systemet må kunne løse to ting:

1. Fremmøte første gang på undervisning -> Møtt «ja» på undervisningsmelding.

i. Bør kjøres automatisk og oppdatere feltet «STATUS_FREMMOTE_UND = J» i tabellen «UNDERVISNINGSMELDING» for emnet.

2. Fremmøte på obligatorisk undervisning -> Kunne telle opp, godkjenne eller opprette «OBLIG» når en regel for fremmøte er oppfylt.

i. Vi ønsker i første omgang at rutinen for dette kjøres manuelt. På sikt kan man se på automatisering.

a. Eks Oppmøteregel 1 (Møt minst 3 ganger): MED1100-1-2-P-1-101, MED1100-1-2-P-1-104, MED1100-1-2-P-1-108¸ MED1100-1-2-P-1-109.

b. Eks Oppmøteregel 2 (Oppmøte på minst 75% av gangene): MED1100-1-2-KF-1-1, MED1100-1-2-KF-1-7, MED1100-1-2-KF-1-9, MED1100-1-2-KF-1-12, MED1100-1-2-KF-1-15

Og i tillegg ha følgende funksjonalitet:

  • Må kunne kopieres ved bruk av standardrutinene for kopiering av undervisning (oppretting/kopiering)
  • Må fungere for undervisning via «AKTIVITETKODE_REF» i tabellen «UNDERVISNINGSTIMEPLAN» slik at alle studenter som har denne «timen» via felles undervisning også tas med. Applikasjonen tar hensyn til dette i dag.
  • Må kunne fungere for enkeltaktiviteter og rekker.
  • Må kunne håndtere endringer fra timeplansystemet TP. Gjelder blant annet unntak fra rekker og endringer av underviser.

Forslag til håndtering av fremmøteregler
 [Se illustrasjon fra FS i vedlegg til RT#3588103]
Felt for registrering av «regelnummer» for fremmøte i underbildet timeplan eller annet egnet sted.
En tabell for å lagre og vedlikeholde reglene knyttet til ID (her MED1100-1-2-P-1-101). Denne kan lagres for emne og trenger ikke å ta hensyn til terminnummer.

Hvordan er endringsønsket vurdert lokalt?

Forslaget er utarbeidet av arbeidsgruppen for studieadministrative systemer i helseutdanningene, som er et samarbeid mellom de medisinske fakultetene ved UiB, NTNU, UiO og UiT. Det er basert på behov spilt inn fra de som har benyttet fremmøteregistrering i pilotperioden, og er forankret lokalt ved MED før innsending hos oss.

Vurdering i studieavdelingen

Studieavdelingen syns ønsket godt beskriver behovet og gir løsningsforslag for hva som trengs av automatiserte løsninger for etterarbeid i FS, etter at oppmøtet er registrert. Studieavdelingen støtter ønsket. Vi kan ikke forskuttere noe om hvilke ressurser Unit har til å prioritere forslaget.

Ønske 17/2019 FS158.001 for lokale opptak

Ønsket av studieavdelingen, og sendt Unit 29.10.2019 i RT#368646. Ønsket er en oppfølging og spesifikasjon etter møtet i nasjonal ekspertgruppe for opptak 5.12.2017, Units RT#260790. 

Navn på bilde/rutine/rapport/annet det gjelder

FS158.001 Automatisk behandling av søknader med godkjent elektronisk vitnemål

Begrunnelse

Vi erfarer at FS158.001 fortsatt ikke fungerer for lokale opptak, og sender inn et endringsønske i håp om at det skal hjelpe, fremfor å gjenåpne RT#260790 med ytterligere tekst.
    
I lokale opptak tilkjennes gsk for de som har elektronisk vitnemål i NVB ved å trykke på «Godkjenn VM»-knappen i Søknad samlebilde. Slik det er nå, må vi manuelt slå opp hver søker og foreta denne operasjonen. I f.eks. enkeltemneopptaket er det gsk (og ev. spesielle opptakskrav) som er kravet for å bli kvalifisert. Flere søknader kan behandles automatisk hvis vi får en rutine for å godkjenne vitnemål for lokale opptak.

Problemstilling

Hvis vi har en rutine for å godkjenne vitnemål, kan vi behandle flere søkere automatisk istedenfor manuelt å måtte gå inn på hver enkelt søknad for å trykke på knappen «Godkjenn VM». I flere av søknadene er det kun denne operasjonen som skal til for at søknaden blir behandlet for kvalifikasjonskrav. Vi bruker en egen rutine for å fullføre søknader (157.001).

Løsningsforslag

Vi ønsker at rutinen FS158.001 skal godkjenne elektroniske vitnemål for gsk (og spesielle opptakskrav) i lokale opptak. Ev. kan det lages en ny rutine som kun gjør dette?

Vårt behov når det gjelder FS158.001, er at vitnemålet godkjennes, slik at generell studiekompetanse blir registrert, og ev. kravelementer i Profil blir oppdatert (det er samme kravelementer som i NOM). Vi trenger ikke setting av kvalifikasjonsgrunnlag, test av førstegangsvitnemål, setting av mangelkoder eller dokumentasjonsstatus. I de lokale opptakene som vi ønsker å bruke rutinen for, skal vi ikke rangere søkerne, kun tilkjenne generell studiekompetanse og registrere spesielle opptakskrav. Vi ønsker også at J blir satt til N i Ubehandlet NVB-resultat, mens ev. J i Ubehandlet dokument/resultat blir stående (tilsvarende som for NOM).

Med rutinen FS158.001 i NOM blir de med ett gyldig vitnemål behandlet, mens de med to eller flere gyldige vitnemål må behandles manuelt. Siden søkere med flere vitnemål kan ha fag som dekker spesielle opptakskrav på kun ett av vitnemålene, ønsker vi i utgangspunktet at rutinen godkjenner alle vitnemålene (hvis det er flere enn ett gyldig) for lokale opptak. Dersom ikke dette lar seg gjøre, ønsker vi oss uansett en rutine for å behandle de med kun ett gyldig vitnemål.

Kost/nyttevurdering for egen institusjon

Automatisering, effektivisering og mindre manuell saksbehandling.

Ønske 18/2019 Dr.gradsmodul: Opprette ny finansieringstype/finanskildekode

Ønsket av studieavdelingen, og sendt Unit 29.10.2019 i RT#368653.

Navn på bilde/rutine/rapport/annet det gjelder

Doktorgradsmodulen / DRKAND_ARBEIDSFORHOLD / FINANSKILDEKODE

Resultat av ev. tidligere behandling 

Oppretting av institusjonskode - RT#5371371

Beskrivelse av problemstilling

Noen av våre doktorgradskandidater blir nå finansiert av NORPART, et partnerskapsprogram for globalt akademisk samarbeid. Programmet er finansiert av Kunnskapsdepartementet og Utenriksdepartementet, og blir administrert av Diku. NORPART er nylig opprettet som institusjon og har fått inst.nr 20371, jf RT 5371371. 

Det er ingen som har formelt arbeidsgiveransvar for NORPART-kandidatene. Vi har derfor behov for å kunne registrere NORPART som Finanskilde (Student samlebilde, underbildet Finansiering) uten verdi i feltet Arbeidsgiver. Arbeidsgiverfeltet er normalt et obligatorisk felt. 

NORPART-kandidatene kan sammenlignes med doktorgradskandidater finansiert av Kvoteprogrammet ved at begge er finansiert av en offentlig stipendordning og at ingen har arbeidsgiveransvar for dem. Vi tenker oss derfor at registrering av NORPART-finansiering kan løses på samme måte som Kvote-finansiering. Ved registrering av Kvote-finansiering er det feltet 'Finansieringstype' (FINANSKILDEKODE) = KVOTE som utløser at feltet Arbeidsgiver ikke blir obligatorisk.

Løsningsforslag

Vi ber om at det opprettes en ny 'Finansieringstype' (DRKAND_ARBEIDSFORHOLD FINANSKILDEKODE) som utløser at arbeidsgiverfeltet ikke blir obligatorisk. Vi tenker oss videre at det kan komme sammenlignbare finansieringsordninger i fremtiden. For at løsningen skal bli mer robust kan finansieringstypen gjøres generisk ved at den for eksempel kalles UTDSTIP : Utdanningsstipend – Uten arbeidsgiver.

Vurdering av konsekvenser

Vi kan registrere det som er sant. Løsningen kan gjenbrukes.

Status 16.2.2020: Løst slik:

Følgende endret til FS8.2.5 (flis05) [ca. mars 2020]:

Finanskilde er utvidet med kolonne status_krev_arbgiv. Dersom denne har verdi J, så må sted for arbeidsgiver være satt for finansiering. Denne kontrolleres ved en trigger. Alle finanskilder med unntak av EGEN og KVOTE har J i den nye kolonnen.

Ny verdi UTDSTIP innføres med flis05, med N i kolonnen status_krav_arbgiv.

Følgende endret i klient til etter flis05:

Bildet Finanskilde er utvidet med kolonnen Krav arb.giver.

Bildet Student samlebilde - Fane Finans: Feltet arbeidsgiver blir påkrevd (gul bakgrunn) dersom angitt finanskilde har verdi J for Krev arb.giver.

Ønske 19/2019 Eget bilde for grunnutdanning

Ønsket av studieavdelingen. Sendt Unit 12.11.2019 i RT#369578

Navn på bilde/rutine/rapport/annet det gjelder

Fanene for «Grunnutd.» i søknad samlebilde; SOKNAD_OPPTAKSGRLAG, søknad samlebilde historikk; H_SOKNAD_OPPTAKSGRL, (informasjonen blir også overført til student samlebilde; STUDPROGSTUD_OPPTAKSGRLAG)

Opprinnelig RT-id

Er relevant for RT#249702, jira FS-644 som ble sendt inn 5. april 2018

Begrunnelse

Ønsket henger sammen med ønsket i FS-644, siden vi ideelt sett ønsker å ha automatisk overføring av data om grunnutdanning fra person ekstern studium slik at saksbehandlere slipper å overføre disse dataene manuelt fra eksternstudium til søknad opptaksgrunnlag i opptaksøyemed.

NB: Det ser ut som saken er tolket som primært viktig for ph.d.-nivå, men det er på masternivå dette er mest aktuelt, da saksbehandlerne for master på UiO i mindre grad fyller dette feltet ut korrekt manuelt, siden det ikke brukes til rapportering, slik det er for ph.d. Ikke desto mindre gjør mangelen på funksjonalitet at innlegging av grunnutdanning er like arbeidskrevende for begge grupper av saksbehandlere.

Hensikten med ønsket er å lette saksbehandling ved master- og ph.d.-opptak i søknad samlebilde. Endringen vil også kunne lede til bedre statistikk over utdanningsbakgrunn for søkere til høyeregradsstudier.

Problemstilling

Grunnutdanning registreres både i forbindelse med opptak til ph.d. og til master. Ved ph.d.-opptak fylles feltene grundig ut siden det rapporteres på informasjonen, mens for master så brukes i stor grad kommentarfeltet. Dette gjør informasjonen lite tilgjengelig i etterkant, siden det er lite praktisk for saksbehandler å opprette informasjon som ofte allerede er tilgjengelig i person eksternstudium manuelt.

Saksbehandlere for internasjonalt opptak og ph.d. er gode til å fylle ut data, men siden det ikke er mulig å søke i feltene i grunnutdanning i dag, så er det vanskelig for dem å finne fram til presedens når de trenger det.

Vi ønsker at feltene i grunnutdanning, både for aktive opptak og for historikk, skal kunne brukes aktivt av saksbehandlere for å finne igjen saker som er løst tidligere, slik at de kan se om presedens følges i de enkelte opptaksvedtakene. For å få dette til tror vi det er nødvendig å opprette et eget bilde for grunnutdanning (SOKNAD_OPPTAKSGRLAG).

Løsningsforslag

Grunnutdanning i søknad samlebilde (SOKNAD_OPPTAKSGRLAG) og søknad samlebilde historikk (H_SOKNAD_OPPTAKSGRL) opprettes som egne bilder. Feltene i bildet må kunne søkes i. De viktigste feltene å kunne søke i for opptak er:

  •     Land
  •     Sted
  •     Kommentar (for å finne data bakover i tid)

Land bør kunne følge av sted, så hvis du legger inn institusjon, bør land komme opp automatisk.

For ph.d.-nivå er det i tillegg viktig å kunne søke i data om fagtilknytning.

Vurdering av konsekvenser

Mer effektiv saksbehandling. Bedre statistikker.

Vurdering av juridiske forhold

Vi ser ingen juridiske forhold som skulle være til hinder for ønsket.

 

Ønske 20/2019 Sluttdato for politiattest ved inndratt studierett

Ønsket av UV 25.11.2019 i RT#3658819. Se også RT#3592252 fra UV. Endringsønske sendt Unit 27.12.2019 i RT#372360

Status 7.7.2020:
Løst til databaseoppgradering FS8.2.7 høsten 2020.

  • FS250.001 Inndragning av studierett
  • FS655.001 Overføring av oppnådd kvalifikasjon til protokoll

Rutinene oppdaterer dato-gyldig-til til slutt-dato for studierett for alle lisenser og attester som ikke har slik dato/har en dato senere enn ny slutt-dato for studierett.

Problemstilling

Ved inndragning av studieretten skal politiattesten settes til utgått. Dette skal i dag gjøres manuelt.

Løsningsforslag

Ved kjøring av inndragningsrutinen gjøres det automatisk

Lokal vurdering av ønsket

Bredt

Vurdering i Studieavdelingen

Vi har vært i dialog med UV. Noen kommentarer og spørsmål:

I Studentweb fungerer det slik at dersom studieretten er inndratt eller av andre grunner ikke lenger er aktiv lenger, vises ingen opplysninger om politiattesten i Studentweb. Men, dersom studenten får opptak på samme program på nytt, vises den "gamle" attesten for studieprogrammet frem, såfremt lisensen av type politiattest ikke har en sluttdato i FS.

Det hender at studenter som får inndratt studierett, får tilbake studieretten på samme program og samme kull. Dersom politiattesten får sluttdato automatisk når studieretten blir inndratt, må man i så fall manuelt fjerne sluttdatoen på politiattesten. UV syns det høres greit ut. Hva syns andre fakulteter? 

Dersom man inndrar studierett manuelt, kommer det opp et varsel i FS om at studenten har en lisens og at man bør vurdere hva man skal gjøre med den. Et slikt varsel kommer ikke dersom man inndrar studieretter med inndragningsrutinen. Ville et varsel være tilstrekkelig?

Når en student har fullført et studieprogram, og dermed får avsluttet studieretten, får ikke politiattesten automatisk en sluttdato. Lisensen er ikke lenger gyldig når graden er oppnådd. Ønske en sluttdato på politiattester også da?

Med tanke på arbeidsfordelingen på fakultetene, virker det fornuftig at de som kan sette sluttdato på lisens eller fjerne sluttdatao, er de samme som inndrar studierett og fullfører studierett ved oppnådd grad? Studieavdelingen kan liste opp hvilke rettigheter man må ha i FS for de å få utført de ulike oppgavene.

Slik ble ønsket formulert til Unit i RT#372360 27.12.2019

Navn på bilde det gjelder

Student samlebilde > fanen Lisens. Lisenstypekode POLITI, POLITI-HOL, POLITI-LEG: Feltet Lisensen gjelder i periode *til* (DATO_SISTE_GYLDIGE)

Begrunnelse

Når en student på et studieprogram der det er krav om politiattest ikke lenger har opptak til dette studieprogrammet på det samme opptaket, er ikke den leverte politiattesten lenger gyldig.

På UiO er det omlag 1500 studenter som skal levere politiattest hvert år, attester vi således skal holde oversikt over i studietiden på studieprogrammet og etterpå.

Beskrivelse av problemstilling

I Studentweb fungerer det slik at dersom studieretten er inndratt eller av andre grunner ikke lenger er aktiv lenger, vises ingen opplysninger om politiattesten i Studentweb. Men, dersom studenten får opptak på samme program på nytt, vises den "gamle" attesten for studieprogrammet frem, såfremt lisensen av type politiattest ikke har en sluttdato i FS.

Dersom man inndrar studierett manuelt, kommer det opp et varsel i FS om at studenten har en lisens og at man bør vurdere hva man skal gjøre med den. Et slikt varsel kommer ikke dersom man inndrar studieretter med inndragningsrutinen FS250.001.

Når en student har fullført et studieprogram, og dermed får avsluttet studieretten, får ikke politiattesten automatisk en sluttdato. Lisensen er ikke lenger gyldig når graden er oppnådd.

Løsningsforslag

Vi ønsker at studenter som ikke lenger har en aktiv studentstatus, får satt sluttdato på lisenstypen for politiattester. Sluttdatoen for lisensen for politiattest skal være den samme som til-datoen for studieprogramstudenten (DATO_STUDIERETT_GYLDIG_TIL).

På UiO har vi per i dag tre lisenstypekoder som gjelder politiattester: POLITI, POLITI-HOL og POLITI-LEG

Et løsningsforslag er at FS250.001 Inndragning av studierett også setter sluttdato i DATO_SISTE_GYLDIGE i tabellen TILDELT_LISENS når studieretter blir inndratt og studenten har en lisens av typen politiattest som ikke har en sluttdato. Alternativt at det kommer opp en merknad om at det finnes en politiattest knyttet til studenten på dette studieprogrammet?

Videre innebærer dette løsningsforslaget at rutinen FS655.001 Overføring av oppnådd kvalifikasjon til protokoll får en funksjonalitet som også kan sette sluttdato i DATO_SISTE_GYLDIGE i tabellen TILDELT_LISENS dersom studenten har en lisens av typen politiattest som ikke har en sluttdato knyttet til studieprogrammet som fullføres. Alternativt at det kommer opp en merknad om at det finnes en politiattest knyttet til studenten på dette studieprogrammet?

Et annet løsningsalternativ er å innføre en ny nattjobb som setter sluttdato for sluttdato for politiattester i DATO_SISTE_GYLDIGE i tabellen TILDELT_LISENS for studenter som ikke lenger har en aktiv studentstatus og der sluttdatoen for studieprogramstudenten (DATO_STUDIERETT_GYLDIG_TIL) er passert.

Vurdering av konsekvenser

Det hender at studenter som får inndratt studierett, får tilbake studieretten på samme program og samme kull. Dersom politiattesten får sluttdato automatisk når studieretten blir inndratt, må vi i så fall manuelt fjerne sluttdatoen på politiattesten. Dette vil det alt i alt være en mindre krevende å holde orden på enn dagens løsning der ingen får sluttdato på politiattestlisens automatisk ved avsluttet studierett.

Vurdering av juridiske forhold og henvisning til sentrale og lokale regler

Når vi skriver at politiattest ikke lenger er gyldig dersom studenten ikke lenger går på programmet, har vi ikke en konkret hjemmel å vise til, men vi tolker regelverket slik at fraværet av en hjemmel forteller oss at en student ikke har lov til å ta med seg politiattester fra ett studium til et annet. Videre er reglene tydelige på at politiattester skal legges fram ved opptak.

Publisert 11. des. 2018 14:19 - Sist endret 21. feb. 2023 10:52