Fronter ved HiØf

Introduksjon

Dette dokumentet spesifiserer detaljene rundt Fronter (CF) ved Høgskolen i Østfold (HiØf). Spesifikasjonen skal være godkjent av begge sider slik at vi unngår misforståelser rundt leveransen. Dokumentet inneholder tekniske detaljer hva Cerebrum angår for å støtte den ønskede funksjonaliteten.

Generelt ønsker HiØf et opplegg som ligner på Cerebrum-CF-installasjonen hos Universitetet i Agder (UiA). Imidlertid er det en del forskjeller som legger visse føringer for implementasjonen, slik at kodebasen for UiA ikke kan gjenbrukes hos HiØf.

I grove trekk foregår eksporten av data slik: det registreres all studierelatert informasjon i FS (FSHIOF.uio.no). Cerebrum plukker ut de interessante data og lagrer disse i en rekke filer. Deretter går det egen jobb som lager grupper i Cerebrum hvis navn og medlemskap gjenspeiler til en viss grad strukturen som skal bygges i Fronter. Deretter går det nok en jobb som på bakgrunn av disse gruppene og datafilene fra FS genererer en XML-fil til import til CF. Filen kopieres på en passende CF-maskin. Der avsluttes ansvarsområdet til Cerebrum. Denne XML-filen importeres så i CF-instansen for HiØf/Oslofjordalliansen.

Utplukket fra FS

Det plukkes ut alle undenh, undakt og stprog som har status_eksport_lms = 'J'. Videre, gitt et stprog som skal eksporteres videre, plukker vi med alle aktive kull og alle klasser under det studieprogrammet.

Dersom en undakt har status_eksport_lms = 'J', mens en undenh har status_eksport_lms = 'N', rapporteres situasjonen som en feil (hverken undenh eller undakt skal da eksporteres til CF). Imidlertid har HiØf veldig veldig få undakt, så dette blir neppe et problem i praksis.

HiØf bruker ikke EVU-modulen, og deres kompetanseutbyggingssenter (tilsvarende EVU) sidestilles med "vanlige" undneh/avdelinger.

Vi plukker ut entiteter fra FS for nåværende og neste semester, der slikt er mulig (f.eks. vi plukker alle kull for et gitt stprog, selv om årstallet for kullet skulle være 1856).

Rollene fra FS

Det plukkes følgende roller i FS: ASSISTENT, HOVEDLÆRER, KURSANV, LÆRER, KONTAKT, VEILEDER.

Alle andre roller fra FS ignoreres (stille).

Gruppene i Cerebrum

For hver rolle som tildeles ved emner, undenh, undakt, stprog, kull, klasse, bygges det en gruppe med identifikatoren for den aktuelle entiteten og rollekoden. I tillegg bygges det grupper med studenter for undenh/undakt/klasser. Disse tilsammen brukes så for å bygge alle de nødvendige CF-strukturene.

Legg merke til at gruppene bygges kun når det faktisk er noen medlemmer der (derimot kan det hende at en gruppe fortsetter å eksisterere i Cerebrum med noe utdatert medlemsmasse, /dersom/ datagrunnlaget i FS for denne gruppen uteblir). Generering av XML-filen baserer seg på disse gruppene, men KUN de gruppene som har en spesifikk trait, og det kan gjerne finnes CF-grupper i Cerebrum uten slike traits.

Gruppene i Cerebrum blir dermed:

• Navn: Studenter ved <undenh> (<terminkode> <år>, versjon <versjon>, <terminnr>. termin)

  ID: "hiof.no:fs:224:<avdeling>:emner:<år>:<sem>:undenh:<emnekode>:<versjon>:<terminnr>:student"

  Eksempel:

  
  

  Navn: "Studenter ved IRB25008 (vår 2009, versjon 1, 1. termin)

  ID: "hiof.no:fs:224:500000:emner:2009:vår:undenh:irb25008:1:1:student"

  
  

  Her foregår den samme tilbakedateringen av terminnummer for

  flersemesteremner slik beskreves i CF-struktur.

  
  

  Denne gruppen inneholder alle studenter meldt til undervisning.

