- Koha - lists.katipo.co.nz

OAI-PMH harvester news
by BOUIS Sonia 29 Dec '23

29 Dec '23

Hello, some news about the OAI-PMH harvester development. Biblibre has almost finished the development, we tried it this this afternoon. It's a simple first version of the OAI-PMH harvester with : A setting page is accessible in the admin section with the manage_search_targets permission. This page contains the fields : name; endpoint; set; data format (oai_dc; marc_xml); Encoding (utf8, ISO_5426, ...); record type (bibliographic, authority); XSLT for transforming rules (OAIDCtoUNIMARCXML.xsl ; OAIMarcxml2KohaMarcxml.xsl ...MARC21 is coming) The harvesting is possible only via the cron with a command harvest_oai.pl with the following parameters : h -help ; -v -verbose ; -s --server: id of the OAI server ; -d --days: number of days to harvest from (optional) ; -l --list: list the OAI servers The logs will be readable via the log viewer in the Tools section. The deduplication is only for records coming from the same OAI server, it will be checked with : server URL, identifier, the record type (biblio/authority). It will be the first step and Biblibre should be able to add it to Bugzilla in January 2024. But, there's still a big issue to solve. To add this development to Koha, we have to change the Perl module and to fix Bug 17704<https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17704> - Fix OAI breakage when using HTTP::OAI 4.03+ Could someone have a look on it? Regards, Sonia Sonia BOUIS Absente le vendredi ------------------------------------------------------ Responsable du Service informatique documentaire (SID) Département d'Appui à la Recherche et aux Projets (DARP) Bibliothèques universitaires Université Jean Moulin Lyon 3 ADRESSE GÉOGRAPHIQUE > Manufacture des Tabacs | 6 cours Albert Thomas | LYON 8e ADRESSE POSTALE > Bibliothèque de la Manufacture | 1C avenue des Frères Lumière | CS 78242 - 69372 LYON CEDEX 08 Ligne directe : 33 (0)4 78 78 79 03 http://bu.univ-lyon3.fr<http://bu.univ-lyon3.fr/>| Suivez-nous > Facebook<https://www.facebook.com/bulyon3/> | Twitter<https://twitter.com/bulyon3>| Instagram<https://www.instagram.com/bu.lyon3/?hl=fr> --------------------------------------------------- L'Université Jean Moulin est membre de l'Université de Lyon

2 1

Koha Community Newsletter: December 2023
by Koha Newsletter 28 Dec '23

28 Dec '23

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

koha-plugin-room-reservations
by Sami M. Rasheed 26 Dec '23

26 Dec '23

Dear all, Hi, koha-plugin-room-reservations (V. 4.02) not working under Koha 23.11.00, the OPAC display this error: Sorry, the requested page is not available Error 500 This message can have the following reason(s): - An error occurred while processing your request. What's next? - You can use the menu and links at the top of the page - You can search our catalog using the search form at the top of this page. - Return to the catalog home page. Report issues and broken links - To report this error, please contact the Koha Administrator. Send email. Thanks

2 1

koha-US January 2024 Events & Meetings
by Kristi Krueger 26 Dec '23

26 Dec '23

Hello! koha-US online meetings and events are free and open to all. See our calendar for a full list: http://koha-us.org/calendar/. For Google Calendar users, add our events calendar to your list for easy access to meeting times and links: https://calendar.google.com/calendar/u/1?cid=a29oYS11cy5vcmdfZG1xb2pkczE5Zn… *Meetings* General Meeting - Wednesday, January 03 @ 8:30a PT / 11:30a ET / 15:30 UTC Board Meeting - Wednesday, January 10 @ 8:30a PT / 11:30a ET / 15:30 UTC *Special Interest Groups* Cataloging - Thursday, January 04 @ 8:00a PT / 11:00a ET / 15:00 UTC System Administration - Tuesday, January 09 @ 8:00a PT / 11:00a ET / 15:00 UTC Circulation - Thursday, January 11 @ 8:00a PT / 11:00a ET / 15:00 UTC Acquisitions - Tuesday, January 16 @ 9:00a PT / 12:00p ET / 16:00 UTC Web Development - Thursday, January 18 @ 10:00a PT / 1:00p ET / 17:00 UTC Consortia - Thursday, January 25 @ 9:00a PT / 12:00p ET / 16:00 UTC Demonstration Instance - on hiatus Visit http://koha-us.org/special-interest-groups/ to learn more and sign up for topic-specific mailing lists. Most meetings and events are recorded and made available at https://www.youtube.com/kohaus Kristi Krueger koha-US Secretary secretary(a)koha-US.org

