Implementering av alumni-ordning for UiO

Den tekniske spesifikasjonen for den nye alumni-ordningen til UIO som skal utvikles ved USIT og bygges inn i UiO sitt brukeradministrasjonssystem, Cerebrum.

1   Oversikt

Alumniløsningen ved bruk av Cerebrum vil bestå av:

2   Alumnibruker

Med alumni snakker vi i dette dokumentet om studentalumni. Andre typer alumni, som ansattalumni, regnes ikke med i spesifikasjonen, men vi opner opp for at også andre alumnityper vil kunne bli brukt i fremtiden.

En alumnibruker i Cerebrum vil være en vanlig, personlig brukerkonto, på lik linje med andre brukerkontoer. Brukerkontoen og tilhørende person-objekt vil få en alumnitilknytning som sier at brukeren er alumni, tilknyttet en stedkode. Vi har satt denne tilknytningen til å hete:

ALUMNI/student

Det som gjør en brukerkonto til en alumnibruker, er at brukerkontoen er registrert med tilknytningen ALUMNI. Det varierer hva brukerkontoer får av andre innstillinger, blant annet spread og gruppetilganger, men alumnibrukere har i utgangspunktet ikke mange tilganger. En alumnibruker kan samtidig også være en studentbruker og/eller en ansattbruker. Brukerkontoen vil da kunne få flere tilganger, i tillegg til det som trengs av tilganger for alumni.

Alumnibrukere vil bli manuelt "aktivert", ved at personen selv melder seg inn i alumniløsningen. Det meste av informasjonen om personen skal likevel komme fra FS, så alumni vil ikke være manuelt opprettet. Alumnibrukere vil i første versjon av løsningen bare kunne aktivere seg dersom de allerede har en aktiv brukerkonto i Cerebrum, da vi ikke har en annen autentiseringsløsning. Dette vil kunne endre seg med autentisering mot ID-porten i senere versjoner av alumniløsningen, som da opner opp for at personer også kan få automatisk opprettet en alumnibrukere i Cerebrum, så lenge de oppfyller kravene til alumni.

Kontoer som bare fungerer som alumni-konto, som vil si at brukeren ikke har andre tilknytninger enn ALUMNI, og ingen andre spreads enn alumni-relaterte spreads, blir omtalt som rene alumnikontoer.

2.1   Manuell alumni

Dersom brukeren ikke har en personlig konto ved universitetet, vil vi ikke ha noen sterk nok autentiseringsmulighet og kan derfor ikke koble personen mot person-objekt i Cerebrum eller FS. Vi aksepterer derfor ikke manuelt registrerte alumnibrukere i denne løsningen.

Den eksisterende alumniløsningen til UiO inneholder en stor andel personer som ikke lenger har tilgang til sin tidligere brukerkonto ved UiO. Disse vil vi dessverre ikke kunne migrere til Cerebrum da vi mangler nok autentiseringsgrunnlag for personene.

Initielt vil man måtte satse på at eksisterende studenter vil registrere seg som alumni før de mister tilgang til sin personlige brukerkonto, som er kort tid etter at studiene er avsluttet.

2.2   Andre alumni

Løsningen vil senere kunne utvides med andre alumni-tilknytniner og kildesystem, som f.eks. ansattalumni, men det vil kreve noe tilpasninger av løsningen.

Alumniadministratorer kan manuelt legge inn ekstra e-postadresser i Sympa sine e-postlister, også eksterne adresser. Dette kan alumniadministratorer bruke for å vedlikeholde de som ikke kan registrere seg i alumniløsningen, for eksempel de som ikke har en aktiv brukerkonto.

2.3   Stedkoder

Hver alumni-tilknytning må være tilknyttet en stedkode, for å markere hvor i enheten tilknytningen til alumni befinner seg. For vanlige studenter er for eksempel den tilknyttede stedkoden med på å vise om studenten studerer på HF eller MatNat.

TODO: Det er ikke avklart om alle alumni skal vere registrert på den samme stedkoden, eller om vi skal hente ut noen stedkoder fra FS.

Slik alumniløsningen er implementert, er den lite avhengig av hvilken stedkode alumni blir registrert på. Det er fullt overkommelig å også endre dette senere. Dersom vi går for å innføre ulike stedkoder trenger vi å se på:

  • Vi må få utvidet utplukket som henter informasjonen fra FS til å inkludere stedkoder.
  • Stedkoden settes bare en gang i dag, ved registrering og aktivering av alumni ved første pålogging, så om vi skal gå for mer enn en stedkode må vi innføre automatikk for å vedlikeholde dette.
  • Vi må vite hvilke enheter som har prioritet over andre.
  • Det må også vurdere om vi trenger mer enn bare en alumnitilknytning. Trenger vi for eksempel ALUMNI/master@ifi og ALUMNI/bachelor@UV?

