March 2023 - Koha - lists.katipo.co.nz

Restore the default Marc Framework
by Victor Barroso Oliveira 04 Sep '24

04 Sep '24

Hello, how to restore the default Marc Framework to the original pattern? koha version 22.05.05 ubuntu 20 Thanks, Victor

4 5

Re: [Koha] How to copy patron permissions?
by BRANNON, CHRISTOPHER 22 Jan '24

22 Jan '24

Michael, I've had some jQuery in the Koha library for quite a while. You should take a look at https://wiki.koha-community.org/wiki/JQuery_Library#Add_clear_and_preset_pe… There are 3 versions of this for different versions of Koha, but this latest one includes a clear permissions button, a couple of preset permission buttons, and a copy permissions button. Please check it out. We also did a video tutorial on this enhancement in season one of The Terrific Every-Other-Thursday Training Videos. You can find that here: https://youtu.be/M6aQITCJY0U. ___________________________ Christopher Brannon IT Coordinator 702 E Front Ave Coeur d'Alene, ID 83814 (208)769-2315 Ext. 456 cbrannon(a)cdalibrary.org www.cdalibrary.org Keep tabs on us at: Date: Tue, 26 Apr 2022 10:39:58 +0200 From: Michael Kuhn <mik(a)adminkuhn.ch> To: Koha <koha(a)lists.katipo.co.nz> Subject: [Koha] How to copy patron permissions? Message-ID: <abc69231-a587-77d5-01d2-7f98e5b16174(a)adminkuhn.ch> Content-Type: text/plain; charset=UTF-8; format=flowed Hi Is it possible to copy the permissions of another patron when creating a new one? I always thought this would happen when copying/duplicating an existing patron. But when I actually tried it today the permissions were not there with the new patron and I had to set them manually. Best wishes: Michael Kuhn

4 3

Cannot import records: Failed to connect: Error connecting to localhost:61613
by Giuseppe Angilella 23 Jun '23

23 Jun '23

