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

Should we support MySQL? (either 5.7 or 8.0)
by Victor Grousset/tuxayo 12 Oct '22

12 Oct '22

Hi :) The CI only tests MySQL 8 on main/master but it passes. Maybe we dropped strong support for MySQL years ago? And only kept MySQL 8 on master to catch the strict SQL mode issues? Because that's mostly how I hears about MySQL lately. (strict SQL mode) And I heard MySQL 5.7 still has the db increment issue so we likely don't want to support it. Cheers, -- Victor Grousset/tuxayo

1 0

enable automatic filesystem refresh in Plack - KTD
by Mason James 11 Oct '22

11 Oct '22

hi folks i recently added this feature to KTD - just master* images, for now it seems to be behaving itself; but pleeese comment in bug 31729, if you see a problem

1 0

Hiding records/items in OAI-PMH output
by David Cook 10 Oct '22

10 Oct '22

Hi Ere, There's been some discussion on Bug 31161 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31161 about hiding records/items in OAI-PMH output, and I was keen to get your thoughts. I've had a few different ideas over time, but right now I'm thinking that the best way to deal with hiding bib records is to mark them as "deleted" in the OAI-PMH feed. Firstly, it would be a very easy change to make, which would probably not affect performance much at all. Secondly, it would allow records that have been hidden to be removed from downstream systems automatically via OAI-PMH harvesters that support deletions. Since it's a small code change, I'm tempted to trial it locally using the OAI Config file to turn on this hiding mechanism. Since you're the person who has done the most work on the OAI-PMH server recently, I figured you'd be a good person to ask for feedback! 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

Re: [Koha-devel] Required Mojolicious versions in Koha
by David Cook 10 Oct '22

10 Oct '22

Thanks, guys. That was very helpful : ). When I work on customizing 22.11 in the new year, I’ll have a play with “skip_validating_specification” and let everyone know how it goes. 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 From: Tomas Cohen Arazi <tomascohen(a)theke.io> Sent: Thursday, 6 October 2022 11:40 AM To: Mason James <mtj(a)kohaaloha.com> Cc: David Cook <dcook(a)prosentient.com.au>; koha-devel <koha-devel(a)lists.koha-community.org>; Martin Renvoize <martin.renvoize(a)ptfs-europe.com> Subject: Re: Required Mojolicious versions in Koha You mean Mojolicious::Plugin::OpenAPI, right? The relevant pieces are - Mojolicious - JSON::Validator - Mojolicious::Plugin::OpenAPI on 22.05+ we jumped to the latest versions of the latter, shifting the Mojolicious version to achieve it, as well. Hope it clarified. BTW, we can now migrate the spec to OpenAPI V3 and take advantage of things like 'nullable' and inheritance to be more compliant. Best regards El mié, 5 oct 2022 20:39, Mason James <mtj(a)kohaaloha.com <mailto:mtj@kohaaloha.com> > escribió: On 6/10/22 12:31 pm, Mason James wrote: > > On 5/10/22 2:23 pm, David Cook wrote: >> >> Hi all, >> >> I’m trying to figure out what versions of Mojolicious and Mojolicious::Plugin::OpenAPI are really required for Koha as I’d like to start using the “skip_validating_specification” feature in Mojolicious::Plugin::OpenAPI which is available from version 4.0.3 onwards. >> > > as i understand: > koha 22.05 runs on openapi 2 > koha 22.11 runs on openapi 3+ > > more info on section 1.4 below.... > https://wiki.koha-community.org/wiki/REST_API_Debug > oops, typo :) koha 21.11 runs on openapi 2 koha 22.05 runs on openapi 3+

1 0

an SMS Send issue - wondering if it is possible to do with Koha
by Indranil Das Gupta 06 Oct '22

06 Oct '22

Hi all, I've written a new SMS::Send driver module for NIC SMS service (a federal IT service provider to Govt agencies in India). It's working fine on its own. India's current anti-spam rules demands that every message template (e.g. "Dear member {#var#} you have checked out {#var#}") must have to its unique 19 digit identifier mapped against the designated sender (e.g. the library) in the federal blockchain system for SMS https://smsgw.sms.gov.in/failsafe/HttpLink?username=xxxx&pin=xxxxx&message=… is a test message&mnumber=91XXXXXXXXXX&signature=sender_id&dlt_entity_id=xxxxxxx&dlt_template_id=xxxxxxx That last part - dlt_template_id will be different for each message template mapped against a specific dlt_entity_id. The sender_id and dlt_entity_id is easily taken care of via yaml (bug 13029). I can map the letter_code against dlt_template_id using the yaml, but is there a way by which I can push it to SMS.pm? thanks in advance. -- Indranil Das Gupta L2C2 Technologies Phone : +91-98300-20971 WWW : http://www.l2c2.co.in Blog : http://blog.l2c2.co.in IRC : indradg on irc://irc.freenode.net Twitter : indradg

