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

Country-specific forks?
by Magnus Enger 16 Feb '16

16 Feb '16

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

17 19

Reminder: Developer IRC meeting 16 February, 19 UTC
by Owen Leonard 16 Feb '16

16 Feb '16

There is a developer IRC meeting later today, 16 February 2016, at 19 UTC. Find the local time here: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+IR… The agenda is here: https://wiki.koha-community.org/wiki/Development_IRC_meeting_16_February_20… -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

1 0

Z39.50 marc21 to unimarc
by Andrea Furin 16 Feb '16

16 Feb '16

Hi. I need to import Z39.50 marc21 results in a unimarc database: is it possible? Tia andrea f.

3 2

Koha::Object validation ?
by Julian Maurice 15 Feb '16

15 Feb '16

Hi there, I'm currently working on some enhancements for authorised values (to make it possible to have a hierarchy of values), so I'm using Koha::AuthorisedValue which is a subclass of Koha::Object. I would like to add some sort of validation mechanism just before saving the object into database. Is there already someone who started to work (or started to think) on something like that ? Jonathan, maybe ? -- Julian Maurice <julian.maurice(a)biblibre.com> BibLibre

3 3

Re: [Koha-devel] Disabling multiple submission on search form
by SUZUKI Arthur 15 Feb '16

15 Feb '16

ERRATUM: You should add onclick="this.disabled=true; this.form.submit(); return true;" as stated in the Sed command. If missing "this.form.submit(); return true;" the trick works only in Firefox and IE (screw you Google...). Best regards, Arthur SUZUKI Service informatique des bibliothèques bIBLIOTHÈQUES UNIVERSITAIRES Université Jean Moulin Lyon 3 6 Cours Albert Thomas - B.P. 8242 - 69355 Lyon Cedex 08 ligne directe : +33 (0)4 78 78 79 16 | http://bu.univ-lyon3.fr L'Université Jean Moulin est membre fondateur de l'Université de Lyon De : SUZUKI Arthur Envoyé : lundi 15 février 2016 10:55 À : 'koha-devel(a)lists.koha-community.org'; 'koha-devel(a)nongnu.org' Cc : BOUIS Sonia; CROUZET Olivier Objet : Disabling multiple submission on search form Hello, We are facing the following problem on our installation of Koha. Some impatient users tends to click several times on the "Go" button of the search form on OPAC. Probably in a desperate hope that this will speed up the whole process. However the result is quite opposite, as Zebra is then queried multiple times which increases the server cpu load, until it reach 100% and cause Denial of Service (boooh...) We had the idea of disabling the "searchsubmit" button upon first click. This is done by adding onclick="this.disabled=true;" after "id=searchsubmit" in masthead.inc. Here is a SED command to make it easier. sed -i -e 's/id="searchsubmit"/id="searchsubmit" onclick="this.disabled=true; this.form.submit(); return true;"/' src/koha-tmpl/opac-tmpl/bootstrap/en/includes/masthead.inc Did any of you already faced similar problems? Any other ideas or implementation are welcome! Arthur SUZUKI Service informatique des bibliothèques bIBLIOTHÈQUES UNIVERSITAIRES Université Jean Moulin Lyon 3 6 Cours Albert Thomas - B.P. 8242 - 69355 Lyon Cedex 08 ligne directe : +33 (0)4 78 78 79 16 | http://bu.univ-lyon3.fr L'Université Jean Moulin est membre fondateur de l'Université de Lyon

1 0

release-tools: get_bugs.pl and the --html switch
by Julian Maurice 12 Feb '16

12 Feb '16

Hi, I just discovered a few issues in get_bugs.pl: 1. The two versions of release notes (txt and html) are always generated even without the --html switch 2. The same 'release_team_*' file is used in both versions, which means if you use --html, the html version of release_team is included in both versions of release notes (and without --html it's the text version that is included). I'm trying to fix those issues and I wonder if the --html switch is still needed. It's used only in a few places, and it's used in a wrong way: either the script think we are only generating html, or it is used in a test that is always true (if defined $html). Can we simply remove it ? -- Julian Maurice <julian.maurice(a)biblibre.com> BibLibre

4 7

Too warning in Koha log " ... CGI::param called in list context from package main ..."
by Zeno Tajoli 12 Feb '16

12 Feb '16

Hi to all, I have find a too high numbers of lines in Koha errors logs. All lines have: ... CGI::param called in list context from package main line xxx this can lead to vulnerabilities. See the warning in "Fetching the value or values of a single named parameter" at /usr/share/perl5/CGI.pm line 436. I use Debian Jessie with Koha 3.20.7. CGI.pm version is 4.09, the jessie version: https://packages.debian.org/jessie/libcgi-pm-perl Reading this one: http://www.perlmonks.org/?node_id=1105164 and seeing this bugzilla: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14076 I go to /usr/share/perl5/CGI.pm, line 28 and I change $LIST_CONTEXT_WARN = 1; into $LIST_CONTEXT_WARN = 0; Now no more warings in error logs. But I don't know: 1)Is present a better way that change a core lib code ? 2)What do we do about "CGI::param called in list context ... can lead to vulnerabilities" ? Bye Zeno Tajoli

5 6

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