1. Innhold. Spesifikasjon Eksport fra FS til Fronter. Spesifikasjon - Eksport fra FS til Fronter

Transkript

1 Spesifikasjon - Eksport fra FS til Fronter 1. Innhold 1. Innledning Overføring av data til Fronter Struktur i Fronter etter eksport Navnsetting på de ulike org.enhetene og rom i Fronter Eksempel på struktur for importerte korridorer og rom Eksempel på struktur for importerte noder og grupper STUDENTER ANSATTE Ekstra Fronterrettigheter: Kontaktlærer- og faglærerrettighet Roller IMS informasjon for data som kan overføres til Fronter Personopplysninger Gruppeopplysninger IMS opplysninger om ulike Medlemsskap i Fronter Hva skal eksporteres fra FS

2 1. Innledning Dagens FS eksport til Fronter, ble laget for mange år siden, og både institusjonene selv og Fronter ser at det må gjøres en oppdatering av denne eksporten for å få en mer helhetlig eksport, og lik struktur for alle institusjoner i Fronter. I dag er det slik at hver enkelt institusjon setter opp eksporten på sine måte, og det er ulike praksis fra institusjon til instiusjon i forhold til hvordan man håndterer denne eksporten. Sett fra Fronters og institusjonenes side, vil hovedmål for ny FS-eksport være: At selve overføringen av dataene fra FS til Fronter gjøres enklere og likt for alle institusjoner. At alle institusjoner får lik struktur i Fronter. At det skal være mulig å detaljstyre hva og når elementer (ulike grupper og rom) skal bli eksportert. Noen institusjoner ønsker at overføringen fra FS skal skje via Bas et (eks. Cerebrum). For disse institusjonene gjelder de samme anbefalingene som for de som ønsker å benytte seg av FS-eksporten direkte. For å få til alle ønskene, vil det også kreve noe utvikling i selve FS-applikasjonen. Her må FS være tydlig på å sette opp en liste som institusjonene må være med å prioritere hvis det mot formodning ikke er mulig å få til alt til semesterstart høst Spesifiksjonen blir litt mye tilpasset direkte mot Fronter, men dette er for at institusjonene som er svært avanserte i bruk av Fronter, skal få en enda bedre integrasjon mellom FS og Fronter. Basisfunksjonaliteten i eksporten kan trolig benyttes mot andre LMS. 2. Overføring av data til Fronter Fronter har laget en egen webservice som skal benyttes for overføre data til Fronter. Hver enkelt institusjon får hver sin (authkey/unik url), som dataene skal sendes til. Fronter har en en WIN-klient til å overføre dataene direkte, men vi kan også tilby kildekode for en java og php-applikasjon, som andre kunder av Fronter har laget til det samme formålet. Hvis hver enkelt institusjon kan styre når eksporten skal kjøres, vil man få mulighet til å starte importen manuelt i Fronter. 2

3 3. Struktur i Fronter etter eksport 3.1 Navnsetting på de ulike org.enhetene og rom i Fronter Så langt det lar seg gjøre, bør det være en felles navnsetting for alle org.enheter og rom på tvers av institusjonene. I og med at hver enkelt institusjon har ulike roller, vil disse kunne være annerledes. Alle titler bør være så korte som det er praktisk mulig, men det er viktig at man enkelt finner det man leter etter ved enkle søk Navn på studieprogramrom <STUDIEPROGRAMKODE> studieprogramrom Navn på kullrom <STUDIEPROGRAMKODE> kullrom ( <ARSTALL> <TERMINKODE> ) Det kan være aktuelt å skille studieprogramkoden fra resten ved å legge de to siste elementene i en parentes. Se eksempel Navn på klasserom <STUDIEPROGRAMKODE> klasserom: (<ARSTALL><TERMINKODE><KLASSEKODE> ) Navn på emneinstansrom <EMNEKODE> ( <VERSJONSKODE><TERMINNR><ARSTALL><TERMINKODE> ) Navn på rom for undervisningsaktivitet <EMNEKODE> ( <VERSJONSKODE><TERMINNR><ARSTALL><TERMINKODE> <AKTIVITETSKODE> ) Navn på studieprogramgrupper <STUDIEPROGRAMKODE> studenter <STUDIEPROGRAMKODE> Studieledere for <STUDIEPROGRAMKODE> Studiekonsulenter for Navn på kullgrupper Studenter på <STUDIEPROGRAMKODE> kull <ARSTALL> <TERMINKODE> Navn på klassegrupper Studenter i <STUDIEPROGRAMKODE> <ARSTALL> <TERMINKODE> klasse <KLASSEKODE> Navn på emneinstansgrupper Studenter på <EMNEKODE> <VERSJONSKODE> <TERMINNR> <ARSTALL> <TERMINKODE> Navn på aktivitetsbaserte grupper Studenter på <EMNEKODE> <VERSJONSKODE> <TERMINNR> <ARSTALL> <TERMINKODE> <AKTIVITETSKODE> 3

