August 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

Built-in offline circulation interface
by Owen Leonard 19 Oct '21

19 Oct '21

Does anyone use it? The one enabled by the AllowOfflineCirculation system preference. I don't think the core functionality of the feature has been touched since its original introduction and I'm concerned that it either doesn't work or is too fragile to be used in production. I'm not asking because I'm thinking of using it but because I'm concerned about us promising users that it works. Thanks, Owen -- Web Developer Athens County Public Libraries (740) 737-6006 https://www.myacpl.org

6 9

Listing Zebra (and Elasticsearch) indexes for end-users' benefit
by dcook＠prosentient.com.au 09 Sep '21

09 Sep '21

Hi all, As always, a new day brings a new Zebra idea. One of my librarians asked me if there was any way to get a list of Zebra indexes (particularly for Record Matching Rules), and I was all prepared to say no. when I remembered something I read the other day. It turns out you can send the query "@attr exp1 1=1 attributedetails" to the magical database "IR-explain-1", and it will give you a list of all the indexes in that database along with the type of index and how many documents are indexed against that index in the database. I think this is something that we should add to Koha! I'm not familiar with Koha's use of Elasticsearch, but I imagine there is an easy way of getting a list of Elasticsearch indexes? -- Of course, while having a list of indexes is good, it would be nice to know what MARC data is in each of those indexes. I'm thinking about creating a Koha Plugin that parses "biblio-koha-indexdefs.xml" and shows a user-friendly view of what parts of the MARC record are put into which indexes. -- What do folk think about that? I think having a list of Zebra indexes would be very useful for Record Matching Rules, but also for a "Search tips" guide for the Staff Interface and OPAC. While we could provide a static list of indexes, but I think that would be too much of a maintenance burden. I think having a list from Zebra (or Elasticsearch), which we could cache in Memcached, would be the way to go. Ideally, we could have an API route that surfaces this information, so that we could just do an AJAX lookup from a web interface. -- I'm hoping my librarian will sponsor development of a plugin, but I think this would be useful in the core Koha code. 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

3 5

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