From henridamien.laurent at gmail.com Wed Dec 1 05:15:13 2010 From: henridamien.laurent at gmail.com (LAURENT Henri-Damien) Date: Wed, 01 Dec 2010 05:15:13 +0100 Subject: [Koha-devel] ICU chains In-Reply-To: References: Message-ID: <4CF5CBD1.9000207@gmail.com> Le 30/11/2010 18:09, Ian Walls a ?crit : > Fellow Kohackers, > > > There has been some talk before of using ICU chains with Zebra in order > to resolve issues with diacritic search. I've looked at the patch from > BibLibre > (http://git.biblibre.com/?p=koha;a=commit;h=c2465153cccb8965b0008186cdb0a94a57317849), > and it seems pretty straightfoward, but it's nearly a year old, and I'm > wondering if any work has been done since then. Does this commit > resolve the issue (at least for French diacritics)? > > There has also been some recent posting on handling both Roman and > Devangari script > (http://old.nabble.com/Re:-display-search-result-problem-p28106148.html). It > references the BibLibre commit. > > If this methodology is working, what should we do to get it committed to > Koha? I'd imagine that we'd need to generalize it to work with all > languages... either by making a master set of rules, or having different > xml files that can be called depending on your language choice... ideas? > > Cheers, > > > -Ian > Ian, This methodology and icuchain is sure working for Korean, Hebrew, Georgian, Russian. It might be different for Arabic languages, since in that language, diacritics are meaningfull. But we had scarce return for those languages. But all in all, the commit said, and the icu chain modification published on 3.4/BibLibre-various (which is fixing a problem on multiple word searching) will suit you. Hope that helps. -- Henri-Damien LAURENT From henridamien.laurent at biblibre.com Wed Dec 1 05:16:36 2010 From: henridamien.laurent at biblibre.com (LAURENT Henri-Damien) Date: Wed, 01 Dec 2010 05:16:36 +0100 Subject: [Koha-devel] ICU chains In-Reply-To: References: Message-ID: <4CF5CC24.2060403@biblibre.com> Le 30/11/2010 18:09, Ian Walls a ?crit : > Fellow Kohackers, > > > There has been some talk before of using ICU chains with Zebra in order > to resolve issues with diacritic search. I've looked at the patch from > BibLibre > (http://git.biblibre.com/?p=koha;a=commit;h=c2465153cccb8965b0008186cdb0a94a57317849), > and it seems pretty straightfoward, but it's nearly a year old, and I'm > wondering if any work has been done since then. Does this commit > resolve the issue (at least for French diacritics)? > > There has also been some recent posting on handling both Roman and > Devangari script > (http://old.nabble.com/Re:-display-search-result-problem-p28106148.html). It > references the BibLibre commit. > > If this methodology is working, what should we do to get it committed to > Koha? I'd imagine that we'd need to generalize it to work with all > languages... either by making a master set of rules, or having different > xml files that can be called depending on your language choice... ideas? > > Cheers, > > > -Ian > Ian, This methodology and icuchain is sure working for Korean, Hebrew, Georgian, Russian. It might be different for Arabic languages, since in that language, diacritics are meaningfull. But we had scarce return for those languages. But all in all, the commit said, and the icu chain modification published on 3.4/BibLibre-various (which is fixing a problem on multiple word searching) will suit you. Hope that helps. -- Henri-Damien LAURENT From kohadevel at agogme.com Wed Dec 1 22:14:02 2010 From: kohadevel at agogme.com (Thomas Dukleth) Date: Wed, 1 Dec 2010 21:14:02 -0000 (UCT) Subject: [Koha-devel] Search Engine Changes : let's get some solr In-Reply-To: <1291154210.2428.37.camel@zarathud> References: <4CA98C01.8080709@biblibre.com> <1291154210.2428.37.camel@zarathud> Message-ID: Reply inline: On Tue, November 30, 2010 21:56, Robin Sheat wrote: > LAURENT Henri-Damien schreef op ma 04-10-2010 om 10:10 [+0200]: >> BibLibre investigated in a catalogue based on solr. > > Not sure if this is known, but I just saw it: > > http://www.indexdata.com/blog/2010/09/solr-support-zoom-pazpar2-and-masterkey > > "...we have just completed a project to add support for SOLR targets in > the ZOOM API implementation in the YAZ library. So YAZ now supports > Z39.50, SRU/SRW 1.x and the SOLR API." The fact that some Index Data products recently added some Solr/Lucene support is helpful and has been cited previously but there are significant limitations. I have been investigating deeply examining source code and communicating with the developers including Sebastian Hammer at Index Data. All the options seem to fall short for providing a sufficiently comparable feature set to what we have with Zebra as a Z39.50/SRU server somewhere beyond matching query indexes with Solr/Lucene indexes. Even something as simple as distinguishing a phrase query from a word list query sent to a Z39.50/SRU server for rewriting as an appropriate Solr/Lucene query seems to require more work to develop judging by not finding appropriate source code. I am expecting explicit confirmation from a couple of people but that finding is part of my findings thus far. The source code may be sufficiently informative but I want a little more feedback from Index Data and Knowledge Integration before posting a comparison of Z39.50/SRU server options in the BibLibre Solr/Lucene RFC. When I last communicated with Ian Ibbotson at Knowledge Integration about whether he had received my last set of questions about JZKit as I had no reply, I told him that there was no hurry for an answer as long as he intended to reply when he had time. If we are having a meeting about the issue soon, I should encourage him to answer now or I will rely upon my findings in the source code. Ian Ibbotson has been at least as helpful in enabling me to think better about options from Index Data as he has been for options from Knowledge Integration. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 From henridamien.laurent at biblibre.com Thu Dec 2 07:13:56 2010 From: henridamien.laurent at biblibre.com (LAURENT Henri-Damien) Date: Thu, 02 Dec 2010 07:13:56 +0100 Subject: [Koha-devel] Meeting solr doodle tendencies closing tomorrow Message-ID: <4CF73924.4010709@biblibre.com> Hi, here are the tendencies for the solr meeting : Tuesday, 7th december, 21h UTC and Wednesday, 15th December, 11h UTC I propose that we close the vote on Monday, at 21PM UTC in order to be able to have the time to send a mail for final votes. As a side note, non techy people are welcome at this meeting. Even though techy questions will be assigned. Feel free to invite. mibbit is a very handy tool to attend irc. I still have to make a real agenda for this meeting with all the questions people raised, why we did this, how we solved some issues, what drove our choices and what is the plan, and how we can work all together is still a good starting point. It will be posted on the wiki and here. Only 12 people voted. It is a good start though. I think there are many things that we could work on in groups. The search engine is one of them, Data persistance, and Plack another, Template organisation another, choosing one javascript framework (concensus seems to be in favour of jquery, but how, who when actions ?) .... if you like the idea of those meetings, please feel free to support the idea and come to those meetings and eventually organize one on the theme you favor or need. -- Henri-Damien LAURENT From henridamien.laurent at gmail.com Thu Dec 2 07:33:12 2010 From: henridamien.laurent at gmail.com (LAURENT Henri-Damien) Date: Thu, 02 Dec 2010 07:33:12 +0100 Subject: [Koha-devel] Meeting solr doodle tendencies closing ON MONDAY 6 21UTC In-Reply-To: <4CF73924.4010709@biblibre.com> References: <4CF73924.4010709@biblibre.com> Message-ID: <4CF73DA8.1090007@gmail.com> Le 02/12/2010 07:13, LAURENT Henri-Damien a ?crit : > Hi, > here are the tendencies for the solr meeting : > Tuesday, 7th december, 21h UTC > and > Wednesday, 15th December, 11h UTC > > I propose that we close the vote on Monday, at 21PM UTC in order to be > able to have the time to send a mail for final votes. > As a side note, non techy people are welcome at this meeting. Even > though techy questions will be assigned. Feel free to invite. mibbit is > a very handy tool to attend irc. > > I still have to make a real agenda for this meeting with all the > questions people raised, why we did this, how we solved some issues, > what drove our choices and what is the plan, and how we can work all > together is still a good starting point. It will be posted on the wiki > and here. > Only 12 people voted. It is a good start though. > > > I think there are many things that we could work on in groups. The > search engine is one of them, Data persistance, and Plack another, > Template organisation another, choosing one javascript framework > (concensus seems to be in favour of jquery, but how, who when actions ?) > .... if you like the idea of those meetings, please feel free to support > the idea and come to those meetings and eventually organize one on the > theme you favor or need. From laurenthdl at alinto.com Thu Dec 2 08:56:18 2010 From: laurenthdl at alinto.com (LAURENT Henri-Damien) Date: Thu, 02 Dec 2010 08:56:18 +0100 Subject: [Koha-devel] Idea for a meeting about tests was: [ Meeting solr] In-Reply-To: <4CF73DA8.1090007@gmail.com> References: <4CF73924.4010709@biblibre.com> <4CF73DA8.1090007@gmail.com> Message-ID: <4CF75122.8010009@alinto.com> Just a practical idea for a meeting : Automated Test implementation in Koha we could try and have a workshop on tests : - How to write a Unit test - How to write a db dependent Test - How to write a selenium test - How to test - gather use cases This would be helpful for all of us. Comments welcome. Hope that helps. Friendly -- Henri-Damien LAURENT Le 02/12/2010 07:33, LAURENT Henri-Damien a ?crit : > Le 02/12/2010 07:13, LAURENT Henri-Damien a ?crit : >> Hi, >> here are the tendencies for the solr meeting : >> Tuesday, 7th december, 21h UTC >> and >> Wednesday, 15th December, 11h UTC >> >> I propose that we close the vote on Monday, at 21PM UTC in order to be >> able to have the time to send a mail for final votes. >> As a side note, non techy people are welcome at this meeting. Even >> though techy questions will be assigned. Feel free to invite. mibbit is >> a very handy tool to attend irc. >> >> I still have to make a real agenda for this meeting with all the >> questions people raised, why we did this, how we solved some issues, >> what drove our choices and what is the plan, and how we can work all >> together is still a good starting point. It will be posted on the wiki >> and here. >> Only 12 people voted. It is a good start though. >> >> >> I think there are many things that we could work on in groups. The >> search engine is one of them, Data persistance, and Plack another, >> Template organisation another, choosing one javascript framework >> (concensus seems to be in favour of jquery, but how, who when actions ?) >> .... if you like the idea of those meetings, please feel free to support >> the idea and come to those meetings and eventually organize one on the >> theme you favor or need. From Katrin.Fischer at bsz-bw.de Thu Dec 2 09:34:33 2010 From: Katrin.Fischer at bsz-bw.de (Fischer, Katrin) Date: Thu, 2 Dec 2010 09:34:33 +0100 Subject: [Koha-devel] Idea for a meeting about tests was: [ Meeting solr] In-Reply-To: <4CF75122.8010009@alinto.com> References: <4CF73924.4010709@biblibre.com> <4CF73DA8.1090007@gmail.com> <4CF75122.8010009@alinto.com> Message-ID: <028B1A54D03E7B4482CDCA4EC8F06BFDE152F7@Bodensee.bsz-bw.de> +1 I think this is a good idea. Perhaps we can work together on some examples? And create some step-by-step tutorials for the wiki. Katrin > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel- > bounces at lists.koha-community.org] On Behalf Of LAURENT Henri-Damien > Sent: Thursday, December 02, 2010 8:56 AM > To: koha-devel at lists.koha-community.org > Subject: [Koha-devel] Idea for a meeting about tests was: [ Meeting > solr] > > Just a practical idea for a meeting : Automated Test implementation in > Koha > we could try and have a workshop on tests : > - How to write a Unit test > - How to write a db dependent Test > - How to write a selenium test > - How to test > - gather use cases > This would be helpful for all of us. > Comments welcome. > Hope that helps. > Friendly > -- > Henri-Damien LAURENT > > Le 02/12/2010 07:33, LAURENT Henri-Damien a ?crit : > > Le 02/12/2010 07:13, LAURENT Henri-Damien a ?crit : > >> Hi, > >> here are the tendencies for the solr meeting : > >> Tuesday, 7th december, 21h UTC > >> and > >> Wednesday, 15th December, 11h UTC > >> > >> I propose that we close the vote on Monday, at 21PM UTC in order to > be > >> able to have the time to send a mail for final votes. > >> As a side note, non techy people are welcome at this meeting. Even > >> though techy questions will be assigned. Feel free to invite. mibbit > is > >> a very handy tool to attend irc. > >> > >> I still have to make a real agenda for this meeting with all the > >> questions people raised, why we did this, how we solved some issues, > >> what drove our choices and what is the plan, and how we can work all > >> together is still a good starting point. It will be posted on the > wiki > >> and here. > >> Only 12 people voted. It is a good start though. > >> > >> > >> I think there are many things that we could work on in groups. The > >> search engine is one of them, Data persistance, and Plack another, > >> Template organisation another, choosing one javascript framework > >> (concensus seems to be in favour of jquery, but how, who when > actions ?) > >> .... if you like the idea of those meetings, please feel free to > support > >> the idea and come to those meetings and eventually organize one on > the > >> theme you favor or need. > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > From kmkale at anantcorp.com Thu Dec 2 10:20:33 2010 From: kmkale at anantcorp.com (Koustubha Kale) Date: Thu, 2 Dec 2010 14:50:33 +0530 Subject: [Koha-devel] Idea for a meeting about tests was: [ Meeting solr] In-Reply-To: <4CF75122.8010009@alinto.com> References: <4CF73924.4010709@biblibre.com> <4CF73DA8.1090007@gmail.com> <4CF75122.8010009@alinto.com> Message-ID: On Thu, Dec 2, 2010 at 1:26 PM, LAURENT Henri-Damien wrote: > Just a practical idea for a meeting : Automated Test implementation in Koha > we could try and have a workshop on tests : > - How to write a Unit test > - How to write a db dependent Test > - How to write a selenium test > - How to test > - gather use cases > This would be helpful for all of us. > Comments welcome. > Hope that helps. > Friendly > -- > Henri-Damien LAURENT > > Great idea +1 for workshop on tests.. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Thu Dec 2 17:23:06 2010 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 02 Dec 2010 17:23:06 +0100 Subject: [Koha-devel] About Hourly loans RFC Message-ID: <4CF7C7EA.6020800@biblibre.com> Hello world, I can't see who really wrote http://wiki.koha-community.org/wiki/Hourly_Loans_RFC, if it's still planned, who will write this great RFC. Do I miss something ? Is it an abandonned_RFC from LL (don't think so, we had http://wiki.koha-community.org/wiki/Hourly_circulation_policies_RFC that was the LL one if i'm not mistaking) ? hint/light welcomed ;-) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From cnighswonger at foundations.edu Thu Dec 2 17:25:10 2010 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 2 Dec 2010 11:25:10 -0500 Subject: [Koha-devel] [Koha-patches] [PATCH] [Bug 5465] Makefile.PL asks for too high version of Business::ISBN In-Reply-To: References: <1291301295-5097-1-git-send-email-lrea@nekls.org> Message-ID: CC'ing the dev list.... On Thu, Dec 2, 2010 at 11:16 AM, Liz Rea wrote: On Thu, Dec 2, 2010 at 9:39 AM, Chris Nighswonger < cnighswonger at foundations.edu> wrote: > On Thu, Dec 2, 2010 at 9:48 AM, Liz Rea wrote: > >> Backing down the version to 2.0301 to match the Lenny available package. >> > > Hmm... 2.05 is the newest version of this module in cpan. I think > Makefile.PL should always ask for what is truly the newest version rather > than being tied to a particular distribution. > > my $0.02 worth > > Kind Regards, > Chris > > I did actually think about this before I did it. :) > > I asked around if it would be better to update the documentation to take > the package out of the install script and add it to the CPAN list, or do > what I did, and the general consensus was that backing down the required > version was a better option (since the newer version doesn't add any > functionality that we actually use), so I did that. > > The reason is that a lot of people use Lenny (and or Ubuntu, which would > cause this same issue), and Squeeze/Sid aren't stable yet (even though they > work fine, I know that). Every indication I've gotten is that "we" prefer > packaged versions of things instead of pulling direct from CPAN. I chose to > eliminate the error message when installing on Lenny/Ubuntu from > Makefile.PL, and allow a required version that was lower than the current > version to help eliminate a bad user experience (An error!!! OMG! What do I > do!). > > I truly don't care which way it's done: we can remove it from the package > script and add it to the modules requiring installation through CPAN, no > problem. I'll do those patches too, if necessary. > > That said, I don't think the reasoning behind this particular patch is > unsound, based on past precedent. > I'm not familiar with what has been the rule in the past. However, it is my opinion we should establish one standard rather than attempting to work around two different ones. If we are going to take the Debian/Ubuntu repo version as the standard, we should set all modules available in those repos to the max current version available in those repos, and be sure that policy is clear in the docs. We should also develop only over those currently available versions. (I realize in this particular case there is no programmatically compelling reason to use the latest version, but that is not always the case.) FWIW, I favor Debian/Ubuntu personally, but am concerned about this from a policy standpoint. If we indeed see this as the best direction to go, I recommend we add something like this to our coding guidelines: When/Where available, Koha Perl dependencies should be sourced from the current stable Debian/Ubuntu repository. Perl dependencies not available in the repository should be sourced from CPAN. Code development should be limited to the most current version available from the proper source. Exceptions to this policy may be made by gaining consensus from the developer section of the community. or some such language... Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Thu Dec 2 17:28:09 2010 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 02 Dec 2010 17:28:09 +0100 Subject: [Koha-devel] [Koha-patches] [PATCH] [Bug 5465] Makefile.PL asks for too high version of Business::ISBN In-Reply-To: References: <1291301295-5097-1-git-send-email-lrea@nekls.org> Message-ID: <4CF7C919.1060706@biblibre.com> Le 02/12/2010 17:25, Chris Nighswonger a ?crit : >> I did actually think about this before I did it. :) >> >> I asked around if it would be better to update the documentation to take >> the package out of the install script and add it to the CPAN list, or do >> what I did, and the general consensus was that backing down the required >> version was a better option (since the newer version doesn't add any >> functionality that we actually use), so I did that. >> >> The reason is that a lot of people use Lenny (and or Ubuntu, which would >> cause this same issue), and Squeeze/Sid aren't stable yet (even though they >> work fine, I know that). Every indication I've gotten is that "we" prefer >> packaged versions of things instead of pulling direct from CPAN. I chose to >> eliminate the error message when installing on Lenny/Ubuntu from >> Makefile.PL, and allow a required version that was lower than the current >> version to help eliminate a bad user experience (An error!!! OMG! What do I >> do!). >> you can count BibLibre in "we" : we prefer packaged versions, no doubts ! So ++ to your proposition to have the oldest version that works fine required ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From ian.walls at bywatersolutions.com Thu Dec 2 17:32:28 2010 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Thu, 2 Dec 2010 11:32:28 -0500 Subject: [Koha-devel] About Hourly loans RFC In-Reply-To: <4CF7C7EA.6020800@biblibre.com> References: <4CF7C7EA.6020800@biblibre.com> Message-ID: Paul, I wrote the new Hourly Loans RFC at http://wiki.koha-community.org/wiki/Hourly_Loans_RFC. It's not currently sponsored, but I'm in talks with a potential client that would be willing to throw some funding at making it a reality. Assuming all the monetary dealings go according to plan (not my department), I'm going to do the development for this on an open branch, and will welcome patches from other developers. If this could be a branch on git.koha-community.org, that'd be great, otherwise I'll set it up on the ByWater repo. Cheers, -Ian On Thu, Dec 2, 2010 at 11:23 AM, Paul Poulain wrote: > Hello world, > > I can't see who really wrote > http://wiki.koha-community.org/wiki/Hourly_Loans_RFC, if it's still > planned, who will write this great RFC. > Do I miss something ? Is it an abandonned_RFC from LL (don't think so, > we had > http://wiki.koha-community.org/wiki/Hourly_circulation_policies_RFC that > was the LL one if i'm not mistaking) ? > > hint/light welcomed ;-) > > -- > Paul POULAIN > http://www.biblibre.com > Expert en Logiciels Libres pour l'info-doc > Tel : (33) 4 91 81 35 08 > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Thu Dec 2 17:45:22 2010 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 02 Dec 2010 17:45:22 +0100 Subject: [Koha-devel] About Hourly loans RFC In-Reply-To: References: <4CF7C7EA.6020800@biblibre.com> Message-ID: <4CF7CD22.30404@biblibre.com> Le 02/12/2010 17:32, Ian Walls a ?crit : > Assuming all the monetary dealings go according to plan (not my department), > I'm going to do the development for this on an open branch, and will welcome > patches from other developers. If this could be a branch on > git.koha-community.org, that'd be great, otherwise I'll set it up on the > ByWater repo. thx for the answer ian, 1- I don't have a library that would/plan sponsor this, but many are interested 2- I hope our 3.4-BibLibre-circ will have been merged before you start, as many new things (including table structure are here 3- could you update the RFCs to use the template? 4- mmm... no, no point 4 ;-) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From cfouts at liblime.com Thu Dec 2 17:48:31 2010 From: cfouts at liblime.com (Clay Fouts) Date: Thu, 2 Dec 2010 08:48:31 -0800 Subject: [Koha-devel] [Koha-patches] [PATCH] [Bug 5465] Makefile.PL asks for too high version of Business::ISBN In-Reply-To: References: <1291301295-5097-1-git-send-email-lrea@nekls.org> Message-ID: Typically they're called "requirements" because they establish a minimum. If a particular version is known to work and passes the tests, why require a system to have a higher version installed? Why instruct users to install from apt at all if they're just going to have to update all the modules from CPAN anyway? Why warn them they *need* to upgrade if in reality they don't? Issuing a warning during the build process should indicate something potentially dire, not making noise about a preference. Regards, Clay 2010/12/2 Chris Nighswonger > CC'ing the dev list.... > > > On Thu, Dec 2, 2010 at 11:16 AM, Liz Rea wrote: > On Thu, Dec 2, 2010 at 9:39 AM, Chris Nighswonger < > cnighswonger at foundations.edu> wrote: > >> On Thu, Dec 2, 2010 at 9:48 AM, Liz Rea wrote: >> >>> Backing down the version to 2.0301 to match the Lenny available package. >>> >> >> Hmm... 2.05 is the newest version of this module in cpan. I think >> Makefile.PL should always ask for what is truly the newest version rather >> than being tied to a particular distribution. >> >> my $0.02 worth >> >> Kind Regards, >> Chris >> > > > >> I did actually think about this before I did it. :) >> >> I asked around if it would be better to update the documentation to take >> the package out of the install script and add it to the CPAN list, or do >> what I did, and the general consensus was that backing down the required >> version was a better option (since the newer version doesn't add any >> functionality that we actually use), so I did that. >> >> The reason is that a lot of people use Lenny (and or Ubuntu, which would >> cause this same issue), and Squeeze/Sid aren't stable yet (even though they >> work fine, I know that). Every indication I've gotten is that "we" prefer >> packaged versions of things instead of pulling direct from CPAN. I chose to >> eliminate the error message when installing on Lenny/Ubuntu from >> Makefile.PL, and allow a required version that was lower than the current >> version to help eliminate a bad user experience (An error!!! OMG! What do I >> do!). >> >> I truly don't care which way it's done: we can remove it from the package >> script and add it to the modules requiring installation through CPAN, no >> problem. I'll do those patches too, if necessary. >> >> That said, I don't think the reasoning behind this particular patch is >> unsound, based on past precedent. >> > > I'm not familiar with what has been the rule in the past. However, it is my > opinion we should establish one standard rather than attempting to work > around two different ones. > > If we are going to take the Debian/Ubuntu repo version as the standard, we > should set all modules available in those repos to the max current version > available in those repos, and be sure that policy is clear in the docs. We > should also develop only over those currently available versions. (I realize > in this particular case there is no programmatically compelling reason to > use the latest version, but that is not always the case.) > > FWIW, I favor Debian/Ubuntu personally, but am concerned about this from a > policy standpoint. > > If we indeed see this as the best direction to go, I recommend we add > something like this to our coding guidelines: When/Where available, Koha > Perl dependencies should be sourced from the current stable Debian/Ubuntu > repository. Perl dependencies not available in the repository should be > sourced from CPAN. Code development should be limited to the most current > version available from the proper source. Exceptions to this policy may be > made by gaining consensus from the developer section of the community. > > or some such language... > > Kind Regards, > Chris > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From altaf.mahmud at gmail.com Thu Dec 2 20:04:38 2010 From: altaf.mahmud at gmail.com (Altaf Mahmud) Date: Fri, 3 Dec 2010 01:04:38 +0600 Subject: [Koha-devel] Suppressing records in Koha 3.2.x Message-ID: Hello, Can someone please tell me how can I query to list the suppressed items in Koha database? Which database field indicates that the item is suppressed in OPAC view? Thanks. -- Altaf Mahmud System Programmer Ayesha Abed Library BRAC University Bangladesh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From henridamien.laurent at biblibre.com Thu Dec 2 21:09:40 2010 From: henridamien.laurent at biblibre.com (LAURENT Henri-Damien) Date: Thu, 02 Dec 2010 21:09:40 +0100 Subject: [Koha-devel] [Koha-patches] [PATCH] [Bug 5465] Makefile.PL asks for too high version of Business::ISBN In-Reply-To: <4CF7C919.1060706@biblibre.com> References: <1291301295-5097-1-git-send-email-lrea@nekls.org> <4CF7C919.1060706@biblibre.com> Message-ID: <4CF7FD04.8020001@biblibre.com> Le 02/12/2010 17:28, Paul Poulain a ?crit : > Le 02/12/2010 17:25, Chris Nighswonger a ?crit : >>> I did actually think about this before I did it. :) >>> >>> I asked around if it would be better to update the documentation to take >>> the package out of the install script and add it to the CPAN list, or do >>> what I did, and the general consensus was that backing down the required >>> version was a better option (since the newer version doesn't add any >>> functionality that we actually use), so I did that. >>> >>> The reason is that a lot of people use Lenny (and or Ubuntu, which would >>> cause this same issue), and Squeeze/Sid aren't stable yet (even though they >>> work fine, I know that). Every indication I've gotten is that "we" prefer >>> packaged versions of things instead of pulling direct from CPAN. I chose to >>> eliminate the error message when installing on Lenny/Ubuntu from >>> Makefile.PL, and allow a required version that was lower than the current >>> version to help eliminate a bad user experience (An error!!! OMG! What do I >>> do!). >>> > you can count BibLibre in "we" : we prefer packaged versions, no doubts ! > So ++ to your proposition to have the oldest version that works fine > required ! > I agree with that. But then we have to be quite specific then about the OS we support Redhat Fedora, CentOS, debian, ubuntu donot have the same standard as of perl module packaging. Or should we try and maintain packages for all the versions ? -- Henri-Damien LAURENT From cnighswonger at foundations.edu Thu Dec 2 21:51:37 2010 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 2 Dec 2010 15:51:37 -0500 Subject: [Koha-devel] [Koha-patches] [PATCH] [Bug 5465] Makefile.PL asks for too high version of Business::ISBN In-Reply-To: <4CF7FD04.8020001@biblibre.com> References: <1291301295-5097-1-git-send-email-lrea@nekls.org> <4CF7C919.1060706@biblibre.com> <4CF7FD04.8020001@biblibre.com> Message-ID: On Thu, Dec 2, 2010 at 3:09 PM, LAURENT Henri-Damien < henridamien.laurent at biblibre.com> wrote: > Le 02/12/2010 17:28, Paul Poulain a ?crit : > > Le 02/12/2010 17:25, Chris Nighswonger a ?crit : > >>> I did actually think about this before I did it. :) > >>> > >>> I asked around if it would be better to update the documentation to > take > >>> the package out of the install script and add it to the CPAN list, or > do > >>> what I did, and the general consensus was that backing down the > required > >>> version was a better option (since the newer version doesn't add any > >>> functionality that we actually use), so I did that. > >>> > >>> The reason is that a lot of people use Lenny (and or Ubuntu, which > would > >>> cause this same issue), and Squeeze/Sid aren't stable yet (even though > they > >>> work fine, I know that). Every indication I've gotten is that "we" > prefer > >>> packaged versions of things instead of pulling direct from CPAN. I > chose to > >>> eliminate the error message when installing on Lenny/Ubuntu from > >>> Makefile.PL, and allow a required version that was lower than the > current > >>> version to help eliminate a bad user experience (An error!!! OMG! What > do I > >>> do!). > >>> > > you can count BibLibre in "we" : we prefer packaged versions, no doubts ! > > So ++ to your proposition to have the oldest version that works fine > > required ! > > > I agree with that. > But then we have to be quite specific then about the OS we support > Redhat Fedora, CentOS, debian, ubuntu donot have the same standard as of > perl module packaging. > This is my only fear. If we stray too far into specifying *which* OS we will support, unforeseen problems could arise. And we begin introducing restrictions. However, regardless of the direction we take, we should standardize and state it so that we have a consistent understanding among developers. > Or should we try and maintain packages for all the versions ? > > Ich... I think this would be a pit into which we would not want to fall. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Thu Dec 2 22:11:32 2010 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 2 Dec 2010 16:11:32 -0500 Subject: [Koha-devel] [Koha-patches] [PATCH] [Bug 5465] Makefile.PL asks for too high version of Business::ISBN In-Reply-To: References: <1291301295-5097-1-git-send-email-lrea@nekls.org> Message-ID: On Thu, Dec 2, 2010 at 11:48 AM, Clay Fouts wrote: > Typically they're called "requirements" because they establish a minimum. > If a particular version is known to work and passes the tests, why require a > system to have a higher version installed? This most likely occurs because the developer adding the module develops over the latest module from CPAN rather than from xyz repository which may be behind CPAN. I think it would be poor practice to expect developers to hunt for the oldest package which contained the desired functionality. It would be better to adopt a sensible standard and adhere to it, which is what I was proposing we do. > Why instruct users to install from apt at all if they're just going to have > to update all the modules from CPAN anyway? > Users are only instructed to install from apt on platforms which support apt. Others should use their distro's package management system or CPAN... which is what gives rise to the "problem" under discussion. > Why warn them they *need* to upgrade if in reality they don't? "Needing" to upgrade is relative. In this case relative to the version required by the developer incorporating the module and thus Koha. If the user's system has a version older than that required by the developer, there is certainly the "need" to upgrade. > Issuing a warning during the build process should indicate something > potentially dire, not making noise about a preference. > Given that it is the developer who writes the code involving a selected module, I think that this is not a mere "preference" of the developer. The one developing knows better than anyone else which version is "needed." Using a module version other than that spec'd by the developer is, indeed, setting up for something potentially dire. There are two points involved here: 1. We need to establish acceptable guidelines for developers to follow when choosing packages. 2. We then need to communicate the clear message to the user that they need *at least* the version chosen by the developer. Then the warnings thrown will be unambiguous. (And I'm assuming here that "we" feel they are ambiguous as they stand at present.) Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From lrea at nekls.org Thu Dec 2 22:18:55 2010 From: lrea at nekls.org (Liz Rea) Date: Thu, 2 Dec 2010 15:18:55 -0600 Subject: [Koha-devel] [Koha-patches] [PATCH] [Bug 5465] Makefile.PL asks for too high version of Business::ISBN In-Reply-To: <4CF7FD04.8020001@biblibre.com> References: <1291301295-5097-1-git-send-email-lrea@nekls.org> <4CF7C919.1060706@biblibre.com> <4CF7FD04.8020001@biblibre.com> Message-ID: <3CA00ABF-1C41-4C17-96E5-FDB8B2A25804@nekls.org> Then I make a formal proposal that as a community we have an understanding of the following guidelines: For Debian and Ubuntu, we prefer to suggest/use packaged versions (if they are adequate) for the latest stable version of the OS at the time of release. Other dependencies that do not have packages or the packaged version is inadequate can be retrieved from CPAN, and the documentation will note which they are. Required versions should be the lowest version that allows all Koha functionality. It is the responsibility of the person adding an enhanced functionality to up the required version number when necessary. Other OS's are supported with dependencies coming from CPAN or packages/RPM's for that distribution, assuming they meet the version requirement. What do you think? Liz Rea NEKLS On Dec 2, 2010, at 2:09 PM, LAURENT Henri-Damien wrote: > Le 02/12/2010 17:28, Paul Poulain a ?crit : >> Le 02/12/2010 17:25, Chris Nighswonger a ?crit : >>>> I did actually think about this before I did it. :) >>>> >>>> I asked around if it would be better to update the documentation to take >>>> the package out of the install script and add it to the CPAN list, or do >>>> what I did, and the general consensus was that backing down the required >>>> version was a better option (since the newer version doesn't add any >>>> functionality that we actually use), so I did that. >>>> >>>> The reason is that a lot of people use Lenny (and or Ubuntu, which would >>>> cause this same issue), and Squeeze/Sid aren't stable yet (even though they >>>> work fine, I know that). Every indication I've gotten is that "we" prefer >>>> packaged versions of things instead of pulling direct from CPAN. I chose to >>>> eliminate the error message when installing on Lenny/Ubuntu from >>>> Makefile.PL, and allow a required version that was lower than the current >>>> version to help eliminate a bad user experience (An error!!! OMG! What do I >>>> do!). >>>> >> you can count BibLibre in "we" : we prefer packaged versions, no doubts ! >> So ++ to your proposition to have the oldest version that works fine >> required ! >> > I agree with that. > But then we have to be quite specific then about the OS we support > Redhat Fedora, CentOS, debian, ubuntu donot have the same standard as of > perl module packaging. > Or should we try and maintain packages for all the versions ? > -- > Henri-Damien LAURENT > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ From gmcharlt at gmail.com Thu Dec 2 22:28:49 2010 From: gmcharlt at gmail.com (Galen Charlton) Date: Thu, 2 Dec 2010 16:28:49 -0500 Subject: [Koha-devel] [Koha-patches] [PATCH] [Bug 5465] Makefile.PL asks for too high version of Business::ISBN In-Reply-To: References: <1291301295-5097-1-git-send-email-lrea@nekls.org> Message-ID: Hi, On Thu, Dec 2, 2010 at 4:11 PM, Chris Nighswonger wrote: > I think it would be poor practice to expect developers to > hunt for the oldest package which contained the desired functionality. It > would be better to adopt a sensible standard and adhere to it, which is what > I was proposing we do. There's no harm if a developer who adds a new Perl module dependency had simply used the latest and greatest, but there's also no harm if somebody points out that an earlier version of the module can serve the needs of Koha just as well. Ideally, Koha's test cases will help bolster a decision to change a version requirement with evidence. Since it's a fact of life that different distributions are more or less conservative about how frequently they update packaged Perl modules, I think we ought to be a bit more flexible and accept that sometimes a minimum required version can be decreased. At least we can be grateful that, as far as I know, we don't have a situation where we need to specify a *maximum* required version for any of Koha's dependencies. Regards, Galen -- Galen Charlton gmcharlt at gmail.com From fridolyn.somers at gmail.com Fri Dec 3 08:30:54 2010 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Fri, 3 Dec 2010 08:30:54 +0100 Subject: [Koha-devel] Suppressing records in Koha 3.2.x In-Reply-To: References: Message-ID: Hie, The suppressed (="deleted") records from tables *biblio, biblioitems* and * items* are moved when deleted into tables *deletedbiblio*, * deletedbiblioitems* and *deleteditems*. Some other tables have a corresponding table beginning with *deleted* or * old*. Regards, -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com 2010/12/2 Altaf Mahmud > Hello, > > Can someone please tell me how can I query to list the suppressed items in > Koha database? Which database field indicates that the item is suppressed in > OPAC view? > > Thanks. > > > -- > Altaf Mahmud > System Programmer > Ayesha Abed Library > BRAC University > Bangladesh. > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From altaf.mahmud at gmail.com Fri Dec 3 12:34:06 2010 From: altaf.mahmud at gmail.com (Altaf Mahmud) Date: Fri, 3 Dec 2010 17:34:06 +0600 Subject: [Koha-devel] Suppressing records in Koha 3.2.x In-Reply-To: References: Message-ID: Actually, our library never used this feature: OpacSuppression, that is always set as 'Don't hide'. Moreover, we don't have any marc record with $942 field, but the *deletedbiblio, deletedbiblioitems *and *deleteditems *still have data. After getting your mail, I searched some items in normal OPAC view which are in *deletedbiblio *table. I got the items in Koha, the records are also in *biblio* table. That's why I'm still confused. Does Koha retain those 'deleted' items for any further reference, or those are supposed to be 'suppressed' items? What the reason could be? On Fri, Dec 3, 2010 at 1:30 PM, Fridolyn SOMERS wrote: > Hie, > > The suppressed (="deleted") records from tables *biblio, biblioitems* and > *items* are moved when deleted into tables *deletedbiblio*, * > deletedbiblioitems* and *deleteditems*. > > Some other tables have a corresponding table beginning with *deleted* or * > old*. > > Regards, > > -- > Fridolyn SOMERS > ICT engineer > PROGILONE - Lyon - France > fridolyn.somers at gmail.com > > 2010/12/2 Altaf Mahmud > >> Hello, >> >> Can someone please tell me how can I query to list the suppressed items in >> Koha database? Which database field indicates that the item is suppressed in >> OPAC view? >> >> Thanks. >> >> >> -- >> Altaf Mahmud >> System Programmer >> Ayesha Abed Library >> BRAC University >> Bangladesh. >> >> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : http://www.koha-community.org/ >> git : http://git.koha-community.org/ >> bugs : http://bugs.koha-community.org/ >> > > > > > -- Altaf Mahmud System Programmer Ayesha Abed Library BRAC University Bangladesh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian.walls at bywatersolutions.com Fri Dec 3 13:24:24 2010 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Fri, 3 Dec 2010 07:24:24 -0500 Subject: [Koha-devel] Suppressing records in Koha 3.2.x In-Reply-To: References: Message-ID: The deletedbiblio, deletedbiblioitems and deleteditems tables are for materials that have been deleted from your catalog. This provides a failsafe recovery option, in case the deletion was not correct. If you're confident you don't need any of the materials in those tables, you can truncate them to clear up space. It's much like emptying the trash on many desktop systems. OpacSuppression is determined by the 942$n MARC subfield. It is not mapped to the database, so you'll need to query and parse the MARC record in order to get a list of all items that are suppressed from OPAC view. -Ian 2010/12/3 Altaf Mahmud > Actually, our library never used this feature: OpacSuppression, that is > always set as 'Don't hide'. Moreover, we don't have any marc record with > $942 field, but the *deletedbiblio, deletedbiblioitems *and *deleteditems > *still have data. After getting your mail, I searched some items in normal > OPAC view which are in *deletedbiblio *table. I got the items in Koha, the > records are also in *biblio* table. That's why I'm still confused. Does > Koha retain those 'deleted' items for any further reference, or those are > supposed to be 'suppressed' items? What the reason could be? > > > On Fri, Dec 3, 2010 at 1:30 PM, Fridolyn SOMERS > wrote: > >> Hie, >> >> The suppressed (="deleted") records from tables *biblio, biblioitems* and >> *items* are moved when deleted into tables *deletedbiblio*, * >> deletedbiblioitems* and *deleteditems*. >> >> Some other tables have a corresponding table beginning with *deleted* or >> *old*. >> >> Regards, >> >> -- >> Fridolyn SOMERS >> ICT engineer >> PROGILONE - Lyon - France >> fridolyn.somers at gmail.com >> >> 2010/12/2 Altaf Mahmud >> >>> Hello, >>> >>> Can someone please tell me how can I query to list the suppressed items >>> in Koha database? Which database field indicates that the item is suppressed >>> in OPAC view? >>> >>> Thanks. >>> >>> >>> -- >>> Altaf Mahmud >>> System Programmer >>> Ayesha Abed Library >>> BRAC University >>> Bangladesh. >>> >>> >>> _______________________________________________ >>> Koha-devel mailing list >>> Koha-devel at lists.koha-community.org >>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >>> website : http://www.koha-community.org/ >>> git : http://git.koha-community.org/ >>> bugs : http://bugs.koha-community.org/ >>> >> >> >> >> >> > > > -- > Altaf Mahmud > System Programmer > Ayesha Abed Library > BRAC University > Bangladesh. > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From Katrin.Fischer at bsz-bw.de Fri Dec 3 13:28:14 2010 From: Katrin.Fischer at bsz-bw.de (Fischer, Katrin) Date: Fri, 3 Dec 2010 13:28:14 +0100 Subject: [Koha-devel] Suppressing records in Koha 3.2.x In-Reply-To: References: Message-ID: <028B1A54D03E7B4482CDCA4EC8F06BFDE15510@Bodensee.bsz-bw.de> Hi, suppressed and deleted are different things. Deleted things go into the tables mentioned before. Suppressed titles are not shown in OPAC, but can still be researched and displayed in Intranet. It is a separate feature. If you have set the sys pref to don't hide, you probably have no suppressed records yet. For a record to be suppressed in OPAC view the 942$n field has to be set to 1. The feature is described in the Koha manual: http://koha-community.org/documentation/3-2-manual/index.php?ch=c18#AEN3 113 There is no separate database field where you can see if a title is suppressed. The information is stored in the XML of biblioitems.marcxml. Katrin From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Altaf Mahmud Sent: Friday, December 03, 2010 12:34 PM To: Fridolyn SOMERS Cc: koha at lists.katipo.co.nz; Koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Suppressing records in Koha 3.2.x Actually, our library never used this feature: OpacSuppression, that is always set as 'Don't hide'. Moreover, we don't have any marc record with $942 field, but the deletedbiblio, deletedbiblioitems and deleteditems still have data. After getting your mail, I searched some items in normal OPAC view which are in deletedbiblio table. I got the items in Koha, the records are also in biblio table. That's why I'm still confused. Does Koha retain those 'deleted' items for any further reference, or those are supposed to be 'suppressed' items? What the reason could be? On Fri, Dec 3, 2010 at 1:30 PM, Fridolyn SOMERS wrote: Hie, The suppressed (="deleted") records from tables biblio, biblioitems and items are moved when deleted into tables deletedbiblio, deletedbiblioitems and deleteditems. Some other tables have a corresponding table beginning with deleted or old. Regards, -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com 2010/12/2 Altaf Mahmud Hello, Can someone please tell me how can I query to list the suppressed items in Koha database? Which database field indicates that the item is suppressed in OPAC view? Thanks. -- Altaf Mahmud System Programmer Ayesha Abed Library BRAC University Bangladesh. _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- Altaf Mahmud System Programmer Ayesha Abed Library BRAC University Bangladesh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From altaf.mahmud at gmail.com Fri Dec 3 15:01:38 2010 From: altaf.mahmud at gmail.com (Altaf Mahmud) Date: Fri, 3 Dec 2010 20:01:38 +0600 Subject: [Koha-devel] Suppressing records in Koha 3.2.x In-Reply-To: <028B1A54D03E7B4482CDCA4EC8F06BFDE15510@Bodensee.bsz-bw.de> References: <028B1A54D03E7B4482CDCA4EC8F06BFDE15510@Bodensee.bsz-bw.de> Message-ID: Thanks, I just learned a lot! On Fri, Dec 3, 2010 at 6:28 PM, Fischer, Katrin wrote: > Hi, > > > > suppressed and deleted are different things. > That what I guessed :) > > > Deleted things go into the tables mentioned before. > > > > Suppressed titles are not shown in OPAC, but can still be researched and > displayed in Intranet. It is a separate feature. If you have set the sys > pref to don?t hide, you probably have no suppressed records yet. For a > record to be suppressed in OPAC view the 942$n field has to be set to 1. > > > > The feature is described in the Koha manual: > http://koha-community.org/documentation/3-2-manual/index.php?ch=c18#AEN3113 > I found this feature under cataloging section of the manual: http://koha-community.org/documentation/3-2-manual/index.php?ch=c18#AEN296 > > > There is no separate database field where you can see if a title is > suppressed. The information is stored in the XML of biblioitems.marcxml. > Couldn't find the file even by exhaustive 'find' command, is it possible to provide the exact path? I need to have those data somehow. > > *From:* koha-devel-bounces at lists.koha-community.org [mailto: > koha-devel-bounces at lists.koha-community.org] *On Behalf Of *Altaf Mahmud > *Sent:* Friday, December 03, 2010 12:34 PM > *To:* Fridolyn SOMERS > *Cc:* koha at lists.katipo.co.nz; Koha-devel at lists.koha-community.org > *Subject:* Re: [Koha-devel] Suppressing records in Koha 3.2.x > > > > Actually, our library never used this feature: OpacSuppression, that is > always set as 'Don't hide'. Moreover, we don't have any marc record with > $942 field, but the *deletedbiblio, deletedbiblioitems *and *deleteditems > *still have data. After getting your mail, I searched some items in normal > OPAC view which are in *deletedbiblio *table. I got the items in Koha, the > records are also in *biblio* table. That's why I'm still confused. Does > Koha retain those 'deleted' items for any further reference, or those are > supposed to be 'suppressed' items? What the reason could be? > > On Fri, Dec 3, 2010 at 1:30 PM, Fridolyn SOMERS > wrote: > > Hie, > > The suppressed (="deleted") records from tables *biblio, biblioitems* and > *items* are moved when deleted into tables *deletedbiblio*, * > deletedbiblioitems* and *deleteditems*. > > Some other tables have a corresponding table beginning with *deleted* or * > old*. > > Regards, > > -- > Fridolyn SOMERS > ICT engineer > PROGILONE - Lyon - France > fridolyn.somers at gmail.com > > 2010/12/2 Altaf Mahmud > > Hello, > > Can someone please tell me how can I query to list the suppressed items in > Koha database? Which database field indicates that the item is suppressed in > OPAC view? > > Thanks. > > > -- > Altaf Mahmud > System Programmer > Ayesha Abed Library > BRAC University > Bangladesh. > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > > > > > > > -- > Altaf Mahmud > System Programmer > Ayesha Abed Library > BRAC University > Bangladesh. > -- Altaf Mahmud System Programmer Ayesha Abed Library BRAC University Bangladesh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From altaf.mahmud at gmail.com Fri Dec 3 15:14:07 2010 From: altaf.mahmud at gmail.com (Altaf Mahmud) Date: Fri, 3 Dec 2010 20:14:07 +0600 Subject: [Koha-devel] Suppressing records in Koha 3.2.x In-Reply-To: <028B1A54D03E7B4482CDCA4EC8F06BFDE15510@Bodensee.bsz-bw.de> References: <028B1A54D03E7B4482CDCA4EC8F06BFDE15510@Bodensee.bsz-bw.de> Message-ID: Please ignore this if found repetitive. I got a bounced reply for the last one. Thanks, I just learned a lot! On Fri, Dec 3, 2010 at 6:28 PM, Fischer, Katrin wrote: > Hi, > > > > suppressed and deleted are different things. > That what I guessed :) > > > Deleted things go into the tables mentioned before. > > > > Suppressed titles are not shown in OPAC, but can still be researched and > displayed in Intranet. It is a separate feature. If you have set the sys > pref to don?t hide, you probably have no suppressed records yet. For a > record to be suppressed in OPAC view the 942$n field has to be set to 1. > > > > The feature is described in the Koha manual: > http://koha-community.org/documentation/3-2-manual/index.php?ch=c18#AEN3113 > Though I found this feature under cataloging section of the manual: http://koha-community.org/documentation/3-2-manual/index.php?ch=c18#AEN296 > > > There is no separate database field where you can see if a title is > suppressed. The information is stored in the XML of biblioitems.marcxml. > Couldn't find the file even by exhaustive 'find' command, is it possible to provide the exact path? I need to have those data somehow. > > > *From:* koha-devel-bounces at lists.koha-community.org [mailto: > koha-devel-bounces at lists.koha-community.org] *On Behalf Of *Altaf Mahmud > *Sent:* Friday, December 03, 2010 12:34 PM > *To:* Fridolyn SOMERS > *Cc:* koha at lists.katipo.co.nz; Koha-devel at lists.koha-community.org > *Subject:* Re: [Koha-devel] Suppressing records in Koha 3.2.x > > > > Actually, our library never used this feature: OpacSuppression, that is > always set as 'Don't hide'. Moreover, we don't have any marc record with > $942 field, but the *deletedbiblio, deletedbiblioitems *and *deleteditems > *still have data. After getting your mail, I searched some items in normal > OPAC view which are in *deletedbiblio *table. I got the items in Koha, the > records are also in *biblio* table. That's why I'm still confused. Does > Koha retain those 'deleted' items for any further reference, or those are > supposed to be 'suppressed' items? What the reason could be? > > On Fri, Dec 3, 2010 at 1:30 PM, Fridolyn SOMERS > wrote: > > Hie, > > The suppressed (="deleted") records from tables *biblio, biblioitems* and > *items* are moved when deleted into tables *deletedbiblio*, * > deletedbiblioitems* and *deleteditems*. > > Some other tables have a corresponding table beginning with *deleted* or * > old*. > > Regards, > > -- > Fridolyn SOMERS > ICT engineer > PROGILONE - Lyon - France > fridolyn.somers at gmail.com > > 2010/12/2 Altaf Mahmud > > Hello, > > Can someone please tell me how can I query to list the suppressed items in > Koha database? Which database field indicates that the item is suppressed in > OPAC view? > > Thanks. > > > -- > Altaf Mahmud > System Programmer > Ayesha Abed Library > BRAC University > Bangladesh. > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > > > > > > > -- > Altaf Mahmud > System Programmer > Ayesha Abed Library > BRAC University > Bangladesh. > -- Altaf Mahmud System Programmer Ayesha Abed Library BRAC University Bangladesh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Katrin.Fischer at bsz-bw.de Fri Dec 3 15:31:44 2010 From: Katrin.Fischer at bsz-bw.de (Fischer, Katrin) Date: Fri, 3 Dec 2010 15:31:44 +0100 Subject: [Koha-devel] Suppressing records in Koha 3.2.x In-Reply-To: References: <028B1A54D03E7B4482CDCA4EC8F06BFDE15510@Bodensee.bsz-bw.de> Message-ID: <028B1A54D03E7B4482CDCA4EC8F06BFDE1553D@Bodensee.bsz-bw.de> Hi, it's not a file, but in the database. The table is called bibliotitems and the field is marcxml. But it's the whole MARC21 record in XML syntax and not only the field for OPAC suppression. So you have to parse it for the field you want to check. Hope that helps, Katrin From: Altaf Mahmud [mailto:altaf.mahmud at gmail.com] Sent: Friday, December 03, 2010 3:14 PM To: Fischer, Katrin Cc: koha at lists.katipo.co.nz; Koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Suppressing records in Koha 3.2.x Please ignore this if found repetitive. I got a bounced reply for the last one. Thanks, I just learned a lot! On Fri, Dec 3, 2010 at 6:28 PM, Fischer, Katrin wrote: Hi, suppressed and deleted are different things. That what I guessed :) Deleted things go into the tables mentioned before. Suppressed titles are not shown in OPAC, but can still be researched and displayed in Intranet. It is a separate feature. If you have set the sys pref to don't hide, you probably have no suppressed records yet. For a record to be suppressed in OPAC view the 942$n field has to be set to 1. The feature is described in the Koha manual: http://koha-community.org/documentation/3-2-manual/index.php?ch=c18#AEN3 113 Though I found this feature under cataloging section of the manual: http://koha-community.org/documentation/3-2-manual/index.php?ch=c18#AEN2 96 There is no separate database field where you can see if a title is suppressed. The information is stored in the XML of biblioitems.marcxml. Couldn't find the file even by exhaustive 'find' command, is it possible to provide the exact path? I need to have those data somehow. From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Altaf Mahmud Sent: Friday, December 03, 2010 12:34 PM To: Fridolyn SOMERS Cc: koha at lists.katipo.co.nz; Koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Suppressing records in Koha 3.2.x Actually, our library never used this feature: OpacSuppression, that is always set as 'Don't hide'. Moreover, we don't have any marc record with $942 field, but the deletedbiblio, deletedbiblioitems and deleteditems still have data. After getting your mail, I searched some items in normal OPAC view which are in deletedbiblio table. I got the items in Koha, the records are also in biblio table. That's why I'm still confused. Does Koha retain those 'deleted' items for any further reference, or those are supposed to be 'suppressed' items? What the reason could be? On Fri, Dec 3, 2010 at 1:30 PM, Fridolyn SOMERS wrote: Hie, The suppressed (="deleted") records from tables biblio, biblioitems and items are moved when deleted into tables deletedbiblio, deletedbiblioitems and deleteditems. Some other tables have a corresponding table beginning with deleted or old. Regards, -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com 2010/12/2 Altaf Mahmud Hello, Can someone please tell me how can I query to list the suppressed items in Koha database? Which database field indicates that the item is suppressed in OPAC view? Thanks. -- Altaf Mahmud System Programmer Ayesha Abed Library BRAC University Bangladesh. _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- Altaf Mahmud System Programmer Ayesha Abed Library BRAC University Bangladesh. -- Altaf Mahmud System Programmer Ayesha Abed Library BRAC University Bangladesh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fridolyn.somers at gmail.com Mon Dec 6 08:09:09 2010 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Mon, 6 Dec 2010 08:09:09 +0100 Subject: [Koha-devel] Suppressing records in Koha 3.2.x In-Reply-To: <028B1A54D03E7B4482CDCA4EC8F06BFDE1553D@Bodensee.bsz-bw.de> References: <028B1A54D03E7B4482CDCA4EC8F06BFDE15510@Bodensee.bsz-bw.de> <028B1A54D03E7B4482CDCA4EC8F06BFDE1553D@Bodensee.bsz-bw.de> Message-ID: To query into the XML (marcxml field), you can use a MySQL 5.1 feature that includes an XPATH into SQL : http://dev.mysql.com/doc/refman/5.1/en/xml-functions.html Reards 2010/12/3 Fischer, Katrin > Hi, > > > > it?s not a file, but in the database. The table is called bibliotitems and > the field is marcxml. > > But it?s the whole MARC21 record in XML syntax and not only the field for > OPAC suppression. > > So you have to parse it for the field you want to check. > > > > Hope that helps, > > > > Katrin > > > > *From:* Altaf Mahmud [mailto:altaf.mahmud at gmail.com] > *Sent:* Friday, December 03, 2010 3:14 PM > *To:* Fischer, Katrin > > *Cc:* koha at lists.katipo.co.nz; Koha-devel at lists.koha-community.org > *Subject:* Re: [Koha-devel] Suppressing records in Koha 3.2.x > > > > Please ignore this if found repetitive. I got a bounced reply for the last > one. > > > Thanks, I just learned a lot! > > On Fri, Dec 3, 2010 at 6:28 PM, Fischer, Katrin > wrote: > > Hi, > > > > suppressed and deleted are different things. > > > That what I guessed :) > > > > Deleted things go into the tables mentioned before. > > > > Suppressed titles are not shown in OPAC, but can still be researched and > displayed in Intranet. It is a separate feature. If you have set the sys > pref to don?t hide, you probably have no suppressed records yet. For a > record to be suppressed in OPAC view the 942$n field has to be set to 1. > > > > The feature is described in the Koha manual: > http://koha-community.org/documentation/3-2-manual/index.php?ch=c18#AEN3113 > > > Though I found this feature under cataloging section of the manual: > http://koha-community.org/documentation/3-2-manual/index.php?ch=c18#AEN296 > > > > There is no separate database field where you can see if a title is > suppressed. The information is stored in the XML of biblioitems.marcxml. > > > Couldn't find the file even by exhaustive 'find' command, is it possible to > provide the exact path? I need to have those data somehow. > > > > *From:* koha-devel-bounces at lists.koha-community.org [mailto: > koha-devel-bounces at lists.koha-community.org] *On Behalf Of *Altaf Mahmud > *Sent:* Friday, December 03, 2010 12:34 PM > *To:* Fridolyn SOMERS > *Cc:* koha at lists.katipo.co.nz; Koha-devel at lists.koha-community.org > *Subject:* Re: [Koha-devel] Suppressing records in Koha 3.2.x > > > > Actually, our library never used this feature: OpacSuppression, that is > always set as 'Don't hide'. Moreover, we don't have any marc record with > $942 field, but the *deletedbiblio, deletedbiblioitems *and *deleteditems > *still have data. After getting your mail, I searched some items in normal > OPAC view which are in *deletedbiblio *table. I got the items in Koha, the > records are also in *biblio* table. That's why I'm still confused. Does > Koha retain those 'deleted' items for any further reference, or those are > supposed to be 'suppressed' items? What the reason could be? > > On Fri, Dec 3, 2010 at 1:30 PM, Fridolyn SOMERS > wrote: > > Hie, > > The suppressed (="deleted") records from tables *biblio, biblioitems* and > *items* are moved when deleted into tables *deletedbiblio*, * > deletedbiblioitems* and *deleteditems*. > > Some other tables have a corresponding table beginning with *deleted* or * > old*. > > Regards, > > -- > Fridolyn SOMERS > ICT engineer > PROGILONE - Lyon - France > fridolyn.somers at gmail.com > > 2010/12/2 Altaf Mahmud > > Hello, > > Can someone please tell me how can I query to list the suppressed items in > Koha database? Which database field indicates that the item is suppressed in > OPAC view? > > Thanks. > > > -- > Altaf Mahmud > System Programmer > Ayesha Abed Library > BRAC University > Bangladesh. > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > > > > > > > -- > Altaf Mahmud > System Programmer > Ayesha Abed Library > BRAC University > Bangladesh. > > > > > -- > Altaf Mahmud > System Programmer > Ayesha Abed Library > BRAC University > Bangladesh. > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From cnighswonger at foundations.edu Mon Dec 6 14:24:00 2010 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Mon, 6 Dec 2010 08:24:00 -0500 Subject: [Koha-devel] 3.2.2 Release Schedule Message-ID: Hi all, 3.2.2 is on track to be released on December 22, 2010, however, there is another important date between now and then which I wanted to point out. On December 15, 2010, 3.2.2 will enter a string freeze to facilitate finalization of translation updates. After this date the only patches introducing string changes which will be pushed for 3.2.2 will be those addressing blocker bugs or security issues. All others will be pushed to 3.2.3. Patches not introducing string changes will be pushed up to the time of the release. As always, many thanks for all of the hard work everyone has been doing to shorten the list of bugs lately. Kind Regards, Chris Nighswonger 3.2 Release Maintainer -------------- next part -------------- An HTML attachment was scrubbed... URL: From henridamien.laurent at biblibre.com Mon Dec 6 22:16:32 2010 From: henridamien.laurent at biblibre.com (LAURENT Henri-Damien) Date: Mon, 06 Dec 2010 22:16:32 +0100 Subject: [Koha-devel] Meeting solr : Schedule Message-ID: <4CFD52B0.1070804@biblibre.com> Hi, We plan to do 2 meetings around solr so that the most people can be aware of the status of our work on solr. The two meetings scheduled are : Tuesday 7th, 21PM UTC Wednesday 15th 11AM UTC Main aim is to present our work, what we did and what we are to do, and try and gather good will and try and unite. It is still early stage though we worked hard, and those meetings can also be the place where you can provide feedback and questions. Schedule is : - We will first try and state the reasons that prompted us into that rewrite. - Then we will present what is working at this stage, and the way one can setup a new install - and the bricks we chose in order to make things more flexible - What we will do (What has to be done) - What could be done - Our ideas for a better integration * use cases on search so that we could have Unit tests on search * Development of modules with ZOOM for Data::SearchEngine We hope you can be there or read the logs. Any further questions you may want to ask can be asked on list. -- Henri-Damien LAURENT From mjr at phonecoop.coop Tue Dec 7 12:07:44 2010 From: mjr at phonecoop.coop (MJ Ray) Date: Tue, 7 Dec 2010 11:07:44 +0000 (GMT) Subject: [Koha-devel] Meeting solr : Schedule In-Reply-To: <4CFD52B0.1070804@biblibre.com> Message-ID: <20101207110744.268BDF749B@nail.towers.org.uk> LAURENT Henri-Damien wrote: > We plan to do 2 meetings around solr so that the most people can be > aware of the status of our work on solr. > > The two meetings scheduled are : > Tuesday 7th, 21PM UTC > Wednesday 15th 11AM UTC Why the change of times? We were consulted on 2200 and 1000 UTC. At least 2100 today means my attention will probably be divided, if I'm available at all. :-( Disappointed, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha From henridamien.laurent at gmail.com Tue Dec 7 13:34:04 2010 From: henridamien.laurent at gmail.com (LAURENT Henri-Damien) Date: Tue, 07 Dec 2010 13:34:04 +0100 Subject: [Koha-devel] Meeting solr : Schedule In-Reply-To: <20101207110744.268BDF749B@nail.towers.org.uk> References: <20101207110744.268BDF749B@nail.towers.org.uk> Message-ID: <4CFE29BC.608@gmail.com> Le 07/12/2010 12:07, MJ Ray a ?crit : > LAURENT Henri-Damien wrote: >> We plan to do 2 meetings around solr so that the most people can be >> aware of the status of our work on solr. >> >> The two meetings scheduled are : >> Tuesday 7th, 21PM UTC >> Wednesday 15th 11AM UTC > > Why the change of times? We were consulted on 2200 and 1000 UTC. At > least 2100 today means my attention will probably be divided, if I'm > available at all. :-( > > Disappointed, from what I can read there was no changes... It was stated quite clearly in my previous messages and time scheduled had always been the same. Two propositions were made in the evening... 21 and 23 PM and in the morning at 11AM 13AM. I am disappointed too if you cannot be really free at that time, since you voted and voted for both 21PM UTC and 23PM. I really did my best to propose and keep people informed of the progress. Nonetheless, you will be able to read the logs and the minutes of this meeting and speak your mind and opinion either on chan or on list. Friendly -- Henri-Damien LAURENT BibLibre From nengard at gmail.com Tue Dec 7 15:26:01 2010 From: nengard at gmail.com (Nicole Engard) Date: Tue, 7 Dec 2010 09:26:01 -0500 Subject: [Koha-devel] New Koha Mailing List - Koha Docs Message-ID: Hi all, Thanks to Henri-Damien at BibLibre we now have a working mailing list for sending patches to the documentation. Visit: https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-docs and sign up if you want to help out with the manual. The manual is available via the official git repo: http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary , just make sure you update the right version - there are now 3.2 and 3.4 manuals in that repo. If you would like to start a new language file, just let me know and I'll put some files in your language folder to get you started. Thanks a bunch, Nicole C. Engard Documentation Manager From henridamien.laurent at gmail.com Tue Dec 7 15:32:13 2010 From: henridamien.laurent at gmail.com (LAURENT Henri-Damien) Date: Tue, 07 Dec 2010 15:32:13 +0100 Subject: [Koha-devel] Meeting solr : Schedule Correction In-Reply-To: <4CFE29BC.608@gmail.com> References: <20101207110744.268BDF749B@nail.towers.org.uk> <4CFE29BC.608@gmail.com> Message-ID: <4CFE456D.8030603@gmail.com> Le 07/12/2010 13:34, LAURENT Henri-Damien a ?crit : > Le 07/12/2010 12:07, MJ Ray a ?crit : >> LAURENT Henri-Damien wrote: >>> We plan to do 2 meetings around solr so that the most people can be >>> aware of the status of our work on solr. >>> >>> The two meetings scheduled are : >>> Tuesday 7th, 21PM UTC >>> Wednesday 15th 11AM UTC >> >> Why the change of times? We were consulted on 2200 and 1000 UTC. At >> least 2100 today means my attention will probably be divided, if I'm >> available at all. :-( >> >> Disappointed, > from what I can read there was no changes... It was stated quite clearly > in my previous messages and time scheduled had always been the same. > Two propositions were made in the evening... 21 and 23 PM and in the > morning at 11AM 13AM. > I am disappointed too if you cannot be really free at that time, since > you voted and voted for both 21PM UTC and 23PM. > I really did my best to propose and keep people informed of the progress. > Nonetheless, you will be able to read the logs and the minutes of this > meeting and speak your mind and opinion either on chan or on list. > Friendly Oh Sorry... doodle set automatically my time zone when I thought it was displaying UTC. So it would be - Tuesday 7th, 20PM UTC - Wednesday 15th 10AM UTC I apologize for this misunderstanding. -- Henri-Damien LAURENT From mjr at phonecoop.coop Tue Dec 7 16:57:10 2010 From: mjr at phonecoop.coop (MJ Ray) Date: Tue, 7 Dec 2010 15:57:10 +0000 (GMT) Subject: [Koha-devel] Meeting solr : Schedule Correction In-Reply-To: <4CFE456D.8030603@gmail.com> Message-ID: <20101207155710.B19DAF749B@nail.towers.org.uk> LAURENT Henri-Damien wrote: > Oh Sorry... > doodle set automatically my time zone when I thought it was displaying UTC. > > So it would be > - Tuesday 7th, 20PM UTC > - Wednesday 15th 10AM UTC > I apologize for this misunderstanding. Yes, it's been pointed out to me that Doodle was different to the email that linked to it, which I hadn't noticed. From mjr at phonecoop.coop Tue Dec 7 21:42:02 2010 From: mjr at phonecoop.coop (MJ Ray) Date: Tue, 7 Dec 2010 20:42:02 +0000 (GMT) Subject: [Koha-devel] Search Engine Changes : let's get some solr In-Reply-To: <4CE06965.8040307@tamil.fr> Message-ID: <20101207204202.83AA7F749B@nail.towers.org.uk> Fr?d?ric Demians wrote (quoting someone without giving credit): > >> But since records stored into Koha are cleanly UTF-8 encoded, are > >> well formed XML and respect a minimalist schema, > > That is the ideal. In practice, Koha currently does not enforce either > > of your two assumptions in that statement; patches to tighten that up > > would be a good idea. > > I don't understand. Do you mean that biblioitems.marcxml field and its > mirror in Zebra can contain something else than valid MARCXML? Invalid > encoded characters shouldn't change anything whatever parser is used. I > see bug #2916 on bugzilla. Is there something more? Well, 2916 is a description of the general problem, but there appear to be multiple vectors for this invalid MARCXML to get in there. If I remember correctly, I don't think it reaches the Zebra mirror because what goes there is MARC that is generated from the MARCXML, so no valid marcxml field means no MARC for Zebra. Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha From robin at catalyst.net.nz Wed Dec 8 06:58:47 2010 From: robin at catalyst.net.nz (Robin Sheat) Date: Wed, 08 Dec 2010 18:58:47 +1300 Subject: [Koha-devel] Test case failures and database access Message-ID: <1291787927.2428.166.camel@zarathud> While attempting to put the packages for 3.2.1 together, I encountered a number of test cases that fail unless you have a database configured. This seems to be due to tests 'use'ing modules that attempt to connect to the database immediately, and therefore failing. The tests I've noticed doing this are: 00-load.t External_BakerTaylor.t Reports_Guided.t Service.t Tags.t UploadedFile.t VirtualShelves_Page.t I'm after some opinions on how to best solve this. My ideas are: * Move these tests into a 'db_dependent' directory so that they aren't run by default. Perhaps add a 'make test_all' rule that includes them. * Have the packages move the iffy ones out of the way (although they will still fail for anyone running 'make test' without the database set up.) * Introduce an environment variable that is set during testing that tells C4::Context (or whatever it is making the DB connection) that failures are OK. This may reduce test coverage however, which we don't want. For now I'm going to make a patch that does the first one (and fixes 00-load.t so that it avoids loading the problematic ones) but I'm interested to see if someone has other ideas or strong opinions on the best way to do this. This is tracked here: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5477 -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From robin at catalyst.net.nz Wed Dec 8 08:08:12 2010 From: robin at catalyst.net.nz (Robin Sheat) Date: Wed, 08 Dec 2010 20:08:12 +1300 Subject: [Koha-devel] Test case failures and database access In-Reply-To: <1291787927.2428.166.camel@zarathud> References: <1291787927.2428.166.camel@zarathud> Message-ID: <1291792092.2428.167.camel@zarathud> Robin Sheat schreef op wo 08-12-2010 om 18:58 [+1300]: > I'm after some opinions on how to best solve this. My ideas are: > * Move these tests into a 'db_dependent' directory so that they aren't > run by default. Perhaps add a 'make test_all' rule that includes them. And, I found that a directory for this already exists. Convenient :) -- Robin Sheat Catalyst IT Ltd. ? +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From henridamien.laurent at biblibre.com Wed Dec 8 09:32:34 2010 From: henridamien.laurent at biblibre.com (LAURENT Henri-Damien) Date: Wed, 08 Dec 2010 09:32:34 +0100 Subject: [Koha-devel] 1st solr meeting : logs Message-ID: <4CFF42A2.10604@biblibre.com> Hi, you can find there the logs of yesterday meeting. http://librarypolice.com/koha-meetings/2010/koha.2010-12-07-20.00.log.html We hope that people were not too much taken away by the form of the meeting. I talked too much. Please feel free to answer back and tell what you really expected, whether you wanted more technical details as of how we did or how to test, or what we still have to do and how we will do. We are disappointed by the fact that it was not that much interactive. We will try to make it clearer at the next meeting. Anyway, you can get the links from http://librarypolice.com/koha-meetings/2010/koha.2010-12-07-20.00.html to read more about what we did. The wip/solr branch is open. So you can use that. Please note nonetheless, as a side note, that we worked much more than what we were contractually mandated to do because we think that solr support is worth it for the whole community. Friendly -- Henri-Damien LAURENT BibLibre From tajoli at cilea.it Wed Dec 8 13:22:50 2010 From: tajoli at cilea.it (Zeno Tajoli) Date: Wed, 08 Dec 2010 13:22:50 +0100 Subject: [Koha-devel] about bug 4506 and branch new/awaiting_qa/analytical_records Message-ID: <4CFF789A.9080803@cilea.it> Hi katrin, I replay with an email because I have pronlem with iirc. But I send the mail also to koha-dev, to share information about this develop. The feature of analytical records is not activated by an system preference. But I will insert this check. I'm OK on your idea to use the 'controlrecord number' if you are part of a Union Cataloge. In a local sistem 'controlrecord number' = biblionumber We use alse itemrecord number because the link is an analytic link. From fridolyn.somers at gmail.com Wed Dec 8 16:41:52 2010 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Wed, 8 Dec 2010 16:41:52 +0100 Subject: [Koha-devel] duplicated vokal images Message-ID: Hie, I found that *Book.png* and *Book-32px.png* exists in vokal images with both upper and lower case. Is this a bug ? Is causes a big problem in Windows file system. Regards, -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From ian.walls at bywatersolutions.com Wed Dec 8 18:15:40 2010 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Wed, 8 Dec 2010 12:15:40 -0500 Subject: [Koha-devel] duplicated vokal images In-Reply-To: References: Message-ID: Fridolyn, Some of the files got remained from upper case to lower, and my patch must have missed the 'remove'. I'll work up a fix for this, and get it out to the community. -Ian 2010/12/8 Fridolyn SOMERS > Hie, > > I found that *Book.png* and *Book-32px.png* exists in vokal images with > both upper and lower case. > Is this a bug ? > Is causes a big problem in Windows file system. > > Regards, > -- > Fridolyn SOMERS > ICT engineer > PROGILONE - Lyon - France > fridolyn.somers at gmail.com > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From colin.campbell at ptfs-europe.com Thu Dec 9 11:03:36 2010 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Thu, 09 Dec 2010 10:03:36 +0000 Subject: [Koha-devel] Test case failures and database access In-Reply-To: <1291787927.2428.166.camel@zarathud> References: <1291787927.2428.166.camel@zarathud> Message-ID: <4D00A978.9020600@ptfs-europe.com> On 08/12/10 05:58, Robin Sheat wrote: > While attempting to put the packages for 3.2.1 together, I encountered a > number of test cases that fail unless you have a database configured. > This seems to be due to tests 'use'ing modules that attempt to connect > to the database immediately, and therefore failing. > > I'm after some opinions on how to best solve this. My ideas are: > * Move these tests into a 'db_dependent' directory so that they aren't > run by default. Perhaps add a 'make test_all' rule that includes them. > * Have the packages move the iffy ones out of the way (although they > will still fail for anyone running 'make test' without the database set > up.) > * Introduce an environment variable that is set during testing that > tells C4::Context (or whatever it is making the DB connection) that > failures are OK. This may reduce test coverage however, which we don't > want. I'm wondering if the last possibility might be enhanced by using something like DBD::Mock. Cheers Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campbell at ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com From colin.campbell at ptfs-europe.com Fri Dec 10 12:53:56 2010 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Fri, 10 Dec 2010 11:53:56 +0000 Subject: [Koha-devel] Database Revisions Message-ID: <4D0214D4.6000500@ptfs-europe.com> I notice the DB Revisions table on the wiki is empty. It seems to have fallen into disuse but there are a number of db updates waiting upstream. I've recreated the page and claimed an update version for a patch I signed off. Wondering if there is a preferable method to make Chris's life easier. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campbell at ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com From kmkale at anantcorp.com Fri Dec 10 14:08:40 2010 From: kmkale at anantcorp.com (Koustubha Kale) Date: Fri, 10 Dec 2010 18:38:40 +0530 Subject: [Koha-devel] Bug 4036 problems after upgrading from 3.00.05 to 3.02.01 Message-ID: Hi, I downloaded 3.02.01 tarball and upgraded the existing 3.00.05 install via the make upgrade route after taking care of all perl dependencies. The librarian was unable to issue to patrons with overdues. The yellow box was showing "Patron has had overdue items and is blocked for 10 day(s)." This led me to bug 4036. On investigating in /usr/share/koha I found that.. 1) koha-tmpl/intranet-tmpl/prog/en/modules/circ/circulation.tmpl had the entries corresponding to the patch proposed here http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=1795 2) I could not find a syspref setting AllowIssuingForPatronsWithOverdues but a corresponding variable was present in the mysql database table systempreferences. 3) I also did not find code introduced in the proposed patch in either C4/Members.pm or koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/circulation.pref 4) I found that these code bits were also missing from C4/Members.pm or koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/circulation.pref from the untarred source code of 3.02.01 5) Adding the changes as per proposed patch at http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=1795 to C4/Members.pm and koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/circulation.pref resolved the issue. It seems the changes proposed to bug 4036 at http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=1795 were pushed only partially. Maybe that this is a bug? 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 From kmkale at anantcorp.com Fri Dec 10 14:24:08 2010 From: kmkale at anantcorp.com (Koustubha Kale) Date: Fri, 10 Dec 2010 18:54:08 +0530 Subject: [Koha-devel] Bug 4036 problems after upgrading from 3.00.05 to 3.02.01 In-Reply-To: References: Message-ID: I would also like to add that before doing any changes to code, 'OverduesBlockCirc' was set to "Ask for confirmation" and the system was still giving the message "Patron has had overdue items and is blocked for 10 day(s)." i.e. there was no yes/ no option. ( bug 4405 ) 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 From henridamien.laurent at gmail.com Sat Dec 11 00:23:36 2010 From: henridamien.laurent at gmail.com (Henri-Damien LAURENT) Date: Sat, 11 Dec 2010 00:23:36 +0100 Subject: [Koha-devel] RE : Database Revisions Message-ID: Sure. Change the updatedatabase for atomic updates. Le 10 d?c. 2010, 12:53 PM, "Colin Campbell" a ?crit : I notice the DB Revisions table on the wiki is empty. It seems to have fallen into disuse but there are a number of db updates waiting upstream. I've recreated the page and claimed an update version for a patch I signed off. Wondering if there is a preferable method to make Chris's life easier. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campbell at ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmkale at anantcorp.com Sat Dec 11 11:55:21 2010 From: kmkale at anantcorp.com (Koustubha Kale) Date: Sat, 11 Dec 2010 16:25:21 +0530 Subject: [Koha-devel] RFC : Local cover images Message-ID: Hi All, I have received sponsorship from "Sikh National Archives" to add the ability in Koha to display book covers scanned and stored locally in the server. "Sikh National Archives" have a lot of old / rare books & manuscripts which do not have ISBN hence this requirement. Here are the customer requirements in brief : 1. Provide facility to upload scanned cover images linked to biblionumber. 2. Create required mysql tables to hold cover images. 3. Provide global system preference to control display of local cover images in OPAC. 4. Create system preference to decide priority of cover images from multiple providers such as Amazon, Google, Local. 5. Customize OPAC to display only first cover image found as per system preference priority. 6. Customize OPAC search and detail pages to display local cover images linked to biblionumber. 7. Provide user rights management to control upload of images. I have added a RFC to wiki here : http://wiki.koha-community.org/wiki/Local_cover_images_RFC I have added this information to Bug 1633 here : http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1633 Requesting for comments and suggestions.. 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 From ian.bays at ptfs-europe.com Sat Dec 11 12:33:04 2010 From: ian.bays at ptfs-europe.com (Ian Bays) Date: Sat, 11 Dec 2010 11:33:04 +0000 Subject: [Koha-devel] RFC : Local cover images In-Reply-To: References: Message-ID: <4D036170.8070201@ptfs-europe.com> Hi Koustubha That's a great feature to add to Koha. Congratulations on this. The only part that I worry about is using the bibliomumber for access: If you were to ever re-install and wanted to export the bib data and re-import then you would be likely to get different biblionumbers for records, so you would lose the link to the images. I would have thought that there should be some unique number or code for each title which you might put into a tag such as the 024 MARC21 tag (Other Standard Identifier): http://www.loc.gov/marc/bibliographic/bd024.html Maybe have the tag and subfield as a system pref? All the best. Ian On 11/12/2010 10:55, Koustubha Kale wrote: > Hi All, > I have received sponsorship from "Sikh National Archives" to add the > ability in Koha to display book covers scanned and stored locally in > the server. "Sikh National Archives" have a lot of old / rare books& > manuscripts which do not have ISBN hence this requirement. > > Here are the customer requirements in brief : > 1. Provide facility to upload scanned cover images linked to biblionumber. > 2. Create required mysql tables to hold cover images. > 3. Provide global system preference to control display of local cover > images in OPAC. > 4. Create system preference to decide priority of cover images from multiple > providers such as Amazon, Google, Local. > 5. Customize OPAC to display only first cover image found as per > system preference > priority. > 6. Customize OPAC search and detail pages to display local cover > images linked to > biblionumber. > 7. Provide user rights management to control upload of images. > > I have added a RFC to wiki here : > http://wiki.koha-community.org/wiki/Local_cover_images_RFC > > I have added this information to Bug 1633 here : > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1633 > > Requesting for comments and suggestions.. > > 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 > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Ian Bays Director of Projects PTFS Europe.com mobile: +44 (0) 7774995297 phone: +44 (0) 800 756 6803 skype: ian.bays email: ian.bays at ptfs-europe.com From kmkale at anantcorp.com Sat Dec 11 13:14:19 2010 From: kmkale at anantcorp.com (Koustubha Kale) Date: Sat, 11 Dec 2010 17:44:19 +0530 Subject: [Koha-devel] RFC : Local cover images In-Reply-To: <4D036170.8070201@ptfs-europe.com> References: <4D036170.8070201@ptfs-europe.com> Message-ID: Hi Ian, On Sat, Dec 11, 2010 at 5:03 PM, Ian Bays wrote: > Hi Koustubha > That's a great feature to add to Koha. ?Congratulations on this. > The only part that I worry about is using the bibliomumber for access: If > you were to ever re-install and wanted to export the bib data and re-import > then you would be likely to get different biblionumbers for records, so you > would lose the link to the images. > I would have thought that there should be some unique number or code for > each title which you might put into a tag such as the 024 MARC21 tag (Other > Standard Identifier): > http://www.loc.gov/marc/bibliographic/bd024.html > Maybe have the tag and subfield as a system pref? Valid point about the export and re-import and a good idea of linking with a marc tag. Thank you. 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 From jcamins at cpbibliography.com Sat Dec 11 15:27:51 2010 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Sat, 11 Dec 2010 09:27:51 -0500 Subject: [Koha-devel] RFC : Local cover images In-Reply-To: References: <4D036170.8070201@ptfs-europe.com> Message-ID: Koustubha, On Sat, Dec 11, 2010 at 7:14 AM, Koustubha Kale wrote: > Valid point about the export and re-import and a good idea of linking > with a marc tag. Thank you. > I agree with Ian that a syspref specifying which field and subfield to use to find local cover images would be best. I think it would also be a good idea to have a syspref for the base URL of the local cover image folder. This way one could keep the cover images on an external server. Regards, Jared -- Jared Camins-Esakov Freelance bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins at cpbibliography.com (web) http://www.cpbibliography.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eric.Begin at inLibro.com Sat Dec 11 15:29:05 2010 From: Eric.Begin at inLibro.com (=?ISO-8859-1?Q?Eric_B=E9gin?=) Date: Sat, 11 Dec 2010 09:29:05 -0500 Subject: [Koha-devel] RFC : Local cover images In-Reply-To: <4D037EAB.6020508@inLibro.com> References: <4D036170.8070201@ptfs-europe.com> <4D037EAB.6020508@inLibro.com> Message-ID: <4D038AB1.4050702@inLibro.com> Hi Koustabha, If we are going to keep information in a MARC field, why not put the file name directly. That way, it doesn't have to be only a number, I could have HarryPotter_V1.jpg or even a remote path. I looked up the MARC standard and it would make sense to store the path to the file in the 856$u field, specifying Image (or Cover) in the $3 field. There is such an example in http://www.loc.gov/marc/authority/ad856.html. *856* *4#**$3*image*$u*http://www.ibiblio.org/wm/paint/auth/vinci/joconde/joconde.jpg A syspref could also be added for a base directory in which are located the files. My 2 cents, Eric On 2010-12-11 07:14, Koustubha Kale wrote: > Hi Ian, > > On Sat, Dec 11, 2010 at 5:03 PM, Ian Bays wrote: >> Hi Koustubha >> That's a great feature to add to Koha. Congratulations on this. >> The only part that I worry about is using the bibliomumber for access: If >> you were to ever re-install and wanted to export the bib data and re-import >> then you would be likely to get different biblionumbers for records, so you >> would lose the link to the images. >> I would have thought that there should be some unique number or code for >> each title which you might put into a tag such as the 024 MARC21 tag (Other >> Standard Identifier): >> http://www.loc.gov/marc/bibliographic/bd024.html >> Maybe have the tag and subfield as a system pref? > Valid point about the export and re-import and a good idea of linking > with a marc tag. Thank you. > > 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 > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website :http://www.koha-community.org/ > git :http://git.koha-community.org/ > bugs :http://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederic at tamil.fr Sun Dec 12 09:16:07 2010 From: frederic at tamil.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_Demians?=) Date: Sun, 12 Dec 2010 09:16:07 +0100 Subject: [Koha-devel] RFC : Local cover images In-Reply-To: References: Message-ID: <4D0484C7.20709@tamil.fr> Le 11/12/2010 11:55, Koustubha Kale a ?crit : > 1. Provide facility to upload scanned cover images linked to > biblionumber. Where will you store them? On Koha server? on another server? on flickr? somewhere else? Will you upload image file one by one during cataloging? or will you load them in batch? Is there any chance to share them with other libraries? > 2. Create required mysql tables to hold cover images. Isn't it a disputable point? If image files are stored on file system, the Web server (Apache or other) can optimize file delivering, the web browser also. Will it be possible with DB stored files? > 4. Create system preference to decide priority of cover images from > multiple providers such as Amazon, Google, Local. +1 It's a very necessary feature. It could be tricky to do since the way to retrieve cover images are so different depending of sources. From my perspective, you will need to redesign Amazon cover image fetching. Now Amazon images are directly linked from an tag target on URL based on biblio record normalized ISBN (ISBN-10)--but which one? You should use Amazon API in javascript to ask for images. This way some current shortcomings could be overcome. For example it would be possible to get images for resources other that books: CD, DVD... Thanks. From kmkale at anantcorp.com Sun Dec 12 09:40:16 2010 From: kmkale at anantcorp.com (Koustubha Kale) Date: Sun, 12 Dec 2010 14:10:16 +0530 Subject: [Koha-devel] RFC : Local cover images In-Reply-To: <4D0484C7.20709@tamil.fr> References: <4D0484C7.20709@tamil.fr> Message-ID: 2010/12/12 Fr?d?ric Demians : > Le 11/12/2010 11:55, Koustubha Kale a ?crit : > >> 1. Provide facility to upload scanned cover images linked to >> biblionumber. > > Where will you store them? On Koha server? Yes for now. > Will you upload image file one by one during cataloging? Yes it could be done by a form between biblio creation and item creation if the marc field we choose to hold the cover image information is populated ( refer Ian's mail earlier in this thread ). And also may be post cataloging from the details page in staff interface ( To facilitate uploading cover images for biblios already in the cataloge). > or will you load them in batch? Yes batch upload will be a good feature. > Is there any chance to share them with > other libraries? May be in future versions? As a syspref under control of the library? > >> 2. Create required mysql tables to hold cover images. > > Isn't it a disputable point? If image files are stored on file system, > the Web server (Apache or other) can optimize file delivering, the web > browser also. Will it be possible with DB stored files? We could store on the file system if it is a better option. 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 From nengard at gmail.com Sun Dec 12 14:49:28 2010 From: nengard at gmail.com (Nicole Engard) Date: Sun, 12 Dec 2010 08:49:28 -0500 Subject: [Koha-devel] December Newsletter Call for Articles In-Reply-To: References: Message-ID: Final call - articles to me by the end of tomorrow (in whatever timezone you're in). Thanks Nicole On Sun, Nov 28, 2010 at 8:22 AM, Nicole Engard wrote: > It's that time again! ?Please submit to me your short newsletter > articles by the13th of December. ?This will be the last "monthly" > issue of the Koha newsletter. ?Starting in 2011 the newsletter will be > published every other month. ?So if you have an announcement you want > out before February please send it to me for this newsletter. > > I encourage those with long articles to post them on the web and send > me a summary with a link to the full article. > > Thanks > Nicole > From chisangaz at gmail.com Mon Dec 13 14:07:55 2010 From: chisangaz at gmail.com (Raphael Muonga) Date: Mon, 13 Dec 2010 15:07:55 +0200 Subject: [Koha-devel] Migrating data from Liberty3 to Koha 3.0 plus Message-ID: Sorry, if I have used a wrong blog. Me I am asking for assistance in terms of migrating from Liberty3 to Koha 3.0 and above. Anybody with this sort of experience? Thanks in anticipation. Raphael Chisanga Muonga From dschust1 at gmail.com Tue Dec 14 17:13:41 2010 From: dschust1 at gmail.com (David Schuster) Date: Tue, 14 Dec 2010 10:13:41 -0600 Subject: [Koha-devel] KUDOS meeting at ALA Midwinter in San Diego Message-ID: KUDOS Meeting Scheduled for ALA Midwinter meeting Hilton San Diego Gaslamp Quarter Friday Jan 7th Pacific Room ? 6-7:30 PM Thanks to Equinox for sponsoring the room for us! All are welcome to come and share and discuss Agenda: Possible Face to Face US May Conference 501c3 ? update Other discussion topics David Schuster -- David Schuster Plano ISD Library Technology Coordinator -------------- next part -------------- An HTML attachment was scrubbed... URL: From henridamien.laurent at biblibre.com Tue Dec 14 17:53:11 2010 From: henridamien.laurent at biblibre.com (LAURENT Henri-Damien) Date: Tue, 14 Dec 2010 17:53:11 +0100 Subject: [Koha-devel] meeting solr tomorrow Message-ID: <4D07A0F7.3000405@biblibre.com> Hi We settled a meeting two weeks ago about solr. And planned a meeting for tomorrow Wednesday 15th morning, at 10 AM UTC In order to prepare that meeting a little deeper than the previous one, please consider taking time to read all the links here : - http://wiki.koha-community.org/wiki/Switch_to_Solr_RFC - http://librarypolice.com/koha-meetings/2010/koha.2010-12-07-20.00.html And try and test our solr instance on solr.biblibre.com and catalogue.solr.biblibre.com (especially the admin solr/index.pl page.) The wiki page is here to gather all your concerns and questions. Concerns section can gather all the questions you want to ask. We were clearly told that our work would not be integrated unless zebra could be chosen as an option. We take that into account. But still, we cannot leave things now. And we still hope that the community can provide some interesting feedback and ideas which we havenot thought of, or can help in some way for it to be a success and eventually integrated. Note that a patch has already been sent to us, and that we are giving it close look. We also have some progress to demonstrate in the progress of advanced search integration and items display. If you have special expectancies from that meeting, please donot hesitate to answer me directly or onlist. So that this could be at least mentioned. -- Henri-Damien LAURENT BibLibre From cnighswonger at foundations.edu Wed Dec 15 04:23:57 2010 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Tue, 14 Dec 2010 22:23:57 -0500 Subject: [Koha-devel] 3.2.2 Release Schedule In-Reply-To: References: Message-ID: Hi everyone, On Mon, Dec 6, 2010 at 8:24 AM, Chris Nighswonger wrote: > Hi all, > > 3.2.2 is on track to be released on December 22, 2010, however, there is > another important date between now and then which I wanted to point out. > > On December 15, 2010, 3.2.2 will enter a string freeze to facilitate > finalization of translation updates. After this date the only patches > introducing string changes which will be pushed for 3.2.2 will be those > addressing blocker bugs or security issues. All others will be pushed to > 3.2.3. As of Wed, 15 Dec 2010 02:48:50 +0000, 3.2.x is in a string freeze until the 3.2.2 release currently scheduled for December 22, 2010. From nengard at gmail.com Wed Dec 15 13:43:48 2010 From: nengard at gmail.com (Nicole Engard) Date: Wed, 15 Dec 2010 07:43:48 -0500 Subject: [Koha-devel] Official Koha Newsletter: Volume 1, Issue 12: December 2010 Message-ID: Read Online with full links: http://koha-community.org/koha-newsletter-volume-1issue-12-december-2010/ Official Koha Newsletter (ISSN 2153-8328) Volume 1, Issue 12: December 2010 Table of Contents * Koha Developments o RFC Roundup: Searching o SolR developments for Koha * Koha Tips & Tricks o Template Editing * Koha Events o Koha Conference in Kenya o KUDOS Meeting at ALA MW Koha Developments RFC Roundup: Searching by MJ Ray The following Searching improvement ideas have Requests For Comments listed on the Koha Community Wiki. If you have suggestions you could make about these topics, please add comments to the relevant page by logging in and clicking the ?Edit? tab at the top of the page. Alternatively, you could start a discussion on the email list or web forum. * Advanced cataloging search RFC o This idea would add to the Cataloging search accessible under the ?More? menu on the Koha staff side the same advanced search options that you find on the Search > Advanced Search page. * Bibliographic searches within acquisitions RFC o Upgrading the search within acquisitions to search catalogue, reservoir and Z39.50 sources consistently, without it being a choice between them. In a way, this might be like adding ?Catalogue? and ?Reservoir? to the Z39.50 search sources tickboxes. * EAN reading RFC o If this happens, scanning a book barcode to result in a correct ISBN search. It looks like this work is currently being done only for Solr (see below). Do Zebra users want it too? Are there problems in autodetecting EANs which should be considered? * Improvements to Authority Searching o Add the ability to search for multiple terms from multiple authorities simultaneously. * Improving searches on orders RFC o Adding new fields to acquisitions history searches: order date: beginning; end, reception date: beginning; end, library branch, vendor, librarian, budget, budget?s authorized value #1, budget?s authorized value #2. * Search authorities using keywords from same menu as keyword search RFC o Allowing patrons to search authorities using the same drop down list as for keyword searches and showing authorities matches in search results pages as suggested search terms. * Storing queries RFC o This idea would allow users to save their past searches. * Switch to Solr RFC o This suggests replacing the small C Zebra indexing server with the larger Java Solr one. It may enable some things to work better, at the cost of much memory and adding Java to Koha. Please, if you have any feedback or encouragement for any of the above, follow the link and add comments, or start a discussion. SolR developments for Koha by Claire Hernandez All this has already been posted on koha-devel list. In order to share with a wider audience our work and our expectancies about a new indexing engine (SolR) for Koha, we thought it would be good to gather all those thoughts here. Thanks to some libraries who are supporting our approach. Read more? Koha Tips & Tricks Template Editing by Fridolyn Somers To edit template files (*.tmpl), we use an HTML editor, from the WTP in Eclipse IDE. But it?s difficult to follow the template tags which are HTML comments : ??. In the last version of Eclipse, ?Helios?, the syntax coloring of HTML Editor offers for HTML comments a customization of both content and delimiters. We use this to highlight the comment?s content and have a better view of template tags. Here?s how it goes: In Preferences : Web / HTML Files / Editor / Syntax Coloring, choose a background color for ?Comment Content?. An example image can be see on the newsletter at : http://koha-community.org/koha-newsletter-volume-1issue-12-december-2010/ Koha Events Koha Conference in Kenya by Bernhard Mugambi When: 9:00 am ? 4:30 pm on December 18, 2010 Where: Gretsa University in Thika More Info: http://koha-community.org/koha-conference-kenya/ KUDOS Meeting at ALA MW by David Schuster When: 6:00 PM- 7:30 PM on Friday January 7th Where: Hilton San Diego Gaslamp Quarter: PACIFIC ROOM (Room sponsored by Equinox) More Info: http://www.facebook.com/event.php?eid=130011290393169 ------------------ Newsletter edited by Nicole C. Engard, Koha Documentation Manager. Please send future story ideas to nengard at gmail.com From paul.poulain at biblibre.com Thu Dec 16 11:45:07 2010 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 16 Dec 2010 11:45:07 +0100 Subject: [Koha-devel] BibLibre-memb-circ-upd branch rewritten Message-ID: <4D09EDB3.2010601@biblibre.com> Hello, I spoke on the chat with chris of the integration of our branches on official Koha. The BibLibre-memb-circ-upd is huge, and hard to deal with. So I have rewritten it: * git reset --soft to master * recommit everything, file (or group of files) by file. It means you won't have the history of our commits, but only the final result (it also means it seems i'm the author of all of this, which is not true) That result in 54 commits, much more readable than the previous branch. I will send-email them on patches@ in a few seconds, *chris c*, if you want me to push -f it on git.koha-community.org, you'll have to enable me, just let me know. Note about updatedatabase : all DB updates are in a single patch (the #51). If you plan to test an individual patch, pls double check if there is DB update needed in case of any problem. I've tested this branch vs master yesterday, and everything works well (on a fresh install, not tested update from a 3.2), except for 2 javascript glitches I couldn't fix: on circulation.pl, the 2 tabs at the bottom (with checkout(s) and holds are not tabbed. on opac-detail.pl, same problem with the new "rebounds" on subjects & author : some js should hide a tab, and it's not the case (see http://cat-bib.nimes.fr/cgi-bin/koha/opac-detail.pl?biblionumber=1413) to see how it should be. feedback welcomed ! cheers -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.poulain at biblibre.com Thu Dec 16 15:11:11 2010 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 16 Dec 2010 15:11:11 +0100 Subject: [Koha-devel] BibLibre-cataloguing rewritten (was: BibLibre-memb-circ-upd branch rewritten) In-Reply-To: <4D09EDB3.2010601@biblibre.com> References: <4D09EDB3.2010601@biblibre.com> Message-ID: <4D0A1DFF.7080600@biblibre.com> Le 16/12/2010 11:45, Paul Poulain a ?crit : > Hello, > > I spoke on the chat with chris of the integration of our branches on > official Koha. The BibLibre-memb-circ-upd is huge, and hard to deal with. > So I have rewritten it: > * git reset --soft to master > * recommit everything, file (or group of files) by file. It means you > won't have the history of our commits, but only the final result (it > also means it seems i'm the author of all of this, which is not true) I also did this for BibLibre-cataloguing Results in 17 patches i'll send now -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From ssenthilanand at gmail.com Thu Dec 16 15:21:34 2010 From: ssenthilanand at gmail.com (Senthil Anand) Date: Thu, 16 Dec 2010 19:51:34 +0530 Subject: [Koha-devel] Numerically sorting a new Zebra Index Message-ID: Hello, Running Koha 3.06 on Centos 5.5. I want to add a new item attribute, canumber to the Zebra Index. It should be visible on the staff client. All values are numbers ranging from 1 to around 15000000. I have done the following steps: 1. In bib1.att att 8032 canumber 2. In the marc21 record.abs melm 952$z canumber, canumber:n, item 3. In ccl.properties canumber 1=8032 Zebra has been reindexed. I want to use the canumber in place of acq-date in the Bulk label barcode generation. In label-item-search.pl under intranet/cgi-bin/labels . I am performing a search using the following limits : "canumber,ge=" and "canumber,le=". The search actually works and returns results but the results seem to be sorted as text. ie searching beween 1000 and 1010 returns items with canumber 1000000 etc. As a test I changed the attribute of itemnotes in items table from varchar to int(11) in a test machine and reran the index. Still not getting proper numeric sorting. The Zebra docs mention that lexicographic sorting is default and numeric sorting has to be enabled. As I understood it is defined in the record.abs. How can I change the mappings in record.abs to get numerically sorted results ? Is the query I am using in label-item-search.pl correct ? Regards, Senthil From henridamien.laurent at biblibre.com Fri Dec 17 12:34:19 2010 From: henridamien.laurent at biblibre.com (LAURENT Henri-Damien) Date: Fri, 17 Dec 2010 12:34:19 +0100 Subject: [Koha-devel] Data Persistence and Plack Message-ID: <4D0B4ABB.7060005@biblibre.com> Hi I am continuing to work on Data Persistence and Plack support. In that matter, I am first focusing on obvious circular references between Modules. I first naively thought that simply using direct calls to functions without calling use module would solve the problem. But if compilation is OK then at runtime, it would fail unless all the modules are loaded in Plack... And in CGI mode, it would fail. It seems that most of the Circular references in the code are owed to functions which have been created to do some checking before doing an operation... For instance : CanItemBeRenewed CanItemBeReserved CanBookBeReserved CanItemBeIssued CanItemBeIssued .... Deletion of Serials in DelBiblio Those things would be solved if we would create new modules in order to perform those checks and then call them not in the module but in the script itself... A kind of Controller. My proposal is to create a new directory in C4/ called Decisions or Controller (I am not fixed on a namespace for that.) And then create inside one module for one "Object" Circulation Reserve, Biblio, Serials... And use that in the scripts. I am aware that it would not fix circular references in the data structures itself... But that would be a first step towards persistence. Then we have to inspect at runtime the increase in Memory consuming and control with introspection... Maybe a server could be built and some apache logs replayed on that so that memory consumption could be traced. If you are working on the same stuff, and want to share what point you are at... Then come on #koha channel or let's organise a meeting around that. Any feedback would be welcome. -- Henri-Damien LAURENT From fridolyn.somers at gmail.com Fri Dec 17 14:40:39 2010 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Fri, 17 Dec 2010 14:40:39 +0100 Subject: [Koha-devel] Numerically sorting a new Zebra Index In-Reply-To: References: Message-ID: Hie, Have a look at @att 7 of Zebra : http://www.indexdata.com/zebra/doc/querymodel-zebra.html#querymodel-zebra-attr-sorting It introduces sorting into query. In ccl.properties you find ascending and descending sort : *sort1 7=1 sort2 7=2* So your ccl query looks like : *"(canumber,ge=1000 and "canumber,le=2000) or sort1,canumber=0"* *PS : * You must add the sort structure (:s) into "record.abs" : melm 952$z canumber, canumber:n, canumber:s, item Regards, On Thu, Dec 16, 2010 at 3:21 PM, Senthil Anand wrote: > Hello, > > Running Koha 3.06 on Centos 5.5. > > I want to add a new item attribute, canumber to the Zebra Index. It > should be visible on the staff client. All values are numbers ranging > from 1 to around 15000000. > > I have done the following steps: > > 1. In bib1.att > > att 8032 canumber > > 2. In the marc21 record.abs > > melm 952$z canumber, canumber:n, item > > 3. In ccl.properties > > canumber 1=8032 > > Zebra has been reindexed. > > I want to use the canumber in place of acq-date in the Bulk label > barcode generation. > > In label-item-search.pl under intranet/cgi-bin/labels . I am > performing a search using the following limits : > > "canumber,ge=" and > > "canumber,le=". > > The search actually works and returns results but the results seem to > be sorted as text. ie searching beween 1000 and 1010 returns items > with canumber 1000000 etc. As a test I changed the attribute of > itemnotes in items table from varchar to int(11) in a test machine and > reran the index. Still not getting proper numeric sorting. > > The Zebra docs mention that lexicographic sorting is default and > numeric sorting has to be enabled. As I understood it is defined in > the record.abs. How can I change the mappings in record.abs to get > numerically sorted results ? Is the query I am using in > label-item-search.pl correct ? > > Regards, > Senthil > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From colin.campbell at ptfs-europe.com Fri Dec 17 15:30:59 2010 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Fri, 17 Dec 2010 14:30:59 +0000 Subject: [Koha-devel] Data Persistence and Plack In-Reply-To: <4D0B4ABB.7060005@biblibre.com> References: <4D0B4ABB.7060005@biblibre.com> Message-ID: <4D0B7423.2030403@ptfs-europe.com> On 17/12/10 11:34, LAURENT Henri-Damien wrote: > It seems that most of the Circular references in the code are owed to > functions which have been created to do some checking before doing an > operation... > For instance : > CanItemBeRenewed > CanItemBeReserved > CanBookBeReserved > CanItemBeIssued > CanItemBeIssued > .... > Deletion of Serials in DelBiblio > Most of those routines are far too large and unmaintainable, many read the same data repeatedly and all mix business logic and reading data. It would probably be good if the "things" they deal with were abstracted into proper objects that police their own destruction, it would also give you the chance to have a more guaranteed interface to e.g. Item so that we dont have to scatter validations about through the business logic. Its one of the attractions of an ORM that it does this for you but you don't need an ORM to do it. I think if you can abstract away some of the current complexity it gets easier keep things clean. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campbell at ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com From paul.poulain at biblibre.com Fri Dec 17 15:37:47 2010 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 17 Dec 2010 15:37:47 +0100 Subject: [Koha-devel] Data Persistence and Plack In-Reply-To: <4D0B7423.2030403@ptfs-europe.com> References: <4D0B4ABB.7060005@biblibre.com> <4D0B7423.2030403@ptfs-europe.com> Message-ID: <4D0B75BB.4010909@biblibre.com> Le 17/12/2010 15:30, Colin Campbell a ?crit : > Most of those routines are far too large and unmaintainable, many read > the same data repeatedly and all mix business logic and reading data. It > would probably be good if the "things" they deal with were abstracted > into proper objects that police their own destruction, it would also > give you the chance to have a more guaranteed interface to e.g. Item so > that we dont have to scatter validations about through the business > logic. Its one of the attractions of an ORM that it does this for you > but you don't need an ORM to do it. I think if you can abstract away > some of the current complexity it gets easier keep things clean. Hi Colin : so... who's first : the egg or the chicken ? (frenchism suspected) Because an ORM can't be achieved without persistency (or we will get awful response times...) I'm in favor of doing one step after the other, and ORM is the step #2, after persistancy that is the #1. IMO, if you disagree, pls argue & convince me. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From colin.campbell at ptfs-europe.com Fri Dec 17 16:14:42 2010 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Fri, 17 Dec 2010 15:14:42 +0000 Subject: [Koha-devel] Data Persistence and Plack In-Reply-To: <4D0B75BB.4010909@biblibre.com> References: <4D0B4ABB.7060005@biblibre.com> <4D0B7423.2030403@ptfs-europe.com> <4D0B75BB.4010909@biblibre.com> Message-ID: <4D0B7E62.3060104@ptfs-europe.com> On 17/12/10 14:37, Paul Poulain wrote: > Le 17/12/2010 15:30, Colin Campbell a ?crit : >> Most of those routines are far too large and unmaintainable, many read >> the same data repeatedly and all mix business logic and reading data. It >> would probably be good if the "things" they deal with were abstracted >> into proper objects that police their own destruction, it would also >> give you the chance to have a more guaranteed interface to e.g. Item so >> that we dont have to scatter validations about through the business >> logic. Its one of the attractions of an ORM that it does this for you >> but you don't need an ORM to do it. I think if you can abstract away >> some of the current complexity it gets easier keep things clean. > Hi Colin : so... who's first : the egg or the chicken ? (frenchism > suspected) > > Because an ORM can't be achieved without persistency (or we will get > awful response times...) > > I'm in favor of doing one step after the other, and ORM is the step #2, > after persistancy that is the #1. > IMO, if you disagree, pls argue & convince me. > Many people implement persistency by using an ORM but if you look at what I wrote I said we did not need an ORM to achieve this. C. -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campbell at ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com From henridamien.laurent at gmail.com Fri Dec 17 16:32:26 2010 From: henridamien.laurent at gmail.com (LAURENT Henri-Damien) Date: Fri, 17 Dec 2010 16:32:26 +0100 Subject: [Koha-devel] Data Persistence and Plack In-Reply-To: <4D0B7423.2030403@ptfs-europe.com> References: <4D0B4ABB.7060005@biblibre.com> <4D0B7423.2030403@ptfs-europe.com> Message-ID: <4D0B828A.6010403@gmail.com> Le 17/12/2010 15:30, Colin Campbell a ?crit : > On 17/12/10 11:34, LAURENT Henri-Damien wrote: > >> It seems that most of the Circular references in the code are owed to >> functions which have been created to do some checking before doing an >> operation... >> For instance : >> CanItemBeRenewed >> CanItemBeReserved >> CanBookBeReserved >> CanItemBeIssued >> CanItemBeIssued >> .... >> Deletion of Serials in DelBiblio >> > Most of those routines are far too large and unmaintainable, many read > the same data repeatedly and all mix business logic and reading data. It > would probably be good if the "things" they deal with were abstracted > into proper objects that police their own destruction, it would also > give you the chance to have a more guaranteed interface to e.g. Item so > that we dont have to scatter validations about through the business > logic. Its one of the attractions of an ORM that it does this for you > but you don't need an ORM to do it. I think if you can abstract away > some of the current complexity it gets easier keep things clean. > > Colin > Thanks for this feedback. Nonetheless those functions are quite "generic" and if they need some refactoring, I guess that they would still need some external calls, for instance, you can Issue an item if it is not reserved... So those checks have to be done... Maybe it could be better abstracted... But I lack some hawkeye to tell how you would not need those external calls. I think that an exemple could be helpful in order to show me what could be done in your view. -- Henri-Damien LAURENT From henridamien.laurent at gmail.com Fri Dec 17 16:48:51 2010 From: henridamien.laurent at gmail.com (LAURENT Henri-Damien) Date: Fri, 17 Dec 2010 16:48:51 +0100 Subject: [Koha-devel] Numerically sorting a new Zebra Index In-Reply-To: References: Message-ID: <4D0B8663.5070600@gmail.com> Le 17/12/2010 14:40, Fridolyn SOMERS a ?crit : > Hie, > > Have a look at @att 7 of Zebra : > http://www.indexdata.com/zebra/doc/querymodel-zebra.html#querymodel-zebra-attr-sorting > > It introduces sorting into query. > > In ccl.properties you find ascending and descending sort : > /sort1 7=1 > sort2 7=2/ > > So your ccl query looks like : > /"(canumber,ge=1000 and "canumber,le=2000) or sort1,canumber=0"/ > > *_PS : _* > You must add the sort structure (:s) into "record.abs" : > > melm 952$z canumber, canumber:n, canumber:s, item > > Regards, Fridolyn, what you said is helpfull but not really fixes the problem... It appears that it lies in @attr 4=109 that should be used and not @attr 4=1 or @attr 4=6... That is to say Senthil has to tell on what TYPE of data he is trying to sort. Sorting on number is not the same as sorting alphabetical things. so in pqf it would be @or your query @attr 1=canumber @attr 7=1 @attr 4=109 1 in ccl yourquery or canumber,sort1,st-numeric=1 or edit the code so that it sends the correct queries. Hopes that helps... -- Henri-Damien LAURENT From fridolyn.somers at gmail.com Fri Dec 17 17:39:54 2010 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Fri, 17 Dec 2010 17:39:54 +0100 Subject: [Koha-devel] Numerically sorting a new Zebra Index In-Reply-To: <4D0B8663.5070600@gmail.com> References: <4D0B8663.5070600@gmail.com> Message-ID: You are right, I missed the @att type 4. Then, it should also be set on query. *I found another error *: le and ge souldn't come with "=" : use ">=" ans "<=". * *It gives :* "(canumber,st-numeric**>=1000 and canumber**,st-numeric<**=2000) or sort1,canumber**,st-numeric**=0".* *PS : * The zero in *sort1**(...)=0* means that this sort in the first (in case there is a second sort, sort=1, etc). If it doesn't work, send us the PQF(... @att ...) query from Zebra logs. Regards, On Fri, Dec 17, 2010 at 4:48 PM, LAURENT Henri-Damien < henridamien.laurent at gmail.com> wrote: > Le 17/12/2010 14:40, Fridolyn SOMERS a ?crit : > > Hie, > > > > Have a look at @att 7 of Zebra : > > > http://www.indexdata.com/zebra/doc/querymodel-zebra.html#querymodel-zebra-attr-sorting > > > > It introduces sorting into query. > > > > In ccl.properties you find ascending and descending sort : > > /sort1 7=1 > > sort2 7=2/ > > > > So your ccl query looks like : > > /"(canumber,ge=1000 and "canumber,le=2000) or sort1,canumber=0"/ > > > > *_PS : _* > > You must add the sort structure (:s) into "record.abs" : > > > > melm 952$z canumber, canumber:n, canumber:s, item > > > > Regards, > > Fridolyn, what you said is helpfull but not really fixes the problem... > It appears that it lies in @attr 4=109 that should be used and not @attr > 4=1 or @attr 4=6... > That is to say Senthil has to tell on what TYPE of data he is trying to > sort. > Sorting on number is not the same as sorting alphabetical things. > so in pqf it would be > @or your query @attr 1=canumber @attr 7=1 @attr 4=109 1 > in ccl > yourquery or canumber,sort1,st-numeric=1 > or edit the code so that it sends the correct queries. > Hopes that helps... > > -- > Henri-Damien LAURENT > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From colin.campbell at ptfs-europe.com Fri Dec 17 18:00:22 2010 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Fri, 17 Dec 2010 17:00:22 +0000 Subject: [Koha-devel] Data Persistence and Plack In-Reply-To: <4D0B828A.6010403@gmail.com> References: <4D0B4ABB.7060005@biblibre.com> <4D0B7423.2030403@ptfs-europe.com> <4D0B828A.6010403@gmail.com> Message-ID: <4D0B9726.6070401@ptfs-europe.com> On 17/12/10 15:32, LAURENT Henri-Damien wrote: > Le 17/12/2010 15:30, Colin Campbell a ?crit : >> On 17/12/10 11:34, LAURENT Henri-Damien wrote: >> >>> It seems that most of the Circular references in the code are owed to >>> functions which have been created to do some checking before doing an >>> operation... >>> For instance : >>> CanItemBeRenewed >>> CanItemBeReserved >>> CanBookBeReserved >>> CanItemBeIssued >>> CanItemBeIssued >>> .... >>> Deletion of Serials in DelBiblio >>> >> Most of those routines are far too large and unmaintainable, many read >> the same data repeatedly and all mix business logic and reading data. It >> would probably be good if the "things" they deal with were abstracted >> into proper objects that police their own destruction, it would also >> give you the chance to have a more guaranteed interface to e.g. Item so >> that we dont have to scatter validations about through the business >> logic. Its one of the attractions of an ORM that it does this for you >> but you don't need an ORM to do it. I think if you can abstract away >> some of the current complexity it gets easier keep things clean. >> >> Colin >> > Thanks for this feedback. > Nonetheless those functions are quite "generic" and if they need some > refactoring, I guess that they would still need some external calls, for > instance, you can Issue an item if it is not reserved... > So those checks have to be done... > Maybe it could be better abstracted... But I lack some hawkeye to tell > how you would not need those external calls. I think that an exemple > could be helpful in order to show me what could be done in your view. The problem is that the Modules containing the external calls are large and rambling. They export into our namespace lots we dont need. It is very hard when calling those routines to know confidently what side effects they may have. So we get a checkout( borrowercard, itemcard) { itemstuff = GetItem(itemcard) blah ... blah... ItemXYZ(itemstuff->itemid); blah .. blah ... ItemABC($var) etc; and we've got GetItem ItemXYZ ItemABC and loads more Item routines imported. And we probably duplicate external accesses across them. But if we have a wrapper class around item and do checkout( borrowercard, itemcard) { my $item = Item->new(ittemcard); blah ... blah ... $item->zyx(); blah .. blah $item->abc() item is lexical, if necessary it can call its destructor when it goes out of scope. We don't have to refetch data for different calls as it persists while the variable persists and we've not imported a pile of package variables into our namespace. Also in our business logic we can avoid those GetItem then a long if else checking varying things and replace that with a method call. For the kind of cases you are mentioning we have simple boolean methods: $item->renewable(); Cheers Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campbell at ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com From ssenthilanand at gmail.com Sat Dec 18 18:41:42 2010 From: ssenthilanand at gmail.com (Senthil Anand) Date: Sat, 18 Dec 2010 23:11:42 +0530 Subject: [Koha-devel] Numerically sorting a new Zebra Index In-Reply-To: References: <4D0B8663.5070600@gmail.com> Message-ID: Hello, I am basically sorting pure numbers from a varchar field. After changing the record.abs to melm 952$z canumber,canumber:n,canumber:s,item and using the query canumber,st-numeric>= and canumber,st-numeric<= with values 3 and 100 I get 11 items. mysql> select itemnotes from items where (itemnotes + 0) >= 3 and (itemnotes + 0) <= 100; ... 11 rows in set (1.16 sec) The corresponding barcodes are also identical in both cases. So it seems to work on my small test install in my netbook. Will check it in a larger test system with more varied canumber values in a few days and report back then. The whole Zebra search syntax seems completely alien to me after being used to SQL. Thanks for the tips. Regards, Senthil 2010/12/17 Fridolyn SOMERS : > You are right, > > I missed the @att type 4. > Then, it should also be set on query. > > I found another error : le and ge souldn't come with "=" : use ">=" ans > "<=". > > It gives : > > "(canumber,st-numeric>=1000 and canumber,st-numeric<=2000) or > sort1,canumber,st-numeric=0". > > PS : > The zero in sort1(...)=0 means that this sort in the first (in case there is > a second sort, sort=1, etc). > > If it doesn't work, send us the PQF(... @att ...) query from Zebra logs. > > Regards, > > On Fri, Dec 17, 2010 at 4:48 PM, LAURENT Henri-Damien > wrote: >> >> Le 17/12/2010 14:40, Fridolyn SOMERS a ?crit : >> > Hie, >> > >> > Have a look at @att 7 of Zebra : >> > >> > http://www.indexdata.com/zebra/doc/querymodel-zebra.html#querymodel-zebra-attr-sorting >> > >> > It introduces sorting into query. >> > >> > In ccl.properties you find ascending and descending sort : >> > /sort1 7=1 >> > sort2 7=2/ >> > >> > So your ccl query looks like : >> > /"(canumber,ge=1000 and "canumber,le=2000) or sort1,canumber=0"/ >> > >> > *_PS : _* >> > You must add the sort structure (:s) into "record.abs" : >> > >> > melm 952$z ? ?canumber, canumber:n, canumber:s, item >> > >> > Regards, >> >> Fridolyn, what you said is helpfull but not really fixes the problem... >> It appears that it lies in @attr 4=109 that should be used and not @attr >> 4=1 or @attr 4=6... >> That is to say Senthil has to tell on what TYPE of data he is trying to >> sort. >> Sorting on number is not the same as sorting alphabetical things. >> so in pqf it would be >> ? ? ? ?@or your query ?@attr 1=canumber @attr 7=1 @attr 4=109 1 >> in ccl >> ? ? ? ?yourquery or canumber,sort1,st-numeric=1 >> or edit the code so that it sends the correct queries. >> Hopes that helps... From henridamien.laurent at biblibre.com Fri Dec 17 19:09:21 2010 From: henridamien.laurent at biblibre.com (LAURENT Henri-Damien) Date: Fri, 17 Dec 2010 19:09:21 +0100 Subject: [Koha-devel] Data Persistence and Plack In-Reply-To: <4D0B9726.6070401@ptfs-europe.com> References: <4D0B4ABB.7060005@biblibre.com> <4D0B7423.2030403@ptfs-europe.com> <4D0B828A.6010403@gmail.com> <4D0B9726.6070401@ptfs-europe.com> Message-ID: <4D0BA751.3040602@biblibre.com> Le 17/12/2010 18:00, Colin Campbell a ?crit : > The problem is that the Modules containing the external calls are large > and rambling. They export into our namespace lots we dont need. Ok... But it is what we have at the moment. And we cannot rewrite all Koha at once... :D Maybe we could try and use more EXPORT_OK and then create tags for actions (circulation, etc..) and try and select the tags we want when we "USE" a module. This could be a step, but would not be enough reading the rest of your message. So ... Let's try and see more. > It is > very hard when calling those routines to know confidently what side > effects they may have. > > So we get a > checkout( borrowercard, itemcard) { > itemstuff = GetItem(itemcard) > blah ... blah... > ItemXYZ(itemstuff->itemid); > blah .. blah ... > ItemABC($var) > > etc; > and we've got GetItem ItemXYZ ItemABC and loads more Item routines > imported. And we probably duplicate external accesses across them. > > But if we have a wrapper class around item and do > checkout( borrowercard, itemcard) { > my $item = Item->new(ittemcard); > blah ... blah ... > $item->zyx(); > blah .. blah > $item->abc() mmmm... I think I get you. Would need even deeper refactoring then... Could we not get step by step ? Or maybe there is some background or easy changes I miss. > > item is lexical, if necessary it can call its destructor when it goes > out of scope. We don't have to refetch data for different calls as it > persists while the variable persists and we've not imported a pile of > package variables into our namespace. Also in our business logic we can > avoid those GetItem then a long if else checking varying things and > replace that with a method call. > > For the kind of cases you are mentioning we have simple boolean methods: > $item->renewable(); Well, still renewable would have to check reserves.... and therefore would use a reserve object in items... (And an item is not renewable per se... It is an issue which can or cannot (impossible) or maynot (you need confirmation) be renewed depending on circumstances. But I got your idea) I wanted to break circular dependencies between Reserves and Circulation and Reserves or Reserves and Items (see the picture brought along). Maybe it is only with object definition and paradygm that we could solve this out. But what occurs to me was that it might have been quite easy to split true atomic object methods (Add, Edit, delete, search) and the definition of ability to do a function (would it be Decision Table driven) that might take into account the whole environment of an object... For instance : Say I want to Delete a Biblio. Is it linked to a subscription, to an order, to an issue ? Then donot delete that... Or delete all the related objects... Or ask confirmation... I think it is good that it is a method. But it might be misplaced in C4::Biblio. Since makes use of the global environment. And therefore makes intensive usage of use C4:: ... This is why I wanted to confine those types of functions into a kind of "Controller" object... This was what I realized with the picture and code analysis... This was my reflection, and what I proposed to work on and have feedback on. I appreciate your feedback, and hope though that with Data Persistence, we will be able to get Koha up to better and widely used coding practises and standards of PERL (using Moose, and DBIx::Class or Schema, maybe KiokuDB and Modern::Perl), and really ease the QA job eventually. Since Data Persistence is one of the battles for 3.4 http://wiki.koha-community.org/wiki/RFCs_for_Koha_3.4 , let's join forces in that battle, win that one, all together... Template::Toolkit is really nicely coped by Catalyst. Hopes that helps. -- Henri-Damien LAURENT -------------- next part -------------- A non-text attachment was scrubbed... Name: master.circ.png Type: image/png Size: 76759 bytes Desc: not available URL: From fridolyn.somers at gmail.com Mon Dec 20 07:28:44 2010 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Mon, 20 Dec 2010 07:28:44 +0100 Subject: [Koha-devel] Numerically sorting a new Zebra Index In-Reply-To: References: <4D0B8663.5070600@gmail.com> Message-ID: Your welcome, The whole Zebra search syntax seems completely alien to me > It was the same for me. But with the only doc online (www.indexdata.com), I descovered a powerfull search engine. Good luke, Regards, On Sat, Dec 18, 2010 at 6:41 PM, Senthil Anand wrote: > Hello, > > I am basically sorting pure numbers from a varchar field. > > After changing the record.abs to > melm 952$z canumber,canumber:n,canumber:s,item > > and using the query > canumber,st-numeric>= > and > canumber,st-numeric<= > > with values 3 and 100 I get 11 items. > > mysql> select itemnotes from items where (itemnotes + 0) >= 3 and > (itemnotes + 0) <= 100; > ... > 11 rows in set (1.16 sec) > > The corresponding barcodes are also identical in both cases. > So it seems to work on my small test install in my netbook. > > Will check it in a larger test system with more varied canumber values > in a few days and report back then. > > The whole Zebra search syntax seems completely alien to me after being > used to SQL. > > Thanks for the tips. > > Regards, > Senthil > > > 2010/12/17 Fridolyn SOMERS : > > You are right, > > > > I missed the @att type 4. > > Then, it should also be set on query. > > > > I found another error : le and ge souldn't come with "=" : use ">=" ans > > "<=". > > > > It gives : > > > > "(canumber,st-numeric>=1000 and canumber,st-numeric<=2000) or > > sort1,canumber,st-numeric=0". > > > > PS : > > The zero in sort1(...)=0 means that this sort in the first (in case there > is > > a second sort, sort=1, etc). > > > > If it doesn't work, send us the PQF(... @att ...) query from Zebra logs. > > > > Regards, > > > > On Fri, Dec 17, 2010 at 4:48 PM, LAURENT Henri-Damien > > wrote: > >> > >> Le 17/12/2010 14:40, Fridolyn SOMERS a ?crit : > >> > Hie, > >> > > >> > Have a look at @att 7 of Zebra : > >> > > >> > > http://www.indexdata.com/zebra/doc/querymodel-zebra.html#querymodel-zebra-attr-sorting > >> > > >> > It introduces sorting into query. > >> > > >> > In ccl.properties you find ascending and descending sort : > >> > /sort1 7=1 > >> > sort2 7=2/ > >> > > >> > So your ccl query looks like : > >> > /"(canumber,ge=1000 and "canumber,le=2000) or sort1,canumber=0"/ > >> > > >> > *_PS : _* > >> > You must add the sort structure (:s) into "record.abs" : > >> > > >> > melm 952$z canumber, canumber:n, canumber:s, item > >> > > >> > Regards, > >> > >> Fridolyn, what you said is helpfull but not really fixes the problem... > >> It appears that it lies in @attr 4=109 that should be used and not @attr > >> 4=1 or @attr 4=6... > >> That is to say Senthil has to tell on what TYPE of data he is trying to > >> sort. > >> Sorting on number is not the same as sorting alphabetical things. > >> so in pqf it would be > >> @or your query @attr 1=canumber @attr 7=1 @attr 4=109 1 > >> in ccl > >> yourquery or canumber,sort1,st-numeric=1 > >> or edit the code so that it sends the correct queries. > >> Hopes that helps... > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From savitra.sirohi at osslabs.biz Mon Dec 20 18:11:23 2010 From: savitra.sirohi at osslabs.biz (savitra sirohi) Date: Mon, 20 Dec 2010 22:41:23 +0530 Subject: [Koha-devel] Analytical records: design In-Reply-To: References: Message-ID: Folks, we think we have the feature in good shape, outside of aesthetics and some fine tuning. I have updated the wiki: http://wiki.koha-community.org/wiki/Analytic_Record_support#Design_as_it_stands_now Please feel free to suggest improvements. Zeno has added UNIMARC support, we will incorporate that into a git branch and publish the software in the next few days. The bug no. for this feature is 5528. Thanks, Savitra Sirohi Nucsoft OSS Labs From frederic at tamil.fr Mon Dec 20 18:31:50 2010 From: frederic at tamil.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_Demians?=) Date: Mon, 20 Dec 2010 18:31:50 +0100 Subject: [Koha-devel] Branch: new/awaiting_qa/biblibre_admin Message-ID: <4D0F9306.9090904@tamil.fr> I've tested this branch. It works. It improves admin module WUI. It add a jquery table sorter to various admin pages, framework editor, branches, item types, cities, authorized values, etc. There is just a small merge issue on link to sysprefs editor. This branch can be pulled here: The following changes since commit 8fe46f3dc1a3250b04a0da2f6dd9335710b4e702: Merge remote branch 'kc/new/bug_5143' into kcmaster (2010-12-20 13:24:40 +1300) are available in the git repository at: git://git.tamil.fr/git/koha qa_biblibre_admin Fr?d?ric Demians (1): Merge branch 'master' into qa_biblibre_admin Henri-Damien LAURENT (3): Followup admin/categorie.pl MT4009: followup removing systempreferences branch transfer limits Matthias Meusburger (2): MT 2446 : Cancel authority edition for a field goes back to this field MT 2310 : New subfield for fields < 10 is now in a tab Paul POULAIN (1): mybranch not exported (merge pb) Paul Poulain (1): Removing usage of preferences.pl St?phane Delaune (11): (MT #1577) complete langages checkbox for unique id (MT #1654) Adding jquery.tablesorter and jquery.tablesorter.pager support for authorised_values.pl (MT #1654) followup : Adding jquery.tablesorter and jquery.tablesorter.pager support for branches.pl (MT #1654) followup : Adding jquery.tablesorter and jquery.tablesorter.pager support for itemtypes.pl (MT #1654) followup : corrects tablesorting for authorised_values and itemtypes (MT #1654) followup : Adding jquery.tablesorter and jquery.tablesorter.pager support for categorie.pl (MT #1654) followup : Adding jquery.tablesorter and jquery.tablesorter.pager support for cities.pl (MT #1654) followup : Adding jquery.tablesorter and jquery.tablesorter.pager support for marctagstructure.pl (MT #1654) followup : Adding jquery.tablesorter and jquery.tablesorter.pager support for auth_tag_structure.pl (MT #1654) followup : corrects tablesorting for authorised_values.pl (MT #1654) followup : Adding jquery.tablesorter and jquery.tablesorter.pager support for branch_transfer_limits.pl C4/Branch.pm | 1 + admin/auth_tag_structure.pl | 11 +- admin/branch_transfer_limits.pl | 10 +- admin/categorie.pl | 2 +- admin/marctagstructure.pl | 6 +- .../prog/en/includes/prefs-admin-search.inc | 2 +- .../lib/jquery/plugins/jquery.tablesorter.pager.js | 184 ++++++++++++++++++++ .../prog/en/modules/admin/admin-home.tmpl | 2 +- .../en/modules/admin/auth_subfields_structure.tmpl | 3 +- .../prog/en/modules/admin/auth_tag_structure.tmpl | 38 +++- .../prog/en/modules/admin/authorised_values.tmpl | 50 ++++-- .../en/modules/admin/branch_transfer_limits.tmpl | 27 +++ .../prog/en/modules/admin/branches.tmpl | 22 ++- .../prog/en/modules/admin/categorie.tmpl | 33 +++- .../prog/en/modules/admin/cities.tmpl | 33 ++++- .../prog/en/modules/admin/itemtypes.tmpl | 37 ++++- .../en/modules/admin/marc_subfields_structure.tmpl | 2 - .../prog/en/modules/admin/marctagstructure.tmpl | 39 +++- .../prog/en/modules/admin/systempreferences.tmpl | 4 +- koha-tmpl/intranet-tmpl/prog/img/first.png | Bin 0 -> 720 bytes koha-tmpl/intranet-tmpl/prog/img/last.png | Bin 0 -> 737 bytes koha-tmpl/intranet-tmpl/prog/img/next.png | Bin 0 -> 736 bytes koha-tmpl/intranet-tmpl/prog/img/prev.png | Bin 0 -> 745 bytes 23 files changed, 442 insertions(+), 64 deletions(-) create mode 100644 koha-tmpl/intranet-tmpl/prog/en/lib/jquery/plugins/jquery.tablesorter.pager.js create mode 100644 koha-tmpl/intranet-tmpl/prog/img/first.png create mode 100644 koha-tmpl/intranet-tmpl/prog/img/last.png create mode 100644 koha-tmpl/intranet-tmpl/prog/img/next.png create mode 100644 koha-tmpl/intranet-tmpl/prog/img/prev.png From oleonard at myacpl.org Mon Dec 20 21:47:49 2010 From: oleonard at myacpl.org (Owen Leonard) Date: Mon, 20 Dec 2010 15:47:49 -0500 Subject: [Koha-devel] Branch: new/awaiting_qa/biblibre_admin In-Reply-To: <4D0F9306.9090904@tamil.fr> References: <4D0F9306.9090904@tamil.fr> Message-ID: I'm curious about this: > Paul Poulain (1): > ? ? ?Removing usage of preferences.pl The relevant change: -
  • System preferences
    • +
  • System preferences
    • What is the purpose of doing so? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From chris at bigballofwax.co.nz Tue Dec 21 02:07:55 2010 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Tue, 21 Dec 2010 14:07:55 +1300 Subject: [Koha-devel] Branch: new/awaiting_qa/biblibre_admin In-Reply-To: References: <4D0F9306.9090904@tamil.fr> Message-ID: On 21 December 2010 09:47, Owen Leonard wrote: > I'm curious about this: > >> Paul Poulain (1): >> ? ? ?Removing usage of preferences.pl > > The relevant change: > > - ? ? ? ? ? ?
  • System > preferences
    • > + ? ? ? ? ? ?
  • href="/cgi-bin/koha/admin/systempreferences.pl">System > preferences
    • > > What is the purpose of doing so? > Nice catch owen, going back to the old systempreferences.pl breaks the translation of system preferences. And the nice interface. There would have to be a pretty compelling reason for ditching that, and it would need to include away to still have translated tempaltes. Chris From chris at bigballofwax.co.nz Tue Dec 21 02:08:28 2010 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Tue, 21 Dec 2010 14:08:28 +1300 Subject: [Koha-devel] Branch: new/awaiting_qa/biblibre_admin In-Reply-To: References: <4D0F9306.9090904@tamil.fr> Message-ID: On 21 December 2010 14:07, Chris Cormack wrote: > On 21 December 2010 09:47, Owen Leonard wrote: >> I'm curious about this: >> >>> Paul Poulain (1): >>> ? ? ?Removing usage of preferences.pl >> >> The relevant change: >> >> - ? ? ? ? ? ?
  • System >> preferences
    • >> + ? ? ? ? ? ?
  • > href="/cgi-bin/koha/admin/systempreferences.pl">System >> preferences
    • >> >> What is the purpose of doing so? >> > Nice catch owen, going back to the old systempreferences.pl breaks the > translation of system preferences. And the nice interface. > There would have to be a pretty compelling reason for ditching that, > and it would need to include away to still have translated tempaltes. > And by tempaltes (sic) I actually meant system preferences :) Chris From f.demians at tamil.fr Tue Dec 21 08:03:07 2010 From: f.demians at tamil.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_DEMIANS?=) Date: Tue, 21 Dec 2010 08:03:07 +0100 Subject: [Koha-devel] Branch: new/awaiting_qa/biblibre_admin In-Reply-To: References: <4D0F9306.9090904@tamil.fr> Message-ID: <4D10512B.50803@tamil.fr> > > The relevant change: > > -
  • System > preferences
    • > +
  • href="/cgi-bin/koha/admin/systempreferences.pl">System > preferences
    • > > What is the purpose of doing so? That's what I was talking about 'syspref editor merge issue'. When merging this branch to HEAD you have to revert to using the new syspref editor. That's done on my branch. -- Fr?d?ric DEMIANS http://www.tamil.fr/u/fdemians.html From frederic at tamil.fr Tue Dec 21 08:03:17 2010 From: frederic at tamil.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_Demians?=) Date: Tue, 21 Dec 2010 08:03:17 +0100 Subject: [Koha-devel] Branch: new/awaiting_qa/biblibre_admin In-Reply-To: References: <4D0F9306.9090904@tamil.fr> Message-ID: <4D105135.9000207@tamil.fr> > > The relevant change: > > -
  • System > preferences
    • > +
  • href="/cgi-bin/koha/admin/systempreferences.pl">System > preferences
    • > > What is the purpose of doing so? That's what I was talking about 'syspref editor merge issue'. When merging this branch to HEAD you have to revert to using the new syspref editor. That's done on my branch. -- Fr?d?ric DEMIANS http://www.tamil.fr/u/fdemians.html From chrisc at catalyst.net.nz Tue Dec 21 08:19:48 2010 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Tue, 21 Dec 2010 20:19:48 +1300 Subject: [Koha-devel] Branch: new/awaiting_qa/biblibre_admin In-Reply-To: <4D10512B.50803@tamil.fr> References: <4D0F9306.9090904@tamil.fr> <4D10512B.50803@tamil.fr> Message-ID: <20101221071948.GR27877@rorohiko> * Fr?d?ric DEMIANS (f.demians at tamil.fr) wrote: > > > > >The relevant change: > > > >-
  • System > >preferences
    • > >+
  • >href="/cgi-bin/koha/admin/systempreferences.pl">System > >preferences
    • > > > >What is the purpose of doing so? > > That's what I was talking about 'syspref editor merge issue'. When > merging this branch to HEAD you have to revert to using the new > syspref editor. That's done on my branch. Ah ha, now it becomes more clear. Ill do some testing now, and merge it in if it seems ok. Chris > > -- > Fr?d?ric DEMIANS > http://www.tamil.fr/u/fdemians.html > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From henridamien.laurent at gmail.com Tue Dec 21 09:05:56 2010 From: henridamien.laurent at gmail.com (LAURENT Henri-Damien) Date: Tue, 21 Dec 2010 09:05:56 +0100 Subject: [Koha-devel] Branch: new/awaiting_qa/biblibre_admin In-Reply-To: References: <4D0F9306.9090904@tamil.fr> Message-ID: <4D105FE4.90406@gmail.com> Le 21/12/2010 02:08, Chris Cormack a ?crit : > On 21 December 2010 14:07, Chris Cormack wrote: >> On 21 December 2010 09:47, Owen Leonard wrote: >>> I'm curious about this: >>> >>>> Paul Poulain (1): >>>> Removing usage of preferences.pl >>> >>> The relevant change: >>> >>> -
  • System >>> preferences
    • >>> +
  • >> href="/cgi-bin/koha/admin/systempreferences.pl">System >>> preferences
    • >>> >>> What is the purpose of doing so? >>> >> Nice catch owen, going back to the old systempreferences.pl breaks the >> translation of system preferences. And the nice interface. >> There would have to be a pretty compelling reason for ditching that, >> and it would need to include away to still have translated tempaltes. >> > And by tempaltes (sic) I actually meant system preferences :) Hi By the time we had to deploy things we had many problems with that new systempreferences, we told on list months ago. This is why we chose to stick to the old system. It would have disturbing for libraries in production to change system preference very short after going live. We know it has been fixed since, but the fact is that This edit should not have been sent in though. And thanks to Frederic to have caught that. -- Henri-Damien LAURENT From chrisc at catalyst.net.nz Tue Dec 21 09:21:45 2010 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Tue, 21 Dec 2010 21:21:45 +1300 Subject: [Koha-devel] Branch: new/awaiting_qa/biblibre_admin In-Reply-To: <4D105FE4.90406@gmail.com> References: <4D0F9306.9090904@tamil.fr> <4D105FE4.90406@gmail.com> Message-ID: <20101221082145.GS27877@rorohiko> * LAURENT Henri-Damien (henridamien.laurent at gmail.com) wrote: > Hi > > By the time we had to deploy things we had many problems with that new > systempreferences, we told on list months ago. > This is why we chose to stick to the old system. It would have > disturbing for libraries in production to change system preference very > short after going live. > > We know it has been fixed since, but the fact is that > This edit should not have been sent in though. And thanks to Frederic to > have caught that. I have pulled the branch from Frederic's repository and rebased them onto master, fixed the remaining link to systempreferences.pl, created a bug (so I dont break my own rules) and have pushed them up as new/enh/bug_5530 Please do some quick testing and let me know if its safe to merge. Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From colin.campbell at ptfs-europe.com Tue Dec 21 11:35:51 2010 From: colin.campbell at ptfs-europe.com (Colin Campbell) Date: Tue, 21 Dec 2010 10:35:51 +0000 Subject: [Koha-devel] Data Persistence and Plack In-Reply-To: <4D0BA751.3040602@biblibre.com> References: <4D0B4ABB.7060005@biblibre.com> <4D0B7423.2030403@ptfs-europe.com> <4D0B828A.6010403@gmail.com> <4D0B9726.6070401@ptfs-europe.com> <4D0BA751.3040602@biblibre.com> Message-ID: <4D108307.1060202@ptfs-europe.com> On 17/12/10 18:09, LAURENT Henri-Damien wrote: > Le 17/12/2010 18:00, Colin Campbell a ?crit : > > Maybe we could try and use more EXPORT_OK and then create tags for > actions (circulation, etc..) and try and select the tags we want when we > "USE" a module. Yes if you are creating a new interface in C4 don't please stick everything in @EXPORT. In fact if you create a new C4 module take a couple of minutes to read perldoc Exporter rather than just copying the style of existing modules. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campbell at ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com From fridolyn.somers at gmail.com Tue Dec 21 16:04:58 2010 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Tue, 21 Dec 2010 16:04:58 +0100 Subject: [Koha-devel] JSCalendar translation - bug 2307 Message-ID: Hie Koha users, I'm opening a mail on the translation of JavaScript Calendar used in both OPAC and Intranet. (JSCalendar, unknown version but < 1.0). The bug 2307 refers to this : http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2307 I think it's can be a great improvement for users. (We French use a wery different date format). How can we propose translation ? 1. In PO files like proposed in bug patch 2. With the language files found in JSCalendar project and put them all in lib/calendar folder. In my opinion, PO files is not necessary. Because : - language files (calendar-[language].js) are very small (4 Ko). - they manage not only translation but also country-specific preferences (such as first day of week). So using PO files will miss the comments that explains those preferences. In second case : In Templates, use : In this case, we just have to rename lang files : calendar-fr.js -> calendar-fr-FR.js, calendar-fr-CA.js ... You'll find a test patch I used for French lang. *PS :* I add to correct a bug on "first day of week" (Calendar._FD) preference to have it work. Regards, Happy Christmas. -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: -------------- section suivante -------------- Une pi?ce jointe autre que texte a ?t? nettoy?e... Nom: calendar_fr.patch Type: text/x-patch Taille: 21716 octets Desc: non disponible URL: From chris at bigballofwax.co.nz Tue Dec 21 23:51:29 2010 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Wed, 22 Dec 2010 11:51:29 +1300 Subject: [Koha-devel] Branch: new/awaiting_qa/biblibre_admin In-Reply-To: <20101221082145.GS27877@rorohiko> References: <4D0F9306.9090904@tamil.fr> <4D105FE4.90406@gmail.com> <20101221082145.GS27877@rorohiko> Message-ID: 2010/12/21 Chris Cormack : > * LAURENT Henri-Damien (henridamien.laurent at gmail.com) wrote: >> Hi >> >> By the time we had to deploy things we had many problems with that new >> systempreferences, we told on list months ago. >> This is why we chose to stick to the old system. It would have >> disturbing for libraries in production to change system preference very >> short after going live. >> >> We know it has been fixed since, but the fact is that >> This edit should not have been sent in though. And thanks to Frederic to >> have caught that. > > I have pulled the branch from Frederic's repository and rebased them > onto master, fixed the remaining link to systempreferences.pl, > created a bug (so I dont break my own rules) and have > pushed them up as new/enh/bug_5530 > > Please do some quick testing and let me know if its safe to merge. > Right, this branch is now merged to master, please test and marked bug 5530 resolved if its all good Chris From cnighswonger at foundations.edu Wed Dec 22 01:34:52 2010 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Tue, 21 Dec 2010 19:34:52 -0500 Subject: [Koha-devel] Koha 3.2.2 is now available Message-ID: It is with pleasure that I announce the release of Koha 3.2.2. The package can be retrieved from: http://download.koha-community.org/koha-3.02.02.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.02.02.tar.gz.MD5 http://download.koha-community.org/koha-3.02.02.tar.gz.MD5.asc http://download.koha-community.org/koha-3.02.02.tar.gz.sig Release notes for 3.2.2 are below. Come and get it! RELEASE NOTES FOR KOHA 3.2.2 - 22 December 2010 ======================================================================== 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.2.2 can be downloaded from: http://download.koha-community.org/koha-3.02.02.tar.gz Installation instructions can be found at: http://wiki.koha-community.org/wiki/Installation_Documentation Koha 3.2.2 is a bugfix/maintenance release. Highlights of 3.2.2 ====================== Some of the higher profile bugs addressed in this release are: Bug 3285 Location on "Add Subscription" should be supplied in a drop-down list (Partial fix) Bug 3575 Conflicts of template variables and the same "use" statement appearing twice in the same script Bug 4211 Acquisitions actions on suggestions now generate email Bug 4218 Staff client detail page now shows item hold status Bug 4252 Edit authorities permission now checked on 'More' list Bug 4832 Re-editing a suggestion no longer changes the item type Bug 5022 Supplements now show in serials Bug 5041 Non repeatable fields are now deletable Bug 5127 Sample suggestions notices are installed by default Bug 5154 "Patrons checking out the most" report now works as expected Bug 5484 List member search internal server errors if a borrower has an invalid category now handled gracefully Other notable fixes in this release include: * A number of template bugs * Various fixes to Koha's interface This release also contains a variety of minor enhancements improving Koha's interface and underlying scripts. Maintenance activities performed in this release include: * Language updates Bugs fixed in 3.2.2 ====================== 2170 Adding 'edititems' user-permission 2808 Hold queue not alphabetizing 2965 Allow the user to specify due dates in the past 2981 Misleading interface for selecting patron from circulation search results 3285 Location on Add Subscription should be pull down 3575 conflits of template var and 2 times the same "use" 3789 Set off Shelving Location in staff and OPAC title display 4173 Statuses not appearing in the OPAC 4211 Acquisitions actions on suggestions don't generate email 4218 Staff client detail page does not show item hold status 4252 edit authorities permission not checked on 'More' list 4449 Cannot place holds on unchecked-out missing items if AllowShelfHolds turned off 4451 Batch item tool cannot process barcode file with Windows line endings 4500 Cant edit budget because of currency formatting 4832 Re-editing a suggestion changes the item type 4851 Batch delete shouldn't show delete button if no items were found 4908 OPAC patron details page doesn't show patron's home library 4935 Batch Modify tool cannot "unset" options such as Lost status 4937 XHTML error in pagination links of saved reports results. 4977 Acq: link to Z39.50 search missing from no results page 4981 Tweak style of item listing on MARC display 4983 Add edit record / edit item links to search results 5000 Uncertain prices misses option to choose display language 5022 supplements not showing in serials 5029 Update patron deletion error page 5030 Improve handling of duplicate patrons 5033 Makefile.PL doesn't know about the xml_sax.pl fix 5041 Non repeatable fields are not deletable 5048 Error in bottom menu/submenu for select language in intranet 5051 Renewal due date doesn't always show on patron Checkout tab 5084 GetBudgetHierarchy doesn't respect the 'active' switch on budgets 5125 Cursor default location on circulation-home.pl 5127 No sample suggestions notices are installed by default 5143 Subtitles not showing on view_holdsqueue.pl 5150 Issuing should read Circulation 5154 the most Checkouts reports problem 5228 Sometimes the zebra server directories break and rebuild_zebra fails 5232 Shelfname does not display on high numbered lists 5255 document type should say item type 5269 link to patron edit form when editing turned off 5281 "Check in" then "Renew" checkboxes checked in the same time 5313 koha-create script doesn't allow libraries with a '-' in their name 5397 number of renewals not displayed consistently 5402 "add to cart" shown on checkbox hover even if cart disabled 5405 catalogue/suggest.pl is no longer used 5416 Template syntax error in moredetails.tmpl 5443 Inaccurate highlighting of fields in request for update of record email 5446 Item creation in Acquisition module doesn't control mandatory fields 5448 Boolean.pm's interface could be cleaned up 5450 Name clash between ILSDI::Utility and Reserves 5455 Fix uninitialized-warnings on authorities.pl 5457 gather_print_notices.pl requires explicit stylesheet 5460 AutoEmailPrimaryAddress set to invalid value in sysprefs.sql 5467 LDR pos 6 o = Kit should not show as visual material 5475 Wrong messages date formating on Check Out page 5479 Update packaging scripts to account for the new version number 5484 Routing list member search internal server errors if a borrower has an invalid category Commits in 3.2.2 without a referenced bug report: * Fix some compile time errors reported in test suite * Fixing formatting and links in the history document * Adding 3.2.1 release to the history * Add BSZ to Koha's About page * Ergonomy improvement in smart rule management * Updating test for systprefs to give more useful output * Adding another developer to the Koha history, 120 now! * Update Debian changelog for 3.2.1 release * Variable redeclared in same scope * Fix for intranet-tmpl had one /TMPL_IF to many * Revert "Ergonomy improvement in smart rule management" * Add .packages file for Ubuntu 10.10 System requirements ====================== Changes since 3.0: * The minimum version of Perl required is now 5.8.8. * There are a number of new Perl module dependencies. Run ./koha_perl_deps.pl -u -m to get a list of any new modules to install during upgrade. Upgrades ====================== The structure of the acquisitions tables have changed significantly from 3.0.x. In particular, the budget hierarchy is quite different. During an upgrade, a new database table is created called fundmapping that contains a record of how budgets were mapped. It is strongly recommended that users of Koha 3.0.x acquisitions carefully review the results of the upgrade before resuming ordering in Koha 3.2.x. 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, several translations of the Koha manual are available: English: http://koha-community.org/documentation/3-2-manual/ Spanish: http://koha-community.org/documentation/3-2-manual-es/ French: http://koha-community.org/documentation/3-2-manual-fr/ 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 * Danish * English (New Zealand) * English (USA) * French (France) * French (Canada) * German * Greek * Hindi * Italian * Norwegian * Portuguese * Spanish * Turkish Translations updated in 3.2.2: * English (United Kingdom) * French * French (Canada) * German * Italian * Japanese * Portuguese * Portuguese (Brazil) * Russian * Spanish * Tetun * Ukrainian Translation related commits new to 3.2.2: * 2307 Calendar widget cannot be translated * 5142 Untranslatable strings in tag review template * 5208 Language chooser missing on Batch item deletion/modification * 5444 Installaling translation fails for 'standard' installed Koha * 5506 Translation Process Simplification Partial translations are available for various other languages. The Koha team welcomes additional translations; please see http://www.kohadocs.org/usersguide/apb.html 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.2 is Release Manager: Galen Charlton Documentation Manager: Nicole Engard Translation Manager: Chris Cormack Release Maintainer (3.0.x): Henri-Damien Laurent Release Maintainer (3.2.x): Chris Nighswonger Credits ====================== We thank the following individuals who contributed patches to Koha 3.2.2: Nahuel Angelinetti Colin Campbell Galen Charlton Garry Collum Chris Cormack Fr?d?ric Demians Nicole Engard Katrin Fischer Srdjan Jankovic Owen Leonard Chris Nighswonger Liz Rea Marcel de Rooy Jean-Andr? Santoni Robin Sheat Jane Wagner Ian Walls Jesse Weaver We regret any omissions. If a contributor has been inadvertantly missed, please send patch against these release notes to koha-patches at lists.koha-community.org. The 3.2.x Release Maintainer especially thanks the 3.4 Release Team and all who participated in QA for their diligent labors in testing and pushing well over 180 patches since the 3.2.0 relese. Their continued work very much makes possible the release of 3.2.2 on its announced schedule. 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.2.x (i.e., this version of Koha and future bugfix releases) is 3.2.x. The next major feature release of Koha will be Koha 3.4.0. Bugs and feature requests ====================== Bug reports and feature requests can be filed at the Koha bug tracker at http://bugs.koha-community.org/ Naku te rourou, nau te rourou, ka ora ai te iwi. From robin at kallisti.net.nz Sun Dec 5 10:52:27 2010 From: robin at kallisti.net.nz (Robin Sheat) Date: Sun, 05 Dec 2010 09:52:27 -0000 Subject: [Koha-devel] Failing test cases Message-ID: <1291541343.3364.5.camel@nyx> I've been attempting to build a new set of packages for 3.2.1, however part of building the packages is running tests. If you attempt to run "make -j1 test" on a system that doesn't have a koha database with the default account and password configured, they will fail. This seems to be because the modules that they're testing include C4::Auth or C4::Context, which tries to talk to the DB. What's the recommended solution to this? My thinking is that anything that requires a database connection should be moved to its own directory so that it won't be run by default (or, better, it should be designed in such a way to not require a database. But that's possibly significantly harder.) I can just move the problematic tests[0] out of the way for the sake of the packages, but that's definitely not the right solution. Robin. [0] 00-load, Auth_with_cas, External_BakerTaylor, Reports_Guided, Service, Tags, UploadedFile, and VirtualShelves. From robin at kallisti.net.nz Sun Dec 5 12:49:58 2010 From: robin at kallisti.net.nz (Robin Sheat) Date: Sun, 05 Dec 2010 11:49:58 -0000 Subject: [Koha-devel] Failing test cases Message-ID: <1291541343.3364.5.camel@nyx> I've been attempting to build a new set of packages for 3.2.1, however part of building the packages is running tests. If you attempt to run "make -j1 test" on a system that doesn't have a koha database with the default account and password configured, they will fail. This seems to be because the modules that they're testing include C4::Auth or C4::Context, which tries to talk to the DB. What's the recommended solution to this? My thinking is that anything that requires a database connection should be moved to its own directory so that it won't be run by default (or, better, it should be designed in such a way to not require a database. But that's possibly significantly harder.) I can just move the problematic tests[0] out of the way for the sake of the packages, but that's definitely not the right solution. Robin. [0] 00-load, Auth_with_cas, External_BakerTaylor, Reports_Guided, Service, Tags, UploadedFile, and VirtualShelves. From ybeddyj at gmail.com Wed Dec 22 03:25:29 2010 From: ybeddyj at gmail.com (Edward Allen) Date: Tue, 21 Dec 2010 21:25:29 -0500 Subject: [Koha-devel] LDAP Integration Message-ID: I currently have a ldap deployment that has object listed in an hierarchical manner. meaning i have multiple sub-level OU with user objects in those containers. eg "cn=John Tom,ou=purchasing,ou=accounting,ou=users,ou=people,dc=example,dc=org" eg 2 "cn=Mary Joe,ou=Wholesale,ou=Sales,ou=users,ou=people,dc=example,dc=org" in the example given in "Auth_with_ldap.pm" it would seem that koha's integration with ldap is expecting a flat structure. could you indicate how best to approach this type of integration? -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin at catalyst.net.nz Wed Dec 22 09:58:50 2010 From: robin at catalyst.net.nz (Robin Sheat) Date: Wed, 22 Dec 2010 21:58:50 +1300 Subject: [Koha-devel] Failing test cases In-Reply-To: <1291541343.3364.5.camel@nyx> References: <1291541343.3364.5.camel@nyx> Message-ID: <1293008330.1794.0.camel@nyx> Robin Sheat schreef op zo 05-12-2010 om 22:29 [+1300]: > I've been attempting to build a new set of packages for 3.2.1, however Ignore this, it apparently got stuck in an outbox until I put my laptop on the internet again. Robin. From reedwade at gmail.com Wed Dec 22 21:39:00 2010 From: reedwade at gmail.com (Reed Wade) Date: Thu, 23 Dec 2010 09:39:00 +1300 Subject: [Koha-devel] LDAP Integration In-Reply-To: References: Message-ID: in place of a knowledgeable response: have you tried omitting the sublevel OUs in the koha ldap config (something I'm not too familiar with myself so this might make less sense than I'm expecting it to)? -reed 2010/12/22 Edward Allen : > I currently have a ldap deployment that has object listed in an hierarchical > manner. meaning i have multiple sub-level OU with user objects in those > containers. eg > "cn=John > Tom,ou=purchasing,ou=accounting,ou=users,ou=people,dc=example,dc=org" eg 2 > "cn=Mary Joe,ou=Wholesale,ou=Sales,ou=users,ou=people,dc=example,dc=org" > in the example given in "Auth_with_ldap.pm" it would seem that koha's > integration with ldap is expecting a flat structure. could you indicate how > best to approach this type of integration? > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > From psm_vu at india.com Thu Dec 23 13:03:30 2010 From: psm_vu at india.com (Partha Mukhopadhyay) Date: Thu, 23 Dec 2010 12:03:30 +0000 (UTC) Subject: [Koha-devel] OPAC Enhancement in Koha 3.4 In-Reply-To: References: , Message-ID: <20101223120401.057C340000356@smtp02.zmail.com> An HTML attachment was scrubbed... URL: From henridamien.laurent at biblibre.com Thu Dec 23 14:35:07 2010 From: henridamien.laurent at biblibre.com (LAURENT Henri-Damien) Date: Thu, 23 Dec 2010 14:35:07 +0100 Subject: [Koha-devel] Solr Search use cases Message-ID: <4D13500B.2040100@biblibre.com> Hi, we proposed in our solr meeting to gather the use cases that you would like to add and proove with the solr search. We wondered why nobody had added any yet.... And we realized that the document, though public, would not be editable. This has been fixed now. So all the persons who were longing to add usecases are now able to do so. The link is the same as previously publicised. https://spreadsheets.google.com/pub?key=0AuZF5Y_c4pIxdEVzTjUtUGFoQnFpSkpfbTU5Ykc3b2c&hl=en&output=html Please, enter whatever query you have success or problem with on zebra. We will try and do it with solr and then build the user interface for it. Hope that helps. -- Henri-Damien LAURENT From laurenthdl at alinto.com Thu Dec 23 14:41:29 2010 From: laurenthdl at alinto.com (LAURENT Henri-Damien) Date: Thu, 23 Dec 2010 14:41:29 +0100 Subject: [Koha-devel] Solr Search use cases In-Reply-To: <4D13500B.2040100@biblibre.com> References: <4D13500B.2040100@biblibre.com> Message-ID: <4D135189.90605@alinto.com> Le 23/12/2010 14:35, LAURENT Henri-Damien a ?crit : > Hi, > we proposed in our solr meeting to gather the use cases that you would > like to add and proove with the solr search. > We wondered why nobody had added any yet.... > And we realized that the document, though public, would not be editable. > This has been fixed now. > So all the persons who were longing to add usecases are now able to do > so. The link is the same as previously publicised. > https://spreadsheets.google.com/pub?key=0AuZF5Y_c4pIxdEVzTjUtUGFoQnFpSkpfbTU5Ykc3b2c&hl=en&output=html > > Please, enter whatever query you have success or problem with on zebra. > We will try and do it with solr and then build the user interface for it. > Hope that helps. Still failing to edit. This latest one should do : http://tinyurl.com/3ydnuhw If anyone wants to test and tell me if it is ok now. -- Henri-Damien LAURENT From henridamien.laurent at biblibre.com Thu Dec 23 15:52:12 2010 From: henridamien.laurent at biblibre.com (LAURENT Henri-Damien) Date: Thu, 23 Dec 2010 15:52:12 +0100 Subject: [Koha-devel] Template::Toolkit Catalyst Work Message-ID: <4D13621C.7000608@biblibre.com> Hi I have tested Template_test branch and it looks great (thanks catalyst) Yet, I have some issues with diacritics. Is it because of Koha, DBI, perl utf8 ? I donot know http://imagebin.org/129237 There is also a problem with hotkeys which prevents the load of the javascript. Hope that helps. -- Henri-Damien LAURENT From chris at bigballofwax.co.nz Thu Dec 23 20:28:25 2010 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Fri, 24 Dec 2010 08:28:25 +1300 Subject: [Koha-devel] Template::Toolkit Catalyst Work In-Reply-To: <4D13621C.7000608@biblibre.com> References: <4D13621C.7000608@biblibre.com> Message-ID: On 24 December 2010 03:52, LAURENT Henri-Damien wrote: > Hi > I have tested Template_test branch and it looks great (thanks catalyst) > Yet, I have some issues with diacritics. Is it because of Koha, DBI, > perl utf8 ? I donot know > http://imagebin.org/129237 Ah yes, we have fixed that now, have pushed up the fix, we still have problems with the xslt but thats the last of utf8 issues. > There is also a problem with hotkeys which prevents the load of the > javascript. Hmm that might also be worth rechecking, http://git.koha-community.org/gitweb/?p=wip/koha-catalyst.git;a=shortlog;h=refs/heads/template_test > Hope that helps. It sure does, thanks for testing. Chris > -- > Henri-Damien LAURENT > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > From cnighswonger at foundations.edu Fri Dec 24 05:48:16 2010 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 23 Dec 2010 23:48:16 -0500 Subject: [Koha-devel] 3.2.x Status and Schedule Update Message-ID: Hi all, Thanks again for all of the hard work toward making the 3.2.2 release happen on schedule. The 3.2.x branch is currently "thawed" and again receiving all applicable commits, so keep them coming! Here is what the 3.2.3 release schedule looks like: January 14, 2011 - 3.2.x enters string freeze in preparation for 3.2.3 release January 20, 2011 - Translation updates pulled January 22, 2011 - 3.2.3 released; 3.2.x thawed. Please note that I will be out of reach of all electronic communication for 7 days beginning on Dec. 27, 2010, for a bit of a holiday. Kind Regards, Chris From henridamien.laurent at biblibre.com Fri Dec 24 09:52:20 2010 From: henridamien.laurent at biblibre.com (LAURENT Henri-Damien) Date: Fri, 24 Dec 2010 09:52:20 +0100 Subject: [Koha-devel] Template::Toolkit Catalyst Work In-Reply-To: References: <4D13621C.7000608@biblibre.com> Message-ID: <4D145F44.5060205@biblibre.com> Le 23/12/2010 20:28, Chris Cormack a ?crit : > On 24 December 2010 03:52, LAURENT Henri-Damien > wrote: >> Hi >> I have tested Template_test branch and it looks great (thanks catalyst) >> Yet, I have some issues with diacritics. Is it because of Koha, DBI, >> perl utf8 ? I donot know >> http://imagebin.org/129237 > > Ah yes, we have fixed that now, have pushed up the fix, we still have > problems with the xslt but thats the last of utf8 issues. > >> There is also a problem with hotkeys which prevents the load of the >> javascript. > > Hmm that might also be worth rechecking, > http://git.koha-community.org/gitweb/?p=wip/koha-catalyst.git;a=shortlog;h=refs/heads/template_test > >> Hope that helps. > > It sure does, thanks for testing. > > Chris > mmmm... Sorry... But links are broken in that branch. moremember is not taking borrowernumber... subscription-detail.pl not taking the subscriptionid... .... It is better at utf8 though ;) even though everything is not fixed. -- Henri-Damien LAURENT From dschust1 at gmail.com Sun Dec 26 19:03:45 2010 From: dschust1 at gmail.com (David Schuster) Date: Sun, 26 Dec 2010 12:03:45 -0600 Subject: [Koha-devel] OPAC Enhancement in Koha 3.4 In-Reply-To: <20101223120401.057C340000356@smtp02.zmail.com> References: <20101223120401.057C340000356@smtp02.zmail.com> Message-ID: These wold be great developments - but then some of us have issues with patron privacy... We have parents and teachers asking for a "list of what student X has checked out" we like to say this is not doable in Koha. So if there was a way to hide the data but use it analytically that would be fantastic. David Schuster 2010/12/23 Partha Mukhopadhyay > > Dear all, > > I would like to put forward a wish list (thinking over it from version > 2.2.8)..... > > > > Preamble > > This wish list is based on the assumption that Koha 3.x stores circulation > history of borrowers. If so, then comes the question how can this dataset be > utilized in developing new breed of services. And how these services can > affect the mirror of any type or size library - the OPAC. > > > > Wish list I > > Is it possible to detrmine degree of association of authors by utlizing > circulation data? For example, in a set of 10 borrowers who borrowed book of > author x (say 10/10) also borrowed book by author y (say 8/10) or author z > (say 6/10) and so on, the degree of association is higher among author x and > author y and comparatively lower among author x and author z. It is quite > easy to determine statistical association of a given author with other > authors in this way and thereafter generating a map of authors where > searched author will be in the centre and highly associated authors in 1st > circle, moderately associated authors in 2nd circle and so on. Confused? Try > this....... > > http://www.literature-map.com/amitav+ghosh.html > > > > Wish list II > > If it is possible to incorporate this feature (author mapping) in Koha > OPAC, then on the basis of same circulation dataset we can generate a > reading advisory service to new users in a given field of study by giving a > service called what_should_they_read_next. Confused again? Try this...... > > Goto http://whatshouldireadnext.com/ and enter "digital library" Witten > > > > Wish list III > > If it is possible to incorporate the above two feature (author mapping and > resource mapping) in Koha OPAC, then on the basis of same circulation > dataset we can generate service (human mapping this time?) to link borrowers > who are interested in a given field of study (assuming people reading same > titles and same authors have coomon area of study/research). Hopefully not > confused again? Anyway try this...... > > Goto http://www.connectviabooks.com/ and enter "digital library" Witten > again. > > > > Hoping my favourite Koha developers will not let us down in this month of > gift and wishes. > > > > Merry X-mass..... > > > > Parthasarathi Mukhopadhyay > > > ----------------------------------------------------------------------- > Dr. Parthasarathi Mukhopadhyay > Lecturer (Sr.), Department of Library and Information Science, University > of Burdwan, > Burdwan - 713 104 (WB), India > ----------------------------------------------------------------------- > > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- David Schuster Plano ISD Library Technology Coordinator -------------- next part -------------- An HTML attachment was scrubbed... URL: From psm_vu at india.com Mon Dec 27 07:56:47 2010 From: psm_vu at india.com (Partha Mukhopadhyay) Date: Mon, 27 Dec 2010 06:56:47 +0000 (UTC) Subject: [Koha-devel] OPAC Enhancement in Koha 3.4 In-Reply-To: References: <20101223120401.057C340000356@smtp02.zmail.com>, Message-ID: <20101227065625.08A52250@smtp01.zmail.com> An HTML attachment was scrubbed... URL: From kohadevel at agogme.com Mon Dec 27 16:38:29 2010 From: kohadevel at agogme.com (Thomas Dukleth) Date: Mon, 27 Dec 2010 15:38:29 -0000 (UCT) Subject: [Koha-devel] Circulation history anonymisation Message-ID: <7a5c2a41f52c2684da3d0a95d6106690.squirrel@wmail.agogme.com> Reply inline: Original subject: Re: [Koha-devel] OPAC Enhancement in Koha 3.4 1. FEATURES BASED ON INDIVIDUAL CIRCULATION HISTORY. On Sun, December 26, 2010 18:03, David Schuster wrote: > These wold be great developments - The proposed features for using correlations of circulation history would produce some useful and interesting correlations which could have the advantage of using large passively acquired data sets. However, passive circulation or purchase history, is a weak basis to inform patron title choice relative to a proper recommendation system using active recommendations and various meta-data sets. Despite the weakness of correlations from circulation history for the purpose of recommendations, if someone is interested in working on developing such features for Koha, then Koha should have such features provided they are properly labelled in some form. "Patrons who borrowed this also borrowed those", would be an appropriate label for mere correlations from circulation history. "Patrons recommend those", would be an inappropriate label for mere correlations from circulation history. 2. PRIVACY USING CIRCULATION HISTORY. 2.1. CIRCULATION HISTORY ANONYMISATION. > but then some of us have issues with > patron privacy... We have parents and teachers asking for a "list of what > student X has checked out" we like to say this is not doable in Koha. Koha will need to constantly improve privacy to stay ahead of Big Brother and comply with privacy laws. Just say no to data retention requests or data retention laws which may be passed and consult appropriate legal advocates if facing data retention mandates from government. The Koha administration interface has a circulation data anonymisation feature in Home > Tools > Patrons (anonymize, bulk-delete). The tool calls C4::Circulation::AnonymiseIssueHistory from tools/cleanborrowers.pl, http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=tools/cleanborrowers.pl . In 2009, Paul Poulain had submitted a patch to allow patrons to protect the privacy of their own circulation history by setting the AnonymousPatron system preference and calling C4::Circulation::AnonymiseIssueHistory from a new script opac/opac-privacy.pl, http://lists.koha-community.org/pipermail/koha-patches/2009-May/003486.html . Both tools/cleanborrowers.pl and opac/opac-privacy.pl require some user to actively actuate a script for circulation history anonymisation. A maintenance script run from cron is needed which would use a system preference for a period to keep circulation history which can be overridden by patrons as at least ether 'no preservation period' or 'preservation forever'. Backup files containing circulation history which has not been anonymised also need to be periodically erased and overwritten with multiple passes including a 'random' overwrite. You should presume that Big Brother might seize a dump of the database at some time in future against your protestations and perhaps without your knowledge. Effort should be taken to minimise the harm in case of such a possible seizure. 2.2. CIRCULATION HISTORY ANONYMISATION WITH CORRELATIONS TO TITLES. > So > if > there was a way to hide the data but use it analytically that would be > fantastic. The suggested circulation history correlation features would need something of a feature for preserving circulation history with correlations between anonymised patrons and titles borrowed instead of only anonymous circulation history with no correlations. Complete pseudonymous circulation history would be the equivalent to having no circulation history anonymisation for anyone with access to a full dump of the database and the source code. Only creating a new anonymous patron ID for holding circulation history as items are borrowed and/or each time patron circulation history is anonymised, would preserve any correlations between anonymised patrons and titles borrowed. Preserving correlations for works, expressions, or manifestations would preserve anonymity better than preserving correlations to individual item barcodes. Beware that even such anonymised correlations could be merely a thin veil of anonymity if the data set would be relatively small or the period between anonymisation actions relatively large. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 From ian.walls at bywatersolutions.com Mon Dec 27 16:44:01 2010 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Mon, 27 Dec 2010 10:44:01 -0500 Subject: [Koha-devel] Circulation history anonymisation In-Reply-To: <7a5c2a41f52c2684da3d0a95d6106690.squirrel@wmail.agogme.com> References: <7a5c2a41f52c2684da3d0a95d6106690.squirrel@wmail.agogme.com> Message-ID: I am currently working on updating Paul Poulain's patch from 2009 to base onto current HEAD. This will give patrons the control over their own reading history (keep forever, keep until the library manually deletes, or anonymize instantly). An additional level to this would be to add a new cronjob and system preference to automatically anonymize circulation history over X days old. Setting that to 0 would anonymize instantly on return, and leaving as NULL would keep the current manual operation. Thoughts? This is getting away from the original purpose of this thread, but I wanted to share that there is work being done on this currently, and it should be released for community testing very shortly. -Ian On Mon, Dec 27, 2010 at 10:38 AM, Thomas Dukleth wrote: > Reply inline: > > > Original subject: Re: [Koha-devel] OPAC Enhancement in Koha 3.4 > > 1. FEATURES BASED ON INDIVIDUAL CIRCULATION HISTORY. > > On Sun, December 26, 2010 18:03, David Schuster wrote: > > These wold be great developments - > > The proposed features for using correlations of circulation history would > produce some useful and interesting correlations which could have the > advantage of using large passively acquired data sets. However, passive > circulation or purchase history, is a weak basis to inform patron title > choice relative to a proper recommendation system using active > recommendations and various meta-data sets. > > Despite the weakness of correlations from circulation history for the > purpose of recommendations, if someone is interested in working on > developing such features for Koha, then Koha should have such features > provided they are properly labelled in some form. "Patrons who borrowed > this also borrowed those", would be an appropriate label for mere > correlations from circulation history. "Patrons recommend those", would > be an inappropriate label for mere correlations from circulation history. > > > 2. PRIVACY USING CIRCULATION HISTORY. > > 2.1. CIRCULATION HISTORY ANONYMISATION. > > > but then some of us have issues with > > patron privacy... We have parents and teachers asking for a "list of > what > > student X has checked out" we like to say this is not doable in Koha. > > Koha will need to constantly improve privacy to stay ahead of Big Brother > and comply with privacy laws. Just say no to data retention requests or > data retention laws which may be passed and consult appropriate legal > advocates if facing data retention mandates from government. > > The Koha administration interface has a circulation data anonymisation > feature in Home > Tools > Patrons (anonymize, bulk-delete). The tool > calls C4::Circulation::AnonymiseIssueHistory from tools/cleanborrowers.pl, > > http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=tools/cleanborrowers.pl > . > > In 2009, Paul Poulain had submitted a patch to allow patrons to protect > the privacy of their own circulation history by setting the > AnonymousPatron system preference and calling > C4::Circulation::AnonymiseIssueHistory from a new script > opac/opac-privacy.pl, > http://lists.koha-community.org/pipermail/koha-patches/2009-May/003486.html > . > > Both tools/cleanborrowers.pl and opac/opac-privacy.pl require some user to > actively actuate a script for circulation history anonymisation. A > maintenance script run from cron is needed which would use a system > preference for a period to keep circulation history which can be > overridden by patrons as at least ether 'no preservation period' or > 'preservation forever'. > > Backup files containing circulation history which has not been anonymised > also need to be periodically erased and overwritten with multiple passes > including a 'random' overwrite. > > You should presume that Big Brother might seize a dump of the database at > some time in future against your protestations and perhaps without your > knowledge. Effort should be taken to minimise the harm in case of such a > possible seizure. > > > 2.2. CIRCULATION HISTORY ANONYMISATION WITH CORRELATIONS TO TITLES. > > > So > > if > > there was a way to hide the data but use it analytically that would be > > fantastic. > > The suggested circulation history correlation features would need > something of a feature for preserving circulation history with > correlations between anonymised patrons and titles borrowed instead of > only anonymous circulation history with no correlations. Complete > pseudonymous circulation history would be the equivalent to having no > circulation history anonymisation for anyone with access to a full dump of > the database and the source code. > > Only creating a new anonymous patron ID for holding circulation history as > items are borrowed and/or each time patron circulation history is > anonymised, would preserve any correlations between anonymised patrons and > titles borrowed. Preserving correlations for works, expressions, or > manifestations would preserve anonymity better than preserving > correlations to individual item barcodes. Beware that even such > anonymised correlations could be merely a thin veil of anonymity if the > data set would be relatively small or the period between anonymisation > actions relatively large. > > [...] > > > Thomas Dukleth > Agogme > 109 E 9th Street, 3D > New York, NY 10003 > USA > http://www.agogme.com > +1 212-674-3783 > > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls at bywatersolutions.com Twitter: @sekjal -------------- next part -------------- An HTML attachment was scrubbed... URL: From kohadevel at agogme.com Mon Dec 27 17:21:36 2010 From: kohadevel at agogme.com (Thomas Dukleth) Date: Mon, 27 Dec 2010 16:21:36 -0000 (UCT) Subject: [Koha-devel] Circulation history anonymisation In-Reply-To: References: <7a5c2a41f52c2684da3d0a95d6106690.squirrel@wmail.agogme.com> Message-ID: <0ed61bb92ecf0679226df2e6f3037e8d.squirrel@wmail.agogme.com> Reply inline: On Mon, December 27, 2010 15:44, Ian Walls wrote: > I am currently working on updating Paul Poulain's patch from 2009 to base > onto current HEAD. This will give patrons the control over their own > reading history (keep forever, keep until the library manually deletes, or > anonymize instantly). > > An additional level to this would be to add a new cronjob and system > preference to automatically anonymize circulation history over X days old. > Setting that to 0 would anonymize instantly on return, and leaving as NULL > would keep the current manual operation. > > Thoughts? This is getting away from the original purpose of this thread, > but I wanted to share that there is work being done on this currently, and > it should be released for community testing very shortly. I had changed the subject to a subject to which this discussion is precisely the purpose of the thread with the new subject. Discussion on the original subject can proceed under the original subject or perhaps with another subject conveying the original purpose. The original subject line lacks words identifying the nature of the proposed features. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 From kohadevel at agogme.com Mon Dec 27 17:26:26 2010 From: kohadevel at agogme.com (Thomas Dukleth) Date: Mon, 27 Dec 2010 16:26:26 -0000 (UCT) Subject: [Koha-devel] Circulation history anonymisation In-Reply-To: References: <7a5c2a41f52c2684da3d0a95d6106690.squirrel@wmail.agogme.com> Message-ID: <00bc2b3c07d22e06e9ec2b061224ad4e.squirrel@wmail.agogme.com> Reply inline: On Mon, December 27, 2010 15:44, Ian Walls wrote: > I am currently working on updating Paul Poulain's patch from 2009 to base > onto current HEAD. This will give patrons the control over their own > reading history (keep forever, keep until the library manually deletes, or > anonymize instantly). > > An additional level to this would be to add a new cronjob and system > preference to automatically anonymize circulation history over X days old. > Setting that to 0 would anonymize instantly on return, and leaving as NULL > would keep the current manual operation. Thank you for your effort. Anonymisation is very important. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 From kohadevel at agogme.com Mon Dec 27 20:05:53 2010 From: kohadevel at agogme.com (Thomas Dukleth) Date: Mon, 27 Dec 2010 19:05:53 -0000 (UCT) Subject: [Koha-devel] Solr Search use cases In-Reply-To: <4D135189.90605@alinto.com> References: <4D13500B.2040100@biblibre.com> <4D135189.90605@alinto.com> Message-ID: <6a37a07ae9fe0042c51ad181e660eb40.squirrel@wmail.agogme.com> Reply inline: On Thu, December 23, 2010 13:41, LAURENT Henri-Damien wrote: > Le 23/12/2010 14:35, LAURENT Henri-Damien a ?crit : >> Hi, >> we proposed in our solr meeting to gather the use cases that you would >> like to add and proove with the solr search. >> We wondered why nobody had added any yet.... >> And we realized that the document, though public, would not be editable. >> This has been fixed now. >> So all the persons who were longing to add usecases are now able to do >> so. The link is the same as previously publicised. >> https://spreadsheets.google.com/pub?key=0AuZF5Y_c4pIxdEVzTjUtUGFoQnFpSkpfbTU5Ykc3b2c&hl=en&output=html >> >> Please, enter whatever query you have success or problem with on zebra. >> We will try and do it with solr and then build the user interface for >> it. >> Hope that helps. > Still failing to edit. > This latest one should do : > http://tinyurl.com/3ydnuhw > If anyone wants to test and tell me if it is ok now. Yesterday, I had only an error pop-up dialog box at one minute or several second intervals in multiple web browsers. Today, I had no edit options for the spreadsheet. I added an alternative use cases table to the BibLibre Solr RFC, http://wiki.koha-community.org/wiki/Switch_to_Solr_RFC#How_To_Help , for those having difficulty editing the Google Docs spreadsheet. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 From tomascohen at gmail.com Tue Dec 28 16:46:29 2010 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Tue, 28 Dec 2010 12:46:29 -0300 Subject: [Koha-devel] Ability to hide MARC documentation links Message-ID: Hi, as those on koha-patches might have seen, I've created a bug and a patch implementing a feature that was on my original post on this enhancement: tha ability to hide links to MARC docs on the cataloguing interface. I implemented it via a syspref. Owen commented on the bug that it would be better (and I fully agree) to enable each user to hide/show the links using javascript and a checkbox. That info could also be saved on a cookie. My question is, do we aim to provide this enhancement for 3.2? It should wait for 3.4? I don't know what approach is more approval-prone for 3.2 and thus, here is an email rom me to koha-devel asking :-D. Thanks To+ From oleonard at myacpl.org Tue Dec 28 20:04:05 2010 From: oleonard at myacpl.org (Owen Leonard) Date: Tue, 28 Dec 2010 14:04:05 -0500 Subject: [Koha-devel] Add lost/claims returned displays to patron record (Bug 4241) Message-ID: I have cherry-picked the changes from wip/koha-ptfs/Bug4241 into an up-to-date branch in my development repo: ip-bug-4241-lost-tab-2010-12-28 at http://gitorious.org/koha-dev/koha-dev. I've updated the bug report as well, including these comments: The new functionality seems to be working in that: - marking something lost adds a fine to patron's record - marking something lost does or does not check in the item following the MarkLostItemsReturned system preference. A couple of bugs/to-dos I see: - The template has markup intended to handle deleted items when displaying the list of lost items. From this I assume it is supposed to show "deleted item" in the list if the lost item is deleted." However, when I delete one of the lost items it disappears from the list. - There seems to have been no code added to Harley to properly handle the addition of the MarkLostItemsReturned preference to the database or the incrementation of the version number. I would appreciate testers and comments, especially from those involved in the original creation. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From chris at bigballofwax.co.nz Wed Dec 29 18:17:34 2010 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Thu, 30 Dec 2010 06:17:34 +1300 Subject: [Koha-devel] Ability to hide MARC documentation links In-Reply-To: References: Message-ID: On 29 December 2010 04:46, Tomas Cohen Arazi wrote: > Hi, as those on koha-patches might have seen, I've created a bug and a > patch implementing a feature that was on my original post on this > enhancement: tha ability to hide links to MARC docs on the cataloguing > interface. > I implemented it via a syspref. Owen commented on the bug that it > would be better (and I fully agree) to enable each user to hide/show > the links using javascript and a checkbox. That info could also be > saved on a cookie. > > My question is, do we aim to provide this enhancement for 3.2? It > should wait for 3.4? I don't know what approach is more approval-prone > for 3.2 and thus, here is an email rom me to koha-devel asking :-D. > Hi Tomas I chatted with you about this on irc, but just for the record, things like this should be based off master and set as a patch for master. Then Chris Nighswonger can decide if he wants to cherry-pick it back to 3.2.x That way we never end up with a feature in 3.2.x that isn't in 3.4.x Chris