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

Interlibrary Loans RFC
by Alex Sassmannshausen 16 Mar '15

16 Mar '15

Hello, I've now been able to draft a first version of an Interlibrary Loans Module for Koha RFC. You can find it at http://wiki.koha-community.org/wiki/ILL_Module. For the purposes of this work I have usurped bug number 7317. The RFC is based on work that I, as part of PTFS Europe am carrying out for our customers, and on discussions that we had at the hackfest. There are 2 primary concerns for this module from my perspective: 1) provide all the functionality our customers require 2) make the module generic enough so that we can implement different 'backends' that would service different ILL workflows/systems. Feedback (both on style and content), welcome. Best wishes, Alex

2 1

Upgrade path for packages
by Tomas Cohen Arazi 16 Mar '15

16 Mar '15

We still need to fix our packaging schema in which people are forced to jump into .0 releases because of our repository naming schema. I propose we step forward and create "3.18", "3.20" and so on, instead of just "stable", "oldstable", etc. This way no one will be forced to jump into another major release. "stable" "oldstable" and "testing" might still be usable as they are now, nothing prevents a .deb package from populating more than one slot. Or even of symbolic links... Some of you expressed your concerns about "people indefinitely using obsolete/insecure releases". I propose that once a release goes "unmaintained" [1] a "last" release/package adding a red-notorious warning message on the intranet footer is pushed stating that the release is no longer maintained and provinding a link for upgrade instructions. I hope we can fix this once and for all soon. [1] unmaintained = it has no release maintainer on some "Roles for XX" vote. -- Tomás Cohen Arazi Prosecretaría de Informática Universidad Nacional de Córdoba ✆ +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F

5 4

Hello, new BibLibre intern presentation
by Julian FIOL 13 Mar '15

13 Mar '15

Hi everyone, I'm Julian FIOL, the new intern of BibLibre for 6 months. I'm going to work on Koha. My mission is to implement new unit tests, and probably other things in a couple of weeks Thanks, My IRC : Jul / Jul- / Jul_

3 2

Overdrive authentication dialogue
by Bob Birchall 13 Mar '15

13 Mar '15

We've recently configured Overdrive integration for a client. It works very well and the client is getting positive feedback from members. There is a shortcoming in the authentication dialogue, where incorrect credentials are offered. 1. Where a correct cardnumber is entered with an incorrect password, Koha's SIP server responds with '(1) Greetings from Koha.' 2. Where an incorrect cardnumber is entered (with any password), the SIP server responds with a blank message: '(1) ' These are displayed on an Overdrive page which includes a link: 'Click here to return to the sign in form' but there is nothing to draw the user's attention to their error and the need to follow that link back to try again. Where correct credentials are offered, Overdrive redirects to the users' Overdrive account page and no messages from Koha are displayed. We propose to replace these messages with 'You have entered an incorrect cardnumber or password. Please try again.' This will appear just above the 'Click here to return ...' link and should make the process obvious for the user. Before I add this to bugzilla, has anyone seen this issue or have any thoughts on it? Have we missed anything? Thanks, Bob

3 2

TTF mapping on koha-conf.xml breaks Patron Card Creator
by Pablo Bianchi 10 Mar '15

10 Mar '15

Hi, I move a production server from A to B: A) An "old" Debian Wheezy upgraded up to current 3.18.4. B) A new Ubuntu Server 14.4 LTS fresh install, also 3.18.4. On A the librarian use fine the unfriendly label creator but on B the generated label was blank (only images). Database where identical so I start looking logs and setup files. The "solution" was just comment out the new XML section *<ttf>* on koha-conf.xml. + I'm not sure what this section does, what I'm disabling. + I'm not sure if is related to bug 13709 <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13709>. + Even logs where full of things like «Argument "377,33" isn't numeric in addition» and «Use of uninitialized value» It seems have nothing to do with the use of comma or dot as decimal separator on (not sanitized?) input fields. I attach the output of something like *cat intranet-error-cleaned.log | sort | uniq -c | sort -rn* Regards, Pablo

2 2

General IRC meeting 11 March 2015
by Magnus Enger 10 Mar '15

10 Mar '15

Kia ora Community! Just a small reminder that there is a general community IRC meeting in just about 24 hours: 11th March 2015 at 10:00 UTC Date and time conversion: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+IRC+General+M… See ya there! Best regards, Magnus Enger

1 0

Re: [Koha-devel] biblioitems marc and marcxml
by Paul A 07 Mar '15

07 Mar '15

