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

Hackfest in Marseille (last call, some news)
by Paul Poulain 28 Sep '16

28 Sep '16

Hi all, 63 persons have registred to the hackfest, in 2 weeks. People will come from 13 different countries: Argentina 1 Belgium 1 CZ 1 France 41 Germany 2 Italy 3 Norway 2 NZ 1 Sweden 1 Switzerland 1 UK 3 USA 6 Grand Total 63 And they'll represent 33 institutions: AARome 2 ACPL 1 Admin Kuhn 1 Arts-UK 1 BDP Meuse 2 BibLibre 17 Bleone-Verdon 2 BSZ 1 BULAC 2 ByWaterSolutions 5 CIRAD 2 ENS Cachan 1 IEP Grenoble 1 Koha 1 Libriotech 1 Living Libraries 1 Mines Paristech 1 Mirko Tietgen 1 Musée histoire immigration 1 Organisation 1 Oslo Public Library 1 PTFS-Europe 3 PUSC 1 R-Bit Technology, s.r.o. 1 Roubaix 1 SAN-OP 1 Sciences po Grenoble 2 SUB Stockholm 1 Theke 1 Univ Aix Marseille 3 Univ Lyon 3 1 Univ Paris 8 1 Université Lyon 2 1 Grand Total 63 It's still time to add your name, your country and/or your organization if you want ! -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries

1 0

Re: [Koha-devel] Improving the API for record imports (Tomas Cohen Arazi)
by Benjamin Rokseth 28 Sep '16

28 Sep '16

Hi, Tomas and David, we have already implemented and are using a biblio CRUD endpoint, and I know the Finland community has, too. Sorry for not starting with a koha bug, but we simply didn't have the time... Now, we would very much like to add /change this to a Koha native bug, but for now, heres our local patch: https://github.com/digibib/koha-docker/blob/master/koha-patched/patches/130… which is based on koha master. Mainly, it reproduces the svc/biblio endpoint using marcxml for add/update, and some other expansions for GETting an expanded record with items. It was quite easy to implement using Koha Objects. Please don't hesitate to shoot us, I mean, ask us for more! Benjamin Rokseth Oslo Public Library ________________________________________ Fra: koha-devel-bounces(a)lists.koha-community.org <koha-devel-bounces(a)lists.koha-community.org> på vegne av koha-devel-request(a)lists.koha-community.org <koha-devel-request(a)lists.koha-community.org> Sendt: 27. september 2016 12:00 Til: koha-devel(a)lists.koha-community.org Emne: Koha-devel Digest, Vol 130, Issue 56 Send Koha-devel mailing list submissions to koha-devel(a)lists.koha-community.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel or, via email, send a message with subject or body 'help' to koha-devel-request(a)lists.koha-community.org You can reach the person managing the list at koha-devel-owner(a)lists.koha-community.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Koha-devel digest..." Today's Topics: 1. Re: Improving the API for record imports (Tomas Cohen Arazi) ---------------------------------------------------------------------- Message: 1 Date: Mon, 26 Sep 2016 12:56:20 +0000 From: Tomas Cohen Arazi <tomascohen(a)gmail.com> To: David Cook <dcook(a)prosentient.com.au>, Koha Devel <koha-devel(a)lists.koha-community.org> Subject: Re: [Koha-devel] Improving the API for record imports Message-ID: <CABZfb=WGH0gCH5veYjHmQEc4n1t+eoLsUmtUwMRceqW3tksLsA(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" David, I agree with your ideas. Having a REST endpoint handling records would be awesome improvement. I'll hapilly sign or QA those patches. Regards El mi?., 21 sept. 2016 a las 22:00, David Cook (<dcook(a)prosentient.com.au>) escribi?: > Hi all, > > > > I want to improve the API(s) for importing (bibliographic) records. > > > > But I?m not 100% sure how to go about what criteria to use to gauge > ?improvement?. Here are some ideas: > > > > ? I think the REST API offers up one obvious addition and that?s > DELETE. It would be great to delete records using the API. I?ve found this > mostly thanks to OAI-PMH where you get a notice when a record has been > deleted upstream and needs to be deleted from Koha too. > > o The difficulty in deleting bibliographic records is items. If there > are items, it blocks the delete. You could auto-delete items, but you can?t > if there are holds or if it?s currently issued. At best, you could return a > failed delete via the API, I think. > > > > ? I keep thinking that ?import profiles? could be a good way to > go too. This might include a MARC Modification Template, it might be a > XSLT, it might be a Koha::Filter. It would let you turns your incoming > metadata from format A to format B. > > o This would also allow you to POST a minimum amount of data to the > API. You?d have your metadata record and your import profile code. > > ? The downside of this is the POST wouldn?t detail the options for the > import, and those imports would be more obfuscated. Changes to a profile > could also impact subsequent imports unintentionally. > > o I?m not sure how batches would work with filtering. You might have > 50/100 records filter correctly and import, but that leaves 50 which aren?t > imported. Do you undo the whole import, or do you fix your filter, and then > re-import the first 50 alongside the first time import of the last 50? > > > > ? The original metadata would be stored regardless of metadata > format (e.g. marcxml, mods, rdf, dc, etc.) for historical purposes or to > allow re-filtering in the event that a filter fails to correctly transform > a record to valid MARCXML (or whatever internal metadata format Koha uses). > > > > ? The import source and the type of import would be stored (ie > http://oai-server.com and ?oai-pmh?, lx2.loc.gov and ?z3950?, <insert > relevant source> and ?oclc connexion?, etc.). > > o I think this would be helpful for managing/processing a certain type > of import, perhaps also in terms of matching records. > > o At the moment, with my work on #10662, I have a separate table > ?import_oai? which obviously is for records imported via oai-pmh only. I > don?t actually track the origin due to how I currently source the imports, > but I could do it in the future. > > > > ? Storing some sort of identifier would be good > > o OAI-PMH records have unique identifiers for the records > > o Z39.50? that?s tougher since it?s not a specific metadata format like > the OAI-PMH format. So I don?t know about this one. > > > > Anyway, these are just some ideas I?ve been having. They?re not fully > formed by any stretch of the imagination. > > > > David Cook > > Systems Librarian > > Prosentient Systems > > 72/330 Wattle St > > Ultimo, NSW 2007 > > Australia > > > > Office: 02 9212 0899 > > Direct: 02 8005 0595 > > > _______________________________________________ > Koha-devel mailing list > Koha-devel(a)lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -- Tom?s Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ? +54 9351 3513384 GPG: B2F3C15F

