Ønske 1/2023 FS568.001 Egen kolonne for trekk under eksamen
Ønsket av medfak i RT#5338739 25.01.2023 og bearbeidet i DIG. Behandlet i FS-nettverket 6. mars 2023 og bred enighet om at UiO skal sende det inn.
Sendt Sikt 15.03.2023 i Sikts nettskjema Ref. 26370369.
Løst i FS-versjonen medio april 2023.
Hvilken del av FS gjelder ønsket for?
FS-klienten
Behovet som skal dekkes og problemet som skal løses
I rapporten FS568.001 vises ikke Trekk under eksamen (sensurregistrering med resultatstatus A, avbrutt eksamen) i kolonnene nederst i rapporten. Trekk under eksamen (resultatstatus A) inngår i tallet som står under Møtt, men vi savner at tallet blir skilt ut og synlig separat.
Nice to know: Eksamensresultater som er FS-registrert med A som resultatstatus, vil bli rapportert med karakteren(!) T til DBH. Karakteren T til DBH betyr altså ikke det samme som resultatstatusen T i FS. Vurderingsprotokollforekomster i FS har ett felt for karakter og ett for resultatstatus. I DBH-eksamensrapporten er de to feltene sammenslått til ett, hvor A er karakteren A, mens T er trekk under eksamen.
Studenter som har trukket seg før eksamen (resultatstatus T), rapporteres ikke til DBH.
Løsningsforslag
Gjøre tall for Trekk under eksamen (resultatstatus A) synlig i FS568.001 som egen kolonne i tabellen nederst.
Hvor viktig er endringen for UiO?
Viktig
Hvilken verdi/gevinst vil endringen ha for UiO?
Viktig i kvalitetsarbeidet og årsrapportering som inngår i kvalitetssystemet og ved forberedelser til NOKUT-tilsyn.
Tror du endringen får konsekvenser for andre institusjoner?
Ja, vil være nyttig også for andre i tilsvarende situasjoner
Vurdering i Studieavdelingen (SADM)
SADM støtter ønsket.
Ønske 2/2023 Emner som overlapper og der det først avlagte inngår i grad
Ønsket av MN 5. juni 2023 i RT#5540103. Vurdert i SADMs interne FS-møte.
Sendt Sikt 13.06.2023 i Sikt RT#361704.
Status 04.07.2023: Sikt skal lage varsel + sperre (https://unit.atlassian.net/browse/FS-1313). Sperren skal bare gjelde gradgivende kvalifikasjoner.
Hvilken del av FS gjelder ønsket for?
FS-klienten
Behovet som skal dekkes og problemet som skal løses
MN har emner på bachelornivå og masternivå som delvis overlapper med hverandre. Vi opplever at dette kan få uheldige konsekvenser når et emne på bachelornivå inngår i bachelorgraden for en student, og så tar samme student det delvis overlappende masteremnet som en del av teoripensumet i mastergraden. Hvis studenten får bedre karakter i masteremnet enn i bacheloremnet så fungerer det jo sånn i FS at mesteparten av vektingen blir lagt på masteremnet som har best karakter.
Eksempel: En student tar eksamen i IN3050 våren 2021 og får karakteren C. Høsten 2021 tok studenten eksamen i FYS-STK4155 og får karakteren B. Disse to emnene overlapper 3 SP. IN3050 inngår i studentens bachelorgrad som ble oppnådd våren 2021. Da det ble registrert karakteren B på FYS-STK4155 så ble vektingen for IN3050 redusert til 7 SP selv om emnet allerede inngår i bachelorgraden. Dette skjer automatisk. I dette tilfellet fikk MN rettet det opp fordi studenten selv tok kontakt om det, men det er ikke noen måte å finne ut av dette på automatisk. Burde det vært lagt inn en sperre i FS sånn at vektingsreduksjon ikke skjer for overlappende emner når det ene emnet allerede inngår i en grad?
Løsningsforslag
Sperre i FS slik at vektingsreduksjon ikke skjer for overlappende emner når det ene emnet allerede inngår i en grad.
Emner som ikke er i en students oppnådde kvalifikasjon/protokoll bør reduseres før emner som inngår i noen oppnådd kvalifikasjon, uavhengig regelens prioriteter og eksamenenes karakter. (Emnenes studienivå har aldri noe å si.)
Vurdering i studieavdelingen
SADM støtter ønsket og mener det gir riktigere data i FS og til studenten.
Ønske 3/2023 Ny beregning av klagefrist ved endringsstatus FEILREG eller NYINFO i (vurderings)protokoll
Sendt Sikt 10.07.2023 i deres RT#365618 som følge av RT#5587317 fra MN.
Løst i FSPROD 11.09.2023.
Hvilken del av FS gjelder endringsønsket for?
FS-klienten
Studentweb
Behovet som skal dekkes eller problemet som skal løses
Klagefrist beregnes ut fra når protokollforekomst ble opprettet, men den beregnes ikke på nytt hvis man gjør endringer i protokollen.
Vi hadde et tilfelle der feil resultat ble protokollført og det ble ikke oppdaget før etter 3 uker. Studenten fikk da ikke sendt klage på sensur via Studentweb når det riktige resultatet ble registrert siden klagefristen hadde gått ut. Men, feilregistreringer fra institusjonens side skal ikke gå ut over klagemulighetene til studentene, så vi regner dette som en feil i FS/Studentweb. Vi har imidertid i RT#365053 blitt bedt om å sende det inn som et endringsønske.
Vi ser også at brukerveiledningen ikke stemmer når det gjelder individuelle frister, så det ber vi dere også se på. Se nærmere i nevnte RT#365053.
Forslag til løsning
Hvis man gjør endringer i protokollen med endringsstatus FEILREG eller NYINFO burde klagefristen bli beregnet på nytt fra endringsdato, så studenten fortsatt har 21 dagers frist fra det riktige resultatet blir protokollført.
Hvor viktig er endringen for din institusjon?
Viktig
Hvilken verdi/gevinst vil din endring gi for din institusjon?
Sørger for at studenten får riktig klagefrist og dermed være sikret sine rettigheter til å klage på sensurvedtaket på den måten UiO tar i mot slike klager; via Studentweb.
Tror du endringen får konsekvenser for andre institusjoner?
Samme som for UiO
Ønske 4/2023 Politiattestbestilling: endring i krav over tid
Ønsket av Studieavdelingen. Sendt Sikt på deres nettskjema 16.08.2023. Sikt RT#369011.
Status fra Sikt 28.09.2023: "Det vil dessverre ikke bli prioritert å utføre dette i nåværende løsning (FS-klienten + Studentweb), men studentportal-teamet har opprettet utviklingssak, og vi har krysslenket internt, slik at behovet/ønsket tas vare på og blir vurdert i ny studentportal-løsning."
Januar 2024: Det teologiske fakultet (TF) på UiO har løst punkt 2 internt, se UiO RT#5868475.
Hvilken del av FS gjelder ønsket for?
FS-klienten og Studentweb
Behovet som skal dekkes og problemet som skal løses
1. Krav om politiattest kan endre seg ut over i studentens studieløp på samme studieprogram, avhengig av hvor de ulike studentene skal ha praksis. På UiO har vi per i dag behovet for en løsning på teologi og på farmasi. Det vil si at enkelte av studentene senere i studieløpet vil trenge en ny og strengere attesttype enn de hadde krav om å levere ved opptak. Ole Ivar Birkelunds [OsloMet] forslag om å kunne tilordne et krav om lisens til enkeltstudenter kunne dekke behovene godt nok.
2. På UiO har vi ytterligere et udekket behov knyttet til politiattestbestilling i Studentweb. Krav til hvilken politiattest studentene må levere har endret seg på enkelte programmer. Til og med 2020 var det eksempelvis på det seksårige programmet i teologi krav om lisenstypen PKHT, mens det fra og med 2021 bare er krav om PTEO ved opptak. Disse ulike kravene, avhengig av hvilket kull studentene er på, medfører at vi ikke kan aktivere bestilling av politiattest via Studentweb på teologistudiet, fordi hvis vi aktiverer (setter J) på begge kravene, både PKHT og PTEO, vil samtlige studenter på programmet se krav i Studentweb om begge attester. Det er jo ikke riktig. Dersom vi aktiverer kun for den ene lisenstypen, vil de som har krav om en annen type for det første ikke se det kravet, og for det andre se krav om en lisenstype som ikke er sann for dem.
Løsningsforslag
1. Ole Ivar Birkelunds på OsloMet foreslo i Sikts nasjonale FS Forum i Teams i 2023 å kunne tilordne et krav om lisens til enkeltstudenter. For UiO vil dette kunne dekke behovene godt nok for de som får et strengere krav om politiattest ut over i studieløpet.
2. Vi tenker at behovet rundt ulike krav til politiattest på ulike kull primært burde løses med felter for kull fra-til i bildet Lisens- /attest-type for studieprogram i FS, og med effekt ut i Studentweb. Slike fra-til-felter er an vanlig måte å håndtere ulike krav på, og medfører mindre grad av oppfølging på hver enkelt student. På den annen side tenker vi at endringer av krav om hvilken type politiattest som blir krevet er ganske uvanlig. Vi vet ikke hvordan denne situasjonen er på andre institusjoner og studieprogrammer, om det skjer aldri, innimellom eller ofte. Hvis vi antar at slik endring av krav er uvanlig, tenker vi at det kan være i meste laget med felt for kullavgrensning i bildet Lisens- /attest-type for studieprogram. Da tenker vi at det å kunne tilordne krav om lisens til enkeltstudenter, slik som beskrevet over, kunne dekke behovet godt nok, dvs. hvis man på enkeltstudenter kunne angi at det *ikke* er krav om en bestemt attesttype for enkeltstudenter, selv om de andre på studieprogrammet må levere den typen. Et konkret eksempel: Vi kunne aktivere bestilling av lisenstypen PTEO via Studentweb på teologiprogrammet CANDTHEOL6, dersom vi hadde muligheten til å angi på de studentene som har levert lisenstypen PKHT (dvs. de på kull 2020 og tidligere), at det ikke er krav om at de leverer lisenstypen PTEO, og slik at studentene ikke ser krav om PTEO i Studentweb. En slik manuell engangsoppdatering er overkommelig på studieprogram med få studenter.
Hvor viktig er endringen for UiO?
Viktig
Hvilken verdi/gevinst vil endringen ha for UiO?
Vi vil kunne ta i bruk bestilling av politiattest i Studentweb på alle programmer med slike krav, og samtidig håndtere individuelle unntak eller endringer i hvilke krav til politiattest som stilles.
Tror du endringen får konsekvenser for andre institusjoner?
Ja, vil være nyttig også for andre i tilsvarende situasjoner.
Ønske 5/2023 FS522.004 Oppgaverapport - kull. Ønsker studentnr. og studieretning
Ønsket av medfak i RT#5697833, støttet av Studieavdelingen. Sendt Sikt på deres nettskjema 19.09.2023, Sikt RT#374291.
Løst i FS9.2.0.1 i september/oktober 2023.
Hvilken del av FS gjelder endringsønsket for?
FS-klienten
Behovet som skal dekkes og problemet som skal løses
1. Vi bruker rapport FS522.004 til å få en oversikt over status for masteroppgaver og til å kunne slå opp studenter vil se nærmere på. Rapporten har bare Vis-valg for fødselsnummer eller uten nummer. Det er ugreit personvernmessig at rapporten ikke har annet Vis-valg enn fødselsnummer og og upraktisk dersom vi enkelt vil slå opp en av studentene. Alle FS-rapporter burde ha Vis-valg også uten fødselsnummer, men med det annet nummer på studenten.
2. Mange av masterstudieprogrammene på UiO har ulike studieretninger. Vi trenger da jevnlig å kunne ta ut lister og holde oversikt over oppgavetitlene fordelt på studieretning.
Løsningsforslag
1. Vis-valg for studentnummer i FS522.004.
2. Mulighet til å hente ut kun én studieretning i tillegg til studieprogram, kull og klasse eller mulighet til å sortere rapporten på studieretning.
Hvor viktig er endringen for UiO?
Litt viktig
Hvilken verdi/gevinst vil endringen ha for UiO?
Enklere å holde orden og oversikt over masteroppgaver.
Tror du endringen får konsekvenser for andre institusjoner?
Ingen negative, samme positive som for UiO
Ønske 6/2023 FS474.004 Oppmøteprotokoll: Uten e-postadresse
Ønsket av UV i RT#5728718, 2. oktober 2023.
Behov og løsningsforslag
Ønsker at man skal kunne huke av for at studentens e-postadresse ikke skal bli med (Under «Vis») i rapport 474.004 Oppmøteprotokoll, eller en funksjon filtrere bort e-post.
Vurdering i studieavdelingen (SADM)
SADM har ikke tatt stilling til ønsket ennå, da det kom inn for sent før møtet i FS-nettverket 9. oktober 2023.
Ønske 7/2023 FS270.001 Utvekslingspersoner: Vis-valg for studieretning
Ønsket av SV i RT#5804286, støttet av Studieavdelingen. Sendt Sikt på deres nettskjema ref. 29542570 20.11.2023, Sikt RT#383095.
Løst. Kommer i FS9.2.4.0.
Hvilken del av FS gjelder endringsønsket for?
FS-klienten
Behovet som skal dekkes og problemet som skal løses
Mange av programmene på UiO har ulike studieretninger. Vi trenger jevnlig å kunne ta ut lister og holde detaljert oversikt over hvor studentene drar på utveksling fordelt på studieretning.
Løsningsforslag
Vis-valg for studieretning i FS270.001 Utvekslingsperson.
Hvor viktig er endringen for UiO?
Litt viktig
Hvilken verdi/gevinst vil endringen ha for UiO?
Enklere å holde orden og rask oversikt over utveksling.
Tror du endringen får konsekvenser for andre institusjoner?
Ingen negative, samme positive som for UiO.
Ønske 8/2023 Søknad samlebilde: 'Vis kun fullførte søknader'. UTEN hake som default.
Ønsket av Studieavdelingen 27.11.2023 i Sikt RT#384155 (Nettskjemaref. 29674429)-
Status: Løst i FS9.2.4.0 i januar 2024.
Grunnen til at default-en var blitt som den var før FS9.2.4.0 går fram av kommentarer i Sikts Jira-sak FS-670 som enkelte i SADM har tilgang til. Tilsvarende funksjon ble først laget for Kursdeltagelse samlebilde (hvor default avhuking var spesifikt ønsket), og siden ble samme funksjon med samme default implementert i Søknad samlebilde. Slik Sikt forstår det er det behov for motsatte deafulter i de to bildene.
Hvilken del av FS gjelder endringsønsket for?
FS-klienten
Behovet som skal dekkes og problemet som skal løses
I dag har feltet 'Vis kun fullførte søknader' i Søknad samlebilde hake som default når man åpner bildet. Det er uheldig. At default er med hake medfører at kun fullførte saker vises, og det skaper ugreie for saksbehandlere på ulike steder på UiO, og ikke minst de på fakultetene som saksbehandler søkere for det selvfinansierte master-opptaket (SFM). Opprinnelig ønsket de som jobber med ph.d.-opptak at haken skulle være på som default, men de har erfart at det ikke var lurt. Til sammenlikning er det ikke hake som default på opptak med obligatorisk dokumenttype.
Defaulthaken på 'Vis kun fullførte søknader' fører til at søknader går under radaren og ikke blir behandlet. I SFM må vi behandle alle søknader uavhengig av om søknaden er "fullført" og vi har ikke anledning til å se bort fra dem som ikke er det.
Løsningsforslag
At det IKKE er hake på 'Vis kun fullførte søknader' som default.
Vi mener også at det ikke er en løsning av FS husker hvilken hake saksbehandleren hadde på forrige gang de brukte bildet. Flere saksbehandlere jobber med flere ulike typer opptak, og hvilken hake som passer best, vil kunne variere fra dag til dag.
Hvor viktig er endringen for UiO?
Viktig
Hvilken verdi/gevinst vil endringen ha for UiO?
Vi vi redusere risikoen for å overse søknader om opptak.
Tror du endringen får konsekvenser for andre institusjoner?
UiO har en robotisert prosess (RPA) knyttet til dette feltet for ph.d.-opptaket. Det kan hende andre andre institusjoner også har RPA-prosesser. På UiO vil det være enkelt å justere RPA-en og ta høyde for at det ikke er hake på 'Vis kun fullførte søknader'.
UiO la ut et spørsmål i FS Forum om denne haken, i kanalen Opptak 21.11.2023. Per 27.11.2023 har seks institusjoner vist at de er positive til endringen, og ingen har meldt at de er negative.