3   Lagring av informasjon i Cerebrum

Følgende informasjon om alumni vil lagres i Cerebrum.

Alumnitilknytning

Når personer melder seg inn i alumniløsningen, skal Person-objektet deres få en person-tilknytning av typen ALUMNI.

Tilknytninger må peke mot en organisasjonsenhet i organisasjonen, som oftest representert ved en stedkode.

TODO: Det er ikke blitt bestemt hvilke(n) stedkode(r) som skal brukes for alumni. En fast "alumni-stedkode" for alle? En stedkode for hver grad? Bare tilknytningen til den siste, eller høyeste, oppnådde graden?

Tilknytningen må også registeres på en av brukerene til personen. Den registreres initielt på brukerkontoen som logget på alumniløsningen for å søke.

Navn

Navn er registrert på Person-objektet.

OBS: Navn skal ikke kunne endres i alumniløsningen. Bruker bare navn registrert i FS.

TODO: Flytt til eiga liste over kva alumniløysinga brukast.

Informasjon om navn innhentes manuelt fra personen ved registrering. Forslag hentes fra kildesystemet system:cached (det høyeste vektede navnet i Cerebrum, uavhengig av kildesystem). Feltet kan fylles inn, samt oppdateres, manuelt. Dette navnet vil være det eneste navnet registrert for manuell alumni, og vil fungere som visningsnavn i alumnisystemet.

Fødselsdato

TODO: Lagrast ikkje, berre for visning.

Fødselsdato lagres i Person-objektet, som et mx.DateTime-objekt.

Siden alle personer allerede må eksistere i Cerebrum, finnes dette feltet allerede, og skal ikke kunne endres. Eventuelle feil må meldes inn til eier av kildesystem, som for student-alumni kan oppdateres av studiekonsulenter.

Dette feltet vil kunne måtte registreres manuelt av personen selv om vi tar i bruk ID-porten-autentisering, med mindre vi får dette fra ID-porten.

Kjønn

TODO: Lagrast ikkje, berre for visning.

Kjønn lagres i Person-objektet.

Siden alle personer allerede må eksistere i Cerebrum, finnes dette feltet allerede, og skal ikke kunne endres. Eventuelle feil må meldes inn til eier av kildesystem, som for student-alumni kan oppdateres av studiekonsulenter.

Ved innføring av ID-porten vil vi måtte se mer på hvordan dette feltet skal settes.

Informasjon om høyeste oppnådde grad

Personen sin høyeste oppnådde grad lagres i et Trait-objekt i Cerebrum.

Trait-type: alumni_degree

Graden blir lagret med strval:

GRADNAVN_FORKORTET (GRADKODE)

Dato for oppnåelse av graden bli lagret i traitet sitt dato-felt.

Eventuell pågående utdanningsløp vil også eventuelt bli lagret her, men da uten dato for oppnåelse.

Grader fra FS hentes inn ved registrering av tilknyttet alumni, og vedlikeholdes også fra FS.

Personen skal ikke kunne selv redigere dette feltet, da det bare skal kunne hentes fra FS.

Andre kvalifikasjoner

Oppnådde grader som ikke finnes i FS (tilknyttet alumni med utdanning fra andre institusjoner, manuell alumni) vil også kunne registreres. Dette lagres i et Trait-objekt for personen.

Trait-type: alumni_otheredu

Feltet er et fritekstfelt, som personen står fritt til å redigere fritt. Personen blir presentert med flere felt for utfylling. Disse lagres i samme traitet, adskilt med n.

Informasjon om andre grader fylles inn ved registrering, og vedlikeholdes manuelt av brukeren. Alumniadministratorer kan også redigere feltet.

Adresse

Adresse lagres som adresseinformasjon tilknyttet Person-objektet.

  • Kildesystem: alumni
  • Adressetype: POST
  • Verdier: Postnummer og land. Gateadresse lagres ikke.

Formålet til denne adressen er at den skal kunne bruke av alumni-administratorer for å avgrense søk på alumni som befinner seg i regioner. Postnummer og land er derfor tilstrekkelig.

Ekstern epost-adresse

Lagres som kontaktinformasjon i Person-objektet:

  • Kildesystem: alumni
  • Kontakttype: EMAIL

Dette er alumnibrukeren sitt kontaktpunkt og skal kunne brukes av alumni-administratorer til å sende ut informasjon, invitasjoner og kan meldes inn og ut av e-postlister.