Hi, after upgrading a Debian (Ubuntu) installation to version 22.11.03.000 Rosalie , I fail to import any new Marc record into the database. My worker-output.log reports: Failed to connect: Error connecting to localhost:61613: Connection refused at /usr/share/perl5/Net/Stomp.pm line 27.; giving up at /usr/share/perl5/Net/Stomp.pm line 26. I believe this strange behavior can be traced back to Bug 26742: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26742 As suggested there, I did manually include the lines: <message_broker> <hostname>localhost</hostname> <port>61613</port> <username>guest</username> <password>guest</password> <vhost></vhost> </message_broker> (which weren't present, despite all previous upgrades) into my etc/koha-conf.xml file, and restarted everything. But the issue is still there. The About tab of my installation says that: Message broker: Using RabbitMQ Any help or hint? Many thanks! Best regards, Giuseppe.

3 2

Koha 21.11.09 released
by Arthur 11 May '23

11 May '23

The Koha community is pleased to announce the release of version 21.11.09. For full release notes, please visit https://koha-community.org/koha-version-21-11-09-released/ <https://koha-community.org/koha-21-11-09-released/> Thanks! 🚀

3 4

Background job / Staging MARC import stuck at 0%
by Michael Brown 09 May '23

09 May '23

Greetings: My name is Michael Brown and I am a professional cataloger and SirsiDynix System Admin at the Texas State Library & Archives in Austin (20+ years now). I have been using Koha on Arch Linux in my home library for about a year now. I am migrating my home server to AlmaLinux and I'm having a problem. I am running Koha 22.11.03.000 Rosalie on AlmaLinux 9.1. Staging a MARC file for import gets stuck at 0%. On screen, I am able to select the file for import (bib.mrc), review the profile options (but I don't change any defaults), and then click on "Stage for import" at the bottom. Next screen reads: The job has been enqueued! It will be processed as soon as possible. 0% View detail of the enqueued job After a few seconds, it changes to (and then hangs at): The job has been enqueued! It will be processed as soon as possible. 0% Not started View detail of the enqueued job Clicking on "View detail of the enqueued job" I see: Details of job #22 Job ID: 22 Status: New Progress: 0 / 0 Type: Staged MARC records for import Queued: 03/02/2023 05:42 Started: Ended: Report Detailed messages Return to the job list The corresponding entry in mariadb is: id 22 status new progress NULL size 0 borrowernumber 1 type stage_marc_for_import queue Name of the queue the job is sent to long_tasks data {"encoding":"UTF-8","comments":"","basket_id":null... context JSON-serialized context information for the job {"flags":1,"branch":"ALMA","interface":"intranet",... enqueued_on 2023-03-02 05:42:33 started_on NULL ended_on NULL (If you need to see the full entries for "data" and "context", please let me know.) tmp, koha_upload, and lock directories have been tweaked and fine tuned. I was getting early warnings about them not being set in koha-conf.xml so I created them (and set correct permissions) and I can see the uploaded file (for job 22 the name is 2287629673fb980ad4102f62ebeaa1b9_bib.mrc), so the actual upload function appears to be working. I am getting no apache errors and no other on-screen diagnostics. I have Koha 22.05.02.000 running on Arch Linux that imports this file just fine. Similarly, I have Koha latest running on a Debian VM that can import this file just fine, too. What am I missing? Details of my system: Koha version: 22.11.03.000 Rosalie OS version ('uname -a'): Linux alma 5.14.0-162.12.1.el9_1.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jan 23 14:51:52 EST 2023 x86_64 Perl interpreter: /usr/bin/perl Perl version: 5.032001 Perl @INC: /usr/share/koha/lib /usr/local/lib64/perl5/5.32 /usr/local/share/perl5/5.32 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 /var/lib/koha/plugins MySQL version: mysql Ver 15.1 Distrib 10.5.16-MariaDB, for Linux (x86_64) using EditLine wrapper Apache version: Server version: Apache/2.4.53 (AlmaLinux) Server built: Jul 20 2022 00:00:00 Memcached: Servers: 127.0.0.1:11211 | Namespace: KOHA | Status: running. | Config read from: koha-conf.xml Zebra version: Zebra 2.2.7 (C) 1994-2023, Index Data Zebra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. SHA1 ID: ac40f289672405a299436d73c1532f9906774cc6 Using ICU Zebra status: Running Message broker: Using RabbitMQ Date and time: 03/01/2023 16:20 Time zone: Used: America/Chicago | Config: Undefined | Environment (TZ): Undefined Thanks, Michael

6 12

Koha and IPV6
by Michael Kuhn 28 Apr '23

28 Apr '23

Hi Our library can access the the future virtual machine running Koha only via IPV6. I coulnd't find the terms IPV4 or IPV6 neither in https://wiki.koha-community.org/wiki/System_requirements_and_recommendations nor in the current Koha manual. Thus my question (since until now I have implemented only Koha-installations with IPV4): Is Koha able to run just with IPV6 addresses, also when using Let's Encrypt? Are there maybe some caveats? 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

3 3

Upgrading from 19.11.29.000 to latest
by Steve Nickerson 28 Apr '23

28 Apr '23

I've upgraded my OS from Jessie to Stretch, and am now trying to upgrade a Koha Debian package install from 19.11.29.000 to the latest, but the schema upgrade fails with this: * Upgrade to 22.06.00.077 [23:48:59]: ERROR: {UNKNOWN}: Can't use an undefined value as a subroutine reference at /usr/share/koha/lib/C4/Installer.pm line 737. at /usr/share/koha/lib/C4/Installer.pm line 739 I've searched Bugzilla and don't' seem to find anything similar. Anyone have any idea what might cause this? Missing some package perhaps? Cheers! Steve

3 5

Re: [Koha] Can the Koha Mailing List and DMARC become friends?
by Thomas Dukleth 12 Apr '23

12 Apr '23

