Ymmärtääkseni OPH:n järjestelmältä kysytään Hetulla RESTin yli OID. OPH generoi OID:t, ei kukaan muu missään tilanteessa. OID on henkilökohtainen, eli vastaa Winhan hetua - ei OPRLI:a (opiskeluoikeusnumero) eikä OPISK:ia (opiskelijanumero), vaan hetua (henkilönumero).

Kyllä pitää. Numero generoidaan vuosiluvun kaksi jälkimmäistä lukua + viisinumeroinen juokseva numero.

Lauri Viitanen

Mika Lavikainen

Tähän olisi hyvä vielä saada vahvistus

Keskustellaan asiantuntijaryhmien kanssa tarkemmin opiskelijanumeron tarpeesta

Koodistosynkronoinnit

• Päivitysten sykli
• Mitä halutaan seurata ja millä tavoin (pääkäyttäjän palvelu)
• Milloin ja mitä koodistoja poistetaan?

ajatus että ei poisteta koodistoja tai koodeja vaan ne vanhennetaan

Ohjaustietojen suhde koodistoihin

"E012 Ohjaustietojen asettaminen Perusrekisterin pääkäyttäjälle on luotava näkymä, jossa hän voi asettaa lukuisia perusrekisteriä koskevia ohjaustietoja ja raporttipohjia.

Ohjaustiedot koostuvat toisaalta organisaatiorakenteen tiedoista, toisaalta perustiedoiksi nimetyistä koodituksista, luokitustermeistä ja muista erityisesti tilastointiin liittyvistä määrityksistä. Osa tiedoista, kuten organisaatiorakenteeseen liittyvät kustannuspaikkatiedot, ovat tallennettuina muihin järjestelmiin. Asetettavat ohjaustiedot löytyvät eri toimintojen sisäisistä kuvauksista."

Kävimme läpi yleisesti ohjaustieto-kokonaisuutta ja vaikuttaa siltä, että se on hyvin paljon päällekkäinen koodistonhallinnan kanssa. Käyttöliittymän näkökulmasta tuntuu turhalta erottaa koodistot ja ohjaustiedot omiin kokonaisuuksiinsa, ja onko se edes ylipäätään mahdollista? Voidaanko rajanvetoa edes tehdä? Onko enemmänkin kyse asiakkaan määrittelyssä käytetyistä termieroista?

Vaatimusmäärittelystä kerättyjä eri ohjaustyyppejä:

1) Ns. Perusmuotoiset, jotka asettuvat koodistomalliin. 
Näissä käyttöliittymänä toimisi jo koodistohallinnan peruskäli.

- koulutustyypit
- rahoitusmuodot
- arviointiasteikot
- pätevyystiedot (onko hierarkisia?)
- peruslista organisaatioista (virallinen ammattikorkeakoululistaus)
- eron syykoodit
- läsnäolokoodit (liittyy kausimaksimeihin)
- luovutusvalinnat
- kieli,direktiivi yms. lausekkeet (todistuksiin liittyvät)
- vapautuksen syyt

2) Haastavammat osiot, joille tehdään oma osio käyttöliittymään(?)
- kaudet (lukuvuosi, -kausi, periodi...)
- opiskeluoikeuden ilm.aika
- kausimaksimit (A014a taulukko)

Kysymykset asiakkaalle:
- voiko tällaisen sulautuksen tehdä?
- "Perusrekisterin pääkäyttäjälle on luotava näkymä, jossa hän voi asettaa lukuisia perusrekisteriä koskevia ohjaustietoja ja raporttipohjia". Mitä tässä tarkoitetaan raporttipohjilla? Millä tavalla liittyy ohjaustietoihin?

Ohjaustiedot/koodistot tarkoittavat mielestäni samaa asiaa eli voi sulauttaa. Nuo olisi kälissä hyvä pystyä kategorisoimaan järkevämmin kuin miten ne Pepissä on tällä hektellä (sikin sokin). Lisäksi koodistojen hallintaa pitää kehittää (Pepissä aika karmea käli tuohon).

Raporttipohjia on käsitelty VM:ssä esim. Diploma supplement, Todistuspohja, opiskeluoikeustodistus, kielilausekkeet (tämä saattaa olla kyllä osa todistuspohjaa koodistona tms. en ole varma)..

