Entä jos poistan, katoaako samalla kaikki tiedot edellisistä varauksista?

Yritin muuttaa varauskohteen vanhentumispäivän, muttei se näköjään vaikuttanut mihinkään - ei näy millään tavalla,

ettei tästä päivästä alkaen saa tehdä varauksia, eikä tule estettä tehdä uusia varauksia.

Mikä on oikea tapa toimia? 16.05.2012

* Varauskohteen (esim. tilan) poisto ei vaikuta varauksiin muuten kuin siten, että varauskohteeseen liittyvät kuvaus- tms. tiedot katoavat. Emme kuitenkaan suosittele varauskohteen poistamista niin, että varaukset jäävät "orvoiksi".

* Vanhentumispäivä on puhtaasti informatiivinen eli ei vaikuta poimintoihin etc.

* Ainakin yksi asiakkaistamme tekee niin, että heillä on erityistilalaji vanhentuneita tai remontissa olevia tiloja varten. Sen alle siis siirretään kyseiset tilat. Raportit voidaan rajata jäljellejääneisiin, "aktiivisiin" tilalajeihin.

Käyttöoikeuksia rajaamalla voidaan estää käyttäjien pääsy vanhentuneet tilat sisältävään tilalajaiin.

Suoraan tilavarauksen kalenterien kautta tehtyä "irtovarausta" ei voi määritellä Asion lukkariin tietyksi pienryhmäksi.

Kannattaakin siksi tehdä aikojen lisäykset olemassaolevaan varaukseen, eli niin, että aika lisätään olemassaolevaan varaukseen. Kokonaan uudet pienryhmät puolestaan tulisi perustaa opetuksen suunnittelun kautta.

Tämmöinen tilanvaraukseen keskittyvä WS-rajapinta olisi itse asiassa huomattavasti monikäyttöisempi ratkaisu. Eli voisimme antaa WS-palvelulle syötteenä vain kurssitunnuksen / listan kurssitunnuksia ja se palauttaisi niiden tilanvaraustiedot kutsuvalle sovellukselle, oli se sitten plsql-proseduuri tai jokin muu kikkare.

Löytyisikö jotain valmista tai järkevällä vaivalla työstettävää ratkaisua tähän, hieman edellisestä tarkennettuun tarpeeseen? 16.05.2012

Tähän meiltä löytyy ainakin yksi läheltä liippaava mahdollinen ratkaisu suoraan ohjelmasta, eli RSS-syötteet kalentereista. Ominaisuus on yleiskäyttöinen kaikista Asion tilavarausohjelmasta löytyvistä kalenterista, ja toimii siten että kun HTTP-pyyntöön syöttää parametrin "outmode" arvolla "rss" tai "rss_days", tulee ohjelmistolta vastauksena sama kalenteri RSS-muodossa. Arvo "rss" antaa syötteen jossa on yksi item per varaus, ja "rss_days" syötteen jossa on yksi item per päivä.

Tässä pari esimerkkiä:

https://amp.jamk.fi/asio_v930/kalenterit2/index.php?av=120521120527&ckurssi=ZZCAR111.2K0z1&kt=co&outmode=rss https://amp.jamk.fi/asio_v930/kalenterit2/index.php?av=120521120527&ckurssi=ZZCAR111.2K0z1&kt=co&outmode=rss_days

Lisäämällä urliin guest-parametrin "&guest=/jkl" siitä saa version joka ei kysele tunnareita.

Tässä on vielä tiivis ohje mitä muita parametreja RSS-kurssikalenteri tukee. Voi olla että jotkut näistä eivät toimi tuolla linkittämälläni versiolla, vaan vaativat meidän tuoreimman järjestelmäversion v12.

- kt = "co", kiinteä teksti joka kertoo kyseessä olevan kurssikalenteri

- outmode = "rss", kiinteä teksti joka valitsee tulostusmuodoksi RSS:n.

- ckurssi = kurssin tunnus

- av = aikavälin määrittely, ensin alku- ja sitten loppupäivä, molemmat kuudella merkillä muodossa VVKKPP

Yksi outmode vielä jota kannattaa kokeilla on "vcal", joka antaa saman kalenterin vcalendar-muotoisena tiedostona. Asion versio 12 tukee myös outmodea "webcal" joka antaa iCalendar-muotoisen tiedoston, ja on yhteensopiva mm. Applen laitteissa ja Outlookin Internet-kalentererissa käytettävän webcal-protokollan kanssa.

Meillä on suunnitelmissa on linkittää Asion lukkariin päivittyviä tietoja ja näkymiä Asion järjestelmän ulkopuolelle, että niitä voisi tarkastella kirjautumatta sisään.

Jos otetaan caseksi seuraava kurssi/näkymä. Tässä tapauksessa olennaista olisi, että klikkaaja näkee päivitetyt tiedot kaikista kurssin opetusajankohdista yhdellä silmäyksellä.

http://tila.teak.fi/kalenterit2/index.php?func=opisklk&lukuk=2012S&b_tarjonta=1&tar[]=05-VXL002%7C%7CV%C4S

1) Saako tuohon URLiin jotain parametriä, jonka avulla voisi ohittaa kirjautumisen?

Sama pulma tietojen tarkastelusta kirjautumatta koskee myös ryhmäkalenterien linkittämistä toisaalle. Mitä saisi eri ryhmiä koskevat ryhmäkalenterit linkitettyä ulkopuolisille sivuille niin, että klikkaaja saisi tiedon ilman omatoimista kirjautumista?

Esim. seuraava näkymä:

http://tila.teak.fi/kalenterit2/index.php?kt=lk&yks=&cluokka=V%C4S1&lang=fin

2) Onko teillä muuten ohjetta siitä, miten URLien avulla voi tuottaa haluttuja näkymiä? 02.05.2012

Kirjautumisen ohittava parametri urlissa on "guest=/teak", eli esim. tällaisella urlilla tulee näkyviin mainitsemasi lukkarin toteutusnäkymä:

http://tila.teak.fi/kalenterit2/index.php?func=opisklk&lukuk=2012S&b_tarjonta=1&tar[]=05-VXL002%7C%7CV%C4S&guest=/teak

Sama parametri toimii globaalisti, eli sitä voi soveltaa kaikkiin sellaisiin näkymiin jotka on sallittu käytettäväksi kirjautumattomille.

Meillä ei valitettavasti ole valmista ohjetta erilaisten näkymien muodostukseen, mutta voin kirjoittaa ohjeita jos laitat tietoa siitä, millaisia näkymiä haluatte nostaa Asion ulkopuolelle näkyviin.

Tässä vielä esimerkkkinä pari viikkokalenterinäkymän parametria, jotka voivat olla kiinnostavia:

- Parametri "ui" määrittelee käyttöliittymän tyypin, arvot: -- tyhjä tai ei annettu = täysi Asion valikko ruudun vasemmalla palstalla -- 1 = valikot piilossa, viikkovalinta näkyvissä -- 3 = viikkovalinta piilossa

- Parametrilla "print" saat ulos tulostettavan version, jossa ei ole muuta käyttöliittymää kuin itse kalenteri. Arvojoukko: -- netti = värillinen kalenteri ma-pe kalenteri, jos la-su ei ole varauksia, parametrilla "kaikkipaivat=1" saat myös la-su aina näkyviin -- arkipaivat = mustavalkoinen ma-pe kalenteri, jos la-su ei ole varauksia -- kaikkipaivat = mustavalkoinen ma-su kalenteri

- Parametrilla "outmode" voit ottaa kalenterista vielä muutamia versioita ulos -- excel_inline = karkeampi HTML-taulukkoversio kalenterista 2 tunnin jaolla -- rss = kalenteri RSS-syötteenä -- rss_days = kalenteri RSS-syötteenä siten, että yksi päivä on syötteessä yksi item

- Kalenterin aikavälin määritteleminen RSS-syötteisiin -- av = alkupäivä muodossa VVKKPP -- pvlkm = päiviä eteenpäin, esim. 1 = vain kuluva päivä, 7 = viikko nykyhetkestä eteenpäin

Asio-järjestelmä itsessään sisältää ainoastaan suhteellisia viittauksia itseensä, eli se toimii domain-riippumattomasti ja lisäksi missä tahansa polussa palvelimella ilman konfiguraatiomuutoksia.

Varusohjelmiin ja integraatioihin liittyen voi kuitenkin olla joitain muutostarpeita:

1) Apachen käyttämät HTTPS-sertifikaatit pitää luonnollisesti uusia, ellei niissä ole uusia nimiä jo valmiina allekirjoitettuna

2) Jos AD-palvelinten domainit vaihtuvat myös, on syytä päivittää ulkoisen kirjautumisjärjestelmän konfiguraatio (inc/server_settings.php, $ext_udb_config) domainien osalta ajan tasalle.

Muuta ei oikeastaan tule mieleen, eli tämän pitäisi olla helppo juttu. Suosittelisin kuitenkin että ennen tuotannon siirtämistä Asiota joko testataan uudessa domainissa testikoneella, tai vaihtoehtoisesti tuotannon siirtoon varataan sen verran pitkä huoltokatko että mahdollisesti ilmeneviä ongelmia ehditään selvittää.

Joskus sain Jukalta ohjeeksi tehdä tämä Suhteellisen kohdeajan kautta, mutta en saanut sitä onnistumaan sillä. Nyt yritän tehdä monta peräkkäistä estoa, yksi esto kutakin viikkoa kohden. Jostain syystä en saa toista estoa näkyviin millään. 23.03.2012

Kyllä pitäisi olla mahdollista tehdä useita samanaikaisia varausestoja, ja jopa samojen tilojen samoille päiville jos estot ovat esim. kellonaika- tai käyttäjäryhmäkohtaisia.

Eston näkyvyydestä sellainen huomio, että oletuksena esto ei koske pääkäyttäjiä, eli voi olla että esto on päällä mutta et vain näe sitä omilla tunnareillasi. Jos et keksi mistä ongelma johtuu, niin laitatko tarkemman esimerkin niin selvittelen.

Suhteellisilla varausestoilla ei pysty tekemään valitettavasti täsmälleen tuota määrittelemääsi tapausta, eli että seuraava viikko avautuu automaattisesti edellisen viikon torstaina. Viikon tarkkuudella se onnistuisi, eli joko niin että vain kuluva viikko on varattavissa, tai että kuluva ja ensi viikko on varattavissa.

Laitoin RSS-syötteiden muodostusta varten tarvittavan ohjelmapalikan paikalleen teidän palvelimella olevaan liikunta -versioon Asio-tilavarauksesta, jotta pääsette testailemaan syötteitä oikealla aineistolla. Tein lisäksi RSS-syötteitä varten järjestelmään käyttäjätunnuksen "rssuser", salasanan "testi" jolla on sopivat selailukäyttöoikeudet syötteiden näyttämiseen.

Syötteen saa Asiosta ulos muotoilemalla kalenterikutsun URL:n tietyllä tavalla. Seuraavassa on kaksi esimerkkiä, sekä ohjeet käytettävistä URL-parametreistä.

Tässä esimerkki Arcanum-lajin tilojen (Arc1, Arc2, Arc3) varauksista yhtenä syötteenä torstailta 01.03.2012: https://asio.utu.fi/liikunta/kalenterit2/index.php?kt=tila&ctila=238,244,245&outmode=rss&av=120301&pvlkm=0

Toinen esimerkki, samojen tilojen varaukset nykyhetkestä 14 vrk eteenpäin niputettuna päivätasolle: https://asio.utu.fi/liikunta/kalenterit2/index.php?kt=tila&ctila=238,244,245&outmode=rss_days&av=&pvlkm=14

Seuraavassa parametrien selitteet:

- kt = "tila", välitä tämä vakioarvo, tarkoittaa että halutaan tilakalenterien varauksia.

- ctila = Lista haluttujen varauskohteiden rivinumeroista. Voit välittää useita pilkkueroteltuna. Rivinumero löytyy helpoiten tilakalentereja selaamalla, se tulee urliin saman nimisenä parametrina "ctila".

- outmode = Arvolla "rss" ohjelma palauttaa syötteen jossa jokainen varaus on omana item-elementtinä. Arvolla "rss_days" palauttaa alunperin Teatterikorkeakoulun tarpeisiin tehdyn syötteen jossa on yksi item per päivä.

- av = Alkupäivä muodossa VVKKPP. Jos välität tämän tyhjänä, näytetään kaikki tulevaisuudessa olevat + meneillään olevat varaukset

- pvlkm = Monta päivää eteenpäin alkupäivästä varauksia poimitaan mukaan. Esim: arvo 0 = vain alkupäivä.

- guest = Selailumoodi, ei kirjautumista. Arvona välitetään ympäristön tunniste joka on teillä "/utu". Jos haluat avata tämän kirjautumattoman käytön, niin järjestelmäänne pitää luoda ylläpitotoimintojen kautta uusi rooli jonka tunniste on "guest". Tässä roolissa määritellään ilman kirjautumista järjestelmää käyttävien henkilöiden käyttöoikeus.

Syötteet luodaan aina reaaliaikaisen tilanteen mukaan järjestelmästä, eli erillistä syötteiden päivityssykliä ei Asion puolella ole olemassa.

Testasin varausestoon usean yksittäisen tilan lisäämistä kerralla, ja sen pitäisi onnistua seuraavalla tavalla tehtynä:

1) Klikkaa blokatut tilat -kohdasta "Hae useita" -painiketta

2) Hae tilat hakutoiminnon avulla ja ruksaa hakutuloksista haluamasi

3) Klikkaa hakutulosten yläpuolelta tai alapuolelta "poimi valitut tilat" painiketta

Lopputuloksen pitäisi tässä vaiheessa olla se, että valitsemasi tilat nousevat varauseston blokatut tilat -kohtaan.

Tilavalintojen määrittely on tosiaan hieman kömpelöä, jos tarvitsee lisätä useita rakennuksia kerralla. Tällöin pitää aina kerran klikata välitallennusta, jotta syöttölomakkeelle tulee uusi tyhjä rivi. Laitan kehityslistalle tämän kohdan parantamisen, voisi olla kaikessa yksinkertaisuudessaan riittävää jos tuossa kohdassa olisi oletuksena enemmän kuin yksi tyhjä rivi "tyrkyllä".

Järjestelmässämme ei ole tiettyyn Info-Tv -järjestelmään liittyvää valmista rajapintaa. Sen sijaan on käytettävissä yleisiä toimintoja, joista saattaa olla apua.

1) Jos haluat aulanäyttöön aina ajan tasalla olevan linkin tietyn tilan HTML-muotoiseen kalenteriin, saat sen esiin jättämällä aikaväliparametrin "av" pois urlista:

https://tilat.laurea.fi/asio/kalenterit2/index.php?kt=tila%2C376&laji=Tikkurila%2FATK-tilat||%25&guest=vierrool%2Flaurea&lang=fin&ctila=2219&print=netti

2) Jos aulajärjestelmänne tukee RSS-syötteiden näyttämistä suoraan, voisi siinä olla hyvä tapa nostaa dataa näytöille.

Tässä esimerkki kolmen atk-tilan varauksista yhtenä syötteenä torstailta 26.01.2012: https://tilat.laurea.fi/asio/kalenterit2/index.php?kt=tila&ctila=2213,2214,2219&outmode=rss&av=120126&pvlkm=0&guest=vierrool/laurea

Toinen esimerkki, samojen tilojen varaukset nykyhetkestä 2 vrk eteenpäin niputettuna päivätasolle: https://tilat.laurea.fi/asio/kalenterit2/index.php?kt=tila&ctila=2213,2214,2219&outmode=rss_days&av=&pvlkm=1&guest=vierrool/laurea

Seuraavassa parametrien selitteet:

- kt = "tila", välitä tämä vakioarvo, tarkoittaa että halutaan tilakalenterien varauksia.

- ctila = Lista haluttujen varauskohteiden rivinumeroista. Voit välittää useita pilkkueroteltuna. Rivinumero löytyy helpoiten tilakalentereja selaamalla, se tulee urliin saman nimisenä parametrina "ctila".

- outmode = Arvolla "rss" ohjelma palauttaa syötteen jossa jokainen varaus on omana item-elementtinä. Arvolla "rss_days" palauttaa alunperin Teatterikorkeakoulun tarpeisiin tehdyn syötteen jossa on yksi item per päivä.

- av = Alkupäivä muodossa VVKKPP. Jos välität tämän tyhjänä, näytetään kaikki tulevaisuudessa olevat + meneillään olevat varaukset

- pvlkm = Monta päivää eteenpäin alkupäivästä varauksia poimitaan mukaan. Esim: arvo 0 = vain alkupäivä.

- guest = Selailumoodi, ei kirjautumista. Arvona välitetään ympäristön tunniste joka on teillä "vierrool/laurea".

Tällainen onnistuu siten, että luodaan muita käyttäjiä varten Asioon uusi rooli, joka sen jälkeen sidotaan profilointikonfiguraatiosta koskemaan kaikkia niitä käyttäjiä, joilla ei ole muuta voimassaolevaa profilointisääntöä.

Tässä pikaohje:

1) Tee uusi rooli selailukäyttäjille, esim. tunnuksella "asio_selaus" ja määrittele siihen sopivat oikeudet.

2) Avaa tekstieditoriin Asio-palvelimelta tiedosto inc/server_settings.php ja etsi profilointikonfiguraation $ext_profiler_config rivi joka alkaa "browsing_groups"

3) Korvaa em. riviltä teksti "browsing_groups" tekstillä "asio_selaus_groups"

4) Lisää vielä asio_selaus -ryhmälle määrittely roles-kohtaan, listan loppuun:

"roles"=>array("admin","Opettajat","asio_varaus","asio_selaus"),

5) Tallenna konfiguraatio

Tämän jälkeen kun kirjaudut uudestaan sisään järjestelmään sellaisella tunnuksella, jolla ei ole Asio_Varaus- tai Asio_Opettajat -ryhmäjäsenyyttä pitäisi käyttäjälle tulla roolin asio_selaus mukaiset oikeudet.

