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

Give a try to RabbitMQ (background jobs rewrite) - POC!
by Jonathan Druart 26 Feb '20

26 Feb '20

Hi devs, I have submited a proof of concept (POC) on bug 22417 (Delegate background jobs execution). The idea would be to isolate our background jobs code (the one in the .pl) into module then use RabbitMQ to process them. More stuffs on the bug! https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22417 Cheers, Jonathan

4 4

Discussion of account types / labels
by Barton Chittenden 01 May '19

01 May '19

The accounts system uses the following codes to show what kind of fee or credit has been issued: A = Account management fee C = Credit F = Overdue fine FOR = Forgiven FU = Overdue, still accruing L = Lost item LR = Lost item returned/refunded M = Sundry N = New card PAY = Payment W = Writeoff The labels, such as 'Account management fee' and 'Overdue fine' are hard coded in various template toolkit files. This is problematic for a number of reasons: 1) It's not obvious where these are defined -- most other constants in Koha are in authorized values. https://koha-community.org/manual/18.05/en/html/faq.html#fines-table is the only place where a koha user can find them all in one place. 2) Because they're not in the database, they can't be used in reports (at least without kludgy case statements). 3) They're not available outside the web interface, so SIP2 and any API endpoints must show the raw codes. 4) 'FU' is a common abbreviation for an obscenity in English, and this has a tendency to show in up in a lot of places where it really shouldn't.

6 7

Serial: numbering patterns: how to make it more clear that months and weekdays start from 0 ?
by Victor Grousset 24 Apr '19

24 Apr '19

Hi :) , That might not be clear, even for developer, and even less for a librarian. How could this info be delivered reliably to the user? To avoid running in circle during too long before realizing that? Even more hard to understand when there are cases like biannual where if you start from February, it will work even if you assumed that January was 1. But if you start from February, there will be issues after one year. Should there be tooltips? The related fields are marked with a red dot in the following screenshot. https://framapic.org/4P2ZzbgJpuvA/SIleKzEuYVaG.png Cheers, -- Victor Grousset, dev support/maintenance BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Libre/Open Source software and services for libraries

3 2

Auto-increment problem has re-emerged
by Bob Birchall 29 Mar '19

29 Mar '19

We're running multiple instances of Koha 18.05.06 installed on stretch from packages. In recent days we've struck the auto-increment problem several times, in relation to issues / old_issues. Known fixes are applied. Is anyone else experiencing this? Thanks, Bob Calyx

4 4

importing from a UNIMARC backup will import biblio records but not items
by giuseppe 26 Mar '19

26 Mar '19

Hello again, today I'm playing the following game (with Koha 18.11.03): 1) create two empty instances, A and B, both in the UNIMARC flavour; 2) populate A with ten bibliorecords, two ones with associated items; 3) create a backup from A so that only UNIMARC records having items are exported; 4) import the backup into instance B; 5) contrary to expectations, see that B now contains two biblio records but no items associated to them. If I inspect the records in the catalog of B, I see that they are void of the field 995 ( https://wiki.koha-community.org/wiki/Holdings_data_fields_%289xx%29#UNIMARC… <https://wiki.koha-community.org/wiki/Holdings_data_fields_%289xx%29#UNIMARC…> ). However, the records staged in the temporary area of B during import phase do have that field. Any suggestions (before I file a bug report)? Thank you, Giuseppe -- Sent from: http://koha.1045719.n5.nabble.com/Koha-devel-f3063671.html

2 1

Critical bug fix to prevent data loss (Bug 22395)
by Nick Clemens 07 Mar '19

07 Mar '19

Hello all, It has been discovered there is a bug in the stable versions of Koha, 18.05.09 and 17.11.15 which can cause quoted text in records to be deleted upon edit/save https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22395 If you have not yet upgraded to the most recent maintenance release please wait a few days as we are releasing a new version to fix the issue. If you are running these versions please be aware of this bug and we will be sending a notice when the new versions are available. Thanks, Nick

