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

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

How to get CAS based Single Sign On working?
by Koustubha Kale 25 May '15

25 May '15

Hi All, I have a situation where we have a main website based on Joomla. This Joomla site uses CAS to authenticate users. We would like users ( who have already logged in to the Joomla site via CAS) to be able to follow a link to Koha site and be logged in automatically ( e.g. Single Sign On ). I have got simple CAS ( not proxy CAS ) working with Koha ( version 3.2.6 ) using the same CAS server as used by Joomla site. Still when I login to Joomla site with CAS, and then go to Koha and click on login and follow the CAS login link, I am asked to fill up CAS login information again. How can this be avoided by using CAS SSO? I have read through http://wiki.koha-community.org/wiki/SSO_CAS_improvements and am confused by the statement "Note: simple sso cas support (no proxy) has been done already by biblibre, is in testing and should be released in Koha 3.2" in there. Does this statement mean that SSO is possible with simple CAS? If yes how to set it up? If not, I have also read through bugs 6012, 5630 and the CAS Proxy examples. Frankly I haven't been able to figure out how I can achieve the above required functionality based on all the reading. Any help is much appreciated.. Another related query is, Is it possible to automatically create users in Koha once they have authenticated with CAS? Regards, Koustubha Kale Anant Corporation Contact Details : Address : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), Maharashtra, India, Pin : 400601. TeleFax : +91-22-21720108, +91-22-21720109 Mobile : +919820715876 Website : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2

3 3

Fwd: Questionaire regarding Patron Privacy and Security
by Chris Cormack 07 Dec '14

07 Dec '14

Forwarded with Marshall's permission Would you be able to help me fill this out? Galen has already made a good start which I have pasted at https://etherpad.mozilla.org/YiC0J8efmw Also the Evergreen community are working on their response at https://docs.google.com/document/d/1RgTnQOITvm3B_yzBOTfAuPZgDZig7xQ3N7Euib8… Thanks Chris ---------- Forwarded message ---------- From: Marshall Breeding <marshall.breeding(a)librarytechnology.org> Date: 11 November 2014 02:55 Subject: Questionaire regarding Patron Privacy and Security To: Chris Cormack <chris(a)bigballofwax.co.nz> As you know, libraries are increasingly concerned with protecting the privacy of their patrons and in strong security. For an upcoming panel for CNI I have been charged with gathering data regarding how library management systems handle patron privacy and security. It would be great if I could have responses by November 21, 2014. Could you provide responses for the Koha? You are the one that comes to mind among those in the Koha community, but if there is someone else that you think should respond, please let me know. I really appreciate your help. I am interested in gathering some information regarding the current capabilities or options that systems offer today, looking forward to further progress in this arena toward more secure treatment of patron-related transactions. Given increasing concerns, I would expect that each company is working on providing a more secure environment. This data initially will be used for a briefing at the upcoming CNI Fall 2014 Membership Meeting, December 8-9, 2014: http://www.cni.org/events/membership-meetings/upcoming-meeting/fall-2014/pr… I also anticipate that this information would be helpful for other discussions, presentations, or reports. In addition to information provided by the developers of systems, I may also work with systems administrators of the various products for their perspectives on these security-related capabilities and options. I would greatly appreciate it if you could have your technical or product managers provide responses to these specific questions. It would also be helpful to have any additional comments or perspective whether these seem to be the best areas of concern regarding patron privacy, if there are alternative strategies that you are pursuing. I would also be interested to hear whether this topic has been raised also by your customers or users through enhancement requests or other product roadmap priorities. Does your online catalog or discovery interface: · Enforce encryption through SSL for all transactions involving patron activity · Offer the library an option to enable SSL for all transactions involving patron activity · Enforce encryption for specific pages or transactions involving patron details or login credentials · Offer the library an option to enable SSL for specific pages or transactions involving patron details or login details Does your client or interface for delivering functionality to library personnel: · Enforce encryption through SSL or other encryption mechanisms for all transactions · Offer the library an option to enable SSL or other encryption mechanisms for all transactions · Enforce encryption for specific pages or transactions involving patron details · Enforce Encryption for specific pages involving authentication of library personnel accounts · Offer the library an option to enable SSL for specific pages involving patron details · Offer the library an option to enable SSL or other encryption mechanisms for specific pages involving authentication of library personnel · Enforce encryption for transactions involving institutional financial data (acquisitions, patron fines, etc) · Offer the library an option to enable SSL or other encryption mechanisms for financial transactions How does your platform or system deal with the security of the storage of specific types of data: · Does your system store patron passwords or PINs as unencrypted text · Does your system store patron passwords or PINs as salted hash or similar mechanisms · Does your system encrypt patron details as they are recorded and stored? Are logs or other system files that include patron search or reading behaviors encrypted? Describe any other security measures in place that protect patron privacy as it is transmitted over local networks or the Internet from interception by any third party. One specific scenario that has been a topic of concern involves the presentation of e-book discovery and lending transactions via library catalogs or discovery interfaces. Describe any integration with third party organizations that could potential expose patron details, search, or reading patterns and measures that you have provided to strengthen privacy and security. Do the APIs allow or require encryption in requests or responses that include patron-related data? What limitations to security impact your system imposed by the APIs or protocols managed by external or third-part products? Would your company be interested in a standardized specification for the treatment of patron or financial data, similar to the way that PCI provides a compliance framework for e-commerce transactions? I really appreciate your help with this project. Please confirm that you will be able to respond and let me know if you have any questions or concerns. -marshall Marshall Breeding http://www.librarytechnology.org marshall.breeding(a)librarytechnology.org http://twitter.com/mbreeding http://www.linkedin.com/in/breeding http://scholar.google.com/citations?user=NnvfJ5cAAAAJ

5 5

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