Registrerte eksterne e-postadresser vil kunne brukes for videresending av e-post for alumni. TODO: Se eget avsnitt/dokument for mer informasjon om dette.

Informasjon om ekstern e-postadresse innhentes ved registrering. Forslag hentes dersom det finnes en videresending-adresse (EmailForward) i Cerebrum. Feltet vil kunne endres/fylles inn manuelt, og kunne oppdateres selv av brukeren.

Obs: Denne e-postadressen må ikke forveksles med UiO-brukeren sine eventuelle videresendingsadresser i Cerebrum.

Mobilnummer

TODO: Kan ikkje redigerast, hentast berre frå FS og visast.

Mobilnummer lagres som kontaktinformasjon tilknyttet Person-objektet:

  • Kildesystem: alumni
  • Kontakttype: MOBILE

Informasjonen hentes inn ved registrering. Forslag hentes fra system:fs, type contact_mobile_phone, men feltet må fylles inn manuelt. Informasjonen vedlikeholdes selv av brukeren, og kan også oppdateres av alumni-administratorer.

Nummeret vil kunne benyttes i Glemt-passord-tjenesten til UiO. Dette må konfigureres__ i glemt-passord-tjenesten når løsningen er på plass.

TODO: Høyr med mocca om ikkje dette skal redigerast.

Arbeidsgiver

Navn på nåværende arbeidsgiver, tekstfelt, lagres som et trait tilknyttet Person-objekt:

  • Trait-type: alummi_employer

Informasjon om arbeidssted fylles inn manuelt ved registrering, og oppdateres manuelt av brukeren selv. Feltet vil være valgfritt, da noen kan være uten arbeid og andre ikke vil oppgi sin arbeidsgiver. Om feltet hadde vært obligatorisk ville det kunne føre til feilaktig informasjon fra brukere.

Stilling

Stilling ved nåværende arbeidssted, lagres som et trait tilknyttet Person-objektet:

  • Trait-type: alumni_position

Informasjon om stilling fylles inn manuelt ved registrering, og oppdateres manuelt av brukeren selv. Feltet vil være valgfritt, av samme årsak som 'Arbeidsgiver'.

Interesseområder

Interesseområder er ulike kategorier/tema som alumnibrukeren er interessert i, og som kan brukes av alumni-administratorer til å gjøre utplukk av relevante personer. Hvert interesseområde vil modelleres i Cerebrum med en gruppe. Av- og påmelding i interesseområder vil da gjøres ved å melde brukerkontoer inn og ut av tilhørende gruppe.

Interesseområder velges manuelt fra et sett ved registrering, og oppdateres manuelt av personen selv.

Hvilke interesseområder som er tilgjengelige styres av et trait som settes på gruppen. Traitet er av typen alumni_interest_group.

4   Oppførsel i Cerebrum

Cerebrum vil måtte utvides med ny funksjonalitet for automatisering for alumnibrukere, og noe funksjonalitet vil måtte endres på som følge av alumniløsningen.

4.1   Oppretting av alumnibruker

Dersom man logger inn med en personlig brukerkonto, vil det være mulig å slå opp informasjon fra FS/Cerebrum ved registrering. Vi vil da kunne kontrollere at personen oppfyller kravene til alumni, ved å spørre FS. Ved oppretting av alumnibruker, vil man måtte hente inn informasjon ihht. punktene under `Lagring av informasjon i Cerebrum`__.

For tilknyttet alumni, vil informasjon om alumni lagres på eksisterende Person- og Konto-objekt. Dersom brukeren kvalifiserer som alumni basert på FS-data, vil også alumni-tilknytning tildeles brukerkontoen. Hvis ikke, må brukeren gjennom en automatisert søknadsprosess.

Det er brukerkontoen som brukes ved pålogging som vil bli registrert som alumnibruker, uansett om personen er registrert med andre brukerkontoer.

TODO: Ved senere bytte av primærbruker vil dette kunne være et problem, då personen har alumni-tilknytning, som blir synlig gjennom Feide, men via en annen brukerkonto som hva som er registrert i Cerebrum. Hva konsekvenser gir dette? Ved senere avvikling av andre brukere enn alumni-brukeren, vil personen kunne få et bytte av primærbruker uten å vite om det selv. Skal vi gå bort fra tilknytning på brukerkontoen og bare se på personen, eller skal vi akseptere dette som et problem? Det er forholdsvis ikke så mange som har mer enn en brukerkonto, spesielt blant studenter, men for ansatte vil dette kunne bli et noe større problem.