Lisäksi VM:ssä oli määritelty, että jossain tilanteissa hakutuloslistaus olisi pääkäyttäjän määrietltävissä (useita "pohjia" samalle listaukselle) Eli esim. mitä tietoja esim. opiskelijalistauksessa näytetään sarakkeissa. Pääkäyttäjä voisi luoda näitä näkymäpohjia useita, koska esim. opiskelijalistgoja tarvitaan/käytetään hyvin eri tarkoituksiin eri tiedoilla. Ts. käyttäjän näkökulmaasta olisi sama opiskelijahaku esim. hae koulutusohjelman X läsnäolevat opiskelijat ja käyttäjä valitsisi mitä pohjaa käytetään. Ydessä pohjassa vaikka vain opiskelijoiden nimet ja spostiosoitteet, toisessa pohjassa opiskelijan nimi, puhelinnumero ja käytetyt läsnäolokaudet tms.. Eli sama haku mutta eri tiedot halutaan näkyviin ja tässä kohdin olisi näitä eri pohjia joita pääkäyttäjä voisi luoda....

Tuossa VM:ssä tarkoitetaan ohjaustiedoilla yleisesti pääkäyttäjän asettamia tietoja/malleja...

Virve:

Myös kohdan 2 asiat eivät voisivat olla kohdassa 1

Raporttipohjat: tutkintotodistuspohja, opintosuoritusotteen pohja, opiskelutodistuspohja..ym. viralliset tulostettavat todistuspohjat. Pohjiin liittyvät ylätunnisteet, viralliset asettelut yms.

Ohjaustiedoissa määritellään käytettävät raporttipohjat, jottei jokainen tee ihan omannäköisiään maailmalle, työnantajille ja viranomaistahoille meneviä raporttipohjia.

Lykätäänkö käyttötapausten "A014a Opiskeluoikeuden kirjaaminen, lukuvuosi-ilmoittautumisen lisääminen" sekä "D001 Opiskelija ilmoittautuu läsnä-/poissaolevaksi lukuvuodelle" toteutusta odottamaan OILI-palvelun tuloksia ja tehdään keväällä päätös mahdollisesta toteuttamisesta?

Onko mahdollisesti muita käyttötapauksia, joita asiakkaan näkökulmasta tulisi lykätä johtuen KSHJ/OILI-kehityksestä?

1)Kirjataanko teillä molemmissa korkeakouluissa käyttäjänhallintajärjestelmiin aukottomasti tieto, josta voidaan päätellä, mihin työpöytiin käyttäjälle annetaan oikeus? Eli jos olet opettaja / ohjaaja, saat automaattisesti oikeudet tämän perusteella oikealla työpöydällä oikeisiin osioihin. Jaotellut roolithan (suluissa työpöytä) speksissä:

• Opintotoimisto (korkeakoulupalvelut)
• Hakutoimisto (korkeakoulupalvelut)
• Opettaja / tuutor-opettaja (ohjaaja) (opettaja ja ohjaaja)
• Opettajia ja ohjaajia ei eritellä käyttäjänhallinnassa?
• Opiskelija (opiskelija)
• Pääkäyttäjä (pääkäyttäjä (tosin speksin kohdassa E004 kirjattu, että korkeakoulupalvelut))
• Rehtori (korkeakoulupalvelut)

1. kysymys:

Käyttäjänhallintajärjestelmästä EI voida aukottomasti todentaa kenelle oikeus mihinkin työpöytään kuuluu vaan hienosäätö nykyisin Liferayssa. Ei etenkään siinä kohdin kun mennään perusrekisterin puolelle.. ks. kysymys 3 jatkoksi..

 2. kysymys

Tuossa on ajateltu sitä, että pääkäyttäjä on tuossa tapauksessa perusrekisterin pääkäyttäjä. Jatkossa tosin voi osa mennä ristiin Pepin pääkäyttäjätoimintojen kanssa eli pitäisi pystyä rajaamaan noita pääkäyttäjän toimintoja eri henkilöille (tai manuaalisesti ylläpidettäville rooleille, joihin liitetään tietyt pääkäyttäjät). Moduulilla tarkoitetaan sitä, että pääkäyttäjän erityistoiminnot rajataan omaan kategoriaan kokonaan (kuten ohjaustietojen asettaminen), johon korkeakoulupalveluilla ei ole mitään asiaa koskaan. Samoin mm. käyttäjäoikeuksien ylläpito tuonne moduuliin (toimintokokonaisuuteen).

