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

Putting Koha into Docker...
by Mark Tompsett 25 Aug '17

25 Aug '17

Greetings, I’ve been tasked to dockerize our Koha installation, and I noticed https://github.com/digibib/koha-docker I also noticed it said “www.koha.org” on https://github.com/digibib/koha-docker/wiki even though the code says, “echo "deb http://debian.koha-community.org/koha stable main" > /etc/apt/sources.list.d/koha.list” on https://github.com/digibib/koha-docker/blob/master/Dockerfile So, I’m confused if this is usable for production and it is is Koha or LibLime. Feedback, thoughts much appreciated. GPML, Mark Tompsett

6 5

REST api / pagination
by Tomas Cohen Arazi 25 Aug '17

25 Aug '17

Hi there, I'm currently implementing a couple endpoints for acquisitions-related stuff and also QAing existing patches introducing endpoints. One of the things that need to be done (which I did for my own endpoint for vendors / bug 18120) is migrating them to Mojolicious::Plugin::OpenAPI instead of (the deprecated) Mojolicious::Plugin::Swagger2. I noticed there's lack of a generic way to deal with pagination. There are a couple options we could consider, but I would like to hear the opinion of UI people, which are the ones that will take advantage or suffer what we do on the backend :-D a) GET /patrons?page=1&per_page=3 => [ {borrower1}, {borrower2}, {borrower3} ] b) GET /patrons?offset=0&limit=3 => [ {borrower1}, {borrower2}, {borrower3} ] Lari proposed another one, which tackles an issue we could have on the UI (knowing the total, calculating pages, etc): c) GET /patrons?page=1&per_page=3 { total: 50000, results: [ {borrower1}, {borrower2}, {borrower3} ] } (c) has the problem that it would mean we need to change the current resposes for list operations on the already implemented endpoints. I'm not sure at this point we would need to shift api version (v2?), I would vote against, but here we have the chance to hear people using the API. Looking forward to your comments as my current dev work completion depends on it :-D -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

5 8

Koha Developers IRC meeting reminder - Today August 23th, 14 UTC
by Jonathan Druart 23 Aug '17

23 Aug '17

Hi, We have a Developers meeting in IRC scheduled for today at 14 UTC (in ~1hour) Local time/date conversion here: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+I… The agenda is here: https://wiki.koha-community.org/wiki/Development_IRC_meeting_23_August_2017 Jonathan

1 0

What's on in koha-devel #14
by Jonathan Druart 21 Aug '17

21 Aug '17

Hello librarians and developers, The what's on in koha-devel #14 is available on the Koha website: https://koha-community.org/whats-on-in-koha-devel-14 Regards, Jonathan

12 19

Call for News: August 2017 Newsletter
by kohanews 16 Aug '17

16 Aug '17

I'm collecting news for the August newsletter. Send anything noteworthy to: k o h a news AT gmail dot com News criteria: --------------------------- ** For events **: - Please include dates for past events. If I can't find dates I may not add it. - Announcements for future events with dates T.B.A. are fine ...Eg., Kohacon - For past events , **** one month back is the cut-off ****. * News items can be of any length. * Images are fine * Anything and everything Koha. * Submit by the 26th of the month. If you are working on an interesting project or development related to Koha, please let me know and I'll include it in the development section. Thank you! -- Chad Roseburg Editor, Koha Community Newsletter

1 0

Indic language conjunct clusters printed incorrectly in spine label
by Indranil Das Gupta 12 Aug '17

12 Aug '17

[CROSS-POSTING] Hi all, This is w.r.t. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19084 (there is a screenshot on the bug showing the problem) This problem seems to be present for most Indian languages whenever they have conjunct clusters in their call numbers (depicted as grapheme clusters in an unicoded string). To describe the problem simply - the order of chars rendered is incorrect in the output. For example the string - "শেখর" is represented by the following code points - \x{09B6}\x{09C7}\x{0996}\x{09B0}. Now here is the catch: \x{09B6} represents the bengali letter SHA, whereas \x{09C7} represents the bengali vowel sign E; however in the correct linguistic visual presentation, the vowel sign E sits before the SHA, which is not how the codepoints are arranged in the unicode string. I looked around PDF::Reuse, Text::PDF::TTFont etc modules, what seems to me to be the root of this problem is the unpacku() method which is pushing the unicode characters into an array in order to introduce them into the PDF content stream with the correct font information. However, being pushed in in that order, I think may be the cause of this problem, which would make this an upstream issue rather than a Koha bug. Your inputs / feedback on this would be greatly appreciated. cheers indranil PS. I am aware of the "CLOSED WONTFIX" status of bug id 2246 ;-) -- Indranil Das Gupta L2C2 Technologies Phone : +91-98300-20971 Blog : http://blog.l2c2.co.in IRC : indradg on irc://irc.freenode.net Twitter : indradg

