May 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 Community Newsletter: April 2014
by Koha Newsletter 05 Jun '14

05 Jun '14

Fellow Koha users: The Koha Community Newsletter for April 2014 is here: http://koha-community.org/koha-community-newsletter-april-2014/ Many thanks to all the folks who submitted articles and news to this month's newsletter. Please feel free to email us with any corrections or suggestions. Thanks! Chad Roseburg Joanne Dillon Editors, Koha Community Newsletter

3 3

RFID
by Fitzpatrick, Christopher 28 May '14

28 May '14

Hi Everyone, I know this topic has been covered in the past...I've read some of the past discussions, but I just wanted to get an update on what are the current technologies people are using, since I think there's been some updates. So..are people using an RFID system with Koha? What vendors are they using for the RFID? What customizations were needed to get it to work with Koha? And most importantly, is the RFID system in production now? I'm helping with a move to a new building and the old tattle tape system is really no longer an option. Thanks for any help! best, chris.

2 1

fieldmapping vs. marc_subfield_structure
by Mark Tompsett 28 May '14

28 May '14

Greetings, Is there a reason we have what seem like two apparently similar tables in use? It would seem to me that adding ‘field’ to marc_subfield_structure would it identically replaceable for the fieldmapping table. And the value would be effectively the field name from the table without the table prepended with a dot like it is in kohafield. The reason I’m asking is because it seems like GetRecordValue looks at subtitle quite a bit in Koha. I noticed this while working on bug 11592. GPML, Mark Tompsett

2 1

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

Authorities localization?
by Joel Cornuz 26 May '14

26 May '14

Hi there, My name is Joel Cornuz, I am the IT manager for a small school in Montreal using (with success!!!) Koha for its library (15k volumes). Many thanks for this great tool that is giving us access to a world class library system!!! I am not sure if this is the right place to ask (feel free to redirect me if required) but here is the question: Our books are a mix of French and English volumes and we would like to translate our authorities (the topical terms). The idea is that we want our students to have access to topical terms in French or in English, and access to our complete collection (French and English volumes) related to this particular topic. I know that it is possible to duplicate an authority - so one idea was to duplicate (and translate) authorities... but then I didn't find a simple way to automatically link items from the source to the duplicated authority (am I missing something there?) Or is there a way to localize existing authorities? Or is there another (different, better) way? Thanks for your help and thanks for Koha! Take care, Joel

2 1