Nidehaun tulosten järjestäminen julkaisuvuoden mukaan ei toimi oikein

[ajrajala]

Mikä vikana?

Kun nidehaun tuloksissa klikkaa saraketta Julkaisuvuosi ( Publication year), niteet hakutuloksessa järjestetään kyllä uudelleen mutta ne eivät mene julkaisuvuoden mukaiseen järjestykseen. Jos saraketta klikkaa uudelleen järjestääkseen niteet laskevaan järjestykseen, ei tapahdu enää mitään.

Mitä pitäisi tapahtua

No response

Kuinka toistaa ongelma/asia

1. Mene nidehakuun ja tee jokin haku
2. Järjestä hakutulossivulla tulos Publication year -sarakkeen mukaan
3. Huomaa, että järjestys muuttuu mutta ei ole oikein
4. Järjestä tulos uudelleen saman sarakkeen mukaan
5. Huomaa, että mitään ei enää tapahdu

Selain

No response

Jotain muuta?

[AnneliO]

Testailin tätä PTFS:n sandboxissa ja siellä minusta vuoden mukaan järjestäminen onnistui. Siellä oli kuitenkin seuraavat asiat eri tavalla:

• Publication date -sarakkeessa näkyi 260c-kentän tieto - meillä 264c tai 260c riippuen tietueen vanhuudesta (Ei RDA-konversiota)
• 260c oli mäpätty biblioitems.copyrightdate-sarakkeeseen - meillä biblioitems.publicationyear. Ei mäppäystä copyrightdate-sarakkeeseen.

[AnneliO]

Testailin vielä lisää ja tein sandboxiin samanlaisen mäppäyksen kuin meillä ja siirsin vuosiluvun 264c-kenttään. Vuosiluku tulee nidehaussa näkyville ja järjestäminenkin onnistuu.

Yritin myös kaivella bugzillaa, mutta en ainakaan löytänyt mitään tähän liityvää sieltä.

[lmstrand]

Helle-testillä järjestäminen näyttäisi toimivan molempiin suuntiin ihan oikein.

[AnneliO]

Helle-testillä järjestäminen näyttäisi toimivan molempiin suuntiin ihan oikein.

Mielenkiintoista, minulla ei toimi siellä julkaisuvuodella järjestäminen oikein.

[pknuuti]

Vaaran testillä näyttäisi toimivan nidehaun tuloksissa julkaisuvuodella järjestäminen. Kun ensin klikkaa julkaisuvuosisaraketta, tulee ensimmäiseksi vuosiluvuttomat nimekkeet ja kun klikkaa uudelleen, järjestyy listaus uusimmasta vanhempaan päin. Vuosiluvuttomissa tietueissa julkaisuvuosi on kentässä 264c, vuosiluvullisissa 260c. Sinänsä järjestäminen ei toimi oikein, koska noissa "vuosiluvuttomissa" on toki vuosiluvut olemassa, mutta ei siinä kentässä mistä tämä järjestäminen vuoden ottaa.

[lmstrand]

Tuolleen toimi siis Helle-testillä minulla, kuten Päivi kuvaili.

[AnneliO]

Minullakin kyllä tulee vuodettomat alkuun, mutta kun selaan listaa alaspäin, on vuodettomien seassa random vuosilukuja.

[pknuuti]

Mä en saa tuollaista tilannetta, mitä Anneli kuvaat. Millaisen haun teit tai onko antaa nimekkeitä, jotka järjestyvät väärin? Vai tarkoitatko Hellen testiä, et Vaaran?

[AnneliO]

Mä en saa tuollaista tilannetta, mitä Anneli kuvaat. Millaisen haun teit tai onko antaa nimekkeitä, jotka järjestyvät väärin? Vai tarkoitatko Hellen testiä, et Vaaran?

Testasin aiemmin siis Hellen testillä, mutta tein vastaavan haun nyt myös Vaaran testillä. Eli hain kaikki niteet, joissa on kotikirjastona Enon kirjasto ja järjestin ne julkaisuvuoden mukaan. Minulla ne järjestyy näin:

[pknuuti]