Jos et saa tätä toimimaan niin voin selvitellä asiaa meidän huoltoyhteytemme kautta. Tässä tapauksessa otatko meidän asio-test -tunnuksesta pois ryhmäjäsenyyden Asio_Varaus.

Tiedostojen selaus- ja lähetystoimintojen käyttö edellyttää, että henkilön roolina on ylläpitäjä, eli pelkkä ylläpito-oikeus ko. tilaan ei riitä. Näin siksi, että tiedostolista on kaikille tiloille yhteinen. Laitamme korvan taakse josko ohjelman antamaa virheilmoitusta ja ohjeita voisi parantaa tältä osin.

Tässä pikaohje ongelman ratkaisemiseksi Mona Forsblomin tapauksessa:

1) Avaa ylläpitotoiminnot (päävalikosta Ylläpito -> Ylläpitotoiminnot)

2) Hae Mona Forsblomin käyttäjätietue esiin

3) Vaihda kohdasta "Rooli" arvoksi "Ylläpitäjä". Älä vielä tallenna heti tämän jälkeen, vaan ruksaa vielä pois automaattisesti aktivoituva ruksi "Oletusoikeudet kaikkiin lajeihin" kohdasta "Tilalajirajaus" jotta tilalajikohtaisesti asetettu oikeustaso säilyy roolin vaihtamisen jälkeenkin.

4) Tallenna tiedot --> tämän jälkeen Mona Forsblomilla on oikeus lähettää tiedostoja

Jäsenrekisteriohjelmiston ja Oracle-pohjaisen Asio-opiskelijahallinto-ohjelmiston välillä on tietojen synkronointirajapinta, joka toimii seuraavalla tavalla:

1) Tiedot päivitetään automaattisesti aina, kun henkilö ilmoittautuu läsnäolevaksi jäsenrekisterin online-ilmoittautumistoiminnon avulla.

2) Tietojen päivitykseen löytyy lisäksi toimistopuolen työkalu, jolla voidaan päivittää yksittäinen opiskellija tai koko rekisteri. Työkalu löytyy päävalikosta kohdasta "Synkronointi", ja etusivulta voi joko lähteä päivittämään tiettyä päivämäärää uudempia tietoja, kaikkia tietoja tai yksittäistä opiskelijaa nimen tai opiskelijanumeron pohjalta.

Tietojen ajan tasalla pysymisen vuoksi olisi hyvä ajaa esim. parin kuukauden välein synkronointiohjelma toimistopuolen kautta. Suosittelen että tällöin käytetään muutospäivän mukaan päivittämistä, sillä koko rekkarin synkronointi voi olla hidasta.

Henkilörekisterissä olevaa henkilön tunniste -tietoa ei pääse vaihtamaan käyttöliittymien kautta suoraan, eli tällainen muutos edellyttää tiedon päivittämistä suoraan tietokantaan.

Koska henkilön tunniste on avaintieto, pitää samalla päivittää ko. tieto myös muihin viittaaviin tauluihin, joita ovat varauskohderekisteri (palvelu_p) sekä käyttöoikeusrekisteri (asio.kayttooikeus_p).

Tässä on esimerkkikyselyt, joilla voit tehdä vaihdoksen 7785 => 007785 suoraan MySQL-kannan kautta:

UPDATE person_p SET person_id = '007785' WHERE person_id = '7785 '; UPDATE palvelu_p SET henkilotun = '007785' WHERE henkilotun = '7785 '; UPDATE asio.kayttooikeus_p SET henkilotun = '007785' WHERE henkilotun = '7785 ';

Tämä pitää paikkansa, eli transaktiomallia ei ole WS-rajapintojen yhteydessä olemassa, koska toiminta on webin periaatteiden tapaan tilatonta. Jokaisen päivitysoperaation tulos menee näin ollen itsenäisenä läpi Oodin tietokantaan.

Ratkaisussamme on kaksi erillistä mekanismia, jolla pyritään minimoimaan tästä mahdollisesti käyttäjälle aiheutuvia ongelmia:

1) Rajapintasiirto-ohjelma tarkistaa opetustapahtumakohtaisesti tietyt yleisimmät virhetilanteet ennen siirron aloittamista ja ilmoittaa niistä käyttäjälle. Virheellistä opetustapahtumaa ei siirretä lainkaan. Tarkistettavia virheitä ovat esim. surrogaattien sekä rajapintasiirrossa tarvittavien kooditusten puuttuminen. Siirto-ohjelman käyttäjällä on mahdollisuus lisäksi ajaa tämä sama virhetarkistus ilman siirron tekemistä.

2) Siirretyt opetustapahtumat voi helposti poistaa Oodista, eli jos jotain odottamatonta tapahtuu, voidaan siirto perua, korjata virhe ja yrittää uudestaan.

Olisi toki kokonaisuuden kannalta parempi jos rajapinnasta löytyisi yksi koottu operaatio jolla voisimme luoda tai päivittää kerralla opetustapahtuman kaikki tiedot alaobjekteineen. Tällöin rajapinnan päässä olisi mahdollista toteuttaa oikea transaktiomalli, ja luulen että suorituskykykin paranisi kutsujen määrän vähenemisen takia.

Tein viime keväällä testejä MariaDB:n kanssa, ja homma kaatui loppupeleissä siihen että en saanut tietokantaa kirveelläkään asennettua ja käyntiin

MariaDB on suunniteltu olemaan drop-in-replacement MySQL:lle, eli myöskin Asion pitäisi toimia siinä ongelmitta. Käytämme AsioEduERP:ssä tietoisesti hyvin rajattua settiä SQL-kyselyjä ja ominaisuuksia, jotta tietokantojen yhteensopivuus olisi mahdollisimman hyvä. Tällä hetkellä yhteensopivuus ulottuu MySQL:n versioon 3.23 asti, vaikkakin vähintään versio 4.1 on suositeltu.

MariaDB kiinnostaa meitäkin kovasti -- MySQL ei ole enää ilmainen ja itse pelkään hintojen vain nousevan nyt kun omistus on Oraclella. Jos teillä on esim. virtuaalikoneita joille saatte MariaDB:n pyörimään niin kuulisimme mielellään Asio-kokemuksia ja auttaisimme toki myös mahdollisten yhteensopivuuskurttujen oikaisussa.

Asio tallentaa tällä hetkellä salasanat suolattuina MD5-hasheinä. SHA-256:n käyttöönotto olisi kohtuullisen helppoa, puhutaan korkeintaan muutamien päivien työstä meidän puolelta.

En itse näe kuitenkaan suuren suurta hyötyä hash-tekniikan vaihtamisesta SHA-256:een -- tokihan SHA-256 antaa toiseen potenssiin paremman hashin, mutta MD5 mielestäni riittävän hyvä kunhan siinä vain on mukana suola.

Kryptauksessa on aina ongelmana se, että jossain täytyy säilyttää salauksen purkamiseen tarvittavaa avainta. Jos hyökkääjä saa avaimen käsiinsä, ei kryptauksesta ole iloa. Avainta jouduttauisi säilyttämään käytännössä samalla Asio-palvelimella.

Luottokorttitietoja ei tietääkseni ole tarpeen koskaan säilyttää Asiossa, vaikka käytössä olisi verkkomaksuliitäntä. Maksuliikenne tapahtuu tällöin asiakkaan ja Verkkomaksut.fi -palvelun välillä, ja Asioon tulee vain tieto onnistuneesta maksusta.

Henkilötiedoista henkilöturvatunnus on Asioon nykyisellään tallennettavista tiedoista mielestäni se, jonka säilyttämiseen tulee kiinnittää eniten huomiota. Ajatuksenamme on että tietokannassa säilytettäisi vain ne sotut jotka ovat täysin välttämätöntä säilyttää, ja tietyn ajan jälkeen ne joko hävitetään tai ainakin sotketaan osittain. 31.10.2011

Varauskohteen poisto ei poista varauksia tietokannasta, eli opettajan poisto ei hävitä esim. ryhmän tai tilan kalenterista varauksia.

Opettajan poisto näkyisi järjestelmässä seuraavilla tavoilla:

1) Opettajan kalenteria ei saa enää näkyviin henkilökalenterit-toiminnon kautta.

2) Opettajan nimi voi tietyistä näytöistä pudota myös pois, niistä paikoista joissa se haetaan varauskohderekisteristä eikä varauksen tiedoista. En valitettavasti muista ulkoa kaikkia paikkoja joissa nimi nostetaan varauskohderekisteristä, mutta tämä asiana joka tapauksessa tiedoksi. Kryptauksessa on aina ongelmana se, että jossain täytyy säilyttää salauksen purkamiseen tarvittavaa avainta. Jos hyökkääjä saa avaimen käsiinsä, ei kryptauksesta ole iloa. Avainta jouduttauisi säilyttämään käytännössä samalla Asio-palvelimella.

Luottokorttitietoja ei tietääkseni ole tarpeen koskaan säilyttää Asiossa, vaikka käytössä olisi verkkomaksuliitäntä. Maksuliikenne tapahtuu tällöin asiakkaan ja Verkkomaksut.fi -palvelun välillä, ja Asioon tulee vain tieto onnistuneesta maksusta.

Henkilötiedoista henkilöturvatunnus on Asioon nykyisellään tallennettavista tiedoista mielestäni se, jonka säilyttämiseen tulee kiinnittää eniten huomiota. Ajatuksenamme on että tietokannassa säilytettäisi vain ne sotut jotka ovat täysin välttämätöntä säilyttää, ja tietyn ajan jälkeen ne joko hävitetään tai ainakin sotketaan osittain. 31.10.2011

Oliko teillä tuo kurssiilmon lomake jossain julkisen puolen netissä näkyvissä? Sisäänmeno tapahtuu aina XXXn kautta, mutta Ilmeisesti osoite on päässyt vuotamaan esim. jonkun opiskelijan selaimen bookmarkseista haittaohjelman kautta ulkomaailmaan, ja sitten spämmirobotti alkanut täyttää lomaketta innokkaasti.

Teidän Asio on niin "pieni kala" spämmääjien näkökulmasta, että robotti on selvästi joku yleinen vekotin eikä kukaan siis erityisen tietoisesti yritä hyökätä teitä vastaan.

Näin ollen järjestelmä joka estää spämmin lähettämisen kurssiilmoon ei tarvitsisi olla kovin monimutkainen, ja uskoisin siihen riittävän esim. seuraavanlaisen ratkaisun:

1) Lomakkeella lukisi tekstinä jossain kohdassa esim. "Varmistuskoodi: 1A2B"

2) Lomakkeen lopussa olisi kenttä "Syötä varmistuskoodi:" johon käyttäjän pitää syöttää oikea varmistuskoodi ennenkuin lomake suostutaan tallentaamaan.

Normaalisti tällaiset järjestelmät vaativat varmistustiedon generoinnin esim. kuvaksi ja lisäksi kuvan sotkemisen jottei spämmibotti pysty ratkaisemaan tehtävää kuvantunnistuksella.

Toinen mikä voisi toimia on että lisätään suomenkielisiin pakollisiin kenttiin validointia. Esimerkkinä postinumero on sellainen johon voitaisi vaatia numeerinen arvo. Toki esim. Ison-Britannian postikoodit voivat sisältää kirjaimia, joten tämä ei toimi mikäli teillä on opiskelijoina ulkomaalaisia.

Spämmejä voi yrittää siivota kurssiilmo_p -taulusta ip-osoitteen avulla. IP-osoite tallennetaan kenttään "ip" ja spämmeistä voisi katsoa josko ne ovat kaikki tulleet samasta IP:stä. Jos ovat, ja lisäksi samasta IP:stä ei ole oikean näköisiä ilmoja, niin kentän avulla saa helposti siivottua spämmit veke:

DELETE FROM kurssiilmo_p WHERE ip='spämmääjän ip';

Jos nauhavarmistusta koko palvelimien levyistä ei ole olemassa, niin tietokantojen varmistus kannattaa järjestää niin että palvelin ottaa esim. kerran yössä tietokantadumppi-tiedostot ulos tietokannasta, ja nämä tiedostot kopioidaan ajastetusti palvelimelta toiseen paikkaan. Suoraan MySQL-kannan datatiedostoja ei kannata lähteä kopioimaan, sillä muuten voi tulla ongelmia palautusvaiheessa ellei kannan versio säily täsmälleen samana.

Olen ajastanut dumpit palvelimelle muodostumaan kerran vuorokaudessa kansioon /data/backup/ nimille asio.sql.gz (asio-tietokanta) ja asiakas3.sql.gz (varaukset sisältävä asikas3-tietokanta).

Windowsilla kannattaa käyttää ilmaista pscp -ohjelmaa, jonka voi ladata tästä: http://the.earth.li/~sgtatham/putty/latest/x86/pscp.exe

SCP-komentorivit joilla dumppien kopiointi onnistuu nykyiseen hakemistoon on seuraava:

pscp -pw SALASANA asio@asioserver2:/data/backup/asio.sql.gz . pscp -pw SALASANA asio@asioserver2:/data/backup/asiakas3.sql.gz .

Ei häviä, tämä tuli aika nopeasti pilottiasiakkailtamme Savonialta ja Pelastusopistolta jatkokehityksenä koska opettajat innostuivat siivoilemaan kalentereitaan

Opetustyyppisten varausten Exchangesta tapahtuvan poiston käsittelyyn on kaksi vaihtoehtoista käsittelysääntöä, joista sopivamman voi valita yrityskohtaisten asetusten kautta:

a) Opettajavarauksesta tyhjennetään poiston yhteydessä opettajatieto, mutta varausta ei poisteta tilan, ryhmän ja kurssin kalentereista.

b) Poiston yhteydessä poistettu opettajavaraus palautetaan takaisin Exchangeen.

Opettajan muutosoikeus opetustyyppiseen omaan varaukseen on hienosäädettävissä yrityskohtaisten asetusten kautta, ja siellä on tällaiset vaihtoehdot:

a) Oletus. Tämä on vanha Asion toimintamalli, eli jos opettajan käyttöoikeustyyppi on selailuoikeus, ei mitään muutosoikeuksia. Jos käyttöoikeustyyppi on tätä korkeampi, muutosoikeus lukujärjestysvaraukseen on siinä tapauksessa että käyttäjä on varaksen ainoa opettaja.

b) Täysi muutosoikeus varauksiiin joissa opettajana. Opettaja pääsee tekemään mitä tahansa muutoksia tai poistoja varaukseen, kunhan hän on yksi ko. varaukseen osallistuvista opettajista. Tämä on ollut käytännössä aika monelle asiakkaallemme toimiva vaihtoehto.

c) Rajoitettu muutosoikeus varauksiin, joissa itse opettajana. Opettajalla on muutosoikeus kuten kohdassa b, mutta hän ei voi vaihtaa opetusvarauksen aikaa eikä poistaa varausta.

Kokeiletko toimiiko jos laittaa sähköpostiosoitteiden väliin erotinmerkiksi pilkun, se on käsittääkseni sähköpostin standarditapa.

Asio-ohjelmisto ei itsessään tue useita osoitteita, vaan se välittää osoitekenttään kirjoitetun tekstin suoraan sähköpostia lähettävälle ohjelmalle. Loppupeleissä usean osoitteen toimiminen on toisin sanoen kiinni palvelimelle asennetusta sähköposteja lähettävästä varusohjelmasta (postfix, sendmail, jne.).

Tässä on jälleen kyseessä ikuinen taistelu Excelin automaattimuotoiluominaisuutta vastaan. Välillä meni jo ihan hyvin, mutta versio versiolta Microsoft keksii uusia tapoja kääntää tämän ominaisuuden päälle niin, että se aiheuttaa ongelmia kun CSV- tai TSV- muotoista tekstiaineistoa nostetaan Exceliin.

Olen lisännyt kikkavitosen opetusaikalistauksiin jolla ainakin Excelin versiot 2002 ja 2003 sekä OpenOffice jotka meillä on täällä toimistolla toimivat oikein.

Yleisesti ottaen tietojen automaattisesta muotoilusta pääsee tietääkseni Excelissä eroon ainoastaan käyttämällä Excelin ulkoisten tietojen tuonti -ominaisuutta: - Tallenna CSV-tiedosto Asiosta levylle, eli älä avaa sitä suroaan selaimesta - Excelin ylävalikosta Tiedot -> Tuo ulkoiset tiedot -> Tuo tiedot. Tämä oli versiosta 2002, jos yhtään muistan niin uudemmassa Excelissä on tietojen tuontiin pikavalintapalkissa oma kuvakkeensa. - Valitse tiedosto ja klikkaa "Avaa". - Tästä käynnistyy tekstimuotoisen tiedon tuonti-Wizard. Valitse tuontioptio "erotettu" ja klikkaa seuraavaan ruutuun - Ruksaa erotinmerkiksi puolipiste ja klikkaa seuraavaan ruutuun - Valitse tietojen esikatselunäkymästä ongelmallinen sarake, ja tietojen muodoksi "Teksti" - Klikkaa lopuksi "Valmis"

Valitettavasti tämä ei onnistu, eli Asioon voi konfiguroida kerrallaan käyttöön vain yhden Exchange-kalenterin, vaikka itse yhteyden aktivoimisen voikin tehdä henkilökohtaisesti.

- Koituuko tästä ongelmia asiossa? (käytössä ulkoinen autentikoniti) 12.9.2011

Opettajakoodien muuttaminen samaksi kuin käyttäjätunnus on oikein hyvä ajatus, sillä se yksinkertaistaa mielestäni asioita paljon. Opettajan koodi on Asiossa tarkalleen ottaen opettajan kalenterivarauskohteen varauskohdetunnus, ja oman kalenterin ja LDAP-kirjautumisen tekniikka pelaa seuraavalla tavalla:

- Jos LDAP-käyttäjä on luotu manuaalisesti Asioon, pitää käyttöoikeuden olla henkilörekisterissä kiinni, samoin kuin varauskohteen. Oma kalenteri toimii kunhan tämä "kolmio" on kunnossa.

- Jos LDAP-käyttäjä on automaattisesti LDAP-käyttäjäryhmän perusteella profiloitava, tehdään tunnistus seuraavasti: a) Ensisijaisesti: mikäli varauskohderekisteristä löytyy henkilötyyppinen varauskohde, jolla käyttäjätunnus = kirjautuva tunnus, tulkitaan se omaksi kalenteriksi. b) Toissijaisesti: mikäli varauskohderekisteristä löytyy henkilötyyppinen varauskohde, jonka varauskohteen tunnus on sama kuin kirjautumistunnus, tulkitaan se omaksi kalenteriksi.

Eli tiivistäen ylläolevasta: tällaisesta muutoksesta ei pitäisi aiheutua mitään ongelmia oman kalenterin käsittelyn kannalta. Päin vastoin, se vähentää manuaaliduunia kun tunnuksia ei tarvitse enää välttämättä kirjoittaa kalenterivarauskohteiden käyttäjätunnus -kenttiin.

Tämä on meillä tiedossa oleva ongelma, ja se liittyy HTTP Basic -kirjautumismenettelyyn.

Tämän kirjautumismenettelyn istunnon sulkemiseen ei ole olemassa lainkaan standardinmukaista

ohjelmallista tapaa. Ainoa tapa on sulkea kaikki selainikkunat - tällöin istunto vanhenee automaattisesti. Ongelmaa ei ole silloin kun käytetään esim. Shibbolethia kirjautumismenettelynä, mutta Asion sisäisen kirjautumisen sekä LDAP-kirjautumisten yhteydessä helppoa ratkaisua tähän ei valitettavasti ole meillä tarjota.

Itse olen sitä mieltä että siitä kautta ei tarvitsisi päästä tekemään varauksia tai muuttamaan varauksia.

Voisivat yhdellä näytöllä helposti selata/etsiä missä joku tilaisuus pidetään ja millaisia varauksia on tulossa seuraavilla viikoilla?

Onko teillä antaa ratkaisua tähän ongelmaan? 25.8.2011

Katsoin läpi statusnäyttöjä tältä kantilta, ja näyttäisi että meillä ei valitettavasti ole tällaista käyttöä hyvin palvelevaa ratkaisua valmiina, eli yhtä näyttöä jolta pääsisi etsimään tiettyä tapahtumaa sekä selaamaan tulevia tapahtumia.

Statusnäytöt vastaavat tarpeeseen osittain, ja ne toimivat automaattisesti selailutilassa silloin kun käyttäjällä on selailuoikeudet. Statusnäyttöjen sisäänmeno voi kuitenkin olla hieman liian monipuolinen ja laaja, mikäli kohderyhmänä ovat infotiskin satunnaiskäyttäjät.

Jos haluat kokeilla statusnäyttöjä selailutilassa, niin se onnistuu seuraavasti - Laita käyttäjätunnukselle päälle vain selailuoikeudet haluttuihin tiloihin - Ruksaa päävalikkoon päälle statusnäytöt

Statusnäyttöön jää yläosaan vielä näkyviin varausnapit, mutta niistä ei pääse kuitenkaan tekemään varauksia. Näin kuitenkin pääsisi kokeilemaan selailustatusnäyttöjä sen verran että näkisi kelpaavatko ne ratkaisuksi.

Osallistujakirjauksiin liittyy seuraava toimintaperiaate:

Varauksiin voidaan sisällyttää - kalenterin omaavia henkilöitä, jotka siis löytyvät henkilörekisteristä - ns. (muita) "osallistujia", jotka ovat pääsääntöisesti ulkopuolisia ja joiden tietoja ei ole rekisterissä.

Osallistujien kirjaus tapahtuu lähinnä viestintätarpeita varten. Menettelyä käytetään lähinnä silloin, kun halutaan kirjata esim. ulkopuoliseen asiakastapahtumaan tulevat henkilöt mm. juuri viestintää varten.

Niille henkilöille, jotka omaavat kalenterin, voidaan varauksen yhteydessä tehdä myös henkilövaraus. Tapauksessasi siis Saaraselle olisi voitu tehdä tätä tapahtumaa koskeva kalenterimerkintä (eli varaus). Jotta hänet saataisiin ulkopuolisten osallistujien kanssa samaan viestintäryhmään, on varauksen osallistujakirjausvaiheessa mahdollista käyttää painiketta "Tuo henkilöt, joiden kalentereihin varaus on merkitty". Tällä menettelyllä siis: * Saarasen kalenteriin on tullut merkintä * Saaranen on tuoto MYÖS osallistujalistalle. Näin hoidettuna taustaväri ei ole punainen.

Kyseessä on siis varaustilanne, jossa tilavarauksen lisäksi tulisi tarvittaessa tehdä varaus myös Saaraselle. Tähän on useita mahdollisuuksia: * Tehdään ensin tilavaraus ja sitten lisätään henkilö varausmuutosten "Lisää aikoja"-toiminnolla. * Mennään sisään vapaiden aikojen haun kautta * Mennään sisään myyntipalvelun kautta.

Jos ette halua Saaraselle tilaisuuden kalenterimerkintää, hänet voi kirjata suoraan osallistujaksi. Tällöin taustaväri pysyy punaisena. Viestintävaiheessa hänen sähköpostiosoitteensa täytyy tässä tapauksessa syöttää käsin.

Hieman monimutkaista, mutta toivottavasti selvisi.

Jos henkilölle on tarve antaa tietyntyyppinen oikeus yksittäiseen tilaan, ei tilalajirajauksen asetuksella ole väliä, eli se voi olla mikä tahansa. Yksittäiseen tilaan tehty määritys on aina ylikirjaava. Tässä tilanteessa riittää toisin sanoen pelkästään se, että Pasilan erikoistilaan 4005 antaa tilakohtaisella asetuksella sopivan varausoikeuden.

Tässä vielä pari esimerkkiä joista toimintamalli valottunee paremmin:

1) Tilalajiin on tasona "ei oikeuksia" ja tilaan määritelty tilaa koskeva "normaali varausoikeus": - Käyttäjä näkee tilavarauksen päävalikon kautta tilalajin kaikista tiloista vain tämän yhden - Käyttäjällä on tilaan normaali varausoikeus, eli hän pääsee tekemään varauksia mutta ei ylivaraamaan tai muuttamaan muiden varauksia

2) Tilalajiin on tasona "normaali varausoikeus" ja tilaan määritelty tilaa koskeva "ei oikeuksia": - Käyttäjä näkee tilavarauksen päävalikon kautta tilalajin kaikista tiloista kaikki muut paitsi sen johon hänelle on määritelty "ei oikeuksia" - Käyttäjällä on tätä yhtä tilaa lukuunottamatta kaikkiin tilalajin tiloihin normaali varausoikeus

Asion henkilönumeroa ei voi korvata Oodin henkilönumerolla - henkilönumeroita ei voi vaihtaa jälkikäteen, koska kyse on avaintiedosta joka pitäisi samalla päivittää moneen muuhunkin paikkaan.

Tähän ei kuitenkaan pitäisi olla tarvetta, sillä Oodi-henkilönumerolle on järjestelmässä oma kenttänsä. Kenttä löytyy varauskohteen tiedoista, nimellä "Oodi-lyhenne". Tämä on se tieto jota järjestelmä käyttää Oodi-siirroissa mikäli se on henkilön varauskohteelle kirjattu.

Lisäsin Oodi-lyhenteen päivitysmahdollisuuden uuteen versioon henkilötietosiirtoa. En saanut päivitettyä tiedostoa inc/intf_datasync.php.asio huoltoyhteytemme kautta (permission denied), joten tässä on päivityspaketti:

Poistetut tilat pitäisi poistaa myös Untisista, tai muuten vaihtoehdot lukujärjestystä tuotaessa ovat jättää tuonti tekemättä tai perustaa tila uutena Asioon. Itse ongelma lienee aiheutunut siitä, että mikäli lukujärjestyksen tuonnissa valitaan uusien, Asiosta puuttuvien tilojen tilalaji oletusoption "Aineiston mukaan" sijaan, Asion Untis-tuonti perustaa järjestelmään tilat jotka ovat Untis-aineistossa ja puuttuvat tilarekisteristä. Kannattaa tuoda Untis-lukujärjestykset aina järjestelmään niin, että edellämainittu tilojen lajia koskeva valinta on oletusarvoissaan. Tällöin ohjelma ei perusta puuttuvia tiloja rekisteriin, vaan antaa puuttuvasta tilasta virheilmoituksen.

Tällainen merkintä edellyttää, että kenttä johon tieto kirjoitetaan tukee HTML-muotoiluja. HTML-muotoiltuja kenttiä ovat ainakin kurssien kuvaustiedot. Muotoilut voivat toimia joissain muissakin kentissä, mutta kriittisissä paikoissa - kuten esim. kurssin nimessä tai koodeissa - niitä ei kannata käyttää. HTML-koodi TM-merkinnälle on tällainen: ™ ja Copyright-C:lle ©

Tässä on aika hyvä lista HTML-koodeista yleisimmille erikoismerkeille: http://www.intuitive.com/coolweb/entities.html

Tämä on sikäli hieman vanhaa juttua jo, että järjestelmästä löytyy myös mekanismi jolla varauskohteen tunnuksen voi kiinnittää ulkoiseen käyttäjään jonka käyttäjätunnus ei ole sama kuin varauskohteen tunnus.

Tämä onnistuu kirjaamalla kalenterivarauskohteelle varauskohteiden ylläpidon kautta lomakkeen alalaidassa oleva käyttäjätunnus-tieto. Kun tähän kirjoittaa LDAP-kirjautumistunnuksen, osaa järjestelmä yhdistää kalenterin ja käyttäjän toisiinsa.

Mielestäni ei ole välttämättä syytä lähteä tyhjentämään Asion käyttäjärekisteristä LDAP:sta poistuvia tunnuksia. Näin siksi, että kirjautumisen yhteydessä Asion palikat käyvät aina tsekkaamassa käyttäjän olemassaolon LDAP:sta, ja tunnuksella ei pysty kirjautumaan jos se vanhenee LDAP-hakemistosta. Asiossa vanhatkin käyttäjätunnukset on hyvä olla ainakin tiettyyn pisteeseen asti mm. siksi, että muutoshistoriatietoihin saadaan näkyville käyttäjän tunnuksen lisäksi myös nimi.

Eri juttu onkin sitten, jos teillä on tarkoituksena ottaa vanhoja käyttäjätunnuksia uudelleen käyttöön eri henkilöille. Siinä tapauksessa vanhat tunnukset on syytä poistaa Asiosta. Valmiita ratkaisuja tähän ei valitettavasti ole, mutta voimme antaa ohjeita putsaukseen SQL:n avulla tai tehdä putsauksen toimittamanne listan perusteella kertaluontoisena operaationa.

Seuraavassa ohjeita muun henkilökunnan perustamiseksi järjestelmään:

1) Henkilöt voi perustaa järjestelmään käsin, ensin henkilörekisterin kautta henkilö ja sen jälkeen hänelle perustetaan kalenterivarauskohde sekä käyttöoikeus.

Kalenterivarauskohteen koodituksessa tulisi noudattaa samoja periaatteita kuin käytätte lukujärjestysten opettajakoodeissa, niin silloin varaukset kohdentuvat oikein jos sama henkilö joskus tulevaisuudessa tulee lukkarisiirron mukana. Kalenterivarauskohteessa varauskohteen tunnus on se tieto, jonka pitäisi olla sama kuin lukujärjestysohjelmissa käytettävä opettajakoodi.

Jos henkilöllä on AD-tunnukset eikä erityismäärittelyjä tarvita käyttöoikeuksiin, riittää kun henkilön käyttäjätunnuksen käy kirjaamassa kalenterivarauskohteelle käyttäjätunnus-kenttään (ylläpitolomakkeen alaosassa). Tämän tiedon avulla järjestelmä osaa nostaa kirjautumisen jälkeen henkilön oman kalenterin päävalikkoon näkyville.

Jos henkilö edellyttää tarkempia käyttöoikeusmäärittelyjä, voidaan käyttöoikeus perustaa henkilörekisterin kautta. Mikäli henkilöllä on AD-tunnukset, tulisi käyttäjätunnukseksi kirjata sama kuin hänen AD-käyttäjätunnuksensa on, ja ruksittaa lomakkeen alta kohta "käytä ulkoista autentikointia". Mikäli käyttäjällä ei ole AD-tunnuksia, syötä käyttäjälle salasana ja jätä em. ruksi ruksaamatta.

2) Vaihtoehtoisesti isompi määrä muuta henkilökuntaa voidaan myös tuoda eränä järjestelmään sisään henkilöiden tuontiohjelmaa käyttäen.

Henkilöiden erätuonnista löytyy tarkempi ohje itse ohjelmasta. Ohjelma on päävalikossa kohdassa Ylläpito -> Aineiston lataus / Yleinen. Valitse aineiston tyypiksi "Asio v10 henkilösiirtoaineisto" niin alalaitaan tulee kuvaus tiedonsiirtoaineistosta sekä tietojen päivitysperiaatteista esim. pakollisten kenttien ja avaintietojen osalta.

Seuraavassa ohjeita muun henkilökunnan perustamiseksi järjestelmään:

1) Henkilöt voi perustaa järjestelmään käsin, ensin henkilörekisterin kautta henkilö ja sen jälkeen hänelle perustetaan kalenterivarauskohde sekä käyttöoikeus.

Kalenterivarauskohteen koodituksessa tulisi noudattaa samoja periaatteita kuin käytätte lukujärjestysten opettajakoodeissa, niin silloin varaukset kohdentuvat oikein jos sama henkilö joskus tulevaisuudessa tulee lukkarisiirron mukana. Kalenterivarauskohteessa varauskohteen tunnus on se tieto, jonka pitäisi olla sama kuin lukujärjestysohjelmissa käytettävä opettajakoodi.

Jos henkilöllä on AD-tunnukset eikä erityismäärittelyjä tarvita käyttöoikeuksiin, riittää kun henkilön käyttäjätunnuksen käy kirjaamassa kalenterivarauskohteelle käyttäjätunnus-kenttään (ylläpitolomakkeen alaosassa). Tämän tiedon avulla järjestelmä osaa nostaa kirjautumisen jälkeen henkilön oman kalenterin päävalikkoon näkyville.

Jos henkilö edellyttää tarkempia käyttöoikeusmäärittelyjä, voidaan käyttöoikeus perustaa henkilörekisterin kautta. Mikäli henkilöllä on AD-tunnukset, tulisi käyttäjätunnukseksi kirjata sama kuin hänen AD-käyttäjätunnuksensa on, ja ruksittaa lomakkeen alta kohta "käytä ulkoista autentikointia". Mikäli käyttäjällä ei ole AD-tunnuksia, syötä käyttäjälle salasana ja jätä em. ruksi ruksaamatta.

2) Vaihtoehtoisesti isompi määrä muuta henkilökuntaa voidaan myös tuoda eränä järjestelmään sisään henkilöiden tuontiohjelmaa käyttäen.

Henkilöiden erätuonnista löytyy tarkempi ohje itse ohjelmasta. Ohjelma on päävalikossa kohdassa Ylläpito -> Aineiston lataus / Yleinen. Valitse aineiston tyypiksi "Asio v10 henkilösiirtoaineisto" niin alalaitaan tulee kuvaus tiedonsiirtoaineistosta sekä tietojen päivitysperiaatteista esim. pakollisten kenttien ja avaintietojen osalta.

Kyse on siitä, että Asio-palvelin asio.helsinkiexpert.fi jolla verkkokauppa sijaitsee on asetettu ns. luotetuksi sivuksi. Tämä varoitus tulee selaimesta aina silloin, kun ei-luotetulta sivulta ollaan siirtymässä linkin kautta luotetulle sivulle.

Ongelmasta pääsee eroon ainakin niin, että asettaa myös www.helsinkiexpert.com -sivun luotetuksi sivuksi.

Tämän jälkeen selaimen pitäisi aina kysyä, mihin tiedosto tallennetaan.

Tämä on tosiaan Firefoxin oletuskäyttäytymistä, eli se tallentaa kysymättä kaikki tiedostolataukset tiettyyn kansioon.

Ominaisuuden voi kytkeä pois seuraavasti: - Valitse ylävalikosta Tools -> Options - Valitse välilehti "Main" (oletuksena ehkä näkyvissä) - Kohdassa "Downloads" on radiovalinta "always ask me where to save files". Klikkaa se aktiiviseksi ja lopuksi vielä "OK".

Tämän jälkeen selaimen pitäisi aina kysyä, mihin tiedosto tallennetaan.

Seuraavassa on pikaohje uuden käyttäjän luomiseksi järjestelmään:

1) Perusta henkilö ensin henkilörekisteriin (Ylläpito -> Henkilörekisteri). Kaikkia tietoja ei tarvitse täyttää mutta ainakin nimi, email, puhelin ja titteli on hyvä olla täytettynä.

2) Henkilörekisterin ylläpitoruudulta löytyy alaosasta kohta "Käyttöoikeustiedot" josta olevaa painiketta klikkaamalla pääset perustamaan uuden käyttöoikeuden.

3) Syötä käyttöoikeudelle ainakin seuraavat tiedot: - Käyttäjätunnus; järjestelmä ehdottaa tähän etunimestä 2 kirjainta + sukunimestä 8 kirjainta, mutta voit kirjoittaa muun tunnuksen jos teillä on näissä ollut jokin toinen käytäntö. - Salasana - Rooliksi kannattaa valita uudelle lyhytkurssin käyttäjälle "ylläpitäjä" - Päävalikosta kannattaa ruksittaa kohdat "Lyhytkurssi" sekä "Ylläpito/lyhytkurssi". Valikoiden sisältöä voi vielä hienosäätää tarpeen mukaan tarkemmin mustan nuolen alta avautuvista tarkennusrukseista.

4) Tallentamisen jälkeen uusi tunnus on valmis otettavaksi käyttöön.

Seuraavassa ohjeita automaattisen ilmoittautumisaikasäännöstön käyttöönottoa varten.

Ilmoittautumisaikojen automaattinen laskenta aktivoituu toiveiden käsittelyssä heti, kun sääntöjä on määritelty vähintään yksi kappale. Teillä ei tainnut olla tällä hetkellä vielä yhtään sääntöä tietokannassa, mutta voit perustaa uuden säännön parametrien ylläpito-ohjelman avulla seuraavalla tavalla.

1) Avaa parametrien ylläpito ja syötä uusi parametriluokka -kohtaan "Q/T" ja jatka eteenpäin.

2) Syötä ilmoittautumisaikasäännön tiedot lomakkeelle. Tässä esimerkki:

-- J.nro = järjestysnumero jossa säännöt esitetään, laita tähän vaikkapa "1"

-- Koodi = ilmoittautumisaikasäännön yksilöivä koodi, esimerkiksi "I" (iso I = roomalainen ykkönen)

-- Säännön nimi (suomi/englanti) = käyttäjälle näytettävä nimi säännölle. Tämä näytetään listoissa aina koodin perässä, eli jos syötät nimeksi vaikkapa "Kauppatieteen opinnot" ja koodiksi "I" niin valintalistalla tämä näkyy käytäjälle tekstinä "Sääntö I - Kauppatieteen opinnot".

-- Apvm/Lpvm:n laskentakaava = kaava jolla ilmoittautumisen alkupäivä ja loppupäivä lasketaan. Parametrien ylläpidon ohjeessa on listattu kaikki mahdolliset kaavassa käytössä olevat merkintätavat. --- Laskennan lähtökohdiksi on tarjolla opetuksen alku- ja loppupäivät (apvm, lpvm) sekä jakson alku- ja loppupäivät (japvm, jlpvm). --- Lopullisen päivän lähtökohdasta laskemista varten voidaan käyttää joko kalenteripäiviä (p) tai arkipäiviä (ap). Arkipäivien laskennassa on huomioitu myös erityispäivärekisteriin kirjatut juhlapyhät. --- Seuraavassa vielä pari käytännön esimerkkiä jotka toivottavasti valottavat laskennan toimintaa: ---- "apvm-5p" = 5 kalenteripäivää ennen opetuksen alkupäivää ---- "japvm+5ap" = 5 arkipäivää jakson alkupäivän jälkeen

-- Ohjeteksti-kenttään voit kirjoittaa pidemmän vapaan selitteen. Olemme soveltaneet tätä Aalto-yliopistolla niin, että tähän kirjoitetaan säännön laskentaperiaate, aukikirjoitettuna käyttäjän ymmärtämällä kielellä.

Ilmoittautumisaikasääntöjen käyttöä varten vielä pari kommenttia seuraavassa:

1) Määrittelyn jälkeen sääntö nousee toiveiden käsittelyyn valittavaksi ilmoittautumisaika-kohtaan. Jos tästä valitaan sääntö, päiviä ei voi syöttää itse vaan ne lasketaan säännön perusteella. Valinnalla "ei automaattisääntöä" käyttäjä voi syöttää päivät manuaalisesti kuten ennenkin.

2) Kurssien lukituksen sekä Oodi-siirto-ohjelman kautta on myös pääsy ilmoittautumisaikojen massa-asetukseen. Massa-asetustoiminnon kautta säännöt voidaan asettaa kerralla joukolle pienryhmiä. Lisäksi sen kautta voidaan esikatsella, millaisia tuloksia automaattilaskenta antaisi. -- Oodi-siirrosta ilmoittautumisaikojen massa-asetukseen pääsee syöttämällä hakuehdot ja klikkaamalla "Päivitä/tarkista ilmoittautumisajat" -painiketta -- Lukituksesta myös vastaavasti, eli täyttämällä hakuehdot ja klikkaamalla "Ilmoittautumisaikojen päivitykseen" -painiketta

Piilotus toimii siten että HH:n haamutilat on laitettu omaksi tilalajikseen johon on asetettu rivikäyttäjille käyttöoikeudeksi "Ei oikeuksia".

Oikeusmääritys on tehty HH:n ympäristössä rooleille "Asio-selaus" ja "Asio-varaus" sekä "Admin-ylläpitäjä" joita tulisi käyttää oikeuksien pohjana kun uusia käyttäjiä perustetaan järjestelmään.

Tämä on ohjelman antama varoitus siitä, että pääkonfiguraatio inc/server_settings.php on vanhaa versiota. Varoitus on lisätty ohjelmaan alkaen versiosta 11.10 siksi, että vanhan konfiguraation käyttö on aiheuttanut muutamilla asiakkaillamme pieniä mutta käytännössä hankalasti selvitettäviä yhteensopivuusongelmia. Muistelin ulkomuistista päivityspakettia koostaessani, että teidän ympäristössä olisi ollut v11 -konfiguraatio jo käytössä mutta se taisikin olla jäänyt edellisestä versiosta 10 paikalleen.
Näyttää että meidän huoltoyhteys teidän palvelimellenne ei ole enää pystyssä, sillä en saa tätä kirjoittaessani SSH-yhteyttä palvelimelle.
Näyttää että meidän huoltoyhteys teidän palvelimellenne ei ole enää pystyssä, sillä en saa tätä kirjoittaessani SSH-yhteyttä palvelimelle.
Varoitus on kuitenkin helppo korjata päivittämällä konfiguraatiotiedoston versio. Seuraavassa ohje:
1) Avaa vanha konfiguraatiotiedosto inc/server_settings.php tekstieditoriin.
2) Etsi konfiguraatiotiedostosta sen loppupuolelta tällainen kohta:
/*********************************************************************** * * Älä tee organisaatiokohtaisia muutoksia tämän kohdan alapuolelle * *********************************************************************** */
3) Poista kaikki ohjelmakoodi konfiguraatiotiedostosta mikä on tämän kohdan jälkeen, paitsi tiedoston ihan viimeinen rivi joka sisältää PHP:n lopetusmerkin ?>
4) Poistettuasi tekstit, lisää tällainen rivi siihen kohtaan mistä teit poiston:
require("../inc/asio_init.php");
5) Tallenna muutokset
Tämän jälkeen tilavarausohjelmasta pitäisi olla kadonnut varoitus konfiguraation versiosta. Tekemämme päivitys konfiguraatioon on sellainen, että siirsimme konfiguraatiosta yleisiä osia osaksi ohjelman kirjastoja. Tällä tavoin vastaavaa konfiguraatioiden päivitysrumbaa ei tarvitse jatkossa enää tehdä aina Asion versiopäivitysten yhteydessä.
Varmuuden vuoksi voisi olla hyvä ajatus ottaa vanhasta inc/server_settings.php-tiedostosta varmuuskopio ennen ylläolevaa muutosta. Näin ihan kaiken varalta, sillä pienikin kirjoitusvirhe tässä tiedostossa voi aiheuttaa ohjelman toiminnan pysähtymisen.

Näin tosiaan on, opettajalla on oletuksena järjestelmässä muutosoikeus vain niihin varauksiin, joissa hän on yksin itse opettajana. Tämän säännön voi ohittaa yrityskohtaisista asetuksista löytyvällä valinnalla:
- Avaa päävalikosta "Ylläpito" -> "Ylläpitotoiminnot"
- Avaa välilehti "Yrityskohtaiset asetukset"
- Kohdasta "Varaamisen asetukset" löytyy valinta "Opettajien käyttöoikeus"
- Valinnalla "Täysi muutosoikeus varauksiin, joissa itse opettajana" tämä ongelma ratkeaa

Ennen tämän asetusmuutoksen tekoa kannattaa käydä lyhyt keskustelu aiheesta talon sisällä eli onko tämä toimintamalli aina OK, vai voiko aiheuttaa ongelmia ja antaa liian laajat muutosoikeudet opettajille.

Tämän asetusmuutoksen voi tehdä pääkäyttäjän oikeuksin, eli sen pitäisi onnistua teidän molempien omia tunnareita käyttäen. /tr>

Huomasin äsken tutkiessani lyhkin viestinlähetysongelmaa, että teillä ei näyttäisi olevan palvelimen MySQL:ssä ns. kyselyvälimuisti (query cache) päällä. Kyselyvälimuistin avulla Asio-ohjelmistoon saa ihan mukavasti suorituskykyä lisää, ja tämä ominaisuus kannattaakin kääntää tietokannasta päälle. Käänsin sen päälle ajonaikaisesti, mutta muutos pitäisi tehdä vielä konfiguraatiotiedostoon /etc/my.cnf jottei asetus haihdu seuraavan bootin yhteydessä.

Tässä ohje kyselyvälimuistin käyttöönottamiseksi. Lisää allaoleva rivi tiedoston /etc/my.cnf [mysqld] -osioon:

query_cache_size= 128M

Isompikin kuin 128 megainen kyselyvälimuisti voi olla hyödyllinen jos palvelimella on paljon aktiviteettia, mutta tämän pitäisi jo riittää pitkälle. /tr>

Huomasin äsken tutkiessani lyhkin viestinlähetysongelmaa, että teillä ei näyttäisi olevan palvelimen MySQL:ssä ns. kyselyvälimuisti (query cache) päällä. Kyselyvälimuistin avulla Asio-ohjelmistoon saa ihan mukavasti suorituskykyä lisää, ja tämä ominaisuus kannattaakin kääntää tietokannasta päälle. Käänsin sen päälle ajonaikaisesti, mutta muutos pitäisi tehdä vielä konfiguraatiotiedostoon /etc/my.cnf jottei asetus haihdu seuraavan bootin yhteydessä.

Tässä ohje kyselyvälimuistin käyttöönottamiseksi. Lisää allaoleva rivi tiedoston /etc/my.cnf [mysqld] -osioon:

query_cache_size= 128M

Isompikin kuin 128 megainen kyselyvälimuisti voi olla hyödyllinen jos palvelimella on paljon aktiviteettia, mutta tämän pitäisi jo riittää pitkälle. /tr>

Sain hitausongelman myös esiin. Näyttäisi että ongelma muodostuu ns. suurryhmästä, eli siitä että varauksessa on tosi paljon ryhmiä/ohjelmia sen lisäksi että varaus on melko pitkä. Hitaus ei ole tietokannasta kiinni, vaan yksinkertaisesti siitä että varausmuutosten käyttöliittymästä tulee tällaisilla varauksilla todella iso.

Huomasin kokeilussani että tämä ruutu nopeutuu teillä huomattavan paljon mikäli tilavarauksen yrityskohtaisista asetuksista valitaan varausmuutoksiin päälle erilainen suurryhmäkäsittely. Teillä lienee se tilanne aina opetustyyppisissä varauksissa, että koko varauksessa on kiinni samat ryhmät, eli että ryhmäkokoonpanot eivät vaihtele saman varauksen sisällä oppitunnista toiseen. Jos näin on, niin tätä asetusta voisi ainakin kokeilla - uskoisin että se ratkaisee varausmuutosten hitausongelman ainakin tällaisista tapauksista.

Asetus löyty toiminnon Ylläpito -> Ylläpitotoiminnot -> Yrityskohtaiset asetukset kautta, "Varaamisen asetukset" -osiosta. Asetuksen nimi on "Suurryhmäkäsittely varausmuutoksissa" ja oletusarvo on "Näytä yksi rivi per ryhmä". Valinnalla "Näytä yksi rivi per opetustapahtuma" varausmuutosruutu muuttuu sellaiseksi, että ryhmistä tulee varauksen yhteinen tieto jolloin niiden aiheuttama monistuminen jää rivikohtaisesta taulukosta pois.

Eri roolien sisältämien oikeuksien määrittely on osoittautunut sen verran asiakkaasta toiseen vaihtelevaksi, että kovin tarkkoja ohjeita en pysty antamaan. Kuten arvelitkin, muutamia asioita kuitenkin on mitkä on hyvä tietää tilavaraajan ja opetuksen suunnittelijan kohdalla:

1) Mikäli tilavaraajan on tarve tehdä laskutettavia ulkoisia varauksia, hänelle pitää avata ylläpitovalikosta pääsy asiakasrekisteriin ja henkilörekisteriin. Yksi hyvä yleiskäyttöoinen ylläpidosta löytyvä ja tilavaraajille soveltuva kohta on myös omat ryhmät, jonka avulla voi määritellä järjestelmään varauskohteista henkilökohtaisia pikavalintoja.

2) Opetuksen suunnittelu -rooli on hyvä määritellä pohjautumaan ylläpitäjä-rooliin, sillä muuten päällekkäisvarausten teon kanssa voi tulla ongelmia. Lisäksi lienee syytä avata ylläpidosta pääsy seuraaviin ylläpito-ohjelmiin: - Kurssitietojen ylläpito - Ohjelmat (ryhmät) - Henkilörekisteri

Sellainen huomio vielä suunnittelemaanne roolitusta silmälläpitäen, että pääkäyttäjän oikeus on tietoturvasyistä sellainen että sen voi antaa vain paikallisella ja henkilökohtaisella määrittelyllä. Pääkäyttäjätason oikeutta ei toisin sanoen voi kiinnittää henkilölle roolin kautta, vaan ainoastaan henkilökohtaisesti ja toisen pääkäyttäjän toimesta.

I - Google-kartan käyttöönotto ja konfigurointi

Mikäli haluatte käyttää Google-karttoja tilan fyysisen sijainnin esittämiseen, kannattaa ensimmäiseksi käydä hakemassa palvelimelle Google-karttoja varten avain tästä osoitteesta: http://code.google.com/apis/maps/signup.html . Avain tulisi konfiguroida inc/server_settings.php -tiedostoon nimellä g_google_maps_code, eli jos avain on vaikkapa "XYZ", sinne pitäisi lisätä tällainen uusi rivi:

$g_google_maps_code = "XYZ";

II - Karttapohjien ylläpito

Karttapohjien ylläpito-ohjelma löytyy ylläpitovalikosta kohdasta "Karttapohjat". Karttapohjalle tulisi määritellä ohjelman kautta seuraavat tiedot:

1) Karttapohjan koodi. Tämä on pohjan yksilöivä tunniste, ja sen tulisi olla koodimuotoinen eli se ei saa sisältää välilyöntejä tai muita erikoismerkkejä. Kannattaa tehdä kooditus niin että karttapohjat järjestyvät fiksusti. Esimerkiksi jos teillä olisi Oulun kampuksesta kampuksen kuva, päärakennuksen kuva ja päärakennuksen kerrosten kuvat, voisi kooditus mennä seuraavasti: - "oulu-kampus" = kampuksen kartta - "oulu-paarakennus" = päärakennuksen kartta - "oulu-paarakennus-1" = päärakennuksen 1. kerros jne..

2) Julkisuus = näkyykö käyttäjille vai ei. Vain julkiset pohjat näkyvät tilakartat-toiminnossa, eli pohjan voi pitää ei-julkisena siihen asti kunnes se on valmis ja kaikki tilat sijoiteltu.

3) Lyhyt nimi, pitkä nimi = karttapohjan nimet, lyhyt nimi on sellaisten valintalistojen varalta kun käyttöliittymässä on vähän tilaa.

4) Ohjeet-kohtaan voit kirjoittaa ohjeita jotka näkyvät tilan sijaintikartan alapuolella selailutoiminnossa.

5) HTML image map ja lupanumerot- kohdat eivät ole tällä hetkellä tilavarausohjelmiston sijantikartat-toiminnossa käytössä. Kentät ovat perua matkailupuolen ohjelmistosta, ja ne on jätetty tilavaraukseen näkyville tulevaisuuden varalta, jos sijaintikartat-toiminnon käyttöä laajennetaan esim. julkisiin selailukäyttöliittymiin (aulatoimintoihin ym.).

6) Kuvan tiedostonimi, kuvan koko: tästä kohdasta voi valita käytettävän kiinteän karttapohjakuvan sekä määritellä sen pikselikoon. "Lähetä uusi tiedosto" -toiminnon avulla palvelimelle voi lähettää uusia kuvia.

7) Karttapohjan vasemman ylänurkan ja oikean alanurkan koordinaatit: tähän määritellään karttapohjan maantieteelliset koordinaatit. Mikäli kyse on karttapohjasta jolla tällaisia ei ole (esim. rakennuksen kerroskuvat tai mittasuhteiltaan viitteelliset kampuksen kartat), voit tehdä määrittelyn seuraavasti: - Vasen ylä, pohj.lev: kuvan pikselikorkeus - Vasen ylä, itä.pit: 0 (nolla) - Oikea ala, pohj.lev: 0 - Oikea ala, itä.pit: kuvan pikselileveys

III - Tilojen sijainnin määrittäminen

Itse tilojen sijaintien ylläpito tapahtuu varauskohteiden ylläpito-ohjelmasta painikkeen "Sijainti kartalla" takaa. Tämän kautta voi käydä valitsemassa, mihin pohjakarttoihin tila kuuluu sekä käydä asettamassa tilan sijainnin kullekin pohjakartalle.

Tilojen sijainnille on olemassa kaksi koordinaatistoa: tilan maantieteelliset koordinaatit (ruudun yläosassa) sekä tilan karttapohjakohtaiset koordinaatit (ruudun alaosassa). Maantieteellisten koordinaattien tarkoitus on kertoa, missä tila oikeasti sijaitsee, ja karttapohjakohtaisia voi käyttää esim. kerroskarttojen ja muiden viitteellisten karttapohjien yhteydessä.

Seuraavassa ohje tilan sijainnin määrittämiseen:

1) Valitse ensin tilalle Kartalla = Kyllä ja tallenna. Tämä perustaa tilalle karttakohderekisteriin merkinnän, minkä jälkeen sijannin määrittäminen on mahdollista.

