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

RE : Re: Country-specific forks?
by Eric Bégin 12 Feb '16

12 Feb '16

I think we wouldn't have a discussion about 'country-specific' if the patch was nor refering Norwegian in its name :) I believe this bring a much larger topic about plugins. We are loosing some important CPU processing the way stuff are currently implemented. For example, the code is filled with checks if we are using MARC21/UNIMARC/NORMARC. I think we (the community) would benefit for a more modular approach. The I see this is that we have hooks in the code on which modules (or plugins) are registering to be called. See this as an interface / implementation. If I'm using MARC21, the MARC21 module implements the required interface. My 0.02 CAD ; ) Eric BéginSolutions inLibro inc. -------- Message d'origine -------- De : Viktor.Sarge(a)regionhalland.se Date : 12/02/2016 02:28 (GMT-05:00) À : magnus(a)enger.priv.no Cc : koha-devel(a)lists.koha-community.org Objet : Re: [Koha-devel] Country-specific forks? I actually think a more general plugin system would both increase the attraction of new libraries and keep existing ones from wanting to fork. Being a firm believer in running the community code it is sometimes frustrating that key features might take years to ge into master. All ways that makes it easy to run standard Koha while still altering the behaviour is therefore welcome. (At the same time I'm a little bit afraid of a future where the ones with resources make their own addons since it's easier and the community codebase never gets the chance to implement good features in a generic way. A bit like "yes it's not very good, but that's why you'll also want to buy this extra discovery system that we happen to sell as well" that seems to happen in some proprietary products.) Kind regards/ Viktor Sarge Senior regional library development officer Skickat från min iPhone > 11 feb. 2016 kl. 10:38 skrev Magnus Enger <magnus(a)enger.priv.no>: > > Dear Community! > > A quote from another thread on koha-devel: > > "I look at the code, and beside wondering why that custom feature > [Norwegian patron DB] is so profoundly imbricated into master Koha, I > was wondering what is not working." > > I think this raises an interesting question. Should we let features > into Koha that are only of interest to libraries in one or a small > number of countries? Or should we confine those features to > country-specific forks? > > The quote above implies (I think) that support for the Norwegian > patron DB should be in a country-specific fork. > > On the other hand, the project implementing Koha for public libraries > in Turkey has been criticized for not integrating their customizations > into Koha. To which someone replied that the customizations were not > of much interest to libraries outside Turkey. > > So do we want one Koha to rule them all, including country-specific > features, or do we want one fork per country? > > Personally, I prefer the former. In the case of the Norwegian patron > DB, that is one of the 2-3 "must have" features that all Norwegian > public libraries will be looking for when they are choosing between > Koha or some proprietary system. Should we be telling them "Nope, you > can't use the real Koha, but you can use this fork over here"? That > will not increase their confidence in choosing Koha, I suspect. > > That said, I do think some principles should be applied: > > - Strive to make even the country specific features as general as > possible, so that others can use them as starting points for similar > features. > > - Strive to make the features as unobtrusive as possible. > > And maybe, in time, the plugin system can be made powerful enough that > it can handle some or all of the country-specific features? > > Thoughts? > > Best regards, > Magnus Enger > Libriotech > _______________________________________________ > 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/ _______________________________________________ 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/

1 0

Huge performance issue cause by bug 13618 (XSS)
by Jonathan Druart 11 Feb '16

11 Feb '16

Hi devs, I have a very bad news... Working on bug 15715, I have found that the patchset introduced by bug 13618 (Prevent XSS in the Staff Client and the OPAC) causes a very important performance issue. Indeed, for each variable displayed in the template, a Template::Stash::AutoEscaping->get method is called. To try and understand the problem, I have put the following snippet in the mainpage.pl script: +my @loop; +for my $i ( 0 .. 10000 ) { + push @loop, { + foo => 'my foo', + bar => 'my bar', + }; +} +$template->param( loop => \@loop ); and then, in the template +[% FOR l IN loop %] + [% l.foo %] [% l.bar %] + <br/> +[% END %] It will display 10k foo and 10k bar There are indeed 20k (+ delta) calls to the Template::Stash::AutoEscaping method, as expected. But the load of the page increases from 2sec to 10sec (no plack, measured with Firebug > network tab) On catalogue/search.pl, 1800 calls, from 6sec to 6.5s On authorities/authorities.pl?breedingid=186&authtypecode=CORPO_NAME&authid=0 (From bug 15715), 64k calls (!!!) from ~10sec to ~4min On cataloguing/addbiblio.pl?biblionumber=1, 13k calls, from 3sec to 9sec Do not take these measures too strictly, but they give an idea of the issue... So I don't see a lot of methods to fix that: 1/ Revert and abandon 13618 2/ Understand how it's possible to have 60k calls to display a form and try to improve these areas 3/ Profile Template::Stash::AutoEscaping to know if we cannot optimise what it does 4/ Any brilliant ideas? Jonathan https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15715 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13618

6 6

feature for bugzilla ?
by Paul Poulain 10 Feb '16

10 Feb '16

Hi all, when an entry on bugzilla has a lot of comments, it can take "hours" to read all the thread, find relevant and obsolete comments,... understand who said what and where we are now. Justs have a look at -randomly chosen- http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6934 to see this (only 33 comments, not so hard to follow, but will take a lot of time. Other bugs are really a nightmare !!! ) I was wondering if there could be an Addon, a feature, un plugin, or whatever, that could "obsolete" a comment. An obsoleted comment would be collapsed by default. Anyone can obsolete a comment, it's just to (hopefully) have a thread easier to read. Another option could be to put a color on comment that are relevant. There could be other way to achieve the goal. But currently, one must be highly motivated to work on a sign-off, except if the bug is "new" ! (I suspect that's a reason why some patches are stuck) -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries

10 15

Tweak Null filter or add new one?
by Mark Tompsett 10 Feb '16

10 Feb '16

Greetings, Since the initialization of parameters is being done incorrectly for Koha::RecordProcessor, the question in my mind is: Do I tweak the Null filter to have an initialize method to be triggered for testing, or do I write a new filter for this regression test? Feedback appreciated. See Bug 15777. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15777 GPML, Mark Tompsett

1 0

maintenance on jenkins
by Laurent Ducos 09 Feb '16

09 Feb '16

Hello Maintenance operation before migration of jenkins server, thursday 28, from 10 A.M to 11 A.M french hour. Please do not use http://jenkins.koha-community.org/ durig this period. Have a good day. Laurent Ducos BibLibre

3 4

Koha Hackfest in Berlin 25–27 May 2016
by Mirko Tietgen 09 Feb '16

09 Feb '16

Hello everyone, details for the Hackfest in Berlin are now set. Date is 25–27 May 2016 (Wednesday to Friday) the week before Kohacon. There are direct flights to Thessaloniki on Saturday and Sunday. Location is Büro 2.0, Weigandufer 45, 12059 Berlin. There will be a Catmandu workshop. Catmandu is a data toolkit. http://librecat.org/Catmandu/ Size of the location is limited, please let me know if you want to come. More info: https://wiki.koha-community.org/wiki/Berlin_Hackfest_2016 Cheers, Mirko -- Mirko Tietgen mirko(a)abunchofthings.net http://koha.abunchofthings.net http://meinkoha.de

1 0

Discussion for Bug 14757 - Allow the use of Template Toolkit syntax for slips and notices
by Kyle Hall 08 Feb '16

08 Feb '16

I would like to start the discussion Marcel wanted to have at the dev meeting. Right now, we have one bespoke syntax for slips and notices with all kinds of caveats and limitations. My first instinct was that we should over time tear out this old syntax and replace it with TT. However, there are some issues: 1) TT is a bit more complicated ( and more powerful of course ) than our custom syntax 2) We have an editor for our current syntax ( though it is somewhat problematic to use at times, as not all fields in the editor are actually available on the notices where they display ) 3) Creating an editor for TT would be somewhat non-trivial if we were to replace what we have with a better and more advanced way of dealing with data passed to the slip or notice. I'm wondering if we should, at least for the time being, consider the existing notice syntax as the "basic" mode for slips and notices, and have the ability for TT in notices and slips be an 'advanced' mode. Basically, that means that nothing will change for librarians. The current syntax and editor will continue to be what they are. Instead, 'advanced' users can simply start using TT in their notices and slips. What we will do is document how to use TT in slips and notices in the manual. So, what I would do at this point is deprecate my replacement notices ( keeping the new methods where necessary for the advanced mode ), and create some good documentation. That way we get the power of TT while retaining backwards compatibility! What does everyone think? 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 )

8 12

about using XSLT for display of holdings (952)
by Indranil Das Gupta 08 Feb '16

08 Feb '16

Hi, At the risk of asking something very stupid, I was wondering why we utilize XSLT only for the biblio record and not for the holdings data in say opac-details.pl thanks in advance -- Indranil Das Gupta Phone : +91-98300-20971 Blog : http://indradg.randomink.org/blog IRC : indradg on irc://irc.freenode.net Twitter : indradg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=- Please exchange editable Office documents only in ODF Format. No other format is acceptable. Support Open Standards. For a free editor supporting ODF, please visit LibreOffice - http://www.documentfoundation.org

5 4

Serials - Next issue publication date management
by Francois Charbonnier 08 Feb '16

08 Feb '16

Hello all, Has any recent develpments change the way Koha manage the next issue publication date ? I noticed in 3.20, but also in master, that you can't change the next issue publication date when editing a serial subscription anymore. And, that we lost a feature I liked when receiving a new issue. Before 3.20, when receiving a new issue, you could change the "Published on" date and Koha will adjust the subscription's next issue publication date for all the new issues to be received. I quickly checked on bugzilla but can't find anything specific. Could it be https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12671 that broke this feature? The thing is, I don't mind if we lost a shortcut to edit the subscription's next issue publication date, but not being able to change it when editing the subscription itselft seems like a bug to me. Before reporting this, am I missing something? Thanks! François -- François Charbonnier, Bibl. prof. / Chef de produits Tél. : (888) 604-2627 francois.charbonnier(a)inLibro.com <mailto:francois.charbonnier@inLibro.com> inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>

2 1

Apache error logs
by Paul A 08 Feb '16

08 Feb '16

For the last couple of days, our production server has "gone bonkers" with tens of thousands of the following: [Wed Jan 20 18:41:58 2016] opac-search.pl: Use of uninitialized value $code_wanted in string eq at /usr/share/perl5/MARC/Field.pm line 314. Appears to involve control fields MARC < 10 I have noted that two new (to us) spiders are quite busy, and date-times appear to correspond -- webmeup-crawler.com and ahrefs.com -- but I don't want to libel them before digging deeper (probably end up firewalling them.) It *might* have something to do with ISBD view. Has anyone got any thoughts? Thanks and best regards -- Paul

2 1