Registreringsprosessen for tilknyttede alumni blir slik:

  1. Bruker logger inn med en av sine personlige brukerkontoer.

  2. Web Service sjekker mot FS (FS Web Service) om bruker tilfredsstiller krav for alumni.

    • Hvis JA – Registreringsskjema

      1. Etter innsendt skjema, vil brukerkontoen automatisk få alumni-affiliation og alumni-informasjonen lagres. Brukerkontoen vil bli innmeldt i interessegrupper, og vil kunne benyttes i alumni-løsningen umiddelbart.

        TODO: Noen spread som skal settes?

    • Hvis NEI - Avslag: Brukeren får beskjed om at du ikke oppfyller kravene til å være alumni. AF bestemmer hvilken tekst som skal stå i avslaget, for eksempel med lenke til hjelpesidene til alumniløsningen.

4.2   Vedlikehold av alumnibrukere

TODO: Trengs det noe automatikk for å vedlikeholde attributter for alumnibrukere? For eksempel spread?

4.3   Oppdatering av personinformasjon

Alumniløsningen utvider Cerebrum med en oppdateringsjobb som tar for seg:

  • Høyeste oppnådde grad: Oppdateres fra informasjon fra FS.

TODO: Vi trenger kanskje å utvide studentautomatikken til å oppdatere personinformasjon om alumni i tillegg til studenter. Dette inkluderer:

  • Navn
  • Mobil

Fødselsnummer-endringer er allerede implementert for alle personer fra FS.

4.4   Nedgradering av aktive brukere til rene alumnibrukere

TODO: Må spesifiseres!

Når studenter slutter å studere, men er meldt inn i alumniløsningen, vil de måtte kunne beholde brukerkontoen sin, men skal samtidig miste andre innstillinger de hadde som studenter, for eksempel gruppetilganger og spreads.

Den vanlige sperre- og avviklingsrutinen vil ta alle personer uten gyldige tilknytninger og først sette brukeren i karantene, og etter en periode også avvikle brukerkontoen. Dette skal ikke skje med aktive alumnibrukere.

Vi må utvide Cerebrum med funksjonalitet for å nedgradere brukerkontoer, basert på tilknytninger. Et løsningsforslag vil være:

  • En egen jobb som ser på alle personer som bare har alumnitilknytning.
    • Alle andre brukerkontoer enn primærbrukeren kan settes i en karantene som gjør at brukeren blir tatt med i den vanlige avviklingsautomatikken. De sperrede brukerene vil da etter en periode bli automatisk avviklet.
    • Personen og primærbrukeren får fjernet alle spreads som det ikke er behov for hos alumni. TODO: Trenger å spesifisere hva alumni trenger av spreads.
    • TODO: Anna?
  • Alumni som har vært i passordkarantene i en periode kan bli avviklet på samme måte som andre brukere. Se mer om dette under Passordregime.
  • Det vil måtte være et tidsvindu fra personen ikke lenger regnes som aktiv student, til brukerkontoene vil bli sperret. Dette for at personen skal få tid til å registrere seg i alumniløsningen. I dag gjøres det ved at student-tilknytninger ikke slettes før etter en periode etter at studenten er ferdig med å studere.
  • Til en senere versjon: Legge til alumnitilknytning på primærbrukeren hvis personen har alumnitilknytning uten at noen av personen sine brukere har det.

4.5   Passordregime

Alumnibrukere vil bli påvirket av den vanlige passordvarslingen, som betyr at passord må byttes minst en gang i året. Dersom ikke passord byttes før fristen, vil kontoen få en autopassord-karantene.

Alumnibrukere skal kunne bruke den vanlige glemt-passord-tenesten til UiO, som autentiserer ved hjelp av registrert mobilnummer. Ved fullført passordbytte vil passordkarantenen bli fjernet, så brukerkontoen kan brukes igjen om den ikke har andre karantener. Alumni vil også ha mulighet til å møte opp personlig ved Houston og få passordet sitt byttet der ved fremvisning av gyldig ID, som alle andre med brukerkonto hos UiO. TODO: Trenger å avklare med Houston om at de har kapasitet til dette eller ikke?

Passordkarantenene vil i alumniløsningen brukes for å finne alumnibrukere som ikke lenger er aktive. Alle alumnibrukere som har vært i passordkarantene i over to år vil kunne bli avviklet.

4.6   Avvikling av inaktive alumni