• Navn: Studenter ved <undakt> (<terminkode> <år>, versjon <versjon>, <terminnr>. termin), aktivitet <aktkode>

  ID: "hiof.no:fs:224:<avdeling>:emner:<år>:<sem>:undakt:<emnekode>:<versjon>:<terminnr>:<aktkode>:student"

  Eksempel:

  
  

  Navn: Studenter ved HSS40505 (vår 2008, versjon 1, 1. termin),

  aktivitet 0

  ID:

  "hiof.no:fs:224:400000:emner:2008:vår:undakt:HSS40505:1:1:0:student"

  
  

  For flersemesteremner gjelder de samme reglene som for <undenh>-studentgruppene.

• Navn: Studenter på <stprog> <terminkode> <arstall>

  ID:

  "hiof.no:fs:224:<avdeling>:studieprogram:<stprog>:kull:<arstall>:<terminkode>:student"

  Eksempel:

  
  

  Navn: Studenter på PPU høst 1997

  ID: "hiof.no:fs:224:300000:studieprogram:ppu:kull:1997:høst:student"

  
  

  Dette skal være gruppen med alle studentene på et gitt kull. Slik FS

  er lagt opp skal det ikke kunne finnes studenter som er med i en

  kullklasse, men ikke finnes i det tilsvarende kullet (det omvendte er

  dog så meget mulig).

• Navn: Studenter på <stprog> <terminkode> <arstall>, klasse <klasse>

  ID:

  "hiof.no:fs:224:<avdeling>:studieprogram:<stprog>:kull:<arstall>:<terminkode>:klasse:<klasse>:student"

  Eksempel:

  
  

  Navn: Studenter på PPU høst 1997, klasse Y

  ID:

  "hiof.no:fs:224:300000:studieprogram:ppu:kull:1997:høst:klasse:y:student"

• Navn: <Rolle> ved <stprog>

  ID: "hiof.no:fs:224:<avdeling>:studieprogram:<stprog>:rolle:<rolle>"

  Eksempel:

  
  

  Navn: ASSISTENT ved <EAVERDIBO1>

  ID: "hiof.no:fs:224:400000:studieprogram:eaverdibo1:rolle:assistent"

  
  

  Slike grupper inneholder alle fra fs.personrolle med den angitte

  rollekoden ved det gitte studieprogrammet.

• Navn: <Rolle> ved <stprog>, <sem> <år>

  ID: "hiof.no:fs:224:<avdeling>:studieprogram:<$stprog>:kull:<år>:<sem>:rolle:<rolle>"

  Eksempel:

  
  

  Navn: LÆRER ved <EAVERDIBO1>, vår 2009

  ID:

  "hiof.no:fs:224:500000:studieprogram:eaverdibo1:kull:2009:høst:rolle:lærer"

• Navn: <Rolle> for <klasse>, <kull>, <stprog>

  ID: "hiof.no:fs:224:<avdeling>:studieprogram:<$stprog>:kull:<år>:<sem>:klasse:<klassekode>:rolle:<rolle>"

  Eksempel:

  
  

  Navn: ASSISTENT for EAVERDIBO1 vår 2009, Klasse A

  ID:

  "hiof.no:fs:224:500000:studieprogram:eaverdibo1:kull:2009:høst:klasse:a:rolle:assistent"

• Navn: <Rolle> for <undenh> Navn: <Rolle> for <undakt>

  ID: "hiof.no:fs:224:<avdeling>:emner:<år>:<sem>:undenh:<emnekode>:<versjon>:<terminnr>:rolle:<rolle>"

  ID: "hiof.no:fs:224:<avdeling>:emner:<år>:<sem>:undakt:<emnekode>:<versjon>:<terminnr>:<aktkode>:rolle:<rolle>"

  Eksempel:

  
  

  Navn: Lærer for IRB25008 (ver 1, 1. termin)

  ID:

  "hiof.no:fs:224:500000:emner:2009:vår:undenh:irb25008:1:1:rolle:lærer"

  Navn: Lærer for IRB25008 (ver 1, 1. termin) aktivitet 0

  ID:

  "hiof.no:fs:224:500000:emner:2009:vår:undakt:irb25008:1:1:0:rolle:lærer"

