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

Koha 3.6.1 is now available
by Chris Nighswonger 29 Nov '11

29 Nov '11

It is with pleasure that I announce the release of Koha 3.6.1. The package can be retrieved from: http://download.koha-community.org/koha-3.06.01.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.06.01.tar.gz.MD5 http://download.koha-community.org/koha-3.06.01.tar.gz.MD5.asc http://download.koha-community.org/koha-3.06.01.tar.gz.sig Release notes for 3.6.1 are below. Come and get it! RELEASE NOTES FOR KOHA 3.6.1 29 Nov 2011 ======================================================================== 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 website for the Koha project is http://koha-community.org/ Koha 3.6.1 can be downloaded from: http://download.koha-community.org/koha-3.06.01.tar.gz Installation instructions can be found at: http://wiki.koha-community.org/wiki/Installation_Documentation OR in the INSTALL files that come in the tarball Koha 3.6.1 is a bugfix/maintenance release. Highlights of 3.6.1 ====================== 6628 critical [security] help system use insecure REFERRER for file inclusion 4211 major Acquisitions actions on suggestions don't generate email 6824 major Basket permissions not looked up correctly 6977 major Support for repeated subfields when importing an authority into a biblio record field. 7069 major Javascript errors in tags/review 7207 major Cannot export label batches Bugs fixed in 3.6.1 ====================== 2847 normal Use HTML escape in templates where appropriate 3958 normal Standardize vendor/supplier/bookseller terminology 5072 normal Filling an order page with no budget defined causes a 500 error 5885 normal UNIMARC XSLT changes 5974 normal Bogus auth check for "StaffMember" role 6253 normal Unified Patron Search subroutine 6280 normal Invalid SQL being passed in circulation checkout 6369 normal Formatting problems on some items when printing an order form (PDF). 6390 normal Basket only visible for librarian who created it 6676 normal Acquisition basket access control trivially by-passable 6963 normal When creating a new order, the item isn't added if its barcode already exists in the items table. 3184 enhancement Show creator and budget receiving a document 4161 enhancement When adding Vendor default to active currencies 5436 enhancement Extended patron attributes display improvements 6721 enhancement Add Basket number and Invoice number search 6875 enhancement de-nesting C4 packages 7173 enhancement Detect duplicates when creating items while receiving System requirements ====================== Changes since 3.4: * Perl 5.10 is required Documentation ====================== As of Koha 3.2, the Koha manual is now maintained in DocBook. The home page for Koha documentation is http://koha-community.org/documentation/ As of the date of these release notes, only the English version of the Koha manual is available: http://manual.koha-community.org/3.6/en/ The Git repository for the Koha manual can be found at http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary Translations ====================== Complete or near-complete translations of the OPAC and staff interface are available in this release for the following languages: * Chinese (Taiwan) * Danish * English (USA) * English (UK) * French (France) * German * Italian * Portuguese (Brazil) * Spanish Partial translations are available for various other languages. The Koha team welcomes additional translations; please see http://wiki.koha-community.org/wiki/Translating_Koha for information about translating Koha, and join the koha-translate list to volunteer: http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate The most up-to-date translations can be found at: http://translate.koha-community.org/ Release Team ====================== The release team for Koha 3.6 is Release Manager: Chris Cormack <chrisc(a)catalyst.net.nz> Documentation Manager: Nicole C Engard <nengard(a)gmail.com> Translation Manager: FrÃ©dÃ©ric Demians <frederic(a)tamil.fr> QA Manager: Ian Walls <ian.walls(a)bywatersolutions.com> Bug Wranglers: MJ Ray, Marcel Roy, Paul Poulain, Mason James Release Maintainer (3.4.x): Chris Nighswonger <cnighswonger(a)foundations.edu> Release Maintainer (3.6.x): Chris Nighswonger <cnighswonger(a)foundations.edu> Credits ====================== We thank the following libraries who are known to have sponsored new features in Koha 3.6: * Los Gatos Public Library * NEKLS * East Brunswick Public Library * Athens County Public Libraries * Horowhenua Library Trust * Halton Borough Council * South Taranaki District Council We thank the following individuals who contributed patches to Koha 3.6.1. 1 Nahuel ANGELINETTI 5 FrÃ©dÃ©rick Capovilla 12 Chris Cormack 2 FrÃ©dÃ©ric Demians 4 Katrin Fischer 6 Owen Leonard 1 Julian Maurice 1 Joy Nelson 3 Chris Nighswonger 2 Maxime Pelletier 5 Paul Poulain 2 Liz Rea 1 Marcel de Rooy 1 Salvador Zaragoza Rubio 7 Ian Walls We regret any omissions. If a contributor has been inadvertantly missed, please send a patch against these release notes to koha-patches(a)lists.koha-community.org. Revision control notes ====================== The Koha project uses Git for version control. The current development version of Koha can be retrieved by checking out the master branch of git://git.koha-community.org/koha.git The branch for Koha 3.6.x (i.e., this version of Koha and future bugfix releases) is 3.6.x. The next major feature release of Koha will be Koha 3.8.0. Bugs and feature requests ====================== Bug reports and feature requests can be filed at the Koha bug tracker at http://bugs.koha-community.org/ Ehara taku toa i te toa takitahi, engari he toa takitini ##### Autogenerated release notes updated last on 29 Nov 2011 at 01:20:19Z #####

