April 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

952$j
by Paul 02 Oct '14

02 Oct '14

Our cataloguers have asked for additional precision in specific stacks -- 952$j "Shelving control number" would appear to be perfect :=) However, any value entered (eg: LLF15 -- loose leaf folder #15) systematically saves as 0 and SchemaSpy doesn't appear to even mention this field which is in the "default template" with no apparent restrictions. Can anyone with good "corporate memory" of 952$j use and programming please assist? Many thanks and best regards -- Paul

3 2

On Koha Debian apt repository layout and package versions
by Tomas Cohen Arazi 10 Jun '14

10 Jun '14

---------- Forwarded message ---------- From: Lars Wirzenius <liw(a)liw.fi> Date: Wed, Apr 30, 2014 at 12:21 PM Subject: On Koha Debian apt repository layout and package versions To: tomascohen(a)gmail.com Hi, I made some Debian packages for Koha in 2010, on contract to Catalyst, Ltd, and then left the Koha community. The packages are now maintained by Robin and others. I still lurk on the IRC channel, but I don't follow the mailing lists. I happened to notice recently that there was some discussion on maybe renaming the apt package repositories. I spoke up, and was directed to the mailing list thread starting at [0]. It's a short thread. I offer the following thoughts on the topic, in the hope they're useful. [0] http://lists.koha-community.org/pipermail/koha-devel/2014-April/040428.html First, a little background. Debian apt package repositories may contain many versions of a package, by grouping things into "pockets". The concept has various names in various corners within Debian, and the greater Debian derivatives community, but I'll use this name for simplicity. Each pocket has a name, which is a subdirectory under the "dists" directory in the apt repository. This provides a single dimension for supporting multiple versions, and is used for different Debian releases. Debian has the pockets "stable", "testing", "unstable", and "experimental", where "stable" is the release users are expected to use, unless they're interested in participating in Debian development. Those pockets are actually aliases (via symbolic links) for code names for Debian releases: "squeeze", "wheezy", and "jessie" are names of three Debian releases. The releases also have version numbers, but this is not evident in the apt repository. In addition to the major pockets (one per release), there are some additional ones, such as one for "backports" (e.g., "wheezy-backports"). This allows the apt repository to allow more versions of a package, for different users. For example, the "wheezy" pocket might have version 1.1 of some application, and "wheezy-backports" might have version 2.0, but built for the "wheezy" release. This is different from having 2.0 in the "jessie" pocket, since the binary package is different depending on where it is built. For example, the build for "wheezy-backports" might depend on different versions of, say, some Perl modules, than the one in the "jessie" pocket. This structure works reasonably well for Debian. For Koha, I suggest that the following questions should be answered before changes are made to the repository structure. * Which versions of Koha does the community want to support? Do you have stable versus alpha versus beta versus some other branches? Do you have "long-term support" releases? * When do you want sysadmins to upgrade their Koha packages? Do you want to give them maximum flexibility on this, or do you want to force upgrades when you make a Koha release? * Do you care about producing builds for a variety of releases of Debian or Debian derivatives? Do you care about building for more than the current Debian stable release? Maybe the current stable, and the previous stable release? My knowledge of Koha is years out of date, but from what I remember and from what I understand from lurking, here are my thoughts (and please excuse me if you know all of this already, and already do all of it): * I think it makes sense, if you can automate it, to build for the current Debian release ("stable"), and the previous Debian release ("oldstable"), and also the current Debian development version ("unstable"). Building for the two releases means that those who install the packages get to choose when they upgrade their operating system, without Koha forcing an upgrade. If you only build for the current Debian stable, you force Koha sysadmins to upgrade when Debian makes a release. Building for Debian unstable (or possibly testing) means that you catch incoming changes in Debian sooner rather than later. For example, when Debian upgrades their Perl, you'll learn soon if it affects Koha. These pockets should probably be named after the Debian releases. Currently that would mean pockets named "squeeze", "wheezy", and "unstable". That is, the pocket should be named according what the user is running, not what version of Koha it contains. This keeps things simple for the user, and keeps the number of pockets manageable. * I think it makes sense to build at least two versions of Koha: the current Koha release, and the current tip of the master branch. These packages should have different names, so they do not conflict in the apt repository. The apt repository keeps all package files in "the pool", whereas the "dists" directory only contains lists of packages and versions. The stable Koha release should probably be called "koha". The tip-of-master should be called something else, perhaps "koha-dangerous" to scare people away from installing it without knowing what they do. The two packages could be co-installable, if that make sense for Koha. The dangerous package would allow anyone to easily try out the latest Koha, and if the package is built any time master changes, it'll be easy to keep up to date. This may be easier than running Koha directly from git. * If you think it is worth it, it may be worthwhile to have more than one Koha release in each pocket. It might be to support the latest release plus an LTS release, or to have several stable releases, for example to release bug fixes to older releases as well. If you decide to do this, the cleanest way, in my opinion, is to have packages for each supported release or branch: "koha-3.10", "koha-3.12", and "koha-3.14". These packages would have the latest version of that branch. For example, there might be version 3.10.07 of the koha-3.10 package. This way, someone who wants to stay with Koha 3.10, will install the koha-3.10 package. If there's a new bug fix release of 3.10, the package is updated, and they upgrade to the new package version in the usual way ("apt-get upgrade"). However, they're not forced to upgrade to a newer version of Koha and can do so when they're ready. In addition, there would be an empty package "koha", which would depend on the latest Koha release, for those who do want to have that, with a minimum of fuss. This would allow one to install the package koha, and then get the latest version, even when latest version changes from 3.14 to 3.16. So, in summary, I recommend: * Have pockets "squeeze", "wheezy", and "unstable". * Have packages "koha", "koha-x.y" (for a set of versions you want to provide), and "koha-dangerous" (for latest git commit). I hope this helps, and I apologise for the verbosity of this. I had some time while waiting for a train, but the train came before I had time to squeeze out the fluff from this. (Please Cc me on any replies you wish me to see, as I unfortunately do not have the cerebral cycles to follow the Koha mailing list at this time.) PS. Despite only participating in the community for three months, I remember it very fondly. You do good work, and you make the world a better place. And you're nice and polite while doing it. Inconceivable! -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers

3 2

Apache configuration for UTF-8
by Zeno Tajoli 06 Jun '14

06 Jun '14

Hi to all, I have update the wiki page http://wiki.koha-community.org/wiki/Encoding_and_Character_Sets_in_Koha in the section about apache. Now there are those lines: AddCharset UTF-8 .utf8 AddDefaultCharset utf-8 I check the use of utf-8 instead of UTF-8 in official Apache manual (2.0, 2.2, 2.4). Bye Zeno Tajoli -- Dr. Zeno Tajoli Dipartimento Gestione delle Informazioni e della Conoscenza z.tajoli(a)cineca.it fax +39 02 2135520 CINECA - Sede operativa di Segrate

4 4

Koha OAI-ORE
by volkan sonmez 26 May '14

26 May '14

Dear List Members, Does KOHA support OAI-ORE. I couldn't find any information about this topic. Volkan Sönmez System Administrator Süleyman Demirel Üniversity Library

2 1

Repeatable field
by Partha Mukhopadhyay 21 May '14

21 May '14

4 3

Call for Development news - April Newsletter
by Koha Newsletter 17 May '14

17 May '14

Koha Development community ~ If you have any bugs or projects you'd like us to highlight or promote in the monthly newsletter, please let us know. Maybe it'll attract some additional eyes, testers and sign-offs. k o h a news AT gmail dot com Thank you! -- Chad Roseburg Joanne Dillon Editors, Koha Newsletter

2 1

Deprecating the Non-XSLT display on Detail and Search/List Results
by David Cook 15 May '14

15 May '14

Hi folks: What do people think about deprecating the non-XSLT display on detail and search/list results pages? The XSLT display provides more data in a much more attractive way than the non-XSLT templates. They're also easier to maintain (as you don't need to modify the Perl scripts to feed data forward). We already have default XSLTs so it would be trivial to use these as fallbacks where people haven't specified a XSLT with the global system preferences. Going forward, I much rather maintain one set of templates than two. I don't know about the most recent versions, but in the past (e.g. 3.8) there were issues with the non-XSLT displays not showing data in the right order and not having as much data. Rather than update these displays, it seems much more logical to deprecate them and switch everyone to using the more modern templates. -David

8 8

Koha Plugins
by Wolfram Schneider 01 May '14

01 May '14

I wanted to write a Koha Plugin for meta searching. I used the Kitchen Sink Example from http://bywatersolutions.com/koha-plugins/ as base. So fare, the plugin works well on the staff site (-intra). I can run the configuration template, save values, and read them and run the tool link. Now I want to run the plugin on my opac site (public). But I don't see it here. I read the koha handbook v3.14 but didn't find anything regarding plugins for the opac. I found a hard coded type => "intranet" in lib/Koha/Plugins/Base.pm Did I miss anything? How does I enable a plugin on the opac? Any advice is greatly appreciated! Thanks, Wolfram Schneider -- Wolfram Schneider <wosch(a)FreeBSD.org> http://wolfram.schneider.org

2 1