I tillegg har vi en rekke grupper i Cerebrum som er ment til å gjenspeile de personene som til enhver tid skal være administratorne i CF. Disse gruppene vedlikeholdes manuelt av HiØf, mens Cerebrum sørger for å opprette selve gruppeentitetene i databasen. Medlemskap i disse gruppene betyr at vedkommende får en rolle av typen Admin i CF.

Gruppenavn blir på formen "hiof.no:fs:224:XX0000:rolle:admin", der XX er avdelingsnummeret. Admin-gruppene må følge denne malen for ID/Navngiving (spesielt ID) og må tildeles CF-spread. Da disse skal vedlikeholdes manuelt er det viktig at dette blir fulgt opp (ellers vil noen admins kunne falle utenfor).

Navn på samtlige grupper MÅ være strukturert på denne måten, siden veldig mye av logikken rundt oppbygging av CF-strukturene baserer seg på å kunne avlede informasjon fra navn. Dette er spesielt viktig å huske på ADMIN-gruppene

CF-struktur

Som nevnte tidligere er en del av komplikasjonen at det skal bygges et undertre som skal flettes inn i en eksisterende CF-struktur til Oslofjordalliansen.

HiØf sitt CF-subtre er også litt annerledes enn andre institusjoner - strukturene er basert på oppdeling under avdelinger:

Trond Akerbæk foreslo at merking av strukturer som korridorer og noder skulle skje som ved UiO. Mao:

• Grupper med brukere i merkes som grupper (typevalue level=2)
• Rom-strukturene (de med "ROOM" i id-en) merkes som rom (typevalue level=4)
• De statiske strukturene er noder (typevalue level=0). Dette er OA-noden, HiOf-noden, manuell og automatisk-nodene
• Strukturene som representerer avdelingene er noder (typevalue level=0)
• De resterende strukturer er korridorer (typevalue level=0).

Hele OA/HiØf-treet ser da slik ut:

