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

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

Information Required
by SANDEEP BHAVSAR 22 Nov '11

22 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 @@@@@@@@@@@@@@@@@@@@@@@@@@

2 1

Koha 3.4.x String Freeze Announcement
by Chris Nighswonger 21 Nov '11

21 Nov '11

Now for the 3.4.x branch: The 3.4.x branch will enter a string freeze on Wed. 30 November. Koha 3.4.7 will release on 7 Dec. Kind Regards, Chris Koha 3.4.x/3.6.x Release Maintainer

1 0

Koha 3.6.x String Freeze Announcement
by Chris Nighswonger 21 Nov '11

21 Nov '11

Ok. I'm batting 0 for 2 on making regular maintenance releases for the past two months. However this time it was due to medical issues. So... The 3.6.x branch is entering a string freeze as of the date/time stamp of this email. Given the holiday in the USA this weekend, I will do the release on Wed. 30 November. Thanks for all of the good work! Kind Regards, Chris Koha 3.4.x/3.6.x Release Maintainer

1 0