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

Immediate logout in Koha 21.05.02 (03?)
by Michael Kuhn 08 Sep '21

08 Sep '21

Hi As written on this list on 26 August I tried to install Koha 21.05.03 but after the installation Koha said the installed version was "21.05.02.003". Jonathan Druart wrote this comes from commit 8ea80995c590dad86c43df636456640d3aa84bab Increment version for 21.05.03 release -$VERSION = "21.05.02.002"; +$VERSION = "21.05.02.003"; Today I updated a Koha 18.11.05 database into this Koha 21.05.02.003 installation. After restarting memcached I executed "sudo koha-upgrade-schema instancename" - the output looked OK and ended with the following lines: Upgrade to 21.05.02.000 done [12:15:20]: Koha 21.05.02 release Upgrade to 21.05.02.001 done [12:15:20]: Bug 28567 - Set to NULL empty branches fields Upgrade to 21.05.02.002 done [12:15:20]: Bug 28813 - Update delivery_note to failure_code in message_queue Upgrade to 21.05.02.003 done [12:15:20]: Bug 28872 - Update syspref values from on and off to 1 and 0 It seems even if I installed Koha 21.05.03 it only upgraded to Koha 21.05.02. I don't know if there is any connection but whatever, I was able to open the staff client and to login - but as soon as I click on any link I'm logged out immediately. I am able to login again and then advance to the next link but then I'm logged out again etc ad infinitum. It is not possible to change any system preference (internal server error) or search for any users. File "plack-error.log" sometimes tells me, without a timestamp: new(): failed: query object HASH(0x555f47cfad30) does not support cookie() and param() methods: Can't call method "cookie" on unblessed reference at /usr/share/perl5/CGI/Session.pm line 707. File "plack-intranet-error.log" says: [2021/09/02 13:33:36] [WARN] Odd number of elements in anonymous hash at /usr/share/koha/intranet/cgi-bin/catalogue/search.pl line 577. Can anyone please give me a hint how to solve this problem? 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

4 6

REST API + DataTables
by dcook＠prosentient.com.au 07 Sep '21

07 Sep '21

Thanks, Mark. That would be great! 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 -----Original Message----- From: Koha-devel <koha-devel-bounces(a)lists.koha-community.org> On Behalf Of Mark Hofstetter Sent: Monday, 6 September 2021 9:32 PM To: koha-devel(a)lists.koha-community.org; koha-devel-request(a)lists.koha-community.org Subject: Re: [Koha-devel] Koha-devel Digest, Vol 190, Issue 4 REST API + DataTables Hi, I've written some plugins that work with datatables which seems quite straightforward to me the plugins are too specific to use widely but I would be happy to share the code anyway! regards Mark _______________________________________________ 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

Re: [Koha-devel] Koha-devel Digest, Vol 190, Issue 4 REST API + DataTables
by Mark Hofstetter 06 Sep '21

06 Sep '21

Hi, I've written some plugins that work with datatables which seems quite straightforward to me the plugins are too specific to use widely but I would be happy to share the code anyway! regards Mark

1 0

REST API + DataTables
by dcook＠prosentient.com.au 03 Sep '21

03 Sep '21

Hi all, Do we have any examples of using the Mojolicious REST API to provide data for DataTables in Koha? I think the answer is probably no since the DataTables calls aren't really RESTful. Yet, we have this growing API, and we want to use that API to make more efficient user interfaces. Does anyone know how we might do that with DataTables? On a different project, I ended up writing a specific controller just for handling DataTables AJAX calls since they're very particular. But even that's easier said than done in a generic way because of business rules and authorization. Thoughts? 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

Fwd: Critical security bug in Koha!
by Paul Poulain 02 Sep '21

02 Sep '21