4 3.2 Eksempel på struktur for importerte korridorer og rom <Institusjon> / 05 Importerte rom <Fakultet (Avdeling)> < Fakultet (Avdeling)> studieprogramrom <studieprogramkode> studieprogramrom <studieprogramkode> fellesrom <studieprogramkode> kull <arstall><terminkode> kullrom <studieprogramkode> kull <arstall><terminkode> klasse <klassekode> klasserom <Institutt> <Institutt> studieprogramrom <studieprogramkode> studieprogramrom <studieprogramkode> fellesrom <studieprogramkode> kull <arstall><terminkode> kullrom <studieprogramkode> kull <arstall><terminkode> klasse <klassekode> klasserom <studieprogramkode> studieprogramrom <studieprogramkode> fellesrom <studieprogramkode> kull <arstall><terminkode> kullrom <studieprogramkode> kull <arstall><terminkode> klasse <klassekode> klasserom <Institutt> emnerom <arstall><terminkode> <emnekode><versjonskode><terminnr><arstall><terminkode> <emnekode><versjonskode><terminnr><arstall><terminkode><aktivitetskode> <Institutt> vurderingsrom <arstall><terminkode> <emnekode><versjonskode><arstall_reell><vurdtidkode_reell><vurdstatuskode> <Institutt> EVU-rom <etterutdkurskode><kurstidsangivelsekode> Bold svart tekst = NODE Blå tekst = korridor Vanlig svart tekst = ROM Kommentarer fra UiA (Tore Junker): Siden spesifikasjonen forutsetter at det meste blir lagt på instituttnivå, må FS angi hvilke felt i FS som skal bestemme hvilket institutt emnerom, vurderingsrom og EVU-rom skal knyttes til. For studieprogram må dette være stedkoden i feltet for Studieansvarlig sted. For emner og vurdering finnes det to alternative stedkoder, Adm ansv (kontr) og Studieansv (regl). Vi benytter i dag konsekvent Adm ansv (kontr), men det er ikke sikkert at alle gjør det. For EVU finnes det også to stedkodefelt, Fagansvarlig og Admin-ansvarlig. Vi har i dag et subtre for all EVU ved UiA, men for oss ville det være naturlig å benytte stedkoden i Fagansvarlig for å fordele EVU-rommene på institutt. 4