2 2

Problems with "LOC" authorized values and tokenization
by David Cook 27 Feb '19

27 Feb '19

Hi all, I have a library with lots of problematic data in their "LOC" authorized value codes, and it's led me to a few issues. 1. LOC authorized values can contain "*", "(", and ")" but all of these characters will cause the ZOOM library to fail to compile the CCL2RPN query. 2. mc-loc (from the "Shelving location" tab on /cgi-bin/koha/catalogue/search.pl) seems to be doing an incomplete search. That means if you have two locations like "Big Box" and "Big Box - Drawer", "Big Box" will return items for both locations. The reason for #2 is actually kind of interesting. While the RPN/PQF query is "@attr 1=8013 @attr 4=1 apple_street" and @attr 4=1 represents a "phrase" search, Zebra is actually using the "w" register and not the "p" register. It's because of the "Completeness Attributes (type = 6)": "Incomplete subfield (1) is the default, and makes Zebra use register type="w", whereas Complete field (3) triggers search and scan in index type="p"." (https://software.indexdata.com/zebra/doc/querymodel-rpn.html) If we wanted to actually just get the exact location, we'd want to use "mc-loc,complete-field", but then we'd get Zebra errors because mc-loc doesn't use the "p" type register currently, although that would be easy enough to add. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595

3 4

zebraidx with 1 large MARC file rather than many small MARC files
by David Cook 27 Feb '19

27 Feb '19

Hi all, I haven't looked into it too deeply, but I was curious if Zebra would have better performance indexing with 1 large MARC file versus many small MARC files. At the moment, we generate 1 huge MARC file and then pass that to zebraidx as an argument. Is that something we've always done or was it done as a performance enhancement? I haven't looked at the Zebra internals to see whether it reads the entire file into memory and then processes it or if it parses the XML using a stream reader. Zebraidx can also take a list of files from stdin*, but if you had tonnes of small files that could be troublesome. I suppose it doesn't matter too much as we march on to ElasticSearch, but I figure lots of people are using Zebra still and probably will for a long time, so perhaps worth thinking about. https://software.indexdata.com/zebra/doc/zebraidx.html David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595

2 3

search result list is void of information
by giuseppe 26 Feb '19

26 Feb '19

Hello all, (already posted on koha-general, but maybe here a better place -- sorry for possible cross postings -- I will file a bug report if nothing happens here too) I've replaced an old Koha 17.11 by a fresh install of Koha 18.11 (on a fresh install of Debian 9.7 64bit). After install, as superlibrarian I successfully populated the DB with sample records including a couple of items, for test purposes. <http://koha.1045719.n5.nabble.com/file/t341209/Screenshot_2019-02-17_17-55-…> Afterwards, as normal user I tried a search for a keyword matching more than one record, and thus I got a list of search results. <http://koha.1045719.n5.nabble.com/file/t341209/Screenshot_2019-02-18_12-38-…> The list is correct, but, as you can see, each entry is void of textual information -- no title/author/etc. . If I click on the "image preview" of one single entry (not visible in the screenshot) I get access to the full info of that entry, which shows correct. But the search results void of textual information is uninformative for a user. This misbehaviour is also present in Koha 18.05 but not in Koha 17.11. Is this just a matter of misconfiguration? What should I do to restore the original behaviour? Thank you. -- Sent from: http://koha.1045719.n5.nabble.com/Koha-devel-f3063671.html

2 1

Limits cannot contain parentheses
by David Cook 26 Feb '19

26 Feb '19

Hi all, I noticed that the CCL2RPN parser throws fatal errors when limits have parentheses in them. I have a fix for it (described at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22344) but it makes for an escaped $limit_cgi and an ugly $limit_desc. It doesn't break anything, but it's not aesthetically pleasing. Would people prefer an ugly fix that is easy to implement, or a more beautiful but difficult to implement fix? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595

2 1