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

What's on in koha-devel #10
by Jonathan Druart 08 Feb '17

08 Feb '17

Hello librarians and developers, Several interesting initiatives emerged in this beginning of year 2017. Lot of things need to ready for the next stable release in March. If you have some spare time, do not hesitate to get involve and make things you love moving forward :) = Catalyst academy = Let's start with the yearly Catalyst academy week. The Open Source Academy is a Catalyst initiative designed to provide training & work experience in open source development for young New Zealand technologists. We got signoffs and patches from 6 students (Zoe, Luke, Grace, Karen, Caitlin and Emma) and they all got at least 1 patch pushed into master this week [1]. Congrats to all of them! Looking forward the next one :) = Move marcxml out of the biblioitems table (bug 17196) = Well, that's it, it's in and will be in 17.05! I'd like to specially thanks Mason, Josef, Zeno, Nick and Marcel to have been involved in the testing and QA process of this important change. It will offer us more flexibility in the future for new developments as well as bring us performance boost in few areas. Since that change will break lot of reports, I have worked on a way to automatically detect the problematic reports and automagically convert it using the new columns. I think we really need it for the next major release, take a look at bug 17898 (Add a way to automatically convert SQL reports). = Dashboard = I have submitted a pull request which has been quickly merged (thanks Chris!). The dashboard (http://dashboard.koha-community.org) now displays a "Overall bug tracker health status" with the number of blocker, critical and major bug reports opened over the last 60 days. If you want to quickly know which are the hot patches waiting for you, just click on the link and you will get the bug list. =Bootstrap 3= The bootstrap library used for the staff interface has been upgraded to the version 3.3.7. Lot of work has been done by Josef and Owen to make the staff interface looking awesome. Elements like buttons, links, icons, modal windows have been homogenised. Some work are still in progress but the big step has been done. You can take a look at the depend patches of bug 17873 (Make all buttons Bootstrap styled) if you want easy signoffs. = Hea - Share your statistics with the community = Few days ago I have submitted patches for a proposition of what could be Hea version 2. If you want more informations, take a look at bug 18066 and especially the comment 2 about screenshots. Developers are very welcome to test, and librarians to give their opinion on what could be missing to make Hea better. I would also like to get help from a native English speaker to add more informations on the administration page to explain better what happens (and what will not happen!) when an option or another is set. = Refactoring = Lot of refactoring bug reports are waiting for testers and QAers. Everything has been stuck for the last month. I really would like to see more attention on these bugs, to continue the work in progress. To know how you can help, take a look at this graph: https://bugs.koha-community.org/bugzilla3/showdependencygraph.cgi?id=15449 Zoom out, zoom out, once again. If you are a signoffer, pick the orange boxes, if you are a QAer, look at the yellow ones. = Template Toolkit syntax for notices = This is certainly one of the most important area if you want to help us getting this in for the next release. These are quite lot of things to do to get something ready. First we want to make sure we will not get regression using the TT syntax. To prove that, I have opened an omnibus (see bug 17961 and related bugs - TT syntax for notices - Prove we have an equivalent for our historical custom syntax). A huge amount of tests are provided to prepare the ground and safe our backs for later. It is, in my opinion, the important part of the work. All of these patches are easy to test. To ease the migration for libraries, I have developed an interface to automagically convert the notices from the historical syntax to the TT syntax. You can take a look at bug 17981 and bug 18007 for this interface change. To test *all* of this stack change, you just need to checkout the remote branch from my github repository [2] Screenshot of the convert interface: https://pageshot.net/pVRqSxln4A9cqjtM/pro.kohadev.vm = Authority merge bugs = Marcel is reworking the authority merge feature. It is quite buggy and the code is hard to maintain currently. You can take a look at bug 17908 (Authority merge omnibus) and all related bug reports to help and/or follow the progress. The next general IRC meeting is on March 1st, 20 UTC. https://wiki.koha-community.org/wiki/General_IRC_meeting_1_March_2017 The next dev IRC meeting is today (!) at 20 UTC https://wiki.koha-community.org/wiki/Development_IRC_meeting_8_February_2017 Hope to see your there! Cheers, Jonathan [1] https://wiki.koha-community.org/wiki/Catalyst_Academy [2] https://github.com/joubu/Koha/tree/bug_17981

1 1

Koha development meeting reminder
by Nick Clemens 07 Feb '17

07 Feb '17

Hi All, The next Koha development meeting is on IRC tomorrow 08 February 2017 at 20:00 UTC You can see what that is in your local time here: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+I… Agenda is here: https://wiki.koha-community.org/wiki/Development_IRC_meeting_8_February_2017 Please make sure to add any topics you wish to discuss. See you all soon!

1 0

Github
by David Cook 07 Feb '17

07 Feb '17

Looking at Moodle's Github, I notice a line that says "mirrored from git://git.moodle.org/moodle.git" (https://github.com/moodle/moodle) I know https://github.com/Koha-Community/Koha is supposed to be a mirror of "git://git.koha-community.org/koha.git", so I was thinking that might be nice. although it seems like adding/updating that "mirrored from" is easier said than done: https://issues.apache.org/jira/browse/INFRA-9978. But I've been looking around and it seems that you might be able to turn off pull requests? Is that something folk would want to do? I've noticed other Githubs add their own little subtitle saying that it's just a mirror of another Git. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595

1 0

KohaDevBox updates
by Tomas Cohen Arazi 06 Feb '17

06 Feb '17

Hi everyone. I've just pushed some updates I had on my working branch for the KohaDevBox: Updates: (a) Support for setting ElasticSearch 5.1 (b) Fixes for instance creation errors Details: (a) For supporting ElasticSearch 5.1 I've removed references to '2.x' in the code (either for repository configuration or display messages). So you should now set in your vars/user.yml file either: elasticsearch_version: '5.x' elasticsearch_version: '2.x' elasticsearch_version: '1.7' for the desired ES version. (Note: the quotes are required) ES 5.1 requires higher RAM availability so I made the Vagrantfile set 4GB of RAM when KOHA_ELASTICSEARCH=1 is set in ENV when doing the 'vagrant up' command. You can tweak the Vagrantfile locally to whatever you want (lower value?). This has all been documented on the README.md file This should be enough for being able to test https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17255 If there's something missing, please file a bug in https://github.com/digibib/kohadevbox/issues/new so we take care of it. As usual, pull requests are welcome. (b) There have recently been some changes on the koha-* scripts so they don't (only) have hardcoded paths, but accept a new entry in koha-conf.xml (<dev_install>) which specifies the place to pick the source code from. Pretty cool! But this made koha-gitify fail to set all it is needed to keep working as we did before. As a workaround I've added a fixed <dev_install>{{ vagrant_home_dir }}/kohaclone</dev_install> entry to the koha-conf-site.xml.in file we ship with KohaDevBox. Ideally, we should just add --dev-install and --dev-install-dir options to koha-create and just (probably) deprecate koha-gitify. I'm not sure what is the best solution. koha-gitify does lots of path fixes in places that are not related to koha-* scripts (zebra configuration files, koha-conf.xml itself, etc). I'm raising this so we can discuss the best way to deal with this. Having a koha-gitify-like feature baked inside Koha is not a bad idea at all! I'd like to highlight that I haven't succeeded in figuring why installing Test::DBIx::Class fails randomly. I blamed CPAN mirrors at some point because the default one was returning 'not found' when fetching the sources. But that doesn't seem to be the ONLY cause for failures. Any help on this is welcome. The way to check what's going on is to comment out that step and log into the box and cpanm manually. The most important on this regard: don't feel bad when the box fails to load because of this stuff. Remember you can 'continue' the process by reprovisioning. It is important to keep in mind that you need to do it with the same params you chose for 'vagrant up'. For example, I always do: $ KOHA_ELASTICSEARCH=1 SKIP_WEBINSTALLER=1 CREATE_ADMIN_USER=1 vagrant up so, if it fails to install something (temporary network issues? the weird Test::DBIx::Class random failure?) I always do: $ KOHA_ELASTICSEARCH=1 SKIP_WEBINSTALLER=1 CREATE_ADMIN_USER=1 vagrant provision No need to halt and reload the machine. I'm not sure why people are doing it, but don't. Unless you have specific reasons to do so. It will eat a couple minutes from your time with no evident advantage. Thanks for reading, and for the recent pull requests we've got. Have a great weekend! Tomás -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

2 1

Hello, and question about kohadevbox
by Mark Alexander 05 Feb '17

05 Feb '17

Hi all, I'm a newbie here, and have been working on setting up a Koha git environment. The kohadevbox project looked good, so I gave it a try just now. The provisioning went fine until the koha-create step: fatal: [jessie]: FAILED! => {"changed": true, "cmd": "koha-create --create-db kohadev", "delta": "0:00:06.582852", "end": "2017-02-01 20:02:32.211551", "failed": true, "rc": 1, "start": "2017-02-01 20:02:25.628699", "stderr": "", "stdout": "Koha instance is empty, no staff user created.\nStarting Zebra server for kohadev", "stdout_lines": ["Koha instance is empty, no staff user created.", "Starting Zebra server for kohadev"], "warnings": []} I ssh'd into the VM and tried removing the kohadev instance and recreating it by hand, and it appears that koha-create returns a non-zero status, even though it appears to have been successful: vagrant@kohadevbox:~$ sudo /usr/sbin/koha-create --create-db kohadev Koha instance is empty, no staff user created. Starting Zebra server for kohadev vagrant@kohadevbox:~$ echo $? 1 vagrant@kohadevbox:~$ Is there some way I can get vagrant to ignore the non-zero result from koha-create, and restart the provisioning at the point where it left off? Thanks in advance!

4 6

Need help for a new calendar (performance improvement and library opening hours) BZ17015
by Francois Charbonnier 03 Feb '17

03 Feb '17

Dear community, We submitted a patch recently that would benefit many. It solves two old bug put on hold for a while (Move calculation code out of C4::Calendar) and (hourly loans doesn't know when library closed). If you a have a bit of time ahead of you to help us get it upstreamed. It will be much appreciated! When I read again the description from bugzilla, I felt that an overview of the work and its benefits will help you get involved. * *_*Short version*_ : The communinity and some of our clients noticed two issues : 1. Hour loans doesn't know when a library is closed 2. We have performance issues when checking in overdue book or managing overdue fines. We identified that both issues are related to the way Koha does date calculation. To improve and fix these issues, we developped a new calendar with a couple of new features. _The benefits of this new calendar are_ : 1. management of the libraries opening hours (new feature). 2. performance improvement when circulating items and managing fines. In particular, when checking in overdue book or managing overdue fines. 3. help to setup holidays/closed days from one year to another (new feature) To acheive this, we redesigned the calendar database table and rewrote part of the code in charge of the date calculation. We used this work to move part of the code and separate what's in charge of the calendar and what's used to do the calculation. This way, we solved two bugzilla issues opened a long time ago : https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11211 (Move calculation code out of C4::Calendar) (opened by Jesse Weaver on the 2013-11-06) https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8133 (hourly loans doesn't know when library closed) (opended by Nicole C. Engard on the 2012-05-21) For now, BZ 11211 blocked BZ 8133. All features from the old calendar is available in the new calendar. The new calendar passed all the unit tests. The patch for the new calendar is here : https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17015 _* *__*Long version*_ : The calendar's database table contains only rules to set whether the library is closed or not. If Koha needs a date or a range of date (was the library closed that day? how long is this book overdue? etc.), it has to be calculated using these rules. Depending on the type of transactions, how Koha does the calculation is not always efficient. For example, a return of overdue books can take as long as many seconds (for 2 months old overdues for example). We redesigned the calendar table to be able to give Koha the information it needs to do the calculation in a more efficient way. In the calendar's new table, we don't store rules anymore. Each day from the calendar is now stored (an entry for each day). For each day, we can indicate if the library is open or closed. We took this redesign opportunity to add the library opening hours as well. That way, Koha gets straight the information it needs to determine if the library is open or not, it can take into consideration the opening hours (good for hour loans and the date range calculation is simplified by using the information stored in the database. No need to calculate it based on different rules anymore. Among the patches we submitted, we have a script to benchmark checkin and checkout transactions. The benchmark of checkin is more indicative of the performance improvement. Here is an example of collected statistics. When an item is returned the day the checkout expires, the calculation time decreased of 22% (for 100 checkins, the calculation time drops from 52.2s to 40.7s). When an item is 2 months overdue and returned, the calculation time decreased of 70% (for 100 checkins, the calculation time drops from 154s to 46.6s). _How does the new calendar work_ ? Before the first use, a script will populate the new calendar table with on entry for each day of the year. This script can retreive your actual setting to keep track of your old set up. It also creates all the entries for future years. The basic set up would be : the library wants to have a 1 year overview of the calendar so they can set it up in advance. The script creates every entry in the table to be able to set up the calendar 1 year in advance. Then, another script will be scheduled to run every day. This script will add a new entry for every day spent. In this manner, Koha keeps a 1 year advance overview at all time. The advantage of this last script is to help the koha admin to set up the calendar in advance. Each time the script will add a new entry (a new day), it will check one year in the past how the same day was set up to try to determine if the library should be closed or not : - If the date is a unique holiday : the script will not keep it for the new entry. - If the date is a repeatable holiday : the script will keep it. (For example, a library closed every saturday) - If the day type was "floatting" (it's a new type of holiday) : the new entry status is "needs confirmation". Thus, when setting up the calendar, I have two options : 1. I know it's a repeatable holiday every year or very week, I choose the date type 'repeatable'. When the script add a new entry, it keeps the holiday. 2. I want to check the holiday every year to adjust the settings (for example, Easter stat holiday), I choose the new date type "floatting". Then, when the script add a new entry, it doesn't assume the library is closed but change the date status to "needs confirmation". Then I will be able to overview these "need confirmation" holidays and set them up when I get the information. The script manage the opening hours as well. It checks the previous week settings instead of the previous year. The other new feature to help setting up the calendar is in the way Koha can create holidays between two dates. When creating this range of dates, you can : - either use a specific day and copy its settings to all the dates in the range. - or use a range of dates and copy the settings of each day to each day of the new range. Besides that, the calendar keeps all its actual features. The patch for the new calendar is here : https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17015 Thank you very much! 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 | Spécialistes en technologies documentaires | www.inLibro.com <http://www.inLibro.com>

1 0

New Contributor
by Baptiste Wojtkowski 03 Feb '17

03 Feb '17

Hello, I am Baptiste and I will work at Biblibre during 6 month (until July, 15th) . I will work at fixing bugs on koha and mana. Baptiste Wojtkowski

1 0

proper sorting order and search for Swedish characters and ISBN search
by Gaetan Boisson 02 Feb '17

02 Feb '17

Hello, I have been trying several things to try to sort this out, and haven't found a way (yet) that would avoid ugly compromises. The issue is: in Swedish ä, ö and å are separate letters. Not variants of a and o. This means that searching for å shouldn't bring up a. When sorting, they belong to the very end of the alphabet, after z, not along a and o. ICU has some kind of setting that allows to standardize isbns for searching, so you can search for any hyphenated variant, and still find the isbn that actually appears in your data. I *think* this works by removing all the hyphens in the index, but i am not quite sure. Anyway, in order to get the Swedish letters right, we had to do some specific chr configuration. Doing this forces us not to use ICU, which means giving up on standardized isbn search. Alternatives are transforming all the isbns in the records (quite uly). Or using the SearchWithISBNVariations syspref, but as far as i understand, this only works when using the dedicated isbn index, not in the simple search. Has anyone found a more satisfactory way of handling this? Thanks, -- Gaetan Boisson Chef de projet bibliothécaire BibLibre +33(0)6 52 42 51 29 108 rue Breteuil 13006 Marseille gaetan.boisson(a)biblibre.com

6 6