Eksporten frå Cerebrum til Fronter

Dokument skreve av igorr og lagt ut i november 2008.

Innledning

ClassFronter har i utgangspunktet 3 entiteter; brukere, gruppe og rom. Den enkle her er bruker og rom, som ikke krever ytterligere forklaringer. Utfordringen ligger i gruppe, som ofte bekrives med begrepene:

  • gruppe

    Når det har brukere som medlemmer.

  • korridor

    når det har rom, eller en underligende gruppe har rom.

Med jevne mellomrom (nattlig) lages det en XML-fil som beskriver brukere/grupper/korridorer som skal være i CF. Denne XML-filen viser kun endringene i forhold til siste dump. TODO: dette ser ut til å ha endra seg, det ser ut til at vi no køyrer fulldump av all data kvar natt.

Arbeidet med generering av en slik XML-fil foregår i to etapper:

- Først hentes relevant informasjon fra FS og man oppdaterer (og ved

behov oppretter) de nødvendige interne gruppene i Cerebrum. Herunder leser man også personroller (fra en XML-fil generert fra FS tidligere) som brukes til bl.a. å registrere undervisningsansvarlige. Disse interngruppene har ikke nøyaktig samme struktur som gruppene som havner i XML-filen. Interngruppene i Cerebrum gjenspeiler situasjonen slik den er på det tidspunktet når jobben kjøres. Altså, her er det ikke snakk om registrere kun differanser, men det helhetlige bildet.

De interne gruppene får fronter-spread, en spread som brukes utelukkende til det formålet å identifisere grupper som skal eksporteres til CF.

Alt dette arbeidet skjer i populate_fronter_groups.py

- Deretter bruker man denne informasjonen for å bygge en XML-fil med

endringene siden sist. Til dette formålet henter man data både fra fronterdatabasen, FS og Cerebrum (de interne gruppene nevnt over).

Alt dette arbeidet skjer i generate_fronter_export.py

Denne filen kjøres av cerbrum_sites/bin/uio/update_fronter.py.

Når XML-filen er omsider generert, lastes denne opp i en passende CF-instans vha. 3. parts kode (FronterImportNG.jar). Virkemåten til denne er ukjent for Cerebrum, utover at XML-data lastes inn i fronterdatabasen. TODO: dette ser ut til å ha endra seg, update_fronter.py ser ut til å berre overføre fulldumpen med scp over til ei classfronter-maskin.

XML-bygging

XML-filen genereres vha. informasjonen innsamlet tidligere og det man henter ved behov fra FS. Selve filen kan grovt deles opp i tre deler:

1. En sekvens med <PERSON>-elementer som beskriver personer som skal
legges til eller fjernes.
2. En sekvens med <GROUP>-elementer som beskriver ymse grupper og
korridorer (kurs, aktiviteter, osv.)
3. En sekvens med <MEMBERSHIP>-elementer for å knytte sammen enten
grupper eller grupper og personer (rom og personer?).

Igjen, elementene som er i filen angir kun endringene i forhold til hvordan situasjonen er i Fronter på det tidspunktet når XML-filen genereres.

Hvert element kan enten opprettes, endres eller slettes. Dette oppgis med recstatus-attributt med verdiene hhv. 1, 2 eller 3.

Avhengig av hva slags informasjon man har om personer (fx. student, kursledelse, osv.), får de forskjellige personene forskjellige rettigheter i rommene. Rettighetstabellen står oppført i kommentarene til generate_fronter_xml.py. Rettighetene er da "owner", "read" og "write".

Det er flere forskjellige CF-maskiner man kan generere XML-dumpen for (produksjon, test, osv.).

