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

Call for News: October 2016 Newsletter
by kohanews 14 Oct '16

14 Oct '16

Fellow Koha users ~ I'm collecting news for the October newsletter. Send anything noteworthy to: k o h a news AT gmail dot com News criteria: --------------------------- ** For events **: - Please include dates for past events. If I can't find dates I may not add it. - Announcements for future events with dates T.B.A. are fine ...Eg., Kohacon - For past events -- **** one month back is the cut-off ***. * News items can be of any length. * Images are fine * Anything and everything Koha. * Submit by the 26th of the month. If you are working on an interesting project or development related to Koha, please let me know and I'll include it in the development section. -- Chad Roseburg Editor, Koha Community Newsletter

1 0

Marseille16 / REST api
by Tomas Cohen Arazi 13 Oct '16

13 Oct '16

During the first couple Hackfest days, Jonathan, Benjamin and I worked on a reference implementation of CRUD code for a REST endpoint, so others can read it, discuss it and use it as a reference for their own developments. We worked on Koha::Cit(y|ies) because it was a really simple class. All our work is now on bug 17428. The main goals/concepts we tried to apply were: * Controller class (Koha::REST::V1::Cities) should be as simple as possible. No business logic on it. All business logic is expected to be put on the Koha::Cit(ies|y) classes. And fully tested. * All verbs/use cases should be covered by tests (t/db_dependent/api/v1/cities.t). We did it, and this file could be used (with little adjustments) as the basis for new endpoint tests. * Heavy use of exceptions. I wouldn't say we heavily use them, but the point is that we pass everything to the business object, and catch exceptions it might raise. Martin pointed out that he would help us further simplify it, making heavier use of the Swagger plugin's facilities. Specially on parameters sanity check. More on this tomorrow! * Koha::Exceptions got per-class files so the exceptions file is more manageable. Bug 17425 introduced Koha/Exceptions/Object.pm, and we propose that's the way to go (Koha/Exceptions.pm still has Virtualshelves-related exceptions that should be moved). * Make use of Try::Tiny for try/catch blocks. On the process we wrote bug 17425, which introduces new exceptions, we added the dependency for Try::Tiny (no worries, it is packaged for Jessie/Ubuntu) and Mirko was here to validate. * Moving business-logic to Koha:: namespace and write REST endpoints on top of that business objects. We picked a simple object, Koha::Patron(s) will be a more complex one of course. This is what Jonathan has been doing, and people willing to write REST endpoints should check with him, and probably help moving business logic into Koha:: namespace. There are several patches on bugzilla introducing endpoints. We will try to contact patch authors to help them make their work match this proposed 'guidelines'. We are sticking to the 'patches speak' approach, so feel free to criticize this implementation, to improve it or even provide a counter-proposal. We are otherwise moving on, trying to get a functional complete REST api ASAP. Thanks! Tomas, Jonathan, Benjamin -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

3 7

Introduce the use of Grunt or Gulp?
by Owen Leonard 13 Oct '16

13 Oct '16

I would very much like to start using some kind of build tool for front-end assets in Koha. The ones I've encountered are Grunt and Gulp: Grunt: http://gruntjs.com/ Gulp: http://gulpjs.com/ I have some experience with Grunt, and have heard good things about Gulp. Has anyone else used either in their non-Koha projects? Adopting them would introduce a little more complexity to the process of making client-side changes to Koha, and to be honest I'm not sure of the right way to incorporate the tools into our workflow. What I see as the advantages: - Automatic linting, minification, and concatenation of CSS and JS - Potentially, automatic compression of images and contruction of image sprites - Overall performance improvements from the above Disadvantages: A new process to learn for those wanting to contribute front-end modifications. A new set of dependencies for front-end developers (Node.js etc). If there is interest I'd be happy to submit a patch introducing the process to the OPAC as a demonstration. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org

10 22

Trying to generate the package.
by Rodrigo Santellan 11 Oct '16

11 Oct '16