3 2

Meeting Reminder: Development IRC meeting 28 September 2016
by Katrin Fischer 27 Sep '16

27 Sep '16

Hi all, there is a Development IRC Meeting scheduled for 28 September 2016, 21 UTC. The agenda and the time converter can as always be found on the wiki: https://wiki.koha-community.org/wiki/Development_IRC_meeting_28_September_2… Please add any topics you want to discuss! Hope to see you there, Katrin

1 0

RPMs for Koha (Fedora, RHEL, openSUSE, etc)
by David Cook 23 Sep '16

23 Sep '16

Hi all, I'm curious how many people are using RPM-based operating systems for running Koha. I know the majority are probably using Debian/Ubuntu, but I reckon there's probably more Fedora/RHEL/openSUSE folk than we might think! I noticed back in 2013 that Nicholas van Oudt had put together a RPM for Koha for Fedora. The link in nabble didn't work anymore, but I'm curious how many people have their own RPM spec files drifting around. I taught myself how to package RPMs back in June, and I package RPMs for a different much smaller Perl project, but I'm not willing to be a RPM manager for Koha. That said, I'm happy to test and QA RPM spec files. The cpanspec tool in Fedora/EPEL is also amazing for converting CPAN modules into RPMs. The openSUSE version is awful unfortunately, and I haven't had time yet to investigate with the openSUSE people about fixing it. I've noticed a few SELinux commands in some Koha code as well. I think Marcel might have included those. I think a reasonable alternative would be to do a custom policy module for Koha, which perhaps could be hosted in a community yum repository. We use openSUSE, so I wouldn't be looking to support Fedora/RHEL myself, but maybe if we started making some infrastructure, it could make it easier for the RPM using members of the Koha community. I know many are probably fearful of opening the door to RPMs since it could make support more difficult. so maybe we could have anything RPM-related be unofficial. Maybe treat it like contribs instead of part of Koha proper. Anyway, just an idea. If nothing else, maybe we RPM-based Koha people could put together a listserv to share RPM-based system issues. That could in theory relieve pressure from the Debian users when people ask them how to install Koha on CentOS/Fedora/RHEL, etc.? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595