1. Navn: "Oslofjordalliasen"

   ID: "root"

   Type: node
   Dette er den overordnede noden for CF-installasjonen for hele

   Oslofjordalliansen. De andre institusjonene er ikke interessante i

   dette tilfellet, kun HiØf-treet. Noden er statisk og skal alltid

   finnes i XML-filen levert av Cerebrum.

   1. Navn: "HiØ"

      ID: "STRUCTURE:hiof.no"

      Type: node
      Rotnoden for HiØf. Dette er en fast node hvor all informasjon om

      HiØf skal plasseres. Noden er statisk og skal alltid finnes i

      XML-filen levert av Cerebrum.

      1. Navn: "Manuell"

         ID: "STRUCTURE:hiof.no:manuell"

         Type: node
         Noden for manuelle ting HiØf måtte ønske å gjøre. I

         tilfellet HiØf ønsker å bygge opp noen strukturer unntatt

         automatikken, kan det gjøres her. Cerebrum gjør ingenting

         utover å lage denne noden i XML-filen. Noden er statisk og

         skal alltid finnes i XML-filen levert av Cerebrum.

      2. Navn: "Automatisk"

         ID: "STRUCTURE:hiof.no:automatisk"

         Type: node
         Dette er rotnoden for det treet som oppdateres automatisk av

         Cerebrum. Noden er statisk og skal alltid finnes i XML-filen

         levert av Cerebrum.

         1. Navn: $akronym

            ID: "STRUCTURE:hiof.no:fs:224:<avdeling>

            Type: node

            Eksempel:
            Navn: "IR"

            ID: "STRUCTURE:hiof.no:fs:224:500000"
            Disse strukturnodene skal opprettes for samtlige

            avdelinger til hiof. Det er relativt få av disse, så

            resultatet burde ikke være uoversiktlig.

            1. Navn: $stprog

               ID: "STRUCTURE:hiof.no:fs:224:<avdeling>:studieprogram:<$stprog>

               Type: korridor

               Eksempel:
               Navn: "EAVERDIBO1"

               ID: "STRUCTURE:hiof.no:fs:224:400000:studieprogram:eaverdibo1"
               Disse strukturnodene skal opprettes for samtlige

               stprog med status_eksport_lms = 'J' for den

               aktuelle avdelingen. For å finne den aktuelle

               avdelingen bruker vi

               fs.studieprogram.faknr_studieansv.

               1. Navn: Kull <stprog> <sem> <år>

                  ID: "STRUCTURE:hiof.no:fs:224:<avdeling>:studieprogram:<$stprog>:kull:<år>:<sem>

                  Type: korridor

                  Eksempel:
                  Navn: "Kull EAVERDIBO1 vår 2009"

                  ID: "STRUCTURE:hiof.no:fs:224:500000:studieprogram:eaverdibo1:kull:2009:høst"
                  Disse strukturnodene skal opprettes for

                  samtlige aktive kull under det gitte

                  studieprogrammet.

                  1. Navn: Rom for kull <stprog> <sem> <år>

                     ID: "ROOM:hiof.no:fs:224:<avdeling>:studieprogram:<$stprog>:kull:<år>:<sem>"

                     Type: rom

                     Eksempel:
                     Navn: Rom for kull EAVERDIBO1 vår 2009

                     ID: "ROOM:hiof.no:fs:224:500000:studieprogram:eaverdibo1:kull:2009:høst"
                     Fellesrom opprettes for alle aktive

                     kull, forutsatt at det er minst en

                     student ved kullet.

                  2. Navn: Rom for kull <stprog> <sem> <år>, klasse <klasse>

                     ID: "ROOM:hiof.no:fs:224:<avdeling>:studieprogram:<$stprog>:kull:<år>:<sem>:klasse:<klassekode>"

                     Type: rom

                     Eksempel:
                     Navn: Rom for kull EAVERDIBO1 vår 2009, klasse A

                     ID: "ROOM:hiof.no:fs:224:500000:studieprogram:eaverdibo1:kull:2009:høst:klasse:a"
                     Disse rom skal opprettes for samtlige

                     klasser i fs.kullklasse. Det er 1'378 av

                     disse.

I tillegg alle disse ClassFronter-strukturene, opprettes det en rekke grupper (type "group"). Gruppene skal fange opp studenter og rolleinnehavere ved forskjellige strukturer og brukes for å gi personer med en eller annen tilknytning til en CF-struktur forskjellige rettigheter ift. denne strukturen

Gruppene gis tilganger til strukturene over på følgende måte:

• studenter ved undenh får:

  • skrivetilgang til undenh sitt rom (ROOM:...:undenh:...)
  • viewContacts på seg selv

• studenter ved undakt får:

  • skrivetilgang til undakt sitt rom (ROOM:...:undakt:...)
  • viewContacts på seg selv

• studenter ved kull får:

  • skriverettighet til kullfellesrommet
  • viewContacts på seg selv.

• studenter ved kullklasser får:

  • skriverettighet i kullklasserommet
  • viewContacts på seg selv.

• <rolle> ved <undenh> får:

  • rettigheten X ved rommet for <undenh>
  • viewContacts på seg selv.
  • viewContacts på tilsvarende studentgruppe.
  • viewContacts på alle andre <rolle>-gruppene ved samme struktur

• <rolle> ved <undakt> får:

  • rettigheten X ved rommet for <undenh>
  • viewContacts på seg selv
  • viewContants på tilsvartende studentgruppe
  • viewContacts på alle andre <rolle>-gruppene ved samme struktur