5 3.3 Eksempel på struktur for importerte noder og grupper STUDENTER Kommentar fra UiA Når det gjelder studentdefinisjonen, bør vi, som flere allerede har nevnt i tidligere kommentarer, benytte verdien i feltet <status_aktiv_student> i studentstatustabellen for å bestemme om en student skal eksporteres eller ikke. Da kan vi benytte felles utplukksregler samtidig som den enkelte institusjon kan tilpasse statusbruken etter egne behov. Det eneste praktiske alternativet for programstudenter er å bruke studentens studierett for å koble vedkommende til fakultet/institutt. Siden noen studenter kan ha aktive studieretter på flere program samtidig, kan en og samme student få kobling til flere fakultet/institutt. Studenter som bare tar enkeltemner (har ikke studierett på program der emnet inngår) og privatister vil i disse rollene ikke ha studierett på et vanlig program. Noe tilsvarende kan vel også gjelde de som tar en selvvalgt bachelor. Ved UiA er studenter i disse gruppene i FS registrert som studenter på egne, administrative program for å gi dem en programtilknytning. Slike programmer har vanligvis stedkoden for hele institusjonen. Disse studentene bør ikke nødvendigvis være med i studentgrupper på samme måte som de ordinære programstudentene, men dersom de er registrert som en slags programstudent, trenger vi regler som gjør at vi kan utelukke dem. Det skal være mulig for hver enkelt institusjon å velge om vurderingsgrupper skal tas i bruk. Hvis det ikke skal tas i bruk, må det være mulig å knytte til et emne. <Institusjon> / 06 Importerte grupper Alle ansatte ved <Institusjon> Alle studenter ved <Institusjon> Alle kursdeltakere ved <Institusjon> <Institusjon>/ 06 Importerte grupper <Fakultet (Avdeling )> Alle ansatte ved <Fakultet(Avdeling)> Alle studenter ved <Fakultet(Avdeling)> <Institutt> Studentgrupper Alle studenter ved <instituttnavn> <Institusjon> / 06 Importerte grupper / <Fakultet (Avdeling ) > / <Institutt >/ Studentgrupper Emnegrupper <semester år> Studenter <semester år> <EMNEKODE><VERSJONSKODE><TERMINNR> emne <ARSTALL><TERMINKODE> studenter Studenter <underv.aktivitet> <semester år> <EMNEKODE><VERSJONSKODE><TERMINNR> emne <ARSTALL><TERMINKODE> aktivitet <AKTIVITETSKODE> studenter 5

6 <Institusjon> / 06 Importerte grupper / <Fakultet (Avdeling ) > / <Institutt >/ Studentgrupper Studieprogramgrupper <studieprogramkode> <studieprogramkode> alle studenter <studieprogramkode> kull <arstall><terminkode> studenter ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: <studieprogramkode> kull <arstall><terminkode> klasse <klassekode> studenter <studieprogramkode> Vurderingsgrupper studenter <emnekode><versjonskode><arstall_reell><vurdtidkode_reell><vurdstatuskode> studenter EVU Kursdeltakere Kursdeltakere <kurskode> <tidskode> Bold svart tekst = NODE Brun vanlig tekst= GRUPPE 6

7 3.3.2 ANSATTE <Institusjon> / 06 Importerte grupper / <Fakultet (Avdeling ) > / <Institutt >/ Ansattgrupper Alle ansatte ved <instituttnavn> Emnegrupper ansatte Emnegrupper ansatte <årstall><terminkode> <emnekode><versjonskode><arstall><terminkode> ansattgrupper <alle ansattgrupper for dette emnet for denne terminen> Studieprogramgrupper ansatte <studieprogramkode> ansattgrupper <alle ansattgrupper for dette studieprogrammet> <studieprogramkode> ansattgrupper <alle ansattgrupper for dette studieprogrammet> Vurderingsgrupper ansatte <emnekode><versjonskode><arstall_reell><vurdtidkode_reell><vurdstatuskode> ansatte EVU-grupper ansatte <kurskode><tidskode> ansattgrupper alle ansattgrupper for dette kurset Bold svart tekst = NODE Brun vanlig tekst= GRUPPE * Alle roller må gjensspeile de rollene som er definert i FS ved egen institusjon. Navnestruktur for de ulike rollegruppene: <studieprogramkode> rollegruppe <rollekode> <studieprogramkode> kull <arstall><terminkode> rollegruppe <rollekode> <studieprogramkode> kull <arstall><terminkode> klasse <klassekode> rollegruppe <rollekode> <emnekode><versjonskode><terminnr><arstall><terminkode> rollegruppe <rollekode> <kurskode><tidskode> rollegruppe <rollekode> 7

8 3.4 Ekstra Fronterrettigheter: Kontaktlærer- og faglærerrettighet De ulike lærergruppene på emner må få rettigheten Faglærer i Fronter på sine respektive emner/aktiviteter REF: IMS.membership.role.extension.groupaccess.contactAccess= 170. De ulike lærergruppene på studieprogram/klasser/kull skal ha kontaktlærerrettighet i Fronter på sine respektive studentgrupper. REF: IMS.membership.role.extension.groupaccess.contactAccess= 160. NB: Nøyaktig hvilke lærergrupper skal ha faglærerrettigheten i Fronter, må defineres nærmere. Disse rettighetene benyttes først og fremst i dag til Fravær og IUP, men i fremtiden kan de også bli brukt for å kunne se portefølje på tvers av rom. 8