Je vous fais suivre ce mail de joubu, si qqn peut se pencher dessus et contribuer à le résoudre... (me tenir au courant svp) A+ -------- Message transféré -------- Sujet : Critical security bug in Koha! Date : Wed, 1 Sep 2021 11:34:23 +0200 De : Jonathan Druart <jonathan.druart(a)gmail.com> Pour : Martin Renvoize <martin.renvoize(a)ptfs-europe.com>, Paul Poulain <paul.poulain(a)biblibre.com>, Nick Clemens <nick(a)bywatersolutions.com>, Tomas Cohen Arazi <tomascohen(a)gmail.com>, David Cook <dcook(a)prosentient.com.au>, Philippe Blouin <philippe.blouin(a)inlibro.com>, Marcel de Rooy <M.de.Rooy(a)rijksmuseum.nl>, Andrii Vashchuk <nugged(a)gmail.com>, Katrin Fischer <Katrin.Fischer.83(a)web.de>, Chris Cormack <chris(a)bigballofwax.co.nz>, Galen Charlton <gmcharlt(a)gmail.com>, Mason James <mtj(a)kohaaloha.com>, Owen Leonard <oleonard(a)myacpl.org> Hello everybody, If you get this email I am expecting from you to talk about it to whom could be concerned. Yesterday a bug (28929) was reported about a possible privilege escalation. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28929 It is confirmed and is highlighly critical in some cases, and stay critical in all other cases. It's really bad. Basically we are missing filtering on patron's data when we create or edit a patron. Which means a user can edit whichever info they want, by modifying the DOM of the page. And, it includes borrowers.flags (that's where it hurts really badly). It impacts both OPAC and Staff interfaces. What you should do: 1. Reduce the risks! * Disable PatronSelfRegistration (!) * Disable AutoApprovePatronProfileSettings (!) or you can totally disable OPACPatronDetails 2. Make sure the staff interface is not accessible to the world 3. Remove old librarian accounts 4. Something else you have in mind? If so, please share! Then you should (or ask your team to) help us. We will need people on the bug to: 1. Write patches and discuss the best approach to fix the different issues (there are patches already) 2. Test! and test! We will have to test on five different versions (master+4 stables)! 3. QA, and *really* review, all the different versions (we really want to prevent a mess publishing a fix that will introduce regressions). We will then need to coordinate. A plan (to discuss) could be: 1. Tell the big actors to be ready for an urgent release (This is the goal of this email!) 2. Make the patches ready for the different versions (see the above) 3. Have all the packages ready, before we communicate publicly (Mason, will you be available?) 4. Tell the people we know to upgrade (so, you, and those who are aware of the problem) 5. Announce publicly What do you think? This info should not be public, but please communicate as much as you can around you (people you trust of course). No need to over communicate either, as we are not ready yet! If you don't have access to the bug, just tell me (or Tomas, Katrin, Martin, Nick, etc.) Cheers, Jonathan -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries

1 1

Perl advice for checking hash content
by Victor Grousset/tuxayo 30 Aug '21

30 Aug '21

Hi :) For a development, I'm adding additional keys to C4::Reserves::CanItemBeReserved returned hash. But there are a bunch of tests that match the whole return value and thus don't expect the new keys in the hash. Here is the best way so far I've found to adapt it. is_deeply( CanItemBeReserved( $patron->borrowernumber, $itemnumber_2 ), { status => 'tooManyReservesToday', limit => 0 }, 'Patron cannot reserve if holds_per_day is 0 (i.e. 0 is 0)' ); ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ my @status_and_limit = @{CanItemBeReserved( $patron->borrowernumber, $itemnumber_2 )}{"status", "limit"}; is_deeply( \@status_and_limit, ['tooManyReservesToday', 0], 'Patron cannot reserve if holds_per_day is 0 (i.e. 0 is 0)' ); How could this be better? Since it took me more than two hours only to have something that works and without warnings. There are surely other ways to do it™, and hopefully a nicer one. Most of the time was reading and learning by trial and error about referencing and dereferencing and the specifics or Perl hashes and array. It's odd to have been working 3.5 years on Koha closer to the code than to the librarian stuff and only have to really start learning Perl now ^^ Away, this is why advice is needed to have something that fit the good practices :) Key/Value Hash Slices would allow to not change the expected param of is_deeply() but that doesn't really look different for the readability. And isn't worth having Koha bump minimal Perl version from 5.14 (2011) to 5.20 (2014). Ok it's just for running the tests and not production but still. -> very minor or inexistent readability improvement. https://perldoc.perl.org/perldata#Key/Value-Hash-Slices Having two assertions (is() calls) for status and limit would allow a simpler syntax but add duplication. Cheers, -- Victor Grousset/tuxayo

