UKEavvik

Denne siden forklarer litt hvordan avvik.uka.no fungerer.

Hva er UKEavvik?

UKEavvik er et system som ble laget for UKA etter at de uttrykte et behov for et avviksystem hvor det var lettere å gi tilbakemeldinger på. Mest kritisk ønsket de at innsendere kunne se hvordan avviket ble behandlet. UKEavvik består derfor i hovedsak av 3 ting:

Et skjema der man kan sende inn avvik
En side der man kan følge med på et avvik og sende meldinger til saksbehandler.
En adminside hvor HMS, Nestledere og UKST kan behandle og oppfølge avvik.

I tillegg er det litt flere ting man kan gjøre. Administratorer har tilgang til å lukke (arkivere) og anonymisere avvik. Brukere som har tilgang til et avvik, har også mulighet til å dele avviket med andre, slik at de kan lese avviket og sende oppfølgning.

Et annet viktig poeng for UKA var at det måtte være mulig å være anonym når man bruker systemet. Når man sender inn et avvik vil man derfor få et passord som man bruker for å "logge inn" og se avviket. På den måten beholder man anonymitet. For å forhindre at man brute-forcer innlogging, er det skrevet et lockout-system som baserer seg kun på IP-addressen.

Men, åssen fungerer dette 'a?

Innlogging for å se avvik

Når en bruker sender inn et avvik, vil hen bli presentert med et generert passord som er langt nok til at det er "computationally infeasible" å brute-force det. Videre kan brukeren navigere til https://avvik.uka.no/deviation/login/, hvor man skriver inn passordet man fikk og logger inn. Slik slipper man et brukersystem for innlogging for å se avvik.

Lockout

For å forhindre forsøk på brute-force, har det blitt laget en lockout-mekanisme som låser ut etter et visst antall feilede forsøk fra en spesifikk IP-addresse. Det som er kinkig her er at det ikke er noe brukersystem, slik som f.eks django-axes bruker, så man kan kun som sagt se på IP-addressen. Dette kan potensielt føre til at "uskyldige" brukere blir låst ute en periode. Du kan lese mer om dette her: https://github.com/erlendps/django-anon-lockout.

Adminsiden

På adminsiden kan administratorer svare på avvik, både internt og eksternt. Internt betyr at kun andre administratorer kan se det, mens eksternt vil en bruker som logger inn for å se avvik kunne se. Superadminer har også mulighet til å lukke avvik, og anonymisere de til neste UKEer.

Det er 2 type adminer: admin og superadmin. Superadmin har tilgang til alt, de kan se alle avvik. Admin har tilgang til å logge inn, men de vil ikke kunne se alle avvik, de ser kun avvik som er delt med dem. Brukere som har tilgang til et avvik har også mulighet til å dele avviket med andre. Ellers kan adminer også svare på avvik de har tilgang til. Det er også mulig å endre svarene man har sendt. Adminer kan kun endre de de selv har sendt, mens superadmin kan endre alle.

Flow

Når et avvik blir sendt inn, får det en status "ny", og vil komme opp på landingssiden under kolonnen "nye avvik". Man kan klikke seg inn på avviket og lese all informasjon om det. Når man svarer eksternt på avviket vil status endre seg til "under behandling", om man svarer internt vil status ikke endre seg. Avviket vil nå befinne seg i kolonnen "Under behandling". For å lukke avviket (konkludere) trykker man på den rød knappen, hvor man blir promptet til å skrive en konklusjonsmelding. Status vil da endre seg til "lukket" og man kan se avviket i arkivet. Om man sender en ny oppfølgning på et lukket avvik, vil avviket endre status tilbake til "under behandling". Innmelderen av avviket kan også sende meldinger til saksbehandleren. Disse meldingene havner under "ekstern oppfølgning" på adminsiden. Hvis avviket er lukket og innmelderen sender en ny melding, vil statusen endre seg tilbake til "under behandling".

Til slutt, når en ny UKE tar over, vil superadminer ha tilgang til å anonymisere et avvik. Dette er så enkelt som at man blir sendt til et skjema hvor man kan endre all fritekst.

Epostvarsling

Hvis innmelderen legger igjen en e-postadresse når avviket opprettes, vil innmelderen både få en bekreftelsesmail på at avviket er registrert, samt epostvarslinger hver gang en saksbehandler sender en melding under "ekstern oppfølgning" eller "ekstern konklusjon". Alle saksbehandlere med tilgang til avviket får også varsling på epost når det kommer inn nye avvik, samt når innmelderen sender en melding.

Hvem har tilgang?

Per nå så er det kun ITK og HMS som har superadmintilgang, og nestledere og UKST har admintilgang. Tilgang gis gjennom ITKACL, men for å logge inn er man nødt til å ha bruker i django sitt brukersystem. Dette blir automatisk synkronisert fra mdb. Synkroniseringsscriptet ligger i pullmdbdata.py som ligger i :

avvikuka/authentication/management/commands

Inkrementering av UKA

Når UKA inkrementerer, det vil si går fra f.eks UKA-23 til UKA-25, er det noen få ting man må passe på å legge til/endre for at avviksystemet skal fungere ordentlig.

Endre CURRENT_UKA og UKA_TITLE til riktig UKE.

I avvikuka/settings/base.py endre disse feltene til riktig UKE-år.

Endre på view-definisjon

For å synkronisere riktig brukere i pullmdbdata, må man endre litt på et view som ligger i public-skjemaet i mdb2. I avvik_uka-skjemaet i mdb2, er det view, mdb_user, som henter fra dette viewet i public-skjemaet. Skjemaet man må endre heter uka_avvik_gruppe_ider, og henter som navnet tilsier, gruppe-idene for de gruppene hvis medlemer skal ha bruker i avviksystemet. Se på view-definisjonen ved hjelp av d+ i psql:

mdb2=# d+ uka_avvik_gruppe_ider

Dette skal hente gruppe-idene til alle subgrupper av HMS, UKEstyret, Nestledere og ITK. Det som må endres er gruppenummeret for HMS, UKST og Nestledere. Ved å kjøre kommandoen over vil man få noe ala:

View definition:
  SELECT mdb_gruppekobling_transitiv_tillukning.undergruppe_id AS gruppe_id
  FROM kortsys2.mdb_gruppekobling_transitiv_tillukning
    WHERE mdb_gruppekobling_transitiv_tillukning.overgruppe_id = 5354
      OR mdb_gruppekobling_transitiv_tillukning.overgruppe_id = 5516
      OR mdb_gruppekobling_transitiv_tillukning.overgruppe_id = 5350
      OR mdb_gruppekobling_transitiv_tillukning.overgruppe_id = 248
  UNION
    SELECT 5354 AS gruppe_id
  UNION
    SELECT 5516 AS gruppe_id
  UNION
    SELECT 5350 AS gruppe_id;

Gruppenummer 248 er ITK, så det trengs ikke å gjøres noe med (med mindre det av en grunn endres). Først finner du rotgruppenummerene til henholdsvis UKST, nestledere og HMS. Deretter kan du gjøre noe lignende dette:

mdb2=# CREATE OR REPLACE VIEW uka_avvik_gruppe_ider AS
  SELECT mdb_gruppekobling_transitiv_tillukning.undergruppe_id AS gruppe_id
  FROM kortsys2.mdb_gruppekobling_transitiv_tillukning
    WHERE mdb_gruppekobling_transitiv_tillukning.overgruppe_id = {HMS gruppe-id}
      OR mdb_gruppekobling_transitiv_tillukning.overgruppe_id = {UKST gruppe-id}
      OR mdb_gruppekobling_transitiv_tillukning.overgruppe_id = {NL gruppe-id}
      OR mdb_gruppekobling_transitiv_tillukning.overgruppe_id = 248
  UNION
    SELECT {HMS gruppe-id} AS gruppe_id
  UNION
    SELECT {UKST gruppe-id} AS gruppe_id
  UNION
    SELECT {NL gruppe-id} AS gruppe_id;

og voilà! Medlem som er med i subgruppe av disse gruppene vil få en bruker i djangos brukersystem slik at de kan logge inn på avviksystemet.