At 08:32 PM 3/6/2015 -0500, Christopher Nighswonger wrote: >On Fri, Mar 6, 2015 at 8:20 PM, Paul A ><<mailto:paul.a@navalmarinearchive.com>paul.a(a)navalmarinearchive.com> wrote: >>[snip] All these marc(xml) errors originate back in 2011 (some 3.2, some >>3.4 according to items.datelastseen.) > >Have a look at this script: > ><http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=misc/maintenance/…>http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=misc/maintenance/… > >Maybe it will help you clean things up. Chris -- just what the doctor ordered, thank you much indeed. This has solved the problem of advanced search picking up erroneous shelving locations. For the completeness of the record, here are my notes: *** a) determine if biblioitems.marc(xml) includes item data mysql> SELECT items.biblioitemnumber AS BiblioNum,items.barcode AS BarCode,items.datelastseen AS Date,items.location AS Shelf952c, ExtractValue(marcxml,'//datafield[@tag="952"]/subfield[@code="c"]') AS ShelfMARCxml FROM items LEFT JOIN biblioitems ON (items.biblioitemnumber=biblioitems.biblioitemnumber) WHERE ExtractValue(marcxml,'//datafield[@tag="952"]/subfield[@code="c"]') != '' ORDER BY Date; +-----------+---------------+------------+-----------------------+------------------+ | BiblioNum | BarCode | Date | Shelf952c | ShelfMARCxml | +-----------+---------------+------------+-----------------------+------------------+ | 43 | 1MESL09120001 | 2011-03-10 | merchant | box_rr24 | | 460 | 1MEGN09120015 | 2011-03-10 | merchant | box_rr39 | | 470 | 1MEGN09100005 | 2011-03-10 | box_rr_fl3 | box_rr_fl3 | | 476 | 1NVUS00070001 | 2011-03-10 | navy RCN | navy | | 486 | 1BIOL03010001 | 2011-03-10 | oceanography | biology marine | | 490 | 1181200090002 | 2011-03-10 | 2fl_rare | rare | /.../ +-----------+---------------+------------+-----------------------+------------------+ 8337 rows in set (0.91 sec) *** b) optionally, manually verify a few biblios N.B. Formats better for fast check as a Koha saved report: SELECT * FROM biblio RIGHT JOIN biblioitems ON biblio.biblionumber=biblioitems.biblionumber LEFT JOIN items ON biblio.biblionumber=items.biblionumber WHERE items.biblionumber = <<Pick your biblio number>> or CLI (well snipped): mysql> SELECT marc,marcxml FROM biblioitems WHERE biblionumber=43; +----------/.../---+ | 00667nam a2200193Ia 450000100030000000300090000300800410001202000150005304000240006810000200009225000060011226000330011830000130015165000390016494200100020324500800021395201690029399900110046243CaOPIACS110310t19781978xx 000 0 und d a0395264499 aOPIACSbENGcOPIACS1 aAdkins, Jan999 a1 bHoughton Mifflinc1978g1978 bb/w 3hb 7aMerchant ships - sail2OPIACS9101 cBK2z10aWooden Ship :bthe building of a wooden sailing vessel in 1870cAdkins, Jan 40xvg/vg/mylar ex-liberr00943bOPIACS10d20091215zjunior: good pencil sketches, construction of an imaginary whaler8merch_sail71cbox_rr24g30.00yBKaOPIACS c43d43 | <?xml version="1.0" encoding="UTF-8"?> <record xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" /.../ <datafield tag="952" ind1=" " ind2=" "> <subfield code="4">0</subfield> <subfield code="x">vg/vg/mylar ex-lib</subfield> <subfield code="e">rr</subfield> <subfield code="0">0</subfield> <subfield code="9">43</subfield> <subfield code="b">OPIACS</subfield> <subfield code="1">0</subfield> <subfield code="d">20091215</subfield> <subfield code="z">junior: good pencil sketches, construction of an imaginary whaler</subfield> <subfield code="8">merch_sail</subfield> <subfield code="7">1</subfield> <subfield code="c">box_rr24</subfield> <subfield code="g">30.00</subfield> <subfield code="y">BK</subfield> <subfield code="a">OPIACS</subfield> </datafield> <datafield tag="999" ind1=" " ind2=" "> <subfield code="c">43</subfield> <subfield code="d">43</subfield> </datafield> </record> | +----------/.../---+ 1 row in set (0.00 sec) *** c) Remove item data from biblioitems.marc(xml) koha@hood:/usr/share/koha/bin/maintenance$ ./remove_items_from_biblioitems.pl --run *** d) Verify: mysql> SELECT items.biblioitemnumber AS BiblioNum,items.barcode AS BarCode,items.datelastseen AS Date,items.location AS Shelf952c, ExtractValue(marcxml,'//datafield[@tag="952"]/subfield[@code="c"]') AS ShelfMARCxml FROM items LEFT JOIN biblioitems ON (items.biblioitemnumber=biblioitems.biblioitemnumber) WHERE ExtractValue(marcxml,'//datafield[@tag="952"]/subfield[@code="c"]') != '' ORDER BY Date; Empty set (0.55 sec) Again, many thanks and best regards, Paul

1 0

Re: [Koha-devel] biblioitems marc and marcxml
by Paul A 07 Mar '15

07 Mar '15