Alumnibrukere som er blitt inaktive vil bli avviklet gjennom samme automatikken som avvikler andre inaktive brukere. Automatikken avvikler alle brukere til personer som ikke lenger har en eneste aktiv tilknytting til UiO. Alumnibrukere blir inkludert i denne avviklingen ved å innføre automatikk som fjerner alle alumnitilknytninger til personen der alle brukerene til personen har vært i passordkarantene i over 2 år.

Dette kan gjøres i en egen jobb i Cerebrum som går regelmessig, og fungerer ved at den fjerner alumni-tilknytningen fra personen når alumnibrukeren har vært i karantene i over to år. Dette gjør at brukeren deretter vil bli omfattet av den vanlige, automatiske sperringen av inaktive brukerkontoer.

TODO: Alternativt kan tilknytningen på personen endres frå `ALUMNI/student` til `ALUMNI/inaktiv`, for å likevel beholde noe av alumni-statusen. Glemt-passord-tjenesten kan da settes opp til å akseptere begge tilknytningene, men den automatiske sperringen ser bare på ALUMNI/student. Dette kan vere fristande å ha, då inaktive alumni framleis vil kunne vere søkbare i alumniløysinga, sjølv om dei ikkje har vore flinke til å bytte passord. Vil kunne vere negativt at vi rydder i gamle alumni, folk vil gjerne ikkje bytte passord så ofte.

Alumni som har mistet alumni-tilknytningen på sin person vil ikke lenger kunne bruke glemt-passord-tenesten for å sette seg et nytt passord. Personen må da søke om alumni-tilgang på nytt, som krever at noen med IT-rettigheter midlertidig opphever karantenen til brukerkontoen. For at personen skal få tilgang til alumni igjen etter at brukerkontoen har blitt avviklet krever det at noen gjenoppretter brukerkontoen til personen.

TODO: Det er ikke spesifisert at alumnibrukere skal få noen egen forklaring om at de må bytte passord gjennom glemt-passord-tjenesten for å bli aktive igjen. Det kan hende at dette vil være nødvendig, men er ikke noe vi har kapasitet til i første versjon. Den automatiske sperringen bør heller inneholde en lenke til en nettside med mer informasjon til alle brukertyper.

4.7   Migrering fra Mira

Den tidligere alumniløsningen, Mira, inneholder ikke noen sterkt autentisert data. Da det er krav om at personen i Cerebrum inneholder autentiske data fra kildesystem kan vi ikke migrere data fra Mira til Cerebrum. Vi har heller ikke noen knytning fra Mira-brukeren til en brukerkonto ved UiO.

Det er ønskelig at alumniløsningen i framtiden har støtte for autentisering via ID-porten. Vi vil da kunne få registrert de som ikke lenger har en aktiv brukerkonto på UiO.

4.8   Melde eksterne adresser på e-postlister

Vedlikehold av e-postlister vil foregå i Sympa, utenfor alumni-løsningen. Cerebrum vedlikeholder interesseområde-grupper etter hva alumni velger i løsningen. Disse gruppene må knyttes opp mot e-postlister i Sympa. Dette vil føre til at utsendinger til en slik e-postliste vil gå til alle brukerene som er medlem av interesseområde-gruppa, og kan deretter bli videresendt til den eksterne adressen som er registrert av alumni, eventuelt bare til UiO-e-postkontoen til brukeren.

TODO: Dette må sjekkast om er riktig.

E-postadresser som blir meldt på direkte gjennom Sympa sitt web-grensesnitt, vil ikke bli berørt av Cerebrum-eksport til Sympa. Det vil være uproblematisk å melde inn i en e-postliste både gjennom eksport fra Cerebrum, og manuelt i Sympa. Man må da være obs på at slike e-postadresser ikke blir meldt ut av e-postlisten ved eksport fra Cerebrum.

TODO: Det er idag personer som er lagt inn i disse interesse-gruppene. Vi må se om dette blir støttet riktig av LDAP og Sympa, eller om vi forandre på det.

Alumniadministratorer har også mulighet til å gjøre søk i alumniløsningen, og kan hente ut en liste over brukerene sine eksterne e-postadresser. Alumniadministratorer kan selv sende e-post til alle på listen, dette blir ikke utført av alumniløsningen.

5   Administrasjon av alumnibruker

Dersom man er registrert som administrator i alumni-systemet, skal man kunne endre på alle manuelle felter som alumnibrukeren kan endre på, for alle alumni.

Endring av fødselsdato og kjønn for manuelle alumni må skje vha. bofh, av en administrator i Cerebrum.

5.1   Administratortilgang

Tilgang til administrering av systemet, administrering av brukere og godkjenning av søknader vil styres av medlemsskap i en administratorgruppe i Cerebrum. Navnet på denne gruppen må angis i konfigurasjonsfil for alumni-løsningen.