[Resending to correct accidental paste in my message but adding consideration of use of Discourse as a partial workaround.] I added to the meeting agenda some brief consideration of implementation if we adopt DMARC for the Koha mailing list. These issues have had some discussion on the Koha mailing list. There is no problem free way to implement DMARC for mailing lists in part because email and mailing lists were designed before authentication of senders was considered a sufficiently concerning problem. 1. Mailman. Two implementation approaches to consider are the following. Quotations below are from the Mailman 3 section in https://wiki.list.org/DEV/DMARC but there are matching parts in the Mailman 2 section. One option: "Munge the From: header - The obvious way to avoid a DMARC rejection [...]" Alternative option: "Wrap the message - This involves MIME wrapping the original message [...] Users of MUAs that can't unwrap this MIME decoration would suffer." The suffering would be some users of the very wide variety of email clients people use from console, to desktop, to some old mobile device may not see any body message and merely have an attachment requiring extra processing outside of the user's email program. See "If MIMEs could talk: Email structures in the wild" / Bo Waggoner - https://bowaggoner.com/bomail/writeups/mimes.html for some perspective on the complexities of mime use in messages and how every email client has an individual implementation to cope. Limiting scope to affected users. It is reportedly possible to configure Mailman to limit the scope of DMARC mitigations to affected users such that the mailing list messages are unaltered for others, "Enable dmarc mitigations" - https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… . My current understanding leads me to prefer "munging the from header" as an implementation despite some RFC non-compliance. As stated above; email, mailing lists, and their associated RFCs long preceded considerations of authentication. Having problematic email clients for "MIME wrapping" in the wild seems to me to be a worse problem than some otherwise unavoidable RFC non-compliance with the very diverse subscriber base for the mailing list. Diverse subscribers have diverse computer systems and frequently restrictions on changing them where they actually read and reply to email on work systems and other systems as opposed to some major proprietary webmail intermediaries through which email may pass for many people. 2. Discourse. Does Discourse mailing list mode avoid problems with DMARC in a manner that is still sensible for offline use? Mailing lists are good for offline use. Does discourse provide something similar to Mailman "munging the from header" so that the message poster is identified in the email from header originating from the Discourse server allowing email clients to display lists of messages helpfully including by message poster in addition to subject and time? Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 On Fri, March 3, 2023 17:43, David Liddle wrote: > Thank you for adding it to the discussion points! > > > On Fri, Mar 3, 2023 at 6:08 PM Katrin Fischer <katrin.fischer.83(a)web.de> > wrote: > >> I have added the DMARC issue to the agenda for the next developer IRC >> meeting, but we might need the people running our mailservers to weigh >> in: >> >> https://wiki.koha-community.org/wiki/Development_IRC_meeting_9_March_2023 >> >> Hope this helps, >> >> Katrin >> >> On 27.02.23 15:49, Coehoorn, Joel wrote: >> > FWIW, I'm seeing the same thing for our "york.edu" domain, but only >> for >> the >> > last couple of months. The list used to handle this correctly. >> > >> > *Joel Coehoorn* >> > Director of Information Technology >> > *York University* >> > Office: 402-363-5603 | jcoehoorn(a)york.edu | york.edu >> > >> > >> > >> > On Mon, Feb 27, 2023 at 8:00 AM David Liddle <david(a)liddles.net> >> wrote: >> > >> >> Greetings, all! >> >> >> >> At the encouragement of one of the mailing list administrators, I >> >> would like to present a situation and a proposal to you all. >> >> >> >> Normally, I would write from my work account, >> david.liddle(a)wycliff.de, >> >> since one of the hats I wear is that of a Koha system administrator. >> >> One of my other hats, however, is that of the email administrator for >> >> our corporate domains. And the latter hat has precedence over the >> >> former. >> >> >> >> To help protect our email domains from being used fraudulently, I >> have >> >> implemented DMARC policies according to current recommendations. You >> >> can read more about the Domain-based Message Authentication, >> Reporting >> >> & Conformance protocol at https://dmarc.org/. The policies direct >> that >> >> only messages from authorized sources should be allowed to send mail >> >> from wycliff.de and our other domains; messages from all unauthorized >> >> sources should be quarantined. >> >> >> >> With DMARC policies in place, messages that I send from my work >> >> account to the Koha mailing list get quarantined by email providers >> >> that comply with the policies' directives. Why? It happens because >> the >> >> Koha mailing list spoofs the email address of the original sender. As >> >> a result, there is a significant number of subscribers who did not >> >> receive the messages at all or had to fetch them from quarantine. >> Some >> >> unknown number will have been marked as spam. >> >> >> >> There are well-meaning reasons for this behavior within an honest, >> >> friendly community such as the Koha mailing list. However, email >> >> spoofing is one of the chief means by which fraudsters engage in >> >> phishing, data exfiltration, and ransomware attacks. In my opinion, >> >> the Koha community ought to avoid the practice of email spoofing. >> >> Therefore, I have a proposal to make: >> >> >> >> -- The Koha Mailing List is based on the Mailman list system. >> >> According to its release notes, Mailman 2.1 supports what the >> >> developers call "DMARC mitigations". >> >> -- Mailman DMARC Mitigations are described here: >> >> >> >> >> https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/d… >> >> ++ I PROPOSE that the mailing list subscribers support the >> >> implementation of DMARC mitigations to the Koha mailing list. >> >> -- The result of the implementation would be that messages submitted >> >> to the list would no longer spoof the sender's address, but rather be >> >> altered so that the messages come from the list's own address, >> >> koha(a)lists.katipo.co.nz. They *should* be delivered successfully to >> >> all recipients. A reply to the message would return to the list, and >> a >> >> reply to all could include the original sender's address explicitly. >> >> -- If you agree (or disagree) with this proposal, you'll need to >> >> indicate that in your own clever way, because there's no voting >> >> mechanism in a mailing list. >> >> >> >> Thank you for being so kind and forbearing as to read this far! I >> hope >> >> that you'll give my proposal your earnest consideration. >> >> >> >> Regards, >> >> >> >> David Liddle >> >> >> >> >> >> After-credits scene: >> >> >> >> For you intrepid readers, I would like to boldly suggest something >> >> even more daring than changing the list's sending practices. Please >> >> consider changing the platforms of the Koha email and chat >> discussions >> >> to one such as Discourse: >> >> >> >> -- The Discourse software and community seems to have a fair bit in >> >> common with the character and nature of Koha's. You can read more >> >> about the platform at https://www.discourse.org/. >> >> -- Not only is it a web forum, but it can handle email submissions, >> >> replies, notifications, and digests. (And it would always send from a >> >> legitimate address.) >> >> -- It has migration tools that appear able to import archives such as >> >> those used by this list. >> >> -- It has chat integration for real-time messaging that can also be >> >> perused later. >> >> -- It has functions for search, categorization, and groups that a >> >> mailing list does not. [...]

