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";