2) Ruksaa karttapohjat-kohdasta kaikki ne karttapohjat joihin tila kuuluu ja tallenna valinta. Tämä kiinnittää tilan karttapohjiin, ja mahdollistaa karttapohjakohtaisten koordinaattien määrittelyn.

3) Määritelläksesi karttapohjakohtaiset koordinaatit klikkaa ensin karttapohjan kohdalla olevaa linkkiä ja ruksaa ruudun alaosasta "käytä karttapohjaisia koordinaatteja". Tämän jälkeen voit joko kirjoittaa koordinaatit X- ja Y-kenttiin tai tuplaklikata karttakuvaa haluamastasi kohdasta. Sijainti näkyy kartalla punaisena pisteenä. Tuplaklikkaus ei välttämättä toimi kaikilla selaimilla, mutta ainakin uusimmat Firefox- ja IE-selaimet toimivat.

5) Kun sijainti on määritelty, voit hienosäätää punaisen pisteen sijaintia hiiren avulla raahaamalla. Tallenna lopuksi koordinaatit.

6) Jos Google-kartta on käytössä, voit määritellä maantieteellisen sijainnin kirjoittamalla koordinaatit yläosan lokeroihin ja tallentamalla. Voit hienosäätää sijaintia myös Google-kartassa raahaamalla punaista karttakohdetta. Versiosta 11 alkaen on myös mahdollista hakea tilan koordinaatit Googlesta automaattisesti katuosoitteen pohjalta.

IV - Tilojen sijaintikartat -toiminnon käyttäminen

Tilojen sijaintikartat löytyvät suoraan tällä nimellä päävalikosta. Näkyviin tulee rakennuksittain selattava taulukko tiloja vastaavalla tavalla kuin tilakalenterit -toiminnossa. Tilan kohdalla oleva linkki on harmaa jos sijaintikarttaa ei ole määritelty. Tällainen harmaa linkki tuo näkyviin tilan lisätietosivun omaan ikkunaansa.

Tilavalinnan jälkeen "Valitse kartta"-kohdassa on alasvetovalikko kaikista karttapohjista, joihin tila on kytketty, sekä Google-kartan valintamahdollisuus jos tilalla on maantieteelliset koordinaatit.

Tilan sijainti näkyy kartalla punaisena pisteenä, ja Google-kartalla punaisena karttakohdemerkkinä.

Näin tosiaan on, eli tilavarausohjelmiston päävalikossa olevien ryhmäkalenterien osalta ohjelma suorittaa myös sellaista siistimistä, että pois jätetään tästä aina sellaiset ryhmät joilla ei ole nykyisenä vuonna yhtään tilavarausta.

Ryhmien aikavälin määrittely on tätä täydentävä toiminto, jolla tämä aikaväli voidaan määritellä itse ja tarvittaessa tarkemmin kuin yhden vuoden tarkkuudella. Tästä toiminnosta on hyötyä etenkin lyhytkurssiohjelmiston yhteydessä, ja se mahdollistaa teknisessä mielessä tehokkaamman aikaan sidotun ryhmärajauksen kun varaustietoja ei tarvitse hakea aikarajausta varten.

Toinen kysymys. Meillä on kaksi kantaa: tuotanto ja testi. Voiko Asioon konfiguroida suoraan sekä testi- että tuotantokannan, että voisi valita kumpaan haluaa selaimella kirjautua vai tehdäänkö molemmista eri inkarnaatiot? (10.11.2010)

Asio-sovellus käyttää PHP:n sisäänrakennettua sähköpostin lähetystä, joka puolestaan käyttää Linux-ympäristöissä palvelimelle asennettua sähköpostin lähetysohjelmistoa (esim. sendmail). Todennäköisin syy kuvailemaasi tilanteeseen on, että palvelimella olevaa sähköpostin lähetysohjelmistoa ei ole konfiguroitu niin että se toimisi teidän verkkoympäristössänne oikein. Kannattaa olla yhteydessä palvelimen asentaneeseen tahoon, sillä emme valitettavasti osaa auttaa tässä asiassa. Tyypillisesti vinkkiä sähköpostin kulkemisen ongelmaan voi hakea sähköpostijärjestelmän lokista /var/log/mail.log

Sellainen huomio mailiasiaan vielä että Asio-järjestelmä asettaa mm. virhepaluupostien ja vastausten oikeaan paikkaan toimittamiseksi sähköpostin lähettäjän osoitteeksi käyttäjätietoihin kirjatun sähköpostiosoitteen. Voi olla että palvelimella oleva sähköpostijärjestelmä tai sähköpostin lähetykseen käytettävä ulkoinen SMTP-palvelin ei ole suostunut lähettämään viestiä eteenpäin mikäli testikäyttäjän sähköpostiosoite on ollut tyhjä tai muuten kelpaamaton.

Testi- ja tuotantotietokannat voivat sijaita samalla palvelimella käytettäessä sisäistä kirjautumista ja käyttää samaa Asio-ohjelman instanssia. Järjestelmässä on tietokanta "asio" joka sisältää käyttäjätiedot taulussa kayttooikeus_p, ja näissä käyttätiedoissa on kiinnitetty tietokanta johon käyttäjä kirjautuu. Seuraavassa ohje jolla voit tehdä samalle palvelimelle testiympäristön käyttäen pohjana tuotantotietokannan "uwasa" dumppia:

1) Luo tietokantapalvelimelle uusi tietokanta testiympäristöä varten, esim "uwasatest"

2) Lataa tuotantotietokannan dumppi tähän uuteen testitietokantaan

3) Lisää asio-tietokantaan testitietokantaan pääkäyttäjätunnus jotta sinne pääsee kirjautumaan. Tämä onnistuu ajamalla MySQL:n konsolista esim. tällainen komento:

insert into asio.kayttooikeus_p (ktun,password,kayttajaryhma,m2,kanta) values ('admintest','testi','ROOT','X','uwasatest');

4) Nyt Asioon kirjautuessa edellisessä käskyssä olevilla tunnuksilla (admintest / testi) ohjelma käyttää testitietokantaa.

5) Kannattaa ensitöiksi vaihtaa yrityskohtaisista asetuksista (Ylläpito -> Ylläpitotoiminnot -> Yrityskohtaiset asetukset) yrityksen nimi esim. lisäämällä perään sana TESTI. Yrityksen nimi näkyy ohjelman ylälaidassa, ja näin ei tule epäselvyyttä milloin on kirjautunut testiin ja milloin tuotantoon.

6) Kannattaa vielä käydä vaihtamassa ylläpitotoimintojen kautta pääkäyttäjän salasana. Edellämainittu suora insert-lause jättää salasanan käyttäjätietokantaan selväkielisenä, mutta ohjelman kautta asettaminen muuttaa sen kryptatuksi MD5-tarkistussummaksi.

Mikäli testiympäristöön on tarve tehdä Shibboleth-kirjautumisia, pitää Asio-järjestelmän ohjelmatiedostoista tehdä toinen kopio palvelimelle. Tämä siksi, että ulkoisten käyttäjien kirjautumisessa käyttämä tietokanta konfiguroidaan inc/server_settings.php -tiedostoon ja niitä voi näin ollen olla käytössä vain yksi kerrallaan.

Kuvailemasi tilanne jossa henkilö- ja käyttöoikeustietojen pääjärjestelmänä on Asio josta sitten synkronoidaan tietoja muualle on sikäli uudenlainen käyttötapaus, että valmiita ratkaisuja meillä ei tähän valitettavasti ole tarjota. Olemassaolevia aiheeseen liittyviä moduuleja meillä on muutamia, mutta erona on tosiaan se että tietoja on aikaisemmin aina siirretty muista järjestelmistä Asioon päin.

Sovelluksen tasolla tässä puhutaan meidän näkökulmasta kahdesta eri asiasta:

1) Pelkkään kirjautumiseen meillä on olemassa integrointipalikat mm. Microsoftin Active Directoryyn, muutamiin muihin LDAP-hakemistoihin sekä Shibbolethiin. Näiden moduulien ajatuksena on autentikoida käyttäjä kirjautumishetkellä sekä profiloida käyttöoikeuden taso automaattisesti jotta käyttöoikeuksien hallintaa ei tarvitsisi tehdä manuaalisesti Asio-ohjelmistossa.

2) Henkilötietojen sisäänlukuun meillä on rakennettu ratkaisut Personec/Fortime- ja Novell IDM- järjestelmiä vastaan. Tämän integraation ideana on tuoda asiakkaan operatiivinen henkilöstö Asio-järjestelmään siten että tietoja voidaan käyttää mm. varaustoiminnassa sekä opetuksen suunnittelussa, sekä siirtää Asiosta edelleen eteenpäin käyttäen asiakkaan omia oikeita koodituksia. Personec/Fortime -integraatio toimii teknisesti lukemalla sisään XML-muotoisia siirtotiedostoja jotka kopioidaan ajastetusti palvelimelle tiettyyn kansioon. Novell IDM -integraatio on puolestaan toteutukseltaan hieman yleisempi, ja se on tehty käyttäen MySQL-tietokannassa olevaa siirtotaulua johon Novell IDM kirjoittaa tietoja ja josta Asio lukee tietoja ajastetusti sisään.

Asion henkilötietojen siirtorajapinnassa päässä tuetut kentät on listattu allaolevassa dokumentissa. Dokumentti käsittelee tietojen tuontia Asioon CSV-muotoisella siirtotiedostolla, mutta siitä ilmenee millaisia tietokenttiä on käytettävissä.

http://www.asio.eu/asio/asio_tilavaraus_henkilosiirto.htm

Jos Asio-järjestelmä halutaan pitää henkilö- ja käyttöoikeustietojen pääjärjestelmänä, edellyttää tämä vastaavien tietojen välittämistä toiseen suuntaan. Käytännössä ratkaisu voisi olla esim. sellainen että Asiosta päivitetään tietoja erilliseen MySQL-tietokannassa olevaan siirtotauluun jota Microsoft Forefront Identity Manager tai vastaava käyttää välivarastonaan.

Mikäli ylläoleva kaavailu kuulostaa järkevältä niin voitaisi edetä asiassa mielestäni siten että sovimme ensin asiakkaan kanssa Asio-järjestelmän päähän tarvittavien lisäominaisuuksien toteuttamisesta, ja sen jälkeen aletaan tarkentaa tekniseltä puolelta. Lähinnä etukäteen mieleeni tulee ongelmana salasanatiedon välitys, sillä meillä ei ole tietoturvasyistä selväkielistä salasanaa tai edes suolaamatonta MD5-tarkistussummaa järjestelmässä lainkaan tallennettuna.

Emme valitettavasti voi taata ohjelman täyttä yhteensopivuutta Windows Server 2008 -käyttöjärjestelmän kanssa. En henkilökohtaisesti kuitenkaan usko että Windows Server 2008 aiheuttaa yhteensopivuusongelmia Asio-ohjelmiston kanssa, sillä ohjelmisto on käyttöjärjestelmäriippumaton kunhan vaan alustalle on saatavilla vaadittu varusohjelmisto eli PHP, MySQL ja Apache. Valitettavasti meillä ei kuitenkaan ole tarjota vinkkejä tai ohjeita mitä asennuksessa Windows Server 2008 -ympäristöön tulisi huomioida.

Olemme lopettaneet Windows-pohjaisten ympäristöjen suosittelemisen uusille asiakkaille johtuen Windows-alustojen hieman huonommasta suorituskyvystä ja merkittävästi vaikeammasta etäylläpidettävyydestä, mutta toki tuemme yhä olemassaolevia tuotantoympäristöjä.

Virtualisoinnista ei puolestaan aiheudu ongelmia, ja se onkin oikein hyvä toimintamalli käyttövarmuuden ja varmistusten kannalta. Virtualisoinnista aiheutuu toki aina jonkin verran lisäkuormaa ja suorituskyky ei siksi ole ihan yhtä hyvä kuin ilman virtualisointia. Asennettaessa Asio-ohjelmistoa uudelle virtuaalialustalle on hyvä antaa ohjelmiston käyttöön ainakin pari kappaletta prosessoriytimiä mikäli palvelinympäristö sen sallii.

Olit kysellyt RSS-syötteiden saamisen mahdollisuudesta Asion tilakalentereista. Teillä tällä hetkellä käytössä olevalla tilavarauksen versiolla on mahdollista tuottaa RSS-syötteitä yksittäisen tilan tilakalenterista seuraavasti: - Mene tilan kalenteriin ohjelman käyttöliittymän kautta - Lisää urlin perään parametri "&outmode=rss"

Vastauksena tulee ko. tilakalenteri RSS-syötteenä. Syötteen muodostus ei tarvitse ihan kaikkia urlissa olevia parametreja, ja toisaalta siinä voidaan käyttää muutamia lisäparametreja hyödyksi. Seuraavassa on kuvaus RSS-syötettä ohjaavista urlin GET-parametreista:
- kt = "tila", kiinteä teksti joka yksilöi varauskohteen tyypin.
- outmode = "rss", kiinteä teksti joka valitsee tulostusmuodoksi RSS:n.
- ctila = Varauskohteen rivin tunniste (rowid). Tämä on numero joka yksilöi varauskohteen. Kannattaa katsoa tämä oikean kalenterin urlista avaamalla se ohjelman käyttöliittymän kautta. Jos integroituvalla ohjelmalla on MySQL-yhteys, voi tämän tiedon lukea palvelu_p-taulun kentästä rowid.
- var_apvm = varaukset alkaen tästä päivästä, 6 merkillä muodossa VVKKPP
- var_lpvm = varaukset tähän päivään asti, 6 merkillä muodossa VVKKPP

Jos päivämääriä ei välitetä parametrina, tulevat listaan oletuksena nykypäivän tulevaisuudessa olevat varaukset.

Esimerkiksi teidän 422 musiikkiluokka -tilasta koko vuoden 2010 varaukset saa ulos RSS:ksi tällaisella urlilla: https://asp.teak.fi/kalenterit2/index.php?kt=tila&ctila=22&outmode=rss&var_apvm=100101&var_lpvm=101231

Tämä ongelma johtuu siitä, että MySQL ei oletusarvoisesti välitä kirjainkoosta tekstikentissä, joten ohjelman tekemät SQL-haut osuvat tässä kohtaa molempiin periodikoodeihin.

Ongelman voi korjata tekemällä seuraavan SQL-kyselyn asiakas12-tietokannassa, joka muuttaa ko. kentän tietokannan päässä case sensisitiveksi (binary):

ALTER TABLE `kokousvaraus_p` CHANGE `KURSSITUN` `KURSSITUN` VARCHAR(20) BINARY NOT NULL;

Asiossa esim. opetustapahtuma 75E00540 Advanced Managerial Writing on ajoitettu koko keväälle eli alkaa periodilla III, joka on opetusperiodiksi valittu.

Sijoittelun aikaväli kohtaan on valittu III periodin alkupäivä ja toiseksi IV periodin päättymispäivä. Opetusaikatoiveeksi Ti klo 9 - 11. Nyt Asio varaa koko ajalle tiistaisin opetusta ko.aikaan. Kun kyseessä on verkkokurssi pidetään vain yksi lähiopetuskerta, joka on ti 18.1.2011. Kun käyttäjä poistaa muokkauksen kautta kaikki muut tiistait paitsi 18.1. muuttuu myös sijoittelun aikaväli vain päivälle 18.1. eli tieto siitä, että kurssi kestää koko kevätlukukauden häviää. Nyt näyttää siltä, että verkkokurssi kestää vain alkukevään, joka voi johtaa opiskelijoita harhaan.

Voiko tälle tehdä jotain, jotta saataisi tuo Sijoittelun aikaväli säilymään koko kevään ajalle. (18.05.2010)

Ongelma liittyy sellaiseen Katriina Korhosen pyynnöstä toteutettuun uuteen ominaisuuteen järjestelmässä, että opetustapahtumien muokkauksen yhteydessä opetuksen aikaväli päivitetään automaattisesti opetustapahtumien pohjalta varaustoteuman mukaiseksi. Tätä toteuttaessa ei tullut meille kummallekaan mieleen tuo etäopetus-case, eli tilanne jossa opetuksen aikaväli on ihan oikeasti eri kuin varattujen opetuskertojen toteutunut aika.

Lisäsin poikkeussäännön automaattiseen päivitykseen etäopetusta varten. Poikkeussäännön saa aktivoitua opetusmuotokohtaisesti parametrien ylläpidosta, opetusmuotoparametrista (luokka 1). Sovellustyyppi-sarakkeeseen syötettävä koodi "E" kääntää automaattisen päivityksen ko. opetusmuodolta pois päältä.

Laitoin edelläolevan poikkeuskäsittelyn päällle Verkkokurssit-opetusmuodolle, eli tämän asian pitäisi olla nyt OK ja opetuksen aikaväliä pystyä muokkaamaan mm. 75E00540:n V01-pienryhmän tapauksessa vanhaan tyyliin.

Alkuperäinen varaaja pääsee muuttamaan tekemästään varauksesta kalenterinäyttöjen kautta ylläpitäjänkin tekemän muutoksen jälkeen niitä varauksen osia, joihin hänellä on käyttöoikeuksiensa puitteissa muutosoikeus.

Käyttäjän muutosoikeus varauksen osaan määräytyy ohjelmassa tarkalleen ottaen seuraavasti:

1) Mikäli varauskohteeseen (= varattuun tilaan) on ylläpito-oikeus, kaikkia kyseiseen varauskohteeseen tehtyjä varauksia voi muokata rajoituksetta ja riippumatta siitä kuka alkuperäisen varauksen tai viimeisimmän muutoksen on tehnyt.
2) Mikäli varauskohteeseen on normaali varausoikeus, voi käyttäjä muokata itse alunperin tekemiään varauksen osia sekä niitä varauksen osia joihin hänet on merkitty itse opettajaksi.
3) Mikäli varauskohteeseen on selailuoikeus tai ei lainkaan oikeutta, ei muutosoikeutta varauksen osaan ole missään tilanteessa, vaikka käyttäjä olisikin alunperin tehnyt itse ko. varauksen osan.