• <rolle> ved <stprog> får:

  • Rettigheten X ved alle strukturer under korridoren for studieprogrammet og for korridoren selv.
  • viewContacts på seg selv.
  • viewContacts på alle andre <rolle>-gruppene ved samme struktur.

• <rolle> ved <kull> får:

  • Rettigheten X ved alle strukturer under korridoren for kullet og for korridoren selv.
  • viewContacts på seg selv.
  • viewContacts på alle andre <rolle>-gruppene ved samme struktur

• <rolle> ved <klasse> får:

  • Rettigheten X ved klasserommet.
  • viewContacts på seg selv.
  • viewContacts på tilsvarende studentgruppe.
  • viewContacts på alle andre <rolle>-gruppene ved samme struktur.

Når det gjelder rettigheten som tildeles over (altså, X), ser det slik ut:

der:

• R - Read
• W - Write (impliserer R)
• D - Delete (impliserer W)

Videre er det slik at alle grupper med rolleinnehavere ved <Z> har viewContacts på alle de andre grupper med rolleinnhavere ved <Z>.

HiØf har ytterligere den komplikasjonen at noen av rollene er rekursive. Dvs. en "ASSISTENT"-rolle gitt ved et <stprog> regnes som "ASSISTENT"-rolle gitt ved samtlige kull og kullklasser knyttet til det studieprogrammet. Derfor vil "ASSISTENT"-rolleinnehavere ha "viewContacts" ikke bare på seg selv og evt. studentgrupper, men også samtlige andre rolleinnehavere og det rekursivt der det gir mening.

For å eksemplifisere dette:

Gitt rollen "LÆRER" ved "STRUCTURE:hiof.no:fs:224:400000:studieprogram:eaverdibo1", så vil følgende tilganger gis:

• Gruppen "hiof.no:fs:224:400000:studieprogram:eaverdibo1:rolle:lærer" får "Write"-rettighet på korridoren "STRUCTURE:hiof.no:fs:224:400000:studieprogram:eaverdibo1"
• Gruppen "hiof.no:fs:224:400000:studieprogram:eaverdibo1:rolle:lærer" får "view Contacts" rettighet på seg selv.
• Gruppen "hiof.no:fs:224:400000:studieprogram:eaverdibo1:rolle:lærer" får "view Contacts" rettighet på samtlige andre grupper hvis id er på formen "hiof.no:fs:224:400000:studieprogram:eaverdibo1:rolle:<...>".
• Gruppen "hiof.no:fs:224:400000:studieprogram:eaverdibo1:rolle:lærer" får "Write"-rettighet på samtlige kullkorridorer (f.eks. "STRUCTURE:hiof.no:fs:224:500000:studieprogram:eaverdibo1:kull:2009:høst") og kullklasserom (f.eks. "ROOM:hiof.no:fs:224:500000:studieprogram:eaverdibo1:kull:2009:høst:klasse:a") som er knyttet til studieprogrammet "EAVERDIBO1".
• Gruppen "hiof.no:fs:224:400000:studieprogram:eaverdibo1:rolle:lærer" får "view Contacts"-rettighet på samtlige grupper på formen "hiof.no:fs:224:500000:studieprogram:eaverdibo1:kull:<...>:<...>:rolle:<...>" og på samtlige grupper på formen "hiof.no:fs:224:500000:studieprogram:eaverdibo1:kull:<...>:<...>:klasse:<...>:rolle:<...>" og på studentgruppen for samtlige kullklasser på formen "hiof.no:fs:224:500000:studieprogram:eaverdibo1:kull:<...>:<...>:klasse:<...>:student"

XML-filen

Formatet på XML-filen er ferdigspikret, og her forventes ingen endringer.

Vi garanterer ikke at det ikke finnes foroverreferanser hva grupper angår (dvs. et gruppemedlem til en gruppe kan komme i filen før foreldergruppen).

Et par forklaringer om hva de forskjellige elementene betyr i XML

• Alle grupper har et <typevalue>-element. 0 betegner node, 1 - korridor, 2 - gruppe (med folk i) og 4 - rom. Tildelingen av disse er beskrevet tidligere.

• Grupper med brukere kan gis "view Contacts"-rettigheter. Disse uttrykkes vha. <membership>. I dette tilfellet brukes <extension>-tag-en (IMS enterprise har ikke et opplegg "view Contacts" ellers):

  <extension>
    <groupaccess contactAccess="100" roomAccess="0"/>
  </extension>
  

  Betydningen av verdien er:

  • "100" til "199": "view contacts"
  • "200": "create contacts"
  • "250": "admin light" (lov til å gi 'allow login')
  • "300": "administrator"

<person recstatus="1">
<sourcedid>
 <source>hiof</source>
 <id>ivr</id>
</sourcedid>
<userid password="ldap1:" pwencryptiontype="5">ivr</userid>
<!-- ... -->
</person>

Testing

Testinstansen er litt fin å ha, og derfor har Fronter laget en til oss/hiof:

- URL: [33]https://fronter.com/oa_test - Brukernavn: root - Passord: ligger i cereprod-hiof:/cerebrum/etc/passwords/

(Vi kan endre passordet; husk dog å endre filinnholdet tilsvarende)

Testinstansen populeres herifra:

mgmt1.fronter.uio.no:/fronter/customers/integration/documents/data/oa_test/1884663333/579487866

Rsync+ssh virker fint og vi har tilgang fra bl.a. cerebellum og cereprod-hiof. Videre er det slik at filen må importeres (av oss). Importen skjer ved å logge seg inn som admin (root), velge "HiØ"-noden, velge deretter "Tools" -> "Fronter integration setup" -> velge importen -> "Run now". Importen er satt opp slik at det gjøres fullimport fra den nyeste filen i den aktuelle katalogen. Eldre XML-filer blir ryddet vekk uten forsøk på import.

Følgende skritt er nødvendige for å foreta et komplett testingforløp for hiof:

1. bygge en kopi av proddatabasen:

   $ pg_dump -i -h dbpg-cerebrum-ext.uio.no -U cerebrum_hiof_prod_user \
             --no-owner cerebrum_hiof_prod \
           | grep -v 'ON SCHEMA public' \
           | /usit/cereprod-hiof/u1/cerebrum/src/uiocerebrum/bin/filter_passwd.pl \
           | gzip -c > /tmp/hiof-prod-no-passwd.sql.gz
   

2. Opprette en passende testdatabase på cere-utv01 og lage et passordfil til den:

   cerebrum=> create database cerebrum_hiof_ivr with encoding 'unicode' ;
   CREATE DATABASE
   

3. Dumpe SQL-filen generert i 1. punkt i den nyopprettede databasen:

   $ zcat hiof-prod-no-passwd.sql.gz \
        | psql -h dbpg-cere-utv.uio.no -U cerebrum cerebrum_hiof_ivr
   

4. I tilfellet det er uoverenstemmelser mellom kodetreet og db-innholdet kan det være lurt med å oppdatere konstantene:

   $ python makedb.py --only-insert-codes
   

5. Nå kan man begynne å trekke nye data. Aller først må vi hente inn de nyeste filene fra FS:

   $ python import_from_FS.py --roleinfo-file roles.xml \
                     --studprog-file studieprog.xml \
                     --emneinfo-file emner.xml \
                     --undenh-file undenh.xml \
                     --edu-info-file edu-info.xml \
                     --misc-func 'undervisning.list_aktiviteter' \
                     --misc-tag 'aktivitet' \
                     --misc-file 'undakt.xml' \
                     -r -s -e -u -i
   

   Vi trenger ikke andre filene, men iallfall disse må hentes ned.

Spørsmål?

For henvendelsene til hiof, bruk e-postlisten cerebrum-hiof@usit.uio.no.

For henvendelsene hos Fronter, bruke webskjemaet deres: support.fronter.com -> contact us -> <velg noe passende>. Man trenger et installasjonsnavn og det er "oa" (uten "-ene).