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

How to make self-referential URLs in Koha
by dcook＠prosentient.com.au 30 Jan '23

30 Jan '23

Hi all, With some recent code, I've been using creating self-referential URL in Koha using CGI->url(), and passing it as a value. With CGI, the URL is correct (ie starting with /cgi-bin/koha). With Plack, it's not, because the OPAC is mounted as "/opac". I worked around this by rewriting the self-referential URL in my code, but I was wondering if anyone else had any thoughts on this. I've noticed there are a few places in Koha where we use CGI->url() and I'm guessing we may have unexpected bugs in Plack-enabled Koha as a result. Of course, one workaround would be to have /opac and /intranet aliases or URL rewriting in Apache, so that the self-referential URLs created by Plack still end up resolving. I wonder if that's the easiest path forward. In the past, I have wondered if we could get rid of "/cgi-bin/koha" as a path prefix all together (especially as cgi-bin scares security tools), but it's so deeply embedded in Koha at this point that it seems a huge task to replace it. Anyway, just throwing that out there. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595

6 8

String Freeze Notice
by Joy Nelson 12 Aug '22

12 Aug '22

Greetings! Just a quick note that string freeze will go into effect at the end of day 12/16/2019 for the maintenance branches. Maintenance releases scheduled for the 23rd. Translations can begin on the 17th. Thanks! -- Joy Nelson President, Koha Division ByWater Solutions <http://bywatersolutions.com> Support and Consulting for Open Source Software Phone/Fax (888)900-8944 What is Koha? <http://bywatersolutions.com/what-is-koha/>

3 3

Embed see-from headings (authorities) into bibliographic records at OAI repository level
by Julien Sicot 27 Jun '22

27 Jun '22

Hi all, An enhancement idea : It could be interesting to enrich the bibliographic records exposed in OAI with see-from headings, this would allow users who use koha with a discovery tool to be able to manage, normalize and index some authorities data ? This is something that could be done directly in C4::Biblio::GetMarcBiblio following the same method used for embedding items. We could use an optional parameter like embed_items (embed_seefromheading) and a function similar to C4::Biblio::EmbedItemsInMarcBiblio by reusing what was made for zebra with EmbedSeeFromHeadings (bug #7417 <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7417>). What do you think about this? Thanks for feedback, Best -- Julien Sicot Systems Librarian Université Rennes 2 02 22 51 44 41

4 4

Replacement of mailman (mailing lists)
by Jonathan Druart 02 Nov '21

02 Nov '21

Hi devs, Should we keep the historical mailing list or move to something modern, like discourse or flarum? Is it something: - we really want/need - we don't want/need - neat we could have Currently the lists are not maintained (messages are not reviewed/no moderation), the mailman version is old, looks like there are a lot of email bounding, etc. Asking for koha-devel first. Cheers, Jonathan

9 12

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

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