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

Koha 3.18.0 released
by Tomas Cohen Arazi 01 Dec '14

01 Dec '14

It is with great pleasure that I announce the release of Koha 3.18.0, the latest major release of the Koha open source integrated library system. Koha is the first free and open source software library automation package (ILS). Development is sponsored by libraries of varying types and sizes, volunteers, and support companies from around the world. The Koha 3.18.0 tarball and install instructions can be found on the download page: http://koha-community.org/download-koha/ More install instructions and useful information can be found on the wiki ( http://wiki.koha-community.org/wiki/Installation_Documentation) and in the INSTALL files that come in the tarball Koha 3.18.0 is a major release, that comes with many new features. It includes 14 new features, 120 enhancements and 487 bugfixes. See the complete release announcement on the community site: http://koha-community.org/koha-3-18-0-released/ Kind regards, Tomás Cohen Arazi, Release Manager for Koha 3.18

2 1

Question about debian scripts
by Mark Tompsett 28 Nov '14

28 Nov '14

Greetings, After faking out my development environment (may have gotten the commands wrong, since ln trips me up sometimes): $ sudo ln -s ~/koha-dev/etc /etc/koha $ cd ~/koha-dev/etc $ mkdir sites $ mkdir library $ ln -s ~/koha-dev/etc/koha_conf.xml koha_conf.xml $ cd /usr/share $ sudo mkdir koha $ cd koha $ sudo ln -s ~/kohaclone/debian/scripts bin QUESTION: Is this too evil? I attempted to: $ git bz apply 13413 $ ./debian/scripts/koha-passwd library Now it worked, but... “Press any key to clear the screen...” wasn’t any key, it required enter/return. Currently it is a sh script. If we made it bash, the line: read anykey could become: read -N1 anykey And then it really would be any key. QUESTION: Do all the koha command scripts need to be only sh? GPML, Mark Tompsett

4 3

UTF-8 work on the 3.20 release cycle
by Tomas Cohen Arazi 27 Nov '14

27 Nov '14

First of all, I'd like to thank everyone involved on bug 11944. An specially people working hard on bug 13264 to have integration tests on the UTF-8 big rewrite. That said, it is too late for that to go into 3.18 for the release now. I'll try to add my bits on 13264 so we have all the 11944 pushed into master ASAP once 3.18.x is branched. For 3.18, please fill bugs on encoding problems, and also sign on those that are marked as 3.16 so they can be pushed to the stable branches. Thanks everyone, this work is really important and we are getting it ready for pushing ASAP.

2 3

Double encoding of query_cgi
by David Cook 26 Nov '14

26 Nov '14

Hey all: It looks like there's a problem with the double encoding of query_cgi (at least in the OPAC). It looks like Bug 9239 (commit a8f23264) was responsible for adding uri_escaping to query_cgi into C4::Search. Unfortunately, we also run query_cgi through "html" and "url" filters on almost every .tt template page it features upon. This means that we always have double-encoded query strings, which. isn't really a problem most of the time. Chrome and Firefox seem to be able to handle double encoded query strings just fine. There might be certain conditions where problems arise due to what's put in the query string. but I haven't tried a million test cases. I suppose the thing I'm wondering is. do we remove the filters from the templates or stop encoding in the module? David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007

2 1

upcoming_digest?!
by Mark Tompsett 26 Nov '14

26 Nov '14

Greetings, I was reading misc/cronjobs/advance_notices.pl and was trying to make sense of where $upcoming_digest is set. I think there must be some side-effect obscuring the code. I was wondering if a second pair of eyes might find it. I was trying to determine how $digest->{email} gets set for the from_address call to C4::Letters::EnqueueLetter. GPML, Mark Tompsett

7 6

Fwd: Streamlining frontend development in Koha
by Jesse 25 Nov '14

25 Nov '14