2 1

git revert
by SANDEEP BHAVSAR 28 Nov '11

28 Nov '11

Respected All Just upgraded the Koha ver through git and facing the error Can't call method "cookie" on an undefined value at /usr/share/koha/lib/C4/Templates.pm line 323. gone through the yesterday's solution of koha forum but not successful. Kindly guide me for git revert.(exact command) -- Thanks and Regards Sandeep Bhavsar Librarian Dr.V.N.Bedekar Institute of Management Studies Thane(W) 400601 MUMBAI. INDIA @@@@@@@@@@@@@@@@@@@@@@@@@@ email : sandeep.bhavsar(a)gmail.com Mob : 9029 345777 elibrary :http://www.vpmthane.org/im/elib/main.htm @@@@@@@@@@@@@@@@@@@@@@@@@@

4 4

Master broken
by Jared Camins-Esakov 28 Nov '11

28 Nov '11

Hello. Just a heads' up- the master branch on git.k-c.org is currently broken. I can't tell exactly when it broke, but it was sometime after the security patch that was pushed yesterday. The error message you get when you try to log in to the staff client is: Can't call method "cookie" on an undefined value at /home/jcamins/k ohaclone/C4/Templates.pm line 323 I don't have time to troubleshoot this, but I wanted to warn people of the problem before too many people updated their systems with catastrophic results (hopefully this will stave off a bit of the wailing and gnashing of teeth which would otherwise accompany the git pull at 9am Monday morning). Regards, Jared Camins-Esakov -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins(a)cpbibliography.com (web) http://www.cpbibliography.com/

5 6

Information Required
by SANDEEP BHAVSAR 27 Nov '11

27 Nov '11

Respected All I would like to integrate EBSCO, Open access databases, through pazpar2 in Koha. Kindly guide me for the documentation. Step by step screenshots or video of the process in lecture form will be preferred. -- Thanks and Regards Sandeep Bhavsar Librarian Dr.V.N.Bedekar Institute of Management Studies Thane(W) 400601 MUMBAI. INDIA @@@@@@@@@@@@@@@@@@@@@@@@@@ email : sandeep.bhavsar(a)gmail.com Mob : 9029 345777 elibrary :http://www.vpmthane.org/im/elib/main.htm @@@@@@@@@@@@@@@@@@@@@@@@@@

1 0

Re: [Koha-devel] [Koha] Plea for help from Horowhenua Library Trust re: Koha
by Chris Cormack 26 Nov '11

26 Nov '11

