- Koha-devel - lists.koha-community.org

Replacing jQueryUI autocomplete
by Owen Leonard 12 Aug '21

12 Aug '21

We're making progress towards a replacement for the jQueryUI datepicker component: Bug 28376, "Replace obsolete jquery-ui-timepicker-addon" https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28376 I think it would be a good idea to look at replacing the rest of the jQueryUI components we use, since jQueryUI appears to be a dead project. I've been looking at this as a replacement for jQueryUI's autocomplete: https://tarekraafat.github.io/autoComplete.js/ It's small, seems fast, and has been around for several years, with its last release happening last month. I'm still testing whether it's missing any functionality we need, but I thought before I get too far I would ask: Does anyone have any experience with this project? Does anyone have any other autocomplete libraries they've used and would recommend? Thanks, Owen -- Web Developer Athens County Public Libraries (740) 737-6006 https://www.myacpl.org

2 1

Bug 17600 (Standardize the EXPORT) is pushed
by Jonathan Druart 11 Aug '21

11 Aug '21

Hi, I've just pushed bug 17600, it's a massive patch (1311 files changed, 4077 insertions(+), 4362 deletions(-)) that will cause conflicts with a lot of other patches in the queue. I've described in the commit message what it is doing, please read it. Most of the time the changes it brings are trivial but be careful when you resolve the conflicts. Ping me if you need help. Enjoy your weekend! Jonathan

3 3

Zebra Trivia
by dcook＠prosentient.com.au 11 Aug '21

11 Aug '21

Hi all, Today I learned (or maybe re-learned) something about Zebra CCL syntax: "Identifier-standard,phr" does not do a phrase search. It does a word list search. Now you might this this is impossible, but it's not, because Identifier-standard is hard-coded with 4=6 in ccl.properties: Identifier-standard 1=1007 4=6 Since Identifier-standard has already set the "4" structure attribute, "phr" does nothing. However, if you write "phr,Identifier-standard", it will do a phrase search. That's because the "phr" sets the "4" structure attribute before the "Identifier-standard" gets converted into PQF/RPN. Cool, n'est-ce pas? David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

2 2

Check of syspref editor with DB columns
by Fridolin SOMERS 11 Aug '21

11 Aug '21

Hi, Since 22844, preferences like BorrowerUnwantedField and BorrowerMandatoryField show a modal selection of DB columns. This relies on /koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/borrowers.json Unwanted fields are hidden in template using : [% UNLESS nofield %] Mandatory fields have attribute require in template using : [% IF mandatoryfield %] Big problem is how do we maintain this ??? For example I see in template memberentrygen.tt : [% UNLESS noautorenew_checkouts %] But this column is not in borrowers.json :( I'm made some checks : grep '% UNLESS no' koha-tmpl/intranet-tmpl/prog/en/modules/members/memberentrygen.tt | awk -F 'UNLESS ' '{print $2}' | tr -d '%]' | sort -u egrep 'mandatory\w' koha-tmpl/intranet-tmpl/prog/en/modules/members/memberentrygen.tt | awk -F 'mandatory' '{print $2}' | tr -d ' %])' | sort -u Plus some manual work. My conclusion : Are missing from borrowers.json (used by nofield and/or mandatoryfield) : - autorenew_checkouts - relationship - sms_provider_id - sort1 - sort2 Are useless in borrowers.json : - categorycode : obviously mandatory ? - smsalertnumber : in form the field is now SMSnumber, but no noSMSnumber/mandarorySMSnumber in template I will create a bug report for autorenew_checkouts first. Maybe we could add something in QA tools ? Best regards, PS : Also not very clear, BorrowerMandatoryField shows all fields but in template there is only : mandatoryborrowernotes mandatorycardnumber mandatorycontactfirstname mandatorycontactname mandatorydateenrolled mandatorydateexpiry mandatorydateofbirth mandatoryemail mandatoryemailpro mandatoryfax mandatoryfirstname mandatoryinitials mandatorymobile mandatoryopacnote mandatoryothernames mandatorypassword mandatoryphone mandatoryphonepro mandatoryprimary_contact_method mandatorysort1 mandatorysort2 mandatorysurname mandatorytitle mandatoryuserid mandatorypassword We should add other fields in exclusions ? -- Fridolin SOMERS <fridolin.somers(a)biblibre.com> Software and system maintainer 🦄 BibLibre, France