2 1

Zebra indexing
by Rodrigo Santellan 22 Sep '16

22 Sep '16

2 2

Curiosity why is cardnumber field size 16?
by Indranil Das Gupta 22 Sep '16

22 Sep '16

Hi all, I'm curious to know why is Koha's cardnumber field in borrowers table is historically set to VARCHAR(16) rather than say VARCHAR(255)? Especially since we now have the CardnumberLength syspref which we could use to drive the length rather than hardcode it down at 16. The background of this question: Schools in Nigeria use a matriculation number which is often larger than 16, as their cardnumber. Zeno did mention to me in a FB post that ExtendedPatronAttribute would equally do the job. Thoughts? -indranil -- Indranil Das Gupta L2C2 Technologies Phone : +91-98300-20971 Blog : http://blog.l2c2.co.in IRC : indradg on irc://irc.freenode.net Twitter : indradg

6 5

To React or not to React
by Kyle Hall 22 Sep '16

22 Sep '16

I have my proof of concept for using React within Koha completed! You can see it here: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17297 Please give it a try! So, I've written this development ( at least in part ) in both Angular and React. I know Angular 2 is out but here are my thoughts so far. 1) It's much easier to think in React than in Angular. React is for the most part just Javascript. It's far less opinionated than Angular. They saying goes React is Javascript and Angular is Angular. I think the flexibility of React works well within the Koha ecosystem. 2) Writing React feels much more like programming. I think it's much faster to develop reactive and ajax features in React than it is using jQuery. 3) React makes it pretty easy to create widgets that we can drop in to a given page and have just work. Pretty much anything that shows up on multiple pages would make for a good React widget. Think the holds table which is on the checkouts page and the patron details page. It is ajaxified now, but a far far cleaner version could be written in React. 4) React is just a view layer. Angular is a full MVC framework with many pieces we don't really need. I think React is probably the way to go for Koha. I like Angular but for Koha in particular, I think React is a better fit. I think we really need to get this decision made as soon as possible. If anyone has opinions, please let everyone know! Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org )

12 24

Re: [Koha-devel] To React or not to React
by Paul A 22 Sep '16

22 Sep '16

With some snipping, please see interspersed text below At 03:03 PM 9/21/2016 +0000, Kivilahti Olli-Antti wrote: >Hi there! >I don't know how I intercepted this email since I never read my email, but... Well, you've been subscribed for many years, have occasionally written, but I would agree that you "never read" ... >[snip] Kyle. I totally f***ing agree with you 10000%. >Swagger2 + React + Redux will f*** the s*** out of any ILS Koha meets. While I also find that Kyle made some good points, I am not a "list moderator" here, but would instantly chuck you out for your asterisks. I have Finnish friends who are perfectly civilized, so may I suggest kiitos and add ole varovainen sanasi ja kiel. >I was planning to start a ... 'KohaFi' ... get rid of the legacy baggage >... before we (as in Finland) can start working on that I have a ton of >stuff to do. Maybe next year ... I wish you (as in Finland [sic]) good luck. I'm holding my breath for "maybe next year" -- or hopefully even later -- for an outcome to your diatribe. Paul P.S. I will not respond to any further trolling.

1 0

Customize debian scripts.
by Rodrigo Santellan 21 Sep '16

21 Sep '16

Hi, I'm looking at the Debian scripts and I'm finding out that all the paths are hard coded. This is not really useful when installing the development version. Is worthy to change them to relatives paths? Or have it to take the enviroment variable to build the paths? Or is a waste of time? Regards

3 3

Re: [Koha-devel] To React or not to React
by Paul A 21 Sep '16

21 Sep '16

