Teknisen toteutuksen Q & A

Peppi:

• Ei vielä selvillä, "kevään puolella" tässä vaiheessa aikamääreenä
• Mika täsmentää Pepin kehitysprojektin aikataulua
• Ei tiedossa tässä vaiheessa pilottitarpeita, mahdollisesti tulossa (mikäli tulee, käsitellään näissä palavereissa)
• Update 18.11.2019
  • Pepin riken kehityspaketti ykköstä ollaan parhaillaan testaamassa 2.0-versiota vasten

Primus/Wilma

• Käynnissä toimittajan kanssa suunnittelu toteutusmallista; pisimmällä ollaan Savonian tarjonnan esittämisestä muille
• Keväällä jossakin vaiheessa tavoiteaikataulu alustavasti
• Update 18.11.2019:
  • keskustelu käynnissä edelleen toimittajan kanssa; tehty konkreettinen ehdotus ja avainkysymys on, miten opiskelijalle näytetään laaja tarjonta ja mahdollisesti tehdään suodatuksia

Sisu

• Ensi vuoden syksyllä kälikehitys alkamassa, mahdollisesti jo sitä ennen rajapinnoista tietojen ulos ottaminen
• Täsmentyy vähitellen, mahdollisesti joidenkin tietojoukkojen (suoritukset esim.) osalta aiemmin 

RIPA

• Vähintään kuukausi ennen tuotantokäytön alkua oltava tieto tuotantoon siirtymisestä, ts. jos halutaan rajattua käyttöönottoa, siitäkin tieto hyvissä ajoin

Kuinka paljon ennen versioiden julkaisua ekosysteemeillä tulisi olla tieto tulevista muutoksista?

Versiointikäytännöistä dokumentti Versionumeroinnin kuvaus

Jos rikkovia muutoksia, viikon varoaika

Nyt 2.0 -versio on tulossa ja siinä mukavia rikkovia muutoksia.

Sovittiin, että hakufiltteröinti tehdään alkaneessa sprintissä kärkeen ja sisällytetään 2.0 -versioon - päivitetään heti valmistumisen jälkeen

Sovittiin, että päätös toteutustavasta valmistellaan kokouksen ulkopuolella. Katsotaan mm. yleisten konventioiden näkökulmasta, huomioidaan toteutuksen työmäärä tässä casessa ja mahdollisesti eskalaation näkökulmasta.

Päätös asap.

Sami:

"Lyhyen selvityksen perusteella tästä ei ole yhtä oikeaa hyvää käytäntöä, vaan tämä liittyy tapauskohtaisesti käytettyyn ohjelmointikirjastoon. Perustelut: projektissa on jo käytetty toteutuksessa tiettyä, yhden käytännön muotoista tapaa, Ripan päähän muutoksen laajuus olisi arvioituna verrattain suuri koskien kaikkia localizedstring-käsittelyja,  Pepin osalta arvioitu muutos oli suuruusluokaltaan rajallinen. -> pitäydytään nyt tehdyssä ratkaisussa."

Tiedossa ei ole, että muissa ekosysteemeissä olisi pohdittu tätä käyttötapausta.

Sami: 

Tässä voisi soveltaa sitä, että opintosuoritusten siirtoon on oma vaihtoehtoinen reititystyyppinsä, jossa ei käytetä opiskelijan rekisteröintipyynnön tietoja. Tämä on ajateltu sitä varten, että vaikka koko prosessia ei pystyttäisi aluksi tukemaan ilmoittautumisesta lähtien, niin suoritusten siirron automatisointi toisi silti hyötyjä. Vastaanottavassa päässä suorituksen kohdentaminen voi järjestelmästä riippuen vaatia jonkin toimenpiteen. Tuossa casessa ilmoittautuminen ei siis tapahtuisi palveluväylän kautta, ja jos opiskelija haluaa suorituksen viralliseksi, tuo prosessi tapahtuu järjestävässä korkeakoulussa. Tässä yhteydessä muodostettavaan opiskeluoikeuteen olisi tärkeä saada kotikorkeakoulun tieto, jonka perusteella suoritustiedon voisi välittää. Tämä voisi siis toimia nyt toteutetulla mallilla ihan ok.


Käydään läpi kokouksessa tikettien tavoite ja toteutusmahdollisuudet

Keskustelu