2 1

Koha packages are available 🎁
by Mason James 07 Aug '21

07 Aug '21

kia ora community, the latest Koha packages are available cheers, Mason

1 0

Advanced Editor for Authority Records
by dcook＠prosentient.com.au 04 Aug '21

04 Aug '21

Hi all, Does anyone know why the Advanced Editor in cataloguing is only for bibliographic records and not for authority records as well? Does anyone know if there is work to add an Advanced Editor for the authority records too? Thanks, David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

2 1

Koha Community Newsletter: Junly 2021
by Koha Newsletter 31 Jul '21

31 Jul '21

The Koha Community Newsletter for July 2021 is here: * https://koha-community.org/koha-community-newsletter-july-2021/ Many thanks to everyone who submitted articles and news to last month's newsletter! Please feel free to email me with any corrections or suggestions. -- Michael Kuhn Editor, Koha Community Newsletter

1 0

mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation' when trying to dump tablespaces
by dcook＠prosentient.com.au 30 Jul '21

30 Jul '21

Hi all (especially Jonathan), I was looking at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23329#c85 where Jonathan points out under MySQL 8 that we’re now getting this error with dumping the database: “mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation' when trying to dump tablespaces” I’ve seen this pop a few times myself on Koha projects, and it looks like it traces back to the security notes listed here: https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-31.html “Incompatible Change: Access to the INFORMATION_SCHEMA.FILES table now requires the PROCESS privilege.” “This change affects users of the mysqldump command, which accesses tablespace information in the FILES table, and thus now requires the PROCESS privilege as well. Users who do not need to dump tablespace information can work around this requirement by invoking mysqldump with the --no-tablespaces option. (Bug #30350829)” I haven’t looked into it too deeply yet, but I imagine adding the --no-tablespaces option to mysqldump in koha-dump is the way to go. (I would’ve commented on Bugzilla but every time I try it keep blocking me and kicking me out.) David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

1 0

International Confrence KohaCon 2021
by FullStack Solutions 28 Jul '21

28 Jul '21