At 08:18 AM 9/19/2016 -0400, Kyle Hall wrote: >Thanks for the feedback Stefano! >Please, if anybody is *against* the use of React in Koha, please voice >your concerns! Question: what has Facebook added to js that we could not use as "regular" js? Not a show stopper, but our "gut feeling" (not fully documented, but more than anecdotal) is that all js code, given its standalone capability, has a more than proportional speed downside. And I'm not going near the licensing questions. If I understand this bug 17297 ("low enhancement") correctly, it refines itemnotes by adding granularity. If this is a "good thing", can the original coding be improved? Add an auth value? If we need js, how optional might this be? (do we know how many Koha users are truly interested?) I've always been impressed by Koha core speed, and without using such expressions as "mission creep" (or heaven forfend, code bloat) I truly recognize that enhancements are a real life necessity. Just wondering how and where they are best added while maintaining the KISS principle... Best -- Paul >Kyle > > > ><http://www.kylehall.info>http://www.kylehall.info >ByWater Solutions ( <http://bywatersolutions.com>http://bywatersolutions.com ) >Meadville Public Library ( ><http://www.meadvillelibrary.org>http://www.meadvillelibrary.org ) >Crawford County Federated Library System ( ><http://www.ccfls.org>http://www.ccfls.org ) > >On Fri, Sep 16, 2016 at 9:50 AM, Stefano Bargioni ><<mailto:bargioni@pusc.it>bargioni(a)pusc.it> wrote: >My +1 for React. Angular requires a specific skill, other than Javascript. >Stefano > >>On 15 set 2016, at 19:22, Kyle Hall >><<mailto:kyle.m.hall@gmail.com>kyle.m.hall(a)gmail.com> wrote: >> >>I have my proof of concept for usingÂ ReactÂ within Koha completed! You >>can see it here:Â >><https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17297>https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17297 >> >>Please give it a try! >> >>So, I've written this development ( at least in part ) in both Angular >>andÂ React. I know Angular 2 is out but here are my thoughts so far. >> >>1) It's much easier to think inÂ ReactÂ than in Angular.Â ReactÂ is for >>the most part just Javascript. It's far less opinionated than Angular. >>They saying goesÂ ReactÂ is Javascript and Angular is Angular. I think >>the flexibility ofÂ ReactÂ works well within the Koha ecosystem. >> >>2) WritingÂ ReactÂ feels much more like programming. I think it's much >>faster to develop reactive and ajax features inÂ ReactÂ than it is using >>jQuery. >> >>3)Â ReactÂ makes it pretty easy to create widgets that we can drop in to >>a given page and have just work. Pretty much anything that shows up on >>multiple pages would make for a goodÂ ReactÂ widget. Think the holds >>table which is on the checkouts page and the patron details page. It is >>ajaxified now, but a far far cleaner version could be written inÂ React. >> >>4) React is just a view layer. Angular is a full MVC framework with many >>pieces we don't really need. >> >>I thinkÂ ReactÂ is probably the way to go for Koha. I like Angular but >>for Koha in particular, I thinkÂ ReactÂ is a better fit. I think we >>really need to get this decision made as soon as possible. If anyone has >>opinions, please let everyone know! >> >>Kyle >> >> >><http://www.kylehall.info/>http://www.kylehall.info >>ByWater Solutions ( >><http://bywatersolutions.com/>http://bywatersolutions.com ) >>Meadville Public Library ( >><http://www.meadvillelibrary.org/>http://www.meadvillelibrary.org ) >>Crawford County Federated Library System ( >><http://www.ccfls.org/>http://www.ccfls.org ) >>_______________________________________________ >>Koha-devel mailing list >><mailto:Koha-devel@lists.koha-community.org>Koha-devel(a)lists.koha-community.org >>http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >>website : <http://www.koha-community.org/>http://www.koha-community.org/ >>git : <http://git.koha-community.org/>http://git.koha-community.org/ >>bugs : <http://bugs.koha-community.org/>http://bugs.koha-community.org/ > > >_______________________________________________ >Koha-devel mailing list ><mailto:Koha-devel@lists.koha-community.org>Koha-devel(a)lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : <http://www.koha-community.org/>http://www.koha-community.org/ >git : <http://git.koha-community.org/>http://git.koha-community.org/ >bugs : <http://bugs.koha-community.org/>http://bugs.koha-community.org/ > > >_______________________________________________ >Koha-devel mailing list >Koha-devel(a)lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

6 15