I've been working on Rancor, a professional MARC editor for Koha sponsored by ByWater and DGI, for the past year or so. As Rancor has a lot more client-side complexity than many other parts of the staff interface, I've run into some major frustrations. I have a proposed solution for them, and would like feedback from both developers and translators: Let's rewrite Koha in GWT! But seriously. The issues come down to translation. Making cleanly translatable JavaScript frontend code using Koha's current system requires a lot of finagling and ugly syntax, especially for any complicated string. There are two problems. Problem One: For example, displaying "You have checked out X books, Y of which are on hold" is frustrating to impossible for either the developer or translator: _("You have checked out ") + X + _(" books, ") + Y + _(" of which are on hold") is easy for a developer to write, but gives the poor translator three separate strings to translate. The commonly given solution is to rewrite this as: _("Books checked out: ") + X + _("Books on hold") + Y which works, but is a bit less elegant, and not always realistic. An informal best practice that has some precedent in the OPAC and Datatables is to use named placeholders in the string: _("You have checked out __X__ books, __Y__ of which are on hold").replace("__X__", X).replace("__Y__", Y) This is good, but currently has to be rewritten for every translated string. I'd like to propose a syntax like the following: _$("You have checked out $1 books, $2 of which are on hold", X, Y) or _$("You have checked out $X books, $Y of which are on hold", {X: X, Y: Y}) with a slight preference for the former. Either approach allows translators to reorder substitutions as needed. The exact details of the syntax are up for debate, but something that can be implemented once, thrown into staff-global.js, and used everywhere is the goal. Either approach would be treated the same as: _("You have checked out $1 books, $2 of which are on hold") for the purposes of generating .po's and creating translated templates from existing .po's. Problem two: Currently, for JavaScript code to contain translated strings, it must be placed within a .tt or .inc. This is a historic limitation of the translation scripts (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4503) The stated reasons for not fixing it, besides the hairiness of the translation scripts, are that a) most JavaScript code has been moved to non-language specific directories and b) there are property-based translation systems available for JavaScript (see the datatables-strings.inc file for an example of how the latter works). Here are my reasons for disagreeing with these two points: a) Keeping most JavaScript code non-language-specific is a very laudable goal, both in terms of separation of concerns and deduplication of files in multi-language installs. I believe that the translation system should allow for translation of strings in .js files, however. Despite factoring out many modules and pieces of UI infrastructure using Require.JS, Rancor is currently sitting at ~1200 lines of code that deal with showing error/informational messages to the user, all of which has to be in a .tt or .inc in the current system. This is untenable for any complex JS code. b) While this is more of a matter of taste, I do not like the properties-based translation system. For one thing, it punts the above problem to a solution like is used for datatables, with the translation strings in a .inc containing a single <script> and the rest of the code in a .js. Also, it introduces a layer of indirection that makes figuring out what is actually displayed to the user (and tracing where a given message came from) needlessly complicated. I believe that while the QA process should continue to encourage splitting out as much functionality as possible into non-language-specific JavaScript, _requiring_ it causes problems. I propose that the translation scripts be extended to process _() (and possibly _$()) directives in .js files in language-specific .../js/ directories. (Note: this is not a "I think this is a fantastic idea that someone else should work on" proposal. I am willing and in fact eager to make these changes. But it would affect many people, so I want your thoughts first.) -- Jesse Weaver

4 5

Critical bug on notices
by Jonathan Druart 25 Nov '14

25 Nov '14

Hello, On master, we are not able to create/copy the same letter (letter code) on different sites (branchcode). Bug 13215 should fix this critical issue. It's not conceivable to have Koha 3.18 released without a fix for this problem. It's still in the 'needs signoff' queue. I can fix quickly any regression or problem you will find testing this patch. Feel free to provide another patch if you like. Cheers, Jonathan http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13215

1 0

Middleware for RFID implementation with Koha
by DP Tripathi 25 Nov '14

25 Nov '14