9 4. Roller De ulike rollene i FS angir hvilke rettighet grupper skal få i rom i Fronter. Eksempel fra UiT: Rollekode Rollenavn Rollenavn-publisering Ims - rollekode Rettighet i Fronter Groupaccess (Emne) Groupaccess (ST.prog) ANSVLEDER Ansvarlig leder Ansv. leder 06 Slette ASSISTENT Studentassistent Studentassistent 06 Slette DLO DLO - Digital lokal Digital lokal 06 Slette administrator administrator FAGANSVARL Fag/Kursansvarlig Fag/Kursansvarlig 06 Slette FORELESER Foreleser Foreleser 06 Slette GJESTEFORE Gjesteforeleser Gjesteforeleser 06 Slette 170 GRUPPELÆRE Gruppelærer Gruppelærer 06 Slette HOVEDLÆRER Hovedlærer Hovedlærer 07 Eier KONTAKT Kontaktperson Kontaktperson 07 Eier KURSANSV Kursansvarlig Kursansvarlig 06 Slette LÆRER Lærer Lærer 06 Slette SENSOR Sensor Sensor STUDIEKONS Studiekonsulent Studiekonsulent 05 Skrive VEILEDER Veileder Veileder 06 Slette Det er opp til hver enkelt institusjon å angi navn og rettighet på de ulike rollene. Eksemplet på rettighet kan være standard for alle institusjoner, men det må være mulig å tilpasse hver enkelt rolle. Det må være opp til hver enkelt institusjon å angi hvilke rettigheter de ulike rollene skal få i rom i Fronter. Alle studentgrupper skal ha skrive -rettighet i rom som standard (IMS Rollekode=05). Mapping IMS roller Fronter roller IMS roller Rettighet i Fronter 01 = Learner Read 02 = Instructor write 03 = Content Developer delete 04 = Member read 05 = Manager write 06 = Mentor delete 07 = Adminstrator owner 9

10 5. IMS informasjon for data som kan overføres til Fronter 5.1 Personopplysninger Enkelte felter for visning av personinformasjon, krever aktiv samtykke fra student. Eks. Mobil og Bilde. Det foreslås at dette gjøres tilgjengelig via StudentWeb. Alle felter unntatt obligatoriske felter må være valgfritt hos hver enkelt institusjon. Personinformasjon IMS attributt i Person-object Oblig. FS + institusjon IMS. person.sourcedid.source Personnummer IMS.person.sourcedid.id Ja Brukernavn IMS.person.userid Ja Passord Ved ldap-autentisering eller FEIDE autentisering: Ja IMS.person.userid.password= ldap1: pwencryptiontype="5" Ved vanlig autentisering: IMS.userid.password= ET PASSORD pwencryptiontype="4" Fullt Navn IMS.person.Name.fn Ja Etternavn IMS.person.N.family Ja Fornavn IMS.person.N.given Ja E-post IMS.person. Adresse IMS.person.adr Telefon 1 IMS.person.Teltype= 1 Mobiltelefon IMS.person.Teltype= 3 Bilde IMS.person.photo Kull for studenter IMS.person.extension.organization Avdeling /Fakultet IMS.person.extension.location Epostkontoinnstillinger IMS.person.extension. settings Epostkonto - IMS.person.extension. settings.mail_username brukernavn Epostkonto - passord IMS.person.extension. settings.mail_password= FRONTERLOGIN Epostkonto - IMS.person.extension. settings.description= Min e-post Beskrivelse Epostkonto - IMS.person.extension. settings.mailserver mailserver Epostkonto - mailtype IMS.person.extension. settings.mailtype= imap Epostkonto - serverdir IMS.person.extension. settings.imap_serverdirectory=.INBOX Epostkonto mappe IMS.person.extension. settings.imap_sentfolder= Sent items for sendte elementer Epostkonto mappe IMS.person.extension. settings.imap_draftfolder= Draft for kladd Epostkonto mappe IMS.person.extension. settings.imap_trashfolder= Trash for søppel Epostkonto - SSL IMS.person.extension. settings.use_ssl (0 1) "0" Rolle IMS.person.institutionrole (Staff/Student) Ja 10

