Open ajrajala opened 1 year ago
Vaarassa on vastaava tilanne syntynyt 30.5.2023 lisätylle asiakkaalle eli pakolliset osoitetiedot puuttuvat asiakkaalta kokonaan. https://vaara.koha-suomi.fi/cgi-bin/koha/members/moremember.pl?borrowernumber=11011313
Onkohan teillä mahdollisesti ollut vielä tuolloin käytössä pika-asiakaslisäys, jossa tuo kenttä ei ole ollut pakollinen?
Ilman osoitetta lisääminen onnistuu, jos osoite-kentän laittaa ns. piiloon. Se tapahtuu joskus ihan vahingossakin, koska nuo asiakkaan lisäyssivulla olevat kentät saa kunkin kentän otsikosta klikkaamalla piilotettua. Puhuin tästä juuri viime viikolla Larille (valituksen aihe: olisi käyttöliittymän kannalta hyvä, jos piilotettujen kenttien otsikon viereen tulisi vaikka plussapainike, jotta helpommin tajuaa, että jotain puuttuu). En siinä vaiheessa hoksannut, että jos kentät ovat piilotettuna, ne eivät enää olekaan pakollisia.
Ilman osoitetta lisääminen onnistuu, jos osoite-kentän laittaa ns. piiloon. Se tapahtuu joskus ihan vahingossakin, koska nuo asiakkaan lisäyssivulla olevat kentät saa kunkin kentän otsikosta klikkaamalla piilotettua. Puhuin tästä juuri viime viikolla Larille (valituksen aihe: olisi käyttöliittymän kannalta hyvä, jos piilotettujen kenttien otsikon viereen tulisi vaikka plussapainike, jotta helpommin tajuaa, että jotain puuttuu). En siinä vaiheessa hoksannut, että jos kentät ovat piilotettuna, ne eivät enää olekaan pakollisia.
No niinpä näkyy onnistuvan noin. Siinä on siis ihan kunnon bugi. Tutkailen löytyykö tuohon yhteisöstä jo korjaus, kopataan se meille matkaan jos löytyy.
EDIT. Bugi on myös yhteisöversiossa.
Tähän kaivataan testejä. :)
Vaski-testillä tulee nyt virheilmoitus, jos osoite-kentät pistää pois näkyvistä ja yrittää tallentaa asiakkaan ilman osoitetietoja:
Lapissa testillä tulee sama viesti. :)
Samoin Siilissä, tallennus ei onnistu ilman osoitetta.
Testattu Vaara-testillä. Ei onnistunut tallentaa ilman pakollisia tietoja (kortinnumeroa myös testailtu).
Näihin liittyvät käännökset löytyvät koha-translations-reposta 22.xx-branchista.
Oletteko testanneet myös niin, että tallennus onnistuu sen jälkeen, kun on saanut virheilmoituksen ja korjannut tiedot?
OUTIssa ei myöskään onnistunut tallentaa ilman osoitetta. Tuli sama virheilmoitus minkä Anni laittoi aiemmin.
Kun osoitetiedot kävi lisäämässä, tallennus onnistui.
Tässä tulikin mutka matkaan. Tämä ongelma siis korjattiin niin, että lomakkeen validointi ei enää jätä huomiotta piilotettuja kenttiä. Mutta takaajan suhde-kenttä on aina piilotettuna, vaikkei kenttä olekaan muokattavissa, se näkyy vain silloin kun lisää uuden takaajan. Se on myös aina pakollinen, paitsi jos borrowerRelationship-asetuksessa ei ole arvoa, mutta asetuksen tyhjäys estää myös suhde-arvon lisäämisen takaajalle. Tämä estää nyt lapsiasiakkaiden muokkaamisen ja kopioinnin testeillä. Eli laitetaankin tämä takaisin työn alle.
Tässä tulikin mutka matkaan. Tämä ongelma siis korjattiin niin, että lomakkeen validointi ei enää jätä huomiotta piilotettuja kenttiä. Mutta takaajan suhde-kenttä on aina piilotettuna, vaikkei kenttä olekaan muokattavissa, se näkyy vain silloin kun lisää uuden takaajan. Se on myös aina pakollinen, paitsi jos borrowerRelationship-asetuksessa ei ole arvoa, mutta asetuksen tyhjäys estää myös suhde-arvon lisäämisen takaajalle. Tämä estää nyt lapsiasiakkaiden muokkaamisen ja kopioinnin testeillä. Eli laitetaankin tämä takaisin työn alle.
Tämä on nyt korjattu. Tätä voisi testailla vielä niin, että 1) testaa ettei ilman vaadittuja tietoja pysty edelleenkään tallentamaan 2) testaa, että lapsiasiakaan voi tallentaa muutamatta takaaja tietoja 3) testaa, ettei lapsiasikasta voi tallentaa jos takaajalta puuttuu suhde-tieto
Kun lisää taattavaa, asiakaslajina on automaattisesti kirjasto/osasto. Muuten näytti toimivan toivotusti.
Ilman pakollisia tietoja en pystynyt tallentamaan asiakasta, ei vaikka osion kentät olisi lomakkeelta klikattu otsikosta piiloon.
Olemassaolevan lapsiasiakkaan tiedot pystyi tallentamaan ilman että teki mitään muutoksia takaajan osalta.
Jos lisään lapsiasiakkaan huoltajan tietojen kautta ("Lisää huollettava" -nappi) ja tallennan ilman Suhde-tietoa, seuraa tallennuksesta virhe 500 ja asiakastietue tallentuu ilman huoltajatietoa. Jos lähtee tekemään lapsiasiakasta "Uusi asiakas" -valikon kautta tai muokkaa olemassa olevaa lapsiasiakasta, virhettä ei tapahdu vaan Koha herjaa puuttuvasta pakollisesta kentästä.
Kun lisää taattavaa, asiakaslajina on automaattisesti kirjasto/osasto. Muuten näytti toimivan toivotusti.
Miten tämä siis näkyy? En ihan ymmärrä mitä tuo kirjasto/osasto meinaa tässä.
Tällä välillä on jotain muuttunut, koska nyt mullekin tulee tuo Annin kohdassa 3 mainitsema virhe 500 ja asiakaslajiksi (otsikko Kirjastonhallinta -> Tyyppi) tulee automaattisesti Lapsiasiakas. Eli aiemmin, kun valitsin huoltajan tiedoista Lisää taattava -painikkeen kautta uuden asiakaspohjan, sillä pohjalla oli asiakaslajina Kirjasto/osasto. Nyt se antaa suoraan asiakaslajiksi Lapsiasiakas ja tulee tuo virhe 500, jos yrittää tallentaa ilman valittua suhdetta Asiakastakaaja-kentän alta.
Nyt huomasinkin, mistä oli kyse, eli jos lisään taattavan huoltajan lainaus-sivun kautta (https://vaara-test.koha-suomi.fi/cgi-bin/koha/circ/circulation.pl?borrowernumber=), taattavan asiakaslaji (tyyppi) on kirjasto/osasto. Jos lisään taattavan huoltajan asiakastietosivulta (https://vaara-test.koha-suomi.fi/cgi-bin/koha/members/moremember.pl?borrowernumber=), tulee asiakaslajiksi lapsi. Molemmilla kerroilla tulee tuo virhe 500, jos takaajasuhteen jättää tyhjäksi.
Tuo, että tyhjä takaajasuhde aiheuttaa 500 herjan, on yhteisön "ominaisuus". Siihen ei ole siis rakennettu minkäänlaista käyttäjäystävällistä virheviestiä, vaan luotetaan siihen että tuon pohjan validointi Javascriptillä toimii aina oikein. Joka ei siis tällä hetkellä toimi oikein tuon "Lisää taattava" napin takaa. Korjailin tuon, mutta vielä pitäisi saada tuohon "Asiakastakaaja" osioon näkymään oikein virheviesti.
Melkein pääsi unohtumaan, tästä on nyt korjattu tuo takaaja ongelma. Eli tätä voisi testata vielä uudelleen.
Testasin lisäämällä lapsiasiakkaan tyhjästä. Ei antanut tallentaa ilman osoitetietoja tai takaajan valintaa. Testasin myös lisäämällä lapsiasiakkaan lähtemällä takaajan tiedoista Lisää taattava. Takaajan suhde oli pakko valita ennen kuin tallennus onnistui. Lapsen asiakastyypiksi olisi tullut Kirjasto/Osasto, jos en olisi sitä muuttanut. Meillä on kaikkiaan kolmella asiakastyypillä "voi olla taattava"-status, joten tämä on vähän ongelmallinen.
Testasin lisäämällä lapsiasiakkaan tyhjästä. Ei antanut tallentaa ilman osoitetietoja tai takaajan valintaa. Testasin myös lisäämällä lapsiasiakkaan lähtemällä takaajan tiedoista Lisää taattava. Takaajan suhde oli pakko valita ennen kuin tallennus onnistui. Lapsen asiakastyypiksi olisi tullut Kirjasto/Osasto, jos en olisi sitä muuttanut. Meillä on kaikkiaan kolmella asiakastyypillä "voi olla taattava"-status, joten tämä on vähän ongelmallinen.
Toimiiko se tuotannossakin tuolla tavalla vai ainoastaan testeillä. Ei ihan äkkiseltään tule mieleen ainakaan tämän korjauksen osalta, mikä tuon väärän asiakastyypin voisi aiheuttaa.
Mie luulen, että nyt kuin huolettavien tyyppejä on useampi, niin Koha antaa randomisti (kuten tuppaa tekemään) jonkun vain niistä.
Voisiko Vaarassa ottaa käyttöön tämän JS-rimpsu, jolla käyttäjä valitsee, mitä asiakastyyppiä huollettava on: Lisää huollettava -monivalintanappi
Esimerkki OUTIsta:
Jos tuo on ok, niin teetkö Päivi siitä erillisen tiketin? :)
Tuotannossa antoi ainakin tällä yrityksellä ihan oikean asiakastyypin lapselle, jonka lisäsin takaajan tietojen kautta. Mutta jos tuo oli "vahinko", täytyy ottaa käyttöön tuo Outin esimerkin mukainen valikko.
Testasin tuotannossa muutaman kerran ja aina antoi Lapsiasiakkaan valikosta. Tosin tuotannossa on vain kaksi "voi olla taattava"-statuksella olevaa asiakastyyppiä. Tämä ei liene siis mikään ongelma.
Testasin testausohjeen mukaisesti uudelleen, minun silmään näyttäisi pelittävän nyt kaikilta osin:
Helle-testissä lisäsin uuden Aikunen-asiakastiedon, jonka tiedoista puuttuu pakollinen Osoite-kentän arvo. Asiakastiedon tallennus ei onnistu.
Poistin asetuksista Osoite-kentän pakollisuuden ja tallensin asiakastiedon ilman Osoite-kenttäarvoa. Asiakas borrowernumber=127888. Tallensin asetuksissa Osoite-kentän pakollisuuden takaisin käyttöön.
Lisäsin uuden Lapsi-asiakkaan tiedot ja asiakkaan takaajaksi äsken lisäämäni Aikuinen-asiakastiedon, jonka tiedoista puuttuu pakollinen Osoite-kenttä. Jätin Suhde-arvon valitsematta. Lapsi-asiakastietoa tallentaessa Koha ilmoitti puuttuvasta Suhde-arvosta
Lisäsin Suhde-arvon Takaaja
Lapsi-asiakastiedon tallennus onnistui. Borrowernumber=127889.
Testailin OUTIssa tuon testisuunnitelman mukaisesti ja vaikuttaisi toimivan kuten pitääkin.
EDIT! Paitsi, että kun yritin poistaa testiasiakastani niin eipä suostunut poistumaan vaan tuli virhe 500. Kokeilin sitten eri tyyppejä (henkilöasiakas, jolla ei taattavaa, LAPSI ja LAOMATOIMI) ja kaikilla sama homma. Henkilöasiakkaalle jolla oli huollettava, tuli ihan oikein ilmoitus "Ei voi poistaa asiakasta. Asiakkaalla on huollettavia."
Siilin testillä tuntui toimivan kuten piti. Meillä on vain yhdenlaisia taattavia eli LAPSI (Lapsiasiakas, Huollettava). En havainnut asiakasta poistaessa ylläolevaa virhe 500:aa. Testikanta taitaa kyllä muutoin olla herkempi kaikenlaisille tilapäisille virhe 500:ille?
Testailin OUTIssa tuon testisuunnitelman mukaisesti ja vaikuttaisi toimivan kuten pitääkin.
EDIT! Paitsi, että kun yritin poistaa testiasiakastani niin eipä suostunut poistumaan vaan tuli virhe 500. Kokeilin sitten eri tyyppejä (henkilöasiakas, jolla ei taattavaa, LAPSI ja LAOMATOIMI) ja kaikilla sama homma. Henkilöasiakkaalle jolla oli huollettava, tuli ihan oikein ilmoitus "Ei voi poistaa asiakasta. Asiakkaalla on huollettavia."
Helle-testillä myös Virhe 500, kun yrittää poistaa asiakastiedon. Testasin muutaman asiakastyypin asiakkaan poistamisen (AIKUINEN, EITILASTO).
Testien perusteella tämä vaikuttaisi toimivan kuten pitää. Viedään seuraavassa päivityksessä tuotantoon.
Testien perusteella tämä vaikuttaisi toimivan kuten pitää. Viedään seuraavassa päivityksessä tuotantoon.
Helle-testillä on edelleen ongelmana se, että asiakastietojen poisto ei onnistu. Testasin nyt uudestaan eri asiakastyyppien asiakastiedon poiston.
Asiakastietoa poistaessa Koha ilmoittaa
Laitanpa tämän Katin kommentin perusteella takaisin työn alle :D
Ainakin Hellen testillä ihan henkilo-asiakkaankin poistaminen johta 500 virheeseen ja lokille kirjautuu seuraavaa:
DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Unknown column 'me.flags' in 'field list' at /home/koha/Koha/Koha/Objects.pm line 394
Skeemassa on nyt jotain pyllyllään. Tutkitaan johtuuko muutoksesta vai onko siellä jotain muuta vinossa.
Testailin OUTIssa tuon testisuunnitelman mukaisesti ja vaikuttaisi toimivan kuten pitääkin.
EDIT! Paitsi, että kun yritin poistaa testiasiakastani niin eipä suostunut poistumaan vaan tuli virhe 500. Kokeilin sitten eri tyyppejä (henkilöasiakas, jolla ei taattavaa, LAPSI ja LAOMATOIMI) ja kaikilla sama homma. Henkilöasiakkaalle jolla oli huollettava, tuli ihan oikein ilmoitus "Ei voi poistaa asiakasta. Asiakkaalla on huollettavia."
Tämä ei enää toistu OUTIn testillä, mutta Hellessä kylläkin. Jännittävää :D
Testailin OUTIssa tuon testisuunnitelman mukaisesti ja vaikuttaisi toimivan kuten pitääkin. EDIT! Paitsi, että kun yritin poistaa testiasiakastani niin eipä suostunut poistumaan vaan tuli virhe 500. Kokeilin sitten eri tyyppejä (henkilöasiakas, jolla ei taattavaa, LAPSI ja LAOMATOIMI) ja kaikilla sama homma. Henkilöasiakkaalle jolla oli huollettava, tuli ihan oikein ilmoitus "Ei voi poistaa asiakasta. Asiakkaalla on huollettavia."
Tämä ei enää toistu OUTIn testillä, mutta Hellessä kylläkin. Jännittävää :D
Testailin lisää ja tässä on kyse jostain kummallisesta Hellen, Vaskin ja Lapin ongelmasta. Muilla testeillä poistuu kyllä asiakaat ihan ok.
No niin, 500 herja on nyt korjattu. Siellä oli jotain mystisesti vinossa, testien uudelleenrakennus ja palveluiden uudelleenkäynnistys auttoi.
Kiitos Emmi, Helle-testissä asiakastiedon poisto onnistuu nyt :) Testasin muutaman eri asiakastyypin asiakastiedon poiston.
Eiköhän tän uskalla laittaa ensi viikon päivitykseen, ei tuo kupru tästä johtunut :smile:
Vaskin tuotannossa ei enää toimi asiakkaan tallennus. Testatessani osoitetietojen pois jättämistä, huomasin että Koha herjaa pakollisesta, puuttuvasta asiakasmääreestä vaikka ko. kenttä ei ole pakollinen. Jos kenttään tekee valinnan, ei asiakastietuetta saa siltikään tallennettua.
Testillä vastaavaa ongelmaa ei ilmennyt (testasin vielä äsken siellä uusiksi).
Näköjään ongelma liittyy siihen, että meillä on automaatti-asiakaslajille pakolliseksi määriteltyjä asiakasmääreitä. Poistin pakollisuuden ja tavallisen henkilöasiakkaan tallentaminen onnistui.
Tuo, että vain tietylle asiakaslajille pakolliseksi määritelty asiakasmääre, on ollut ongelmana joskus aiemmin ja korjaantui versiossa 22.11 (tiketti https://tiketti.koha-suomi.fi/issues/5539). Tämä osoitetietoihin liittyvä korjaus on kaiketi tuonut ongelman takaisin. Testillä automaattien asiakasmäärekentät on jääneet muuttaamatta pakollisiksi joten ongelma ei tullut siellä testatessa esille.
Näköjään ongelma liittyy siihen, että meillä on automaatti-asiakaslajille pakolliseksi määriteltyjä asiakasmääreitä. Poistin pakollisuuden ja tavallisen henkilöasiakkaan tallentaminen onnistui.
Tuo, että vain tietylle asiakaslajille pakolliseksi määritelty asiakasmääre, on ollut ongelmana joskus aiemmin ja korjaantui versiossa 22.11 (tiketti https://tiketti.koha-suomi.fi/issues/5539). Tämä osoitetietoihin liittyvä korjaus on kaiketi tuonut ongelman takaisin. Testillä automaattien asiakasmäärekentät on jääneet muuttaamatta pakollisiksi joten ongelma ei tullut siellä testatessa esille.
Enpä tosiaan huomannut ottaa huomioon tällaisiä piilotettuja kenttiä. Yritän katella tässä piakkoin saako ongelman kierrettyä jollain tapaa.
Kirjailenpa tännekin mikä tässä mättää. Eli Koha käsittelee asiakasmääreitä niin, että ne on piilotettu pohjasta jos ne eivät koske tiettyä asiakastyyppiä. Jos määre on pakollinen, se on sitä myös piilotettuna, mikä estää asiakkaan tallennuksen tämän korjauksen kanssa.
Korjaus on periaatteessa helppo, jos määre ei koske asiakastyyppiä, sitä ei aseteta pakolliseksi. Ongelmana tässä on vain se, että jos asiakastyypin vaihtaa kesken asiakkaan luomisen sellaiseksi asiakastyypiksi, jolla määreen tulisi olla pakollinen, pakollisuutta ei asetetakaan. Eli tämän jälkeen ollaan oikestaan jälleen alkuperäisessä ongelmassa, asiakkaan voi tallentaa ilman pakollista kenttää. Pitää kokeilla saako tuota käpisteltyä muuttumaan dynaamisesti.
Korjaus viety testeille. Asiakkaan pitäisi nyt tallentua vaikka pakollinen asiakasmääre piilottelisikin tallennuspohjassa.
Muutin vaski-testillä automaatti-asiakaslajille määritellyt asiakasmääreet pakollisiksi. Saan silti henkilöasiakasta tallentaessa herjan puuttuvista pakollisista määreistä, koitin välissä päivittää sivun ctrl+f5.
Muutin vaski-testillä automaatti-asiakaslajille määritellyt asiakasmääreet pakollisiksi. Saan silti henkilöasiakasta tallentaessa herjan puuttuvista pakollisista määreistä, koitin välissä päivittää sivun ctrl+f5.
Korjattu korjaus, toimisikohan nyt kuten pitää?
Juu, nyt näyttää hyvältä! Vaski-testillä herjaa nyt automaatti-asiakaslajin pakollisista kentistä vain jos olen lisäämässä tietuetta automaatti-asiakaslajille.
Testasin samalla, että ilman osoitetietoja tallentaminen ei edelleenkään onnistu vaikka osoitekentät olisi lomakkeelta klikattu piiloon.
Korjaus tuotu onnistuneesti tuotantoon, suljen tiketin.
Tiketti Bugzillassa on edelleen kesken, joten avaan tämän tiketin vielä Bugiton-tietovarannossa, että muistetaan seurata sitä. :)
Mikä vikana?
Virkailija oli saanut (versiopäivityksen jälkeen) lisättyä uuden asiakkaan ilman osoitetietoja. Virkailija muisteli, että lomakkeelta olisi puuttuneet osoitekentät, ja joka tapauksessa tallentamisen jälkeen asiakkaan tietoihin mentyään kentät näkyivät tyhjinä.
En saa toistettua tilannetta, mutta löysin yhden Kohan käytön aikana tallennetun asiakastietueen, jossa katuosoite on tyhjä: https://vaski.koha-suomi.fi/cgi-bin/koha/members/moremember.pl?borrowernumber=388452. Asiaks on lisätty 2.6.2023.
En tiedä pystyykö tätä mitenkään sen enempää tutkimaan, mutta ehkä hyvä joka tapauksessa kirjata tapaus ylös jos vastaavaa tulee vielä vastaan.
Mitä pitäisi tapahtua
No response
Kuinka toistaa ongelma/asia
No response
Selain
No response
Jotain muuta?
No response