2011/11/24 Buster <storypage(a)gmail.com> > > > 2011/11/22 Lori Bowen Ayre <lori.ayre(a)galecia.com> > >> There has already been plenty of outrage expressed by the Koha community >> and clearly it hasn't made a difference. >> > > Oh, I don't know about that. We investigated Koha and Evergreen for a year > and recently decided to go with community Koha using ByWater Solutions as a > vendor rather than LibLime largely because of LibLime's position within (or > rather, without) the community. That, and the fact its product has > basically become a proprietary system with all the weaknesses and pitfalls > of such systems. While investigating, we did visit a couple of LibLime > clients who are jumping ship as soon as they are legally able, for many of > the same reasons we eschewed it from the git-go. > > So, I think it has, in fact, made a difference. People who care do pay > attention. > > Some very interesting news. http://diligentroom.wordpress.com/2011/11/22/the-exemplar-of-stupid-koha-vs… >From Liblime: "Here’s PTFS/LibLime’s press release about the matter: http://www.liblime.com/ptfsliblime-granted-provisional-use-of-koha-trademar… The TL;DR is: this was inherited—by surprise—from the previous owners. We don’t know their intentions then, but we know ours now. We’ll hand the NZ trademark off to a non-profit (including HLT) who agrees to continue our practice of protecting non-exclusive use of the name." Which sounds great to me, HLT makes that promise (as they are the community elected body to hold community property and a registered non profit Trust) and PTFS/Liblime can sign over the application. This could all be resolved in a couple of days time. I really hope this is true and the application is signed over to HLT as soon as possible so we can put this all behind us. Chris

3 3

Update database changes proposal [IMPORTANT]
by Paul Poulain 26 Nov '11

26 Nov '11

Hello, During the hackfest in Mumbaï, 5 of us had a brainstorming about database changes to try to improve it. Here are the goals: * must result in patches being easier to test by testers (to sign-off) * must result in less conflict when trying to apply a patch with a DB update when another patch has been applied (the .XXXX problem) * must fix the linear problem (where patches are applied in a completly linear way) * be easy to implement We throwed many ideas, here is the one that seems both easy and usefull : * patches would be submitted in a specific file, in atomicupdate directory * a new file (YAML) would be added, that would have 2 columns, one for the version number, one for the atomicupdate file name * updatedatabase wouldn't change anymore: we would just add something like : LoadYAMLFile() ForEachLine { if (C4::Context->preference("Version") < FirstColumnYAML) { exec(secondColumnYAML); SetVersion (FirstColumnYAML); } } The YAML file would be updated only by the Release Manager, when he pushes a patch. This idea fully achieve most of our initial goals: * (very) easy to implement * it will be easier to test a patch : is there an atomic update in the patch ? OK, to test it, i'll first execute the file * there won't be any conflict anymore of a patch applied and your .XXXX file not applying anymore, needing a rebase * it fixes partially the linear problem = if you have a local branch, you can see what has been applied just looking in the yaml file. Let's say Limoges library has sponsored stuff that has resulted in atomicupdate/limogeupdate.pl Those changes are live in Limoges, but still not in official/community version. The Limoges YAML file will be: 3.07.0001 Community_change1.pl 3.07.0002 community_change2.pl localchange limogesupdate.pl 3.07.0003 community_change3.pl the "localchange" in first column will mean for the updater : "OK, apply the change but don't change the version number" When the localchange has been applied on master community branch, the official/community YAML file will look like: 3.07.0001 Community_change1.pl 3.07.0002 community_change2.pl 3.07.0003 community_change3.pl 3.07.0004 limogesupdate.pl Switching back limoges to a community version would require some manual checking, but that will be *much* easier than what we have today : * diff limoges.yaml official.yaml * apply community changes if/where needed * UPDATE systempreferences SET kohaversion=3.07.0004 manually It's done ! And if the localchange that has been made is never merged into master, whatever the reason, it will be easier to keep track of it too. And if you want to apply a submitted patch to your local setup before it's pushed onto master, you can, just by running the file in atomicupdate directory. And add a "localchange" line to your YAML file to remember the change you've made. Does anyone see a problem with this new updatedatabase procedure ? Until now, I have pushed no changes in database, so if we agree, i'll implement this change quickly (before pushing any change having a database consequence) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

12 37