11 5.2 Gruppeopplysninger Gruppe informasjon FS + <institusjon> ID på gruppen, noden, korridor eller rom Tittel Beskrivelse Definere om det er en node, gruppe, korridor eller rom Hvilken gruppe som er foreldrenode IMS attributt i Group IMS. group.sourcedid.source IMS.group.sourcedid.id IMS.group.description.short IMS.group.description.long Group.typevalue.level= 0 Node Group.typevalue.level= 1 Korridor Group.typevalue.level= 2 Gruppe Group.typevalue.level= 4 Rom IMS.group.relationship 5.3 IMS opplysninger om ulike Medlemsskap i Fronter Medlemsskapsinformasjon FS + <institusjon> ID på gruppen eller rom ID på personen som skal meldes inn i gruppen Id en på gruppen som skal meldes inn i et rom. Id en på gruppen som skal ha groupaccessrettighet 160/170 på gruppen. Angi om IMS. membership.sourcedid.id er en gruppe eller rom. Angi kontaktlærer-/faglærerrettighet for spesifikke grupper IMS attributt i Membership IMS. membership.sourcedid.source IMS. membership.sourcedid.id IMS. membership.member.sourcedid.id IMS. membership.member.idtype IMS. membership.member.role.extension.groupaccess Verktøylister til rom i Fronter trenger man ikke lengre å definere i FS, da dette kan spesifiseres pr. org.enhet i Fronter. 11

12 6. Hva skal eksporteres fra FS A) På overordnet nivå må det være mulig å bestemme om alle studieprogram/klasser/kull/emner og Evu skal bli eksportert. Dette bør styres av et eget oppsett for hver institusjon. B) På et underordnet nivå må det være mulig å definere i detalj hvilket studieprogram/emne/kull eller klasser samt Evu(kurs) som skal bli eksportert. Dette bør styres via felt i FS. Det er i dag et felt for eksport til LMS for de fleste objektene. Det bør være mulig å få til for samtlige felt. C) Det må være mulig å definere hvilke rom som skal opprettes på hvert enkelt undernivå. F.eks skal man kunne opprette klasserom, uten at kullrom opprettes. Siden behovet for rom vil kunne variere innenfor den enkelte institusjon, bør dette styres vha egne felt i FS. I og med at verktøylister ikke lengre er nødvendig å registrere i FS, kan feltet istedenfor benyttes til om rom skal opprettes eller ikke. D) Det må være mulig å tidsstyre når grupper/rom skal eksporteres. Både start og slutt for et kurs må kunne angis. Den enkelte institusjon bør i importoppsettet kunne bestemme hvilke terminer det skal plukkes fra. Ellers bør felt i FS for de ulike objektene benyttes for å styre dette på rom-/gruppenivå. E) Det må være mulig å eksportere flere terminer samtidig, og bestemme eksportdato for de ulike terminene. F.eks må det være mulig å eksportere både inneværende semester og neste semester. Dette bør den enkelte institusjon kunne angi i eget importoppsett. F) Det må være mulig å definere hvilke personopplysninger som skal eksporteres. Se 5.1 for mer informasjon. G) Eksporten må ivareta at enkelte studenter kan beskytte seg mot at informasjon blir eksportert. Til og med opptre som et alias i Fronter. Som allerede nevnt under pkt. 5.2, bør dette håndteres via StudentWeb/FS og da fortrinnsvis som aktivt og positivt samtykke og ikke som reservasjon. Eventuelle alias bør ikke opprettes direkte i Fronter, men komme fra et autoritativt kildesystem. H) Bilder for studenter må være mulig å overføre. Det må være mulig å reservere seg mot at bilder blir eksportert, evt. at det bør være aktiv samtykke. Hvis informasjon av bilde eller kontaktopplysninger blir reservert av en student i etterkant må dette overstyre det som ligger i Fronter. 12