Strukturnodene organiseres hierarkisk slik (KIS4020 er bare et eksempel, situasjonen er tilsvarende for andre kurs):

  • STRUCTURE/Sko:185:900000 (UiO)
    • STRUCTURE/Sko:185:140000 (HF)
      • STRUCTURE/Sko:185:143200 (Institutt for kulturstudier ...)
        • STRUCTURE/Enhet:KURS:185:KIS4020:1:HØST:2005:1
          Hovedkorridor for enheten - gruppen som inneholder
          informasjon om det aktuelle kurset (KIS4020,
          arkivfunksjoner). Gruppeid'en kan deles opp i disse
          komponentene:
          - 185 - institusjonsnummer
          - KIS4020 - emnekode
          - 1 - versjonskode
          - HØST - terminkode
          - 2005 - år
          - 1 - terminnummer (spesielt aktuelt for flersemesteremner)
        • STRUCTURE/Studentkorridor:KURS:185:KIS4020:1:HØST:2005:1
          • Undervisningskorridor

        • ROOM/Felles:KURS:185:KIS4020:1:HØST:2005:1

        • ROOM/Larer:KURS:185:KIS4020:1:HØST:2005:1

        • ROOM/Aktivitet:KURS:185:KIS4020:1:HØST:2005:1:<aktkode>

I tillegg bygger man følgende grupper med personmedlemmer:

  • uio.no:fs:kurs:185:kis4020:1:høst:2005:1:student
    alle studenter ved undervisningsenheten
  • uio.no:fs:kurs:185:kis4020:1:høst:2005:1:enhetsansvar
    alle ansvarlige for undervisningsenheten
  • uio.no:fs:kurs:185:kis4020:1:høst:2005:1:student:3-1
    alle studenter ved undervisningsaktiviteten 3-1.
    Man har en slik gruppe per undervisningsaktivitet.
  • uio.no:fs:kurs:185:kis4020:1:høst:2005:1:aktivitetsansvar:3-1
    alle ansvarlige ved undervisningsaktiviteten 3-1.
    Man har en slik grupper per undervisningtsaktivitet.

Gruppeid'ene har tilsvarende struktur som hovedkorridorid'en (institusjon, emnekode, versjonskode, terminkode, år, terminnummer).

Disse skrives ut i XML-filen med informasjon som er lagret i Cerebrum (altså, det finnes tilsvarende grupper internt i Cerebrum som man har populert med informasjon fra FS). Medlemskapsforholdet for disse gruppene er mellom gruppe og brukernavn (altså, det hele er uttrykt vha. <MEMBERSHIP>).

Grupper knyttes til andre grupper vha. medlemskap (<MEMBERSHIP>) på følgende måte (legg merke til at til hvert medlemskap er det knyttet ClassFronter rettighetene i den aktuelle gruppen): (FIXME: hva uttrykker disse medlemskapene? FIXME: Er det slik at disse medlemskapene finnes kun for å gi rettigheter?)

  • "uio.no:fs:<id>:aktivitetsansvar:<aktkode>" (samlige <aktkode>) "uio.no:fs:<id>:enhetsansvar" => er medlemmer i "All_users" (FIXME: Hva uttrykker det?)
  • "uio.no:fs:<id>:student", "uio.no:fs:<id>:student:3-1", "uio.no:fs:<id>:enhetsansvar", "uio.no:fs:<id>:aktivitetsansvar:<aktkode>" (samtlige <aktkode>) => er medlemmer i "uio.no:fs:<id>:enhetsansvar"
  • "uio.no:fs:<id>:enhetsansvar", "uio.no:fs:<id>:aktivitetsansvar:<aktkode>" (samtlige <aktkode>) => er medlemmer i "STRUCTURE/Studentkorridor:KURS:185:KIS4020:1:HØST:2005:1"
  • "uio.no:fs:<id>:student:<aktkode>", "uio.no:fs:<id>:aktivitetsansvar:<aktkode>" => er medlemmer i "ROOM/Aktivitet:KURS:185:KIS4020:1:HØST:2005:1:<aktkode>" Dette er for hver <aktkode>.
  • "uio.no:fs:<id>:student", "uio.no:fs:<id>:student:<aktkode>", "uio.no:fs:<id>:enhetsansvar", "uio.no:fs:<id>:aktivitetsansvar:<aktkode>" => er medlemmer i "uio.no:fs:<id>:aktivitetsansvar:<aktkode>" Dette er for hver <aktkode>. (FIXME: Huh? Hva er dette medlemskapet ment å uttrykke?)
  • "uio.no:fs:<id>:student", "uio.no:fs:<id>:enhetsansvar", "uio.no:fs:<id>:aktivitetsansvar:<aktkode>" (samtlige <aktkode>) => er medlemmer i "ROOM/Felles:KURS:185:KIS4020:1:HØST:2005:1" => er medlemmer i "uio.no:fs:<id>:student"
  • "uio.no:fs:<id>:enhetsansvar", "uio.no:fs:<id>:aktivitetsansvar:<aktkode>" (samtlige <aktkode>) => "ROOM/Larer:KURS:185:KIS4020:1:HØST:2005:1"
  • "uio.no:fs:<id>:student:<aktkode>", "uio.no:fs:<id>:enhetsansvar", "uio.no:fs:<id>:aktivitetsansvar:<aktkode>" => er medlemmer i "uio.no:fs:<id>:student:<aktkode>" Dette er for hver <aktkode>.