Dear All, I am trying to integrate RFID Device with Koha but have been unsuccessful. Looking for any middleware (open source) which can solve my problem. Or any tool using which I can develop the same. Thanks -- ********************* D. P. Tripathi Assistant Librarian Biju Patnaik Central Library NIT Rourkela Odisha - 769008 **********************

1 0

Sign off request...
by Mark Tompsett 24 Nov '14

24 Nov '14

Greetings, I was hoping that someone might look at http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11592 opac detail scripts do not respect MARC tag visibility The differences in what appears between Normal View and Marc View (and potentially ISBD view) differs even if some things are marked as not visible. It’s too late for 3.18, but it would be great to get a sign off. I just rebased it. There is a pretty good test plan that should be easy enough to follow. GPML, Mark Tompsett

2 5

Tied Hashes in suggestions.pl and opac-suggestions.pl
by David Cook 24 Nov '14

24 Nov '14

I've noticed that suggestions.pl, opac-suggestions.pl, and other old code make use of the Vars() CGI method. "Called in a scalar context, it returns the parameter list as a tied hash reference. Changing a key changes the value of the parameter in the underlying CGI parameter list." This has some problems. When you manipulate the tied hash reference, you're changing the underlying CGI object. That means that calls to $input will change depending on what you've entered into $tied_hashref. 99% of the time, we probably do NOT want to do that. In suggestion.pl, it creates all sorts of weirdness: ~line 245: unless ( exists $$suggestion_ref{'branchcode'} ) { $$suggestion_ref{'branchcode'} = C4::Context->userenv->{'branch'}; } ~line 303: my $branchfilter = ($displayby ne "branchcode") ? $input->param('branchcode') : ''; $$suggestion_ref itself is tied to $input->param(s). So in the first case, by default, there won't be a branchcode. So we stuff in the user context branch. In this case, it's a debatable idea. I've noticed a few librarians complaining about not being able to find suggestions, and it's because of this default branch filter which isn't obvious at all. But that's a side note... Anyway, once $$suggestion_ref{'branchcode'} is changed, $input->param('branchcode') will also be changed, as they rely on the same hash in the CGI object. I was going crazy over this one... I couldn't see how $input was being set at all! Then I figured out that $suggestion_ref was a tied hash ref. It makes the following line utterly redundant: ($branchfilter and $branches->{$thisbranch}->{'branchcode'} eq $branchfilter ) || ( $$suggestion_ref{'branchcode'} and $branches->{$thisbranch}->{'branchcode'} eq $$suggestion_ref{'branchcode'} ) $branchfilter will always be the same as $$suggestion_ref{'branchcode'}. In terms of the end result. it might not matter so long as we keep that earlier condition "unless ( exists $$suggestion_ref{'branchcode'} )" so that we're not overwriting the real CGI parameter with our user environment variable. However, it makes for some ridiculous code. It took longer than I would've liked to figure out what was going on there. I rather improve code readability and not have situations where we might accidentally be changing underlying variables without knowing it. This might even have a few issues in these scripts that I haven't noticed. Actually, I have noticed a problem in opac-suggestions.pl because of this very issue. ~line 37 in opac-suggestions.pl: "my $suggestion = $input->Vars;" We later try passing $suggestion to a DBIC object, but it croaks because the template used "branch" while the DBIC object expects "branchcode". We should probably be using the param() method to explicitly build our data structure. Using Vars() also has other consequences. If we add a CGI parameter and don't delete it in the opac-suggestions.pl script (like we're already doing for 'op') then we're going to get more errors. If this were set up as a service and the client sent some additional information, it would croak. I suppose what I'm trying to say is. we should keep this in mind when we're writing new code and when we're looking at old code. opac-suggestions.pl will need a patch just to start working again (although the easiest fix there is to change the template rather than the perl script). Alas, I don't have time at the moment to tidy up these scripts. I found out what I need to know and now I have to move onto the next issue. I don't mean this to be a "someone should fix this" email. Rather a FYI. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007

1 0