3 3

Analytical cataloguing causing a searching warning
by Aleisha Amohia 31 Mar '23

31 Mar '23

Hi Koha community! We're having some trouble with analytical cataloguing - linking host and child records. We have EasyAnalyticalRecords enabled, and UseControlNumber disabled. When we link the host item using the barcode, the detail page for the child item shows this warning above the title: "There was an error searching for analytic records, please see the logs for details." The Plack Intranet error log shows the following errors: [2022/02/15 13:59:09] [WARN] CCL parsing error (10014) Embedded truncation not supported ZOOM for query: Host-item=(BIBLIO_TITLE /) at /usr/share/koha/lib/C4/Search.pm line 241. [2022/02/15 13:59:09] [WARN] Warning from simple_search_compat: CCL parsing error (10014) Embedded truncation not supported ZOOM at /usr/share/koha/intranet/cgi-bin/catalogue/detail.pl line 152. I have tried also manually linking the host item by cataloguing directly into the 773 of the child item, the searching warning still shows. I have also tried enabling UseControlNumber and putting the 001 of the host record into 773$w of the child item, which has usually worked (the warning disappears), however this method does not work for us because the library doesn't usually fill in the 001. We'd rather keep UseControlNumber disabled. Is this a problem that other libraries have other seen? Have you been able to solve it while keeping EasyAnalyticalRecords enabled and UseControlNumber disabled? Would appreciate any help. Thanks all! -- Aleisha Amohia (she/her) Koha Developer Catalyst IT - Expert Open Source Solutions www.catalyst.net.nz CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 4 499 2267.

4 5

Koha Community Newsletter: March 2023
by Koha Newsletter 31 Mar '23

31 Mar '23

The Koha Community Newsletter for March 2023 is here: https://koha-community.org/koha-community-newsletter-march-2023/ 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

1 0