Dersom det alt finnes en gruppe som dekker STA sitt ønske om administratorer, kan denne benyttes. Hvis ikke, må en slik gruppe opprettes manuelt.

Sikkerhetsutfordringer: Gruppemedlemsskap i administrator-gruppe for alumni-systemet styres manuelt, og må holdes oppdatert. Moderatortilgang for gruppen må tildeles passende personale.

5.2   Påminnelse om oppdatering av informasjon

Dersom administrator ser en alumni-konto med utdatert informasjon, skal det være mulig å sende ut en e-postmal, som ber brukeren oppdatere sin egen informasjon. Dette vil ikke være med i første omgang, men må utvikles i en eventuell ny versjon.

6   Egenadministrasjon av alumnibruker

Alumni har selv mulighet og ansvar for å holde informasjon om seg selv oppdatert. Hvilke felt som kan redigeres er beskrevet lenger oppe.

I tillegg vil alumni måtte endre passord jevnlig. Mer om dette under passordregime.

7   Søk

Alumniadministratorer skal kunne søke frem alumni basert på følgende informasjon:

Navn
Her må søk foregå på navn i fra FS. Man vil kunne benytte wildcards i dette feltet.
Utdanning/Grad
Høyeste oppnådde grad kan søkes på, og behandles som et fritekstfelt. Man vil kunne benytte wildcards i dette feltet.
Arbeidsgiver
Fritekstsøk etter arbeidsgiver. Man vil kunne benytte wildcards i dette feltet.
Stilling
Fritekstsøk etter stillingstittel. Man vil kunne benytte wildcards i dette feltet.

Støttede wildcards vil være ? (ett tegn) og * (flere tegn).

Flere søkevalg i samme felt vil returnere alumni som treffer ett av valgene (kombinatorisk OR). Søkevalg i flere ulike felter vil gi treff hvis samtlige felt treffer (kombinatorisk AND).

Søkeresultat vil inkludere de mest relevante feltene ved visning, men alumniadministratoren kan også hente ut en CSV-fil med alle felter.

Søkeresultat for visning er begrenset til maks 250 alumni, men CSV-filen har ingen begrensinger.

7.1   Søk for alumni

Det er ikke kapasitet til å støtte at andre enn administratorer kan søke på registrerte alumni i første versjon av alumniløsningen.

Alumni skal kunne søke opp tidligere studievenner, samt alumni med samme faglige bakgrunn. Disse skal derfor kunne benytte seg av søk i utvalgte felt:

  • Navn (Bare navn fra system:alumni). Ingen wilcard-støtte.

  • Eksaminasjonsår og/eller alder

  • Ekstern e-postadresse (ingen wildcards)

    Sikkerhetsutfordringer: Det må være mulig å reservere seg mot å dukke opp i slike søk. Hvilken informasjon skal man kunne se om andre alumni?

Denne funksjonaliteten vil ikke utvikles i første omgang.

8   Eksport

8.1   LDAP for alumnibrukere

TODO: Det er ikke avgjort enda om vi skal eksportere alumnibrukere til et eget LDAP-tre, som kan brukes av *weblogin.uio.no*, eller om vi skal eksportere de til organisasjonstreet, som blant annet brukes av Feide. Om alumnibrukerene eksporteres til katalogen som brukes av Feide vil de også få autentisert seg mot alle tjenester som bruker Feide-pålogging. Det er usikkert om vi vil måtte utvide eksporten til LDAP, eller om det er nok å oppdatere konfigurasjonen for disse.

TODO: Det må godkjennes av sikkerhetssjefen om vi eventuelt kan eksportere alumnibrukere til Feide. Siden vi ved innmelding i alumniløsningen både krever autentisering mot UiO-brukeren, sjekker studiestatus i FS før aksept, og har automatiske rutiner for avvikling av brukerene, oppfyller vi en del av kravene som Feide setter, og vi kan derfor la alumni få være med i Feide. TODO: Er det andre krav vi ikke oppfyller?

Med et eget LDAP-tre vil en måtte be katalog-drift om et nytt tre, og deretter få weblogin-drift til å sette opp denne som en ny brukerkilde som deretter kan brukes i tjenester som skal ha alumnibrukere. Cerebrum-miljøet må også settes opp med en eigen ldif-eksport for denne katalogen. Cerebrum må få et nytt spread til alumni som styrer tilgangen for dette treet, og vi må innføre automatikk for å sette og fjerne spreadet.

8.2   Mail-LDAP

TODO: Det er ikke avklart om vi skal støtte videresending for alumnibrukere.