Dear All, Hopefully you all will be fine and good health. I am pleased to inform you that the International Confrence Kohacon2021 website is up Now. Kindly visit for further details I.e. Registration, proposal submissions, date of Confrence and others. Regards Sher Afzal Khan President Koha Pakistan Country Ambassador DSpace Sent from my iPhone > On 26-Jul-2021, at 3:00 PM, koha-devel-request(a)lists.koha-community.org wrote: > > Send Koha-devel mailing list submissions to > koha-devel(a)lists.koha-community.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > or, via email, send a message with subject or body 'help' to > koha-devel-request(a)lists.koha-community.org > > You can reach the person managing the list at > koha-devel-owner(a)lists.koha-community.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Koha-devel digest..." > > > Today's Topics: > > 1. Re: Update from Koha 19.11 to 21.05 terminating because "Row > size too large" (Katrin Fischer) > 2. Re: Update from Koha 19.11 to 21.05 terminating because "Row > size too large" (Michael Kuhn) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 25 Jul 2021 12:31:51 +0200 > From: Katrin Fischer <katrin.fischer.83(a)web.de> > To: koha-devel(a)lists.koha-community.org > Subject: Re: [Koha-devel] Update from Koha 19.11 to 21.05 terminating > because "Row size too large" > Message-ID: <2bc7f482-ecef-ff7f-6b88-284ae283b715(a)web.de> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hi Michael, > > I found another bug about the row size issue: > > *Bug 28267* > <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28267> - > Koha-common package upgrade problem from 20.05.xx to 20.11.04-1 > > I think filing a bug is always a good first step as we seem to run into > this issue more and more. > > Katrin > >> On 12.07.21 21:29, Michael Kuhn wrote: >> Hi >> >> Today I updated our host from Debian GNU/Linux 9 with Koha 19.11.00 >> first to Debian GNU/Linux 10, then to Koha 21.05.01. When running >> "apt-get install koha-common" the process terminated showing the >> following messages: >> >> ### BEGIN ######################### >> >> Upgrade to 19.12.00.052 done [18:30:04]: Bug 21443 - Add ability to >> exclude holidays when calculating rentals fees by time period >> {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: Row size too >> large. The maximum row size for the used table type, not counting >> BLOBs, is 8126. This includes storage overhead, check the manual. You >> have to change some columns to TEXT or BLOBs [for Statement "ALTER >> TABLE borrowers ADD COLUMN autorenew_checkouts TINYINT(1) NOT NULL >> DEFAULT 1 AFTER anonymized"] at /usr/share/perl5/DBIx/Class/Schema.pm >> line 1118. >> DBIx::Class::Schema::throw_exception(Koha::Schema=HASH(0x30abec0), >> "DBI Exception: DBD::mysql::db do failed: Row size too large. "...) >> called at /usr/share/perl5/DBIx/Class/Storage.pm line 113 >> DBIx::Class::Storage::throw_exception(DBIx::Class::Storage::DBI::mysql=HASH(0x3aa549c), >> "DBI Exception: DBD::mysql::db do failed: Row size too large. "...) >> called at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1501 >> DBIx::Class::Storage::DBI::__ANON__("DBD::mysql::db do failed: Row >> size too large. The maximum row"..., DBI::db=HASH(0x3ee6314), undef) >> called at >> /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase.pl >> line 21313 >> >> dpkg: error processing package koha-common (--configure): >> installed koha-common package post-installation script subprocess >> returned error exit status 11 >> Processing triggers for systemd (241-7~deb10u7) ... >> Errors were encountered while processing: >> koha-common >> E: Sub-process /usr/bin/dpkg returned an error code (1) >> Script done, file is /tmp/apt-get_install_koha-common_20210712.txt >> >> ### END ######################### >> >> This looks a lot like >> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24986 >> (Maximum row size reached soon for borrowers and deletedborrowers) or >> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28267 >> (Koha-common package upgrade problem from 20.05.xx to 20.11.04-1) but >> it's not exactly the same. >> >> According to >> https://mariadb.com/kb/en/troubleshooting-row-size-too-large-errors-with-in… >> I ran the described script "rowsize.sh" which showed me the following >> 7 tables with row size too large. >> >> aqbooksellers >> biblioitems >> borrower_modifications >> borrowers >> deletedbiblioitems >> deletedborrowers >> z3950servers >> >> One solution seems to be to alter the row format of these tables from >> "Compact" to "Dynamic" so I did that for all seven tables. >> >> ALTER TABLE aqbooksellers ROW_FORMAT=DYNAMIC; >> etc >> >> After running "apt-get install koha-common" again, the process >> continued with >> >> Upgrade to 19.12.00.053 done [19:19:28]: Bug 24476 - Allow patrons to >> opt-out of autorenewal >> >> and ran to the end. >> >> Upgrade to 21.05.01.003 done [19:19:38]: Koha 21.05.01 release >> Error: the selected language is already installed. Try --update if >> you want to re-install it. >> ERROR: an error was found when updating 'de-DE' translations. Please >> manually >> run 'koha-translate --update de-DE'. Run man koha-translate for more >> options. >> >> Except of the error regarding the "selected language" which I have >> described in another e-mail to koha-devel, everything seems to work fine. >> >> Still I'm asking myself if I should open another bug report about "Row >> size too large" since the problem does not to be solved by Bug 24986 >> ("Pushed to master for 20.11") or the pending Bug 28267. >> >> Also I'm not sure what consequences the changed row format "Dynamic" >> for these 7 tables might have. >> >> Best wishes: Michael >> -- >> Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis >> Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz >> T 0041 (0)61 261 55 61 · E mik(a)adminkuhn.ch · W www.adminkuhn.ch >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel(a)lists.koha-community.org >> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : https://www.koha-community.org/ >> git : https://git.koha-community.org/ >> bugs : https://bugs.koha-community.org/ >