2 2

Required Mojolicious versions in Koha
by David Cook 06 Oct '22

06 Oct '22

Hi all, I'm trying to figure out what versions of Mojolicious and Mojolicious::Plugin::OpenAPI are really required for Koha as I'd like to start using the "skip_validating_specification" feature in Mojolicious::Plugin::OpenAPI which is available from version 4.0.3 onwards. I notice cpanfile on master says: requires 'Mojolicious', '8.12'; requires 'Mojolicious::Plugin::OpenAPI', '2.16'; debian/control on master says: libmojolicious-perl (>= 6.0), libmojolicious-plugin-openapi-perl, koha-testing-docker w/ Debian 11 Bullseye has: ii libmojolicious-perl 9.90+really9.22-koha1 all simple, yet powerful, Web Application Framework ii libmojolicious-plugin-openapi-perl 5.99+really5.05-koha1 all OpenAPI / Swagger plugin for Mojolicious Looking around on https://debian.koha-community.org/koha/pool/main/libm/libmojolicious-plugin- openapi-perl/ it looks like the 5.05 libmojolicious-plugin-openapi-perl isn't used in stable. but I'm guessing it will be used in 22.11? 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 packages are available 🎁
by Mason James 05 Oct '22

05 Oct '22

kia ora community, the latest Koha packages are available an installation guide is below... https://wiki.koha-community.org/wiki/Koha_on_Debian cheers, Mason

1 0

Excess fields in Koha 22.05 file "patron_import.csv"
by Michael Kuhn 30 Sep '22

30 Sep '22

Hi When unloading the field names of Koha 22.05 table "borrowers" I get 79 field names (plus "borrowernumber"). But when in Koha 22.05 menu "Tools > Import patrons" I click the link "Starter CSV file" the unloaded file "patron_import.csv" does include 82 fields. When comparing the two outputs I see there are three more fields in file "patron_import.csv" than in table "borrowers": patron_attributes guarantor_relationship guarantor_id These three fields aren't included in https://schema.koha-community.org/22_05/tables/borrowers.html What is the explanation for these excess fields? 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

Merging authority records can corrupt data
by Thomas Klausner 30 Sep '22

30 Sep '22

Hi! It seems that merging authorities with lots of linked biblios can lead to data corruption (at least in 21.05): The merging of the auth record itself seems to work, but the linking of the biblios from old to new auth record happens inside a normal synchrone web request. If this requests times out (because there might be a lot of biblio records to relink), some of the biblios still point to the old auth, which is already deleted. (At least this seems to be happening, based on the complaints we got from librarians) I guess the only fix is to handle authority merging via background jobs / job queue. Is this a known bug? I couldn't find anything about that in bugzilla? If yes, is there a timeframe when it will be fixed? If no, I will create a bug (though reproducing it will need some weird fixtures in the DB..). In any case, the Steiermärkische Landesbibliothek is keen to get this working, so I could give fixing it a try. But this will need some discussion, I assume? As I suppose this will be a bit more work than a single-line fix in a template, I'd like to have some backing by other Koha-devs, that this behaviour is indeed a bug, and that using background jobs is the correct way to fix it. Greetings, domm -- #!/usr/bin/perl https://domm.plix.at for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

2 2

koha-create with remote mariadb server
by David Schmidt 30 Sep '22

30 Sep '22

im trying to create a koha instance configured for a remote mariadb server https://wiki.koha-community.org/wiki/Debian#Create_a_Koha_instance > remove /etc/mysql/koha-common.cnf > create a new file in its place containing the connection information for the server, in the form of a my.cnf file. what does that mean? the only my.cnf file that I can find on the system is /etc/mysql/my.cnf and that doesnt look right $ koha-create --dbhost 172.23.0.3 --database kohadb --request-db koha-demo $ vim koha-demo-db-request.txt $ koha-create --dbhost 172.23.0.3 --database kohadb --populate-db koha-demo Koha instance is empty, no staff user created. after that I still see the autogenerated password in /etc/koha/sites/koha-demo/koha-conf.xml and the mariadb database is empty after reading the koha-create source i have a feeling this --request-db/--populate-db stuff cant possibly work. --populate-db is trying to get the db passwort using getinstancemysqluser() but that function is a wrapper around xmlstarlet and i was just told by `koha-create --request-db` to write the new db password into this txt file. I will update the wiki after I figured this out cheers david

1 1