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

Packaging RDF::Trine
by David Cook 12 May '17

12 May '17

Hi all, Magnus and I have been working on a RDF project for Stockholm University Library, and I've been using RDF::Trine for our prototype. It works great overall, although I found a bug with RDF::Trine::Store::SPARQL version 1.016 (most current version on CPAN*). I sent in a pull request yesterday (https://github.com/kasei/perlrdf/pull/147) and the author of the module said that he's hoping to review it and merge it into master in the next few days. But what this means is that we'll be wanting to use the latest version of RDF::Trine, and that's going to be much newer than what is in the Debian repositories for Jessie and Wheezy. I've taken a peek at the code in those repos, and it's buggy too. I seem to recall on https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13642 that there were some issues packaging RDF libraries, but I think it may have mostly related to RDF::Helper, of which we have no need. But Mirko if I could get your input, that would be great. *Actually it seems the latest version in CPAN is newer than master in Github. I'll have to talk to the maintainer about that too. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595

2 3

Authenticate to use Webservices/ Koha API
by Paul Poulain 11 May '17

11 May '17

Hi all, Matthias is working on connecting Koha and Coral, and he's facing some problems with authentication. We need to authenticate and use a session cookie, that's not easy. Could we find another solution ? Should we revive bz 13920 ? (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13920) Suggestions/ideas welcomed ! -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries

3 2

Acquisitions change in Koha 16.11 and forward
by Nick Clemens 10 May '17

10 May '17

Hello All, With the current versions of Koha there have been some changes in acquisitions and how prices are calculated and there seems to be some confusion in terms and how things are currently being used. We wanted to clarify what is happening, propose a change and get feedback on what needs to happen. When placing an order there are several price fields: Vendor price (listprice in db) -This is used to populate the Replacement cost and budgeted cost on the order page. It is not used against the budget Replacement cost (rrp in db) -This is used to calculate the 'budgeted cost/ecost' in the budget - it also populates the replacement price in the item created by the aqc process once received Budgeted cost (ecost in db) -This is the replacement/rpp minus any discount on the order - this is the value that will be encumbered when the order is placed Actual cost (unitprice) -This is the eventual 'price' of the item and is the encumbered amount once the item has been received. With the changes that were made one can no longer adjust the 'Replacement/RRP' once an order is placed - this is because this value is adjusted for tax in the db (rrp_tax_excluded, rrp_tax_included) and used for calculating the ecost tax adjusted (ecost_tax_excluded, ecost_tax_included) Some libraries have been having issues as they use 'Replacement' cost mostly for populating items and are not used to it being unable to be edited and/or affecting budgets. We are proposing to rename the current 'Replacement cost' field to match the db value - 'Recommended retail price' (RRP) and add a new 'Replacement cost' field, editable at any point, that is only used for populating the item field. We think this will clear up how the other values are being used and restore functionality that changed. Please let us know if this works or what other suggestions you have here. Thank you, Nick, Kyle, Jonathan

4 3

Communication - Extra meeting on May 10th, 13UTC
by Jonathan Druart 09 May '17

09 May '17

Hello, I'd like you to take a look at the following pad: https://mensuel.framapad.org/p/build_task_force_Koha_1711 Following what I announced in the RM proposal I will send an email to the different actors of the community. I'd like to get your opinion on the content. I propose to discuss it (quickly because we have patches to test!) for agreement tomorrow May 10th 13UTC https://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+I… If we need more time to reach a consensus or if there are strong objections we could rethink the whole thing and vote later. Cheers, Jonathan

1 0

Koha 16.05.12 released
by Mason James 09 May '17

09 May '17

The Koha community is proud to announce the release of Koha 16.05.12. This is a maintenance release of 16.05 and includes 49 bugfixes. The full release notes are available at https://koha-community.org/koha-16-05-12-release/ Packages will be available soon.

2 1

Single character searches are slow when queryfuzzy and/or querystemming are enabled.
by Barton Chittenden 09 May '17

09 May '17