1 0

The Terrific Every-Other-Thursday Training Video | Reports and Makeshift Sorting | 408
by BRANNON, CHRISTOPHER 21 Dec '23

21 Dec '23

Wouldn't it be nice if you could sort your results in a Koha report? Well, in this episode, George will share a workaround that will let you do just that. Now, if only I could get George to sort the rest of the things in my office. Well, we can only expect so much! https://youtu.be/wj1kV1I1rNk Christopher Brannon koha-US Admin

1 0

Member of koha Ethiopia Defence University Mr. Tadesse Gebre
by Tadesse Gebre 21 Dec '23

21 Dec '23

How to member of Koha and dspace open software your community ?

1 0

Database discrepancy flagged after Koha upgrade
by City & Guilds of London Art School Admin 20 Dec '23

20 Dec '23

Hello, Platform: Ubuntu 20.04.6 LTS DB: 10.3.38-MariaDB Koha Version: 23.11 Since the most recent upgrade (using the package manager) from 23.05.x to 23.11.00, the following is returned in *About Koha -> System Information* ====== Data problems Some of your tables have problems with their auto_increment values which may lead to data loss. You should not ignore this warning. The problem is that InnoDB does not keep auto_increment across SQL server restarts (it is only set in memory). So on server startup the auto_increment values are set to max(table.id)+1. To know how to avoid this problem see the related wiki page: DBMS auto increment fix Problems found Bibliographic records The following IDs exist in both tables biblio and deletedbiblioitems: 2 , 3 , 4 ====== Note that the fix here: https://wiki.koha-community.org/wiki/DBMS_auto_increment_fix has been implemented since we started with Koha, and that the five tests for data corruption documented there return empty sets. The mysql error.log reports no issues with parsing the bespoke init file etc. Investigating further I see that indeed: > select biblionumber, timestamp from deletedbiblioitems where biblionumber <= '8'; +--------------+---------------------+ | biblionumber | timestamp | +--------------+---------------------+ | 1 | 2023-01-13 11:00:38 | | 2 | 2021-06-09 14:06:34 | | 3 | 2021-06-09 14:06:52 | | 4 | 2021-06-09 14:06:57 | | 5 | 2021-06-09 14:07:00 | | 6 | 2021-06-09 14:07:06 | | 7 | 2021-06-09 14:07:10 | | 8 | 2021-06-09 14:07:13 | +--------------+---------------------+ 8 rows in set (0.000 sec) Whereas: > select biblionumber, timestamp from biblio where biblionumber <= '8'; +--------------+---------------------+ | biblionumber | timestamp | +--------------+---------------------+ | 2 | 2021-11-04 16:32:46 | | 3 | 2022-01-17 16:50:10 | | 4 | 2022-08-02 16:00:02 | +--------------+---------------------+ 3 rows in set (0.001 sec) Also: > select biblionumber, timestamp from deletedbiblio where biblionumber <= '8'; +--------------+---------------------+ | biblionumber | timestamp | +--------------+---------------------+ | 1 | 2023-01-13 11:00:39 | | 5 | 2021-06-09 14:07:02 | | 6 | 2021-06-09 14:07:07 | | 7 | 2021-06-09 14:07:12 | | 8 | 2021-06-09 14:07:14 | +--------------+---------------------+ 5 rows in set (0.000 sec) Correct me if I'm wrong, but my understanding is that Koha row counts should *always* be identical for the pair of tables: *biblio* and *biblioitems*, and also be identical for the pair *deletedbiblio* and *deletedbiblioitems*, since the latter is copied from the former. However, we have: > select count(*) from biblio; +----------+ | count(*) | +----------+ | 11508 | +----------+ 1 row in set (0.006 sec) > select count(*) from biblioitems; +----------+ | count(*) | +----------+ | 11508 | +----------+ 1 row in set (0.033 sec) > select count(*) from deletedbiblioitems; +----------+ | count(*) | +----------+ | 15777 | +----------+ 1 row in set (0.072 sec) > select count(*) from deletedbiblio; +----------+ | count(*) | +----------+ | 15774 | +----------+ 1 row in set (0.011 sec) Also, I was able to ascertain from backups that this discrepancy went back some way - at least till mid October '23 (which as as far back as our backups go), however, Koha did not report on it till after the most recent upgrade from 23.05 to 23.11.00. While this is easy enough to "solve" by removing records 2 - 4 from *deletedbiblioitems*, I have the following questions: *1.* If I run a query modeled on the existing queries for data corruption in the linked wiki page, unsurprisingly I get: > SELECT b.biblionumber FROM biblio b JOIN deletedbiblioitems db ON b.biblionumber=db.biblionumber; +--------------+ | biblionumber | +--------------+ | 2 | | 3 | | 4 | +--------------+ 3 rows in set (0.000 sec) So I'm wondering if the documented fix needs updating since it was last reviewed (11th December 2020). My guess is that an additional corruption test comparing *deletedbiblio* and *deletedbiblioitems*, and something like the below may be needed, but I would prefer someone a *lot* more knowledgeable about SQL (and Koha) to give their input, since my SQL skills are pretty basic: SET @new_AI_deletedbiblio = ( SELECT GREATEST( IFNULL( ( SELECT MAX(biblioitemnumber) FROM deletedbiblio ), 0 ), IFNULL( ( SELECT MAX(biblioitemnumber) FROM deletedbiblioitems ), 0 ) ) + 1 ); SET @sql = CONCAT( 'ALTER TABLE deletedbiblio AUTO_INCREMENT = ', @new_AI_deletedbiblio ); PREPARE st FROM @sql; EXECUTE st; 2. Although I can only check actual backups of the db back to mid October, it seems logical that this error has always existed since we got beyond 4 deleted records (presumably June 2021). So I'm wondering what causes Koha to flag it up now? 3. Is there any chance this could be caused by writes occurring during a mysqldump operation not run as a single transaction? 4. According to the wiki page the issue with persistence only affects < MariaDB 10.2.4. As we are running a later version presumably the statements have nothing to correct and I need to look elsewhere for a cause? Or is this just a case of the Wiki page needing an update? Thanks and all the best, Chris