Rettigheter

Det er flere rettigheter knyttet til både personer og grupper i CF. Overordnet kan man dele rettighetene i to deler - gruppe/romrettighetene og kontaktrettighetene. Rettighetene gis til personer vha. medlemskap i grupper; altså, en person blir medlem i en gruppe som så får rettighetene mot en annen gruppe.

En instans av et kurs vil gi opphav til disse gruppene:

  • Grupper med personer i:
    • student:<kursid>
    • enhansv:<kursid>
    • student:<aktkode>
    • aktansv:<aktkode>
  • Strukturgrupper:
    • Enhetsrom:<kursid>
    • Studentkorridor:<kursid>
    • Fellesrom:<kursid>
    • Lærerrom:<kursid>
    • Aktrom:<aktkode>

(<kursid> vil identifisere den aktuelle kursinnstansen entydig, slik beskrevet tidligere, og aktkode inneholder <kursid> samt en entydig aktivitetsid innen denne kursinstansen).

Strukturgruppene henger sammen i et hierarki, plassert under den organisasjonsenheten (i LT sin betydning av ordet, ikke CF) som kurset er knyttet til, mens alle grupper med personer i hektes (logisk sett) under det passende Enhetsrommet.

  • "student"
    inneholder (brukernavn til) alle studentene på et gitt kurs
  • "enhansv"
    inneholder (brukernavn til) alle de med ansvarsforhold mot kurset (det er typisk forelesere og gruppelærere). Det er også slik at de med rollen knyttet til aktiviteten "FOR" (forelesning), havner i denne gruppen (selv uten å være formelt oppført som kursansvarlige).
  • "student:<aktkode>"
    inneholder studentene meldt opp til den aktuelle aktiviteten (typisk: gruppeundervisning, labøvelser, osv.)
  • "aktansv:<aktkode>"
    inneholder alle de med ansvarsforhold mot aktiviteten (typisk gruppelærere).

Det finnes en rekke forskjellige rettigheter som gruppene kan få tildelt (mot/vis-a-vis andre grupper):

  • ROLE_READ (er "gjest" i CF)

  • ROLE_WRITE (er "student" i CF)

  • ROLE_DELETE (er "lærer" i CF)

  • ROLE_CHANGE (er "hovedlærer" i CF)

    => disse rettighetene er mot rom og definerer hva en gruppe (med personer) får lov til å gjøre i det rommet.

  • Admin lite / Room creator

    => denne er mot en korridor.

  • View contacts

    => denne er mot grupper med personer i (om en gruppe får se kontaktinformasjon til folk i en annen gruppe)

Den komplette oversikten over rettighetene står i generate_fronter_export.py.

Rettighetene uttrykkes i XML-filen vha.:

  • For rettigheter mot rom, lager man et <ROLE>-element, hvis roletype attributt uttrykker en rettighet.
  • For rettigheter mot grupper (som ikke er rom), uttrykkes det hele via et GROUPACCESS-element, hvis contactAccess/roomAccess-attributtene uttrykker en rettighet.

Vi kan ta noen eksempler på rettighetstildeling:

  • For å uttrykke at gruppe A har en av ROLE-rettighetene mot gruppe B, vil man bruke noe slikt:

     <MEMBERSHIP>
   <!- identifikasjon av gruppe B -->
   <MEMBER>
     <SOURCEDID><!-- identifikasjon av gruppe A -->
     <ROLE roletype=XX ...>
     </ROLE>
   </MEMBER>
 </MEMBERSHIP>