Hi, I'm trying to generate the package to learn how to so can I apply it later. I follow: https://wiki.koha-community.org/wiki/Building_Debian_Packages_-_The_Easy_Way on the kohadevbox (jessie) but when I try to generate the package this message appear: W: /home/vagrant/.pbuilderrc does not exist I have to said that I change he file: build-git-snapshot the line 32 to my $distribution='testing'; because of this warning: dch --force-distribution -D "squeeze-dev" -v "16.05.04git+20161011182826.70be2835" "Building git snapshot." dch warning: Recognised distributions are: unstable, testing, stable, oldstable, experimental, {testing-,stable-,oldstable-,}proposed-updates, {testing,stable,oldstable}-se And the error I have is: vagrant@kohadevbox:kohaclone(origin/local-16.05.X)$ sudo -E ./debian/build-git-snapshot -r ~/debian -v 16.05.04git -d git status --porcelain -unormal git rev-parse --short=8 HEAD dch --force-distribution -D "squeeze-dev" -v "16.05.04git+20161011182826.70be2835" "Building git snapshot." dch warning: Recognised distributions are: unstable, testing, stable, oldstable, experimental, {testing-,stable-,oldstable-,}proposed-updates, {testing,stable,oldstable}-security, wheezy-backports, jessie-backports and UNRELEASED. Using your request anyway. dch -r "Building git snapshot." git archive --format=tar --prefix="koha-16.05.04git+20161011182826.70be2835/" HEAD | gzip -9 > "../koha_16.05.04git+20161011182826.70be2835.tar.gz" pdebuild --buildresult /home/vagrant/debian W: /home/vagrant/.pbuilderrc does not exist dpkg-checkbuilddeps: warning: relation < is deprecated: use << or <= dpkg-buildpackage: warning: using a gain-root-command while being root dpkg-buildpackage: source package koha dpkg-buildpackage: source version 16.05.04git+20161011182826.70be2835 dpkg-buildpackage: source distribution squeeze-dev dpkg-buildpackage: source changed by root <root@kohadevbox> dpkg-source --before-build kohaclone dpkg-source: warning: relation < is deprecated: use << or <= dpkg-checkbuilddeps: warning: relation < is deprecated: use << or <= fakeroot debian/rules clean dh clean --fail-missing --with bash-completion dh_testdir -O--fail-missing dh_auto_clean -O--fail-missing make[1]: Entering directory '/home/vagrant/kohaclone' make[1]: *** No rule to make target '/usr/lib/x86_64-linux-gnu/perl/5.22/Config.pm', needed by 'Makefile'. Stop. make[1]: Leaving directory '/home/vagrant/kohaclone' dh_auto_clean: make -j1 distclean returned exit code 2 Command 'pdebuild --buildresult /home/vagrant/debian' returns an error (512) debian/rules:9: recipe for target 'clean' failed make: *** [clean] Error 2 dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2 Where can I look for information about this? Regards

1 0

Pending 16.11 Release Dates
by Kyle Hall 11 Oct '16

11 Oct '16

Hey All, It's that time of the year again! Here is the timeline Brendan and I have mapped out for the pending Koha 16.11 release: Nov 1st - Feature Slush For the uninitiated, the slush means that no new enhancements, only bug fixes, will be pushed to master until some time after the 16.11 release. During the slush phase bug fixes may include template string changes that will require translation. Nov 3 - 1st Draft of release notes The 1st draft of the 16.12 release notes will be published and made available so corrections may be submitted. Nov 10 - 2nd Draft of release notes Nov 15th - Feature Freeze >From November 15 until the release date, only bug fixes without string changes will be pushed to master. Nov 17 - Final Draft of release notes Nov 22 - 16.12 Release Day! Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com )

2 2

Sandboxes are up
by Fridolin SOMERS 11 Oct '16

11 Oct '16

Hie, Since a few weeks our sandboxes are down. We have created a new system with Ubuntu Xenial machines. The virtualisation LXD allows unlimited cloning. See https://wiki.koha-community.org/wiki/Sandboxes#BibLibre Best regards, -- Fridolin SOMERS Biblibre - Pôles support et système fridolin.somers(a)biblibre.com

1 1

Koha 16.11 feature slush, feature freeze, string freeze, release dates
by David Cook 11 Oct '16

11 Oct '16

Hi all, Do we have any dates set for feature slush, feature freeze, string freeze, and release? I think the release is often done around November 26th or 28th? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595

1 0

ICU Chains Library -- an easy way to make Koha better
by Barton Chittenden 10 Oct '16

10 Oct '16

After some conversations on the Koha mailing list, I re-factored some of the language specific ICU chains pages and created https://wiki.koha-community.org/wiki/ICU_Chains_Library Which documents language specific modifications to words-icu.xml (and, at least theoretically, phrases-icu.xml). If any devs know of modifications that they've made for other languages, I would *love* to see these added to that page -- five minutes of copy/paste on your part could easily save another member of the community days or weeks of effort. Thank you! --Barton

1 0

What's on in Koha devel #5 - Special hk16
by Jonathan Druart 08 Oct '16

08 Oct '16