2 2

Koha Community Newsletter: August 2021
by Koha Newsletter 27 Aug '21

27 Aug '21

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

1 0

Installing Koha 21.05.03-1 but Koha gives 21.05.02.003 as the installed version
by Michael Kuhn 26 Aug '21

26 Aug '21

Hi Yesterday/today I was installing the most current Koha: $ sudo apt-cache show koha-common | grep Version Version: 21.05.03-1 During the installation of Debian package "koha-common" it says: Holen:62 http://debian.koha-community.org/koha 21.05/main amd64 koha-common all 21.05.03-1 [41,1 MB] ... Vorbereitung zum Entpacken von .../485-koha-common_21.05.03-1_all.deb ... Entpacken von koha-common (21.05.03-1) ... ... koha-common (21.05.03-1) wird eingerichtet ... But after the installation I see the following in Koha menu "About Koha": Koha version: 21.05.02.003 Also in the source text of the OPAC main page it says: <meta name="generator" content="Koha 21.0502003" /> This happened on a completely new machine with Debian GNU Linux 11.0. 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 1

Character sets in MariaDB 10.5
by Michael Kuhn 26 Aug '21

26 Aug '21

Hi 1. In the last few years when installing Koha on Debian GNU/Linux 9 or 10 the character sets in MariaDB were as follows: MariaDB [(none)]> SHOW VARIABLES LIKE '%char%'; +--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+----------------------------+ | character_set_client | utf8mb4 | | character_set_connection | utf8mb4 | | character_set_database | utf8mb4 | | character_set_filesystem | binary | | character_set_results | utf8mb4 | | character_set_server | utf8mb4 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | +--------------------------+----------------------------+ Today I installed Koha 21.05.03 on Debian GNU/Linux 11 with MariaDB 10.5.11 where the character sets are as follows: MariaDB [(none)]> SHOW VARIABLES LIKE '%char%'; +--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+----------------------------+ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | utf8mb4 | | character_set_filesystem | binary | | character_set_results | utf8 | | character_set_server | utf8mb4 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | +--------------------------+----------------------------+ I'm not sure what is going on here. Does anyone know why the character sets for client, connection and results have changed from utf8mb4 to utf8? Is this correct with Koha or should these character sets be changed? 2. Today I came upon an installation of Koha 18.11.05 using MariaDB 10.0.32 which has the following character sets: MariaDB [(none)]> SHOW VARIABLES LIKE '%char%'; +--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+----------------------------+ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | latin1 | | character_set_filesystem | binary | | character_set_results | utf8 | | character_set_server | latin1 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | +--------------------------+----------------------------+ This seems quite wrong to me - as far as I know "latin1" was never a supported character set in Koha... as far as I know the character sets should be set as shown in topic 1. However, is it still possible to update such a database with these character sets to Koha 21.05.03 without destroying the data completely? 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

Koha 19.11.21 released
by Wainui Witika-Park 26 Aug '21

26 Aug '21

Hello everyone! The Koha community is proud to announce the release of version 19.11.21. The full release notes can be found at: https://koha-community.org/koha-19-11-21-released/ Thank you to everyone involved! Cheers, Wainui Witika-Park (she/her)

1 0