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

ldap authentication in koha 16.11 become broken when enabling plack
by Mohammad Nashbat 12 Dec '16

12 Dec '16

Hi All, We've recently upgraded to Koha 16.11 which is running on Debian Jessie, we also activated plack which makes the system really faster than before but found out that Koha ldap authentication become broken, but when we disabled plack it works fine with slowness. Any help to make koha ldap integration works with plack is highly appreciated. Thanks & Best Regards, Mohammed Nashbat Library Instructor Alfaisal University ________________________________ DISCLAIMER: This electronic mail transmission contains confidential information intended only for the person(s) named. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you received this transmission in error, please notify the sender by reply e-mail and then destroy the message. Opinions, conclusions, and other information in this message that do not relate to the official business of Alfaisal University shall understand to be neither given nor endorsed by Alfaisal University. The contents of any attachment to this e-mail may contain software viruses, which could damage your own computer system. While “Alfaisal University” has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening the attachment.

1 0

What's on in koha-devel #8
by Jonathan Druart 05 Dec '16

05 Dec '16

Hello librarians and developers, Koha 16.11 and its Debian packages have now been released [1]. As Mirko noted Debian Wheezy is no longer supported and Debian packages won't be provided for 3.22 [2]. I should also added that some important bugs have been reported recently and it may be better to wait for the 16.11.1 version to be released before upgrading [3, 4, 5]. Note that if you database password contain Unicode characters, you should also wait for bug 17720 (CSRF token is not generated correctly). = Refactoring = == Move to the Koha namespace == We keep on moving the C4::Members module code to the Koha namespace and a few subroutine of C4::Circulation are going to be moved as well [6]. == Remove the biblioitems.marcxml field == I have been asking for help on bug 17196 (Move marcxml out of the biblioitems table) for months now and this will certainly be my last attempt to get attention on it. As we are at the beginning of the release we should focus on it to get it pushed soon. That way we will have time to catch and fix bugs if we find some. == Rewrite of the upload feature = A month ago Marcel started to refactor the upload section [7]. This is the groundwork to start improvements in this area. Once this is pushed we will be able to add new features, so please test! = Template Toolkit syntax for notices = Kyle started a discussion some months ago [8] to switch from our home-made syntax for notices to the Template Toolkit syntax. That would bring us a lot of flexibility to write the notices. But to do so, we need a plan! We already started to support this syntax (inside 16.11) but then we have to decide what to do next. Currently the plan would be to replace the default syntax (bug 15278), then reveal in the editor that you can use this new syntax (bug 15277) and finally add documentation to help people writing/porting their own notices (bug 15276). We need to get opinions to know how we could move forward. Kyle is going to start a new topic on the Koha mailing list for that. Stay tuned! = Standardize our EXPORT = A bit more technically, I would need developer's attention on bug 17600 (Standardize the EXPORT). At the end of the last release, very bad bugs appeared at the last minute because of our circular dependencies and the way we export subroutines from routines. Everything is (quickly) explained on that bug and a patchset has been submitted for discussion. If you are aware of how we could fix that cleanly, please jump into the discussion. The next general IRC meeting is on December 7th, 14 UTC. https://wiki.koha-community.org/wiki/General_IRC_meeting_7_December_2016 The next dev IRC meeting is on December 14th, 13 UTC. https://wiki.koha-community.org/wiki/Development_IRC_meeting_14_December_20… Hope to see your there! Cheers, Jonathan [1] https://koha-community.org/koha-16-11-released-2 [2] http://lists.koha-community.org/pipermail/koha-devel/2016-November/043330.h… [3] Bug 17676 - Default COLLATE for marc_subfield_structure is not set [4] Bug 17344 - Can't set guarantor in quick add brief form [5] Bug 17709 - Article request broken [6] Bug 17677 - Move C4::Circulation code to the Koha namespace [7] Bug 17501 - Koha Objects for uploaded files [8] http://lists.koha-community.org/pipermail/koha-devel/2016-February/042316.h…

1 0

942 versus 952
by Karen Myers 02 Dec '16

02 Dec '16

Hi all I am wanting to clarify the usage of the 942$c field versus the 952$y field as I am setting up a new bib framework. I am wondering if it is necessary to have both the 942$c field and the 952$y field in the framework as they seem to record the same information i.e Koha item type. Is there an advantage to recording the same information in both fields and if not which is the preferred? We are using Koha 3.22 thanks! Karen