Det er ønskelig å støtte videresending til ekstern e-postadresse for alumni, for detaljer om hvordan dette vil kunne gjøres, se dokumentet Vidaresending av e-post til alumnistudentar. Utfordringen med dette, er å unngå at ansatte og studenter får e-posten sin videresendt dersom de samtidig er alumni.

8.3   Sympa

E-postlistene vil modelleres i Cerebrum vha. grupper; En gruppe representerer en e-postliste. Hvilke grupper som hører til hvilke e-postlister, vil måtte spesifiseres in en konfigurasjonsfil. E-postlister må opprettes manuelt i Sympa sitt grensesnitt.

Sympa kan importere e-postadresser til en e-postliste fra en tekstfil – formatet på denne er ren tekstfil med en e-postadresse pr. linje. Slik import vil ikke berøre e-postadresser som blir lagt til vha. andre metoder, f.eks. via web-grensesnittet til Sympa.

Det må skrives eksport som går gjennom alle e-postlister definert i konfigurasjonsfil_, og lager medlemsliste for hver av disse. Eksporterte lister må flyttes over på Sympa-tjeneren for automatisk import til Sympa.

Kontoer som ikke har fått behandlet søknad eller blitt avvist (indikert vha. trait/karantene) vil ikke bli tatt med i en slik eksport.

@todo: Gruppe - spread. Ikke config.

9   Konfigurasjonsfil

  • Administratorgruppe
  • Prefix for interessegrupper.

9.1   Øvrige innstillinger

Glemt-passord-tjenesten konfigureres til å benytte telefonnummer i system:alumni for brukere som ikke er student eller ansatt. Dette vil gi manuelle alumni anledning til å benytte tjenesten.

10   Automatikk

10.1   Automatisk oppdatering av informasjon

Alle personer som skal eksporteres til Feide må komme fra et kildesystem, og må ha rutiner for oppdatering av personinformasjon.

Følgende felter må holdes oppdatert med informasjon fra FS:

  • Informasjon om oppnådd grad
  • Fødselsdag
  • Kjønn
  • Dødsfall
  • Navn

Fødselsdag, kjønn og dødsfall dekkes alt av FS-import for aktive studenter. Det må skrives automatikk for import av:

  • Informasjon om oppnådd grad, for alle tilknyttede alumni
  • Fødselsdag, kjønn og dødsfall for alle tilknyttede alumni, som også er inaktiv student
  • Navn. Denne oppdateringen kan gjøres for alle personer vi får fra FS, og ikke bare alumni. Bør begrense oss til berre alumni-personar i første runde, men skal bli designa slik at den skal kunne utvidast til å dekke alle. Sjå løysingsforslaget til ny studentautomatikk (TODO: url) for meir info om korleis dette kan løysast.

Kan vurdere om personløpenummer fra FS kan brukes i utplukkene i steden for fødselsnummer.

10.2   Opprydding

Alumni-kontoer som oppfyller visse kriterier, skal automatisk avvikles.

Vi må her passe på å ikke avvikle Person- eller Konto-objekter med andre tilknytninger enn Alumni. Vi må også se opp for Person-objekter med andre kontoer, og kontoer med spreads som man ikke får som alumni.

Manuelle alumni vil kunne «nukes», altså slettes helt fra Cerebrum. Dette vil ikke innføres i første omgang, grunnet tidsbegrensning.

Autopassord-karantene
Alumni-brukere med to år gammel autopassord-karantene kan avvikles, dersom dette er en ren alumni-konto.
Migrering
Dersom en migrert konto ikke blir tatt i bruk, vil den automatisk avvikles når auto_passord-karantenen er to år gammel.
Ikke-godkjente søknader
Ved avvising, vil brukeren miste eventuell alumni-relatert informasjon som er registrert umiddelbart. Tilknyttede brukere vil da håndteres av eksisterende automatikk, dersom de skal avvikles. Manuelle brukere vil måtte avvikles, og evt. «nukes» av egen automatikk. Slike brukere vil kunne gjenkjennes ved at de har utløpsdato og alumnisøker-karantene.
Studenter uten grad

Aktive studenter som har søkt og blitt godkjent som Alumni, er bare alumni så lenge de er aktive studenter. For å beholde tilgang til alumni-systemet, må de etter endt utdanning bli satt opp med en grad i FS. Dette vil FS-importen ta seg av.

En aktiv student vil ha studieprogrammet sitt registrert som en 'grad' i feltet for dette i alumni-systemet. Denne 'graden' vil forsvinne ved import fra FS etter endt studie. Dersom brukeren alt har, eller får en annen grad i dette feltet, vil det ikke være noen endring.