Hello librarians and developers, I send a "What's on in Koha devel" email to koha-devel list each month. But this one is a bit special as I will focus on the different subjects you may heard of if you attend the hackfest in Marseille next week. It can be helpful for both librarians and developers! A lot of things are going on in the Koha ecosystem so it might be hard to follow all the discussions or to jump into one. So my attempted goal here is to compile the topics currently "à la mode" for Koha developers. In this email I will go a bit more into details than usual, to let you the opportunity to better understand the themes and to ask questions next week if you want to know more. I hope it will help you to choose the subject you want to be involved in during the hackfest. = Sandboxes = Sandboxes have been developed with the aim to help people without any technical skills to test patches submitted on the Koha bugtracker. You will find all the information you want on the dedicated wiki page https://wiki.koha-community.org/wiki/Sandboxes = Refactoring = During the last 3 (more?) years we have integrated DBIx::Class (a Perl ORM, Object-Relationnal Mapping) into Koha, for several (sometimes disputed) reasons. To take advantage of it, we are using it as much as possible through a home-made object module called Koha::Object. For the last year, a lot of legacy code has been rewritten and moved out of the C4 namespace to the new Koha namespace. For instance Koha::Virtualshelves replaced C4::VirtualShelves::Page (bug 14544), Koha::Libraries replaces C4::Branch (bug 15293). At the moment, the job focusses on moving the legacy authorised values from the C4::Koha module to Koha::AuthorisedValues (bug 15799) and the patrons/borrowers/users/members code from C4::Members to Koha::Patrons (bug 16846). For an overview of this refactoring work, please have a look at bug 15449 and its scary dependency graph: https://bugs.koha-community.org/bugzilla3/showdependencygraph.cgi?id=15449 Another refactoring work is about moving the biblioitems.marcxml content out of the biblioitems table. The idea is to create another table (biblio_metadata) to add the ability to store a record in different formats. The direct and major addition of this move would be to bring performance speed. See the comment 1 of bug 17196 for more information. = Speed improvements = During the last 2 releases, we have made a lot of speed improvements. That has been achieve with the consolidation and the stabilisation of our caching system and plack integration. If you are running a recent version of Koha (3.22, 16.05 or later) you should set them up correctly to fully enjoy the improvement. To be fair I must say that we have had to concentrate our efforts on these points because of our previous technical decisions (mainly related to DBIx::Class). Two main playgrounds: Plack and Memcached, that I will explain now. == Plack == I bet you already have heard of Plack, because Koha developers have been talking about it for ages. Basically it is just an interface between the web server (Apache, starman, etc.) and the perl application (Koha). When a user hits the a Koha url, a lot of files (Perl modules) are compiled. In CGI mode, this compilation step is done for every request. Using Plack they are compiled only once. The code will be put in RAM and other requests won't need to process all the modules again. It is an advantage since we are using DBIx::Class more and more and its schema is heavy to load. With Plack it is only loaded once. Koha is now considered as stable under Plack for the last versions of Koha, so you must use it. To know about known bugs, you can follow bug 7172 which gather Plack related known bugs together. At this time there is only one patch not yet pushed, bug 17392 (ping QAer!). Note that a timeout issue seems related to Plack and is not yet resolved, see: Bug 16714 - Unexpected logout with "IP address change" (with SessionRestrictionByIP set) == Caching system == The way we are caching "stuffs" in Koha has really been improved recently and will continue to! Important steps have been done in this area. We are using Memcached - a memory caching system - to store big bunch of data that we do not want to recalculate or retrieve from the database everytime. For instance: - the sysprefs. A lot of them are retrieved from the database for each request - the biblio frameworks - the holidays - ... a lot of other things could/will be cached! A big step has been done when we decided to introduce a 2-level caching mechanism (bug 16044): we have now a in-memory L1 cache (flush at every request) and a L2 cache (Memcached). To understand how this mechanisms are useful, imagine a simple scenario: launch a search which will return 20 results. For each result we need to know the MARC bibliographic framework of the record. Say they are all using the default frameworkcode. Without any caching mechanism, we retrieved from the database the whole structure, 20 times, once per result. With our new caching mechanism, the information for the default MARC bibliographic framework will be retrieved on the first request, then put in both L1 and L2 cache. The 19 other results will retrieve it from the L1 cache. If the same or another user does a search, the framework info will be retrieved from the L2 cache for the first result, and the L1 cache will be populated. The other results will retrieve it from the L1 cache. Not sure this is clear, but catch me if you need more details :) All of that to say that if you are a developer, there are 3 other bugs with ideas to improve again the caching mechanism. They are all of them in discussion: Bug 16140 - Only clear L1 cache when needed Bug 16079 - Retrieving system preferences from database via DBIx is not fast enough Bug 15341 - Performance - Retrieve all sysprefs at once One which would be nice to have is: Bug 17261 - Add memcached configuration info to about.pl It will permit to display the memcached configuration in the about page. = MySQL 5.7 compatibility = If you are interested in using Koha with MySQL 5.7 (the default version for the last Ubuntu 16.04), you should take a look at bug 17258 and its dependencies. Koha is not ready at all for the new default sql_mode configuration of this version of MySQL (STRICT_TRANS_TABLES). = Security issues = A lot of security issues (CSRF and XSS) have been fixed for the last 4 months, and almost all of these fixes have been backported to stable releases. They are all reported under the 2 following omnibus: Bug 17096 - [OMNIBUS] CSRF protections Bug 14568 - [OMNIBUS] XSS in Staff Client Only one known bug is waiting to be QAed (but 17365). = Elastic search = There are no big new features pushed since the first big push. But a few bug fixes and enhancement are waiting to be QAed. You can find them on the dependency graph of bug 12478. Note that there are 2 known bugs, without patches: Bug 16660 - Elasticsearch broken if OpacSuppression is activated Bug 17373 - Elasticsearch - Authority mappings are not defined for UNIMARC Are there some UNIMARC users around? :) = RESTful API = Tons of patches have been submitted on bugzilla, but only few got attention from signoffers. If you are interested in testing of them, search for "rest api". = ReactJS = React is a JS library aimed to easier DOM manipulations. This topic is a recurrent one and developers involved in this discussion will be present at the hackfest. They should organise a discussion to reach a consensus once and for all. If accepted, it would be good to define guidelines and write complete examples. = Koha plugin system = It seems that people are curious about our plugin system. It would be good to revive the discussion on new and more powerful plugin system. See the discussion on the koha-devel list at http://lists.koha-community.org/pipermail/koha-devel/2016-May/042673.html = Transactions & exceptions = It would be good to see some developers organise a brainstorming session on the different topics that Tomas raised on his email to koha-devel a few weeks ago. http://lists.koha-community.org/pipermail/koha-devel/2016-September/043032.… = Mana = Paul presented us Mana (https://lists.katipo.co.nz/pipermail/koha/2016-July/045739.html) at the beginning of July. Morgan finished her internship and will be there are the hackfest to show us what she developed. Testers and QAers would certainly be welcomed to test and review this feature. = Hea = Hea is a website (http://hea.koha-community.org) collecting usage statistics from different Koha installations around the world. This feature is not enabled by default but is very useful for developers and other people loving statistics (so librarians isn't it?). If it is not done yet, you should enable this feature to join the 496 libraries already registered! One enhancement is developed and waiting for testers: 14608 - HEA : add possibility of sharing usage statistics in Administration page and Web installer Hope to see you ready to fix, translate, test or QA patches (and drink beers when everything is done) this week! Cheers, Jonathan