1 0

Koha integration with other systems
by Russel G. P. Shihepo 20 Dec '23

20 Dec '23

Dear Community Does Koha support integrations such as: - Centralized Single-Sign-On Integration. - ERP Integration (Student and HRMs). - Payment gateway integration. I have been tasked by our school to make an attempt to integrate Koha with other systems at the institution. Thank you in advance. Regards, Russel

3 4

Debian Upgrade Error: 23.02.04-2 to 23.11.00-1
by skaman.tx＠gmail.com 19 Dec '23

19 Dec '23

Attempting to update Koha installation on Debian Bullseye host from 23.02.04-2 to 23.11.00-1. The following is the output and error message. Any ideas on how to resolve? # apt upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following NEW packages will be installed: koha-l10n The following packages will be upgraded: koha-common 1 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 49.9 MB of archives. After this operation, 31.0 MB of additional disk space will be used. Do you want to continue? [Y/n] y Get:1 http://debian.koha-community.org/koha stable/main amd64 koha-l10n all 23.11.00-1 [32.4 MB] Get:2 http://debian.koha-community.org/koha stable/main amd64 koha-common all 23.11.00-1 [17.5 MB] Fetched 49.9 MB in 14s (3,540 kB/s) Reading changelogs... Done Preconfiguring packages ... /tmp/koha-common.config.bbiGxu: 49: koha-list: not found Selecting previously unselected package koha-l10n. (Reading database ... 182866 files and directories currently installed.) Preparing to unpack .../koha-l10n_23.11.00-1_all.deb ... Unpacking koha-l10n (23.11.00-1) ... dpkg: error processing archive /var/cache/apt/archives/koha-l10n_23.11.00-1_all.deb (--unpack): trying to overwrite '/usr/share/koha/misc/translator/po/am-Ethi-installer-MARC21.po', which is also in package koha-common 23.05.04-2 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Preparing to unpack .../koha-common_23.11.00-1_all.deb ... Unpacking koha-common (23.11.00-1) over (23.05.04-2) ... Errors were encountered while processing: /var/cache/apt/archives/koha-l10n_23.11.00-1_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1)

4 7

Generating fine in every renewal
by JITHIN N 19 Dec '23

19 Dec '23

Dear community We are using Koha 22.11.07. In our Koha circulation rule patron category have maximum 5 time renewal allowed (Renewal Count) with time period of 10 days (Renewal period). In administration menu *Renewal Period Base* is calculated based on old due date of book and for late return every day 1 rupee is calculated as fine. A patron have overdue of a book which is not returned till date with 30 days late, his account shows accruing fine of 30 rupees. when the staff renew the book, along with 30 rupees an amount of 20 rupees creating with a total of 50 rupees. If again renew the book it again generating an amount 10 rupees along with 50 rupees with total of 60. Since the account have already fine till the date why Koha generating fine again based on new due date of renewal. is it a bug or any configuration need to change?

3 3