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ä?

Toteutetaanko käyttötapaus ”A007a Läsnäolokaudet ja läsnäolot” vaihtoehdon 1 mukaan?

Mitä eroa on lukukaudella ja läsnäolokaudella lopulta eroa? Voiko läsnäolokausi olla jotain muuta kuin lukukausi?

Onko tarvetta merkitä L1 ja L2 jne? Nämähän voi laskea opiskeluoikeuden oletuskeston mukaan?

Voiko olla niin, että läsnäolorivit muodostuvat ainoastaan, mikäli poikkeuksia läsnäolokausiin

---

Täydennetty 30.9. / LS

• http://espdev.eduix.fi/studentregistry/mockups/PR-169/
  • Lukukaudet tulevat siis Pepistä.
  • Voidaanko perusrekisterin puolella olettaa, että läsnäolokaudet ovat tismalleen samoja vai tarvitseeko vielä erikseen asettaa läsnäolokaudet?
• http://espdev.eduix.fi/studentregistry/mockups/PR-102/entitlements.php
  • valitse Läsnäolotiedot -> Näet läsnäolokauden perustiedot, voit lisätä uuden läsnäolo
    
    • Onko tässä näkymässä tarvetta nyt esimerkkinä esiin laitetulle info-tiedolle? Tämä voisi kertoa hoverina esim. ”poikkeuksellisen” läsnäolotiedon tarkempia tietoja (esim. eronnot-tilanteessa)
  • nimeä klikkaamalla / Toiminnot-painikkeen kautta pääsee riveille. -> rivikohtaiset tiedot
  • (Tehty nyt javascriptillä niin back ei toimi. Mockupissa murupolku ei toimi oikein (vaatisi turhaa ylimääräistä säätöä); sovelluksessa luonnollisesti toimii kuten pitääkin.)
  • halutaanko rivejä speksin mukaisesti aidosti poistaa / muokata? Vai jätettäisiinkö historiatieto kuitenkin näkyviin suoraan tähän näkymään?

Miten vaihtoehdossa 1. esim. saadaan selville ne opiskelijat, jotka eivät ole tehneet läsnäoloilmoittautumista tulevalle tai meneillä olevalle kaudelle. Läsnäoloilmoittautumisen puuttuminen pitää tietää ilmoittautumisesta muistuttamisen vuoksi eli voi hakea ne opiskelijat, joilta tieto puuttuu ja sitten laittaa muistutuksia. Myös kauden alussa pitää olla mahdollisuus hakea ne opiskelijat, joilta läsnäoloilmoittautuminen puuttuu, että heille voidaan tallentaa OP-merkinnät.

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ä.

Tosin A017 kohtaan oli määritelty opinto-oikeuden menettäneen ja yhteishaun kautta uudelleen valitun opiskelijan entisen roolin muokkaaminen, mikä Tamkin näkökulmasta on vähän monimutkainen tapa. Tamkissa tehdään uusi rooli ja vanhat suoritustiedot siirretään uudelle roolille.

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.

kun luodaan uutta opiskelijaa ja haetaan opintopolku palvelusta hetun perusteella OID niin mitä tehdään ellei ko. opiskelijaa löydy sieltä? Rajapinnan avullahan sen voi luodakin sinne ilmeisesti. Mutta onko se perusrekisterin asia luoda tuonne opiskelijoita?

Opintopolusta päivitetään myös hakijoiden tiedot (vrk:n asemesta). Vastaus liittyy kokonaisuudessaan tähän.

Aktiivisten opiskelijoiden tietojen päivittäminen:

-       Pääkäyttäjän asetuksiin vaihtoehtoja:

• ”ei päivitetä”
• ”kerran viikossa” -> viikonpäivä + kellonaika
• ”määritä ajankohta” -> pvm + kellonaika
  • Tähän voisi määrittää useita päivitysajankohtia

En usko, että tuon useammin tarvitsee, jos tarvitsee niin manuaalisesti asettaa tuon ajankohdan…

Fiksummat voisi ottaa kantaa tuohon vanhojen opiskelijoiden OID-tietojen hakuun – itse ehdottaisin jotain työkalua, koska noita opiskelijoitahan tulee myös opintopolun ohi CSV:llä joten ei ole kertaluonteinen -> voisi käyttää opiskelijahakua (kehittynyt haku) ja ”päivitä näille opiskelijoille OID” -> jos listassa on opiskelijoita, joilla ei ole OID:tä, se päivitetään.

Nyt kun en tiedä miten tuo toimii opintopolun päässä niin osaako joku sanoa, miten käy tilanteessa, jossa meille tulee käsin tuotuna opiskelija perusrekisteriin –> ei oid:ta -> käydään hakemassa opiskelijalle OID, ja opiskelijalla onkin siellä jo olemassa OID, tunnistaako opintopolku samaksi henkilöksi tai miten tuo toimii ettei tule samalle henkilölle kahta OIDta?

-Mika