At 12:52 AM 3/6/2015 +0000, Tomas Cohen Arazi wrote: >I'm not sure what you're trying to do, but items are no longer inserted >into marcxml, and to shouldn't be using 3.8. At all. And at 12:10 PM 3/6/2015 +1100, Bob Birchall wrote: [snip] Items data were removed from the marcxml for performance reasons, at Koha 3.4. Any version above 3.2 should have no 952 data in the marcxml. Tomás, Bob -- thank you both. I've found time to look deeper into this, and discovered (to my dismay) that these are pre-3.4 remnants. I had totally forgotten that we started looking at Koha in March 2011 (just before 3.4.0 the following month, with about 10,000 records from oOo via MarcEdit), migrated through 3.4, 3.6 to current 3.8. All these marc(xml) errors originate back in 2011 (some 3.2, some 3.4 according to items.datelastseen.) >The routines that take care of that are on C4::Biblio btw. Yes -- I had looked at that (see my 2nd para below) -- the "redeeming" factor is that re-saving the *biblio* corrects the marc(xml) (editing items retains the error, adding items propagates the error.) I'm not sure if I can automate the corrections required (export/delete/re-import?) -- at worst, I'll have to set things up for our volunteers to open each biblio and re-save. Then I'll try to repeat the speed tests on 3.18 and see if this makes any difference. At the moment we've decided to stay with 3.08.24 because of the performance (our priorities as a non-lending library do not require all the other very positive improvements to 3.18) Again thanks and warmest regards -- Paul >El vie., 6 de marzo de 2015 0:10, Paul A ><<mailto:paul.a@navalmarinearchive.com>paul.a(a)navalmarinearchive.com> >escribiÃ³: >Good morning|evening to you all. I'm looking for some help please for a >problem [1] that has surfaced concerning "advanced search" (OPAC and staff) >by "Shelving location" and by "Collection Code". > >I can't find an bugs relating to this. ><<http://perldoc.koha-community.org/C4/Biblio.html>http://perldoc.koha-community.org/C4/Biblio.html> >states: >When dealing with items, we must : >/.../ >3. overwrite the MARC record (with the added item) into biblioitems.marc(xml) > >but I can't easily find where or how marc(xml) gets *updated*...Â and I'm >not even certain that this is not an "error" left over from 3.6 two years ago > >I can do a certain amount directly in MySQL (painstaking >UPDATE...SET...REPLACE), but additionally, we have many >biblioitems.marc(xml) which do *not* contain 952$c or $8 data at all. Since >upgrade to 3.8? if 3.6 didn't put them there, I have no idea how they got >there ;={ > >Importantly, should 952$c and 952$8 even be present in >biblioitems.marc(xml)? (The advanced search uses these apparently unedited >data in preference to items.location and items.ccode) > >Is there a routine/utility to do this? > >[1] Most of our cataloging is done into "boxes" at 952$c level using a >provisional 952$8 (CCODE); then a different volunteer does the final >shelving, edits the 952$c and possibly modifies the CCODE -- e.g. a book >from "box_rr198" gets put onto the "engineering" shelf rather than "navy". >This is accurately reflected by all searches (I think) except by the >advanced options "Shelving location" and "Collection" which appear to rely >primarily on biblioitems.marc(xml) neither of which is being updated by >saving the edit to "items" or in new items in 3.8 > >Many thanks -- Paul --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

2 1

biblioitems marc and marcxml
by Paul A 06 Mar '15

06 Mar '15

Good morning|evening to you all. I'm looking for some help please for a problem [1] that has surfaced concerning "advanced search" (OPAC and staff) by "Shelving location" and by "Collection Code". I can't find an bugs relating to this. <http://perldoc.koha-community.org/C4/Biblio.html> states: When dealing with items, we must : /.../ 3. overwrite the MARC record (with the added item) into biblioitems.marc(xml) but I can't easily find where or how marc(xml) gets *updated*... and I'm not even certain that this is not an "error" left over from 3.6 two years ago I can do a certain amount directly in MySQL (painstaking UPDATE...SET...REPLACE), but additionally, we have many biblioitems.marc(xml) which do *not* contain 952$c or $8 data at all. Since upgrade to 3.8? if 3.6 didn't put them there, I have no idea how they got there ;={ Importantly, should 952$c and 952$8 even be present in biblioitems.marc(xml)? (The advanced search uses these apparently unedited data in preference to items.location and items.ccode) Is there a routine/utility to do this? [1] Most of our cataloging is done into "boxes" at 952$c level using a provisional 952$8 (CCODE); then a different volunteer does the final shelving, edits the 952$c and possibly modifies the CCODE -- e.g. a book from "box_rr198" gets put onto the "engineering" shelf rather than "navy". This is accurately reflected by all searches (I think) except by the advanced options "Shelving location" and "Collection" which appear to rely primarily on biblioitems.marc(xml) neither of which is being updated by saving the edit to "items" or in new items in 3.8 Many thanks -- Paul

3 2

Web services only of authenticated users [C4::Service]
by Zeno Tajoli 05 Mar '15

05 Mar '15

Hi to all, today, working on do a metsearch for Opac, I have found that web service basic API (C4::Service) could be used only from authenticated users. In fact with C4::Service->init(<permission to check>); it is mandatory to insert a permission that is checked in C4::Auth check_api_auth. The check is done on the user that is logged in the browers that does the request. If you do the request from the opac without be logged, the answer could be only: {"type":"auth","message":"failed"} We have a web service that work without authentication ,it is opac/svc/report. But it doesn't use C4::Service. I think it is an important topic to know if we want to use more a central web service infrastructure. Bye

3 2