Kiitos Anneli. Tarkistin vastaavan haun tuloksissa muutaman nimekkeen tietoja ja kyllähän siellä oli vuosiluku monessakin ns. tyhjässä tietueessa, mutta vuosi oli hakasuluissa tai siinä oli kysymysmerkki tms. En tiedä, miksi esim. tuo Tuurin kirja on tuossa ensimmäisenä, siinä tieto on oikeassa muodossa, mutta vaikuttaako asiaan puuttuva indikaattori 260:ssa, en tiedä. Ainakin sama indikaattori puuttui myös tuosta Jouluaamun kissanpennusta ja muutakin tarkistamastani nimekkeestä. Eli ehkä nekin puutteet voivat vaikuttaa järjestykseen?

[AnneliO]

Nuo tiedot haetaan tietokannan taulusta, jonne indikaattoreita ei tallenneta, joten en usko ongelman johtuvan niistä.

[atarnus]

Ihan yksinkertaisimillaan tämä alkaa toimimaan omassa testiympäristössä sillä, että kommentoi pois seuraavat rivit itemsearch.pl -tiedostosta:

if (C4::Context->preference("marcflavour") ne "UNIMARC" && $field eq 'publicationyear') { $field = 'copyrightdate'; }

if (C4::Context->preference("marcflavour") ne "UNIMARC" && $sortby eq 'publicationyear') { $sortby = 'copyrightdate'; }

Tämän jälkeen taulukkoon pitäisi tulla pelkästään biblioitems.publicationyear, ja sitten järjestely toimii, ja niin myös filteröinti, joka ei ainakaan minulla myöskään toiminut ennen muutosta. Käytännössä sekä sorting että filtering näki nuo kaikki kentät tyhjinä, myös ne, joissa oli dataa.

Jos ihmetyttää miksi järjestys muuttui ekalla painalluksella, niin se johtuu siitä, että haun alussa nimeke-sarake on aakkostettuna, ja toisen sarakkeen painaminen vapauttaa tuon aakkostuksen.

[CodoDerDritte]

Jostain syystä siis tuossa käytetään MARC21:stä käytettäessä publicationyear sorttia pyydettäessä kuitenkin copyrightdatea, joka meillä on tyhjä, koska siihen ei ole mäpätty mitään. Olisikohan tämä viisainta nyt kuitenkin ratkaista niin että tuohon copyrightdate-kenttään mäpätään järjestystä varten tarvittavat MARC-kentät ja ajetaan batch rebuild biblio-tauluille? Silloin ei tarvitsisi tehdä Kohaan meidän ylläpidolle jäävää koodimuutosta. En kyllä ihan tavoita nyt logiikkaa tämän iffityksen taustalla. Siis miksi yhteisössä on haluttu tehdä tuo sorttaus tällä tavalla.

[AnneliO]

Pääkäyttäjäpalaveri 19.12.2023: Pääkäyttäjät lisäävät sekä testeille, tuotantoon että nexteille biblio.copyrightdate -kenttään samat mäppäykset kuin biblioitems.publicationyear eli 260$c ja 264$c.

Seuranta, ketkä ovat tehneet mäppäykset

• [x] Lappi
• [x] OUTI
• [x] Siilinjärvi
• [x] Vaara
• [x] Lumme
• [x] Kyyti
• [x] Helle
• [x] Kirkes
• [x] Vaski

Sen jälkeen joku kehittäjistä ajaa rebuildbiblio-ajon kimppoihin.

Seuranta rebuildbiblio-ajolle:

• [x] Lappi
• [x] OUTI
• [x] Siilinjärvi
• [x] Vaara
• [x] Lumme
• [x] Kyyti
• [x] Helle
• [x] Kirkes
• [x] Vaski

[AnneliO]

Huomio palaverista: Jos mäppäyksen tekee copyright-kenttään, poistuu se publicationyear-kentästä. Onko meillä käytetty publicationyear-kenttää jossain eli onko haittaa, jos kenttä tyhjenee?

[ajrajala]

Ainakin tallennetuissa raporteissa voi olla publicationyear-kenttä käytössä.

[velimarj]

Eli kannattaako tätä siis tehdä?

[AnneliO]