• Todettiin, että toiminnallisesti olisi hyödyllistä pystyä hakemaan samaan aikaan sekä opintokokonaisuuksien, -jaksojen että toteutusten tietoja
• Tarjontatiedot ja toteutustiedot ovat eri indekseissä, mikä tarkoittaa sitä, että ensin haetaan tarjonta ja sitten toteutukset 
• Mahdollista olisi toimia niin, että viedään vain hakua kiinnostavat toteutuksen kentät tarjontaindeksiin
• Edellyttää tiketin 365 tarkempaa määrittelyä, jotta tiedetään toteutusten relevantit kentät
• Työmäärällisesti muutos arviolta noin 3 - 4 htp
• Kokouksessa todettiin, että tämä olisi järkevä kehityssuunta
• Lauri juttelee Samin kanssa, onko ok lähteä muuttamaan. Jos ok
  • määritellään muutostarve
  • toteutetaan

Varmistetaan, onko määrittely ymmärretty oikein

• Ks. edellinen kohta

Pepillä ja Sisulla ei tarvetta studyElementIdentifierCode:lle, onko Primus/Wilmalla? 

• Ei ole tarvetta
• Arvioidaan muutostarvetta ja -vaihetta, kun kevään resurssitilanne selviää → Lauri R tekee tiketin

Onko Peppi-kehityksen kannalta tarpeellista saada kuinka paljon ennen stagingin päivitystä siitä tieto? Jos kriittistä, sovitaan päivitysmallista (esim: 1 pv ennen), jos ei, Gofore päivittää aina, kun sopiva hetki oman työn kannalta

Sovittiin seuraavasti:

• Maanantaina sprintin päättyessä uusi version vanhaan testiympäristöön noin klo 15.00
• Keskiviikkona päivitetään staging klo 12.00, jos ei ongelmia päivittämisen osalta 
• Muutetaan mallia tarvittaessa kokemusten mukaan

Primus/Wilma

• Neuvottelu käynnissä järjestelmätoimittajan kanssa.
• Perusjärjestelmää kehitetään mm. asennukseen liittyen (on-premisestä SaaSiksi), lisäksi Primuksesta ollaan mahdollisesti luopumassa eli Primus/Wilma/Kurre kaikki olisi selaimen kautta saatavilla

Peppi

• Ensimmäinen kehityspaketti laitettu kiinni, toisesta tehty noin puolet
  • Ykkösessä tarjontaan vieminen
  • Kakkosessa opintoihin ilmoittautuminen
  • Kolmosessa arviointi
• Kevään aikana tavoitteena saada kaikki osiot kuntoon Pepin osalta
• Muutamia löydöksiä uusien ripa-versioiden osalta tullut

Lisäksi tuotiin tiedoksi pakollisuuspalaverista, että

• opiskeluoikeuteen liittyen voi tehdä päivityksiä jatkossa

Pepin ristiinopiskeluprojekti:

Vanhalle ympäristölle ei välttämättä enää tarvetta, eli periaatteessa staging-ympäristö riittäisi. Lähtökohtaisesti päivitetään vain staging-ympäristöön.

Käytännössä virkailijamenettely.

Jos viestissä itsessään jotain pielessä, tulee virheilmoitus. Jos viesti ei mene perille → menee dlq, josta tieto korkeakoululle ettei mennyt perille.

Hylkäyksen syy-kenttä viesteihin olisi hyvä, alkuun vapaa kieleistetty tekstikenttä.

Opiskelijalle tiedot, mitä tietoja kulkee jne. olisi hyvä saada. Linkit kansallisen palvelun selosteisiin.

Onko tarve myös tarjota kohdekorkeakoulun tietosuojaselostetta?

Työn alla tällä hetkellä.

Korkeakoulukohtaiset selvitettävä.

Sijaluvun kuljettaminen ilmoittautumisen mukana

• monesko kokonaisuudessaan
• monesko ristiinopiskelijoista

Toteutukselle ilmoittautumisen kysymykset puuttuvat vaikka ovat toteutuksen luomisen yhteydessä

• ovatko aina tekstikenttiä, oFnko tarve muulle?
• kysymysten pakollisuus

Lisätään kysymykset ilmoittautumisen yhteyteen

Tekstikenttien osalta tiketti → tarkastellaan myöhemmin onko tarve muille

Pakollisuustiedot aiheuttavat vielä hieman ongelmia

Hakufiltteri, nyt näyttää kaikki muutkin verkostot vaikka pitäisi näkyä vain ne, joille oppija voi ilmoittautua. Tarkennetaan vielä tiketille RIPA-477 muut mahdolliset tapaukset liittyen filtteröinnin suhteen löytyneisiin haasteisiin.

Verkoston poisto toteutukselta ei onnistu.

Nykyinen validointisääntö: toteutuksella pitää olla vähintään yksi sama verkosto kuin opintojaksolla

Toteutuksen poiston voi tehdä, eli näissä tapauksissa poistetaan toteutus tai vanhennetaan liitos. Voi myös updatella laittaa kuntoon.

Olisi hyvä, että toteutus kuitenkin aina liittyisi opintojaksoon.

1.6. päätettiin, että RIPA sallii kaikkien verkostojen poistamisen. Teteutus spnt 23.

30.3.2020

1.6.2020

Onko teknisiä rajoitteita sille, että koko verkosto ei ota käyttöön palveluväylää?

Entä jos kaikki ko. verkoston korkeakoulut eivät lähde palveluväylän käyttöönottoon samaan aikaan? Mitä mutkia tuo matkaan? Onko siis järkeä lähteä palveluväylän käyttöönottoon jos verkoston kaikki korkeakoulut eivät pysty ottamaan käyttöön samoja teknisiä asioita yhtä aikaa?

Onko teknisiä rajoitteita sille, että verkoston korkeakoulut ottavat käyttöön eri "komponentteja"?

Entä, jos verkoston korkeakoulut eivät ota käyttöön kaikkien tietojen siirtoja, vaan vain esim. suoritusten siirron?

Ei periaatteessa pitäisi olla rajoitteita, ei sitten vastaa muihin viesteihin. Väylän kannalta onnistuu, pitää käyttää other-reititystyyppiä.

Pepin puoli rakennettu siitä näkökulmasta, että kokonaisuus on käytössä. Eli tarjonta - ilmoittautuminen - (opiskeluoikeuden luominen) - suoritus, eli taustalla täytyy olla tuo opiskelu-oikeus.

Filtterit ilmoittautumisen suhteen:

• ilmoittautuminen käynnissä nyt
• seuraavalle lukukaudelle
• sitä seuraavalle lukukaudelle

Only enrollable ja ilmoittautumisen päivämäärät kentät, mitä palauttavat? 

Arviointikohteiden filtteröiminen?

• Only enrollable hakuehto palauttaa vain opintoja, joiden suorilla toteutuksilla (courseUnit.realisations) ja arviointikohteiden toteutuksilla (courseUnit.completionOptions.assessmentItems.realisations) on kenttä "enrollmentClosed" = false.
• Arviointikohteiden toteutusten osalta aggregaattien tarpeellisuus täytyy vielä tarkistaa.

Erasmus_organisation_name

Käytetäänkö Isäntäolion name-kenttää vai erasmus-organisaation name-kenttää?

Erasmus-oppilaitoskoodi on eri kuin tk-koodi eli vähintään tiedetään nimi.

Tarvitseeko olla pakollinen?

Päättely käsittelemättömyydestä voidaan päätellä RIPAssa. Opiskelija silloin saisi aina vastauaksen ilmoittautuminen on ok/ei ole.

Testauksessa on huomattu: Jos ilmoittautumista ei käsitelty, voi perua vielä ilmoittautumisajan jälkeen. Silloin peruuntuu Pepissä, mutta ei vieraskorkeakoulussa, jolloin vieras voi hyväksyä, jolloin Pepissä palaa hyväksytty-tilaan (jne...). Korjataan sprintissä 22.

RIPA-517 Korjattiin huoltokatkon yhteydessä virhettä RIPA-470. Tuli uusi ongelma. Komentorivityökalut ei toimi.

Uusi ongelma: Apache konfissa Terena allekirjoittajana, selaimet luottaa tähän, mutta komentorivipohjaiset ei. Luottavat alla olevaan Digicertiin. 

Konfis-ongelma lienee Pepin päässä. Tämä pitää ratkaista elokuun alkuun mennessä. 

RIPA kuittaa vastaanotetun pyynnön, mutta ei jäädä odottamaan indeksointia.

Jos muutoksia json/skeemoihin, joka ei riko mitään, voidaan tehdä vain informoimalla. Jos tehdään rikkovia muutoksia, tuetaan vanhempia versioita, jos mahdollista.

Kehittäjien pitää päivittää Wikiin tekemänsä muutokset ja tulukot, jossa viimeaikaiset muutokset selvästi näkyvillä

Kohdekorkeakoulusta tulee paluusanoma ilmoittautumisen yhteydessä. Kun ilmoittautuminen hyväksytään, niin tulee opinto-oikeuden syntymisestä. Opiskelijan tiedot kohdekorkeakoulussa.

Miten saataisiin päivityksiä tulemaan → Kehityskohteeksi.

Update study right reply yhteydessä ei ole aukoton. Kohdekorkeakoulussa tehdään muutos _> triggeröi update study right reply

CourseUnitRealisation