1 0

Migrating from koha 2.2 to koha 16.05
by Rodrigo Santellan 06 Oct '16

06 Oct '16

Hi, I have a question about the locations and from where it get the data of the marcs. For what I understand after running the move_marc_to_biblioitems.pl two new columns are created, marc and marcxml. And it moves all the data from marc_subfield_table to those fields. That has happen alright, my problem now is that I see the marcxml record this fields: <datafield tag="900" ind1=" " ind2=" "> <subfield code="b">n</subfield> <subfield code="c">a</subfield> <subfield code="d">m</subfield> <subfield code="g">2</subfield> <subfield code="h">2</subfield> <subfield code="k">a</subfield> </datafield> <datafield tag="908" ind1=" " ind2=" "> <subfield code="1">090903</subfield> <subfield code="2">t</subfield> <subfield code="3">2007</subfield> <subfield code="5">XXK</subfield> <subfield code="6">ENG</subfield> <subfield code="8">d</subfield> <subfield code="a">a</subfield> <subfield code="b">g</subfield> <subfield code="c">r</subfield> <subfield code="d">n</subfield> <subfield code="f">0</subfield> <subfield code="g">0</subfield> <subfield code="h">1</subfield> <subfield code="j">0</subfield> <subfield code="z">1</subfield> </datafield> But on the interface I can't find the fields 900 or 908! Not in the MARCdetail.pl or the addbiblio.pl those fields are empty. For what I see It take the value from there but is not populating them. What I'm missing? Regards and thanks for the help!!

1 0