Näihin periaatteisiin ole tullut muutoksia pariin vuoteen, joten tällainen muutosmahdolisuus alkuperäisellä varaajalla on itseasiassa ollut ohjelman käyttöönotosta lähtien.

Helpoin paikka ratkaista tämä ongelma on itseasiassa vaihtaa ohjelmalle tuleva kirjautumistieto pienille kirjaimille. Tämä onnistuu seuraavalla tempulla:

1) Avaa tiedosto /var/www/inc/server_settings.php tekstieditoriin

2) Lisää tiedoston alkuosaan, vaikkapa tietokantakonffisten jäkeen, tällainen rivi:

$PHP_AUTH_USER = strtolower($PHP_AUTH_USER);

Tämän jälkeen sisään kirjautuvan käyttäjän ohjelmalle asti päätyvä käyttäjätunnus on aina pienillä kirjaimilla, ja kirjainkoon eroista aiheutuvan ongelman pitäisi olla pois päiväjärjestyksestä uusien varausten osalta. Ongelmahan koskee ainoastaan sellaisia AD:n avulla kirjautujia, joille ei ole perustettu varauksen tekohetkellä tunnuksia Asioon. Näiden käyttäjätunnustieto otetaan suoraan käyttäjän syöttämästä tunnuksesta mikäli AD-LDAP-sidonta onnistuu.

Shibbolethin kautta kirjautuville perustetaan profilointisääntöjen perusteella automaattisesti käyttöoikeus mikäli heillä ei sellaista valmiiksi ole. Nämä automaattisesti perustetut ovat jompaa kumpaa seuraavista muodoista:

1) Jos henkilö on löytynyt henkilörekisteristä jonkin tunnistetiedon pohjalta, on väliaikainen käyttäjätunnus muotoa SHIB_Tnnnnn, missä kohta nnnnn on henkilörekisterin henkilönumero

2) Jos henkilö on tuntematon eli ei löytynyt rekisteristä eikä myöskään ole pystytty perustamaan rekisteriin, on tunnus muotoa SHIB_nnnnn_vvvvppkk_ttss, missä: - nnnnn = arvottu luku välillä 00000-99999 - vvvvkkpp = perustamispäivämäärä, esim. 20100423 - ttss = perustamiskellonaika, esim. 1200

Nämä automaattiset käyttäjätunnukset ovat luonteeltaan väliaikaisia, ja ne poistetaan automaattisesti aina välillä, tyypillisesti n. vuorokauden kuluttua viimeisestä käyttötapahtumasta. Uudelleen kirjautumisen yhteydessä ne myös poistetaan ja muodostetaan profilointisääntöjen perusteella uusiksi.

Väliaikaisten tunnusten osalta ei tarvitse tehdä mitään, eli niiden voi antaa olla tietokannassa. Jos väliaikaisen tunnuksen omistavasta käyttäjästä tarvitsee tehdä tarkemmin määritelty, manuaalisesti perustettu käyttäjä, onnistuu se henkilörekisterin kautta. Henkilötietolomakkeen alalaidassa käyttöoikeustiedot -kohdassa näkyy tieto siitä, mikäli käyttöoikeus on väliaikainen/automaattinen. Perusta-painikkeella pääsee tästä kohdasta perustamaan käyttäjälle manuaalisesti määriteltävän oikeuden.

Lisäsin kurssien ylläpitoon usean opintojakson poiston kerralla, sillä tämä oli hyvä ja varsin helposti toteutettavissa oleva kehitysehdotus.

Kurssien perustietojen ylläpidossa on hakutuloslistalla uusi painike "usean kurssin poisto" jonka valitsemalla listalta voi ruksata poistettavat kurssit ja poistaa ne kerralla. Toiminto on näkyvissä vain pääkäyttäjän oikeuksin, koska sen avulla voi hävittää yhdellä napin painalluksella niin suuren määrän tietoa.

Opintojaksot poistetaan vain siinä tapauksessa, jos alla mainitsemistani valinnoista on ruksattu kohta 2.

Vanhoja lukujärjestystuonteja voi siivota kannasta peruuttamalla. Peruuttaminen poistaa oletusarvoisesti vain tuonnissa muodostetut varaukset, mutta peruutuksen yhteydessä voidaan lisäksi poistaa muitakin tietoja seuraavilla lisävalinnoilla:

1) Poista myös tuonnin yhteydessä luodut tilat ja opettajat käyttöoikeuksineen
2) Poista myös tuonnin yhteydessä luodut kurssit ja luokat

Katselin, että tämmöinen ominaisuus olisi saatavana. Omnia on ottamassa käyttöön Exchange 2010 -järjestelmän vielä ennen kesää, ja oltaisiin kiinnostununeita tästä tuotteesta.

Katselin verkkosivulta http://www.asio.fi/asio_exchange_liitanta/asio_exchange_liitanta.html esittelyn, ja muutama asia jäi kaipaamaan lisätietoja:

- TOimivuus Exchange 2010 -järjestelmässä? - Siirtyvätkö esim. Lukujärjestykset opettajan omaan kalenteriin, kun esim. Untis -aineisto siirretään asioon? (07.04.2010)

Meillä on ollut Exchangen kanssa toistaiseksi vain yksi pilotti (Savonia AMK) ja heillä on tietääkseni ollut käytössä Exchangen versio 2007. Version 2010 kanssa yhteensopivuutta en osaa täydellä varmuudella kommentoida ennenkuin sitä päästään kokeilemaan. Koska kaikki operaatiot Asio-järjestelmän ja Exchange-palvelimen välillä tehdään käyttäen Exchangen Web Serviceä, olettaisin kuitenkin että version 2010 kanssa ei tule käytännössä yhteensopivuusongelmia.

Kalvosarjassa mainittu HTTP Basic -autentikointivaatimus on puolestaan sellainen tekninen knoppi joka kannattaa ottaa tarjouspyyntöjä tehdessä huomioon mikäli suunnitelmissanne on kokeilla Asion Exchange-palikoita. Joskus Exchangea palveluna tarjoavat toimijat eivät suostu tekemään tällaista konfiguraatiomuutosta omaan päähänsä, vaikkei siihen mielestäni olekaan mitään todellisia perusteita.

Kyllä tällainen siivous on aika helppo tehdä, mikäli eroon halutaan kaikesta aikaan sidotusta tiedosta ja jäljelle olisivat jäämässä vain tietyt perustietorekisterit (käyttäjät, tilat, henkilöt). Tällainen siivous voi olla hyvä juttu myös järjestelmän suorituskyvyn kannalta, kun vanhasta varausmassasta ja lokitiedoista päästään eroon.

Seuraavassa on listattuna eri tietojen sijaintitaulut järjestelmän mysql-tietokannassa:
- tietokanta "mamk":
-- course_p = kurssien perustiedot
-- kokousvaraus_p = tilavaraukset
-- loki2_p = varausten muutoshistorialoki
-- loki_p = tapahtumaloki
-- person_p = henkilöiden perustiedot
-- palvelu_p = tilojen perustiedot
-- luokka_p = ryhmien (ohjelmien) perustiedot
-- lajirajaus_p = käyttöoikeuksien resurssikohtaiset oikeustarkennukset
- tietokanta "asio"
-- kayttooikeus_p = käyttäjien perustiedot

Komennolla "truncate table TAULUN_NIMI" saa tyhjennettyä mysql:ssä nopeasti taulun siten, että taulun data-osio menee kokonaan sileäksi ja rakenteeseen ei jää tyhjiä aukkoja.

Ennen siivouksia kannasta kannattaa toki ottaa backuppi, ihan kaiken varalta

"Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 79 bytes) in /opt/www/intra/kalenteri/inc/asiodb_legacy.php on line 284"

Varaus on ilmeisesti moniosainen, yksikön yhteinen kokousaika. Sain saman ilmoituksen yrittäessäni poistaa varausta ylläpitäjän tunnareilla. Mistähän voisi olla kysymys? (05.03.2010)

Ongelma johtuu siitä, että varaus on liian suuri mahtuakseen teidän palvelimella PHP:lle määriteltyjen muistirajojen sisään.

Näyttää virheilmoituksen pohjalta, että muistia on varattu PHP:lle vain 32 megatavua. Muistin ylärajaa kannattaa nostaa tästä jonkin verran, esimerkiksi 128 megatavuun.

Asetus löytyy php.ini -tiedostosta nimellä memory_limit. Muutoksen jälkeen www-palvelinohjelma (Apache) pitää käynnistää uudestaan jotta uusi konfiguraatio astuisi voimaan.

Myös parametreissa on tämäntyyppistä tietoa. Parametriluokassa 0 (nolla) on erillinen lista yksiköistä, jotka voidaan kiinnittää kurssiin kurssirekisterin ylläpito-ohjelman kautta. Tämän tiedon merkitys järjestelmässä on opetuksen järjestävä yksikkö, eli sillä ei ole tekemistä varausten taloushallintopuolen vastuuyksikkötiedon (= maksaja / tilaava yksikkö) kanssa.

Parametreista löytyvää yksikkötietoa hyödynnetään järjestelmässä lähinnä opetuksen suunnittelun hakutoiminnoissa, mutta tilavarauksien yhteydessä sitä ei käytetä.

Tämä tieto ei näy myöskään millään tavoin Raindance-siirron alta löytyvissä listauksissa.

Kyse on mitä ilmeisimmin Internet Explorer kasin uudesta ominaisuudesta, joka käyttää erillistä prosessia jokaiselle uudelle selainikkunalle. IE8:n saa toimimaan sekä niin että cookiet säilytetään myös uuteen ikkunaan että niin, että cookiet pudotetaan uudessa ikkunassa. Cookieiden säilyttävä vaihtoehto on IE8:n termein "session merging" ja asiasta on muutama sana allaolevan linkin päässä: http://stackoverflow.com/questions/1324181/ie8-losing-session-cookies-in-popup-windows

Vaikuttaa siltä, että tämän käyttäjän koneella session merging -ominaisuus ei toimi. Linkin päässä oli yksi ratkaisu, mutta en ole ihan varma voiko tätä soveltaa teillä: "It seems that the problem automagically goes away when the user is added as a Local Administrator on the machine. Only time will tell if this change permanently (and positively) affects this problem."

Emme ole itse törmänneet koskaan tähän ongelmaan IE8-testauksissa, mutta tämä voi johtua siitä että käytössä on XP-käyttis ja käyttäjän tili on administrator. Mielestäni tässä on kyse nimenomaan selaimen bugista tai suunnitteluvirheestä, ja aika pahasta sellaisesta koska se vaikuttanee lähes kaikkiin istunto-cookieita käyttäviin web-sovelluksiin jotka avaavat useita selainikkunoita. Onko mahdotonta käyttää Asiota jollain muulla selaimella, esim. Firefoxilla, ennenkuin tähän saadaan ratkaisu?

Sori "tuplapostauksesta", mutta tsekkaatteko vielä että käyttäjällä jolla ongelma esiintyy on käytössään IE8:n uusin versio. Jos ei ole, niin selain kannattaa päivittää. Ilmeisesti vielä tämän vuoden alussa olleessa IE8:n versiossa on ollut rinnakkaisuuteen liittyvä ongelma session merging -ominaisuudessa, joka on myös voinut aiheuttaa tämän oireen. https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=408806

Varsinkin jos ongelma tapahtuu silloin-tällöin voisi kyse olla tuosta rinnakkaisuusjutusta.

Käytä listausten alta löytyvää ohjelmaa "Käyttöraportit". Valitse aikaväli ja prikkaa päälle kaikki tilalajit. Valitse käsittelyyn max 40 vastuuyksikköä kerralla. Käytä painiketta "Tiivistetty listaus vastuuyksiköittäin".

Tällaista testausta varten yksinkertaisin mahdollinen palikka on ulkoisen autentikoinnin moduuli ext_auth.php.asiotester.simple josta pitäisi löytyä helppo käyttöesimerkki. Moduulin voi ottaa käyttöön symlinkkaamalla tai kopioimalla sen nimelle ext_auth.php.

Ohjelmiston sisäinen rajapinta toimii yksinkertaisimmillaan siten, että ulkoisen autentikoinnin moduulissa on määritelty PHP-funktio "ext_authorize" jolle tulee sisään käyttäjätunnus ja salasana ja joka palauttaa "true" mikäli kirjautuminen on OK ja "false" jos kirjautuminen ei ole OK.

Myös ohjelmiston käyttäytymistä erilaisten Shibboleth-attribuuttien kanssa on mahdollista testata ennen Shibboleth SP:n asennuksia, mutta siinä on hieman enemmän askelia. Laittakaa meillepäin tietoa mikäli haluatte tehdä tällaisia testejä niin voin kirjoitella teille ohjeita.

Tämä kuulostaa nimenomaan cookieihin liittyvältä ongelmalta. Vaikuttaa siltä, että käyttäjän selain hävittää tilavarausohjelmiston asettaman istunto-cookien. Vika voi johtua joko liian tiukoista tietoturva-asetuksista selaimessa, tai jostain työasemakohtaisesta softaongelmasta.

Yksi helppo temppu mitä kannattaa kokeilla lääkkeeksi IE:n cookie-ongelmiin on tilavarauspalvelimen https://tilavaraus.tkk.fi lisääminen ns. luotetuksi sivustoksi. Tämä onnistuu Internet Explorerin versioissa 7 ja 8 seuraavan ohjeen mukaisesti: http://www.asio.fi/popup_ie7.shtml

Suorituskyky voi parantua MyISAM storage enginellä hieman, painottuen niin että tiedon lukuoperaatiot nopeutuvat hieman ja päivitysoperaatiot vastaavasti hidastuvat. Tässä puhutaan kuitenkin muutaman prosentin erosta, eli mitään dramaattista vaikutusta suorituskykyyn tällä tuskin on.

Voit tehdä halutessasi storage enginen muutoksen ilman taulujen pudottamistakin seuraavalla käskyllä:

ALTER TABLE taulun_nimi ENGINE = myisam;

Tässä operaatioissa voi kestää isolle taululle kauan minkä ajan tietokanta on lukossa ko. taulun osalta, joten tätä ei kannata ajaa tuotantoaikana ilmoittamatta käyttäjille käyttökatkoksesta.

Seuraavassa on muutamia vinkkejä suorituskyvyn parantamiseen.

Suorituskyvyn kannalta kriittisintä on, että isoihin tauluihin tapahtuvat kyselyt nojaavat indekseihin. Jos indeksit puuttuvat, hidastuvat operaatiot sitä mukaa kun tavaraa tulee tauluihin lisää. Kannattaa tarkistaa ainakin taulujen kokousvaraus_p, loki2_p sekä loki_p indeksit. Tässä on lista isojen taulujen indekseistä meidän koneelta:

loki2_p: KEY `id2` (`id2`), KEY `id1` (`id1`), KEY `varnro` (`varnro`), KEY `varpvm` (`varpvm`), KEY `tyyppi` (`tyyppi`), KEY `pvm` (`pvm`), KEY `klo` (`klo`)

loki_p: KEY `ktun` (`ktun`), KEY `id1` (`id1`), KEY `id2` (`id2`),

kokousvaraus_p: KEY `AKLO` (`AKLO`), KEY `LKLO` (`LKLO`), KEY `LAJI` (`LAJI`), KEY `HENKILOTUN` (`HENKILOTUN`), KEY `VARNRO` (`VARNRO`), KEY `LSIJAINTI` (`LSIJAINTI`), KEY `ASTUN` (`ASTUN`), KEY `tila` (`TILA`), KEY `OPETTAJATUN` (`OPETTAJATUN`), KEY `LUOKKATUN` (`LUOKKATUN`), KEY `TUONTINRO` (`TUONTINRO`), KEY `TYYPPI` (`TYYPPI`), KEY `tehtava` (`TEHTAVA`), KEY `SIJAINTI` (`SIJAINTI`), KEY `PVM` (`PVM`), KEY `ASKUTSUMANIMI` (`ASKUTSUMANIMI`), KEY `KURSSITUN` (`KURSSITUN`), KEY `EDUCOURSEOFERING` (`EDUCOURSEOFFERING`), KEY `LASKUNRO` (`LASKUNRO`), KEY `SIIRTONRO` (`SIIRTONRO`), KEY `EXC_ID` (`EXC_ID`), KEY `PROJEKTI` (`PROJEKTI`), KEY `MUUTOSAIKA` (`MUUTOSAIKA`)

Syntaksi tarkoittaa näissä kaikissa tapauksissa yhden sarakkeen indeksiä mainittuun taulun sarakkeeseen.

Kannattaa myöskin tarkistaa, että MySQL:n kyselyvälimuisti (query cache) on teillä päällä. Tämä onnistuu mysql-konsolista käskyllä: show status like '%qcache%';

Mikäli arvot näyttävät nollaa, pitäisi kyselyvälimuisti kääntää päälle. Tämä onnistuu my.cnf / my.ini -tiedoston asetuksella query_cache_size, johon voi laittaa palvelimen vapaan muistin määrästä riippuen arvon väliltä 32M - 256M.

Lokitauluista ja varaustauluista voisi yrittää arkistoida vanhoja tietoja jos teillä ei ole niille käyttöä. Uusimmassa tilavarauksen versiossa on tätä varten oma toimintonsa kohdassa Ylläpito -> Arkistointi. Toiminto siirtää tavaraa aktiivivaraustaulusta arkistotauluun (esim. tilavaraukset kokousvaraus_p -> xkokousvaraus_p).

Jos järjestelmä vielä kaiken tämänkin jälkeen tuntuu hitaalta, voi syytä yrittää selvitellä MySQL:n slow query lokin pohjalta. Kts. http://dev.mysql.com/doc/refman/5.1/en/slow-query-log.html