1 0

Update from Koha 19.11 to 21.05 terminating because "Row size too large"
by Michael Kuhn 25 Jul '21

25 Jul '21

Hi Today I updated our host from Debian GNU/Linux 9 with Koha 19.11.00 first to Debian GNU/Linux 10, then to Koha 21.05.01. When running "apt-get install koha-common" the process terminated showing the following messages: ### BEGIN ######################### Upgrade to 19.12.00.052 done [18:30:04]: Bug 21443 - Add ability to exclude holidays when calculating rentals fees by time period {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs [for Statement "ALTER TABLE borrowers ADD COLUMN autorenew_checkouts TINYINT(1) NOT NULL DEFAULT 1 AFTER anonymized"] at /usr/share/perl5/DBIx/Class/Schema.pm line 1118. DBIx::Class::Schema::throw_exception(Koha::Schema=HASH(0x30abec0), "DBI Exception: DBD::mysql::db do failed: Row size too large. "...) called at /usr/share/perl5/DBIx/Class/Storage.pm line 113 DBIx::Class::Storage::throw_exception(DBIx::Class::Storage::DBI::mysql=HASH(0x3aa549c), "DBI Exception: DBD::mysql::db do failed: Row size too large. "...) called at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1501 DBIx::Class::Storage::DBI::__ANON__("DBD::mysql::db do failed: Row size too large. The maximum row"..., DBI::db=HASH(0x3ee6314), undef) called at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase.pl line 21313 dpkg: error processing package koha-common (--configure): installed koha-common package post-installation script subprocess returned error exit status 11 Processing triggers for systemd (241-7~deb10u7) ... Errors were encountered while processing: koha-common E: Sub-process /usr/bin/dpkg returned an error code (1) Script done, file is /tmp/apt-get_install_koha-common_20210712.txt ### END ######################### This looks a lot like https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24986 (Maximum row size reached soon for borrowers and deletedborrowers) or https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28267 (Koha-common package upgrade problem from 20.05.xx to 20.11.04-1) but it's not exactly the same. According to https://mariadb.com/kb/en/troubleshooting-row-size-too-large-errors-with-in… I ran the described script "rowsize.sh" which showed me the following 7 tables with row size too large. aqbooksellers biblioitems borrower_modifications borrowers deletedbiblioitems deletedborrowers z3950servers One solution seems to be to alter the row format of these tables from "Compact" to "Dynamic" so I did that for all seven tables. ALTER TABLE aqbooksellers ROW_FORMAT=DYNAMIC; etc After running "apt-get install koha-common" again, the process continued with Upgrade to 19.12.00.053 done [19:19:28]: Bug 24476 - Allow patrons to opt-out of autorenewal and ran to the end. Upgrade to 21.05.01.003 done [19:19:38]: Koha 21.05.01 release Error: the selected language is already installed. Try --update if you want to re-install it. ERROR: an error was found when updating 'de-DE' translations. Please manually run 'koha-translate --update de-DE'. Run man koha-translate for more options. Except of the error regarding the "selected language" which I have described in another e-mail to koha-devel, everything seems to work fine. Still I'm asking myself if I should open another bug report about "Row size too large" since the problem does not to be solved by Bug 24986 ("Pushed to master for 20.11") or the pending Bug 28267. Also I'm not sure what consequences the changed row format "Dynamic" for these 7 tables might have. Best wishes: Michael -- Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz T 0041 (0)61 261 55 61 · E mik(a)adminkuhn.ch · W www.adminkuhn.ch

2 2