I've got an issue that we've seen periodically at ByWater; I want to file a bug, but I don't have a clear idea of how to replicate the issue, so I'm trying to solicit information from the community on how to narrow the scope of the problem and/or measure the performance problems that I'm seeing. The problem is that keyword searches (as you'd see from an un-modified masthead search on the opac, or the "search the catalog" search on the staff client) are markedly slow on some sites when a) The search term contains single letter words like "a" in "Once Upon A Time" and b) One or both of the QueryFuzzy or QueryStemming system preferences is enabled. We first ran across this issue when we moved a number our Koha instances to slower drives, and found that some (but not all) would time out when searching for "Once upon a time", "A swiftly tilting planet", "Hitchiker's Guide to the Galaxy" (where the 's' after the apostrophe is counted as a single word). I turned on 'request' logging in zebra, here's the query that timed out: find @attrset Bib-1 @or @or @or @or @or @or @attr 1=36 @attr 4=1 @attr 6=3 @attr 9=32 @attr 2=102 "once upon a time" @attr 1=4 @attr 4=1 @attr 6=3 @attr 9=28 @attr 2=102 "once upon a time" @attr 1=36 @attr 4=1 @attr 9=26 @attr 2=102 "once upon a time" @attr 1=4 @attr 4=6 @attr 9=24 @attr 2=102 "once upon a time" @attr 4=6 @attr 5=103 @attr 9=16 @attr 2=102 "once upon a time" @attr 4=6 @attr 5=1 @attr 9=14 @attr 2=102 "onc? upon? a time? " @attr 4=6 @attr 9=14 @attr 2=102 "once upon a time" Sent searchRequest. I ran the PQF in zebra: Z> base biblios Z> find @attrset Bib-1 @or @or @or @or @or @or @attr 1=36 @attr 4=1 @attr 6=3 @attr 9=32 @attr 2=102 "once upon a time" @attr 1=4 @attr 4=1 @attr 6=3 @attr 9=28 @attr 2=102 "once upon a time" @attr 1=36 @attr 4=1 @attr 9=26 @attr 2=102 "once upon a time" @attr 1=4 @attr 4=6 @attr 9=24 @attr 2=102 "once upon a time" @attr 4=6 @attr 5=103 @attr 9=16 @attr 2=102 "once upon a time" @attr 4=6 @attr 5=1 @attr 9=14 @attr 2=102 "onc? upon? a time? " @attr 4=6 @attr 9=14 @attr 2=102 "once upon a time" Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 119, setno 1 SearchResult-1: term=once upon a time cnt=3, term=once upon a time cnt=5, term=once cnt=94, term=upon cnt=63, term=a cnt=4876, term=time cnt=515, term=once cnt=168, term=upon cnt=125, term=a cnt=19801, term=time cnt=1507, term=once cnt=9830, term=upon cnt=960, term=a cnt=82237, term=time cnt=8524, term=onc cnt=1915, term=upon cnt=914, term=a cnt=82237, term=time cnt=7709, term=once cnt=1302, term=upon cnt=914, term=a cnt=68283, term=time cnt=5442 records returned: 0 Elapsed: 98.163583 The elapsed time is just under 100 seconds; I think Koha times out after 60. We looked at the disk I/O and found that the disk where the searches were occurring was getting hammered, so we migrated the sites that were having issues onto a server that had a much faster drive, and this did, at least solve the time-out issue. The issue keeps on popping up, however -- if not in actual timeouts, then at least in complaints of slowness in search. My hypothesis is that either QueryFuzzy or QueryStemming is expanding the one letter words, i.e. a search for "a" is returning results for either all words that start with "a" or all words contaning "a", and that all of these results are written to disk before any further filtering is done. When we were seeing timeout issues, I'm not clear on which sites were likely to have issues -- sites with a very small number of bibs didn't have issues, but the problem wasn't solely by collection size. So here's what I'd like to know, for the purposes of further testing, and/or to be able to replicate the issue: 1) Is there anyone who knows all about PQF who can tell me why the query above would run so slowly? 2) Is there part of the PQF that seems to be behaving particularly badly? Which parts of the query are returning "term=a cnt=82237", and can we avoid having that called twice? 3) How do I go about constructing a data set that illustrates this problem? 4) What's the best way to measure the performance problems and/or define what the problem is when I file a bug? 5) Are there any work-arounds, given that certain sites really want query stemming and queryfuzzy enabled? Thanks, --Barton

2 1

The interface "winks" when I check out a book after upgrading firefox
by Francois Charbonnier 05 May '17

05 May '17

Hi, I use Koha 16.05 and firefox 53. When I check out an item, the interface "winks". I tried this with firefox 52, the interface stays still. Have you noticed it as well ? Any advice to fix it ? Thanks! -- François Charbonnier, Bibl. prof. / Chef de produits Tél. : (888) 604-2627 francois.charbonnier(a)inLibro.com <mailto:francois.charbonnier@inLibro.com> inLibro | Spécialistes en technologies documentaires | www.inLibro.com <http://www.inLibro.com>

3 4

Koha and xhtml2pdf
by Fridolin SOMERS 05 May '17

05 May '17

Hie. We have some problems with xhtml2pdf on Ubuntu Xenial. This soft is used by misc/cronjobs/printoverdues.sh. First it is strange that the package containing this soft "python-pisa" is not in koha-deps. I see there is "html2pdf" but there is no CSS option. In jessie we have to use the jessie-backports repo and install several packages : python-pisa python3-reportlab python-html5lib python-pypdf python-imaging python-renderpm python-reportlab python-reportlab-accel On ubuntu Xenial, we install those same packages but we have a bug in python call. We found it can be corrected by installing xhtml2pdf from its GIT repo. We would prefere to avoid this. Any help is welcome. Best regards, -- Fridolin SOMERS Biblibre - Pôles support et système fridolin.somers(a)biblibre.com

4 5

Global Bug Squashing Day - Bugs Only Edition! Wednesday, May 10th, 2017
by Nick Clemens 05 May '17

05 May '17

Hi All, A reminder / update - next week will be a GBSD dedicated to squashing bugs for the upcoming 17.05 release. I added a wiki page here: https://wiki.koha-community.org/wiki/2017-05-10_Global_bug_squashing_day_-_… ! I will be adding some bugs there and trying to keep status up to date as I can but please help out, list bugs you want to work on/are working on, add comments/sections or make the page more attractive :-) We want community involvement so if you have been thinking of getting involved this is a great time. I will be available in IRC as long as I can that day, feel free to ping me. If you are a seasoned community member and can help please add your name to the 'hand holders' list on the wiki I hope to see you all around, hear lots of questions, and see lots of squashing :-) -Nick

3 3

Jenkins is down
by Mason James 04 May '17

04 May '17

hi Folks would someone please fix jenkins specifically the debian_8 node https://jenkins.koha-community.org/computer/Debian_8/ thanks, Mason

2 1