From katrin.fischer at bsz-bw.de Thu Feb 1 14:28:13 2024 From: katrin.fischer at bsz-bw.de (Fischer, Katrin) Date: Thu, 1 Feb 2024 14:28:13 +0100 Subject: [Koha-devel] Temporary halt on pushing patches Message-ID: <01de01da5512$81adbc30$85093490$@bsz-bw.de> Hi all, just letting you know that we are temporarily halting pushes to our main/master branch while we finish a big global change that touches a lot of files. Rebasing it constantly would take away from the resources we need to finish this properly. I will keep you updated. Thank you for your patience! Katrin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7253 bytes Desc: not available URL: From dcook at prosentient.com.au Fri Feb 2 06:24:35 2024 From: dcook at prosentient.com.au (David Cook) Date: Fri, 2 Feb 2024 16:24:35 +1100 Subject: [Koha-devel] January point releases Message-ID: <0b3201da5598$1c2aae00$54800a00$@prosentient.com.au> Hi all, I think the January point releases have been done. Just curious when we'll see those flow through to the main repository? 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fridolin.somers at biblibre.com Fri Feb 2 10:49:10 2024 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Fri, 2 Feb 2024 10:49:10 +0100 Subject: [Koha-devel] Koha January release with security fixes Message-ID: <58cf899c-99ca-49ff-a1b3-467e4d082f55@biblibre.com> Hello everyone 🤗 The Koha community is proud to announce the release of January version : 23.11.02 23.05.08 22.11.14 22.05.18 It is a bugfix/maintenance release including security fixes. The full release notes are available here: https://koha-community.org/koha-23-11-02-released/ https://koha-community.org/koha-23-05-08-released/ https://koha-community.org/koha-22-11-14-released/ https://koha-community.org/koha-22-05-18-released/ Debian packages are be available. Best regards 🤓 -- Fridolin SOMERS Software and system maintainer 🦄 BibLibre, France From mik at adminkuhn.ch Fri Feb 2 11:06:40 2024 From: mik at adminkuhn.ch (Michael Kuhn) Date: Fri, 2 Feb 2024 11:06:40 +0100 Subject: [Koha-devel] [Koha] Koha January release with security fixes In-Reply-To: <58cf899c-99ca-49ff-a1b3-467e4d082f55@biblibre.com> References: <58cf899c-99ca-49ff-a1b3-467e4d082f55@biblibre.com> Message-ID: <21f8e0bb-f0a1-4167-83c1-31a9605d121a@adminkuhn.ch> Hi Fridolin You wrote: > The full release notes are available here: > https://koha-community.org/koha-23-11-02-released/ This link works. > https://koha-community.org/koha-23-05-08-released/ > https://koha-community.org/koha-22-11-14-released/ > https://koha-community.org/koha-22-05-18-released/ These three links do not work. 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 at adminkuhn.ch · W www.adminkuhn.ch From dcook at prosentient.com.au Sun Feb 4 23:30:29 2024 From: dcook at prosentient.com.au (David Cook) Date: Mon, 5 Feb 2024 09:30:29 +1100 Subject: [Koha-devel] Growing size of koha/koha-testing:master Message-ID: <002401da57b9$c243a3f0$46caebd0$@prosentient.com.au> Hi all, I've noticed recently that koha/koha-testing:master has been steadily growing. At this point, it's about 4.37GB in size. For 21.11 I think it used to be about 2GB and 22.11 was 3.5GB. Do we know what's contributing to this? 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Mon Feb 5 12:49:36 2024 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Mon, 5 Feb 2024 08:49:36 -0300 Subject: [Koha-devel] Growing size of koha/koha-testing:master In-Reply-To: <002401da57b9$c243a3f0$46caebd0$@prosentient.com.au> References: <002401da57b9$c243a3f0$46caebd0$@prosentient.com.au> Message-ID: I think it's related to having Cypress bundled. And maybe some mistake on package cache cleanup. El dom, 4 feb 2024 a las 19:30, David Cook via Koha-devel (< koha-devel at lists.koha-community.org>) escribió: > Hi all, > > > > I’ve noticed recently that koha/koha-testing:master has been steadily > growing. At this point, it’s about 4.37GB in size. For 21.11 I think it > used to be about 2GB and 22.11 was 3.5GB. > > > > Do we know what’s contributing to this? > > > > 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 > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- Tomás Cohen Arazi Theke Solutions (https://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From fridolin.somers at biblibre.com Mon Feb 5 15:50:14 2024 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Mon, 5 Feb 2024 15:50:14 +0100 Subject: [Koha-devel] January point releases In-Reply-To: <0b3201da5598$1c2aae00$54800a00$@prosentient.com.au> References: <0b3201da5598$1c2aae00$54800a00$@prosentient.com.au> Message-ID: <53806d18-57a0-43ce-ac34-1d864fd48aa8@biblibre.com> Hi, All branches should be in main repo now Le 02/02/2024 à 06:24, David Cook via Koha-devel a écrit : > Hi all, > > I think the January point releases have been done. Just curious when > we’ll see those flow through to the main repository? > > 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 > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ -- Fridolin SOMERS Software and system maintainer 🦄 BibLibre, France From paul.poulain at biblibre.com Mon Feb 5 17:16:45 2024 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 5 Feb 2024 17:16:45 +0100 Subject: [Koha-devel] Hackfest registrations open ! Message-ID: <24434d10-13d3-46b7-9730-21ec7b3676bc@biblibre.com> Hello koha developers ! I'm very happy to open the registrations for the Marseille Koha hackfest. Some information: * *date* : April 8th > April 12th * *location*: BibLibre office, 23 rue Fauchier, 13002 Marseille *[NEW ADDRESS]* * *what is the cost* ? 0€ (I let you calculate in your own currency ;) ) * who can come: anyone with a laptop o librarian who want to contribute to Koha: test new version, test new features, document, translate, ... o developers who want to contribute to Koha: test technical patches, write unit tests, work on package, unit test, Elasticsearch, ERM module, LRMisation of Koha, or anything else ;) * can I come just for a part of the week ? Yes, but coming at least 3 days seems needed * coffee, tea, and break : provided by BibLibre. Feel free to come with candies from your country * what about lunch ? BibLibre organize, and ask for 21€ per lunch per person (veggie & gluten-free option available). * what about the cheese lunch ? On Tuesday :D * *How to register* ? Drop me an email About our new office: it's smaller than the previous one. However, I've found an additional location, just on the other side of the street, that can welcome 20 more ppl. 25+ ppl fit in BibLibre office, so we'll have enough space for everybody wanting to come. -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor at tuxayo.net Wed Feb 7 03:32:36 2024 From: victor at tuxayo.net (Victor Grousset/tuxayo) Date: Wed, 7 Feb 2024 03:32:36 +0100 Subject: [Koha-devel] Growing size of koha/koha-testing:master In-Reply-To: <002401da57b9$c243a3f0$46caebd0$@prosentient.com.au> References: <002401da57b9$c243a3f0$46caebd0$@prosentient.com.au> Message-ID: On 24-02-04 23:30, David Cook via Koha-devel wrote: > Do we know what’s contributing to this? After running `ncdu /` from inside KTD Debian 10 (the smallest image it seems) - 661 M /kohadevbox/Cypress - 347 M /kohadevbox/node_modules - 95 M /kohadevbox/misc4dev - 224 M /usr/lib/locale (does locales are needed for Koha? because all are generated) - 410 M /usr/lib/x86_64-linux-gnu , various lib, maybe libLLVM and guile are not needed - 93 M /usr/lib/gcc - 270 M /usr/share/locale & /usr/share/doc not sure that prunable depending on how packages are made in Debian. Maybe part can be pruned via a dirty rm -rf like it seems to be done for the apt repo metadata in dockerfiles. Seen that a few times. - 400 M /usr/local/share/.cache/yarn likely everything is needed to be able to rebuild CSS & vue without having to redownload. Which is done on start so not only needed when working with UI. Ok maybe some stuff is not needed? Same questions with /kohadevbox/node_modules npm(node) and yarn have redundancy in their cache >_< They share all of their top 10 packages (some with same size, other with quite different) ^^" I guess one is used for SCSS compilation and another one for vue and cypress. But they still have in common the packages of the 3, hmm Cheers, -- Victor Grousset/tuxayo From dcook at prosentient.com.au Wed Feb 7 03:41:24 2024 From: dcook at prosentient.com.au (David Cook) Date: Wed, 7 Feb 2024 13:41:24 +1100 Subject: [Koha-devel] Growing size of koha/koha-testing:master In-Reply-To: References: <002401da57b9$c243a3f0$46caebd0$@prosentient.com.au> Message-ID: <015001da596f$2afb5fd0$80f21f70$@prosentient.com.au> That's interesting. I think that adds up to about 2.5GB. I wonder where the other 2GB comes from. I have been wondering if we should be doing some of these steps in a "builder" image and copying across files in case some of the bloat is in the layering. Something to play with perhaps. It's not a top priority at the moment, but I thought I'd raise it. A few large koha-testing-docker images start adding up in terms of SDD space. I upgraded workstations not that long ago, and now I'm thinking maybe I need to do it again just for the storage... 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: Victor Grousset/tuxayo Sent: Wednesday, 7 February 2024 1:33 PM To: David Cook Cc: koha-devel Subject: Re: [Koha-devel] Growing size of koha/koha-testing:master On 24-02-04 23:30, David Cook via Koha-devel wrote: > Do we know what’s contributing to this? After running `ncdu /` from inside KTD Debian 10 (the smallest image it seems) - 661 M /kohadevbox/Cypress - 347 M /kohadevbox/node_modules - 95 M /kohadevbox/misc4dev - 224 M /usr/lib/locale (does locales are needed for Koha? because all are generated) - 410 M /usr/lib/x86_64-linux-gnu , various lib, maybe libLLVM and guile are not needed - 93 M /usr/lib/gcc - 270 M /usr/share/locale & /usr/share/doc not sure that prunable depending on how packages are made in Debian. Maybe part can be pruned via a dirty rm -rf like it seems to be done for the apt repo metadata in dockerfiles. Seen that a few times. - 400 M /usr/local/share/.cache/yarn likely everything is needed to be able to rebuild CSS & vue without having to redownload. Which is done on start so not only needed when working with UI. Ok maybe some stuff is not needed? Same questions with /kohadevbox/node_modules npm(node) and yarn have redundancy in their cache >_< They share all of their top 10 packages (some with same size, other with quite different) ^^" I guess one is used for SCSS compilation and another one for vue and cypress. But they still have in common the packages of the 3, hmm Cheers, -- Victor Grousset/tuxayo From kohanews at gmail.com Tue Feb 13 01:15:37 2024 From: kohanews at gmail.com (Koha Newsletter) Date: Tue, 13 Feb 2024 01:15:37 +0100 Subject: [Koha-devel] Call for news - Newsletter February 2024 Message-ID: Hi I'm collecting news for the February 2024 Koha Community Newsletter. Please send anything noteworthy to: kohanews (at) gmail (dot) com News criteria: * News items can be of any length. * Images are fine. * Anything and everything Koha. * Submit by the 26th of the month. Text format criteria: * Just structured plain text, or * HTML text to include tables or similar For events: * Consider adding your event to the Koha Community calendar at https://koha-community.org/calendar/ Thank you! Michael Kuhn Editor, Koha Community Newsletter -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Tue Feb 13 01:36:18 2024 From: dcook at prosentient.com.au (David Cook) Date: Tue, 13 Feb 2024 11:36:18 +1100 Subject: [Koha-devel] Session corruption in koha-testing-docker master Message-ID: <03c501da5e14$a8fb0170$faf10450$@prosentient.com.au> Hi all, The last two days I've noticed that my session is getting corrupted while I'm working on master in koha-testing-docker. I'm not touching the session myself, but seemingly randomly the session gets all kinds of DIBC data stuffed into it, and Koha seems to be parse it and Koha throws a fatal error, which can only be resolved by deleting the problematic session from the table. Just curious if anyone else is seeing this. I really don't think it's related to anything I'm working on, but I also can't reliably reproduce it. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleonard at myacpl.org Tue Feb 13 13:11:47 2024 From: oleonard at myacpl.org (Owen Leonard) Date: Tue, 13 Feb 2024 07:11:47 -0500 Subject: [Koha-devel] Session corruption in koha-testing-docker master In-Reply-To: <03c501da5e14$a8fb0170$faf10450$@prosentient.com.au> References: <03c501da5e14$a8fb0170$faf10450$@prosentient.com.au> Message-ID: > Koha throws a fatal error, which can only be resolved by deleting the problematic session from the table. Did the error look like this? https://paste.koha-community.org/37943 If so then yes I've seen it! But I don't know what happened to trigger it. I was able to resolve it by deleting cookies and local storage for the domain. -- Owen -- Web Developer Athens County Public Libraries (740) 737-6006 https://www.myacpl.org From tomascohen at gmail.com Tue Feb 13 14:02:08 2024 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Tue, 13 Feb 2024 10:02:08 -0300 Subject: [Koha-devel] Session corruption in koha-testing-docker master In-Reply-To: <03c501da5e14$a8fb0170$faf10450$@prosentient.com.au> References: <03c501da5e14$a8fb0170$faf10450$@prosentient.com.au> Message-ID: That's interesting! I've seen such situation on stuck STOMP messages, so I guess we are breaking userenv somewhere! El lun, 12 feb 2024 a las 21:36, David Cook via Koha-devel (< koha-devel at lists.koha-community.org>) escribió: > Hi all, > > > > The last two days I’ve noticed that my session is getting corrupted while > I’m working on master in koha-testing-docker. I’m not touching the session > myself, but seemingly randomly the session gets all kinds of DIBC data > stuffed into it, and Koha seems to be parse it and Koha throws a fatal > error, which can only be resolved by deleting the problematic session from > the table. > > > > Just curious if anyone else is seeing this. I really don’t think it’s > related to anything I’m working on, but I also can’t reliably reproduce it. > > > > 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 > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- Tomás Cohen Arazi Theke Solutions (https://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at bugs.koha-community.org Tue Feb 13 15:39:32 2024 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Tue, 13 Feb 2024 15:39:32 +0100 Subject: [Koha-devel] Session corruption in koha-testing-docker master In-Reply-To: <03c501da5e14$a8fb0170$faf10450$@prosentient.com.au> References: <03c501da5e14$a8fb0170$faf10450$@prosentient.com.au> Message-ID: Seen it for the first time right now. It is inside "cas_ticket" and it contains the columns for Koha::Patrons Seems related to bug 34893 Le mar. 13 févr. 2024 à 01:36, David Cook via Koha-devel < koha-devel at lists.koha-community.org> a écrit : > Hi all, > > > > The last two days I’ve noticed that my session is getting corrupted while > I’m working on master in koha-testing-docker. I’m not touching the session > myself, but seemingly randomly the session gets all kinds of DIBC data > stuffed into it, and Koha seems to be parse it and Koha throws a fatal > error, which can only be resolved by deleting the problematic session from > the table. > > > > Just curious if anyone else is seeing this. I really don’t think it’s > related to anything I’m working on, but I also can’t reliably reproduce it. > > > > 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 > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.jonsson at kreablo.se Tue Feb 13 16:25:25 2024 From: andreas.jonsson at kreablo.se (Andreas Jonsson) Date: Tue, 13 Feb 2024 16:25:25 +0100 Subject: [Koha-devel] Session corruption in koha-testing-docker master In-Reply-To: References: <03c501da5e14$a8fb0170$faf10450$@prosentient.com.au> Message-ID: <46880a0d-48c2-4c7d-8d18-6ce291e9c0c9@kreablo.se> As I wrote on bug 36034, with binary logging enabled, this can quickly fill up the disk space.  I think that an extra release with the fix is justified. /Andreas Den 2024-02-13 kl. 15:39, skrev Jonathan Druart via Koha-devel: > Seen it for the first time right now. > It is inside "cas_ticket" and it contains the columns for Koha::Patrons > Seems related to bug 34893 > > Le mar. 13 févr. 2024 à 01:36, David Cook via Koha-devel > a écrit : > > Hi all, > > The last two days I’ve noticed that my session is getting > corrupted while I’m working on master in koha-testing-docker. I’m > not touching the session myself, but seemingly randomly the > session gets all kinds of DIBC data stuffed into it, and Koha > seems to be parse it and Koha throws a fatal error, which can only > be resolved by deleting the problematic session from the table. > > Just curious if anyone else is seeing this. I really don’t think > it’s related to anything I’m working on, but I also can’t reliably > reproduce it. > > 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 > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Fri Feb 16 06:52:12 2024 From: dcook at prosentient.com.au (David Cook) Date: Fri, 16 Feb 2024 16:52:12 +1100 Subject: [Koha-devel] Override sysprefs in Apache config Message-ID: <011a01da609c$4bb7eac0$e327c040$@prosentient.com.au> Hi all, I've read this wiki page and tried this many times, and never ever gotten it to work. Is there something missing from these instructions? https://wiki.koha-community.org/wiki/Override_sysprefs_in_Apache_config 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Fri Feb 16 06:56:54 2024 From: dcook at prosentient.com.au (David Cook) Date: Fri, 16 Feb 2024 16:56:54 +1100 Subject: [Koha-devel] Override sysprefs in Apache config Message-ID: <012401da609c$f1e321d0$d5a96570$@prosentient.com.au> I think it might be partially broken. As per https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16520 I added the following to the OPAC and the staff interface: RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_LibraryName Potato\, Potato" It did indeed load into the OPAC. In the past, I think it used to fill in and lock the syspref in the staff interface as well. but maybe not anymore. Maybe because it would just affect the staff interface, and yet sometimes maybe you only want to affect the staff interface. hmm. 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: David Cook Sent: Friday, 16 February 2024 4:52 PM To: 'koha-devel' Subject: Override sysprefs in Apache config Hi all, I've read this wiki page and tried this many times, and never ever gotten it to work. Is there something missing from these instructions? https://wiki.koha-community.org/wiki/Override_sysprefs_in_Apache_config 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus at libriotech.no Fri Feb 16 08:26:17 2024 From: magnus at libriotech.no (Magnus Enger) Date: Fri, 16 Feb 2024 08:26:17 +0100 Subject: [Koha-devel] Override sysprefs in Apache config In-Reply-To: <012401da609c$f1e321d0$d5a96570$@prosentient.com.au> References: <012401da609c$f1e321d0$d5a96570$@prosentient.com.au> Message-ID: <9aa54b5c-da37-4f52-8a20-229185e0ee36@libriotech.no> Hi! Den 16.02.2024 06:56, skrev David Cook via Koha-devel: > I think it might be partially broken. > > As per https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16520 > I > added the following to the OPAC and the staff interface: > > RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_LibraryName Potato\, > Potato" > > It did indeed load into the OPAC. > > In the past, I think it used to fill in and lock the syspref in the > staff interface as well…  but maybe not anymore. Maybe because it would > just affect the staff interface, and yet sometimes maybe you only want > to affect the staff interface… hmm… We have used this a fair bit to set up alternative/infividual OPACs for individual libraries, but I have never seen a setting like that fill in or otherwise affect the actual syspref. And how would that work when you have 5 different VirtualHost configs all setting their own OVERRIDE_SYSPREF_LibraryName? I can confirm that settings like these work for us: RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_LibraryName Grundskolan" RequestHeader add X-Koha-SetEnv "OPAC_SEARCH_LIMIT branch:multibranchlimit-23" RequestHeader add X-Koha-SetEnv "OPAC_LIMIT_OVERRIDE 1" Best regards, Magnus From dcook at prosentient.com.au Sun Feb 18 23:21:11 2024 From: dcook at prosentient.com.au (David Cook) Date: Mon, 19 Feb 2024 09:21:11 +1100 Subject: [Koha-devel] Override sysprefs in Apache config In-Reply-To: <9aa54b5c-da37-4f52-8a20-229185e0ee36@libriotech.no> References: <012401da609c$f1e321d0$d5a96570$@prosentient.com.au> <9aa54b5c-da37-4f52-8a20-229185e0ee36@libriotech.no> Message-ID: <01c101da62b8$d4187c90$7c4975b0$@prosentient.com.au> Hi Magnus, Yeah, I was thinking it wouldn't make sense to affect the staff interface UI, since you might be overriding 5 different OPAC virtual hosts. But I had a vague memory that there was some sort of signifier that the syspref was being overridden. Maybe a false memory in the end. In the end, I did use X-Koha-SetEnv to set a syspref for one of two OPAC virtual hosts, so that worked well enough. 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 On Behalf Of Magnus Enger via Koha-devel Sent: Friday, 16 February 2024 6:26 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Override sysprefs in Apache config Hi! Den 16.02.2024 06:56, skrev David Cook via Koha-devel: > I think it might be partially broken. > > As per https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16520 > I > added the following to the OPAC and the staff interface: > > RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_LibraryName Potato\, > Potato" > > It did indeed load into the OPAC. > > In the past, I think it used to fill in and lock the syspref in the > staff interface as well… but maybe not anymore. Maybe because it > would just affect the staff interface, and yet sometimes maybe you > only want to affect the staff interface… hmm… We have used this a fair bit to set up alternative/infividual OPACs for individual libraries, but I have never seen a setting like that fill in or otherwise affect the actual syspref. And how would that work when you have 5 different VirtualHost configs all setting their own OVERRIDE_SYSPREF_LibraryName? I can confirm that settings like these work for us: RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_LibraryName Grundskolan" RequestHeader add X-Koha-SetEnv "OPAC_SEARCH_LIMIT branch:multibranchlimit-23" RequestHeader add X-Koha-SetEnv "OPAC_LIMIT_OVERRIDE 1" Best regards, Magnus _______________________________________________ Koha-devel mailing list Koha-devel at 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/ From dcook at prosentient.com.au Wed Feb 21 05:11:56 2024 From: dcook at prosentient.com.au (David Cook) Date: Wed, 21 Feb 2024 15:11:56 +1100 Subject: [Koha-devel] DataTables 2.0.0 Message-ID: <019501da647c$22ebec20$68c3c460$@prosentient.com.au> Hi all, I do not intend to draw your attention to this in any meaningful way. I just wanted to point out that DataTables 2.0.0 was released on February 15th 2024 (https://cdn.datatables.net/2.0.0/). Just squirrel away that information in the back of your brain for later. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From katrin.fischer at bsz-bw.de Mon Feb 26 16:55:02 2024 From: katrin.fischer at bsz-bw.de (Fischer, Katrin) Date: Mon, 26 Feb 2024 16:55:02 +0100 Subject: [Koha-devel] Development IRC meeting 28 February 2024 Message-ID: <17da01da68cc$28b57a50$7a206ef0$@bsz-bw.de> Hi all, since we missed the meeting in early February, I have now scheduled our next meeting for this Wednesday: https://wiki.koha-community.org/wiki/Development_IRC_meeting_28_February_202 4 Time converter: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+IR C+Meeting&iso=20240228T1200 I know it's a little short notice, but I hope to see you there! Katrin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7253 bytes Desc: not available URL: From martin.renvoize at ptfs-europe.com Mon Feb 26 23:46:03 2024 From: martin.renvoize at ptfs-europe.com (Renvoize, Martin) Date: Mon, 26 Feb 2024 22:46:03 +0000 Subject: [Koha-devel] Override sysprefs in Apache config In-Reply-To: <011a01da609c$4bb7eac0$e327c040$@prosentient.com.au> References: <011a01da609c$4bb7eac0$e327c040$@prosentient.com.au> Message-ID: We use it still I believe. There's an allow list of options inside the middleware: https://git.koha-community.org/Koha-community/Koha/src/branch/master/Koha/Middleware/SetEnv.pm#L66 I can't remember what the _NAMES option is for of the top of my head. Let me know if you need any further guidance and I'll try to dig out a working implementation here too help guide it. On Fri, 16 Feb 2024, 5:52 am David Cook via Koha-devel, < koha-devel at lists.koha-community.org> wrote: > Hi all, > > > > I’ve read this wiki page and tried this many times, and never ever gotten > it to work. Is there something missing from these instructions? > > > > https://wiki.koha-community.org/wiki/Override_sysprefs_in_Apache_config > > > > 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 > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.renvoize at ptfs-europe.com Mon Feb 26 23:50:52 2024 From: martin.renvoize at ptfs-europe.com (Renvoize, Martin) Date: Mon, 26 Feb 2024 22:50:52 +0000 Subject: [Koha-devel] Override sysprefs in Apache config In-Reply-To: <01c101da62b8$d4187c90$7c4975b0$@prosentient.com.au> References: <012401da609c$f1e321d0$d5a96570$@prosentient.com.au> <9aa54b5c-da37-4f52-8a20-229185e0ee36@libriotech.no> <01c101da62b8$d4187c90$7c4975b0$@prosentient.com.au> Message-ID: That might be what the _NAMES override is for.. I believe you pass it a list of the Prefs your overriding and it'll then display a message in the sysprefs if the staff client stating their likely override at the virtual host level. On Sun, 18 Feb 2024, 10:21 pm David Cook via Koha-devel, < koha-devel at lists.koha-community.org> wrote: > Hi Magnus, > > Yeah, I was thinking it wouldn't make sense to affect the staff interface > UI, since you might be overriding 5 different OPAC virtual hosts. But I had > a vague memory that there was some sort of signifier that the syspref was > being overridden. Maybe a false memory in the end. > > In the end, I did use X-Koha-SetEnv to set a syspref for one of two OPAC > virtual hosts, so that worked well enough. > > 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 On Behalf > Of Magnus Enger via Koha-devel > Sent: Friday, 16 February 2024 6:26 PM > To: koha-devel at lists.koha-community.org > Subject: Re: [Koha-devel] Override sysprefs in Apache config > > Hi! > > Den 16.02.2024 06:56, skrev David Cook via Koha-devel: > > I think it might be partially broken. > > > > As per https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16520 > > I > > added the following to the OPAC and the staff interface: > > > > RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_LibraryName Potato\, > > Potato" > > > > It did indeed load into the OPAC. > > > > In the past, I think it used to fill in and lock the syspref in the > > staff interface as well… but maybe not anymore. Maybe because it > > would just affect the staff interface, and yet sometimes maybe you > > only want to affect the staff interface… hmm… > > We have used this a fair bit to set up alternative/infividual OPACs for > individual libraries, but I have never seen a setting like that fill in or > otherwise affect the actual syspref. And how would that work when you have > 5 different VirtualHost configs all setting their own > OVERRIDE_SYSPREF_LibraryName? > > I can confirm that settings like these work for us: > > RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_LibraryName Grundskolan" > RequestHeader add X-Koha-SetEnv "OPAC_SEARCH_LIMIT > branch:multibranchlimit-23" > RequestHeader add X-Koha-SetEnv "OPAC_LIMIT_OVERRIDE 1" > > Best regards, > Magnus > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Mon Feb 26 23:57:34 2024 From: dcook at prosentient.com.au (David Cook) Date: Tue, 27 Feb 2024 09:57:34 +1100 Subject: [Koha-devel] Override sysprefs in Apache config In-Reply-To: References: <012401da609c$f1e321d0$d5a96570$@prosentient.com.au> <9aa54b5c-da37-4f52-8a20-229185e0ee36@libriotech.no> <01c101da62b8$d4187c90$7c4975b0$@prosentient.com.au> Message-ID: <00db01da6907$35dca0b0$a195e210$@prosentient.com.au> Martin, you legend. That’s what I was looking for and missing I think. Thanks for making me feel less crazy : ). 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: Renvoize, Martin Sent: Tuesday, 27 February 2024 9:51 AM To: David Cook Cc: Magnus Enger ; Koha Devel Subject: Re: [Koha-devel] Override sysprefs in Apache config That might be what the _NAMES override is for.. I believe you pass it a list of the Prefs your overriding and it'll then display a message in the sysprefs if the staff client stating their likely override at the virtual host level. On Sun, 18 Feb 2024, 10:21 pm David Cook via Koha-devel, > wrote: Hi Magnus, Yeah, I was thinking it wouldn't make sense to affect the staff interface UI, since you might be overriding 5 different OPAC virtual hosts. But I had a vague memory that there was some sort of signifier that the syspref was being overridden. Maybe a false memory in the end. In the end, I did use X-Koha-SetEnv to set a syspref for one of two OPAC virtual hosts, so that worked well enough. 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 > On Behalf Of Magnus Enger via Koha-devel Sent: Friday, 16 February 2024 6:26 PM To: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Override sysprefs in Apache config Hi! Den 16.02.2024 06:56, skrev David Cook via Koha-devel: > I think it might be partially broken. > > As per https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16520 > I > added the following to the OPAC and the staff interface: > > RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_LibraryName Potato\, > Potato" > > It did indeed load into the OPAC. > > In the past, I think it used to fill in and lock the syspref in the > staff interface as well… but maybe not anymore. Maybe because it > would just affect the staff interface, and yet sometimes maybe you > only want to affect the staff interface… hmm… We have used this a fair bit to set up alternative/infividual OPACs for individual libraries, but I have never seen a setting like that fill in or otherwise affect the actual syspref. And how would that work when you have 5 different VirtualHost configs all setting their own OVERRIDE_SYSPREF_LibraryName? I can confirm that settings like these work for us: RequestHeader add X-Koha-SetEnv "OVERRIDE_SYSPREF_LibraryName Grundskolan" RequestHeader add X-Koha-SetEnv "OPAC_SEARCH_LIMIT branch:multibranchlimit-23" RequestHeader add X-Koha-SetEnv "OPAC_LIMIT_OVERRIDE 1" Best regards, Magnus _______________________________________________ Koha-devel mailing list Koha-devel at 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/ _______________________________________________ Koha-devel mailing list Koha-devel at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kohanews at gmail.com Tue Feb 27 22:44:20 2024 From: kohanews at gmail.com (Koha Newsletter) Date: Tue, 27 Feb 2024 22:44:20 +0100 Subject: [Koha-devel] Koha Community Newsletter: February 2024 Message-ID: The Koha Community Newsletter for February 2024 is here: https://koha-community.org/koha-community-newsletter-february-2024/ Many thanks to everyone who submitted articles and news to this newsletter! Please feel free to email me with any corrections or suggestions. -- Michael Kuhn Editor, Koha Community Newsletter -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Wed Feb 28 06:09:36 2024 From: dcook at prosentient.com.au (David Cook) Date: Wed, 28 Feb 2024 16:09:36 +1100 Subject: [Koha-devel] Future of mod_security Message-ID: <01c701da6a04$551ae3d0$ff50ab70$@prosentient.com.au> Hi all, mod_security has had a troubled existence the past few years, but it looks like the company behind it has transferred it over to OWASP: https://owasp.org/blog/2024/01/09/ModSecurity.html Hopefully this means mod_security starts getting updated more. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hammat.wele at inlibro.com Wed Feb 28 22:37:10 2024 From: hammat.wele at inlibro.com (Hammat Wele) Date: Wed, 28 Feb 2024 21:37:10 +0000 Subject: [Koha-devel] Z3950 authority server integrated with ElasticSearch Message-ID: Hello everyone, I'm currently facing an issue with a new Z3950 authority server integrated with ElasticSearch that I'm trying to set up. My basic searches are functioning properly, but when I attempt to use @attr attributes, it doesn't seem to work. Interestingly, attribute 1=1 (personal name) works fine. I've attempted to address this by adding the attributes in the /etc/z3950/attribute_mappings.yaml file, but unfortunately, that hasn't resolved the issue. This situation has led me to question whether it's possible, with ElasticSearch for authorities, to perform a search on a specific field, such as a title by adding @attr 1=4 on yaz-client command line. In contrast, I haven't encountered this problem with an authority server under ZEBRA. For example, when I use @attr 1=4, it works seamlessly, but with ElasticSearch, it's not functioning as expected. Example with a Z3950 authority server under Zebra $ yaz-client xxx.xxx.xxx.xxx:xxxx/authorities Connecting...OK. Sent initrequest. Connection accepted by v3 target. ID     : 81 Name   : Zebra Information Server/GFS/YAZ Version: 2.0.44/4.2.69 026ad3d737be4cbba4e98c6b6dc753f8029e3655 Options: search present delSet triggerResourceCtrl scan sort extendedServices namedResultSets Elapsed: 0.446096 Z> f canada Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 172856, setno 1 SearchResult-1: term=canada cnt=172856 records returned: 0 Elapsed: 0.208821 Z> f @attr 1=4 canada Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 1920, setno 2 SearchResult-1: term=canada cnt=1920 records returned: 0 Elapsed: 0.858340 Z> With a Z3950 authority server under ElasticSearch $ yaz-client xxx.xxx.xxx.xxx:xxxx/authorities Connecting...OK. Sent initrequest. Connection accepted by v3 target. ID     : 81 Name   : Koha/GFS/YAZ Version: 21.05.11.000/5.27.1 872b6f92a024bb53bc1c11dfeccd47f065f98238 Options: search present triggerResourceCtrl namedResultSets Elapsed: 0.425683 Z> f canada Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 56811, setno 1 records returned: 0 Elapsed: 0.478937 Z> f @attr 1=4 canada Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 56811, setno 2 records returned: 0 Elapsed: 0.261396 Z> Utilizing a Z3950 authority server with ElasticSearch, the yaz-client connects successfully to Koha/GFS/YAZ (Version 21.05.11.000/5.27.1). However, when attempting searches for 'canada' with the attribute '@attr 1=4', the number of results (56811) remains the same, '@attr 1=4' does not have effect. I aim to enable the functionality of attributes to be able to search via these field         nameany           => '@attr 1=1002 "#term" ',         authorany         => '@attr 1=1003 "#term" ',         authorcorp        => '@attr 1=2 "#term" ',         authorpersonal    => '@attr 1=1 "#term" ',         authormeetingcon  => '@attr 1=3 "#term" ',         subject           => '@attr 1=21 "#term" ',         subjectsubdiv     => '@attr 1=47 "#term" ',         title             => '@attr 1=4 "#term" ',         uniformtitle      => '@attr 1=6 "#term" ',         srchany           => '@attr 1=1016 "#term" ',         controlnumber     => '@attr 1=12 "#term" ', Do you have any suggestion/check to fix this situation ? Cheers Hammat Wele From michael.hafen at washk12.org Wed Feb 28 22:45:04 2024 From: michael.hafen at washk12.org (Michael Hafen) Date: Wed, 28 Feb 2024 14:45:04 -0700 Subject: [Koha-devel] Z3950 authority server integrated with ElasticSearch In-Reply-To: References: Message-ID: I believe, for Zebra, the file /etc/koha/zebradb/authorities/etc/bib1.att maps attributes to indexes. I don't know elasticsearch that well, so I can't say whether there is or isn't a similar configuration there. Or even whether it's possible to do that. In the past it was deemed unfeasible to have elasticsearch handle the Z39.50 protocol, and zebra was kept around for that. Maybe that's changed since then? On Wed, Feb 28, 2024 at 2:37 PM Hammat Wele via Koha-devel < koha-devel at lists.koha-community.org> wrote: > Hello everyone, > > I'm currently facing an issue with a new Z3950 authority server > integrated with ElasticSearch that I'm trying to set up. My basic > searches are functioning properly, but when I attempt to use @attr > attributes, it doesn't seem to work. Interestingly, attribute 1=1 > (personal name) works fine. I've attempted to address this by adding the > attributes in the /etc/z3950/attribute_mappings.yaml file, but > unfortunately, that hasn't resolved the issue. > > This situation has led me to question whether it's possible, with > ElasticSearch for authorities, to perform a search on a specific field, > such as a title by adding @attr 1=4 on yaz-client command line. In > contrast, I haven't encountered this problem with an authority server > under ZEBRA. For example, when I use @attr 1=4, it works seamlessly, but > with ElasticSearch, it's not functioning as expected. > > Example > with a Z3950 authority server under Zebra > > $ yaz-client xxx.xxx.xxx.xxx:xxxx/authorities > Connecting...OK. > Sent initrequest. > Connection accepted by v3 target. > ID : 81 > Name : Zebra Information Server/GFS/YAZ > Version: 2.0.44/4.2.69 026ad3d737be4cbba4e98c6b6dc753f8029e3655 > Options: search present delSet triggerResourceCtrl scan sort > extendedServices namedResultSets > Elapsed: 0.446096 > Z> f canada > Sent searchRequest. > Received SearchResponse. > Search was a success. > Number of hits: 172856, setno 1 > SearchResult-1: term=canada cnt=172856 > records returned: 0 > Elapsed: 0.208821 > Z> f @attr 1=4 canada > Sent searchRequest. > Received SearchResponse. > Search was a success. > Number of hits: 1920, setno 2 > SearchResult-1: term=canada cnt=1920 > records returned: 0 > Elapsed: 0.858340 > Z> > > With a Z3950 authority server under ElasticSearch > $ yaz-client xxx.xxx.xxx.xxx:xxxx/authorities > Connecting...OK. > Sent initrequest. > Connection accepted by v3 target. > ID : 81 > Name : Koha/GFS/YAZ > Version: 21.05.11.000/5.27.1 872b6f92a024bb53bc1c11dfeccd47f065f98238 > Options: search present triggerResourceCtrl namedResultSets > Elapsed: 0.425683 > Z> f canada > Sent searchRequest. > Received SearchResponse. > Search was a success. > Number of hits: 56811, setno 1 > records returned: 0 > Elapsed: 0.478937 > Z> f @attr 1=4 canada > Sent searchRequest. > Received SearchResponse. > Search was a success. > Number of hits: 56811, setno 2 > records returned: 0 > Elapsed: 0.261396 > Z> > > Utilizing a Z3950 authority server with ElasticSearch, the yaz-client > connects successfully to Koha/GFS/YAZ (Version 21.05.11.000/5.27.1). > However, when attempting searches for 'canada' with the attribute '@attr > 1=4', the number of results (56811) remains the same, '@attr 1=4' does > not have effect. > > I aim to enable the functionality of attributes to be able to search via > these field > nameany => '@attr 1=1002 "#term" ', > authorany => '@attr 1=1003 "#term" ', > authorcorp => '@attr 1=2 "#term" ', > authorpersonal => '@attr 1=1 "#term" ', > authormeetingcon => '@attr 1=3 "#term" ', > subject => '@attr 1=21 "#term" ', > subjectsubdiv => '@attr 1=47 "#term" ', > title => '@attr 1=4 "#term" ', > uniformtitle => '@attr 1=6 "#term" ', > srchany => '@attr 1=1016 "#term" ', > controlnumber => '@attr 1=12 "#term" ', > > > Do you have any suggestion/check to fix this situation ? > > Cheers > Hammat Wele > _______________________________________________ > Koha-devel mailing list > Koha-devel at 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/ > -- Michael Hafen Washington County School District Technology Department Systems Analyst -------------- next part -------------- An HTML attachment was scrubbed... URL: