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

ElasticSearch for Koha - presenting the Koha Gruppo Italiano's project
by Stefano Bargioni 08 Feb '14

08 Feb '14

The Koha Gruppo Italiano is proud to present a new project for the development of Koha. Recently the community has shown a big interest in substituting Zebra with a new search engine. How this is done -- whether Zebra is replaced or complemented, etc. -- will determine the workload and necessary financial support. The Koha Gruppo Italiano wants to promote the project through a crowd-funding campaign, sponsorships, events, endorsements etc. The Koha Gruppo Italiano would like to bring together the community of developers to determine the possibility of introducing the new search engine, to set up the work flow, and to collect the funding necessary for the project. On March 11, 2014 the project will be presented in Marseille at the Koha Hackfest for evaluation. Important software editors/producers working for Koha, and others interested in the project will be invited. The project will be presented by Stefano Bargioni, Deputy Director and System Librarian at the Library of the Pontificia Università della Santa Croce. The goal is to discuss solutions, and propose ideas in order to take initial decisions. The project and its progress can be followed through the website <http://kohagruppoitaliano.moonfruit.com>, on FB <http://www.facebook.com/KohaGruppoItaliano> and on Twitter <https://twitter.com/kohagruppoit>. We are very interested to hearing your first impressions, your suggestions etc. about this proposed project. Please respond to this e-mail if you have any comments. Probably the best contributions during this early phase will be the definition of the fundamentals. Example: - Which search engine? - ElasticSearch, Solr or other (even if, at this time, the name of the initial project is ElasticSearch for Koha)? - Should the effort focus on complementing Zebra or on its replacement? - Subdivide the workload. - Draft a road map. We are grateful to all developers who will be contributing to our project. We hope that this project is seen favorably within the community, and specifically wish that the Librarian community worldwide see the benefits of this project and would be willing to assist us with finding financial support. Kindest regards, Franziska Wallner, Stefano Bargioni, Sebastian Hierl, Juan Diego Ramirez

6 8

IMPORTANT: Koha security release
by Galen Charlton 07 Feb '14

07 Feb '14

[apologies for the multi-post, but if there are any folks who are subscribed to koha-devel but not the general list, they need to see this too] The Koha community is releasing a security update for all supported and recent unsupported versions of Koha. The security update is available in the following new releases being made today: * 3.14.3 * 3.12.10 * 3.10.13 * 3.8.23 The following security bugs are fixed by this update: * Bug 11660: tools/pdfViewer.pl could be used to read arbitrary files on the server * Bug 11661: the staff interface help editor could be used to modify or create arbitrary files on the server with the privileges of the Apache user * Bug 11662: member-picupload.pl could be used to write to arbitrary files on the server with the privileges of the Apache user * Bug 11666: the MARC framework import/export function did not require authentication, and could be used to perform unexpected SQL commands The fix for bug 11666 removes SQL as a supported format for importing or exporting MARC frameworks. We recommend that you upgrade immediately to get the fixes for these security issues. However, if you are not able to perform the upgrade right away, you can mitigate against the issues by performing the following actions: * deleting the pdfViewer.pl script * deleting the member-picupload.pl script * making edithelp.pl not be executable, e.g., by doing chmod a-x edithelp.pl * making import_export_framework.pl not be executable, which will disable the MARC framework import and export functionality Our thanks to John Lightsey for finding and reporting the issues. The 3.14.3 and 3.10.13 releases also contain unrelated bugfixes which are described in their release notes. Please note that if you installed from a tarball, you may need to manually delete pdfViewer.pl and member-picupload.pl, even after you upgrade. Users of the Debian packages for 3.12.x and 3.14.x (and master) can get the latest release by running apt-get update followed by apt-get upgrade. Tarballs are also available and can be downloaded from http://download.koha-community.org. If you are not running a version of Koha that has has a release maintainer (currently 3.8.x, 3.10.x, 3.12.x, and 3.14.x), we strongly urge you to upgrade to a supported version. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc(a)esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org

2 1

Reporting security bugs
by Galen Charlton 04 Feb '14

04 Feb '14

Hi, There is now a mechanism in place for reporting security bugs via Bugzilla. If you look at the footer, you should now see a 'Report security bug' link. This allows someone who has a Bugzilla account to enter a bug in a new BZ product called 'Koha security'. Bugs reported in this fashion are visible only to the reporter and to members of a Koha security group currently consisting of the following individuals: Bernardo Gonzalez Kriegel Chris Cormack Frère Sébastien Marie Fridolin SOMERS Galen Charlton Ian Walls Jared Camins-Esakov Jonathan Druart Katrin Fischer Kyle M Hall M. de Rooy MJ Ray (software.coop) Paul Poulain Robin Sheat Tomás Cohen Arazi The idea is that members of the security group would be responsible for evaluating the bugs, fixing them (and drawing in outside help if needed), and releasing the fixes. Once a fix is released, the relevant bug(s) would be sanitized to remove mention of direct exploits, then have their products changed to 'Koha' so that they would be visible to all. This is not set in stone, so I invite discussion of the security policy. I also invite anybody who may have been sitting on security bugs for lack of a means to report them securely to go ahead and use BZ. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc(a)esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org

3 3

Some thoughts on the SIP-server scalability
by Petter Goksøyr Åsen 03 Feb '14

03 Feb '14

Dear Koha devs! I work at at Oslo public library. We recently decided to go for Koha, and are now working on planning the migration from our current ILS. Our library is fully automated, with RFID-checkin machines taking care of almost all of our circulation. We currently have around 50 of these running at 15 branches around the city. Because of this, we naturally need the SIP-server to handle quite a load. I checked the logs of our current ILS, and found the number of SIP-messages peeked at 58 per second. (In addition to the checkin-machines - we have a lot of RFID-workstations which potentially also will make use of SIP) Correct me if I'm wrong, but this is what I have found out: Koha's SIP server can only handle one request at a time. So if you need more you have to spin up more SIP-severes. This fine for a few, but try to spin up 30 of theese - it takes 15 minutes just to get them all started on a new box with plenty of RAM & CPU. The servers are independent processes which share no resources.. Instead of forking seperate processes for each connection - what about a server which runs as _one_ process and handles multiple tcp connections? I've read about and tested Poe (http://poe.perl.org/) with this in mind - and it seems pretty nice. Poe is an evented framework (akin to Node for javascript or EventMachine in Ruby) which handles such multiplexing of severeal connections. Poe seems very mature, but I'm not competent to judge if its a good fit. There are other options as well (ex IO::Async & AnyEvent ) Any thoughts? We're also very keen on hearing about experiences from other automated Koha libraries, especially those with more than a checkin-machines. Best regards, Petter Goksøyr Åsen Deichmanske bibliotek / Oslo Public Library

4 7

Add itemnumber constraint to aqorders_items
by Marcel de Rooy 03 Feb '14

03 Feb '14

Hi, Would you mind putting a FK constraint on itemnumber in aqorders_items (with cascaded delete) ? Please feel free to join the discussion on report http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11617 Thanks, Marcel

1 0

meetings.koha-community.org site - link for 2014 meetings
by David Nind 02 Feb '14

02 Feb '14

I thought I would post this here first - I can log a bug report if that is the right way to do it. For http://meetings.koha-community.org/ there is no link on the main page or sub pages for the 2014 meetings. A folder for 2014 exists though: http://meetings.koha-community.org/2014/ I couldn't find the details of who looks after this site on http://wiki.koha-community.org/wiki/Website_Administration David Nind | david.nind(a)gmail.com PO Box 12367, Thorndon, Wellington, New Zealand 6144 h. +64 4 9720 600 | m. +64 21 0537 847 | w. +64 4 8906 098

2 2

Modules only on CPAN
by Zeno Tajoli 31 Jan '14

31 Jan '14

Hi to all, I check with master the modules that we need to install. Those 4 modules are not present in http://debian.koha-community.org Data::Pagination 0 * 0.44 No HTTPD::Bench::ApacheBench 0 * 0.73 No Test::WWW::Mechanize 0 * 1.44 No Archive::Extract 0.48 * 0.60 No Data::Pagination is used in Solr search Koha/SearchEngine/Solr/Search.pm and opac/search.pl HTTPD::Bench::ApacheBench is used in load_testing/benchmark_circulation.pl and in load_testing/benchmark_staff.pl Test::WWW::Mechanize is used in db_dependent/www/batch.t Archive::Extract is used in plugins/plugins-upload.pl and plugins/plugins-uninstall.pl and t/db_dependent/Plugins.t In my opinion Data::Pagination and Archive::Extract could be packages in http://debian.koha-community.org, the others no (because are only for developer). Cheers Zeno Tajoli -- Dr. Zeno Tajoli Dipartimento Gestione delle Informazioni e della Conoscenza z.tajoli(a)cineca.it fax +39 02 2135520 CINECA - Sede operativa di Segrate

5 7

Re: [Koha-devel] KOHA 3.14.1 Error (Continuing)
by volkan sonmez 31 Jan '14

31 Jan '14

I applied "Bug-11475-Links-are-broken-when-editingdeleting-it.patch" patch to 3.14.1 and tried "Editing items in batch" in 3.14.2. But nothing changed in both versions. Problem still persists. Am I doing something wrong? -----Original Message----- From: koha-devel-bounces(a)lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Owen Leonard Sent: Friday, January 03, 2014 4:59 PM To: koha-devel(a)lists.koha-community.org Subject: Re: [Koha-devel] KOHA 3.14.1 Error Replying to the list, since a direct message to me excludes all the other people on the list who might be interested in the conversation. > Here I will try to describe specific steps which will lead us to the > error 404 screen; > > 1- First we search for records with multiple items (books or serials, > does not matter) > > 2- We open this record we found with multiple items for editing > > 3- We chose "Edit items in batch" option from the "Edit" menu > > 4- We make corrections on the fields under the "Edit item" (For > example we change the collection code as "fiction") > > 5- We save this using "Save button" at the bottom, after we are done. > > 6- Just after we save, there will be a button named "Done" available just under the page, and when we click on "Done" we encounter the Error screen. I have just tested this in master and I get the same results. I have filed a bug report: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11475 -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.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/

2 2

Bootstrap-styled buttons in the staff client
by Owen Leonard 29 Jan '14

29 Jan '14

When we implemented Bootstrap buttons the staff client changes were limited to places where YUI was being used to style a button (mostly in toolbars). We have lots of other buttons in the templates and some patches are starting to add the default "btn" class to non-toolbar buttons. At the moment this is causing display problems because the "btn" class conflicts with the staff client's default class for submit buttons. We have a couple of choices: 1. Stop adding the "btn" class to non-toolbar buttons and remove the class from templates which have been recently modified. 2. Start adding the "btn" class to non-toolbar buttons in ALL cases and adjust the global stylesheet so that the styles don't conflict. If we choose option 2 I would propose that we choose a secondary class as well, for instance btn-primary for submit buttons: http://getbootstrap.com/2.3.2/base-css.html#buttons This would maintain the visual difference between toolbar buttons and submit buttons. I think this is helpful for visually understanding the structure of a page. I would appreciate everyone's opinions. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

1 0

Re: [Koha-devel] QueryParser question
by Marcel de Rooy 27 Jan '14

27 Jan '14

Thanks, Jared. Just to be more complete: I meant with an uppercase variant in this case the variant starting with only the first character in uc (like Number-local-acquisition). I scrolled through the QueryParser code and came at the lines 855-857 of OpenILS/QueryParser.pm where three regexes are used to search for fields and aliases. Is it an idea to make these regexes case insensitive? This would make QueryParser behave case insensitive as to index names, just like C4/Search.pm now is when you disable QueryParser. (compare BZ 6786) As an example, the Number-local-acquisition index of BZ 10544 could be mentioned. QueryParser does not recognize the index name with capital N, but since it prefixes the string with pqf=, C4/Search will not change it either. Copying dev list for additional feedback? Marcel Van: Jared Camins-Esakov [mailto:jcamins@cpbibliography.com] Verzonden: donderdag 23 januari 2014 16:02 Aan: Marcel de Rooy Onderwerp: Re: QueryParser question Marcel, Upper-case indexes seem odd to me, but it would be easy to add them. For example, the following change in Koha/QueryParser/Driver/PQF.pm: 97 $self->add_search_field_alias( $class => $field => uc $field ); Regards, Jared On Thu, Jan 23, 2014 at 8:32 AM, Marcel de Rooy <M.de.Rooy(a)rijksmuseum.nl<mailto:M.de.Rooy@rijksmuseum.nl>> wrote: Hi Jared, This question came up when looking at report http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10544 The index names in the config file seem to be lower case. Upper case variants do not seem to work. Is it possible to add uppercase names? Or is it possible to have all variants work in some case insensitive manner? Thanks, Marcel -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins(a)cpbibliography.com<mailto:jcamins@cpbibliography.com> (web) http://www.cpbibliography.com/

2 1