3 3

Improvements to framework plugins (cataloguing)
by Marcel de Rooy 02 Dec '16

02 Dec '16

Hi all, Around two years ago I wrote Koha::FrameworkPlugin now. As an ongoing project I wanted to convert existing plugins to its new style (while it also supports the old style). Unfortunately, this project did not get much further the last six months of 16.11. Two reports https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13438 and https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16203 are just waiting for a signoff already over 6 months, while they still apply. Since one report deals with normarc plugins, I hoped for Magnus, but unfortunately.. I am still hoping for some attention. Further development in this project depends on it. Testing them should not be that hard. Thanks, Marcel

1 0

Koha Community Newsletter:November 2016
by kohanews 30 Nov '16

30 Nov '16

Fellow Koha users: The Koha Community Newsletter for November 2016 is here: https://koha-community.org/koha-community-newsletter-november-2016/ Many thanks to the folks who submitted articles and news to this month's newsletter. Please feel free to email me with any corrections or suggestions. Thanks! -- Chad Roseburg Editor, Koha Community Newsletter

1 0

Questions regarding localization
by Roger Grossmann 29 Nov '16

29 Nov '16

Hi all, as a Koha development newbie I am having a few questions especially with localization. I am developing enhancements which I plan to bring in to the community hopefully soon. Your answers will help to make progress with it. 1st question ---------------- After looking at much Koha code I did not find a solution to build server side localized strings to persist localized text in the database. What do you recommend to use here? Background: As you know, fines and fees are a sensitive area. Borrowers like to know exactly why they are charged and for what exactly. Lets assume, you want to store good localized name for the type of an overdue fine. It was for instance planned for function "UpdateFine" in C4::Overdues but the parameter $type is never filled as originally planned. If an additional type name would be passed here, it needed to be a localized string since borrowers want to read the charge reason in their language. As this is just an example for the use of a localized server text, the question is, whether there is already an approach to manage localised server side texts. Ideally, server side texts would support parameter replacement that is not dependent of the position in the text as for instance with %s using sprintf. 2nd question ----------------- I want to build some new UI functionality. The procedure how to do that with templates in english first is clear to me. As I am German, I would like to build during development a first German version of the template as well and would like to extend the related German .po file. How can I add the texts for a specific language in my development environment? Is there a way to extract the new texts of templates and add them to an existing .po file with a script and use poedit to translate them? How do you do that? Thanks in advance for your help. Best regards, Roger -- Roger Großmann LMSCloud GmbH Konrad-Zuse-Platz 8 - D-81829 München t +49 (0)89 207042-620 m +49 (0)171-2194775 f +49 (0)89 207042-623 e roger.grossmann(a)lmscloud.de w www.lmscloud.de

2 3

Koha 16.11.00 Debian package released
by Mirko Tietgen 28 Nov '16

28 Nov '16

Hello everyone, the Debian package for Koha, koha-common 16.11.00, is now available from the community repository. Please note that with the new release, the codename/version relationship shifts to stable 16.11 oldstable 16.05 Koha 3.22 is still maintained, but there won't be new Debian packages for this branch an longer. Koha 16.11 requires Debian Jessie. Debian Wheezy is not supported any longer. The same goes for future versions of Koha 16.05. We still have problems with Koha and MySQL 5.7. If you want to run Koha 16.11 on Ubuntu, you will probably have the best experience with Ubuntu 16.04 LTS and MariaDB instead of MySQL 5.7. If you are running Koha 16.05 now and want to stay on this branch, please make sure to change your apt configuration to use the oldstable branch. To upgrade to Koha 16.11, use stable in your apt configuration and do apt-get update apt-get upgrade apt-get dist-upgrade Please report any bugs you may encounter to http://bugs.koha-community.org/ Cheers, Mirko -- Mirko Tietgen mirko(a)abunchofthings.net http://koha.abunchofthings.net http://meinkoha.de

1 0

Koha Wiki Facebook
by Kyle Hall 28 Nov '16

28 Nov '16