1 0

Not listed my question?
by Librarian Guide 11 Aug '17

11 Aug '17

Dear Admin, I have sent many times my questions and doubts to clarify on forum but none of them have been posted. Please let me know why it is so? -- With kind regards, ************************************ *Dhanwantari Prakash Tripathi* ************************************ *Assistant Librarian, Periodicals* Biju Patnaik Central Library <http://library.nitrkl.ac.in> National Institute of Technology <http://nitrkl.ac.in> Rourkela, Odisha - INDIA *- 769 008* *M - +91-8895296796* *U - www.dptripathi.in <http://www.dptripathi.in> * *YouTube - Librarian Guide <https://www.youtube.com/channel/UCqq2XkD5KKp5W7VrMJOsGhw>* ************************************

1 0

MARC frameworks in Koha
by Marcel de Rooy 10 Aug '17

10 Aug '17

Hi developers or librarians, If you are interested in say sorting search results or lists by publication date based on 260 and RDA 264, please read further. OR If you use varying kohafield mappings across your MARC frameworks. Say you connected biblio.copyrightdate to 260$c in framework A, but to 264$c in framework B. Bug 10306 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306) is aimed to resolve the issue of having the copyrightdate in two MARC fields. It allows you to have multiple mappings per kohafield. So you can connect 260c and 264c to copyrightdate. Current Koha allowed you to add the second mapping already in the frameworks, but it silently ignores one of the two. In finishing this development however, I got stuck at the following question: Should Koha really allow varying kohafield mappings per framework? In the above example the multiple mappings feature should resolve the need of having a different assignment for copyrightdate between framework A and B. Both could simply have two mappings for copyrightdate. Although Koha more or less allows you to add kohafield assignments per framework via the MARC frameworks, it does not really support kohafields per framework. (The Koha to MARC mappings tool in Administration does change the mappings in Default and copies them to other frameworks.) We have GetMarcFromKohaField calls in the codebase that do not pass a framework code. And when we process search results or import records, we do not have a framework code either. So in those cases Koha just uses the kohafield mappings from the Default framework, although you might have specified another mapping in the associated framework of a search result. I would propose now to make the decision that we only use one set of kohafield mappings (those from Default), and that we do no longer allow changes to kohafield mappings in the other frameworks. The possibility of adding multiple mappings per kohafield hopefully removes most objections to that approach as illustrated in the frameworks A and B example. I submitted my changes so far on the Bugzilla report. If we agree on Default as the authoritative framework for these mappings, I will still add code to change GetMarcFromKohaField calls etc. If you have stringent reasons for maintaining varying kohafield mappings per framework and your need for them cannot be resolved with multiple mappings, please respond and provide information about the fields you are mapping differently across your frameworks. Any other feedback is welcome too. Thanks, Marcel

4 8

Koha Developers IRC meeting reminder - Today August 9th, 22 UTC
by Jonathan Druart 09 Aug '17

09 Aug '17

Hi All, My apologies for late reminder, we have a Developers meeting in IRC scheduled for today at 22 UTC (in ~1hour) Local time/date conversion here: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+I… The agenda is here: *https://wiki.koha-community.org/wiki/Development_IRC_meeting_9_August_2017 <https://wiki.koha-community.org/wiki/Development_IRC_meeting_9_August_2017>* Please add any topics you wish to discuss to the agenda, or add yourself in to the apologies if you can't make it. Hope to see you all there! Nick^WJonathan

1 0

AUTO_INCREMENT fix - prevent data lost
by Jonathan Druart 09 Aug '17

09 Aug '17

Hi devs, Please review and test https://wiki.koha-community.org/wiki/DBMS_auto_increment_fix I have added a ref from the Koha on Debian wiki page https://wiki.koha-community.org/wiki/Koha_on_Debian#Further_Configuration It sounds like I should add it somewhere more visible, but do not find where, any ideas? See also bug 18931 where I would like to add a warning on the about page if data are corrupted. Please review quickly, that way we can share the tips on the general mailing list. Cheers, Jonathan

8 18