Dersom dette feltet derimot blir stående tomt etter endt studie, vil brukeren ikke lenger være alumni. Merk at dette bare gjelder tilknyttede brukere.

@todo: Ta bort affiliation? Vil dette være nok?

10.3   Rapporter

Automatiske rapporter kan opprettes etter behov, på lik linje med øvrige Cerebrum-rapporter. Rapporter kan plasseres under https://app.uio.no/usit/cerebrum/, eller sendes pr. epost til STA. Det er i første versjon ingen rapporter.

11   Web Service

All alumni-relatert kommunikasjon med Cerebrum skal gå gjennom en Web Service, basert på eksisterende Cerebrum Integration Services (CIS). Web Services vil være eneste grensesnitt mot Alumni-løsningen. Alle alumni-relaterte handlinger vil måtte foregå ved bruk av denne.

11.1   Autentisering

Autentisering vil skje gjennom den eksisterende CIS-modulen for dette. Servicen tar seg av autentisering med brukernavn og passord, samt session-håndtering. Det vil være opp til klient-applikasjonen (websidene) å sende med sesjonsnøkkel i spørringer mot andre moduler i en slik Web Service.

11.2   Alumni-modul(er)

Web Servicen vil være eneste grensesnitt mot Alumni-løsningen. Modulen må ha følgende funksjonalitet:

Registrering og søknad

Vi må ha funksjon for registrering av alumni. Søknad og registrering kan benytte seg av samme funksjon, da samme sett med data skal sendes inn. Det vil være opp til klient-applikasjonen å skille mellom registrering og søking, det vil være behov for en hjelpefunksjon til dette (gjøre oppslag i FS basert på innlogget bruker sitt brukernavn/personnummer).

Det vil også behøves en hjelpefunksjon for uthenting av standard-data for tilknyttet alumni.

Sammenslåing
Det må finnes en funksjon for å slå sammen to brukere. Denne funksjonen vil ta brukernavn og passord som argument. Den vil kontrollere at innlogget bruker ikke er alumni, og er en personlig brukerkonto. Hvis dette er tilfelle, og angitt brukernavn og passord er korrekt for en manuell alumni, vil sammenslåing kunne gjennomføres.
Oppdatere alumni-informasjon

Det må finnes en funksjon for oppdatering av alumni-data. Denne vil ta alle felt som er mulig å endre på, som parameter, samt brukernavn til alumni man vil oppdatere informasjon for.

Dersom man ikke har tilgang til å endre et felt for en alumni, vil må få feilmelding. Det samme gjelder om man har fylt inn ugyldig informasjon i et felt.

Hente ut alumni-informasjon
Vi må kunne hente ut registrert informasjon om en alumni.
Søking

Det må opprettes en funksjon for søking. Denne søke-funksjonen vil ta mange parametre, og returnere en liste med alumni.

Hvert enkelt søkeparameter vil kreve et gitt tilgangsnivå. Dersom en benytter seg av et søkeparameter som ikke man har tilgang til å benytte seg av, vil man få feilmelding.

Alumni-status
Vi må ha hjelpefunksjon for å finne ut om innlogget (ikke-alumni) bruker vil ha mulighet til å registrere seg selv, eller om vedkommende må sende inn søknad til STA.
Tilgang

Vi må ha hjelpefunksjon for å finne innlogget bruker sitt tilgangsnivå (manuell-, tilknyttet alumni, admin). Dette vil gi klienten mulighet til å tilpasse grensesnittet.

Operasjonen må ikke brukes som en sikkerhetsmekanisme – kontroller på om brukeren har tilgang til å utføre en gitt operasjon mot WS, må gjøres i WS.

12   Nettsider

Cerebrum utvikler et enkelt brukergrensesnitt for egenregistrering for alumnibrukere og for administrering av alumnibrukerene.

Nettsidene vil bruke samme rammeverket som Brukerinfo, men i ein oppgradert form.

13   Annet

  • Anbefaler å ha veiledning om navnebytte på hjelpesidene til alumniløsningen. Veiledningen må si noe om hvem en kan kontakte for å få navnebytte registrert.

Docutils System Messages

System Message: ERROR/3 ({DAVSYNC3}Alumni/teknisk-spesifikasjon.rst); backlinks: 1, 2, 3

Anonymous hyperlink mismatch: 3 references but 4 targets. See "backrefs" attribute for IDs.
Av fhl, jbr, jokim
Publisert 9. apr. 2014 07:02 - Sist endret 11. mai 2019 13:31
Del på e-post