Hello All! You can think Nick for finally pushing me to put up all the photos from the HackFest! For the uninitiated, for a long time I've been wanting to have a Koha community facebook, in the original sense of the word. So here it is! https://wiki.koha-community.org/wiki/Community_Facebook *Please* feel free to add and update this page. If you see any misspellings or misinformation, please correct it! In particular, I wasn't able to add the diacritics to names. If you are not listed, please add yourself! You can upload a file and edit the wiki page. If you need help doing so, please let me know! Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org )

2 1

Koha and Qvarn, a suggestion (also too long for anyone to finish reading)
by Lars Wirzenius 28 Nov '16

28 Nov '16

Hi, Koha developers, some of you may remember me from the Debian packaging of Koha I made in 2010 for Catalyst IT. I've never looked much at the actual code base of Koha, but one thing that even a quick grep reveals is that SQL code is sprinkled all over the code base. To me, this indicates that the application code ("business logic") and the way data is stored are closely coupled, and that's generally not a good thing. Among other things, if there's a need so change the database schema, or database engine, the whole code base might be affected. In my current job we develop a storage system (roughly, "database, but with better access control") with an emphasis on privacy. Our software is free software released under the Affero GPL, version 3 or later. I suggest that our software (called Qvarn) would be worth considering for Koha. A summary of my impression of the situation: * Koha stores very sensitive information about people's reading habits. * In the EU the new General Data Protection Regulation (GDPR) is in effect (with a transition period until some time in 2014), which requires everyone who collects or stores personal information to take good care so the data doesn't leak and violate people's privacy. Koha, or at least libraries using Koha, would seem to fall under this (IANAL, TINLA, AYOL). * At minimum, a "privacy impact assessment" needs to be made. Basically, think about what the happens to the people whose data it is that gets leaked. (Best to assume it will be.) * Koha stores all its data (including the personal stuff) in MySQL/MariaDB. There is no clean abstraction layer, which means SQL is all over the code base, making things harder to change. I think it would be good for Koha to add an abstraction layer even if Koha stays with MySQL. * Qvarn was designed from the ground up with privacy and security in mind. It is meant to be the least weak link in the chain to protect privacy of the data it stores. It's still under active development, and doesn't have all the planned features yet. It's backed by my new company, QvarnLabs, and is in production use already, storing around a million personal identities. * Qvarn provides a RESTful HTTP(S) JSON API, meaning there's no per-client/per-user session state on the Qvarn side. Makes it really easy to use, from the client, in my opinion. All data is in JSON form, which also makes things easier to use, in my opinion. It's conceptually JSON objects, not tables/columns. Qvarn uses Postgres behind the scenes, at least for now, but that's not visible to API clients (read: we could replace it with individual files on disk and you'd not notice). * Qvarn requires the use of Gluu (see gluu.org) for authentication and authorization. Gluu is an identity management server, which is also free software. We aim to hide Gluu entirely behind the Qvarn API, and already mostly do that, so it's not something you need to know much about, except that operationally it's a bit tricky, since it's harder to deploy than Qvarn itself it (Qvarn comes as a .deb). Here's my thoughts about Koha using Qvarn: * First step would be to change Koha to have a suitable abstraction layer for storing data. I imagine this will be a big job. * Second step would be to model the data Koha stores in Qvarn resource types, i.e., decide which types of records should be and what they should contain. * Third step is ... * Fourth step is profit. Benefits to Koha as far as I can see: * Abstraction layer: cleaner code, easier database related changes in the future, possibly a better test suite as a side effect. * Qvarn: more privacy protection for user data, maybe (this is my highly personal and biased opinion) a nicer way to store/access the data. What do you think? Is this something that the Koha community might want? I don't want to waste your time or anyone else's time if it's not interesting. However, if it is interesting, QvarnLabs is willing to work on making sure Qvarn is good for Koha. Note: though both Qvarn and Koha are developed/supported by companies, they're free software and also free to use. This is not unlike Koha itself. I'm happy to answer any questions you may have, preferably on the koha-devel list.

6 6

INSTALL.debian is outdated
by Jonathan Druart 27 Nov '16

27 Nov '16

2015-11-11 22:37 GMT+00:00 Robin Sheat <robin(a)catalyst.net.nz>: > Aparrish schreef op wo 11-11-2015 om 08:13 [-0700]: >> I followed the official instructions: >> http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=INSTALL.debian;hb… > > We need to delete those, they're from 2012 and are super out of date. Shall we 1) delete them, 2)replace them with the content of the wiki page or 3) just put a link to the wiki page?

12 23