Koha-Suomi (Lari) selvittää vielä, missä kaikkialla tuota publicationyear-saraketta on käytetty ja aiheutuuko muutoksesta ongelmia.

[AnneliO]

Lari sai tutkimukset tehtyä ja ei havainnut mitään, mikä menisi rikki, jos mäppäysmuutos tehdään.

Ainoastaan biblioitems.publicationyear-kenttää käyttävät tallennetut raportit pitää korjata käyttämään biblio.copyrightdate-kenttää. Ne löytää helpoiten, kun menee tallennettuihin raportteihin ja kirjoittaa sanahaku-kenttään "publicationyear", jolloin hakutulokseksi saa kaikki raportit, jotka sisältävät kyseisen termin. Eli siis se kenttä, joka näkyy joko raporttien etusivulla tai tallennetuissa raporteissa vasemmalla Suodata-osiossa. Raporttitaulukon yläpuolella oleva Search-laatikko ei hae raporttien sisällöistä, joten sillä näitä ei saa kiinni. Raportteja näytti olevan 2-4 kpl/kimppa.

Sovitaan viikon 2 palaverissa, millä aikataululla asian kanssa edetään.

[AnneliO]

Pääkäyttäjien palaveri 9.1.2024: Tehdään rebuildbiblio-ajot kaksi kimppaa/yö ja lähdetään pohjoisesta etelään.

• 9.1.2024 Lappi ja OUTI
• 10.1.2024 Siili ja Vaara
• 11.1.2024 Lumme ja Kyyti
• 15.1.2024 Helle ja Kirkes
• 16.1.2024 Vaski

Pääkäyttäjät peukuttavat seurantakommenttia, kun omaan kimppaan on tehty tarvittava mäppäysmuutos. Ohje mäppäysmuutoksen tekoon.

• biblio.copyrightdate-sarakkeeseen mäpätään MARC-kentät 264c ja 260c

Lari ajelee rebuildbiblio-ajot sovittuina öinä ja kliksuttelee seurantakommenttiin, kun kimppa on valmistunut.

[lmstrand]

Outi keskeytyi eilen illalla, ajetaan uudelleen Vaskin jälkeen. Lappi ok. Ajot ajastettu alkamaan sovitusti kaikkiin loppuihin tuotantoihin.

[lmstrand]

Lumme-ajo on keskeytynyt: C4::Biblio::_koha_modify_biblioitem_nonmarc(): DBI Exception: DBD::mysql::st execute failed: Deadlock found when trying to get lock; try restarting transaction at /home/koha/Koha/misc/batchRebuildBiblioTables.pl line 71 Thu 11 Jan 2024 10:41:59 PM EET: End /home/koha/Koha/misc/batchRebuildBiblioTables.pl -c Thu 11 Jan 2024 10:41:59 PM EET: Runtime 0 hours, 41 minutes, 58 seconds

Ajetaan OUTIn kanssa uusiksi 17.1.

[lmstrand]

Ajettu batchRebuildBiblioTables.pl kaikille testeille, paitsi Vaski-test ja Täti-test.

[AnneliO]

Tajusin nyt käydä tekemässä mäppäysmuutoksen Tätiin ja Täti-testillekin.

[lmstrand]

Laitan tikettiin muistiin vielä outi-tuotannon ongelman:

1408700 records processed in 16702.46 seconds C4::Biblio::_koha_modify_biblioitem_nonmarc(): DBI Exception: DBD::mysql::st execute failed: Cannot add or update a child row: a foreign key constraint fails (outiprod.biblioitems, CONSTRAINT biblioitems_ibfk_1 FOREIGN KEY (biblionumber) REFERENCES biblio (biblionumber) ON DELETE CASCADE ON UPDATE CASCADE) at ./batchRebuildBiblioTables.pl line 71 [koha@outi-prod] last: 16706s ~/Koha/misc $ Connection to 10.0.2.151 closed by remote host.

[lmstrand]

Lumme ja OUTI ajettu onnistuneesti. OUTIssa valitti ajo, ettei pystynyt käsittelemään tietuetta 2308250.

[ajrajala]

Tehtyjen muutosten jälkeen julkaisuvuoden mukainen järjestäminen toimii nyt nidehaun tuloksissa oikein, suljen tiketin.