3. kysymys:

Käyttöoikeusrooleja (absoluuttisia, nuo ovat hyviä arvauksia mitä luettelit) ei ole tiedossa ja ne joka tapauksessa muotoutuvat tarpeen mukaan (geneerisyys rooli/oikeusmatriisissa) -> vrt. se ressun roolimatriisi jossa voi luoda tarpeen mukaan uusia ressun sisäisiä rooleja, joille annetaan oikeuksia tiettyihin toimintoihin tarpeen mukaan. Näihin sisäisiin rooleihin voidaan yhdistää käyttäjiä automaattisesti perustuen käyttäjähallintajärjestelmän valmiisiin rooleihin ja/tai näihin rooleihin voidaan kytkeä käsin uusia henkilöitä.

A017

19.9.2014 projektipäällikköpalaverissa linjattiin, että jokaisesta läsnäolomerkinnästä tulee syntyä uusi rivi, ts. esim. opiskeluoikeuden palautuksessa ei muokata tai korvata vanhaa merkintää vaan luodaan aina uusi rivi, ja viimeisin käytännössä tarkoittaa voimassaolevaa opiskeluoikeuden statusta. Nythän käyttöliittymät on vaatimusmäärittelyn mukaisesti (A017) speksattu niin, että jokaista läsnäoloriviä voi muokata tai rivin voi poistaa (esim. virhetilanteita varten)

Linjaus on erilainen kuin vaatimusmäärittelyssä oli kirjattu. Laadunvarmistusmielessä pyytäisin siis vielä vahvistamaan, että toteutammeko tässä hieman eri tavoin kuin määrittelyssä oli todettu.

Mikäli tällä linjalla jatketaan, siitä seuraa kysymys, onko olemassa ylipäänsä enää lainkaan sellaista tilannetta, jossa läsnäoloriviä muokataan tai se poistetaan? Mikäli tällaisia tilanteita on, mitä ne ovat? Vien tämän kysymyksen tuttuun tapaan perusrekisterin Q&A-palstalle.

--

Lisäys 23.9. / LS

Huom. Myös käyttötapaus A007a on uuden linjauksen kanssa nyt ristiriidassa:

"Esimerkkinä tilanne,

jossa opiskelija on ilmoittautunut läsnäolevaksi syksylle 2013, mutta keskeyttää opintonsa
lokakuussa, tuolloin hänet merkitään eronneeksi, mutta hänen läsnäolokautensa (syksy 2013) jää
silti “läsnäolevaksi”."

A014a

"Kun opiskelija kirjaa itsensä (tai kirjataan) läsnäolevaksi tai poissaolevaksi lukukaudelle, hänelle syntyy automaattisesti vastaava läsnäolorivi. Erikoistapaukset kuten eroamiset yms. kirjataan opintosihteerin toimesta omiksi läsnäoloriveikseen." ALK: lisätään siis uusi rivi, ei muokata edellistä.

"Läsnäolokausien ja läsnäolorivien kirjaamisesta tulee jäädä aina merkintä, koska tieto on asetettu / muutettu ja kuka tallennuksen on tehnyt. Lisäksi läsnäoloriveille voidaan laittaa “Lisätieto”, joka on vapaa tekstikenttä (opintosihteeri kirjaa)." ALK: kyllä minun mielestäni VM on kirjoitettu siten, että jokaisesta läsnäolon muutoksesta tehdään uusi rivi. VM:ään on myös kirjoitettu, että riviä voidaan editoida (A017). Tarkistin vielä opintosihteereiltä käsitykseni ja olivat yhtä mieltä.

A021: Ahotointi: Winhassa on kirjattu vaihdossa suoritetut opintopisteet ahotointi (korvaava/muusuoritus) menetelmällä ihan ohjelmateknisten rajoitteiden vuoksi. Vaihdon suoritukset pitäisi kirjata muulla tapaa suoraan hopsiin, sillä vaihto tapahtuu opiskelujen aikana ja on normaalia toimintaa.

Lähtevän opiskelijan vaihdon suoritukseen pitää tulla merkintä, että suoritus on tapahtunut ulkomailla joko  opiskelijavaihdossa(ulk-ov) tai  harjoitteluvaihdossa (ulk-hv). Sen lisäksi pitää hopsin opintoon pystyä kirjoittamaan ulkomaisen oppilaitoksen nimi.