EDIfact Integration - update please
by savitra sirohi 25 Nov '11

25 Nov '11

Hi Mark, We need to implement EDI for one our customers by end of March. Can you please send an update on the EDIfact integration work you have been doing? Specifically: Is this branch up-to-date: https://github.com/paddyfitz/koha/tree/EDIfact_3.4.x? Have you implemented other messages outside of Quotes and Orders? We have the resources to start work on EDI from middle of December, if possible we would like to collaborate on this. I found this email from you dating from July of this year. >>>>>>>>>>>>>> Koha-devel] EDIfact integration Mark Gavillet mark.gavillet at ptfs-europe.com Mon Jul 11 13:19:00 CEST 2011 Hi Henri UK public authorities and academic institutions now require EDIfact integration so this has become something which we at PTFS Europe have been working toward over the past couple of months. We now have a branch containing EDIfact integration for Koha which is online at GitHub (https://github.com/paddyfitz/koha/tree/EDIfact_3.4.x) Bertrams and Dawsons booksellers have been a part of the process throughout and the current implementation successfully processes QUOTE and ORDER messages to/from both vendors. We currently have one live customer using the EDIfact module successfully, and another will be going live in the next couple of weeks. We will be tidying the code and submitting to the community in the near future. Regards, Mark Thanks, Savitra Sirohi Nucsoft OSS Labs http://www.osslabs.biz

2 1

Bug 6929 and Status field in Bugzilla in relation to git master
by Dobrica Pavlinusic 24 Nov '11

24 Nov '11

I'm working on a system which would allow me to automatically apply arbitrary number of patches from bug tracker to new koha instance (using unique git branch for it) for easy testing of multiple-patch interaction. It's in planning stage, but I started going through my Cc bugs in Bugzilla and stumbled upon 6929 which was in git master, so I chaged it's Status to RESOLVED FIXED Then it occured to me that this not be OK, since Robin might depend on bug beeing assigned to him as reminder to apply it to production somewhere. Should I keep my hands off Status field in bugzilla or try to update them to current master? -- Dobrica Pavlinusic 2share!2flame dpavlin(a)rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin

2 1

Plea for help from Horowhenua Library Trust re: Koha
by Joann Ransom 23 Nov '11

23 Nov '11

As I am sure most of you are aware, Horowhenua Library Trust is the birth place of Koha and the longest serving member of the Koha community. Back in 1999 when we were working on Koha, the idea that 12 years later we would be having to write an email like this never crossed our minds. It is with tremendous sadness that we must write this plea for help to you, the other members of the Koha community. The situation we find ourselves in, is that after over a year of battling against it, PTFS/Liblime have managed to have their application for a Trademark on Koha in New Zealand accepted. We now have 3 months to object, but to do so involves lawyers and money. We are a small semi rural Library in New Zealand and have no cash spare in our operational budget to afford this, but we do feel it is something we must fight. For the library that invented Koha to now have to have a legal battle to prevent a US company trademarking the word in NZ seems bizarre, but it is at this point that we find ourselves. So, we ask you, the users and developers of Koha, from the birth place of Koha, please if you can help in anyway, let us know. Regards, Jo. -- Joann Ransom RLIANZA Head of Libraries, Horowhenua Library Trust.

14 15

Reading history concerns and opinions
by David Schuster 23 Nov '11

23 Nov '11

This is a library question on policy and just curious how others are handling it. Reading history can be maintained in Koha - I understand that, and as a policy we protect individuals freedom to read what they want. As a School district - we often get the request from teachers and parents "I need a list of what Susie has read this semester"... Currently we have not been providing access to even the students so it is easy for us to say "Sorry we don't keep that information"... I know we could say "Sorry that is private student information and I can't share it", Teachers could probably be thwarted with that, but not so much Parents... Then the whole "FBI" coming for reading history is another issue... As we build these features that allow "staring" and "if you read X you might enjoy Y" or "people who read X also read Y" - what is our best avenue for defending our clients reading history, yet making these features available to them. Just pondering... -- David Schuster Plano ISD Library Technology Coordinator

1 0