Käytettävän kutsupohjan valinnassa ei ole kurssipaikkaan sidottua logiikkaa, vaan se valitaan "kutsut/laskut"-toiminto avattaessa seuraavalla säännöllä: 1) Mikäli kurssille löytyy kurssikohtainen pohja, johon on tallennettu muutoksia "Kutsupohjan muokkaukseen"-toiminnon kautta, käytetään sitä 2) Jos ei löydy, valitaan yleisistä pohjista ensimmäinen Koska ohjelmaan ei ole tullut kutsupohjan valintalogiikkaan muutoksia edes tässä uusimmassa isossa versiopäivityksessä, olettaisin että ongelma aiheutuu joidenkin kutsupohjaan liittyvien tietojen muutoksesta. Tietokannassa olevien tietojen perusteella näyttäisi, että kohdassa 2 mainitsemani ensimmäisen kutsun pohjaan on tehty muutoksia hiljattain, joten olettaisin että tämä on ongelman syy. Kutsujen lähetyksessä käytettävän pohjan voi valita "Kutsupohjan valintaan"-napin kautta löytyvästä toiminnosta kutsujen lähetyksen yhteydessä.

Kuulostaisi omaan korvaani siltä, että www-selaimella on ongelmia evästeiden (cookie) käsittelyssä. Jos selain hävittää weblogin-kirjautumisen tallentamiseen käytetyn evästeen, tapahtuisi juuri kuvailemallasi tavalla, eli ohjelma alkaa pyytää kirjautumaan uudestaan. Ensihätään voisi kokeilla käyttää eri selainta. Jos ongelma esiintyi Internet Explorerilla niin kannattaa kokeilla Firefoxia. Jos ongelma häviää tällä, on vika selaimen asetuksissa ja vikaa voi lähteä etsimään niistä. Internet Explorerilla olemme yleensä suositelleet että Asion sovellus lisätään ns. luotetuksi sivustoksi. Tämän pitäisi lieventää selvästi IE:n tietoturvaominaisuuksista sekä popup-ikkunoiden estosta johtuvia ongelmia. Sivuston lisääminen luotetuksi onnistuu allaolevan ohjeen mukaisesti. Ohje on kirjoitettu Internet Explorer 7:lle mutta versiossa 8 on myös vastaava valikko. Luotetuksi lisättävä osoite on "tilavaraus.tkk.fi". http://www.asio.fi/popup_ie7.shtml

Ei voi. Ainoa tapa on peruuttaa varaus ja tehdä uudelleen.

Tämä on itseasiassa ohjelman normaalia toimintaa. Kyse on selailutyyppisestä kalenterista, johon ei voi tehdä varauksia (ilmeisesti käyttäjällä ei riittävästi oikeuksia). Mikäli selailukalenterissa ei ole viikonlopulle yhtään varausta, jättää ohjelma viikonlopun tulostamatta.

Seuraavassa infoa Asion sovellusten sähköpostilähetyksestä.
Asio-ohjelmisto käyttää sähköpostin lähetykseen PHP:n mail-funktiota, jonka toimiminen edellyttää tyypillisesti Unix/Linux-ympäristöissä sähköpostin lähetyksen aktivointia suoraan paikalliselta koneelta (esim. sendmail-ohjelmistolla) ja Windows-ympäristöissä PHP:n konfigurointia käyttämään organisaationne lähtevän postin mailipalvelinta (kts. php.ini:n SMTP-konfiguraatiodirektiivi, http://fi2.php.net/manual/en/mail.configuration.php#ini.smtp )
Teillä taisi olla pystytettynä Windows-palvelin, joten lähtevän postin SMTP-palvelin tulisi konfiguroida php.ini-tiedostoon kohtaan "SMTP". Operaation jälkeen Apache pitää käynnistää uudestaan jotta uudet asetukset astuvat voimaan.

Kahdella ehdolla:
* On pääkäyttäjä
* On merkitty varaukseen opettajaksi.

Ylläpitotoimintojen "ulkoiset järjestelmät"-sivulla pitäisi näkyä tietoa ulkoisesta autentikointijärjestelmästä mikäli konffiksen kaikki palikat ovat OK paikallaan. Kyseisen sivun tarkistukset ovat seuraavat:
1) Onko tiedosto inc/ext_auth.php paikallaan
2) Onko konfiguraatio $ext_udb_config määritelty (tämä on inc/server_settings.php tiedostossa).
3) Onko tällä hetkellä kirjautuneena olevalle pääkäyttäjälle määritelty tietokanta (mysql-kenttä asio.kayttooikeus_p.kanta) sama kuin ulkoisen autentikoinnin konfiguraatioon määritelty tietokanta ($ext_udb_config kohta "database")
Jos yksikin näistä ehdoista ei täyty, näytetään tuo teksti "Ei käytössä". Vaikuttaisi että ohjelman mielestä jotain on näiden sääntöjen puitteissa pielessä.

Ohjelmassa erityispäiväkäsittely on sisäistä. Ulkoisista lähteistä (siirtotiedostot, Untis tms.) tulevan aineiston oletetaan olevan tältä osin kunnossa eikä siihen siis kohdisteta erityispäivä- tarkistusta.

Hitausongelma kuulostaa indeksointiongelmalta tietokannassa tai ohjelmassa. Eka asia josta selvityksiä voisi aloittaa on sen tarkistaminen, onko MySQL:ssä kyselyvälimuisti (query cache) päällä. Tämä ominaisuus parantaa merkittävästi Asion softien suorituskykyä, koska kyselyt ovat yksinkertaisia mutta niitä on todella paljon.
Kyselyvälimuistin tilan saa selville ajamalla tietokannassa kysely: show status like 'qcache%'; Sekä kysely: show variables like 'query_cache%'; Jos nämä molemmat näyttävät nolla, tyhjä tai OFF -arvoja, ei kyselyvälimuisti ole päällä. Sen saa päälle MySQL:n konfiguraatiosta kohdasta query_cache_size. Asion asp.asio.fi-koneella (joka on vuodelta 2003 oleva vanha serveri 1gt keskusmuistilla) on query_cache_size arvossa 32M eli 32 megatavua. Modernimmalla koneella sopiva arvo on 64-256M välillä, keskusmuistin määrästä riippuen.

Liitetiedoston lisääminen on mahdollista. Tuetut tiedostomuodot ovat Word- ja PDF-tiedostot ja lisäksi liitetiedoston maksimikoko on 1 MB.

The problem might be related to maximum file upload size limits in your server's PHP configuration. The default for PHP is 2 megabytes. This file is much smaller, but url-encoding might raise the total request above the limit.

The following PHP configuration directives (in the php.ini file) affect the file uploading: - upload_max_filesize - post_max_size

You can check the current runtime configuration settings in PHP by creating a file with the following source code on the server and running it with the web browser: A suitable value for both upload_max_filesize and post_max_size for uploading large Untis files should be"16M" (16 megabytes) .

Tietokannan varmistukset kannattaa aina tehdä mysqldumpilla.

Meidän kokemuksemme mukaan mysql 4.0:sta muodostettuja dumppeja saa luettua sisään versioon 5. Seuraavanlaisia dumppausoptioita olemme yleensä käyttäneet:

mysqldump --opt -K --skip-comments TIETOKANNAN_NIMI > dumppi.sql

Oikeaoppisin tapa on antaa näille käyttäjille varauskohdekohtainen ylläpito-oikeus niihin tiloihin, joiden varauksia heidän tulee päästä muuttamaan. Tällä menettelyllä käyttäjät eivät saa muita oikeuksia, esim. pääsyä ylläpitotoimintoihin.

* Tässä yksi tapa:
** Valitse valikosta "Statusnäytöt" ja sieltä päivämääriksi haluamasi viikon keskiviikko-sunnuntai.
** Valitse sitten se tai ne tilalajit, joihin haluamasi tilat kuuluvat. Paina "Jatka" -painiketta.
** Saat nyt näkyviin ns. status-näytön, joka näyttää valittujen tilalajien tilojen tilanteen valituilta päiviltä. Prikkaa haluamasi tilat ja paina "Varauksen teko / kalenteri" -painiketta.
** Nyt ruutuun tulee kalenterityyppinen näyttö, jossa jokainen tila ja päivä muodostaa oman sarakkeen. Maalaa mihin tahansa sarakkeeseen se aikaväli, jota varauksessa on eniten (esimerkissä 8-22). Ohjelma avaa maalauksen jälkeen varausikkunan.
** Kirjaa avautuneessa ikkunassa varauksen perustiedot. Mikäli varausjakso ei ole alustunut, valitse alku- ja loppupäivä. Lopuksi prikkaa valituiksi kaikki ruutuun tulostuneet tilat ja paina "Hyväksy" -painiketta.
** Mikäli päällekkäisvarauksia ei tullut, on edessä viimeinen vaihe. Klikkaa varaus auki ja paina "Näytä koko varaus" -painiketta. Sitten prikkaa ne varausrivit, joiden aika tulee muuttaa (esimerkissäsi keskiviikon varausrivit). Siirry hieman alaspäin rivitietojen pika-asetukseen, aseta siellä haluamasi ajat ja paina ko. rivillä "Aseta valittuihin" -painiketta. Tämän jälkeen varaus on valmis.

On myös toinen tapa: Tehdään ensin status-näyttöjen kautta (kuten edellä) ne ajat, jotka ovat samat kaikille tiloille. Tämän jälkeen tehdään loput tilavaraukset varauksen muutosruudun painikkeen "Lisää aikoja" avulla.

Mikäli käyttöoikeudet on perustettu siten että on annettu normaali varausoikeus ja sen jälkeen laitettu tiettyihin tiloihin ei oikeuksia tai selailuoikeus. Lajirajauksen ulkopuoliset uudet lajit saavat aina tuon "perusoikeuden" eli tällaisten käyttäjien tapauksessa normaalin varausoikeuden.

Käyttöoikeuksien hallinnan helpottamiseksi tilavarauksen versiosta 7 alkaen on kuvioihin tuotu mukaan uusi käsite nimeltään rooli. Käyttäjä voidaan kiinnittää rooliin ja kaikkien tällaisten käyttäjien yhteisiä käyttöoikeuksia voidaan ylläpitää roolin kautta. Tällaiseen tilanteeseen olisi kätevä jos käyttäjät olisi jaettu rooleihin - tällöin muutos tarvitsisi tehdä vain muutamaan rooliin. Roolien ylläpito löytyy ylläpitotoiminnoista, pääsy toimintoon edellyttää pääkäyttäjän oikeudet. Rooliin määritellään oikeudet tiloihin sekä päävalikon näkyvissä olevat toiminnot kuten yksittäiselle käyttäjälle.

Voisi olla hyvä ajatus jatkoa ajatellen alkaa käyttää uusien käyttäjien tapauksessa rooleja käyttöoikeuden perustana. Ennen roolien perustamista kannattaa kartoittaa minkätyyppisiä käyttäjiä teillä on ja käyttää tätä kartoitusta perustana roolien määrittelylle. Esimerkiksi KKO, KL, KOY sekä varaajille ja selailijoille voisi ajatella olevan omat roolinsa.

Varaajia voi olla yhdessä varauksessa useita mm. jos toinen henkilö on käynyt lisäämässä toisen tekemään varaukseen uusia osia "lisää aikoja"-toiminnon kautta. Varaajaksi kirjautuu aina ensimmäinen henkilö joka tekee kirjauksen.

Varaajatiedon näkymättömyys palasella johtunee puolestaan käytössä olevasta ulkoisesta autentikoinnista (LDAP). Varauksen "palasella" yritetään näyttää varaajan koko nimi ja puhelinnumero, listalla pelkkä käyttäjätunnus.

Tilavarauksen versiossa 8 on parannettu varaajatiedon näkymistä ulkoisen autentikoinnin yhteydessä siten, että aina sisäänkirjautumisvaiheessa ulkoisesta käyttäjästä taltioidaan lokiin nimi, puhelinnumero, ja joitain muitakin tietoja jotta tiedot voitaisi näyttää mm. varausmuutosruudulla.

Tehtävät määritellään parametriluokassa T ja niitä pääsee muokkaamaan valikosta löytyvän ohjelman Ylläpito -> Parametrit avulla. Tehtävien parametrimäärityksissä tärkeimmät parametrien sarakkeet ovat seuraavat:

• Luokka = T (tehtävillä aina tämä)
• Koodi = Tyhjä
• Arvo = Tehtävän yksilöivä kokonaisluku, jonka pitää olla joka tehtävällä eri. Numeroa nolla ei saa tässä käyttää koska se on sama kuin tyhjä eli ei tehtävää.
• Selite = Tehtävän nimi, esim. "1.2. Suunnittelu"
• Selite2 = Tehtäväluokitus, esim. "1. Opetus"

Ongelma syntyi tässä tapauksessa siinä että 1.1. Opetus -tehtävällä on arvona nolla.

Tämä on ohjelmistossa käytössä olevan HTTP-basic-tyyppisen autentikoinnin perustavaa laatua oleva ongelma, sillä kyseisessä kirjautumismenettelyssä ei ole olemassa mitään virallista tapaa vanhentaa sisäänkirjautumista sulkematta selainta.

Meiltä on kyselty uloskirjautumisominaisuutta muutamien käyttäjien taholta, joten lähitulevaisuudessa ohjelmistoon tulossa kokonaan uusi kirjautumismenettely joka tukee myös uloskirjautumista. Versioon 8 tämä toiminto ei vielä valitettavasti ehtinyt.

Eli nykyversiossa uloskirjautuminen tapahtuu selaimen sulkemalla.

Opiskelijoille voi antaa järjestelmään tiettyihin tiloihin varausoikeudet. Opiskelijoita varten kannattaa määritellä tilavarausohjelmistoon oma roolinsa kohdasta Ylläpitotoiminnot -> Asiakaskohtaiset roolit, jossa merkkaa varausoikeudet päälle vain opiskelijoille suunnattuihin harjoitussaleihin. Tämän toiminnon kautta voi myös säätää päävalikon sisältämään ainoastaan opiskelijoille käytettäväksi tarkoitetut toiminnot.

Varausoikeuksien antaminen opiskelijoille edellyttää myös että opiskelijoiden käyttöoikeustiedot saadaan jollain tavalla tilavarausohjelmalle. Täysin anonyymisti ja ilman kirjautumista varausta ei voi tehdä.

Koska henkilömäärä on tässä tapauksessa niin suuri, vaatii tämä käytännössä jonkinlaisen ulkoisen autentikointirajapinnan (esim. Microsoft Active Directory tai muu LDAP, Shibboleth) käyttöönottoa. Tämä ulkoisen autentikoinnin käyttöönotto on puolestaan sellainen askel jossa voidaan edetä kunnolla vasta kun ohjelmisto on siirretty omalle palvelimelle.

Automaattisesti profiloinnin kautta pääteltäviin oikeuksiin tällaiset asetukset ovat mahdollisia roolien avulla. Toimintaperiaatteena on se että ulkoisesta autentikoinnista tulevien tietojen perusteella päätellään käyttäjän rooli, ja ylläpitovalikosta löytyvän toiminnon Ylläpitotoiminnot -> Asiakaskohtaiset roolit avulla määritellään tälle roolille sopivat oikeudet.

LDAP:n tapauksessa roolin sidonta voidaan tehdä LDAP:ssa olevien käyttäjäryhmien perusteella. Sitominen tehdään tilavarausohjelmiston konfiguraatiotiedostoon

inc/server_settinsg.php

http://www.asio.fi/extauth.fi.shtml

Listaustoiminnoissa on (ehkä hieman kyseenalainen) toimintaperiaate, että jos "Opettajat" on ruksittu, ohjelma näyttää myös ne tilalajit, joihin opettajille on kirjattu varauksia. Jos jätät Opettajat ruksaamatta, ohjelma toimii halutulla tavalla.

Sähköposti lähtee toimistonne Asio-palvelimelta ja siihen ollaan yhteydessä webbiselaimen avulla. Palvelimen kannalta käyttö on samanlaista riippumatta siitä, onko selainyhteys otettu toimiston sisäverkosta vai etäyhteyden kautta.

Mahdollinen ongelma liittyy tällöin todennäköisesti www-selaimeen. Jokin selainasetus on todennäköisesti erilailla kotikoneessa vrt. toimisto, ja tämä häiritsee postitustoimintojen toimintaa.

Muutamia mahdollisia ongelmakohtia alla:

• Selaimen popup-ikkunoiden esto. Jos käytössä on Internet Explorer, kannattaa palvelin lisätä ns. luotettuihin sivustoihin. Ohjeet IE6:lle täällä: http://www.asio.fi/popup.shtml ja 7:lle täällä: http://www.asio.fi/popup_ie7.shtml
• Selain voi olla epäyhteensopiva. Toimistotoiminnoissa kannattaa käyttää Internet Explorer 6 tai uudempaa, mutta myös Firefoxilla homman pitäisi toimia OK. Sen sijaan Operaa tai Mac:n Safaria ei kannata käyttää.
• JavaScript saattaa olla pois päältä selaimesta. Ilman tätä ei valtaosa toiminnoista toimi.
• Evästeiden (cookie) asettamisen pitää olla mahdollista, ja joskus tämä on kielletty selaimesta. Nämä tulisi sallia vähintään kohdesivulle ("target site"). Jos selaimena on IE6 tai IE7, ekan kohdan linkeissä neuvottu luotettuihin sivustoihin lisääminen pitäisi riittää tämän kohdan varmistamiseksi.

Kurssihallinnon sähköpostilähetys merkitsee virheiden lähetysosoitteeksi sen osoitteen, mikä on käyttöoikeuksissa lähettäjän sähköpostiosoitteena.

On tiettyjä tilanteita joissa virheellisestä osoitteesta ei välttämättä palaudu minkäänlaista virheraporttia. Tämä on valitettavasti asia johon ei useinkaan pysty vaikuttamaan. Muutamia esimerkkejä tällaisista tapauksista seuraavassa:

1. Vastaanottajan organisaatiolla voi olla käytössään "haavilaatikko" jonne kaikki sellaiset postit ohjataan joille ei löytynyt oikeaa laatikkoa. Tällöin jos sähköpostiosoitteen alkuosan ennen @ merkkiä on kirjoittanut väärin, menee viesti haavilaatikkoon. Virhettä ei kuitenkaan ole tapahtunut, koska viesti on mennyt perille.
2. Virheelliseen osoitteeseen lähetetyt viestit voidaan tietyissä tilanteissa tulkita roskapostiksi, jolloin virhettä ei myöskään välttämättä palauteta.
3. On myöskin mahdollista että virhepaluuviesti tulkitaan roskapostiksi teidän oman sähköpostipalvelimenne päässä, jolloin se ei välttämättä tule perille.

MySQL ei perusasetuksilla tee eroa isojen ja pienten kirjainten välillä. Asio-Data suosittelee, että koodit kirjataan isoilla kirjaimilla. Missään tapauksessa ei koodeja saa kirjata niin, että ne eroavat vain kirjaimen koon osalta.

Asion Oracleen tekemää web serviceä käytetään ensisijaisesti Asion opiskelijakunnan jäsenrekisteriohjelmistossa sekä opintojaksotarjotinohjelmistossa, ja sen läpi siirretään opiskelijoiden perustietoja, käyttöoikeustietoja sekä joitakin ohjelmien vaatimia perustietoja. Toteuttamamme palikka ei noudata mitään W3C:n web servicen määritystä, vaan on syntynyt puhtaasti kahden meidän oman softan tarpeesta keskustella keskenään HTTP:n yli.

Web service on toteutettu PL/SQL-kehittimen avulla, ja sitä kutsutaan Apache/MySQL/PHP-alustalla toimivasta ohjelmasta PHP:n HTTP-stream-wrapperin avulla. Se on oikeastaan vain normaali Oracle-webbiohjelma, joka HTML-sivun sijaan vastaa saamaansa kyselyyn määrämuotoisesti. Emme käytä toteutuksessa SOAP:n, XML-RPC:n tai WSDL:n kaltaisia mekanismeja, vaan kutsu tehdään tavallisena HTTP-GET-pyyntönä, ja kutsun parametrit välitetään tavalliseen tapaan URL:ssa. Vastauksena tulee CSV-muotoinen (puolipiste-eroteltu) tietosisältö, joka on ryhmitelty 2-ulotteiseksi taulukoksi siten, että ensimmäisellä rivillä on sarakkeiden nimet ja seuraavilla riveillä on itse tietosisältö.

Esimerkiksi kutsun ollessa:
https://palvelin/asio/pls/asio_jasrek.get?func=opisk&henkilotun=10000

Vastaus olisi opiskelijanumerolla 10000 olevan henkilön jäsenrekisteriin luovutettavat tiedot:

henkilotun;henkilotyyppi;sukunimi;etunimi;katuos;postinro;postios;puhelin;email;
10000;O;Testi;Teppo;Testikatu 1;00100;Helsinki;09-123123;asio@asio.fi;

Tässä muodossa tuleva vastaus on helppo parsia PHP:n päässä taulukoksi.

Web servicessä ei ole erillistä autentikointia, vaan käyttöoikeusrajaus on toteutettu IP-osoiterajauksella. Web service -moduuliin määritellään lista IP-osoitteista, joista palvelun kutsuminen on mahdollista. Jos kutsujan IP-osoite ei ole listalla, web service ei palauta vastausta.

Kutsut kannattaa tehdä HTTPS-yhteyden yli mikäli palvelimet eivät ole samassa sisäverkossa. Tällöin PHP saattaa alustasta riippuen edellyttää OpenSSL-kirjastojen asentamista ja konfiguroimista.

Kyse on todennäköisesti www-selaimen suojausasetuksista jotka estävät tiedoston latauksen palvelimelta. Varsinkin Internet Exploreriin on tullut tietoturvapäivitysten myötä asetuksia jotka voivat aiheuttaa tällaisen ongelman.

Helpoin tapa kiertää nämä suojausestot on lisätä kurssihallinto-ohjelmisto ns. luotetuksi sivustoksi. Tämän pitäisi kääntää selaimesta pois kaikki tietoturvan nimissä tehdyt estot, kuten esimerkiksi tiedostojen latauksen eston.

Ohjeet suojatuksi sivuksi lisäämiselle löytyvät allaolevista linkeistä:

Internet Explorer 6:
http://www.asio.fi/popup.shtml

Internet Explorer 7:
http://www.asio.fi/popup_ie7.shtml

Vihreät reunukset liittyvät siihen, että tietyssä liikuntatilassa voidaan tiettyjä lajeja harrastaa kerralla useammalla kuin yhdellä kentällä. Esim. Jalkapallo/länsi, sulkapalloa voidaan pelata kahdella kentällä.

Asio mahdollistaa em. monikenttäkäsittelyn sillä ainoalla rajauksella, että samaan aikaan voi harrastaa vain yhtä lajia. Jos kenttiä on vapaana (kuten esimerkissäsi), vihreän reunuksen sisällä olevat kellonajat ilmoittavat, milloin vähintään puolen tunnin aikaväli kysesitä lajia voidaan pelata. Klikkaamalla ko. kohtaa ohjelma asettaa tietyt arvot automaattisesti varausikkunaan ja tekee varauksen, joka aikaisemmin olisi estetty päällekkäisyyseston pohjalta.

• <YKSIKKÖ> = selailunäkymässä näytetään vain tämän yksikön tilat. Parametria voidaan käyttää myös vaihtoehtoisen selailijaroolin valintaan. Tarkempia tietoja useiden selailijaroolien käytöstä löydät tilavarausohjelmiston käyttöohjeista.
• <TIETOKANTA> = asiakastietokantasi nimi. Tämä parametri tarvitaan, koska samalla palvelimella voi olla käytössä useita tietokantoja.
• <KALENTERITYYPPI> = oletusarvoisesti päävalikossa avattuna näytettävä kalenterityyppi. Mahdollisia arvoja ovat:
  • tila = tilakalenterit
  • hlo = henkilökalenterit
  • lk = ohjelma/ryhmäkalenterit

PHP-ohjelmien kannalta perinteisesti ongelmallisia merkkejä ovat vain kenoviiva \ jota käytetään PHP:ssä ja MySQL:ssä eskapointimerkkinä ja heittomerkki ' jota käytetään MySQL:ssä merkkijonoerottimena. Asio-tilanvarausohjelmistossa nämäkin merkit toimivat, koska eskapoimme ohjelmistossa kyllä kaikki merkkijonot tietokantaoperaatioissa.

Ulkoista käyttäjätietojärjestelmää vastaan autentikoiduttaessa voidaan kuitenkin törmätä järjestelmäkohtaisiin merkistörajoitteisiin tai enkoodausongelmiin. Yleisesti ottaen aina toimivia merkkejä ovat vähintäänkin isot kirjaimet A-B, pienet kirjaimet a-b, numerot 0-9 sekä alaviiva _.

Kertomerkin * käyttöä salasanossa tulisi välttää. Jos paikallisesti tallennetun käyttäjän salasana on pelkkä *, niin autentikoinnissa syötettyä salasanaa yritetään tarkistaa ulkoisesta järjestelmästä.

• Hän on itse tehnyt varauksen tai hänet on merkitty varaukseen opettajaksi. Vain ylläpitäjä pääsee muuttamaan ja poistamaan muiden tekemiä varauksia.
• Henkilöllä ei ole päällä varauksen poistoa rajoittavia päivämäärävalintoja. Pääkäyttäjätoimintojen kautta voidaan rajata esim. että henkilö voi tehdä muutoksia tai poistaa (=peruuttaa) varauksen vain, jos varaukseen on aikaa tietty määrä päiviä.

1. Avaa varaus varauksen muutoksen kautta.
2. Mene henkilön varausriville, ja paina hakupainiketta.
3. Etsi henkilö henkilörekisteristä, ja poimi hänet uudestaan varaukseen.
4. Tallenna varaus.

Juuri näin järjestelmän kuuluukin toimia. Lähetysvaiheessa voidaan olla varmoja vain siitä, että sähköpostiosoite on muodoltaan oikea ja että lähettävä palvelin pystyy toimittamaan viestin eteenpäin. Näitä koskevat virheet näkyvät heti lähetysvaiheessa.

Viestin toimittamisessa matkan varrella voi sen sijaan tulla monenlaisia lähettävästä palvelimesta riippumattomia virheitä: esimerkiksi vastaanottajan laatikko voi olla täynnä tai vastaanottavassa organisaatiossa ei ole ollenkaan pyydettyä laatikkoa. Tällaiset virheraportit palautuvat sähköpostiviestinä virkailijan käyttöoikeuksiin kirjattuun sähköpostiosoitteeseen.

• Asiakasliittymä ilman kirjautumista: yksikkötiedon avulla voidaan määrittää, mitä varauskohteita, kursseja, opettajia, ohjelmia (ryhmiä) ja tapahtumia käyttäjälle näytetään.
• Käyttöoikeudet: Mikäli käytätte toimintoa "Piilota varausten tiedot muilta yksiköiltä" (ylläpito -> yrityskohtaiset aseukset) ja mikäli käyttäjän käyttöoikeuksiin on määritelty yksikkötieto, muiden yksiköiden tekemät varaukset näkyvät käyttäjälle vain väripalkkeina ilman tekstuaalista tietoa.
• Statusnäytöt ja opetuksen suunnittelu: Yksikkötietoa käytetään yläkäsitteenä ohjelmien (ryhmien) poiminnassa
• Kurssikalenterit ja ryhmäkalenterit: Kurssikalenterit on mahdollista ryhmitellä päävalikossa yksiköittäin. Asio-Data voi aktivoida tämän toiminnon asiakaskohtaisesti.

Tällä hetkellä viikonpäivien valinta toimii seuraavasti:

1) Varauksen tekoa aloitettaessa (kun on klikattu esim. maanantaita) on klikatun päivän kohdalla ruksi, ja muiden viikonpäivävalintalaatikoiden valitseminen on estetty. Alku- ja loppupvm:inä on sisääntulopvm.

2) Valittaessa uusi loppupvm alle 7 päivän päähän alkupvm:stä ohjelma tekee kyseiselle välille osuvien viikonpäivävalintalaatikoiden valitsemisen mahdolliseksi ja ruksittaa ne.

3) Valittaessa uusi loppupvm vähintään 7 päivän päähän alkupvm:stä ohjelma tekee kaikkien viikonpäivävalintalaatikoiden valitsemisen mahdolliseksi, mutta ei ruksaa ylimääräisiä päiviä.

Palvelimen Fully Qualified Domain Name ei ole oikein asetettu (Jotkin sähköpostia vastaanottavat serverit ovat tarkkoja tästä). Tarkista /etc/hostname ja /etc/hosts -konfiguraatiotiedostoista että palvelimen nimi on asetettu kokonaan, esim. asp.asio.fi eikä pelkkä asp.

FQDN:n näkee antamalla käskyn "hostname --fqdn"

• safe_mode = Off
  PHP:n safe moden on oltava sähköpostin lähetyksessä pois päältä, koska mail-komennolle annetaan ns. envelope-osoite käyttäjän tiedoista. Tämän tiedon välittäminen on safe modessa kielletty. Safe mode voi estää myöskin väliaikaiseen hakemistoon kirjoittamisen PHP:ltä, koska se sallii tiedostojen käsittelyn vain tiettyihin polkuihin.
• file_uploads = On
  Sähköpostiliitteet välitetään PHP:lle HTTP POST multipart/form-data -menetelmällä. Tämä asetus sallii PHP:n vastaanottaa tällä tavoin lähetettyjä tiedostoja.
• upload_max_filesize = 16M (esimerkiksi, tai muu sopiva liitteen maksimikoko)
  Tämä asetus asettaa sen, miten suuri lähetettävä liitetiedosto saa olla. Palvelin ei hyväksy tätä suurempia tiedostoja.
• post_max_size = 16M (esimerkiksi, vähintään sama kuin upload_max_filesize)
  Tämä asetus asettaa sen, miten suuri palvelimelle saapuva HTTP POST -palvelupyyntö saa olla.

Suurin hyöty käyttäjäorganisaation kannalta uuteen roolipohjaiseen käyttöoikeuteen siirtymisessä on käyttäjien ylläpitotyön helpottuminen. Esimerkiksi jos tilahallinnon puolella tulee varauskohteisiin muutoksia, joutuisi vanhalla systeemillä käymään koko käyttäjämassan läpi ja tarkistamaan tilalajirajaukset jokaiselta käyttäjältä yksitellen. Uudessa systeemissä riittää että muutoksen tekee rooliin.

Käyttäjien siirtäminen tiettyyn rooliin onnistuu helposti "roolien joukkoasetus"-toiminnolla, joka on hakutulossivun lopussa. Sillä voi asettaa roolin monelle käyttäjälle kerrallaan.

Kaikkia käyttäjiä, esim. pääkäyttäjää ja muita ylläpitäjiä, ei ehkä kannatakaan laittaa rooleihin. Uusi järjestelmä toimii roolittomien käyttäjien osalta täsmälleen samalla tavalla kuin vanhakin. Epäilisin että ainakin kaikki opettajat ja muut "laumaeläimet" on hyvä laittaa johonkin tiettyyn rooliin, tai sitten esim. eri yksiköiden opettajat kukin omaan rooliinsa. Tämä riippuu hieman siitä miten tarkasti käyttöoikeuksia jaetaan: jos kaikilla opettajilla on suurinpiirtein samat oikeudet, niin yksi rooli riittää.

Vielä yksi lisäetu uudessa käyttöoikeusjärjestelmässä on, ja se liittyy ulkoiseen autentikointiin. Ulkoisesta käyttäjätietojärjestelmästä saatujen tietojen (esim. LDAP-hakemiston ryhmäjäsenyydet) perusteella voidaan kiinnittää käyttäjälle rooli. Rooleja ylläpitämällä on helppoa ja joustavaa hallita noita ulkoista järjestelmää vastaan autentikoitavia käyttäjiä.

MySQL-tietokantapalvelimen max_allowed_packet-asetus on liian pieni. Kyseinen asetus määrittelee suoritettavan SQL-kyselyn maksimikoon. Tietyissä tilanteissa, esimerkiksi suurten lukujärjestystiedostojen tapauksessa, tilavarausohjelmiston vaatima kyselyn maksimikoko voi muodostua suuremmaksi kuin MySQL:n oletusarvoinen maksimi, joka on 1 megatavu.

Ratkaisu ongelmaan on kasvattaa asetuksen kokoa. Sopiva asetuksen arvo raskaaseen käyttöön on esimerkiksi 8 megatavua ("8M"). Asetus tehdään joko my.ini (Linux: my.cnf) -tiedostoon tai annetaan käynnistysparametrina MySQL-palvelimelle.

Lisätietoja asetuksesta löydät MySQL:n ohjekirjasta.

Todennäköisin selitys on se, että dumppitiedostosta ovat kadonneet auto_increment-määreet MySQL:n tietyissä versioissa olevan bugin takia. Saat korjattua tilanteen hakemalla Asion palvelimelta viimeisimmän tietokantasynkronointiskriptin, ja suorittamalla sen. Osoite synkronointiskriptin hakemiselle on annettu sinulle asennuspaketin lähetyksen yhteydessä sähköpostitse. Jos olet hukannut osoitteen, ota yhteys Asio-Dataan.

Lisätietoja bugista alempana tämän FAQ:n kohdassa "Miten muodostan tietokannasta dumpin tietokannan siirtoa tai varmistusta varten?".

Kyse on MySQL:n InnoDB-tietokantamoottorin antama virheilmoitus, joka tarkoittaa todennäköisesti jompaa kumpaa seuraavista kahdesta asiasta:

1) MySQL luulee taulun olevan jo olemassa vaikka sitä ei vielä oikeasti olekaa olemassa. Tällainen tilanne on voinut syntyä esimerkiksi levyvian tai tietokantatiedostojen toisesta tietokannasta kopioinnin tuloksena. Kokeile pudottaa taulu ensin "DROP TABLE"-komennolla, ja sitten ajaa kysely uudestaan.

2) CREATE TABLE-käskyn syntaksissa on virhe liittyen avaimien nimiin, joka johtaisi InnoDB-moottorissa kahden avaimen menemiseen samalle nimelle.

Suositeltava tapa korjata virhe on vaihtaa tietokantamoottorin tyypiksi InnoDB:n sijaan MyISAM (kts. kts. tilanvarausohjelmiston tekninen dokumentaatio, MySQL:n asennusta koskeva kappale). Voit vaihtoehtoisesti luoda taulun käsin lisäämällä CREATE TABLE -käskyn perään tietokannan valintaparametrin seuraavaan tapaan:

	CREATE TABLE taulu (
	  kentta1 varchar(25),
	  kentta2 varchar(255),
	  ....
	) TYPE=MyISAM;
	

Vika on todennäköisesti palvelimenne PHP:n timeout-arvon pienuudessa. Itse käytämme täällä 10 minuutin timeoutia.

Ratkaisu: editoi php.ini - tiedostoon asetus max_execution_time suuremmaksi, esim 600. Jotta tulisi voimaan, kirjoita

	  net stop apache
	  net start apache
	

	mysqldump --opt -K --skip-comments TIETOKANNAN_NIMI > dumppi.sql
	

	mysqldump --opt -K --skip-comments --compatible=mysql323 TIETOKANNAN_NIMI > dumppi.sql
	

	mysql --force TIETOKANNAN_NIMI < dumppi.sql
	

	REPAIR TABLE session_p;
	

UPDATE mysql.user
SET Password = OLD_PASSWORD('TIETOKANNAN SALASANA')
WHERE User = 'TIETOKANNAN KTUN';
	

$db_server = "PALVELIMEN OSOITE, OLETUS=TYHJÄ";
$db_user	= "TIETOKANNAN KÄYTTÄJÄTUNNUS";
$db_passwd = "TIETOKANNAN SALASANA";