• Toteutuksen skeemassa ei ole paikkaa toteutuksen nimelle

StudyElementReferences (CourseUnit OR AssessmentItem)

• Onko tämä joku luettelo opintojakson koodeista mitä toteutuksella voidaan suorittaa?

Kyllä. viittaus joko opintojakson tunnisteeseen tai arvioinninkohteen tunnisteeseen.

Miten opiskelija lyö lukkoon ilmoittautumisen yhteydessä että minkä opintojakson opiskelija suorittaa tämän toteutuksen yhteydessä jos vaihtoehtoja on useita (jotenkin olisi helpompaa että voisi suorittaa vain tietyn opintojakson aina eikä valintaa)

Ilmoittautumisen yhteydessä tämä valinta tulisi tehdä. Kun asiaa lähestytään siten, että esitettäisiin opintojakson ja sen toteutuksen tiedot yhdessä, tämä olisi ehkä yksinkertaisinta ratkaista. Jos opiskelijan hakunäkymässä haetaan tietoa toteutuksista, jolloin nämä viittaukset ovat lisätietoina, tässä voisi käyttää ensisijaisen opintojakson tietoa.

groupSelections

• Vaatii tarkan määrityksen miten tulee toimia eri tilanteissa (pitäisi olla ”yhteinen” käli eri järjestelmissä jotta tuon toiminnon monipuolisuus menisi aina samalla tavalla eri järjestelmissä)

Tätä on hyvä tarkentaa, on keskitetyn palvelun osalta toteutuksessa loppukeväällä.

questionSets

• Miten tämä pitäisi mallintaa koska meillä ei tällaisia ole mutta toisaalta tuo tieto pitäisi pystyä viemään sellaiseen korkeakouluun jolla tuo on käytössä. Ts. sama haaste kuin tuossa ensimmäisessä. Meillä ei ole siis tällä hetkellä tietomallia tällaisen tiedon käsittelyä/tallentamista varten..

Tätä on hyvä tarkentaa, on keskitetyn palvelun osalta toteutuksessa loppukeväällä.

Pitäisikö kansallisessa Rike-palvelussa (esim. verkoston luonnin yhteydessä) olla joku pakollinen linkki tai palvelussa tehtävä muotoiltava teksti (kieleistetty), johon laitetaan korkeakoulun info ja joka voidaan nostaa aina opintojen haun yhteyteen (kun opiskelija hakee opintojaksoja/toteutuksia). Tuo info siis kertoisi opiskelijalle

• Ennen ilmoittautumista
  • Ehkä jotain tietoa verkostosta
  • Kohdekorkeakoulun yhteystiedot
  • Linkit mistä voin katsoa opinnon (toteutuksen) opetusjärjestelyt etukäteen, esim. linkki lukkarikoneeeseen
• Ilmoittautumisen jälkeen
  • Miten saan tunnukset kohdekorkeakoulun järjestelmiin yms…

Kuulostaa järkevältä asialta, täytyy selvittää mikä olisi luontevin kohta tuolle tiedolle tai onko jokin olemassaoleva organisaation kuvaukseen liittyvä kenttä soveltuva tähän.

Täytyykö Pepin kysellä tietoja suoraan ES indeksistä ES:n käyttämällä notaatiolla? Vai tuleeko JSON/REST-rajapinnat

Onko heittää aikatauluarvioita milloin RIKE:n tarjoamat REST rajapinnat ovat saatavilla swagger muodossa? 

Onko verkoston id kenttä sama kuin vanhan määrityksen "yksilöivätunniste (OID)"?

Vastaavasti organisationId:ssa on varmaankin listattu verkoston organisaatioiden OIDit?

Tilanne, jossa opintojakson toteutus julkaistu kansalliseen rike-palveluun, mutta siihen liittyvää äitiopintoa (opintojakso) ei ole julkaistu kanalliseen palveluun.

• Voidaanko esim. Pepin päästä (jos halutaan julkaista vain toteutus) viedä mukana myös opintojakson tiedot vaikka itse opintojaksoa ei ole julkaistu rike-verkostoon? Ts. Rike-opiskelijan käyttöliittymään voisi hakea kansallisesta palvelusta opintojakson tiedot toteutuksen perusteella vaikka itse opintojaksoa ei olisi julkaistu.
• Jääkö kerran julkaistun opintojakson tiedot pysyvästi rike-palveluun? Esim. jos vanhennamme verkoston opintojaksolta niin ”vanhoille” opiskelijoille jää saataviksi edelleen opintojakson tiedot mm. käyttöliittymiin (saman tyyppinen case kun tuo missä toteutus on julkaistu mutta opintojakso ei).