... der XX kan være:

     - 07 for ROLE_CHANGE
     - 03 for ROLE_DELETE
     - 02 for ROLE_WRITE
     - 01 for ROLE_READ

NB! ROLE_DELETE og ROLE_READ brukes IKKE som rettighet i rom (selv om
kodeverdiene finnes).
  • For å uttrykke at gruppe A har admin lite / creator rettighetene mot

    gruppe B, vil man bruke noe slikt:

    <MEMBERSHIP>
  <!-- identifikasjon av gruppe B -->
  <MEMBER>
    <SOURCEDID><!-- identifikasjon av gruppe A -->
    <ROLE ...>
      <GROUPACCESS roomAccess = "100" contactAccess="250">
    </ROLE>
  </MEMBER>
</MEMBERSHIP>

Interne grupper i Cerebrum

For å holde oversikt over hvilke personer og hvilke grupper skal til slutt eksporteres til CF, bygges det en rekke interne grupper i Cerebrum. Disse gruppene får en spesiell spread og de brukes ved XML-filgenereringen senere.

Den eksakte oversikten over de interne gruppene finnes i kommentarene i populate_fronter_groups.py. EVU-gruppene var ikke med i den opprinnelige versjonen, men de skiller seg ikke i nevneverdig grad fra ikke-EVU-grupper. Id'ene på gruppene er litt annerledes (nøkkelen for EVU-grupper er gjerne paret (etterutdkurskode, kurstidsangivelseskode)), men utover dette genereres alle gruppene på samme måte som for "vanlige" kurs.

Hva gjør automagien i forhold til blyant.uio.no (DLOPROD)

Automagien bygger alle 'organisasjonsenheter' fra root (UiO) ned til emnet som skal 'mappes' opp.

På root lages:

  • En gruppe 'UiO-Admin' med enkelte SYDR/DML folk som medlemmer. Denne gruppen får 'Administrator' og 'Create Room' på 'root'-strukturen. Medlemmene av denne skal i tillegg være 'Administrator' (som er en rettighet knyttet til kontakter).

  • En gruppe 'UiO-Alle' med alle UiO's brukerene som medlemmer og med 'View no contacts'. Alle grupper som representerer lærere/lokale administratorer blir beldt inn i denne gruppen med 'View contacts'.

    Alle andre grupper som lages legges strukturmessig inn her.

Det vil bli opprettet rom/struktur for følgende (gitt at det emnet skal mappes opp):

  • Korridor for eksamensemne (emne med studenter meldt til eksamen inneværende og fremtidige semestre).

    • En gruppe med Undervisningsansvarlige og Fagansvarlig for emne knyttes til korridoren med 'View contacts'. Senere semestre kan det bli aktuelt å gi denne gruppen 'Room Creator' her.

    • En gruppe med de studenter som er eksamensmeldt til emnet knyttes til korridoren med 'View no contacts'.

    • Et rom 'Lærerrommet'
      • En gruppe med Undervisningsansvarlige og Fagansvarlig for emne, og Lærere, Undervisere og fagansvarlige for undervisningsaktivitetene får 'Delete' til rommet.
    • Et rom 'Fellesrom'
      • En gruppe med Undervisningsansvarlige og Fagansvarlig for emne, og Lærere, Undervisere og fagansvarlige for undervisningsaktivitetene får 'Delete' til rommet.
      • En gruppe med de studenter som er eksamensmeldt til emnet får 'Read' til rommet.
    • En korridor 'Undervisningsrom'
      • En gruppe med Undervisningsansvarlige og Fagansvarlig for emne knyttes til korridoren med 'Room Creator' og 'Administrator'.

    • Ett rom per undervisningsaktivitet det er registrert studenter ved.

      • En gruppe med Lærere, Undervisere og fagansvarlige for undervisningsaktiviteten får 'Delete' til rommet.
      • En gruppe med studenter undervisningsmeldt til undervisningsaktiviteten får 'Write' til rommet.
Publisert 10. apr. 2013 13:40
Del på e-post