From paul.poulain at biblibre.com Thu Dec 1 09:11:58 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 01 Dec 2011 09:11:58 +0100 Subject: [Koha-devel] Version numbering, starting a discussion Message-ID: <4ED736CE.2080003@biblibre.com> Hello, There are 2 questions in this mail: === DB update numbering === The bug 7167 will probably pushed in a few days, and it's a new way to handle updatedatabase. They will be non-linear, meaning update 1 can be applied after update 2, and before update 3. The previous numbering pattern, made from 4 parts (3.06.00.001 for example) was made to handle release version + DB version. The 1st update for version 3.8.3 would be called 3.08.03.001 for example. With the new scheme, there's no need to have a so complex numbering system. We could just number our databases update 1, 2, 3, ... What do you think of this idea ? Why should we keep the previous numbering scheme ? Any other suggestion ? === Koha version numbering === This second topic is a harder one. So please, don't jump on this and forget the 1st one. I was wondering why/if we should continue with our 3.6 / 3.8 / 4.0 / ... numbering. This question arise because some of our libraries have problem understanding what will be the next version number. It will be 3.8. And the next one ? 3.10 or 4.0, depending on Solr or any other major change being applied. And maybe, in april, Solr will be pushed, in this case it would be called 4.0 (I don't think it will, but it's just for the example) That's quite unclear for external people. That's why I was wondering : why not use another, totally new numbering schema. The "koha april 2012" could be called 2012.A, or 12.A, or 12.1. The "Koha October 2012" could be called 2012.B, or 12.B, or 12.2 (or any other scheme, I'm open to any proposal, including not changing, I just want to share the idea. - we should just avoid Ubuntu numbering patter: 12.4 / 12.10 would be a bad idea, as Ubuntu is released in april and october, like Koha. So it may be confusing -) What we need is a number for each monthly maintainance release. But for the rest, what about changing everything in our numbering method ? There's also another interest with this idea: if we change completly our numbering, we would not seem to be "late" against another software that is currently numbered 4.8 (i've been in Greece recently, for a talk in academic libraries. I saw that there is a big confusion here, and changing the numbering would also help I think). Let's start the discussion, but please, on both topics, that are related but different: we could change #1 and not #2 ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From chris at bigballofwax.co.nz Thu Dec 1 09:17:41 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Thu, 1 Dec 2011 21:17:41 +1300 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: <4ED736CE.2080003@biblibre.com> References: <4ED736CE.2080003@biblibre.com> Message-ID: On 1 December 2011 21:11, Paul Poulain wrote: > Hello, > > There are 2 questions in this mail: > === DB update numbering === > The bug 7167 will probably pushed in a few days, and it's a new way to > handle updatedatabase. They will be non-linear, meaning update 1 can be > applied after update 2, and before update 3. > The previous numbering pattern, made from 4 parts (3.06.00.001 for > example) was made to handle release version + DB version. > The 1st update for version 3.8.3 would be called 3.08.03.001 for example. > > With the new scheme, there's no need to have a so complex numbering > system. We could just number our databases update 1, 2, 3, ... > > What do you think of this idea ? Why should we keep the previous > numbering scheme ? Any other suggestion ? > > === Koha version numbering === > This second topic is a harder one. So please, don't jump on this and > forget the 1st one. > I was wondering why/if we should continue with our 3.6 / 3.8 / 4.0 / ... > numbering. > This question arise because some of our libraries have problem > understanding what will be the next version number. It will be 3.8. And > the next one ? 3.10 or 4.0, depending on Solr or any other major change > being applied. And maybe, in april, Solr will be pushed, in this case it > would be called 4.0 (I don't think it will, but it's just for the example) > That's quite unclear for external people. > > That's why I was wondering : why not use another, totally new numbering > schema. > The "koha april 2012" could be called 2012.A, or 12.A, or 12.1. The > "Koha October 2012" could be called 2012.B, or 12.B, or 12.2 (or any > other scheme, I'm open to any proposal, including not changing, I just > want to share the idea. - we should just avoid Ubuntu numbering patter: > 12.4 / 12.10 would be a bad idea, as Ubuntu is released in april and > october, like Koha. So it may be confusing -) > What we need is a number for each monthly maintainance release. But for > the rest, what about changing everything in our numbering method ? > > There's also another interest with this idea: if we change completly our > numbering, we would not seem to be "late" against another software that > is currently numbered 4.8 (i've been in Greece recently, for a talk in > academic libraries. I saw that there is a big confusion here, and > changing the numbering would also help I think). > > Let's start the discussion, but please, on both topics, that are related > but different: we could change #1 and not #2 ! > -- Remembering that we also do maintenance releases, what would they be 2012.A.1 2012.A.2 ? I think the confusion comes in when we talk about 3.8 .. we never do releases like that, its 3.8.0, 3.8.1 etc. Having the third number is very handy, and will be very useful when we get Koha into debian which we are working on. As for the db versions, I have no opinion on that, so my vote is abstain for 1, and -1 for 2 Chris From mjr at phonecoop.coop Thu Dec 1 11:40:51 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Thu, 01 Dec 2011 10:40:51 +0000 Subject: [Koha-devel] Version numbering, starting a discussion Message-ID: Paul Poulain > === DB update numbering === [...] > What do you think of this idea ? Why should we keep the previous > numbering scheme ? Any other suggestion ? It doesn't really matter, so go with whatever's easiest to manage, but if you go back to plain numbers, I suggest starting from 4 so that it is still bigger than 3.7.whatever in one sense. > === Koha version numbering === [...] > This question arise because some of our libraries have problem > understanding what will be the next version number. It will be 3.8. And > the next one ? 3.10 or 4.0, depending on Solr or any other major change > being applied. And maybe, in april, Solr will be pushed, in this case it > would be called 4.0 (I don't think it will, but it's just for the example) > That's quite unclear for external people. All versioning numbers are hard for some people to understand. At least the current one has the advantage that Linux uses a similar one so there are already some education materials out there. > That's why I was wondering : why not use another, totally new numbering > schema. Because they're all less well-understood than our current one. You wouldn't believe the confusion the YY.MM Ubuntu-ish pattern seems to cause in new users. > There's also another interest with this idea: if we change completly our > numbering, we would not seem to be "late" against another software that > is currently numbered 4.8 (i've been in Greece recently, for a talk in > academic libraries. I saw that there is a big confusion here, and > changing the numbering would also help I think). Screw them. If that's the only reason, let's skip to 5.8 for the next release, or append ".not-a-LibLime-fake" to ours. But do we want to let them interfere with the real project in yet another way? Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. 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 ian.walls at bywatersolutions.com Thu Dec 1 13:46:27 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Thu, 1 Dec 2011 07:46:27 -0500 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: References: Message-ID: The way I've seen version numbering is in 4 parts: ... Major version has at yet been a single digit, but should we get up to major version 9, we'll probably just roll on to 10. It only changes when there are significant reworkings to the internal mechanisms of Koha. Major release is two digits, zero-padded, incrementing by 2 each time, off-set by 1 for development versions. I think the major confusion factor here is the zero-padding. Koha 3.6 and Koha 3.06 are the same thing, but people often confuse 3.06 with 3.0.6, which is a significant difference! Major releases come out every 6 months, now, and I hope that practice will continue. Maintenance releases are also two digit zero-padded values, incrementing by 1 each time. This is done on a strict monthly schedule, and keeps any major release fresh. We rarely get far past a single digit, just given our end-of-life patterns so far, but it can happen. The DB rev is really only for developers or those who follow the master branch. In the absence of the formal maintenance release notes, it gives one an idea exactly what features and bug fixes are included in the software they're running at the moment. This takes form of a 3 digit zero padded value, incrementing by 1 for each change to the database structure or default data. I think this schema works pretty well. The major hiccup I see the zero padding in the major release causing confusion. There is of course confusion introduced by other folks with a similarly-named software package trying to 'one-up' the current Koha version, but that's out of our control, and in my opinion not worth changing our practices over. One possible counter-proposal: instead of just numeric releases, what if we started given them names, as well? Something in a theme agreed upon by the community (Liz Rea and I discussed 'cheeses' as a possible theme, once). About 3 months before the next release, the community solicits ideas for names. Once gathered, we vote. Just an idea :) Cheers, -Ian On Thu, Dec 1, 2011 at 5:40 AM, MJ Ray wrote: > Paul Poulain > > === DB update numbering === [...] > > What do you think of this idea ? Why should we keep the previous > > numbering scheme ? Any other suggestion ? > > It doesn't really matter, so go with whatever's easiest to manage, > but if you go back to plain numbers, I suggest starting from 4 so > that it is still bigger than 3.7.whatever in one sense. > > > === Koha version numbering === [...] > > This question arise because some of our libraries have problem > > understanding what will be the next version number. It will be 3.8. And > > the next one ? 3.10 or 4.0, depending on Solr or any other major change > > being applied. And maybe, in april, Solr will be pushed, in this case it > > would be called 4.0 (I don't think it will, but it's just for the > example) > > That's quite unclear for external people. > > All versioning numbers are hard for some people to understand. > At least the current one has the advantage that Linux uses a similar > one so there are already some education materials out there. > > > That's why I was wondering : why not use another, totally new numbering > > schema. > > Because they're all less well-understood than our current one. > You wouldn't believe the confusion the YY.MM Ubuntu-ish pattern > seems to cause in new users. > > > There's also another interest with this idea: if we change completly our > > numbering, we would not seem to be "late" against another software that > > is currently numbered 4.8 (i've been in Greece recently, for a talk in > > academic libraries. I saw that there is a big confusion here, and > > changing the numbering would also help I think). > > Screw them. If that's the only reason, let's skip to 5.8 for the > next release, or append ".not-a-LibLime-fake" to ours. But do we > want to let them interfere with the real project in yet another way? > > Regards, > -- > MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. > http://koha-community.org supporter, web and LMS developer, statistician. > In My Opinion Only: see http://mjr.towers.org.uk/email.html > Available for hire for Koha work http://www.software.coop/products/koha > _______________________________________________ > 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 oleonard at myacpl.org Thu Dec 1 14:31:19 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Thu, 1 Dec 2011 08:31:19 -0500 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: References: Message-ID: > Screw them. ?If that's the only reason, let's skip to 5.8 for the > next release, or append ".not-a-LibLime-fake" to ours. ?But do we > want to let them interfere with the real project in yet another way? I strongly agree with this. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From kyle.m.hall at gmail.com Thu Dec 1 15:48:24 2011 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Thu, 1 Dec 2011 09:48:24 -0500 Subject: [Koha-devel] Koha Virtual Appliance 3.6 Now Available For Download Message-ID: Hey All, I just wanted to let everyone know that I've updated my virtual appliances to 3.6. This is a complete rebuild using Debian 6.0 ( Squeeze ) instead of Lenny. I also added a bit more to the Koha Console program for automatically fixing the networking issue that crops up on virtual machines from time to time. Enjoy! http://millruntech.com/koha/koha-virtual-appliances Kyle http://www.kylehall.info Mill Run Technology Solutions ( http://millruntech.com ) Crawford County Federated Library System ( http://www.ccfls.org ) Meadville Public Library ( http://www.meadvillelibrary.org ) From Katrin.Fischer at bsz-bw.de Thu Dec 1 16:22:48 2011 From: Katrin.Fischer at bsz-bw.de (Fischer, Katrin) Date: Thu, 1 Dec 2011 16:22:48 +0100 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: References: Message-ID: <028B1A54D03E7B4482CDCA4EC8F06BFD019E253D@Bodensee.bsz-bw.de> I think changing our numbering scheme will only cause more confusion than it will help. Perhaps we should have an explanation somewhere in the wiki ? but the current numbering is logical and has a lot of important information. -- Katrin From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Ian Walls Sent: Thursday, December 01, 2011 1:46 PM To: MJ Ray Cc: koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] Version numbering, starting a discussion The way I've seen version numbering is in 4 parts: ... Major version has at yet been a single digit, but should we get up to major version 9, we'll probably just roll on to 10.? It only changes when there are significant reworkings to the internal mechanisms of Koha. Major release is two digits, zero-padded, incrementing by 2 each time, off-set by 1 for development versions.? I think the major confusion factor here is the zero-padding.? Koha 3.6 and Koha 3.06 are the same thing, but people often confuse 3.06 with 3.0.6, which is a significant difference!? Major releases come out every 6 months, now, and I hope that practice will continue. Maintenance releases are also two digit zero-padded values, incrementing by 1 each time.? This is done on a strict monthly schedule, and keeps any major release fresh.? We rarely get far past a single digit, just given our end-of-life patterns so far, but it can happen. The DB rev is really only for developers or those who follow the master branch.? In the absence of the formal maintenance release notes, it gives one an idea exactly what features and bug fixes are included in the software they're running at the moment.?? This takes form of a 3 digit zero padded value, incrementing by 1 for each change to the database structure or default data. I think this schema works pretty well.? The major hiccup I see the zero padding in the major release causing confusion.? There is of course confusion introduced by other folks with a similarly-named software package trying to 'one-up' the current Koha version, but that's out of our control, and in my opinion not worth changing our practices over. One possible counter-proposal:? instead of just numeric releases, what if we started given them names, as well?? Something in a theme agreed upon by the community (Liz Rea and I discussed 'cheeses' as a possible theme, once).? About 3 months before the next release, the community solicits ideas for names.? Once gathered, we vote.? Just an idea :) Cheers, -Ian On Thu, Dec 1, 2011 at 5:40 AM, MJ Ray wrote: Paul Poulain > === DB update numbering === [...] > What do you think of this idea ? Why should we keep the previous > numbering scheme ? Any other suggestion ? It doesn't really matter, so go with whatever's easiest to manage, but if you go back to plain numbers, I suggest starting from 4 so that it is still bigger than 3.7.whatever in one sense. > === Koha version numbering === [...] > This question arise because some of our libraries have problem > understanding what will be the next version number. It will be 3.8. And > the next one ? 3.10 or 4.0, depending on Solr or any other major change > being applied. And maybe, in april, Solr will be pushed, in this case it > would be called 4.0 (I don't think it will, but it's just for the example) > That's quite unclear for external people. All versioning numbers are hard for some people to understand. At least the current one has the advantage that Linux uses a similar one so there are already some education materials out there. > That's why I was wondering : why not use another, totally new numbering > schema. Because they're all less well-understood than our current one. You wouldn't believe the confusion the YY.MM Ubuntu-ish pattern seems to cause in new users. > There's also another interest with this idea: if we change completly our > numbering, we would not seem to be "late" against another software that > is currently numbered 4.8 (i've been in Greece recently, for a talk in > academic libraries. I saw that there is a big confusion here, and > changing the numbering would also help I think). Screw them. ?If that's the only reason, let's skip to 5.8 for the next release, or append ".not-a-LibLime-fake" to ours. ?But do we want to let them interfere with the real project in yet another way? Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha _______________________________________________ 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 From jcamins at cpbibliography.com Thu Dec 1 16:31:18 2011 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Thu, 1 Dec 2011 10:31:18 -0500 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: <028B1A54D03E7B4482CDCA4EC8F06BFD019E253D@Bodensee.bsz-bw.de> References: <028B1A54D03E7B4482CDCA4EC8F06BFD019E253D@Bodensee.bsz-bw.de> Message-ID: Katrin failed to mention her excellent counter-proposal to Ian's suggestion of cheese as a theme: cookies and other sweets as the theme. Koha 3.8 Curried coconut oatmeal chocolate chip cookies, etc. Regards, Jared On Thu, Dec 1, 2011 at 10:22 AM, Fischer, Katrin wrote: > I think changing our numbering scheme will only cause more confusion than > it will help. Perhaps we should have an explanation somewhere in the wiki ? > but the current numbering is logical and has a lot of important information. > > -- Katrin > > > From: koha-devel-bounces at lists.koha-community.org [mailto: > koha-devel-bounces at lists.koha-community.org] On Behalf Of Ian Walls > Sent: Thursday, December 01, 2011 1:46 PM > To: MJ Ray > Cc: koha-devel at lists.koha-community.org > Subject: Re: [Koha-devel] Version numbering, starting a discussion > > The way I've seen version numbering is in 4 parts: > > ... > > Major version has at yet been a single digit, but should we get up to > major version 9, we'll probably just roll on to 10. It only changes when > there are significant reworkings to the internal mechanisms of Koha. > > Major release is two digits, zero-padded, incrementing by 2 each time, > off-set by 1 for development versions. I think the major confusion factor > here is the zero-padding. Koha 3.6 and Koha 3.06 are the same thing, but > people often confuse 3.06 with 3.0.6, which is a significant difference! > Major releases come out every 6 months, now, and I hope that practice will > continue. > > Maintenance releases are also two digit zero-padded values, incrementing > by 1 each time. This is done on a strict monthly schedule, and keeps any > major release fresh. We rarely get far past a single digit, just given our > end-of-life patterns so far, but it can happen. > > The DB rev is really only for developers or those who follow the master > branch. In the absence of the formal maintenance release notes, it gives > one an idea exactly what features and bug fixes are included in the > software they're running at the moment. This takes form of a 3 digit zero > padded value, incrementing by 1 for each change to the database structure > or default data. > > I think this schema works pretty well. The major hiccup I see the zero > padding in the major release causing confusion. There is of course > confusion introduced by other folks with a similarly-named software package > trying to 'one-up' the current Koha version, but that's out of our control, > and in my opinion not worth changing our practices over. > > One possible counter-proposal: instead of just numeric releases, what if > we started given them names, as well? Something in a theme agreed upon by > the community (Liz Rea and I discussed 'cheeses' as a possible theme, > once). About 3 months before the next release, the community solicits > ideas for names. Once gathered, we vote. Just an idea :) > > Cheers, > > > -Ian > On Thu, Dec 1, 2011 at 5:40 AM, MJ Ray wrote: > Paul Poulain > > === DB update numbering === [...] > > What do you think of this idea ? Why should we keep the previous > > numbering scheme ? Any other suggestion ? > It doesn't really matter, so go with whatever's easiest to manage, > but if you go back to plain numbers, I suggest starting from 4 so > that it is still bigger than 3.7.whatever in one sense. > > > === Koha version numbering === [...] > > This question arise because some of our libraries have problem > > understanding what will be the next version number. It will be 3.8. And > > the next one ? 3.10 or 4.0, depending on Solr or any other major change > > being applied. And maybe, in april, Solr will be pushed, in this case it > > would be called 4.0 (I don't think it will, but it's just for the > example) > > That's quite unclear for external people. > All versioning numbers are hard for some people to understand. > At least the current one has the advantage that Linux uses a similar > one so there are already some education materials out there. > > > That's why I was wondering : why not use another, totally new numbering > > schema. > Because they're all less well-understood than our current one. > You wouldn't believe the confusion the YY.MM Ubuntu-ish pattern > seems to cause in new users. > > > There's also another interest with this idea: if we change completly our > > numbering, we would not seem to be "late" against another software that > > is currently numbered 4.8 (i've been in Greece recently, for a talk in > > academic libraries. I saw that there is a big confusion here, and > > changing the numbering would also help I think). > Screw them. If that's the only reason, let's skip to 5.8 for the > next release, or append ".not-a-LibLime-fake" to ours. But do we > want to let them interfere with the real project in yet another way? > > Regards, > -- > MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. > http://koha-community.org supporter, web and LMS developer, statistician. > In My Opinion Only: see http://mjr.towers.org.uk/email.html > Available for hire for Koha work http://www.software.coop/products/koha > _______________________________________________ > 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 > _______________________________________________ > 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/ > -- Jared Camins-Esakov 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 ian.walls at bywatersolutions.com Thu Dec 1 16:38:24 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Thu, 1 Dec 2011 10:38:24 -0500 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: <028B1A54D03E7B4482CDCA4EC8F06BFD019E253D@Bodensee.bsz-bw.de> References: <028B1A54D03E7B4482CDCA4EC8F06BFD019E253D@Bodensee.bsz-bw.de> Message-ID: Paul, About your first suggestion (the one you didn't want to get buried in the discussion of part 2): It would be feasible to employ a new numbers system just for DB revs (not for releases). DB rev is only really used in master, so the third number (maintenance release) is always "00". What we really need is a multi-headed path through DB revs. We need to be able to trace the DB revision history for both master and stable releases. I'd really like to see an easy way to convert back and forth, so if you're on master, and want to change to stable, you don't have to move the earth. DB revs need to maintain a sequence, as sometimes order of application is important. But if two completely orthogonal things are applied out of sequence, it really doesn't matter. Oh, wait, this is just like in Git! That would lead me back to using a Hash to keep track of the current default DB state, but as it's not just structure, but also data, that gets more complex than possibility really allows. -Ian On Thu, Dec 1, 2011 at 10:22 AM, Fischer, Katrin wrote: > I think changing our numbering scheme will only cause more confusion than > it will help. Perhaps we should have an explanation somewhere in the wiki ? > but the current numbering is logical and has a lot of important information. > > -- Katrin > > > From: koha-devel-bounces at lists.koha-community.org [mailto: > koha-devel-bounces at lists.koha-community.org] On Behalf Of Ian Walls > Sent: Thursday, December 01, 2011 1:46 PM > To: MJ Ray > Cc: koha-devel at lists.koha-community.org > Subject: Re: [Koha-devel] Version numbering, starting a discussion > > The way I've seen version numbering is in 4 parts: > > ... > > Major version has at yet been a single digit, but should we get up to > major version 9, we'll probably just roll on to 10. It only changes when > there are significant reworkings to the internal mechanisms of Koha. > > Major release is two digits, zero-padded, incrementing by 2 each time, > off-set by 1 for development versions. I think the major confusion factor > here is the zero-padding. Koha 3.6 and Koha 3.06 are the same thing, but > people often confuse 3.06 with 3.0.6, which is a significant difference! > Major releases come out every 6 months, now, and I hope that practice will > continue. > > Maintenance releases are also two digit zero-padded values, incrementing > by 1 each time. This is done on a strict monthly schedule, and keeps any > major release fresh. We rarely get far past a single digit, just given our > end-of-life patterns so far, but it can happen. > > The DB rev is really only for developers or those who follow the master > branch. In the absence of the formal maintenance release notes, it gives > one an idea exactly what features and bug fixes are included in the > software they're running at the moment. This takes form of a 3 digit zero > padded value, incrementing by 1 for each change to the database structure > or default data. > > I think this schema works pretty well. The major hiccup I see the zero > padding in the major release causing confusion. There is of course > confusion introduced by other folks with a similarly-named software package > trying to 'one-up' the current Koha version, but that's out of our control, > and in my opinion not worth changing our practices over. > > One possible counter-proposal: instead of just numeric releases, what if > we started given them names, as well? Something in a theme agreed upon by > the community (Liz Rea and I discussed 'cheeses' as a possible theme, > once). About 3 months before the next release, the community solicits > ideas for names. Once gathered, we vote. Just an idea :) > > Cheers, > > > -Ian > On Thu, Dec 1, 2011 at 5:40 AM, MJ Ray wrote: > Paul Poulain > > === DB update numbering === [...] > > What do you think of this idea ? Why should we keep the previous > > numbering scheme ? Any other suggestion ? > It doesn't really matter, so go with whatever's easiest to manage, > but if you go back to plain numbers, I suggest starting from 4 so > that it is still bigger than 3.7.whatever in one sense. > > > === Koha version numbering === [...] > > This question arise because some of our libraries have problem > > understanding what will be the next version number. It will be 3.8. And > > the next one ? 3.10 or 4.0, depending on Solr or any other major change > > being applied. And maybe, in april, Solr will be pushed, in this case it > > would be called 4.0 (I don't think it will, but it's just for the > example) > > That's quite unclear for external people. > All versioning numbers are hard for some people to understand. > At least the current one has the advantage that Linux uses a similar > one so there are already some education materials out there. > > > That's why I was wondering : why not use another, totally new numbering > > schema. > Because they're all less well-understood than our current one. > You wouldn't believe the confusion the YY.MM Ubuntu-ish pattern > seems to cause in new users. > > > There's also another interest with this idea: if we change completly our > > numbering, we would not seem to be "late" against another software that > > is currently numbered 4.8 (i've been in Greece recently, for a talk in > > academic libraries. I saw that there is a big confusion here, and > > changing the numbering would also help I think). > Screw them. If that's the only reason, let's skip to 5.8 for the > next release, or append ".not-a-LibLime-fake" to ours. But do we > want to let them interfere with the real project in yet another way? > > Regards, > -- > MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. > http://koha-community.org supporter, web and LMS developer, statistician. > In My Opinion Only: see http://mjr.towers.org.uk/email.html > Available for hire for Koha work http://www.software.coop/products/koha > _______________________________________________ > 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 > _______________________________________________ > 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 cnighswonger at foundations.edu Thu Dec 1 17:11:51 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 1 Dec 2011 11:11:51 -0500 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: References: <028B1A54D03E7B4482CDCA4EC8F06BFD019E253D@Bodensee.bsz-bw.de> Message-ID: 2011/12/1 Ian Walls : > About your first suggestion (the one you didn't want to get buried in the > discussion of part 2): > > DB revs need to maintain a sequence, as sometimes order of application is > important.? But if two completely orthogonal things are applied out of > sequence, it really doesn't matter.? Oh, wait, this is just like in Git! > > That would lead me back to using a Hash to keep track of the current default > DB state, but as it's not just structure, but also data, that gets more > complex than possibility really allows. DB version really becomes meaningless for master/dev use once we allow non-linear and selective application of DB related changes. The only time everyone is likely to be at a common DB version will be at major/maintenance release times. And even then, if someone has opted out of certain DB changes, they may never be "in sync" with everyone else. This leads me to think that the use of hashes is the best option. As Ian mentions, this is common to version control systems which is really what we are talking about here: a DB version control system. /me wonders if we are not re-inventing the wheel here... there's only so many ways to make it round, you know. Kind Regards, Chris From gmc at esilibrary.com Thu Dec 1 21:28:24 2011 From: gmc at esilibrary.com (Galen Charlton) Date: Thu, 01 Dec 2011 15:28:24 -0500 Subject: [Koha-devel] Code4Lib Scholarships available Message-ID: <4ED7E368.1070900@esilibrary.com> Please excuse the cross-posting. Equinox Software is offering 2 scholarships to the code4lib conference in February. The scholarships will reimburse travel and accommodation expenses up to $750.00 USD for a full-time employee from public libraries using either Evergreen or Koha to attend the Code4Lib Conference in Seattle, Washington, USA, from February 6-9, 2012. The awardees will also receive free registration to Code4Lib. ELIGIBILITY The applicants must be presently working in a public library that is currently using or is actively committed to moving to either Evergreen or Koha as their ILS. The applicants must indicate any amount and source of additional funding which, combined with the Scholarship, will permit them to cover their expenses to attend the Conference. (This will not reduce the amount of the award.) Preference will be given to underfunded libraries or libraries in budget crisis. DEADLINE FOR APPLICATION December 31, 2011 The email application should include a current resume, including all contact information, education, and experience, along with an essay as described below. The applicants will write up to 750 words of narrative in English to address the following: ? Description of the library?s mission and commitment to open source solutions ? How attendance may benefit the applicant ? How the applicant intends to share the benefit of the experience with colleagues ? Description of funding constraints, budgetary limitations, or travel/hiring freezes pertinent to the applicant?s situation APPLICATION ADDRESS: Please send resumes and essays to Grace Dunbar before December 31, 2011 by email attachment to c4lgrant at esilibrary.com NOTIFICATION: The successful applicants will be notified by January 5, 2012. Feel free to re-post this announcement and/or our press release (http://esilibrary.com/esi/newsitem.php?id=2182) Regards, Galen -- Galen Charlton Director of Support and Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org From gmc at esilibrary.com Thu Dec 1 23:56:30 2011 From: gmc at esilibrary.com (Galen Charlton) Date: Thu, 01 Dec 2011 17:56:30 -0500 Subject: [Koha-devel] Code4Lib Scholarships available In-Reply-To: <4ED7E368.1070900@esilibrary.com> References: <4ED7E368.1070900@esilibrary.com> Message-ID: <4ED8061E.6000602@esilibrary.com> Hi, To add one clarification, since Equinox is not holding any registration slots for the conference, the "free registration to Code4Lib" will be done by reimbursing the awardees $150 each for the registration fee. This reimbursement is in _addition_ to the $750 for travel and accommodations. This does mean that in order to be considered for the scholarship, one must already be registered or on the waitlist, and the awards can only be made to individuals who have an active registration by January 5th. Regards, Galen On 12/01/2011 03:28 PM, Galen Charlton wrote: > Please excuse the cross-posting. > > Equinox Software is offering 2 scholarships to the code4lib conference > in February. > > The scholarships will reimburse travel and accommodation expenses up to > $750.00 USD for a full-time employee from public libraries using either > Evergreen or Koha to attend the Code4Lib Conference in Seattle, > Washington, USA, from February 6-9, 2012. The awardees will also receive > free registration to Code4Lib. > > ELIGIBILITY > The applicants must be presently working in a public library that is > currently using or is actively committed to moving to either Evergreen > or Koha as their ILS. > > The applicants must indicate any amount and source of additional funding > which, combined with the Scholarship, will permit them to cover their > expenses to attend the Conference. (This will not reduce the amount of > the award.) > > Preference will be given to underfunded libraries or libraries in budget > crisis. > > DEADLINE FOR APPLICATION December 31, 2011 > > The email application should include a current resume, including all > contact information, education, and experience, along with an essay as > described below. > > The applicants will write up to 750 words of narrative in English to > address the following: > ? Description of the library?s mission and commitment to open source > solutions > ? How attendance may benefit the applicant > ? How the applicant intends to share the benefit of the experience with > colleagues > ? Description of funding constraints, budgetary limitations, or > travel/hiring freezes pertinent to the applicant?s situation > > APPLICATION ADDRESS: Please send resumes and essays to Grace Dunbar > before December 31, 2011 by email attachment to c4lgrant at esilibrary.com > > NOTIFICATION: The successful applicants will be notified by January 5, > 2012. > > Feel free to re-post this announcement and/or our press release > (http://esilibrary.com/esi/newsitem.php?id=2182) > > Regards, > > Galen -- Galen Charlton Director of Support and Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org From M.de.Rooy at rijksmuseum.nl Fri Dec 2 12:17:36 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Fri, 2 Dec 2011 11:17:36 +0000 Subject: [Koha-devel] [Bug 7310] Improving permissions on lists (virtual shelves) Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3137C53A@S-MAIL-1B.rijksmuseum.intra> Hi, If you have a suggestion on report 7310 about lists management, please respond. Following up on report 7281 (hide lists from OPAC) I am sending the following question to the ml in order to improve lists management: 1 Who should be allowed to delete a public [closed] list (category 2 only!) or add/remove items from that list? (Note that removing all items from a list is more or less the same as removing the list at once.) My answer would be: the owner should only be allowed to do that in the OPAC. A user in the staff client may do it too. [Currently, any opac login can delete the list. This is a bug!] 2 Who should be allowed to delete an public open list (category 3 only!) or add/remove items from that list? My answer would be: any login from OPAC or staff. It should be made clear that creating such a list is really at your own risk ;) Currently, a user in the opac cannot create an open list. (Is that a bug?) 3 Proposed revisions to lists management: If we solve points 1 and 2, management of lists comes down to all or nothing. You can do everything with an open list, but if you are not owning a closed list, you can't do anything. Would it be useful to have something in between? Like deleting your own added items from a closed list (we could save borrowernumber in virtualshelfcontents)?? Or give the owner of an open list the choice between full access for other logins, adding items only or deleting own added items? What do you think? Marcel From kyle.m.hall at gmail.com Fri Dec 2 14:58:43 2011 From: kyle.m.hall at gmail.com (Kyle Hall) Date: Fri, 2 Dec 2011 08:58:43 -0500 Subject: [Koha-devel] [Koha] Koha Virtual Appliance 3.6 Now Available For Download In-Reply-To: References: Message-ID: Glad to be of service! I would encourage anyone who tries the new appliance to let me know if they discover any appliance specific problems. I haven't noticed any, but one can never be sure. Kyle http://www.kylehall.info Mill Run Technology Solutions ( http://millruntech.com ) Crawford County Federated Library System ( http://www.ccfls.org ) Meadville Public Library ( http://www.meadvillelibrary.org ) On Thu, Dec 1, 2011 at 10:08 AM, Muhammad Abdullah wrote: > Thanks alot for this. Been using it for awhile now, very useful > appliance. This upgrade should make it more robust, now that it is > running on Debian 6. > > On Thu, Dec 1, 2011 at 10:48 PM, Kyle Hall wrote: >> Hey All, >> ?I just wanted to let everyone know that I've updated my virtual >> appliances to 3.6. This is a complete rebuild using Debian 6.0 ( >> Squeeze ) instead of Lenny. I also added a bit more to the Koha >> Console program for automatically fixing the networking issue that >> crops up on virtual machines from time to time. Enjoy! >> >> http://millruntech.com/koha/koha-virtual-appliances >> >> Kyle >> >> http://www.kylehall.info >> Mill Run Technology Solutions ( http://millruntech.com ) >> Crawford County Federated Library System ( http://www.ccfls.org ) >> Meadville Public Library ( http://www.meadvillelibrary.org ) >> _______________________________________________ >> Koha mailing list ?http://koha-community.org >> Koha at lists.katipo.co.nz >> http://lists.katipo.co.nz/mailman/listinfo/koha From paul.poulain at biblibre.com Fri Dec 2 17:46:35 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 02 Dec 2011 17:46:35 +0100 Subject: [Koha-devel] Benchmarking Koha Message-ID: <4ED900EB.60901@biblibre.com> Hello, I've pushed a few minuts ago a new script, you'll find it at misc/load_testing/benchmark_staff.pl Run the script to get the parameters and information. It run up to 7 different benchmarks on a given setup. I'll use this script regularly, when pushing patches that are related to speed of Koha. I'll add the results on the page : http://wiki.koha-community.org/wiki/Benchmark_for_3.8 I already have added 2 benchmark, with the speed of today master, with and without memcache. My first surprise (and I did the tests 3 times to be sure I wasn't making a mistake !) is that you almost get no speed improvement with memcache ON. Some patches should be validated soon, I hope we will see a lot of improvements, as Koha really need it ! HTH -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From dpavlin at gmail.com Fri Dec 2 18:47:10 2011 From: dpavlin at gmail.com (Dobrica Pavlinusic) Date: Fri, 2 Dec 2011 18:47:10 +0100 Subject: [Koha-devel] Benchmarking Koha In-Reply-To: <4ED900EB.60901@biblibre.com> References: <4ED900EB.60901@biblibre.com> Message-ID: <20111202174709.GE22460@rot13.org> On Fri, Dec 02, 2011 at 05:46:35PM +0100, Paul Poulain wrote: > My first surprise (and I did the tests 3 times to be sure I wasn't > making a mistake !) is that you almost get no speed improvement with > memcache ON. I have seen similar behaviour when I benchmarked Koha about a year ago[1] In the end, I opted to test with plain Memoize as opposed to memcache-backed one. My assumption was that TCP overhead eats away all improvements we might get from memcache (or to put it nicely, mysql and zebra are not *that* slow :-) 1: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7177 2: http://git.rot13.org/?p=koha.git;a=commitdiff;h=b2155fc483f09b34c4a6ba92256f2732152bb1d5;hp=daadc5bc8f24e1bf2c1e8d958d410408d1cccc47 -- Dobrica Pavlinusic 2share!2flame dpavlin at rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin From chrisc at catalyst.net.nz Fri Dec 2 18:56:32 2011 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Sat, 3 Dec 2011 06:56:32 +1300 Subject: [Koha-devel] Benchmarking Koha In-Reply-To: <20111202174709.GE22460@rot13.org> References: <4ED900EB.60901@biblibre.com> <20111202174709.GE22460@rot13.org> Message-ID: <20111202175632.GP17072@rorohiko.wgtn.cat-it.co.nz> * Dobrica Pavlinusic (dpavlin at gmail.com) wrote: > On Fri, Dec 02, 2011 at 05:46:35PM +0100, Paul Poulain wrote: > > My first surprise (and I did the tests 3 times to be sure I wasn't > > making a mistake !) is that you almost get no speed improvement with > > memcache ON. > > I have seen similar behaviour when I benchmarked Koha about a year > ago[1] > > In the end, I opted to test with plain Memoize as opposed to > memcache-backed one. My assumption was that TCP overhead eats away all > improvements we might get from memcache (or to put it nicely, mysql and > zebra are not *that* slow :-) > > 1: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7177 > 2: http://git.rot13.org/?p=koha.git;a=commitdiff;h=b2155fc483f09b34c4a6ba92256f2732152bb1d5;hp=daadc5bc8f24e1bf2c1e8d958d410408d1cccc47 > Memcached is for scalability not speed. It will however give you speed in easy serialised and deserialised objects, that are costly to create. But scalability is the main thing, you will notice better throughput. And it will take load off your database server, which when you site is very busy will provide speed. 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 fridolyn.somers at gmail.com Fri Dec 2 18:57:25 2011 From: fridolyn.somers at gmail.com (Fridolyn SOMERS) Date: Fri, 2 Dec 2011 18:57:25 +0100 Subject: [Koha-devel] Benchmarking Koha In-Reply-To: <20111202174709.GE22460@rot13.org> References: <4ED900EB.60901@biblibre.com> <20111202174709.GE22460@rot13.org> Message-ID: Looks great. But I have a missing dependance : "HTTPD::Bench::ApacheBench". Is there a debian package of it ? Regards, -- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers at gmail.com On Fri, Dec 2, 2011 at 6:47 PM, Dobrica Pavlinusic wrote: > On Fri, Dec 02, 2011 at 05:46:35PM +0100, Paul Poulain wrote: > > My first surprise (and I did the tests 3 times to be sure I wasn't > > making a mistake !) is that you almost get no speed improvement with > > memcache ON. > > I have seen similar behaviour when I benchmarked Koha about a year > ago[1] > > In the end, I opted to test with plain Memoize as opposed to > memcache-backed one. My assumption was that TCP overhead eats away all > improvements we might get from memcache (or to put it nicely, mysql and > zebra are not *that* slow :-) > > 1: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7177 > 2: > http://git.rot13.org/?p=koha.git;a=commitdiff;h=b2155fc483f09b34c4a6ba92256f2732152bb1d5;hp=daadc5bc8f24e1bf2c1e8d958d410408d1cccc47 > > -- > Dobrica Pavlinusic 2share!2flame > dpavlin at rot13.org > Unix addict. Internet consultant. > http://www.rot13.org/~dpavlin > _______________________________________________ > 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 mtj at kohaaloha.com Sun Dec 4 01:34:37 2011 From: mtj at kohaaloha.com (Mason James) Date: Sun, 4 Dec 2011 13:34:37 +1300 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: References: Message-ID: <101F53DA-80F6-44DE-A7B0-CFE746BADD02@kohaaloha.com> On 2011-12-2, at 2:31 AM, Owen Leonard wrote: >> Screw them. If that's the only reason, let's skip to 5.8 for the >> next release, or append ".not-a-LibLime-fake" to ours. But do we >> want to let them interfere with the real project in yet another way? > > I strongly agree with this. yeah, i'm kinda OK with this too... (a bump to 5.8 for the next Koha release) -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 535 bytes Desc: This is a digitally signed message part URL: From mtj at kohaaloha.com Sun Dec 4 01:43:34 2011 From: mtj at kohaaloha.com (Mason James) Date: Sun, 4 Dec 2011 13:43:34 +1300 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: References: <028B1A54D03E7B4482CDCA4EC8F06BFD019E253D@Bodensee.bsz-bw.de> Message-ID: <47A1F9C9-DA41-40BB-96FE-6FCB89C9B8B0@kohaaloha.com> On 2011-12-2, at 4:31 AM, Jared Camins-Esakov wrote: > Katrin failed to mention her excellent counter-proposal to Ian's suggestion of cheese as a theme: cookies and other sweets as the theme. Koha 3.8 Curried coconut oatmeal chocolate chip cookies, etc. > > Regards, > Jared any type of food is a great idea :) (this worked pretty well for the Debian project, and their 'toy story' release names) the 'master' branch would always be called 'ricotta' (a fresh cheese?) ...or some other names? -> http://www.foodsubs.com/Chefresh.html :) -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 535 bytes Desc: This is a digitally signed message part URL: From mtj at kohaaloha.com Sun Dec 4 03:04:20 2011 From: mtj at kohaaloha.com (Mason James) Date: Sun, 4 Dec 2011 15:04:20 +1300 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: <47A1F9C9-DA41-40BB-96FE-6FCB89C9B8B0@kohaaloha.com> References: <028B1A54D03E7B4482CDCA4EC8F06BFD019E253D@Bodensee.bsz-bw.de> <47A1F9C9-DA41-40BB-96FE-6FCB89C9B8B0@kohaaloha.com> Message-ID: <050EB281-331D-43D7-9944-E8F72BEEC1D8@kohaaloha.com> On 2011-12-4, at 1:43 PM, Mason James wrote: > > On 2011-12-2, at 4:31 AM, Jared Camins-Esakov wrote: > >> Katrin failed to mention her excellent counter-proposal to Ian's suggestion of cheese as a theme: cookies and other sweets as the theme. Koha 3.8 Curried coconut oatmeal chocolate chip cookies, etc. >> >> Regards, >> Jared > > any type of food is a great idea :) > (this worked pretty well for the Debian project, and their 'toy story' release names) > we could also consider switching to the Debian style?, i have found it quite easy to understand. would it work well for Koha? the Debian project uses both an internal 'linux-kernal' style numbering system (like Koha does already) and people-friendly nick-names too... :) http://wiki.debian.org/DebianReleases http://www.debian.org/releases/ http://www.debian.org/doc/manuals/project-history/ch-releases.en.html -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 535 bytes Desc: This is a digitally signed message part URL: From cnighswonger at foundations.edu Sun Dec 4 03:36:35 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Sat, 3 Dec 2011 21:36:35 -0500 Subject: [Koha-devel] Koha 3.2.11 is now available [Security Release] Message-ID: It is with pleasure that I announce the release of Koha 3.2.11. The package can be retrieved from: http://download.koha-community.org/koha-3.02.11.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.02.11.tar.gz.MD5 http://download.koha-community.org/koha-3.02.11.tar.gz.MD5.asc http://download.koha-community.org/koha-3.02.11.tar.gz.sig Release notes for 3.2.11 are below. Come and get it! RELEASE NOTES FOR KOHA 3.2.10 - 3 December 2011 ======================================================================== Koha is the first free and open source software library automation package (ILS). Development is sponsored by libraries of varying types and sizes, volunteers, and support companies from around the world. The website for the Koha project is http://koha-community.org/ Koha 3.2.10 can be downloaded from: http://download.koha-community.org/koha-3.02.10.tar.gz Installation instructions can be found at: http://wiki.koha-community.org/wiki/Installation_Documentation IMPORTANT ANNOUNCEMENT CONCERNING 3.2.x EOL ======================================================================== 3.2.x has reached its EOL and is officialy unsupported at this point. Releases beyond 3.2.10 are for security issues only and are not gauranteed. Highlights of 3.2.10 ====================== NOTE: This release is a security release. It is strongly recommended that users apply this upgrade immediately to production systems. If you are installing a new system, please use this version rather than earlier versions. 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 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.10: Fr??d??rick Capovilla Chris Cormack Chris Nighswonger 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.6 Release Team and all who participated in QA for their diligent labors in testing and pushing well over 680 patches since the 3.2.0 relese. Their continued work very much makes possible the release of 3.2.10 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 catalyst.net.nz Sun Dec 4 12:16:10 2011 From: robin at catalyst.net.nz (Robin Sheat) Date: Mon, 05 Dec 2011 00:16:10 +1300 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: <050EB281-331D-43D7-9944-E8F72BEEC1D8@kohaaloha.com> References: <028B1A54D03E7B4482CDCA4EC8F06BFD019E253D@Bodensee.bsz-bw.de> <47A1F9C9-DA41-40BB-96FE-6FCB89C9B8B0@kohaaloha.com> <050EB281-331D-43D7-9944-E8F72BEEC1D8@kohaaloha.com> Message-ID: <4EDB567A.7090706@catalyst.net.nz> Op 04-12-11 15:04, Mason James schreef: >>> Katrin failed to mention her excellent counter-proposal to Ian's suggestion of cheese as a theme: cookies and other sweets as the theme. Koha 3.8 Curried coconut oatmeal chocolate chip cookies, etc. Been done, kinda. I have Android devices running Froyo (an Americanism I guess), Honeycomb (what I think the rest of us call hokey-pokey) and Ice Cream Sandwich (an interesting idea.) Not that I'm averse to it :) I think I prefer it to names such as Onanistic Ocelot[0] ;) > we could also consider switching to the Debian style?, i have found it quite easy to understand. > would it work well for Koha? fwiw (and this won't affect anything to do with Koha numbering), I've been numbering the Debian packages in the Debian style, but as the package detail is in upstream we never get away from '-1' (which is OK) e.g. 3.06.01 is 3.6.1-1. The master builds are along the lines of 3.7-1~git. or something like that. Should I ever need to push a patch in the packaging itself, it would become 3.6.1-2. This matters in debian-land because the source is base on the part before the '-', the stuff after that is debian-release-specific. [0] not the real name. Robin. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From mjr at phonecoop.coop Sun Dec 4 12:56:48 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Sun, 04 Dec 2011 11:56:48 +0000 Subject: [Koha-devel] Version numbering, starting a discussion Message-ID: Mason James > we could also consider switching to the Debian style?, i have found it quite easy to understand. > would it work well for Koha? > > > the Debian project uses both an internal 'linux-kernal' style numbering system (like Koha does already) and people-friendly nick-names too... :) Debian's x.y.z number is not quite linux-style: there have been full (non-development) x.1 release versions. I'm not against the idea but a difficulty I have with Debian's nick-names is that (except for sid) there seems little meaning or relationship or progression to them, so remembering that lenny is 5.0 and squeeze is 6.0 is not straightforward for me. Hope that informs, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. 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 mtj at kohaaloha.com Sun Dec 4 21:10:26 2011 From: mtj at kohaaloha.com (Mason James) Date: Mon, 5 Dec 2011 09:10:26 +1300 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: References: Message-ID: On 2011-12-5, at 12:56 AM, MJ Ray wrote: > Mason James >> we could also consider switching to the Debian style?, i have found it quite easy to understand. >> would it work well for Koha? >> >> >> the Debian project uses both an internal 'linux-kernal' style numbering system (like Koha does already) and people-friendly nick-names too... :) > > Debian's x.y.z number is not quite linux-style: there have been full > (non-development) x.1 release versions. yep, sorry, i generalized there > > I'm not against the idea but a difficulty I have with Debian's > nick-names is that (except for sid) there seems little meaning or > relationship or progression to them, so remembering that lenny is 5.0 > and squeeze is 6.0 is not straightforward for me. > both android and ubuntu choose their release names in alphabetical sequence, (like a,b,c,d) as a workaround to your problem ...we could do that too?, (eg: brie, cheddar, durrus) -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 535 bytes Desc: This is a digitally signed message part URL: From 5p4m at gmx.de Sun Dec 4 22:32:35 2011 From: 5p4m at gmx.de (Mirko) Date: Sun, 04 Dec 2011 22:32:35 +0100 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: References: Message-ID: <4EDBE6F3.7040304@gmx.de> Mason James schrieb am 05.12.2011 09:10:26 > > both android and ubuntu choose their release names in > alphabetical sequence, (like a,b,c,d) as a workaround to your > problem > > ...we could do that too?, (eg: brie, cheddar, durrus) > Please don't do this. There are so many nice things in the world and you want to name it after rotten milk? Nooooo. Think of the lactose intolerant, vegans and people with irrational aversions (like me). From mtj at kohaaloha.com Mon Dec 5 01:51:05 2011 From: mtj at kohaaloha.com (Mason James) Date: Mon, 5 Dec 2011 13:51:05 +1300 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: <4EDBE6F3.7040304@gmx.de> References: <4EDBE6F3.7040304@gmx.de> Message-ID: On 2011-12-5, at 10:32 AM, Mirko wrote: > Mason James schrieb am 05.12.2011 09:10:26 >> >> both android and ubuntu choose their release names in >> alphabetical sequence, (like a,b,c,d) as a workaround to your >> problem >> >> ...we could do that too?, (eg: brie, cheddar, durrus) >> > > Please don't do this. ok, so make a better suggestion. how about vegetables? (asparagus, broccoli, carrot, etc...) > There are so many nice things in the world and > you want to name it after rotten milk? Nooooo. Think of the lactose > intolerant, vegans and people with irrational aversions (like me). is anyone intolerant/irrationally-averse towards vegetables? -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 535 bytes Desc: This is a digitally signed message part URL: From mtj at kohaaloha.com Mon Dec 5 02:04:59 2011 From: mtj at kohaaloha.com (Mason James) Date: Mon, 5 Dec 2011 14:04:59 +1300 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: References: <4EDBE6F3.7040304@gmx.de> Message-ID: <2ACD3FB2-9A4E-4DB7-86E3-39B906335A47@kohaaloha.com> On 2011-12-5, at 1:51 PM, Mason James wrote: > > On 2011-12-5, at 10:32 AM, Mirko wrote: > >> Mason James schrieb am 05.12.2011 09:10:26 >>> >>> both android and ubuntu choose their release names in >>> alphabetical sequence, (like a,b,c,d) as a workaround to your >>> problem >>> >>> ...we could do that too?, (eg: brie, cheddar, durrus) >>> >> >> Please don't do this. > > > ok, so make a better suggestion. > > how about vegetables? (asparagus, broccoli, carrot, etc...) my favorite (other than any food category) is important librarians, (Avram, Cutter, Dewey, etc...) http://en.wikipedia.org/wiki/List_of_librarians -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 535 bytes Desc: This is a digitally signed message part URL: From abesottedphoenix at yahoo.com Mon Dec 5 02:07:37 2011 From: abesottedphoenix at yahoo.com (BWS Johnson) Date: Sun, 4 Dec 2011 17:07:37 -0800 (PST) Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: <2ACD3FB2-9A4E-4DB7-86E3-39B906335A47@kohaaloha.com> References: <4EDBE6F3.7040304@gmx.de> <2ACD3FB2-9A4E-4DB7-86E3-39B906335A47@kohaaloha.com> Message-ID: <1323047257.73332.YahooMailNeo@web114712.mail.gq1.yahoo.com> Salvete! >> how about vegetables? (asparagus, broccoli, carrot, etc...) > ??? If we're going to be this silly, I'd go with Cait's sweets idea modified for the appropriate nationality of the KohaCon host for the year the release is out.? > > my favorite (other than any food category) is important librarians, (Avram, > Cutter, Dewey, etc...) > ??? Screw Dewey, he took students' eye colour and waist size. Cheers, Brooke From cnighswonger at foundations.edu Mon Dec 5 03:14:19 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Sun, 4 Dec 2011 21:14:19 -0500 Subject: [Koha-devel] Adding .mailmap file to 3.6.x Message-ID: Hi all, I've added a .mailmap file to the 3.6.x branch. This file is used by git to help standardize authors' names/email addys. You can read more in the comments included in the file as well as as in 'man git-shortlog.' Please feel free to submit patches against this file to improve your own information. Paul, I would recommend adding this file to master as well. Kind Regards, Chris http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=.mailmap;h=b186da0047a91d58dfaa6227e788b8c32e69b5e2;hb=5dc48be361fd66db512f8c4caaa022535efa3485 From oleonard at myacpl.org Mon Dec 5 03:30:43 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Sun, 4 Dec 2011 21:30:43 -0500 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: <101F53DA-80F6-44DE-A7B0-CFE746BADD02@kohaaloha.com> References: <101F53DA-80F6-44DE-A7B0-CFE746BADD02@kohaaloha.com> Message-ID: On Sat, Dec 3, 2011 at 7:34 PM, Mason James wrote: > > On 2011-12-2, at 2:31 AM, Owen Leonard wrote: > >>> Screw them. ?If that's the only reason, let's skip to 5.8 for the >>> next release, or append ".not-a-LibLime-fake" to ours. ?But do we >>> want to let them interfere with the real project in yet another way? >> >> I strongly agree with this. > > yeah, i'm kinda OK with this too... (a bump to 5.8 for the next Koha release) Okay, just to be clear, I was strongly agreeing with the "screw them" part. I interpreted the 5.8 comment as sarcasm. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From mtj at kohaaloha.com Mon Dec 5 03:31:19 2011 From: mtj at kohaaloha.com (Mason James) Date: Mon, 5 Dec 2011 15:31:19 +1300 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: <1323047257.73332.YahooMailNeo@web114712.mail.gq1.yahoo.com> References: <4EDBE6F3.7040304@gmx.de> <2ACD3FB2-9A4E-4DB7-86E3-39B906335A47@kohaaloha.com> <1323047257.73332.YahooMailNeo@web114712.mail.gq1.yahoo.com> Message-ID: On 2011-12-5, at 2:07 PM, BWS Johnson wrote: > > Salvete! > >>> how about vegetables? (asparagus, broccoli, carrot, etc...) >> > > If we're going to be this silly, I'd go with Cait's sweets idea modified for the appropriate nationality of the KohaCon host for the year the release is out. >> >> my favorite (other than any food category) is important librarians, (Avram, >> Cutter, Dewey, etc...) >> > > Screw Dewey, he took students' eye colour and waist size. yeah, i like sweets the most too, it's a fun theme :) dead librarians are a bit obscure and boring (no offense people) -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 535 bytes Desc: This is a digitally signed message part URL: From jcamins at cpbibliography.com Mon Dec 5 03:44:52 2011 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Sun, 4 Dec 2011 21:44:52 -0500 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: References: <4EDBE6F3.7040304@gmx.de> <2ACD3FB2-9A4E-4DB7-86E3-39B906335A47@kohaaloha.com> <1323047257.73332.YahooMailNeo@web114712.mail.gq1.yahoo.com> Message-ID: It seems to me that my input is called for here. > > If we're going to be this silly, I'd go with Cait's sweets idea > modified for the appropriate nationality of the KohaCon host for the year > the release is out. > >> > >> my favorite (other than any food category) is important librarians, > (Avram, > >> Cutter, Dewey, etc...) > >> > > > > Screw Dewey, he took students' eye colour and waist size. > > > yeah, i like sweets the most too, it's a fun theme :) > Agreed. And we must have a Koha x.y.6 Frambois Fudge. dead librarians are a bit obscure and boring (no offense people) > I'm not included in that category. Just sayin'. Regards, Jared -- Jared Camins-Esakov 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 mtj at kohaaloha.com Mon Dec 5 06:33:48 2011 From: mtj at kohaaloha.com (Mason James) Date: Mon, 5 Dec 2011 18:33:48 +1300 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: References: <4EDBE6F3.7040304@gmx.de> <2ACD3FB2-9A4E-4DB7-86E3-39B906335A47@kohaaloha.com> <1323047257.73332.YahooMailNeo@web114712.mail.gq1.yahoo.com> Message-ID: <3AE4BE89-91D0-46DA-9AA7-C7C149D0CDD5@kohaaloha.com> On 2011-12-5, at 3:44 PM, Jared Camins-Esakov wrote: > It seems to me that my input is called for here. > > > If we're going to be this silly, I'd go with Cait's sweets idea modified for the appropriate nationality of the KohaCon host for the year the release is out. > >> > >> my favorite (other than any food category) is important librarians, (Avram, > >> Cutter, Dewey, etc...) > >> > > > > Screw Dewey, he took students' eye colour and waist size. > > > yeah, i like sweets the most too, it's a fun theme :) > > Agreed. And we must have a Koha x.y.6 Frambois Fudge. yes, yess! and next... Koha x.y.8 is 'germane g?teaux' :P -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 535 bytes Desc: This is a digitally signed message part URL: From M.de.Rooy at rijksmuseum.nl Mon Dec 5 11:46:35 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Mon, 5 Dec 2011 10:46:35 +0000 Subject: [Koha-devel] FW: Improving permissions on lists (virtual shelves) Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3137D1A4@S-MAIL-1B.rijksmuseum.intra> This would create the need for borrowernumber in virtualshelvescontent. And a new table for shared lists/invitations with shelfnumber, borrowernumber, invitationkey, date. Comments welcome. -----Oorspronkelijk bericht----- Van: Marcel de Rooy Verzonden: maandag 5 december 2011 11:43 Aan: koha Onderwerp: Improving permissions on lists (virtual shelves) Hi all, Still hoping to get some feedback on this subject, I would now propose the following. Please respond to the list, if you agree or disagree. 1 Do not allow to create a public list in the OPAC. (Only private lists.) Public lists are only created by staff users in the staff client. 2 Add three permission options to any list: a) Allow adding entries b) Allow deleting your own entries (that you added) and c) Allow deleting entries that someone else added. This makes the distinction between public list and open list no longer needed and adds some refinement in lists management. Only the owner of the list can change these permissions. 3 Add a new (opac) feature to private lists: Share a list (with another patron). Let the user share access to a list by Koha sending an email with a URL including some (temporary) invitation key. When the invited patron clicks that URL (when logged in) he gains access (in accordance with the described permission options for that specific list). The invited patron can always 'delete' the shared list, i.e. delete the share. The owner can 'unshare' the list and remove all shares for that list. 4 With respect to user privacy, a feature may be added in staff client to moderate shared list names. 5 Possibly, libraries do not want patrons sharing lists. So the option could be disabled with a preference. In that case points 2 and 3 still apply. Note that the shared private list concept makes report 7281 (Hiding some lists) obsolete. Bug 7310 will be used for this feature. Your comments are very welcome! Marcel From M.de.Rooy at rijksmuseum.nl Mon Dec 5 12:55:11 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Mon, 5 Dec 2011 11:55:11 +0000 Subject: [Koha-devel] Passed QA Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3137D23C@S-MAIL-1B.rijksmuseum.intra> Paul, While we are waiting on 7167, would it be possible to push patches with a db rev like 6190, 6880 and 7077? Since we already have revisions on borrowers/debarred in 001 and 002, we could just continue with pushing other db revs too until 7167 passed qa? That seems fair. The number at which the new dbrev scheme will start, is just a number ;) Does 7167 still need more community consensus or additional signoffs? Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From 5p4m at gmx.de Mon Dec 5 21:34:03 2011 From: 5p4m at gmx.de (Mirko) Date: Mon, 05 Dec 2011 21:34:03 +0100 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: References: <4EDBE6F3.7040304@gmx.de> Message-ID: <4EDD2ABB.9060706@gmx.de> Mason James schrieb am 05.12.2011 13:51:05 > > ok, so make a better suggestion. > > how about vegetables? (asparagus, broccoli, carrot, etc...) > puredyne[1] seems to be using something in that direction with names like "leek and potato" and "carrot and coriander". Personally, I like the "sweets" approach that was already mentioned in this thread. Koha is much sweeter than, let's say, a lime. On the other hand, I would also like "fruit" as a theme. I would love "Omniscient orange"! Cheers, Mirko [1] http://puredyne.org/ From mtj at kohaaloha.com Mon Dec 5 22:01:47 2011 From: mtj at kohaaloha.com (Mason James) Date: Tue, 6 Dec 2011 10:01:47 +1300 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: <4EDD2ABB.9060706@gmx.de> References: <4EDBE6F3.7040304@gmx.de> <4EDD2ABB.9060706@gmx.de> Message-ID: On 2011-12-6, at 9:34 AM, Mirko wrote: > Mason James schrieb am 05.12.2011 13:51:05 > >> >> ok, so make a better suggestion. >> >> how about vegetables? (asparagus, broccoli, carrot, etc...) >> > > puredyne[1] seems to be using something in that direction with names > like "leek and potato" and "carrot and coriander". > > Personally, I like the "sweets" approach that was already mentioned > in this thread. Koha is much sweeter than, let's say, a lime. On the > other hand, I would also like "fruit" as a theme. I would love > "Omniscient orange"! > > Cheers, > > Mirko > yep, 'fruit' was one of my other favs too :p theres a very impressive list of them on wikipedia http://en.wikipedia.org/wiki/List_of_culinary_fruits -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 535 bytes Desc: This is a digitally signed message part URL: From cnighswonger at foundations.edu Mon Dec 5 22:05:08 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Mon, 5 Dec 2011 16:05:08 -0500 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: References: <4EDBE6F3.7040304@gmx.de> <4EDD2ABB.9060706@gmx.de> Message-ID: 2011/12/5 Mason James : > > theres a very impressive list of them on wikipedia > http://en.wikipedia.org/wiki/List_of_culinary_fruits We could also use astronomical names of stars, constellations, etc. Kind Regards, Chris From axelb at skolelinux.no Mon Dec 5 22:33:04 2011 From: axelb at skolelinux.no (Axel Bojer) Date: Mon, 05 Dec 2011 22:33:04 +0100 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: References: <4EDBE6F3.7040304@gmx.de> <4EDD2ABB.9060706@gmx.de> Message-ID: <4EDD3890.1080107@skolelinux.no> Den 05. des. 2011 22:05, skrev Chris Nighswonger: > 2011/12/5 Mason James : >> >> theres a very impressive list of them on wikipedia >> http://en.wikipedia.org/wiki/List_of_culinary_fruits > > We could also use astronomical names of stars, constellations, etc. If by names: Why not famous book titles? Something related to libraries ... Makes it easier to remember at least, and more relevant :-) -A. From custard at westnet.com.au Mon Dec 5 23:18:51 2011 From: custard at westnet.com.au (=?iso-8859-1?Q?Ramon_Andi=F1ach?=) Date: Tue, 6 Dec 2011 06:18:51 +0800 Subject: [Koha-devel] Version numbering, starting a discussion In-Reply-To: References: <101F53DA-80F6-44DE-A7B0-CFE746BADD02@kohaaloha.com> Message-ID: <9E271FBE-31AD-42B1-B181-B531265A7D1B@westnet.com.au> On 05/12/2011, at 10:30 , Owen Leonard wrote: > On Sat, Dec 3, 2011 at 7:34 PM, Mason James wrote: >> >> On 2011-12-2, at 2:31 AM, Owen Leonard wrote: >> >>>> Screw them. If that's the only reason, let's skip to 5.8 for the >>>> next release, or append ".not-a-LibLime-fake" to ours. But do we >>>> want to let them interfere with the real project in yet another way? >>> >>> I strongly agree with this. >> >> yeah, i'm kinda OK with this too... (a bump to 5.8 for the next Koha release) > > Okay, just to be clear, I was strongly agreeing with the "screw them" > part. I interpreted the 5.8 comment as sarcasm. > > -- Owen A counter thought. Some time back a small but useful browser called Netscape skipped numbers to bring its numbers in line with IE. I always felt that this was pandering to IE, and letting the competition set the schedule. That said, anything but Mozilla's current numbering scheme/philosophy! Even Ubuntu's is more intelligible than that. As for the naming idea. Two ideas: 1. Words with roughly similar meanings to koha. (I suspect there's not enough, but haven't really looked into it) 2. Other famous "gifts" (other than koha!). -ramon. From magnus at enger.priv.no Tue Dec 6 11:57:55 2011 From: magnus at enger.priv.no (Magnus Enger) Date: Tue, 6 Dec 2011 11:57:55 +0100 Subject: [Koha-devel] Global bug squashing day #7 - It's on! Message-ID: Dear Community! Global bug squashing day #7 is almost an hour old - in Kiribati! http://wiki.koha-community.org/wiki/2011-12-07_Global_bug_squashing_day And remember: you don't have to be a hard-core developer to make a difference! Take a look at the wiki page above to see all the fun things you can do! Best regards, Magnus Enger From sandeep.bhavsar at gmail.com Tue Dec 6 17:59:03 2011 From: sandeep.bhavsar at gmail.com (SANDEEP BHAVSAR) Date: Tue, 6 Dec 2011 22:29:03 +0530 Subject: [Koha-devel] Koha and Pazpar2 Message-ID: Respected All I would like to add Koha OPAC, open access databases and commercial databases (EBSCO, ProQuest) in pazpar2. Kindly guide me for integrating all these resources. -- Thanks and Regards Sandeep Bhavsar Librarian Dr.V.N.Bedekar Institute of Management Studies Thane(W) 400601 MUMBAI. INDIA @@@@@@@@@@@@@@@@@@@@@@@@@@ email : sandeep.bhavsar at gmail.com Mob : 9029 345777 elibrary :http://www.vpmthane.org/im/elib/main.htm @@@@@@@@@@@@@@@@@@@@@@@@@@ -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleonard at myacpl.org Tue Dec 6 18:05:56 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Tue, 6 Dec 2011 12:05:56 -0500 Subject: [Koha-devel] Koha and Pazpar2 In-Reply-To: References: Message-ID: > I would like to add Koha OPAC, open access databases and commercial > databases (EBSCO, ProQuest) in pazpar2. Since no answers appear to be forthcoming you may need to turn to these resources: http://koha-community.org/support/paid-support/ -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From nightstalker2019 at gmail.com Wed Dec 7 05:01:58 2011 From: nightstalker2019 at gmail.com (Auninda Rumy Saleque) Date: Wed, 7 Dec 2011 10:01:58 +0600 Subject: [Koha-devel] [Koha] Koha fails to authenticate against a secured CAS server Message-ID: Hello everyone, Lately I tried to connect koha with a CAS server for testing purpose and everything seemed to work fine but when I tried to use a secured CAS server url for koha, the login keeps on failing and returns me to the koha login page with an invalid error msg 'Sorry, the CAS login failed.' am I doing something wrong here? Note: for an insecured CAS login url, both secured/insecured koha login works fine but it fails in both cases if i use a secured CAS url. Any help will be greatly appreciated. Regards -- Auninda Rumy Saleque Asst. System Programmer Ayesha Abed Library BRAC University Dhaka, Bangladesh From paul.poulain at biblibre.com Wed Dec 7 09:46:57 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 07 Dec 2011 09:46:57 +0100 Subject: [Koha-devel] [Koha] Koha fails to authenticate against a secured CAS server In-Reply-To: References: Message-ID: <4EDF2801.7020506@biblibre.com> Le 07/12/2011 05:01, Auninda Rumy Saleque a ?crit : > Hello everyone, Hello Auninda (should I say Rumy ? Saleque ?), and welcome on board, it's the 1st post I see from you. > Note: for an insecured CAS login url, both secured/insecured koha > login works fine but it fails in both cases if i use a secured CAS > url. What do you call a "secured CAS url" ? We (BibLibre) have a customer running Koha with a CAS server (it's not koha-community/master yet -they should upgrade in 2012-), and it work fine. So some details are welcomed ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From nightstalker2019 at gmail.com Wed Dec 7 10:19:05 2011 From: nightstalker2019 at gmail.com (Auninda Rumy Saleque) Date: Wed, 7 Dec 2011 15:19:05 +0600 Subject: [Koha-devel] [Koha] Koha fails to authenticate against a secured CAS server In-Reply-To: <4EDF2801.7020506@biblibre.com> References: <4EDF2801.7020506@biblibre.com> Message-ID: Hi Paul, Thankx for the welcoming gesture. You can call me auninda. yea, this is my first post here in the developers group. What do you call a "secured CAS url" ? well, i can access my cas server over a secured mode i.e. https or in normal http mode. this is what i meant as secured/not-secured CAS urls that i put in the 'casServerUrl' preference box of koha. in my case, under the 'casServerUrl' preference i am putting my cas server link (http://internal_cas_ip:8080/cas) which helps me login to some koha user using cas authentication. but if the link is an https link (https://internal_cas_ip:8443/cas), i am being returned to the koha login page with this message 'sorry, the cas login failed.' and also the returned url looks something like this: 'http://192.168.2.95/cgi-bin/koha/opac-user.pl?ticket=ST-48-tfCtNe4BxN5ejOj5qelb-cas' Note: i am also using cas over https with drupal and it is working fine. so i am guessing i am putting/doing something wrong while configuring koha in combination with CAS. Thankx On 12/7/11, Paul Poulain wrote: > Le 07/12/2011 05:01, Auninda Rumy Saleque a ?crit : >> Hello everyone, > Hello Auninda (should I say Rumy ? Saleque ?), and welcome on board, > it's the 1st post I see from you. > >> Note: for an insecured CAS login url, both secured/insecured koha >> login works fine but it fails in both cases if i use a secured CAS >> url. > What do you call a "secured CAS url" ? We (BibLibre) have a customer > running Koha with a CAS server (it's not koha-community/master yet -they > should upgrade in 2012-), and it work fine. So some details are 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/ > -- Auninda Rumy Saleque 06101003 SECS BRACU From psm_vu at india.com Wed Dec 7 12:44:44 2011 From: psm_vu at india.com (Partha Mukhopadhyay) Date: Wed, 7 Dec 2011 12:44:44 +0100 (CET) Subject: [Koha-devel] Version numbering, starting a discussion - LTS In-Reply-To: <9E271FBE-31AD-42B1-B181-B531265A7D1B@westnet.com.au> References: <101F53DA-80F6-44DE-A7B0-CFE746BADD02@kohaaloha.com> , <9E271FBE-31AD-42B1-B181-B531265A7D1B@westnet.com.au> Message-ID: <20111207114444.254FE1C33B9E@smtp03.zmail.com> An HTML attachment was scrubbed... URL: From 5p4m at gmx.de Wed Dec 7 15:42:43 2011 From: 5p4m at gmx.de (Mirko) Date: Wed, 07 Dec 2011 15:42:43 +0100 Subject: [Koha-devel] Version numbering, starting a discussion - LTS In-Reply-To: <20111207114444.254FE1C33B9E@smtp03.zmail.com> References: <101F53DA-80F6-44DE-A7B0-CFE746BADD02@kohaaloha.com> , <9E271FBE-31AD-42B1-B181-B531265A7D1B@westnet.com.au> <20111207114444.254FE1C33B9E@smtp03.zmail.com> Message-ID: <4EDF7B63.6050309@gmx.de> If this is an offer to sponsor the maintenance of a LTS release (with money or labour), such a version once in a while could be interesting to some. There might be support firms that can offer such a paid service. You can find a list on http://www.koha-community.org/ I don't see why every big Koha release (coming every six months) should be LTS though. Best, Mirko Partha Mukhopadhyay schrieb am 07.12.2011 12:44:44 > What about LTS (Long Term Support) release in every six months? > > ---------------------------------------------------- > > Dr. Parthasarathi Mukhopadhyay > > Lecturer (Sr. Scale) > > Department of Library and Information Science > > The University of Burdwan (WB) > > ------------------------------------------ > From paul.poulain at biblibre.com Wed Dec 7 15:50:16 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 07 Dec 2011 15:50:16 +0100 Subject: [Koha-devel] [Koha] Koha fails to authenticate against a secured CAS server In-Reply-To: References: <4EDF2801.7020506@biblibre.com> Message-ID: <4EDF7D28.6060905@biblibre.com> Le 07/12/2011 10:19, Auninda Rumy Saleque a ?crit : > What do you call a "secured CAS url" ? > > well, i can access my cas server over a secured mode i.e. https or in > normal http mode. this is what i meant as secured/not-secured CAS urls > that i put in the 'casServerUrl' preference box of koha. in my case, > under the 'casServerUrl' preference i am putting my cas server link > (http://internal_cas_ip:8080/cas) which helps me login to some koha > user using cas authentication. but if the link is an https link > (https://internal_cas_ip:8443/cas), i am being returned to the koha > login page with this message 'sorry, the cas login failed.' and also > the returned url looks something like this: > 'http://192.168.2.95/cgi-bin/koha/opac-user.pl?ticket=ST-48-tfCtNe4BxN5ejOj5qelb-cas' > > Note: i am also using cas over https with drupal and it is working > fine. so i am guessing i am putting/doing something wrong while > configuring koha in combination with CAS. mmm... that's very strange, because Aix-Marseille universities also have an https: CAS server, as you can see at http://catalogue.univ-aix-marseille.fr/cgi-bin/koha/opac-user.pl do you have a more detailled error message ? is it open (ie: can I test myself, if it's possible, drop me a valid cas account by mail pls) PS: you should/could add a bug at bugs.koha-community.org Even if it's a configuration problem, it will be worth adding it in the doc once we will have understood/fix the problem ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From M.de.Rooy at rijksmuseum.nl Wed Dec 7 17:08:58 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Wed, 7 Dec 2011 16:08:58 +0000 Subject: [Koha-devel] Improving permissions on lists (virtual shelves) Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3137F0B6@S-MAIL-1B.rijksmuseum.intra> Thanks all for responding to this inquiry. This was very helpful. I am merging here the results and will be posting them back to report 7310 or a wiki page. Feel free to correct me where I made the wrong conclusion. 1 Public lists in OPAC: Currently, a user should be logged in to create a list. I would strongly recommend to keep that restriction. A new preference is added that allows opac users to create public lists or does not allow that. Additionally, I would add the restriction that another opac user cannot change the list type of a public list to private list or change the list permissions when he did not create it (currently possible); the owner can do that or a staff member with permissions in the staff client. 2 Three new permissions per list: Add items, Delete own items, Delete other items. This makes the Open list type obsolete. 3 Share private lists with another patron (as described before). Can be turned on/off with a preference. 4 Staff client features: add an option under Tools to moderate inappropriate list names for public lists and shared private lists. (A library is free to use it or not.) Add staff list permission: allow to manage lists (virtual shelves). With that permission a staff member can moderate the list names as mentioned and access the staff Lists module. (He can change list type and permissions. He can take ownership of a public list if the owner has been deleted.) 5 [NEW] Deleting a patron should also delete his (unshared) private lists, his shares with private lists of someone else and clear owner on his public lists. [Currently, the virtualshelves table will contain lists (of any type) of deleted borrowers.] A new problem is what to do with shared private lists (still used by other patrons). Just deleting them would not be nice for those patrons. Just promoting them to public lists could not be ideal too; same for leaving this to be sorted out by the librarian. The best [pragmatic] solution is probably setting ownership to the first user that received a share on that list. (He already had access to those lists, but is now able to change settings on that list too.) ADDITIONAL COMMENT If a library does not allow public list creation in OPAC and does not share lists, how should a staff member change list type of a private list? This is not possible. You could say by design. It is the result of combining those two prefs. As a workaround, a staff member could enable public list creation, let the user change list type in opac and reset the pref. Or enable sharing lists, let the user share that list with staff member, accept it and reset the pref. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Wed Dec 7 19:34:36 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Wed, 7 Dec 2011 13:34:36 -0500 Subject: [Koha-devel] Koha 3.4.7 is now available Message-ID: It is with pleasure that I announce the release of Koha 3.4.7. The package can be retrieved from: http://download.koha-community.org/koha-3.04.07.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.04.07.tar.gz.MD5 http://download.koha-community.org/koha-3.04.07.tar.gz.MD5.asc http://download.koha-community.org/koha-3.04.07.tar.gz.sig Release notes for 3.4.7 are below. Come and get it! RELEASE NOTES FOR KOHA 3.6.2 07 Dec 2011 ======================================================================== Koha is the first free and open source software library automation package (ILS). Development is sponsored by libraries of varying types and sizes, volunteers, and support companies from around the world. The website for the Koha project is http://koha-community.org/ Koha 3.6.2 can be downloaded from: http://download.koha-community.org/koha-3.06.02.tar.gz Installation instructions can be found at: http://wiki.koha-community.org/wiki/Installation_Documentation OR in the INSTALL files that come in the tarball Koha 3.6.2 is a bugfix/maintenance release. Highlights of 3.6.2 ====================== 7285 blocker ILSDI service AuthenticatePatron doesn't work 6740 critical can add items at ordering but not remove items 6786 critical False detection of index names in Search; make index names case insensitive 6893 critical Order from suggestion does not remove suggestion from 'accepted' list 5211 major marking lost (long overdue) not charging fines 6022 major Auth_with_ldap check if categorycode is valid 6530 major item due notice label saying 'unknown' 7250 major stage_biblios_file.pl is missing options for encodings, wrongly passing the MARC flavour instead Bugs fixed in 3.6.2 ====================== 2346 normal consolidate duplicate methods C4::Overdues::UpdateBorrowerDebarred and C4::Members::DebarMember 4330 normal Copyright statements out of date 5974 normal Bogus auth check for "StaffMember" role 6291 normal Cart printing truncated in Firefox 6877 normal test for Libravatar::URL can cause scripts to abort 6894 normal Default currency on Acquisitions suggestion form 6926 normal overdue_notices don't send itemcount to notification 6966 normal Update Help Files for Koha 3.6 Release 6997 normal koha-remove leaves system in inconsistent state if there is an error 7105 normal Bad sql request in GetSubscriptions 7108 normal Lists of "Similar" languages break display across multiple lines in both Opac and Intranet 7120 normal After deleting order from order receive page redirect fails 7216 normal koha-restore doesn't set HOME 7251 normal Fields are separated by "t" when the delimiter preference is set to "tabulation" in overdue_notices.pl 7254 normal Show pending orders from baskets with closedate > 180 days 7268 normal Templates failing translation tests 7280 normal Can't place hold without selecting on list 2011 enhancement Link patron extra sort fields to authorized values 3385 enhancement Add checkout date and renewal date to display list of checked out items 4051 enhancement add columns to overdues export 4877 enhancement Create and update the manual pages for the koha-* scripts. 5327 enhancement Unit tests required for all C4 modules 6303 enhancement Display Organisation and Parent Organisation names when viewing a borrower of type organisation 7008 enhancement Sometimes zebra needs a tmp directory that it doesn't create itself 7041 enhancement Sort >1000 search results with sortmax parameter in zebra config file 7073 enhancement GetCOinSBiblio should take $record, not $biblionumber 7091 enhancement Patches required to make the packages know about the 3.6 release System requirements ====================== Changes since 3.4: * Perl 5.10 is required Documentation ====================== As of Koha 3.2, the Koha manual is now maintained in DocBook. The home page for Koha documentation is http://koha-community.org/documentation/ As of the date of these release notes, only the English version of the Koha manual is available: http://manual.koha-community.org/3.6/en/ The Git repository for the Koha manual can be found at http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary Translations ====================== Complete or near-complete translations of the OPAC and staff interface are available in this release for the following languages: * Chinese (Taiwan) * Danish * English (USA) * English (UK) * French (France) * German * Italian * Portuguese (Brazil) * Spanish Partial translations are available for various other languages. The Koha team welcomes additional translations; please see http://wiki.koha-community.org/wiki/Translating_Koha for information about translating Koha, and join the koha-translate list to volunteer: http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate The most up-to-date translations can be found at: http://translate.koha-community.org/ Release Team ====================== The release team for Koha 3.6 is Release Manager: Chris Cormack Documentation Manager: Nicole C Engard Translation Manager: Fr??d??ric Demians QA Manager: Ian Walls Bug Wranglers: MJ Ray, Marcel Roy, Paul Poulain, Mason James Release Maintainer (3.4.x): Chris Nighswonger Release Maintainer (3.6.x): Chris Nighswonger Credits ====================== We thank the following libraries who are known to have sponsored new features in Koha 3.6: * Los Gatos Public Library * NEKLS * East Brunswick Public Library * Athens County Public Libraries * Horowhenua Library Trust * Halton Borough Council * South Taranaki District Council We thank the following individuals who contributed patches to Koha 3.6.2. 1 Alex Arnaud 1 Greg Barniskis 3 Jared Camins-Esakov 2 Colin Campbell 2 Fr??d??rick Capovilla 8 Chris Cormack 1 Christophe Croullebois 1 Fr??d??ric Demians 1 Nicole Engard 1 Magnus Enger 5 Katrin Fischer 1 Chris Hall 1 Mason James 2 Srdjan Jankovic 1 Henri-Damien Laurent 7 Owen Leonard 9 Chris Nighswonger 1 Albert Oller 1 Dobrica Pavlinusic 1 Maxime Pelletier 10 Paul Poulain 1 Liz Rea 2 Martin Renvoize 4 Marcel de Rooy 2 Adrien Saurat 3 Robin Sheat 2 Ian Walls We regret any omissions. If a contributor has been inadvertantly missed, please send a patch against these release notes to koha-patches at lists.koha-community.org. Revision control notes ====================== The Koha project uses Git for version control. The current development version of Koha can be retrieved by checking out the master branch of git://git.koha-community.org/koha.git The branch for Koha 3.6.x (i.e., this version of Koha and future bugfix releases) is 3.6.x. The next major feature release of Koha will be Koha 3.8.0. Bugs and feature requests ====================== Bug reports and feature requests can be filed at the Koha bug tracker at http://bugs.koha-community.org/ Ehara taku toa i te toa takitahi, engari he toa takitini ##### Autogenerated release notes updated last on 07 Dec 2011 16:41:07 Z ##### From tomascohen at gmail.com Wed Dec 7 20:27:58 2011 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 7 Dec 2011 16:27:58 -0300 Subject: [Koha-devel] on Bug 6802 Message-ID: Hi, I've just heard of bug 6802, we are having some issues with that as it is holding a University from finishing its Koha official deployment. I'm willing to work on that, and would like to ask if something like this would be a good solution: somehow wrapping the "saveitem" block within if (C4::Context->preference("IndependantBranches")) { my $userenv = C4::Context->userenv(); unless (($userenv->{'flags'} == 1) or ($userenv->{'branch'} eq $item->{'homebranch'})) { # ERROR HANDLING CODE HERE } } might or not work. Hope we start a good discussion on this... Regards To+ From chris at bigballofwax.co.nz Wed Dec 7 20:39:42 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Thu, 8 Dec 2011 08:39:42 +1300 Subject: [Koha-devel] on Bug 6802 In-Reply-To: References: Message-ID: On 8 December 2011 08:27, Tomas Cohen Arazi wrote: > Hi, I've just heard of bug 6802, we are having some issues with that > as it is holding a University from finishing its Koha official > deployment. > I'm willing to work on that, and would like to ask if something like > this would be a good ?solution: somehow wrapping the "saveitem" block > within > > ? ?if (C4::Context->preference("IndependantBranches")) { > ? ? ? ?my $userenv = C4::Context->userenv(); > ? ? ? ?unless (($userenv->{'flags'} == 1) or ($userenv->{'branch'} eq > $item->{'homebranch'})) { > ? ? ? ?# ERROR HANDLING CODE HERE > > > ? ? ? ?} > ? ?} > > might or not work. Hope we start a good discussion on this... > That should work, I recommend giving it a try and throwing up a patch for others to test Chris From cnighswonger at foundations.edu Wed Dec 7 20:45:30 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Wed, 7 Dec 2011 14:45:30 -0500 Subject: [Koha-devel] Koha 3.4.7 is now available [Corrected Version] Message-ID: It is with pleasure that I announce the release of Koha 3.4.7. The package can be retrieved from: http://download.koha-community.org/koha-3.04.07.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.04.07.tar.gz.MD5 http://download.koha-community.org/koha-3.04.07.tar.gz.MD5.asc http://download.koha-community.org/koha-3.04.07.tar.gz.sig Release notes for 3.4.7 are below the fold. Come and get it! RELEASE NOTES FOR KOHA 3.4.7 07 Dec 2011 ======================================================================== Koha is the first free and open source software library automation package (ILS). Development is sponsored by libraries of varying types and sizes, volunteers, and support companies from around the world. The website for the Koha project is http://koha-community.org/ Koha 3.4.7 can be downloaded from: http://download.koha-community.org/koha-3.04.07.tar.gz Installation instructions can be found at: http://wiki.koha-community.org/wiki/Installation_Documentation OR in the INSTALL files that come in the tarball Koha 3.4.7 is a bugfix/maintenance release. Highlights of 3.4.7 ====================== 7138 blocker Can't print basket group order pdf. 6628 critical [security] help system use insecure REFERRER for file inclusion 6629 critical [security] insecure use of Cookie for language selection 5945 major can't search patron's email anymore 6475 major Edit it's not possible subfield "0" in MARC framework 6977 major Support for repeated subfields when importing an authority into a biblio record field. 7069 major Javascript errors in tags/review 7095 major Merge Marker Test Issues Unclear Failure Messages 7134 major patron records getting funny birthdays 7207 major Cannot export label batches Bugs fixed in 3.4.7 ====================== 3958 normal Standardize vendor/supplier/bookseller terminology 5885 normal UNIMARC XSLT changes 5974 normal Bogus auth check for "StaffMember" role 6799 normal rebuild_zebra.pl -x produces invalid XML records 6895 normal Diacritics in Pootle/po files are broken in source text 6963 normal When creating a new order, the item isn't added if its barcode already exists in the items table. 6994 normal 'No budget defined' showing up although budgets and funds are defined 7076 normal shelfpage renders OPAC XSLT bloc for intranet Lists 7146 normal Update timestamps when deleting a biblio 4161 enhancement When adding Vendor default to active currencies 6471 enhancement column sorter on holds queue 7128 enhancement logged in and logged out states of opac-main.tt are hard to style 7184 enhancement have mysql returning errors 7188 enhancement case-insensitive grep of /mysql/ in C4::Context System requirements ====================== Changes since 3.2: * Template::Toolkit Documentation ====================== As of Koha 3.2, the Koha manual is now maintained in DocBook. The home page for Koha documentation is http://koha-community.org/documentation/ As of the date of these release notes, only the english version of the Koha manual is available: http://koha-community.org/documentation/3-4-manual/ 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 Partial translations are available for various other languages. The Koha team welcomes additional translations; please see http://wiki.koha-community.org/wiki/Translating_Koha for information about translating Koha, and join the koha-translate list to volunteer: http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate The most up-to-date translations can be found at: http://translate.koha-community.org/ Release Team ====================== The release team for Koha 3.4 is Release Manager: Chris Cormack Documentation Manager: Nicole C Engard Translation Manager: Fr??d??ric Demians Release Maintainer (3.2.x): Chris Nighswonger Release Maintainer (3.4.x): Chris Nighswonger QA Manager: Colin Campbell Credits ====================== We thank the following individuals who contributed patches to Koha 3.4.7 (The numeral in the first column represents the number of patches included in this release): 1 Nahuel ANGELINETTI 5 Fr??d??rick Capovilla 10 Chris Cormack 2 Fr??d??ric Demians 4 Katrin Fischer 3 Owen Leonard 1 Joy Nelson 4 Chris Nighswonger 2 Maxime Pelletier 5 Paul Poulain 2 Liz Rea 1 Marcel de Rooy 1 Salvador Zaragoza Rubio 6 Ian Walls We regret any omissions. If a contributor has been inadvertantly missed, please send a patch against these release notes to koha-patches at lists.koha-community.org. Revision control notes ====================== The Koha project uses Git for version control. The current development version of Koha can be retrieved by checking out the master branch of git://git.koha-community.org/koha.git The branch for Koha 3.4.x (i.e., this version of Koha and future bugfix releases) is 3.4.x. The next major feature release of Koha will be Koha 3.6.0. Bugs and feature requests ====================== Bug reports and feature requests can be filed at the Koha bug tracker at http://bugs.koha-community.org/ Ehara taku toa i te toa takitahi, engari he toa takitini ##### Autogenerated release notes updated last on 07 Dec 2011 16:48:02 Z ##### From M.de.Rooy at rijksmuseum.nl Thu Dec 8 14:37:12 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Thu, 8 Dec 2011 13:37:12 +0000 Subject: [Koha-devel] updatedatabase Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3138055B@S-MAIL-1B.rijksmuseum.intra> Paul, Could you add \n to the recent print statements in updatedatabase? Prevents cluttered output on web installer. Thanks, Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Thu Dec 8 17:56:51 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 08 Dec 2011 17:56:51 +0100 Subject: [Koha-devel] A few patches waiting for your signature... Message-ID: <4EE0EC53.9060100@biblibre.com> Hello world, Digging into bugzilla, I see there are a few patches that have been submitted more than 3 months ago and are still waiting for someone signing it... Here is the list: 6466 hung socket read causes SIP tests to fail SIP2 2011-06-06 6098 zebra conf NSB NSE indexed as space Searchin 2011-08-01 6115 Acquisition reports : date filter & sorting don't work Reports 2011-08-05 3431 Catalog by itemtype report pulling from holdingbranch Reports 2011-08-23 6800 Koha authentication should handle proxies better Authenti 2011-09-12 6917 Acquisitions reports: Dates filters doesn't work when they are not selected on row or column Reports 2011-09-26 I'm sure Koha will thank you if you give some of them a chance to become a part of the next release ! -- 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 8 18:15:58 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 08 Dec 2011 18:15:58 +0100 Subject: [Koha-devel] Hackfest in Europe 2012 in march ! Message-ID: <4EE0F0CE.9090606@biblibre.com> Hello world, Last year, BibLibre has hosted a week of hackfest, where a lot of european people came to hack Koha. It was a very good week, so we decided to host a new one next year ! Last year, it was close to the release, maybe a little bit too close. So, for 2012 edition, it will be earlier. Last year, we had people coming from Germany, United Kingdom, Spain, Norway. So, for 2012 edition, we hope to have more countries coming. We will warmly welcome ppl from Italy, Netherland, Croatia ! (If you want to come from NZ, US, AUS, IN, or anywhere in the world you're welcomed too, but it may be more expensive...) So, ask your boss, book your flight/train, and join us *** from monday, march 19th to friday, march 23 *** As last year: * the day start by 5-10 minuts meeting to assign tasks/goals. We work in groups of 2-3 dedicated to a given task = signing-off patches, testing, translating, fixing bugs, developing features,... * we work hard, and usually have a lot of things to eat or drink * the lunch is organised by BibLibre (one day pizza, one day sushi, one day, we have vegies at BibLibre so you'll be welcomed ;-) ), we share the fee (10?/lunch last year) * We're close to the center of Marseille, there are many hotels, from very cheap to very expensive ! If you plan to come, drop a mail to kim.nguyen -at- biblibre.com ! Disclaimer: this week is made for developers, it's not the place where you can discover Koha. For this, you'll have to wait a little bit, and go to the KohaCon11, in Edinburg, in June ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From lrea at nekls.org Thu Dec 8 20:46:37 2011 From: lrea at nekls.org (Liz Rea) Date: Thu, 8 Dec 2011 13:46:37 -0600 Subject: [Koha-devel] Koha IRC Holiday Shindig Message-ID: <83DCFAE2-AE87-4171-A341-4E313E27D6C0@nekls.org> So. It's happy holiday time of year - I propose that we all get together on 22/23 December in the Koha IRC channel, maybe setup some Hangouts (or other video link) and have a jolly good time at this jolly good time of year. What do you think? lrea at nekls.org -------------- next part -------------- A non-text attachment was scrubbed... Name: email_signature.jpeg Type: image/jpeg Size: 4862 bytes Desc: not available URL: -------------- next part -------------- From chris at bigballofwax.co.nz Thu Dec 8 20:49:41 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Fri, 9 Dec 2011 08:49:41 +1300 Subject: [Koha-devel] Koha IRC Holiday Shindig In-Reply-To: <83DCFAE2-AE87-4171-A341-4E313E27D6C0@nekls.org> References: <83DCFAE2-AE87-4171-A341-4E313E27D6C0@nekls.org> Message-ID: 2011/12/9 Liz Rea : > So. It's happy holiday time of year - I propose that we all get together on 22/23 December in the Koha IRC channel, maybe setup some Hangouts (or other video link) and have a jolly good time at this jolly good time of year. > > What do you think? > I can do the 23rd NZ time Chris From magnus at enger.priv.no Thu Dec 8 21:16:52 2011 From: magnus at enger.priv.no (Magnus Enger) Date: Thu, 8 Dec 2011 21:16:52 +0100 Subject: [Koha-devel] Koha IRC Holiday Shindig In-Reply-To: <83DCFAE2-AE87-4171-A341-4E313E27D6C0@nekls.org> References: <83DCFAE2-AE87-4171-A341-4E313E27D6C0@nekls.org> Message-ID: 2011/12/8 Liz Rea : > So. It's happy holiday time of year - I propose that we all get together on 22/23 December in the Koha IRC channel, maybe setup some Hangouts (or other video link) and have a jolly good time at this jolly good time of year. > > What do you think? +1! Magnus From cnighswonger at foundations.edu Thu Dec 8 21:52:15 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 8 Dec 2011 15:52:15 -0500 Subject: [Koha-devel] 3.6.2 Release Schedule Update Message-ID: Just as a reminder to all interested parties: 3.6.2 will release on 22 Dec. 2011. This means that the 3.6.x branch will enter a string freeze on 15 Dec. 2011. Translators then have until 20 Dec. to do their work. The Translation Manager has until 21 or early 22 Dec to finish his work. Kind Regards, Chris Koha 3.4/3.6 Release Maintainer -------------- next part -------------- An HTML attachment was scrubbed... URL: From irma at calyx.net.au Thu Dec 8 23:28:52 2011 From: irma at calyx.net.au (Irma Birchall) Date: Fri, 9 Dec 2011 09:28:52 +1100 Subject: [Koha-devel] Koha IRC Holiday Shindig In-Reply-To: References: <83DCFAE2-AE87-4171-A341-4E313E27D6C0@nekls.org> Message-ID: +1 and we can enjoy some Fruit Mince Pies... :-) Irma CALYX On 9 December 2011 07:16, Magnus Enger wrote: > 2011/12/8 Liz Rea : >> So. It's happy holiday time of year - I propose that we all get together on 22/23 December in the Koha IRC channel, maybe setup some Hangouts (or other video link) and have a jolly good time at this jolly good time of year. >> >> What do you think? > > +1! > > Magnus > _______________________________________________ > 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 mjr at phonecoop.coop Fri Dec 9 01:01:41 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Fri, 09 Dec 2011 00:01:41 +0000 Subject: [Koha-devel] Koha IRC Holiday Shindig In-Reply-To: <83DCFAE2-AE87-4171-A341-4E313E27D6C0@nekls.org> Message-ID: Liz Rea > So. It's happy holiday time of year - I propose that we all get > together on 22/23 December in the Koha IRC channel, maybe setup some > Hangouts (or other video link) and have a jolly good time at this > jolly good time of year. > > What do you think? Sadly a failing company (not software.coop but one we hold shares in) has called a meeting for early on 23 Dec (5am start if I go by train!), so I may not be there, but I wish you all the best for the season. Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/ From abesottedphoenix at yahoo.com Fri Dec 9 01:32:31 2011 From: abesottedphoenix at yahoo.com (BWS Johnson) Date: Thu, 8 Dec 2011 16:32:31 -0800 (PST) Subject: [Koha-devel] Koha IRC Holiday Shindig In-Reply-To: References: <83DCFAE2-AE87-4171-A341-4E313E27D6C0@nekls.org> Message-ID: <1323390751.8223.YahooMailNeo@web114716.mail.gq1.yahoo.com> Kia ora! > 2011/12/8 Liz Rea : >> So. It's happy holiday time of year - I propose that we all get > together on 22/23 December in the Koha IRC channel, maybe setup some Hangouts > (or other video link) and have a jolly good time at this jolly good time of > year. >> >> What do you think? ??? I *would* but Marge specifically told me not to. http://gaaras-so-cool.deviantart.com/art/Simpsons-It-s-A-Box-Social-135044989 From paul.poulain at biblibre.com Fri Dec 9 09:40:31 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 09 Dec 2011 09:40:31 +0100 Subject: [Koha-devel] updatedatabase In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA3138055B@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA3138055B@S-MAIL-1B.rijksmuseum.intra> Message-ID: <4EE1C97F.50802@biblibre.com> Le 08/12/2011 14:37, Marcel de Rooy a ?crit : > Paul, > > Could you add \n to the recent print statements in updatedatabase? > > Prevents cluttered output on web installer. Done (& pushed) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From mamfab at gmail.com Thu Dec 1 16:08:10 2011 From: mamfab at gmail.com (Muhammad Abdullah) Date: Thu, 1 Dec 2011 23:08:10 +0800 Subject: [Koha-devel] [Koha] Koha Virtual Appliance 3.6 Now Available For Download Message-ID: Thanks alot for this. Been using it for awhile now, very useful appliance. This upgrade should make it more robust, now that it is running on Debian 6. On Thu, Dec 1, 2011 at 10:48 PM, Kyle Hall wrote: > Hey All, > I just wanted to let everyone know that I've updated my virtual > appliances to 3.6. This is a complete rebuild using Debian 6.0 ( > Squeeze ) instead of Lenny. I also added a bit more to the Koha > Console program for automatically fixing the networking issue that > crops up on virtual machines from time to time. Enjoy! > > http://millruntech.com/koha/koha-virtual-appliances > > Kyle > > http://www.kylehall.info > Mill Run Technology Solutions ( http://millruntech.com ) > Crawford County Federated Library System ( http://www.ccfls.org ) > Meadville Public Library ( http://www.meadvillelibrary.org ) > _______________________________________________ > Koha mailing list http://koha-community.org > Koha at lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha From adalid at tij.uia.mx Wed Dec 7 20:47:01 2011 From: adalid at tij.uia.mx (Adalid Ortiz) Date: Wed, 7 Dec 2011 11:47:01 -0800 Subject: [Koha-devel] [Koha] Improving permissions on lists (virtual shelves) Message-ID: <20111207194646.A2A54313597@mail.tij.uia.mx> Excellent but I want to add a useful feature, list categories and subcategories like in this Koha fork called "Estantes virtuales": http://biblioteca.exactas.unlp.edu.ar/cgi-bin/koha/opac-shelves.pl?startfrom=0 Saludos, Felipe Adalid Ortiz Anzaldo Bibliotecario de sistemas Universidad Iberoamericana Tijuana Biblioteca Loyola http://clavius.tij.uia.mx Ave. Centro Universitario 2501 Playas de Tijuana 22200, Tijuana, B.C. 0 664 630-1577 Ext. 623 adalid at tij.uia.mx "En una jerarqu?a, el poder lo tiene quien guarda secretos; en una red el poder lo obtiene quien disemina informaci?n?. -John Perry Barlow-> >Subject: Re: [Koha] Improving permissions on lists (virtual shelves) > From: Marcel de Rooy > Date: Wed, 7 Dec 2011 16:08:58 +0000 > To: "koha at lists.katipo.co.nz" , > "koha-devel at lists.koha-community.org" > >--===============0312935277== >Content-Language: nl-NL >Content-Type: multipart/alternative; > boundary="_000_809BE39CD64BFD4EB9036172EBCCFA3137F0B6SMAIL1Brijksmuseu_" > >--_000_809BE39CD64BFD4EB9036172EBCCFA3137F0B6SMAIL1Brijksmuseu_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Thanks all for responding to this inquiry. This was very helpful. > > > >I am merging here the results and will be posting them back to report 7310 = >or a wiki page. Feel free to correct me where I made the wrong conclusion. > > > >1 Public lists in OPAC: Currently, a user should be logged in to create a l= >ist. I would strongly recommend to keep that restriction. A new preference = >is added that allows opac users to create public lists or does not allow th= >at. > >Additionally, I would add the restriction that another opac user cannot cha= >nge the list type of a public list to private list or change the list permi= >ssions when he did not create it (currently possible); the owner can do tha= >t or a staff member with permissions in the staff client. > > > >2 Three new permissions per list: Add items, Delete own items, Delete other= > items. This makes the Open list type obsolete. > > > >3 Share private lists with another patron (as described before). Can be tur= >ned on/off with a preference. > > > >4 Staff client features: add an option under Tools to moderate inappropriat= >e list names for public lists and shared private lists. (A library is free = >to use it or not.) Add staff list permission: allow to manage lists (virtua= >l shelves). With that permission a staff member can moderate the list names= > as mentioned and access the staff Lists module. (He can change list type a= >nd permissions. He can take ownership of a public list if the owner has bee= >n deleted.) > > From paul.poulain at biblibre.com Fri Dec 9 15:13:42 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 09 Dec 2011 15:13:42 +0100 Subject: [Koha-devel] Speed improvement & T::T Message-ID: <4EE21796.6050703@biblibre.com> Hello Koha-devel, As I said during last IRC chat, I'm focusing on performance improvement those weeks. I've digged into Template::Toolkit, and here http://search.cpan.org/~abw/Template-Toolkit-2.22/lib/Template/Manual/Config.pod#Caching_and_Compiling_Options I've found 2 options that look promizing : COMPILE_EXT and COMPILE_DIR The loading of the template seems to cost 150ms, and I feel that those 2 options could be usefull to speed up the process. Did anyone already saw this option before ? Is it something worth investigating more ? Here is the documentation of the 1st option: COMPILE_EXT From cnighswonger at foundations.edu Fri Dec 9 15:23:06 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Fri, 9 Dec 2011 09:23:06 -0500 Subject: [Koha-devel] Speed improvement & T::T In-Reply-To: <4EE21796.6050703@biblibre.com> References: <4EE21796.6050703@biblibre.com> Message-ID: Nice work Paul! I think this is worth at least a try to see what improvement may be gained. I wonder if permissions will be an issue here? Kind Regards, Chris On Fri, Dec 9, 2011 at 9:13 AM, Paul Poulain wrote: > Hello Koha-devel, > > As I said during last IRC chat, I'm focusing on performance improvement > those weeks. > I've digged into Template::Toolkit, and here > > http://search.cpan.org/~abw/Template-Toolkit-2.22/lib/Template/Manual/Config.pod#Caching_and_Compiling_Options > I've found 2 options that look promizing : COMPILE_EXT and COMPILE_DIR > > The loading of the template seems to cost 150ms, and I feel that those 2 > options could be usefull to speed up the process. Did anyone already saw > this option before ? Is it something worth investigating more ? > > Here is the documentation of the 1st option: > > COMPILE_EXT > > From version 2 onwards, the Template Toolkit has the ability to compile > templates to Perl code and save them to disk for subsequent use (i.e. > cache persistence). The COMPILE_EXT option may be provided to specify a > filename extension for compiled template files. It is undefined by > default and no attempt will be made to read or write any compiled > template files. > > my $template = Template->new({ > COMPILE_EXT => '.ttc', > }); > > If COMPILE_EXT is defined (and COMPILE_DIR isn't, see below) then > compiled template files with the COMPILE_EXT extension will be written > to the same directory from which the source template files were loaded. > > Compiling and subsequent reuse of templates happens automatically > whenever the COMPILE_EXT or COMPILE_DIR options are set. The Template > Toolkit will automatically reload and reuse compiled files when it finds > them on disk. If the corresponding source file has been modified since > the compiled version as written, then it will load and re-compile the > source and write a new compiled version to disk. > > This form of cache persistence offers significant benefits in terms of > time and resources required to reload templates. Compiled templates can > be reloaded by a simple call to Perl's require(), leaving Perl to handle > all the parsing and compilation. This is a Good Thing. > -- > 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdhafen at tech.washk12.org Fri Dec 9 20:42:37 2011 From: mdhafen at tech.washk12.org (Mike Hafen) Date: Fri, 9 Dec 2011 12:42:37 -0700 Subject: [Koha-devel] Speed improvement & T::T In-Reply-To: References: <4EE21796.6050703@biblibre.com> Message-ID: Perhaps the way to overcome permissions would be to host the pre-compiled template files in git, or create them just before creating the archives for releases. 2011/12/9 Chris Nighswonger > Nice work Paul! > > I think this is worth at least a try to see what improvement may be gained. > > I wonder if permissions will be an issue here? > > Kind Regards, > Chris > > > On Fri, Dec 9, 2011 at 9:13 AM, Paul Poulain wrote: > >> Hello Koha-devel, >> >> As I said during last IRC chat, I'm focusing on performance improvement >> those weeks. >> I've digged into Template::Toolkit, and here >> >> http://search.cpan.org/~abw/Template-Toolkit-2.22/lib/Template/Manual/Config.pod#Caching_and_Compiling_Options >> I've found 2 options that look promizing : COMPILE_EXT and COMPILE_DIR >> >> The loading of the template seems to cost 150ms, and I feel that those 2 >> options could be usefull to speed up the process. Did anyone already saw >> this option before ? Is it something worth investigating more ? >> >> Here is the documentation of the 1st option: >> >> COMPILE_EXT >> >> From version 2 onwards, the Template Toolkit has the ability to compile >> templates to Perl code and save them to disk for subsequent use (i.e. >> cache persistence). The COMPILE_EXT option may be provided to specify a >> filename extension for compiled template files. It is undefined by >> default and no attempt will be made to read or write any compiled >> template files. >> >> my $template = Template->new({ >> COMPILE_EXT => '.ttc', >> }); >> >> If COMPILE_EXT is defined (and COMPILE_DIR isn't, see below) then >> compiled template files with the COMPILE_EXT extension will be written >> to the same directory from which the source template files were loaded. >> >> Compiling and subsequent reuse of templates happens automatically >> whenever the COMPILE_EXT or COMPILE_DIR options are set. The Template >> Toolkit will automatically reload and reuse compiled files when it finds >> them on disk. If the corresponding source file has been modified since >> the compiled version as written, then it will load and re-compile the >> source and write a new compiled version to disk. >> >> This form of cache persistence offers significant benefits in terms of >> time and resources required to reload templates. Compiled templates can >> be reloaded by a simple call to Perl's require(), leaving Perl to handle >> all the parsing and compilation. This is a Good Thing. >> -- >> 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/ >> > > > _______________________________________________ > 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 chris at bigballofwax.co.nz Fri Dec 9 20:52:44 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Sat, 10 Dec 2011 08:52:44 +1300 Subject: [Koha-devel] Speed improvement & T::T In-Reply-To: References: <4EE21796.6050703@biblibre.com> Message-ID: 2011/12/10 Mike Hafen : > Perhaps the way to overcome permissions would be to host the pre-compiled > template files in git, or create them just before creating the archives for > releases. > Hmm no, it doesn't work that way, Template::Toolkit will create them and use them itself, and it will use the directory you tell it to. http://template-toolkit.org/docs/manual/Config.html#section_Caching_and_Compiling_Options By default we are caching them all already, so switching on mod_perl or plack or the like will give us a big performance boost, because the cache then is more persistent. This means it will totally outperform the corresponding set up using html::template::pro But for CGI, then the compiling is useful also, so we should try switching that on. Chris From cnighswonger at foundations.edu Fri Dec 9 20:57:40 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Fri, 9 Dec 2011 14:57:40 -0500 Subject: [Koha-devel] Speed improvement & T::T In-Reply-To: References: <4EE21796.6050703@biblibre.com> Message-ID: On Fri, Dec 9, 2011 at 2:52 PM, Chris Cormack wrote: > > But for CGI, then the compiling is useful also, so we should try > switching that on. > > Perhaps the "on/off" could be set by a system preference. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at bigballofwax.co.nz Fri Dec 9 21:04:46 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Sat, 10 Dec 2011 09:04:46 +1300 Subject: [Koha-devel] Speed improvement & T::T In-Reply-To: References: <4EE21796.6050703@biblibre.com> Message-ID: On 10 December 2011 08:57, Chris Nighswonger wrote: > On Fri, Dec 9, 2011 at 2:52 PM, Chris Cormack > wrote: >> >> >> But for CGI, then the compiling is useful also, so we should try >> switching that on. >> > > Perhaps the "on/off" could be set by a system preference. > Could easily be done that way. Chris From mdhafen at tech.washk12.org Fri Dec 9 21:44:44 2011 From: mdhafen at tech.washk12.org (Mike Hafen) Date: Fri, 9 Dec 2011 13:44:44 -0700 Subject: [Koha-devel] Fwd: Speed improvement & T::T In-Reply-To: References: <4EE21796.6050703@biblibre.com> Message-ID: So it is not possible to have TT pre-compile the files? On Fri, Dec 9, 2011 at 1:04 PM, Chris Cormack wrote: > On 10 December 2011 08:57, Chris Nighswonger > wrote: > > On Fri, Dec 9, 2011 at 2:52 PM, Chris Cormack > > wrote: > >> > >> > >> But for CGI, then the compiling is useful also, so we should try > >> switching that on. > >> > > > > Perhaps the "on/off" could be set by a system preference. > > > Could easily be done that way. > > 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 nengard at gmail.com Fri Dec 9 21:49:20 2011 From: nengard at gmail.com (Nicole Engard) Date: Fri, 9 Dec 2011 15:49:20 -0500 Subject: [Koha-devel] what is the need of the tables: deletedbiblio, deletedbiblioitems, deleteditems In-Reply-To: <1322112927010-5019267.post@n5.nabble.com> References: <1322112927010-5019267.post@n5.nabble.com> Message-ID: I use these tables on a regular basis for statistics. If you want to know how many items you cataloged in a year you want an accurate count - and if you had deleted things and those tables weren't there you wouldn't be able to get an accurate count. I also see these as a way for those with the right skills to be able to restore their data - there is no tool in Koha for this, but if you know MySQL you can do it. Nicole On Thu, Nov 24, 2011 at 12:35 AM, tanzeem wrote: > what is the need of the tables: > deletedbiblio,deletedbiblioitems,deleteditems > in the koha database. > Does it have anything to do with restoring deleted biblio items.If yes then > please explain how to restore deleted values > > -- > View this message in context: > http://koha.1045719.n5.nabble.com/what-is-the-need-of-the-tables-deletedbiblio-deletedbiblioitems-deleteditems-tp5019267p5019267.html > Sent from the Koha-devel mailing list archive at Nabble.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 chris at bigballofwax.co.nz Fri Dec 9 22:47:20 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Sat, 10 Dec 2011 10:47:20 +1300 Subject: [Koha-devel] Fwd: Speed improvement & T::T In-Reply-To: References: <4EE21796.6050703@biblibre.com> Message-ID: On 10 Dec 2011 09:44, "Mike Hafen" wrote: > > So it is not possible to have TT pre-compile the files? > Yes, it will do that for you if you tell it to, what isn't practical for us to try to distribute compiled templates, because the first time someone hits a page it will compile it and use it. And we would have to do them for every language. Chris > > On Fri, Dec 9, 2011 at 1:04 PM, Chris Cormack wrote: >> >> On 10 December 2011 08:57, Chris Nighswonger >> wrote: >> > On Fri, Dec 9, 2011 at 2:52 PM, Chris Cormack >> > wrote: >> >> >> >> >> >> But for CGI, then the compiling is useful also, so we should try >> >> switching that on. >> >> >> > >> > Perhaps the "on/off" could be set by a system preference. >> > >> Could easily be done that way. >> >> 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/ > > > > > _______________________________________________ > 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 mdhafen at tech.washk12.org Fri Dec 9 23:30:25 2011 From: mdhafen at tech.washk12.org (Mike Hafen) Date: Fri, 9 Dec 2011 15:30:25 -0700 Subject: [Koha-devel] Fwd: Speed improvement & T::T In-Reply-To: References: <4EE21796.6050703@biblibre.com> Message-ID: I was just thinking about the permissions. You're right about having to do every language though, that wouldn't be practical. On Fri, Dec 9, 2011 at 2:47 PM, Chris Cormack wrote: > > On 10 Dec 2011 09:44, "Mike Hafen" wrote: > > > > So it is not possible to have TT pre-compile the files? > > > > Yes, it will do that for you if you tell it to, what isn't practical for > us to try to distribute compiled templates, because the first time someone > hits a page it will compile it and use it. And we would have to do them for > every language. > > Chris > > > > > On Fri, Dec 9, 2011 at 1:04 PM, Chris Cormack > wrote: > >> > >> On 10 December 2011 08:57, Chris Nighswonger > >> wrote: > >> > On Fri, Dec 9, 2011 at 2:52 PM, Chris Cormack < > chris at bigballofwax.co.nz> > >> > wrote: > >> >> > >> >> > >> >> But for CGI, then the compiling is useful also, so we should try > >> >> switching that on. > >> >> > >> > > >> > Perhaps the "on/off" could be set by a system preference. > >> > > >> Could easily be done that way. > >> > >> 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/ > > > > > > > > > > _______________________________________________ > > 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 tomascohen at gmail.com Sat Dec 10 01:51:53 2011 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Fri, 9 Dec 2011 21:51:53 -0300 Subject: [Koha-devel] Fwd: Speed improvement & T::T In-Reply-To: References: <4EE21796.6050703@biblibre.com> Message-ID: Why would generating them for every language be a problem? Also, why not provide a translation for every language by default? (removing the translation procedure from the install process). Regards To+ El 09/12/2011 19:30, "Mike Hafen" escribi?: > I was just thinking about the permissions. You're right about having to > do every language though, that wouldn't be practical. > > On Fri, Dec 9, 2011 at 2:47 PM, Chris Cormack wrote: > >> >> On 10 Dec 2011 09:44, "Mike Hafen" wrote: >> > >> > So it is not possible to have TT pre-compile the files? >> > >> >> Yes, it will do that for you if you tell it to, what isn't practical for >> us to try to distribute compiled templates, because the first time someone >> hits a page it will compile it and use it. And we would have to do them for >> every language. >> >> Chris >> >> > >> > On Fri, Dec 9, 2011 at 1:04 PM, Chris Cormack >> wrote: >> >> >> >> On 10 December 2011 08:57, Chris Nighswonger >> >> wrote: >> >> > On Fri, Dec 9, 2011 at 2:52 PM, Chris Cormack < >> chris at bigballofwax.co.nz> >> >> > wrote: >> >> >> >> >> >> >> >> >> But for CGI, then the compiling is useful also, so we should try >> >> >> switching that on. >> >> >> >> >> > >> >> > Perhaps the "on/off" could be set by a system preference. >> >> > >> >> Could easily be done that way. >> >> >> >> 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/ >> > >> > >> > >> > >> > _______________________________________________ >> > 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/ >> >> > > _______________________________________________ > 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 chris at bigballofwax.co.nz Sat Dec 10 03:45:27 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Sat, 10 Dec 2011 15:45:27 +1300 Subject: [Koha-devel] Fwd: Speed improvement & T::T In-Reply-To: References: <4EE21796.6050703@biblibre.com> Message-ID: On 10 Dec 2011 13:51, "Tomas Cohen Arazi" wrote: > > Why would generating them for every language be a problem? Also, why not provide a translation for every language by default? (removing the translation procedure from the install process). > I think you are misunderstanding, generating them gains us nothing except a huge tarball. TT will generate them as needed. Differing perl versions, differing TT versions, differing distributions etc will all cause a mess. Why not just let them work in the way they are designed to work. Chris > Regards > To+ > > El 09/12/2011 19:30, "Mike Hafen" escribi?: > >> I was just thinking about the permissions. You're right about having to do every language though, that wouldn't be practical. >> >> On Fri, Dec 9, 2011 at 2:47 PM, Chris Cormack wrote: >>> >>> >>> On 10 Dec 2011 09:44, "Mike Hafen" wrote: >>> > >>> > So it is not possible to have TT pre-compile the files? >>> > >>> >>> Yes, it will do that for you if you tell it to, what isn't practical for us to try to distribute compiled templates, because the first time someone hits a page it will compile it and use it. And we would have to do them for every language. >>> >>> Chris >>> >>> >>> > >>> > On Fri, Dec 9, 2011 at 1:04 PM, Chris Cormack < chris at bigballofwax.co.nz> wrote: >>> >> >>> >> On 10 December 2011 08:57, Chris Nighswonger >>> >> wrote: >>> >> > On Fri, Dec 9, 2011 at 2:52 PM, Chris Cormack < chris at bigballofwax.co.nz> >>> >> > wrote: >>> >> >> >>> >> >> >>> >> >> But for CGI, then the compiling is useful also, so we should try >>> >> >> switching that on. >>> >> >> >>> >> > >>> >> > Perhaps the "on/off" could be set by a system preference. >>> >> > >>> >> Could easily be done that way. >>> >> >>> >> 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/ >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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/ >> >> >> >> _______________________________________________ >> 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 cnighswonger at foundations.edu Sat Dec 10 12:46:24 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Sat, 10 Dec 2011 06:46:24 -0500 Subject: [Koha-devel] Fwd: Speed improvement & T::T In-Reply-To: References: <4EE21796.6050703@biblibre.com> Message-ID: 2011/12/9 Chris Cormack > I think you are misunderstanding, generating them gains us nothing except > a huge tarball. TT will generate them as needed. > > huge tarball-- > Differing perl versions, differing TT versions, differing distributions > etc will all cause a mess. Why not just let them work in the way they are > designed to work. > I agree with Chris here. If we implement this feature, we need to make it a syspref or something and leave it to the user to enable it if they like. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Mon Dec 12 09:07:47 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Mon, 12 Dec 2011 08:07:47 +0000 Subject: [Koha-devel] FW: A few patches waiting for your signature... Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31381657@S-MAIL-1B.rijksmuseum.intra> Just to mention another patch that I wrote myself ;) 6536 Z3950 Enhancements: SRU targets, MARC conversion, additional XSLT processing The functionality patch dates from June 30, but still applies. (We use it in production for 6 months now already!) The dbrev patch has been rebased last time on August 11. As you will understand, it needs rebasing constantly (updatedatabase stuff). The patch has a test plan with 12 steps on the wiki. Was hoping for two signoffs (MARC21 and UNIMARC) once ... -----Oorspronkelijk bericht----- Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Paul Poulain Verzonden: donderdag 8 december 2011 17:57 Aan: koha-devel at lists.koha-community.org Onderwerp: [Koha-devel] A few patches waiting for your signature... Hello world, Digging into bugzilla, I see there are a few patches that have been submitted more than 3 months ago and are still waiting for someone signing it... Here is the list: 6466 hung socket read causes SIP tests to fail SIP2 2011-06-06 6098 zebra conf NSB NSE indexed as space Searchin 2011-08-01 6115 Acquisition reports : date filter & sorting don't work Reports 2011-08-05 3431 Catalog by itemtype report pulling from holdingbranch Reports 2011-08-23 6800 Koha authentication should handle proxies better Authenti 2011-09-12 6917 Acquisitions reports: Dates filters doesn't work when they are not selected on row or column Reports 2011-09-26 I'm sure Koha will thank you if you give some of them a chance to become a part of the next release ! -- 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/ From M.de.Rooy at rijksmuseum.nl Mon Dec 12 14:06:17 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Mon, 12 Dec 2011 13:06:17 +0000 Subject: [Koha-devel] Bug 5636 Message-ID: <809BE39CD64BFD4EB9036172EBCCFA313817A6@S-MAIL-1B.rijksmuseum.intra> Hi all, Patch 5636 should be next in passing qa now, but these questions remained open: Style question to the community: should core pages in the staff client (like tools/cleanborrowers.pl) have both a templated page in the staff client AND a command-line presence, or should the commandline tool be a separate script in misc/? At this time, there doesn't seem to be any precedent for inclusion in the core script. Before passing this patch for QA, I'd like to get some feedback, as this may both open doors for us, as well as create additional work to create consistency of implementation for existing jobs. Please respond if you want to share your opinion on this subject. Thanks. Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From tajoli at cilea.it Mon Dec 12 14:36:52 2011 From: tajoli at cilea.it (Zeno Tajoli) Date: Mon, 12 Dec 2011 14:36:52 +0100 Subject: [Koha-devel] Bug 5636 In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA313817A6@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA313817A6@S-MAIL-1B.rijksmuseum.intra> Message-ID: <4EE60374.3030905@cilea.it> Hi all, Il 12/12/2011 14:06, Marcel de Rooy ha scritto: > Patch 5636 should be next in passing qa now, but these questions remained open: > > Style question to the community: should core pages in the staff client (like > tools/cleanborrowers.pl) have both a templated page in the staff client AND a > command-line presence, or should the commandline tool be a separate script in > misc/? My idea is yes, we can have scripts with a templated page AND a command-line presence. We need only to insert it in http://manual.koha-community.org/3.6/en/cronjobsch.html Bye Zeno Tajoli -- Dott. Zeno Tajoli tajoliAT_SPAM_no_prendiATcilea.it fax +39 02 2135520 CILEA - Consorzio Interuniversitario http://www.cilea.it/disclaimer From tomascohen at gmail.com Mon Dec 12 16:36:39 2011 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Mon, 12 Dec 2011 12:36:39 -0300 Subject: [Koha-devel] Bug 5636 In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA313817A6@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA313817A6@S-MAIL-1B.rijksmuseum.intra> Message-ID: 2011/12/12 Marcel de Rooy : > Hi all, > > > > Patch 5636 should be next in passing qa now, but these questions remained > open: > > > > Style question to the community:? should core pages in the staff client > (like > > tools/cleanborrowers.pl) have both a templated page in the staff client AND > a > command-line presence, or should the commandline tool be a separate script > in misc/? > > At this time, there doesn't seem to be any precedent for inclusion in the > core > script.? Before passing this patch for QA, I'd like to get some feedback, as > this may both open doors for us, as well as create additional work to create > consistency of implementation for existing jobs. > > > > > > Please respond if you want to share your opinion on this subject. I think functionality should be included in C4 or Koha, and exposed by both command-line tool and templated front-ends. Also, any command-line tool should honour system preferences by default, and the user be warned if using parameters others than default. Regards To+ From paul.poulain at biblibre.com Mon Dec 12 17:07:42 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 12 Dec 2011 17:07:42 +0100 Subject: [Koha-devel] Bug 5636 In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA313817A6@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA313817A6@S-MAIL-1B.rijksmuseum.intra> Message-ID: <4EE626CE.1000406@biblibre.com> Le 12/12/2011 14:06, Marcel de Rooy a ?crit : > Hi all, > Patch 5636 should be next in passing qa now, but these questions > remained open: > Style question to the community: should core pages in the staff client > (like > > tools/cleanborrowers.pl) have both a templated page in the staff client > AND a > command-line presence, or should the commandline tool be a separate > script in misc/? > At this time, there doesn't seem to be any precedent for inclusion in > the core > > script. Before passing this patch for QA, I'd like to get some feedback, as > this may both open doors for us, as well as create additional work to create > consistency of implementation for existing jobs. My comment here : if an ENH don't break any existing behaviour, do what it announces, and is consistent with existing features and code, then we must welcome any patch and don't request for an improvement of the improvement: if you want more, just do it yourself, everybody is acting on a volunteer basis ! In this case (speaking as RM here, not as owner of the company submitting the patch ;-) ), it should just be "passed QA", as it passes the 3 questions: don't break existing behaviour, do what it announces, consistent with existing feature & code. (double check if there can be a security issue !) -- 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 Mon Dec 12 17:24:04 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Mon, 12 Dec 2011 11:24:04 -0500 Subject: [Koha-devel] Bug 5636 In-Reply-To: <4EE626CE.1000406@biblibre.com> References: <809BE39CD64BFD4EB9036172EBCCFA313817A6@S-MAIL-1B.rijksmuseum.intra> <4EE626CE.1000406@biblibre.com> Message-ID: My difficulty with this patch is that it sets precedent for implementing both commandline and staff client interfaces for a single script. Up until now, that's not be the case (as far as my research has shown; counter-examples welcome). I just think we need, for consistency sake, to either make this the standard practice, or require separate cronjobs. So, I don't have any issue with the feature, but the potential shift in coding practices that the patch represents. Is the rest of the Koha developer community comfortable with having dual-purpose scripts like this? Are there are any best practices that can be cited for or against such practice? Cheers, -Ian On Mon, Dec 12, 2011 at 11:07 AM, Paul Poulain wrote: > Le 12/12/2011 14:06, Marcel de Rooy a ?crit : > > Hi all, > > Patch 5636 should be next in passing qa now, but these questions > > remained open: > > Style question to the community: should core pages in the staff client > > (like > > > > tools/cleanborrowers.pl) have both a templated page in the staff client > > AND a > > command-line presence, or should the commandline tool be a separate > > script in misc/? > > At this time, there doesn't seem to be any precedent for inclusion in > > the core > > > > script. Before passing this patch for QA, I'd like to get some > feedback, as > > this may both open doors for us, as well as create additional work to > create > > consistency of implementation for existing jobs. > > My comment here : > if an ENH don't break any existing behaviour, do what it announces, and > is consistent with existing features and code, then we must welcome any > patch and don't request for an improvement of the improvement: if you > want more, just do it yourself, everybody is acting on a volunteer basis ! > > In this case (speaking as RM here, not as owner of the company > submitting the patch ;-) ), it should just be "passed QA", as it passes > the 3 questions: don't break existing behaviour, do what it announces, > consistent with existing feature & code. (double check if there can be a > security issue !) > > -- > Paul POULAIN > http://www.biblibre.com > Expert en Logiciels Libres pour l'info-doc > Tel : (33) 4 91 81 35 08 > -- Ian Walls Lead Development Specialist ByWater Solutions ALA Midwinter Booth #2048 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 Mon Dec 12 17:31:35 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 12 Dec 2011 17:31:35 +0100 Subject: [Koha-devel] Jenkins back to unstable ! Message-ID: <4EE62C67.80401@biblibre.com> Hello (chris_c & others) Jenkins is back to unstable, because of XISBN.t test. build 562 was stable, and 563 is not, and I can't see where the problem can come from. BREAKING NEWS : (just before sending this mail) build 565 is stable again. The patch I pushed can't explain why we're stable. I'm really confused. Any idea warmly welcomed ! -- 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 Mon Dec 12 17:34:48 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 12 Dec 2011 17:34:48 +0100 Subject: [Koha-devel] Bug 5636 In-Reply-To: References: <809BE39CD64BFD4EB9036172EBCCFA313817A6@S-MAIL-1B.rijksmuseum.intra> <4EE626CE.1000406@biblibre.com> Message-ID: <4EE62D28.4010103@biblibre.com> Le 12/12/2011 17:24, Ian Walls a ?crit : > My difficulty with this patch is that it sets precedent for implementing > both commandline and staff client interfaces for a single script. Up > until now, that's not be the case (as far as my research has shown; > counter-examples welcome). I just think we need, for consistency sake, > to either make this the standard practice, or require separate cronjobs. > > So, I don't have any issue with the feature, but the potential shift in > coding practices that the patch represents. Is the rest of the Koha > developer community comfortable with having dual-purpose scripts like > this? Are there are any best practices that can be cited for or against > such practice? As I said already (on the ML iirc), there are only a very few cases where this should be relevant. So I think it's not worth spending too much time deciding if it should be a rule or not -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From nengard at gmail.com Mon Dec 12 17:55:06 2011 From: nengard at gmail.com (Nicole Engard) Date: Mon, 12 Dec 2011 11:55:06 -0500 Subject: [Koha-devel] dontmerge preference Message-ID: I need some assistance in documenting this preference: http://manual.koha-community.org/3.6/en/administration.html#dontmerge It says that the cron is required, but apparently its not: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7347 What should the manual say about the cron job? If it's not required then I can say that, but I know that it's still there so I assume it can be used and should be documented. Thanks Nicole -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcamins at cpbibliography.com Mon Dec 12 18:00:13 2011 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Mon, 12 Dec 2011 12:00:13 -0500 Subject: [Koha-devel] Bug 5636 In-Reply-To: References: <809BE39CD64BFD4EB9036172EBCCFA313817A6@S-MAIL-1B.rijksmuseum.intra> <4EE626CE.1000406@biblibre.com> Message-ID: Ian, My difficulty with this patch is that it sets precedent for implementing > both commandline and staff client interfaces for a single script. Up until > now, that's not be the case (as far as my research has shown; > counter-examples welcome). I just think we need, for consistency sake, to > either make this the standard practice, or require separate cronjobs. > > So, I don't have any issue with the feature, but the potential shift in > coding practices that the patch represents. Is the rest of the Koha > developer community comfortable with having dual-purpose scripts like > this? Are there are any best practices that can be cited for or against > such practice? > I'm not really sure why this should be an issue. Consistency is nice, but it seems to me there are very few scripts that would be usable both via server and via command line, simply because the different requirements of the two. So consistency won't be greatly impacted. The important thing is making sure that things are documented (and this script is documented, though I suppose POD would be even nicer, if someone was in the mood.). If a script can handle either option, though, I see no reason not to. Provided the bulk of the work is done in the C4 or Koha namespace, which, for this patch, is true. Regards, Jared -- Jared Camins-Esakov 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 gmc at esilibrary.com Mon Dec 12 18:07:02 2011 From: gmc at esilibrary.com (Galen Charlton) Date: Mon, 12 Dec 2011 12:07:02 -0500 Subject: [Koha-devel] Bug 5636 In-Reply-To: References: <809BE39CD64BFD4EB9036172EBCCFA313817A6@S-MAIL-1B.rijksmuseum.intra> <4EE626CE.1000406@biblibre.com> Message-ID: <4EE634B6.8020206@esilibrary.com> Hi, On 12/12/2011 11:24 AM, Ian Walls wrote: > My difficulty with this patch is that it sets precedent for implementing > both commandline and staff client interfaces for a single script. Up > until now, that's not be the case (as far as my research has shown; > counter-examples welcome). I just think we need, for consistency sake, > to either make this the standard practice, or require separate cronjobs. I think it goes beyond just consistency. Without having looked at the particular script in question, most/all command-line scripts produce output files. No big deal, right? But if the script can also run as a CGI script, keep in mind that it runs with the same privileges as the whatever user the webserver is running as. If such a script has a bug that allows it to be run by Apache *and* invoke one or more of the command-line output file options, in principle it could scribble over other files. Such an attack may be more theoretical than real, but my preference would be that if a script's logic should be accessible from the command line and the web interface, to put the logic in the API and have the CGI and CLI scripts just be thin wrappers. Regards, Galen -- Galen Charlton Director of Support and Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org From laurenthdl at alinto.com Mon Dec 12 18:11:44 2011 From: laurenthdl at alinto.com (LAURENT Henri-Damien) Date: Mon, 12 Dec 2011 18:11:44 +0100 Subject: [Koha-devel] Bug 5636 In-Reply-To: References: <809BE39CD64BFD4EB9036172EBCCFA313817A6@S-MAIL-1B.rijksmuseum.intra> <4EE626CE.1000406@biblibre.com> Message-ID: <4EE635D0.4020301@alinto.com> Le 12/12/2011 17:24, Ian Walls a ?crit : > My difficulty with this patch is that it sets precedent for implementing > both commandline and staff client interfaces for a single script. Up > until now, that's not be the case (as far as my research has shown; > counter-examples welcome). I just think we need, for consistency sake, > to either make this the standard practice, or require separate cronjobs. > > So, I don't have any issue with the feature, but the potential shift in > coding practices that the patch represents. Is the rest of the Koha > developer community comfortable with having dual-purpose scripts like > this? Are there are any best practices that can be cited for or against > such practice? > > Cheers, > > > -Ian > Hi, in my opinion, it is not "dual-purpose" script, command-line or web interface, it is the same process you want. duplicating code and editing to make the code commandline compliant would be far harder to maintain and keep synched than having the script callable via command-line and web. In my opinion, we have enough exemples of copy paste edit code in Koha, to see how un maintainable that behaviour is and to be willing to restrain from that from now on. This is my opinion. cheers -- Henri-Damien LAURENT > On Mon, Dec 12, 2011 at 11:07 AM, Paul Poulain > > wrote: > > Le 12/12/2011 14:06, Marcel de Rooy a ?crit : > > Hi all, > > Patch 5636 should be next in passing qa now, but these questions > > remained open: > > Style question to the community: should core pages in the staff > client > > (like > > > > tools/cleanborrowers.pl ) have both a > templated page in the staff client > > AND a > > command-line presence, or should the commandline tool be a separate > > script in misc/? > > At this time, there doesn't seem to be any precedent for inclusion in > > the core > > > > script. Before passing this patch for QA, I'd like to get some > feedback, as > > this may both open doors for us, as well as create additional work > to create > > consistency of implementation for existing jobs. > > My comment here : > if an ENH don't break any existing behaviour, do what it announces, and > is consistent with existing features and code, then we must welcome any > patch and don't request for an improvement of the improvement: if you > want more, just do it yourself, everybody is acting on a volunteer > basis ! > > In this case (speaking as RM here, not as owner of the company > submitting the patch ;-) ), it should just be "passed QA", as it passes > the 3 questions: don't break existing behaviour, do what it announces, > consistent with existing feature & code. (double check if there can be a > security issue !) > > -- > Paul POULAIN > http://www.biblibre.com > Expert en Logiciels Libres pour l'info-doc > Tel : (33) 4 91 81 35 08 > > > > > -- > Ian Walls > Lead Development Specialist > ByWater Solutions > ALA Midwinter Booth #2048 > Phone # (888) 900-8944 > http://bywatersolutions.com > ian.walls at bywatersolutions.com > Twitter: @sekjal > > > > _______________________________________________ > 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 chris at bigballofwax.co.nz Mon Dec 12 18:24:04 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Tue, 13 Dec 2011 06:24:04 +1300 Subject: [Koha-devel] Bug 5636 In-Reply-To: <4EE635D0.4020301@alinto.com> References: <809BE39CD64BFD4EB9036172EBCCFA313817A6@S-MAIL-1B.rijksmuseum.intra> <4EE626CE.1000406@biblibre.com> <4EE635D0.4020301@alinto.com> Message-ID: On 13 December 2011 06:11, LAURENT Henri-Damien wrote: >> > Hi, > in my opinion, it is not "dual-purpose" script, > command-line or web interface, it is the same process you want. > duplicating code and editing to make the code commandline compliant > would be far harder to maintain and keep synched than having the script > callable via command-line and web. In my opinion, we have enough > exemples of copy paste edit code in Koha, to see how un maintainable > that behaviour is and to be willing to restrain from that from now on. > This is my opinion. I agree, if code is used in more than one place it should be in a module, in fact our scripts should be as lightweight as possible and as close to simple wrappers for functionality in perl modules. So I agree that we should not copy paste code, but we should cut and paste it into modules and have the scripts use it from there. Chris From cnighswonger at foundations.edu Mon Dec 12 18:48:44 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Mon, 12 Dec 2011 12:48:44 -0500 Subject: [Koha-devel] Bug 5636 In-Reply-To: <4EE634B6.8020206@esilibrary.com> References: <809BE39CD64BFD4EB9036172EBCCFA313817A6@S-MAIL-1B.rijksmuseum.intra> <4EE626CE.1000406@biblibre.com> <4EE634B6.8020206@esilibrary.com> Message-ID: On Mon, Dec 12, 2011 at 12:07 PM, Galen Charlton wrote: > Hi, > > Such an attack may be more theoretical than real, but my preference would > be that if a script's logic should be accessible from the command line and > the web interface, to put the logic in the API and have the CGI and CLI > scripts just be thin wrappers. > I agree with this concern particularly, but also agree that scripts should be light-weight and "vanilla" as possible. So +1 for having the logic in C4 and separate scripts to call it from there. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederic at tamil.fr Mon Dec 12 19:20:42 2011 From: frederic at tamil.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_Demians?=) Date: Mon, 12 Dec 2011 19:20:42 +0100 Subject: [Koha-devel] dontmerge preference In-Reply-To: References: Message-ID: <4EE645FA.5060802@tamil.fr> > What should the manual say about the cron job? If it's not required > then I can say that, but I know that it's still there so I assume it > can be used and should be documented. Take a look at: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6094 and my comment: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6094#c26 'merge_authorities.pl -b' is still required if dontmerge=1. It is located in 'misc/migration_tools' not 'misc/cron'. From mjr at phonecoop.coop Tue Dec 13 00:05:16 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Mon, 12 Dec 2011 23:05:16 +0000 Subject: [Koha-devel] Bug 5636 In-Reply-To: Message-ID: Tomas Cohen Arazi > I think functionality should be included in C4 or Koha, and exposed by > both command-line tool and templated front-ends. Also, any > command-line tool should honour system preferences by default, and the > user be warned if using parameters others than default. I agree with this. I'd much prefer command-line tools outside the web folders. If they have logic in common, that logic should be in the modules, which should make the two interfaces pretty simple. Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/ From mjr at phonecoop.coop Tue Dec 13 00:33:44 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Mon, 12 Dec 2011 23:33:44 +0000 Subject: [Koha-devel] Bug 5636 In-Reply-To: <4EE626CE.1000406@biblibre.com> Message-ID: Paul Poulain > In this case (speaking as RM here, not as owner of the company > submitting the patch ;-) ), it should just be "passed QA", as it passes > the 3 questions: don't break existing behaviour, do what it announces, > consistent with existing feature & code. (double check if there can be a > security issue !) Consistent with existing code? What existing code implements a dual web/command-line interface? Thanks for any clarification, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/ From danielg.koha at gmail.com Wed Dec 14 21:35:51 2011 From: danielg.koha at gmail.com (Daniel Grobani) Date: Wed, 14 Dec 2011 12:35:51 -0800 Subject: [Koha-devel] Call for News for the December Newsletter Message-ID: Dear Koha Kommunitarians, I'm harvesting news for the December newsletter. Please send me by the 25th anything you think your fellow community members might like to know about. "News" can be as short as a sentence or as long as a paper. I especially encourage you to send me a line or two about what you're currently working on for publication in the gossip/society column. And if you know of a go-live not announced on the list, please be sure to let me know about it. Please note that it's not too late to send in your reports or reminiscences of KohaCon11! Happy holidays, Daniel Grobani From paul.poulain at biblibre.com Thu Dec 15 17:55:56 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 15 Dec 2011 17:55:56 +0100 Subject: [Koha-devel] adding fields in XSLT (bug 7332) Message-ID: <4EEA269C.30000@biblibre.com> Hello, The bug 7332 (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7332) add a new (242) field on the XSLT display. The question is: the XSLT does not contain all the fields we have in MARC21, so what must drive the content of XSLT ? Should we accept any patch (and have a huge XSLT at the end) ? Should we refuse any patch -except a bugfix- (and have a basic-but-enough XSLT) An Option between those 2 extreme positions ? I open the question, let me know your opinion !!! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From 5p4m at gmx.de Thu Dec 15 19:30:56 2011 From: 5p4m at gmx.de (Mirko) Date: Thu, 15 Dec 2011 19:30:56 +0100 Subject: [Koha-devel] adding fields in XSLT (bug 7332) In-Reply-To: <4EEA269C.30000@biblibre.com> References: <4EEA269C.30000@biblibre.com> Message-ID: <4EEA3CE0.3060903@gmx.de> Hello Paul, in my opinion, it would be nice to have 1) an eventually huge XSLT file. It's probably easier for most people to comment out or tweak things that are already there than to add the "extra" fields they need from scratch. 2) a "local" XSLT file that survives updates unharmed where people can put the files they tweaked to their likings (I think this was talked about while ago, I don't know if it exists already). Cheers, Mirko Paul Poulain schrieb am 15.12.2011 17:55:56 > Hello, > > The bug 7332 > (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7332) add a > new (242) field on the XSLT display. > > The question is: the XSLT does not contain all the fields we have in > MARC21, so what must drive the content of XSLT ? > Should we accept any patch (and have a huge XSLT at the end) ? > Should we refuse any patch -except a bugfix- (and have a > basic-but-enough XSLT) > An Option between those 2 extreme positions ? > > I open the question, let me know your opinion !!! From jcamins at cpbibliography.com Thu Dec 15 19:53:55 2011 From: jcamins at cpbibliography.com (Jared Camins-Esakov) Date: Thu, 15 Dec 2011 13:53:55 -0500 Subject: [Koha-devel] adding fields in XSLT (bug 7332) In-Reply-To: <4EEA3CE0.3060903@gmx.de> References: <4EEA269C.30000@biblibre.com> <4EEA3CE0.3060903@gmx.de> Message-ID: Paul, My vote will surprise no one. > in my opinion, it would be nice to have > > 1) an eventually huge XSLT file. It's probably easier for most > people to comment out or tweak things that are already there than to > add the "extra" fields they need from scratch. +1 The other option would quickly make it impossible for people who are concerned about MARC display (people like me, for example) to contribute what you call "bugfixes". I use fields most other libraries do not, so my stylesheets will diverge. Also, I would argue that not displaying as called for in bib standards *is* a bug. > > 2) a "local" XSLT file that survives updates unharmed where people > can put the files they tweaked to their likings (I think this was > talked about while ago, I don't know if it exists already). This would be nice, but at present it is not possible, and I don't think anyone is working on it. Regards, Jared -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Thu Dec 15 19:55:29 2011 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Thu, 15 Dec 2011 15:55:29 -0300 Subject: [Koha-devel] adding fields in XSLT (bug 7332) In-Reply-To: <4EEA269C.30000@biblibre.com> References: <4EEA269C.30000@biblibre.com> Message-ID: On Thu, Dec 15, 2011 at 1:55 PM, Paul Poulain wrote: > Hello, > > The bug 7332 > (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7332) add a > new (242) field on the XSLT display. > > The question is: the XSLT does not contain all the fields we have in > MARC21, so what must drive the content of XSLT ? > Should we accept any patch (and have a huge XSLT at the end) ? > Should we refuse any patch -except a bugfix- (and have a > basic-but-enough XSLT) > An Option between those 2 extreme positions ? > > I open the question, let me know your opinion !!! I think the problem here is translation maintenance and consistency. I'd go for a 'official' huge translated set of XSLT files, and provide a stripped down (good default) version set as default. Regards To+ From chrisc at catalyst.net.nz Thu Dec 15 20:14:48 2011 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Fri, 16 Dec 2011 08:14:48 +1300 Subject: [Koha-devel] adding fields in XSLT (bug 7332) In-Reply-To: References: <4EEA269C.30000@biblibre.com> <4EEA3CE0.3060903@gmx.de> Message-ID: <20111215191448.GJ10855@rorohiko.wgtn.cat-it.co.nz> * Jared Camins-Esakov (jcamins at cpbibliography.com) wrote: > Paul, > > My vote will surprise no one. > > > in my opinion, it would be nice to have > > > > 1) an eventually huge XSLT file. It's probably easier for most > > people to comment out or tweak things that are already there than to > > add the "extra" fields they need from scratch. > > +1 > > The other option would quickly make it impossible for people who are > concerned about MARC display (people like me, for example) to contribute > what you call "bugfixes". I use fields most other libraries do not, so my > stylesheets will diverge. Also, I would argue that not displaying as > called for in bib standards *is* a bug. +1 from me also I think following the standard for display (even if I think the standard is mental, it is the standard) is the way to go here. > > > > 2) a "local" XSLT file that survives updates unharmed where people > > can put the files they tweaked to their likings (I think this was > > talked about while ago, I don't know if it exists already). > > This would be nice, but at present it is not possible, and I don't think > anyone is working on it. > Not actively, but there are specs, look for something in the new year! 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 Katrin.Fischer at bsz-bw.de Thu Dec 15 20:15:38 2011 From: Katrin.Fischer at bsz-bw.de (Fischer, Katrin) Date: Thu, 15 Dec 2011 20:15:38 +0100 Subject: [Koha-devel] adding fields in XSLT (bug 7332) References: <4EEA269C.30000@biblibre.com> <4EEA3CE0.3060903@gmx.de> <20111215191448.GJ10855@rorohiko.wgtn.cat-it.co.nz> Message-ID: <028B1A54D03E7B4482CDCA4EC8F06BFD016265C6@Bodensee.bsz-bw.de> +1 from me too. The XSLT is done so that only information in your records shows up. I don't see why people would not want that. Katrin * Jared Camins-Esakov (jcamins at cpbibliography.com) wrote: > Paul, > > My vote will surprise no one. > > > in my opinion, it would be nice to have > > > > 1) an eventually huge XSLT file. It's probably easier for most > > people to comment out or tweak things that are already there than to > > add the "extra" fields they need from scratch. > > +1 > > The other option would quickly make it impossible for people who are > concerned about MARC display (people like me, for example) to contribute > what you call "bugfixes". I use fields most other libraries do not, so my > stylesheets will diverge. Also, I would argue that not displaying as > called for in bib standards *is* a bug. +1 from me also I think following the standard for display (even if I think the standard is mental, it is the standard) is the way to go here. > > > > 2) a "local" XSLT file that survives updates unharmed where people > > can put the files they tweaked to their likings (I think this was > > talked about while ago, I don't know if it exists already). > > This would be nice, but at present it is not possible, and I don't think > anyone is working on it. > Not actively, but there are specs, look for something in the new year! Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus at enger.priv.no Fri Dec 16 09:06:50 2011 From: magnus at enger.priv.no (Magnus Enger) Date: Fri, 16 Dec 2011 09:06:50 +0100 Subject: [Koha-devel] adding fields in XSLT (bug 7332) In-Reply-To: <028B1A54D03E7B4482CDCA4EC8F06BFD016265C6@Bodensee.bsz-bw.de> References: <4EEA269C.30000@biblibre.com> <4EEA3CE0.3060903@gmx.de> <20111215191448.GJ10855@rorohiko.wgtn.cat-it.co.nz> <028B1A54D03E7B4482CDCA4EC8F06BFD016265C6@Bodensee.bsz-bw.de> Message-ID: 2011/12/15 Fischer, Katrin : > +1 from me too. > > The XSLT is done so that only information in your records shows up. I don't > see why people would not want that. +1 In an ideal world I think we would have some cool graphical tool where each library could easily configure their own display by dragging tags and subfields around, set conditions, formatting etc. Well, one can dream... Best regards, Magnus Enger libriotech.no From ian.walls at bywatersolutions.com Fri Dec 16 13:42:04 2011 From: ian.walls at bywatersolutions.com (Ian Walls) Date: Fri, 16 Dec 2011 07:42:04 -0500 Subject: [Koha-devel] adding fields in XSLT (bug 7332) In-Reply-To: References: <4EEA269C.30000@biblibre.com> <4EEA3CE0.3060903@gmx.de> <20111215191448.GJ10855@rorohiko.wgtn.cat-it.co.nz> <028B1A54D03E7B4482CDCA4EC8F06BFD016265C6@Bodensee.bsz-bw.de> Message-ID: +1 to displaying all standard information on the Details page. If a library has this info in a record, but DOESN'T want it displayed, then can either remove the info, or strip the field out with JQuery. Hopefully 'sensitive' information is not being put in MARC records... I'm with Magnus on this one; a tool where the user can edit what fields are displayed in what order with what additional HTML (links and lists and spans etc), would be ideal. This is going to be particularly difficult with XSLT, because XSLT is, well, difficult. There has been a spec written to do User-Uploaded XSLT, so a library could modify and tweak the display as they need. We at ByWater weren't able to find enough folks interested in funding it, though, last time we asked, so it was shelved in favour of other projects. I'd really like to see more done with the ISBD view. As it stands, it's not terribly useful, as we've mostly moved away from cards at this point. But it's user-editable in a system preference, and can pull in MARC information and mix it with plaintext. If we used some of this code elsewhere, I think we could create a very customizable and user-friendly record display interface. Mashing that code up with the "tokens" we have in the Notices editor, and adding a little JQuery, could give us that drag/drop experience for customizing a record display. Probably not the most practical idea for immediate deployment, but making these sorts of display tweaks data-based instead of code-based will greatly easy the upgrade process for many libraries with particular information display needs. Cheers, -Ian On Fri, Dec 16, 2011 at 3:06 AM, Magnus Enger wrote: > 2011/12/15 Fischer, Katrin : > > +1 from me too. > > > > The XSLT is done so that only information in your records shows up. I > don't > > see why people would not want that. > > +1 > > In an ideal world I think we would have some cool graphical tool where > each library could easily configure their own display by dragging tags > and subfields around, set conditions, formatting etc. Well, one can > dream... > > Best regards, > Magnus Enger > libriotech.no > _______________________________________________ > 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 ALA Midwinter Booth #2048 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 Fri Dec 16 14:08:12 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 16 Dec 2011 14:08:12 +0100 Subject: [Koha-devel] Bugzilla : how to mark a file as obsolete Message-ID: <4EEB42BC.6040800@biblibre.com> Hello world, It seems that some of you have problem marking an attachment obsolete without attaching another file. I found how to do that a while ago, so, as I know, I share: * go to the bug * on the attachment line, you've 3 links: "file title/description", "Details" and "Diff". Click on Details * when you're on Details page: click on "Edit Details" (that's what is very hidden !)... Gotcha!!! I can obsolete or un-obsolete or update the comment, or add the patch flag!!! * click "submit" at the end of your patch ! (feel free to add this to the wiki if you think it's worth it) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From magnus at enger.priv.no Fri Dec 16 15:18:14 2011 From: magnus at enger.priv.no (Magnus Enger) Date: Fri, 16 Dec 2011 15:18:14 +0100 Subject: [Koha-devel] Bugzilla : how to mark a file as obsolete In-Reply-To: <4EEB42BC.6040800@biblibre.com> References: <4EEB42BC.6040800@biblibre.com> Message-ID: On 16 December 2011 14:08, Paul Poulain wrote: > (feel free to add this to the wiki if you think it's worth it) Done, and thanks! http://wiki.koha-community.org/wiki/Bugzilla#To_mark_a_patch_obsolete Best regards, Magnus Enger libriotech.no From lrea at nekls.org Fri Dec 16 17:22:27 2011 From: lrea at nekls.org (Liz Rea) Date: Fri, 16 Dec 2011 10:22:27 -0600 Subject: [Koha-devel] Bugzilla : how to mark a file as obsolete In-Reply-To: References: <4EEB42BC.6040800@biblibre.com> Message-ID: I think more likely people are forgetful - would be nice to add this to git-bz as a flag so it was "forget proof." Liz Rea lrea at nekls.org -------------- next part -------------- A non-text attachment was scrubbed... Name: email_signature.jpeg Type: image/jpeg Size: 4862 bytes Desc: not available URL: -------------- next part -------------- On Dec 16, 2011, at 8:18 AM, Magnus Enger wrote: > On 16 December 2011 14:08, Paul Poulain wrote: >> (feel free to add this to the wiki if you think it's worth it) > > Done, and thanks! > http://wiki.koha-community.org/wiki/Bugzilla#To_mark_a_patch_obsolete > > Best regards, > Magnus Enger > libriotech.no > _______________________________________________ > 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 paul.poulain at biblibre.com Fri Dec 16 17:30:24 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 16 Dec 2011 17:30:24 +0100 Subject: [Koha-devel] Bugzilla : how to mark a file as obsolete In-Reply-To: References: <4EEB42BC.6040800@biblibre.com> Message-ID: <4EEB7220.4020801@biblibre.com> Le 16/12/2011 17:22, Liz Rea a ?crit : > I think more likely people are forgetful - would be nice to add this to git-bz as a flag so it was "forget proof." ??? git bg attach -e NNNN => the -e will show you the commit, with #obsoletes NNNN at the end. Just remove the # and you'll obsolete the old patches ! Note you must be quick. If you don't do this in less than 20seconds, you'll get a nasty python error -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From lrea at nekls.org Fri Dec 16 18:23:49 2011 From: lrea at nekls.org (Liz Rea) Date: Fri, 16 Dec 2011 11:23:49 -0600 Subject: [Koha-devel] Bugzilla : how to mark a file as obsolete In-Reply-To: <4EEB7220.4020801@biblibre.com> References: <4EEB42BC.6040800@biblibre.com> <4EEB7220.4020801@biblibre.com> Message-ID: Right you are, I didn't know about that when I sent my message. So - everybody, obsolete your patches when you attach them using git bz! It's easy and fun! Liz Rea lrea at nekls.org -------------- next part -------------- A non-text attachment was scrubbed... Name: email_signature.jpeg Type: image/jpeg Size: 4862 bytes Desc: not available URL: -------------- next part -------------- On Dec 16, 2011, at 10:30 AM, Paul Poulain wrote: > Le 16/12/2011 17:22, Liz Rea a ?crit : >> I think more likely people are forgetful - would be nice to add this to git-bz as a flag so it was "forget proof." > ??? > git bg attach -e NNNN > => the -e will show you the commit, with #obsoletes NNNN at the end. > Just remove the # and you'll obsolete the old patches ! > > Note you must be quick. If you don't do this in less than 20seconds, > you'll get a nasty python error > > > -- > Paul POULAIN > http://www.biblibre.com > Expert en Logiciels Libres pour l'info-doc > Tel : (33) 4 91 81 35 08 From mjr at phonecoop.coop Fri Dec 16 19:02:47 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Fri, 16 Dec 2011 18:02:47 +0000 Subject: [Koha-devel] Bugzilla : how to mark a file as obsolete In-Reply-To: Message-ID: Liz Rea > I think more likely people are forgetful - would be nice to add this > to git-bz as a flag so it was "forget proof." It is already possible with git bz attach -e BUGNUM BRANCHPOINT which is documented on http://wiki.koha-community.org/wiki/Git_bz_configuration#Signing_off but our bugzilla does time out rather swiftly. Hope that informs, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/ From cnighswonger at foundations.edu Fri Dec 16 20:41:32 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Fri, 16 Dec 2011 14:41:32 -0500 Subject: [Koha-devel] [Koha] 3.6.1 updatedatabase.pl [was: Checkout fails] In-Reply-To: <5.2.1.1.2.20111216131422.0705abb8@localhost> References: <5.2.1.1.2.20111216092939.05e73038@localhost> <5.2.1.1.2.20111216102557.05e73038@localhost> <5.2.1.1.2.20111216131422.0705abb8@localhost> Message-ID: Moving this to the devel list.... On Fri, Dec 16, 2011 at 1:24 PM, Paul wrote: > At 12:51 PM 12/16/2011 -0500, Chris Nighswonger wrote: > >> Hi Paul, >> > [snip] > > I see no reason why the errors you posted in this thread should/would >> affect the ability to put a server into production. >> > > Hi Chris, > > They don't -- it was just programmatical curiosity on my behalf (I have > this very old-fashioned foible about trying to understand what I do.) > > I'll help feed that old-fashioned "foible" since it will hopefully encourage you to jump into the development of Koha at some point. :-) Here is an explanation I sent to another dev: I'll help feed that old-fashioned "foible" since it will hopefully encourage you to jump into the development of Koha at some point. :-) It should probably still be SOP to check for the existence of tables/columns/etc. prior to adding them. mysqldump does a similar sort of thing by default, proceeding every "CREATE TABLE" with such as this: DROP TABLE IF EXISTS `foo`; We could do something like: UNLESS ( OR ) THEN We could even add a function which could be called to do this to make it even easier to do. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Fri Dec 16 20:43:07 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Fri, 16 Dec 2011 14:43:07 -0500 Subject: [Koha-devel] [Koha] 3.6.1 updatedatabase.pl [was: Checkout fails] In-Reply-To: References: <5.2.1.1.2.20111216092939.05e73038@localhost> <5.2.1.1.2.20111216102557.05e73038@localhost> <5.2.1.1.2.20111216131422.0705abb8@localhost> Message-ID: Well, cut and paste strikes again... here it is with the missing portion.... On Fri, Dec 16, 2011 at 2:41 PM, Chris Nighswonger < cnighswonger at foundations.edu> wrote: > Moving this to the devel list.... > > > On Fri, Dec 16, 2011 at 1:24 PM, Paul wrote: > >> At 12:51 PM 12/16/2011 -0500, Chris Nighswonger wrote: >> >>> Hi Paul, >>> >> [snip] >> >> I see no reason why the errors you posted in this thread should/would >>> affect the ability to put a server into production. >>> >> >> Hi Chris, >> >> They don't -- it was just programmatical curiosity on my behalf (I have >> this very old-fashioned foible about trying to understand what I do.) >> >> > I'll help feed that old-fashioned "foible" since it will hopefully > encourage you to jump into the development of Koha at some point. :-) > > Here is an explanation I sent to another dev: > > The cause for these errors is duplicate SQL in updatedatabase.pl. Take > for example: > > > DBD::mysql::db do failed: Duplicate column name 'privacy' at > /home/koha/kohaclone/installer/data/mysql/updatedatabase.pl < > http://updatedatabase.pl> line 3997. > > This particular error is a result of the 'privacy' column being added at > line 2824: > > > http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=installer/data/mysql/updatedatabase.pl;h=0063a750980757e4b240a7cbbe1d3a24f1ad2903;hb=HEAD#l2824 > > So when we get to line 3997: > > > http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=installer/data/mysql/updatedatabase.pl;h=0063a750980757e4b240a7cbbe1d3a24f1ad2903;hb=HEAD#l3997 > > it is truly a duplicate as the error indicates. > > Without digging into all of the errors, I think this is true for most, if > not all of them. Some of this (iirc) was an attempt to fix out-of-sync > databases. If this was truly necessary, the later attempt to add a column > should have had code to check for the existence before attempting to add it. > > > > It should probably still be SOP to check for the existence of > tables/columns/etc. prior to adding them. mysqldump does a similar sort of > thing by default, proceeding every "CREATE TABLE" with such as this: > > DROP TABLE IF EXISTS `foo`; > > We could do something like: > > UNLESS (
OR ) THEN > > We could even add a function which could be called to do this to make it > even easier to do. > > Kind Regards, > Chris > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.a at aandc.org Sat Dec 17 01:09:37 2011 From: paul.a at aandc.org (Paul) Date: Fri, 16 Dec 2011 19:09:37 -0500 Subject: [Koha-devel] FIXME in biblio.pm Message-ID: <5.2.1.1.2.20111216190209.0765c7a8@stormy.ca> Good evening, First glitch with 3.06 has appeared: adding an 'item' after importing biblio via z39.50 is functional (it adds the item !!!) but the admin interface gives: Software error: Can't call method "subfield" on an undefined value at /usr/share/koha/lib/C4/Biblio.pm line 3008. Lines 3006-3008 of biblio.pm called from additem.pl: # get title of the record (to store the 10 first letters with the index) my ( $titletag, $titlesubfield ) = GetMarcFromKohaField( 'biblio.title', '' ); # FIXME: should be GetFrameworkCode($biblionumber) ?? $title = lc( $record->subfield( $titletag, $titlesubfield ) ); Before I start looking elsewhere, can someone kindly help me with the use of FIXME comments? tnx and br, Paul From cnighswonger at foundations.edu Sat Dec 17 04:12:19 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Fri, 16 Dec 2011 22:12:19 -0500 Subject: [Koha-devel] FIXME in biblio.pm In-Reply-To: <5.2.1.1.2.20111216190209.0765c7a8@stormy.ca> References: <5.2.1.1.2.20111216190209.0765c7a8@stormy.ca> Message-ID: Hi Paul, On Fri, Dec 16, 2011 at 7:09 PM, Paul wrote: > Good evening, > > First glitch with 3.06 has appeared: adding an 'item' after importing > biblio via z39.50 is functional (it adds the item !!!) but the admin > interface gives: > > Software error: > Can't call method "subfield" on an undefined value at > /usr/share/koha/lib/C4/Biblio.**pm line 3008. > > Experience has shown that this type of error usually is the result of corrupt data. > Lines 3006-3008 of biblio.pm called from additem.pl: > > # get title of the record (to store the 10 first letters with the > index) > my ( $titletag, $titlesubfield ) = GetMarcFromKohaField( > 'biblio.title', '' ); # FIXME: should be GetFrameworkCode($**biblionumber) > ?? > $title = lc( $record->subfield( $titletag, $titlesubfield ) ); > > Before I start looking elsewhere, can someone kindly help me with the use > of FIXME comments? > FIXME's are notes by devs generally flagging code which works, but could/should be factored differently, etc. This particular FIXME was added by commit 6b9b778b1bc09eeb7d6e982a6fd5420b2209a641 authored by Joe Atzberger. I've not dug into this far enough to know why he thought that GetFrameworkCode might be the better function to use here. If he sees this thread, maybe he can comment. However, I think its safe to say that the error you are experiencing is not related to this FIXME. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From cnighswonger at foundations.edu Sat Dec 17 04:16:41 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Fri, 16 Dec 2011 22:16:41 -0500 Subject: [Koha-devel] FIXME in biblio.pm In-Reply-To: References: <5.2.1.1.2.20111216190209.0765c7a8@stormy.ca> Message-ID: On Fri, Dec 16, 2011 at 10:12 PM, Chris Nighswonger < cnighswonger at foundations.edu> wrote: > Hi Paul, > > On Fri, Dec 16, 2011 at 7:09 PM, Paul wrote: > >> Lines 3006-3008 of biblio.pm called from additem.pl: >> >> # get title of the record (to store the 10 first letters with the >> index) >> my ( $titletag, $titlesubfield ) = GetMarcFromKohaField( >> 'biblio.title', '' ); # FIXME: should be GetFrameworkCode($**biblionumber) >> ?? >> $title = lc( $record->subfield( $titletag, $titlesubfield ) ); >> >> Before I start looking elsewhere, can someone kindly help me with the use >> of FIXME comments? >> > > FIXME's are notes by devs generally flagging code which works, but > could/should be factored differently, etc. > > This particular FIXME was added by commit > 6b9b778b1bc09eeb7d6e982a6fd5420b2209a641 authored by Joe Atzberger. I've > not dug into this far enough to know why he thought that GetFrameworkCode > might be the better function to use here. If he sees this thread, maybe he > can comment. However, I think its safe to say that the error you are > experiencing is not related to this FIXME. > Based on the commit message it looks like Joe was thinking that the second argument passed to GetMarcFromKohaField might should be populated with the results of GetFrameworkCode($biblionumber). In any case, it is still more likely to be corrupted data than the empty framework parameter passed to GetMarcFromKohaField that is causing your error. Kind Regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Mon Dec 19 10:00:57 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Mon, 19 Dec 2011 09:00:57 +0000 Subject: [Koha-devel] Bug 6296 - Allow authentication to Koha via PKI / x.509 certificates Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31383A32@S-MAIL-1B.rijksmuseum.intra> Hi all, This report is pending for some time now (original patch dated June 14). It still needs another signoff. If you are familiar with SSL and certs, please go ahead, test and sign off ;) Thanks, Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.de.Rooy at rijksmuseum.nl Mon Dec 19 15:23:38 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Mon, 19 Dec 2011 14:23:38 +0000 Subject: [Koha-devel] Error on test in KohaTest Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31383E27@S-MAIL-1B.rijksmuseum.intra> Hi, What am I doing wrong here? [marcel at RKM004 testclone]$ perl t/db_dependent/lib/KohaTest/AuthoritiesMarc.pm Invalid CODE attribute: Test( 1 ) at t/db_dependent/lib/KohaTest/AuthoritiesMarc.pm line 39 BEGIN failed--compilation aborted at t/db_dependent/lib/KohaTest/AuthoritiesMarc.pm line 39. [marcel at RKM004 testclone]$ perl t/db_dependent/lib/KohaTest/Search.pm Invalid CODE attribute: Test( 1 ) at t/db_dependent/lib/KohaTest/Search.pm line 35 BEGIN failed--compilation aborted at t/db_dependent/lib/KohaTest/Search.pm line 35. Lines concerned look like: sub methods : Test( 1 ) { ... } Thx, Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmonk at envisionware.com Tue Dec 20 06:23:47 2011 From: mmonk at envisionware.com (Mike Monk) Date: Tue, 20 Dec 2011 00:23:47 -0500 Subject: [Koha-devel] Question about behavior of SIP AF Screen Message information Message-ID: Our Company provides self service software and related products for libraries. We are working with a customer where an unusual situation has occurred and need to understand whether the environment is representative of Koha typical behavior, a problem with a particular release or unique to this customer because it is not something we have seen with other systems nor have any of our Koha users reported problems. We are attempting to help this Koha customer solve a problem. The protocol document describes the use of the screen message (AF) field as text for display to a borrower, typically informative information related to blocks or other reasons why a patron cannot circulate an item. We use AF information to set rules for access to computers and of course for self check out and we display the contents of the AF field to the borrower. Often the text in AF is consistent for given conditions so that the contents are predictable. In this customer's environment there are unique, manually created one-off messages that are obviously intended to be seen only by staff (circulation type information that is not appropriate for a patron to see) embedded in some very lengthy AF fields in the SIP response. It appears that the field is continuously appended with patron-facing and staff-facing text, making the strings quite long and unpredictable. Any insight into this will be appreciated. Thanks Mike Monk EnvisionWare, Inc. From chrisc at catalyst.net.nz Tue Dec 20 07:47:40 2011 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Tue, 20 Dec 2011 19:47:40 +1300 Subject: [Koha-devel] Question about behavior of SIP AF Screen Message information In-Reply-To: References: Message-ID: <20111220064740.GN10855@rorohiko.wgtn.cat-it.co.nz> * Mike Monk (mmonk at envisionware.com) wrote: Hi Mike > Our Company provides > self service software and related products for libraries. We are > working with a customer where an unusual situation has occurred and > need to understand whether the environment is representative of Koha > typical behavior, a problem with a particular release or unique to > this customer because it is not something we have seen with other > systems nor have any of our Koha users reported problems. We are >attempting to help this Koha customer solve a problem. What version of Koha are they running? > The protocol document describes the use of the screen message (AF) > field as text for display to a borrower, typically informative > information related to blocks or other reasons why a patron cannot > circulate an item. We use AF information to set rules for access to > computers and of course for self check out and we display the contents > of the AF field to the borrower. Often the text in AF is consistent > for given conditions so that the contents are predictable. > > In this customer's environment there are unique, manually created > one-off messages that are obviously intended to be seen only by staff > (circulation type information that is not appropriate for a patron to > see) embedded in some very lengthy AF fields in the SIP response. It > appears that the field is continuously appended with patron-facing and > staff-facing text, making the strings quite long and unpredictable. > Do you know how they are creating these messages and what field they are storing them in, in Koha? Chris > Any insight into this will be appreciated. > > Thanks > > Mike _______________________________________________ > 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 oleonard at myacpl.org Thu Dec 22 00:32:51 2011 From: oleonard at myacpl.org (Owen Leonard) Date: Wed, 21 Dec 2011 18:32:51 -0500 Subject: [Koha-devel] Quoting table column names (was Re: [Koha-patches] [PATCH] bug_5786: moved AllowOnShelfHolds to circ matrix (issuingrules)) Message-ID: On Wed, Dec 21, 2011 at 9:22 AM, Marc Balmer wrote: > Please stop putting column names in backquotes, it is a MySQLism and hinders my efforts to run Koha on PostgreSQL, I thought this was an issue that should be raised on the devel list. Is this something for which a best practice has already been established? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org From chris at bigballofwax.co.nz Thu Dec 22 02:27:08 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Thu, 22 Dec 2011 14:27:08 +1300 Subject: [Koha-devel] Error on test in KohaTest In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA31383E27@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA31383E27@S-MAIL-1B.rijksmuseum.intra> Message-ID: 2011/12/20 Marcel de Rooy : > Hi, > > > > What am I doing wrong here? > > > > [marcel at RKM004 testclone]$ perl > t/db_dependent/lib/KohaTest/AuthoritiesMarc.pm > > Invalid CODE attribute: Test( 1 ) at > t/db_dependent/lib/KohaTest/AuthoritiesMarc.pm line 39 > > BEGIN failed--compilation aborted at > t/db_dependent/lib/KohaTest/AuthoritiesMarc.pm line 39. > > > > [marcel at RKM004 testclone]$ perl t/db_dependent/lib/KohaTest/Search.pm > > Invalid CODE attribute: Test( 1 ) at t/db_dependent/lib/KohaTest/Search.pm > line 35 > > BEGIN failed--compilation aborted at t/db_dependent/lib/KohaTest/Search.pm > line 35. > > > The tests in that dir are not designed to be run that way, in fact we should probably just remove them. The real tests for those files are t/db_dependent/Search.t and t/AuthoritiesMarc_MARC21.t t/AuthoritiesMarc.t t/AuthoritiesMarc_UNIMARC.t Chris From marc at msys.ch Thu Dec 22 08:11:47 2011 From: marc at msys.ch (Marc Balmer) Date: Thu, 22 Dec 2011 08:11:47 +0100 Subject: [Koha-devel] Quoting table column names (was Re: [Koha-patches] [PATCH] bug_5786: moved AllowOnShelfHolds to circ matrix (issuingrules)) In-Reply-To: References: Message-ID: <4EF2D833.3080203@msys.ch> Am 22.12.11 00:32, schrieb Owen Leonard: > On Wed, Dec 21, 2011 at 9:22 AM, Marc Balmer wrote: >> Please stop putting column names in backquotes, it is a MySQLism and hinders my efforts to run Koha on PostgreSQL, > > I thought this was an issue that should be raised on the devel list. Good idea. > Is this something for which a best practice has already been > established? I think common sense should be enough ;) There is just no point in using MySQL-only idioms when with little or no effort the code can run onPostgreSQL as well. So it is not understandable why someone would write insert into `atable` (a) values (42) which chokes on PostgreSQL (and maybe isn't even proper SQL), when insert into atable (a) values (42) runs on both MySQL and PostgreSQL. There is already some minimal PostgreSQL support in Koha and I am actively working on a branch that should bring full PostgreSQL support eventually. It would help these efforts (and I am sure I am not the only one wanting to run on PostgreSQL) if MySQLisms would be kept at a minimum. - mb From M.de.Rooy at rijksmuseum.nl Thu Dec 22 08:47:39 2011 From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy) Date: Thu, 22 Dec 2011 07:47:39 +0000 Subject: [Koha-devel] Error on test in KohaTest In-Reply-To: References: <809BE39CD64BFD4EB9036172EBCCFA31383E27@S-MAIL-1B.rijksmuseum.intra> Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3139DC2B@S-MAIL-1B.rijksmuseum.intra> Thanks, but how should they be run then? > -----Oorspronkelijk bericht----- > Van: Chris Cormack [mailto:chris at bigballofwax.co.nz] > Verzonden: donderdag 22 december 2011 02:27 > Aan: Marcel de Rooy > CC: koha-devel at lists.koha-community.org > Onderwerp: Re: [Koha-devel] Error on test in KohaTest > > 2011/12/20 Marcel de Rooy : > > Hi, > > > > > > > > What am I doing wrong here? > > > > > > > > [marcel at RKM004 testclone]$ perl > > t/db_dependent/lib/KohaTest/AuthoritiesMarc.pm > > > > Invalid CODE attribute: Test( 1 ) at > > t/db_dependent/lib/KohaTest/AuthoritiesMarc.pm line 39 > > > > BEGIN failed--compilation aborted at > > t/db_dependent/lib/KohaTest/AuthoritiesMarc.pm line 39. > > > > > > > > [marcel at RKM004 testclone]$ perl t/db_dependent/lib/KohaTest/Search.pm > > > > Invalid CODE attribute: Test( 1 ) at t/db_dependent/lib/KohaTest/Search.pm > > line 35 > > > > BEGIN failed--compilation aborted at t/db_dependent/lib/KohaTest/Search.pm > > line 35. > > > > > > > The tests in that dir are not designed to be run that way, in fact we > should probably just remove them. > > The real tests for those files are > t/db_dependent/Search.t > and > t/AuthoritiesMarc_MARC21.t > t/AuthoritiesMarc.t > t/AuthoritiesMarc_UNIMARC.t > > Chris From chris at bigballofwax.co.nz Thu Dec 22 11:16:29 2011 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Thu, 22 Dec 2011 23:16:29 +1300 Subject: [Koha-devel] Error on test in KohaTest In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA3139DC2B@S-MAIL-1B.rijksmuseum.intra> References: <809BE39CD64BFD4EB9036172EBCCFA31383E27@S-MAIL-1B.rijksmuseum.intra> <809BE39CD64BFD4EB9036172EBCCFA3139DC2B@S-MAIL-1B.rijksmuseum.intra> Message-ID: They shouldn't be anymore, they dont work. Use the .t ones Chris On 22 Dec 2011 20:47, "Marcel de Rooy" wrote: > Thanks, but how should they be run then? > > > -----Oorspronkelijk bericht----- > > Van: Chris Cormack [mailto:chris at bigballofwax.co.nz] > > Verzonden: donderdag 22 december 2011 02:27 > > Aan: Marcel de Rooy > > CC: koha-devel at lists.koha-community.org > > Onderwerp: Re: [Koha-devel] Error on test in KohaTest > > > > 2011/12/20 Marcel de Rooy : > > > Hi, > > > > > > > > > > > > What am I doing wrong here? > > > > > > > > > > > > [marcel at RKM004 testclone]$ perl > > > t/db_dependent/lib/KohaTest/AuthoritiesMarc.pm > > > > > > Invalid CODE attribute: Test( 1 ) at > > > t/db_dependent/lib/KohaTest/AuthoritiesMarc.pm line 39 > > > > > > BEGIN failed--compilation aborted at > > > t/db_dependent/lib/KohaTest/AuthoritiesMarc.pm line 39. > > > > > > > > > > > > [marcel at RKM004 testclone]$ perl t/db_dependent/lib/KohaTest/Search.pm > > > > > > Invalid CODE attribute: Test( 1 ) at > t/db_dependent/lib/KohaTest/Search.pm > > > line 35 > > > > > > BEGIN failed--compilation aborted at > t/db_dependent/lib/KohaTest/Search.pm > > > line 35. > > > > > > > > > > > The tests in that dir are not designed to be run that way, in fact we > > should probably just remove them. > > > > The real tests for those files are > > t/db_dependent/Search.t > > and > > t/AuthoritiesMarc_MARC21.t > > t/AuthoritiesMarc.t > > t/AuthoritiesMarc_UNIMARC.t > > > > Chris > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmonk at envisionware.com Thu Dec 22 19:13:06 2011 From: mmonk at envisionware.com (Mike Monk) Date: Thu, 22 Dec 2011 13:13:06 -0500 Subject: [Koha-devel] Question about behavior of SIP AF Screen Message information In-Reply-To: <20111220064740.GN10855@rorohiko.wgtn.cat-it.co.nz> References: <20111220064740.GN10855@rorohiko.wgtn.cat-it.co.nz> Message-ID: <0CCBB4EE-CAA1-4616-8E53-D7C37752B493@envisionware.com> Chris Thank you for your response. The version is 3.01.00.032 The user is typing information into two fields on the Modify Patron Screen Under the Library set-up section, there are fields for Registration Date, Expiry Date, OPAC Note and Circulation Note. In Circulation Note there is text that says: MESSAGES: This is a test....... My understanding is that the library wants these 'Circulation Notes' to be visible to staff on the staff circ screen during check out. These notes contain information that is not suitable for patrons. These messages are displaying to patrons because they are delivered via the AF field in SIP. So on a self service station the text displays as follows: "Greetings from Koha." In some cases the combined strings are 3-4 times the 'typical' length of a 64. Mike On Dec 20, 2011, at 1:47 AM, Chris Cormack wrote: > * Mike Monk (mmonk at envisionware.com) wrote: > > Hi Mike > >> Our Company provides >> self service software and related products for libraries. We are >> working with a customer where an unusual situation has occurred and >> need to understand whether the environment is representative of Koha >> typical behavior, a problem with a particular release or unique to >> this customer because it is not something we have seen with other >> systems nor have any of our Koha users reported problems. We are >> attempting to help this Koha customer solve a problem. > > What version of Koha are they running? > >> The protocol document describes the use of the screen message (AF) >> field as text for display to a borrower, typically informative >> information related to blocks or other reasons why a patron cannot >> circulate an item. We use AF information to set rules for access to >> computers and of course for self check out and we display the contents >> of the AF field to the borrower. Often the text in AF is consistent >> for given conditions so that the contents are predictable. >> >> In this customer's environment there are unique, manually created >> one-off messages that are obviously intended to be seen only by staff >> (circulation type information that is not appropriate for a patron to >> see) embedded in some very lengthy AF fields in the SIP response. It >> appears that the field is continuously appended with patron-facing and >> staff-facing text, making the strings quite long and unpredictable. >> > Do you know how they are creating these messages and what field they > are storing them in, in Koha? > > Chris > >> Any insight into this will be appreciated. >> >> Thanks >> >> Mike > > _______________________________________________ > 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 From cnighswonger at foundations.edu Fri Dec 23 00:24:48 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Thu, 22 Dec 2011 18:24:48 -0500 Subject: [Koha-devel] Koha 3.6.2 is now available Message-ID: It is with pleasure that I announce the release of Koha 3.6.2. The package can be retrieved from: http://download.koha-community.org/koha-3.06.02.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.06.02.tar.gz.MD5 http://download.koha-community.org/koha-3.06.02.tar.gz.MD5.asc http://download.koha-community.org/koha-3.06.02.tar.gz.sig Release notes for 3.6.2 are below the fold. Come and get it! RELEASE NOTES FOR KOHA 3.6.2 22 Dec 2011 ======================================================================== Koha is the first free and open source software library automation package (ILS). Development is sponsored by libraries of varying types and sizes, volunteers, and support companies from around the world. The website for the Koha project is http://koha-community.org/ Koha 3.6.2 can be downloaded from: http://download.koha-community.org/koha-3.06.02.tar.gz Installation instructions can be found at: http://wiki.koha-community.org/wiki/Installation_Documentation OR in the INSTALL files that come in the tarball Koha 3.6.2 is a bugfix/maintenance release. Highlights of 3.6.2 ====================== 7285 blocker ILSDI service AuthenticatePatron doesn't work 6740 critical can add items at ordering but not remove items 6786 critical False detection of index names in Search; make index names case insensitive 6893 critical Order from suggestion does not remove suggestion from 'accepted' list 7093 critical Placeholders for suggestion table in suggestion related mails broken 7160 critical paying fines throws error 7316 critical Missing escaping in search results 5211 major marking lost (long overdue) not charging fines 6022 major Auth_with_ldap check if categorycode is valid 6530 major item due notice label saying 'unknown' 7202 major z39.50 search on bib edit not working 7250 major stage_biblios_file.pl is missing options for encodings, wrongly passing the MARC flavour instead 7275 major Pagination lost when click in the option "Show more" of facets column Bugs fixed in 3.6.2 ====================== 2346 normal consolidate duplicate methods C4::Overdues::UpdateBorrowerDebarred and C4::Members::DebarMember 4330 normal Copyright statements out of date 5604 normal additional icons for the Seshat set 5974 normal Bogus auth check for "StaffMember" role 6291 normal Cart printing truncated in Firefox 6877 normal test for Libravatar::URL can cause scripts to abort 6894 normal Default currency on Acquisitions suggestion form 6917 normal Acquisitions reports: Dates filters doesn't work when they are not selected on row or column 6926 normal overdue_notices don't send itemcount to notification 6966 normal Update Help Files for Koha 3.6 Release 6997 normal koha-remove leaves system in inconsistent state if there is an error 7028 normal koha-conf.xml template that comes with the packages needs updating 7105 normal Bad sql request in GetSubscriptions 7108 normal Lists of "Similar" languages break display across multiple lines in both Opac and Intranet 7120 normal After deleting order from order receive page redirect fails 7124 normal Back to search wrapping in lower resolutions 7141 normal The biblio details page in the intranet doesn't work if XSLT is activated and the xsl file contains " " 7198 normal overdue report does not display patron name if firstname and/or surname are null 7215 normal callnumber versus itemcallnumber 7216 normal koha-restore doesn't set HOME 7245 normal Errors in MySQL tables population with mandatory data for italian installation 7251 normal Fields are separated by "t" when the delimiter preference is set to "tabulation" in overdue_notices.pl 7254 normal Show pending orders from baskets with closedate > 180 days 7262 normal No calendar present in holidays module when there are quotes in title or description 7268 normal Templates failing translation tests 7280 normal Can't place hold without selecting on list 7287 normal overdue notification is processed several times if some sites do not have rules 2011 enhancement Link patron extra sort fields to authorized values 3385 enhancement Add checkout date and renewal date to display list of checked out items 4051 enhancement add columns to overdues export 4877 enhancement Create and update the manual pages for the koha-* scripts. 5327 enhancement Unit tests required for all C4 modules 6303 enhancement Display Organisation and Parent Organisation names when viewing a borrower of type organisation 6663 enhancement would be nice to put ranges of dates in the calendar 6716 enhancement Database Documentation 6818 enhancement acquisitions basket groups could use some design work 6865 enhancement Replace image-based gradient backgrounds with CSS3 gradients 7008 enhancement Sometimes zebra needs a tmp directory that it doesn't create itself 7041 enhancement Sort >1000 search results with sortmax parameter in zebra config file 7073 enhancement GetCOinSBiblio should take $record, not $biblionumber 7091 enhancement Patches required to make the packages know about the 3.6 release 7135 enhancement in addbiblio, make save button floating to have it on always on screen 7139 enhancement Log circulation messags 7143 enhancement Bug for tracking changes to the about page 7159 enhancement Add branchcode to circulation.pl search 7164 enhancement add Koha history timeline tab to 'About' page 7197 enhancement ES translation of the Debian readme 7259 enhancement Show a count of items pending approval on staff client home and tools pages 7309 enhancement Add NORMARCslim2intranetDetail.xsl for detail view in intranet System requirements ====================== Changes since 3.4: * Perl 5.10 is required Documentation ====================== As of Koha 3.2, the Koha manual is now maintained in DocBook. The home page for Koha documentation is http://koha-community.org/documentation/ As of the date of these release notes, only the English version of the Koha manual is available: http://manual.koha-community.org/3.6/en/ The Git repository for the Koha manual can be found at http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary Translations ====================== Complete or near-complete translations of the OPAC and staff interface are available in this release for the following languages: * Chinese (Taiwan) * Danish * English (USA) * English (UK) * French (France) * German * Italian * Portuguese (Brazil) * Spanish Partial translations are available for various other languages. The Koha team welcomes additional translations; please see http://wiki.koha-community.org/wiki/Translating_Koha for information about translating Koha, and join the koha-translate list to volunteer: http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate The most up-to-date translations can be found at: http://translate.koha-community.org/ Release Team ====================== The release team for Koha 3.6 is Release Manager: Chris Cormack Documentation Manager: Nicole C Engard Translation Manager: Fr?d?ric Demians QA Manager: Ian Walls Bug Wranglers: MJ Ray, Marcel de Rooy, Paul Poulain, Mason James Release Maintainer (3.4.x): Chris Nighswonger Release Maintainer (3.6.x): Chris Nighswonger Credits ====================== We thank the following libraries who are known to have sponsored new features in Koha 3.6: * Los Gatos Public Library * NEKLS * East Brunswick Public Library * Athens County Public Libraries * Horowhenua Library Trust * Halton Borough Council * South Taranaki District Council We thank the following individuals who contributed patches to Koha 3.6.2. 1 Jon Aker 2 Alex Arnaud 1 Greg Barniskis 3 Brendan 3 Jared Camins-Esakov 3 Colin Campbell 2 Fr?d?rick Capovilla 1 Galen Charlton 16 Chris Cormack 2 Christophe Croullebois 3 Fr?d?ric Demians 7 Nicole Engard 2 Magnus Enger 8 Katrin Fischer 2 Chris Hall 2 Mason James 2 Srdjan Jankovic 1 Henri-Damien Laurent 18 Owen Leonard 1 Fr?re S?bastien Marie 1 Sophie Meynieux 15 Chris Nighswonger 1 Albert Oller 1 Dobrica Pavlinusic 1 Maxime Pelletier 15 Paul Poulain 2 Liz Rea 2 Martin Renvoize 6 Marcel de Rooy 2 Adrien Saurat 5 Robin Sheat 2 Juan Sieira 4 Ian Walls We regret any omissions. If a contributor has been inadvertantly missed, please send a patch against these release notes to koha-patches at lists.koha-community.org. Revision control notes ====================== The Koha project uses Git for version control. The current development version of Koha can be retrieved by checking out the master branch of git://git.koha-community.org/koha.git The branch for Koha 3.6.x (i.e., this version of Koha and future bugfix releases) is 3.6.x. The next major feature release of Koha will be Koha 3.8.0. Bugs and feature requests ====================== Bug reports and feature requests can be filed at the Koha bug tracker at http://bugs.koha-community.org/ Ehara taku toa i te toa takitahi, engari he toa takitini ##### Autogenerated release notes updated last on 22 Dec 2011 22:53:23 Z ##### From cnighswonger at foundations.edu Mon Dec 26 03:02:27 2011 From: cnighswonger at foundations.edu (Chris Nighswonger) Date: Sun, 25 Dec 2011 21:02:27 -0500 Subject: [Koha-devel] 3.4.8 Release Timeline Update Message-ID: Hello all, I will be away for the next week for holidays. In light of that, the 3.4.x branch will enter a string freeze on 8 Jan 2012 00:00 UTC. The 3.4.8 release will be on 14 January 2012. Kind Regards, Chris From paul.poulain at biblibre.com Mon Dec 26 18:16:09 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Mon, 26 Dec 2011 18:16:09 +0100 Subject: [Koha-devel] mailman mailing lists hosting Message-ID: <4EF8ABD9.2040903@biblibre.com> Hello & merry christmas, our contract with the provider that hosts the mailing lists (and also mails, DNS, and some other important things) will end on february 18th. We won't renew it for various reasons. So there are two options: * we move the mailing lists to a new server (a virtual one). * someone else want to host those mailing lists. To speak frankly, we (BibLibre) don't manage mailman for anything outside from koha mailing lists. So we are not experts in mailman, so if someone want to do it, we will be happy to switch. If no-one want to take the ball, we will continue on a new server, don't worry. So, the question: is there any volunteer ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From indradg at gmail.com Mon Dec 26 18:29:50 2011 From: indradg at gmail.com (Indranil Das Gupta) Date: Mon, 26 Dec 2011 22:59:50 +0530 Subject: [Koha-devel] mailman mailing lists hosting In-Reply-To: <4EF8ABD9.2040903@biblibre.com> References: <4EF8ABD9.2040903@biblibre.com> Message-ID: Hi all, On Mon, Dec 26, 2011 at 10:46 PM, Paul Poulain wrote: To speak frankly, we (BibLibre) don't manage mailman for anything > outside from koha mailing lists. So we are not experts in mailman, so if > someone want to do it, we will be happy to switch. > If no-one want to take the ball, we will continue on a new server, don't > worry. > > So, the question: is there any volunteer ? > Would be happy to volunteer hosting the mailing lists using Mailman and taking care of them, if it is really needed :) cheers -idg -- Indranil Das Gupta Phone : +91-98300-20971 Blog : http://indradg.randomink.org/blog IRC : indradg on irc://irc.freenode.net Twitter : indradg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=- Please exchange editable Office documents only in ODF Format. No other format is acceptable. Support Open Standards. For a free editor supporting ODF, please visit LibreOffice - http://www.documentfoundation.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Tue Dec 27 15:57:36 2011 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Tue, 27 Dec 2011 11:57:36 -0300 Subject: [Koha-devel] mailman mailing lists hosting In-Reply-To: <4EF8ABD9.2040903@biblibre.com> References: <4EF8ABD9.2040903@biblibre.com> Message-ID: On Mon, Dec 26, 2011 at 2:16 PM, Paul Poulain wrote: > Hello & merry christmas, > > our contract with the provider that hosts the mailing lists (and also > mails, DNS, and some other important things) will end on february 18th. > We won't renew it for various reasons. > > So there are two options: > * we move the mailing lists to a new server (a virtual one). > * someone else want to host those mailing lists. > > To speak frankly, we (BibLibre) don't manage mailman for anything > outside from koha mailing lists. So we are not experts in mailman, so if > someone want to do it, we will be happy to switch. > If no-one want to take the ball, we will continue on a new server, don't > worry. > > So, the question: is there any volunteer ? Is there any integration with git that needs to be kept in mind? To+ From gmc at esilibrary.com Tue Dec 27 15:57:36 2011 From: gmc at esilibrary.com (Galen Charlton) Date: Tue, 27 Dec 2011 09:57:36 -0500 Subject: [Koha-devel] mailman mailing lists hosting In-Reply-To: References: <4EF8ABD9.2040903@biblibre.com> Message-ID: <4EF9DCE0.6070404@esilibrary.com> Hi, On 12/27/2011 09:57 AM, Tomas Cohen Arazi wrote: > Is there any integration with git that needs to be kept in mind? Not as such except for being an item to check after the transition. As long as the subscriptions are transferred over to the new host, the automatic emails from Git to koha-patches should just continue to work. Regards, Galen -- Galen Charlton Director of Support and Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org From gmc at esilibrary.com Tue Dec 27 16:01:12 2011 From: gmc at esilibrary.com (Galen Charlton) Date: Tue, 27 Dec 2011 10:01:12 -0500 Subject: [Koha-devel] mailman mailing lists hosting In-Reply-To: References: <4EF8ABD9.2040903@biblibre.com> Message-ID: <4EF9DDB8.3050804@esilibrary.com> Hi Indranil, On 12/26/2011 12:29 PM, Indranil Das Gupta wrote: > Would be happy to volunteer hosting the mailing lists using Mailman and > taking care of them, if it is really needed :) +1. If you want any help with the hosting or transition, we run a bunch of Mailman lists at Equinox and would be happy to lend a hand. Regards, Galen -- Galen Charlton Director of Support and Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org From paul.poulain at biblibre.com Tue Dec 27 16:26:11 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 27 Dec 2011 16:26:11 +0100 Subject: [Koha-devel] mailman mailing lists hosting In-Reply-To: <4EF9DCE0.6070404@esilibrary.com> References: <4EF8ABD9.2040903@biblibre.com> <4EF9DCE0.6070404@esilibrary.com> Message-ID: <4EF9E393.2030603@biblibre.com> Le 27/12/2011 15:57, Galen Charlton a ?crit : > Hi, > > On 12/27/2011 09:57 AM, Tomas Cohen Arazi wrote: >> Is there any integration with git that needs to be kept in mind? > > Not as such except for being an item to check after the transition. As > long as the subscriptions are transferred over to the new host, the > automatic emails from Git to koha-patches should just continue to work. The only tricky part here is to also move mailman history and, during the transition, accept to loose a few messages for history or some failure for ppl with poor DNS Here could be the timing: T0 = transfer the subscriber list & the history T+10mn = retrieve subscriber list & history on new server T+20mn = stop mailman on BibLibre server, switch DNS then, all ppl trying to use mailman service will either: * have a failure (ie: their DNS is not updated) * succeed (ie: their DNS is uptodate) If we do that on a friday, that should ease things a lot ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From gmc at esilibrary.com Tue Dec 27 16:29:09 2011 From: gmc at esilibrary.com (Galen Charlton) Date: Tue, 27 Dec 2011 10:29:09 -0500 Subject: [Koha-devel] mailman mailing lists hosting In-Reply-To: <4EF9E393.2030603@biblibre.com> References: <4EF8ABD9.2040903@biblibre.com> <4EF9DCE0.6070404@esilibrary.com> <4EF9E393.2030603@biblibre.com> Message-ID: <4EF9E445.8080701@esilibrary.com> Hi, On 12/27/2011 10:26 AM, Paul Poulain wrote: > Here could be the timing: > > T0 = transfer the subscriber list& the history > T+10mn = retrieve subscriber list& history on new server > T+20mn = stop mailman on BibLibre server, switch DNS > > then, all ppl trying to use mailman service will either: > * have a failure (ie: their DNS is not updated) > * succeed (ie: their DNS is uptodate) > > If we do that on a friday, that should ease things a lot ! And if it's done this Friday in particular, I think we can expect even less chance of disrupting any messages. Regards, Galen -- Galen Charlton Director of Support and Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org From paul.poulain at biblibre.com Tue Dec 27 16:45:17 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 27 Dec 2011 16:45:17 +0100 Subject: [Koha-devel] mailman mailing lists hosting In-Reply-To: <4EF9E445.8080701@esilibrary.com> References: <4EF8ABD9.2040903@biblibre.com> <4EF9DCE0.6070404@esilibrary.com> <4EF9E393.2030603@biblibre.com> <4EF9E445.8080701@esilibrary.com> Message-ID: <4EF9E80D.4040206@biblibre.com> Le 27/12/2011 16:29, Galen Charlton a ?crit : > Hi, >> If we do that on a friday, that should ease things a lot ! > > And if it's done this Friday in particular, I think we can expect even > less chance of disrupting any messages. Indra, do you think it could be possible by the end of THIS week for you? (not sure it could be for us) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From gmc at esilibrary.com Tue Dec 27 16:46:53 2011 From: gmc at esilibrary.com (Galen Charlton) Date: Tue, 27 Dec 2011 10:46:53 -0500 Subject: [Koha-devel] mailman mailing lists hosting In-Reply-To: <4EF9E80D.4040206@biblibre.com> References: <4EF8ABD9.2040903@biblibre.com> <4EF9DCE0.6070404@esilibrary.com> <4EF9E393.2030603@biblibre.com> <4EF9E445.8080701@esilibrary.com> <4EF9E80D.4040206@biblibre.com> Message-ID: <4EF9E86D.2070707@esilibrary.com> Hi, On 12/27/2011 10:45 AM, Paul Poulain wrote: > Indra, do you think it could be possible by the end of THIS week for > you? (not sure it could be for us) And to be clear -- since I made the suggestion to do this quickly, I'm happy to help make it happen, but it's just a suggestion. As long as there's advance notice, I'm sure that most any time between now and mid-February will work. Regards, Galen -- Galen Charlton Director of Support and Implementation Equinox Software, Inc. / The Open Source Experts email: gmc at esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org From nomankazidu at yahoo.com Thu Dec 29 05:06:24 2011 From: nomankazidu at yahoo.com (kazi) Date: Wed, 28 Dec 2011 20:06:24 -0800 (PST) Subject: [Koha-devel] software error Message-ID: <1325131584953-5106744.post@n5.nabble.com> Dear community, Is this a bug or some other error in 3.6.3.001. How to fix it? Date::Calc::Add_Delta_Days(): not a valid date at /usr/share/koha/opac/cgi-bin/opac/opac-user.pl line 113. With regards, Kazi -- View this message in context: http://koha.1045719.n5.nabble.com/software-error-tp5106744p5106744.html Sent from the Koha-devel mailing list archive at Nabble.com. From paul.poulain at biblibre.com Thu Dec 29 18:14:29 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Thu, 29 Dec 2011 18:14:29 +0100 Subject: [Koha-devel] RM monthly newsletter #2 In-Reply-To: <4ECFD84E.7080307@biblibre.com> References: <4ECFD84E.7080307@biblibre.com> Message-ID: <4EFC9FF5.3020906@biblibre.com> December Release Manager newsletter (#2) == Patches and contributors == This month, i've pushed almost ... 100 patches ! congrats to all the commiters. A special thanks to ppl recently joigning us and entering the "hall of fame" of Koha contributors: Adrien Saurat, Jon Aker, Fabio Tiana, Duncan Tyler and Marc Balmer ! == Highlighted patches pushed == * in about page (Koha > More > About) there is a new tab with the timeline of Koha. All contributors are placed here. (comment: as it's incomplete, maybe we could/should remove the "Koha dev team" list in the Koha team tab. We should also update "Koha Release Team" and "Special thanks to the following organizations") * some security issues have been fixed. Many thanks to Fr?re S?bastien Marie (a French monk!) that reports them & sometimes fixes them as well ! == Jenkins == Jenkins (http://jenkins.koha-community.org/) is now "stable". Some new tests have been added to the test suite last week. Thanks to those who have fixed tests that are failing. There are 3 possible reasons for a test to fail: * the code of Koha is wrong. This was not the largest part of the failures. * the code of the test is wrong. This can come from a test not updated after a commit that should have (API changed), or a test case that had been forgotten * the test database is wrong. There are 2 kinds of tests: general tests (ie: are templates valid, are perl scripts perlcritic compliant) and DB dependant tests (ie: is patron searching working). If you want to play with the sample database we use on jenkins, just start a fresh install of Koha and check all the optional options in the webinstaller to install sample itemtypes, patron categories, ... To finish with jenkins, i'd like to see more tests being submitted ! Sometimes I'm also a little bit disappointed to see that some tests are OK, just because we don't test everything. For example, perlcritic test don't try to check some directories. Here is the list of all dirs that should be checked: > my @all_koha_dirs = qw( acqui admin authorities basket C4 catalogue cataloguing circ debian errors > labels members misc offline_circ opac patroncards reports reserve reviews rotating_collections > serials sms suggestion t tags test tools virtualshelves); and here is the list of all checked dirs: > my @dirs = qw( acqui admin authorities basket catalogue cataloguing circ debian errors labels > offline_circ reserve reviews rotating_collections serials sms virtualshelves ); Feel free to work on directories that are still untested ! just run perlcritic xxxx/ to see what is failing for directory xxxx == Koha speed == Last month, and it will continue next months, i've been focusing on Koha speed. A lot of improvements can be done on this matter. The main one will be moving from CGI to a persistent layer like mod_perl or plack. I've been told that Catalyst & Bywater are working on that, I'm impatiently waiting for some feedback & will participate personally if I can. But persistence is not the only thing we can work on. Some patches have been pushed or are waiting to improve the speed of Koha. * bug 6193: reading xml config file from memcache = if you've memcache activated, then the Koha config file will be read from memcached, not from XML parsing, that is a consuming a lot of time (250ms on my laptop !) * bug 6015: benchmarking suite: I've completed (& pushed) a script to benchmark Koha. It's located in misc/load_testing/benchmark_staff.pl 4 patches bugs related to speed/performance are waiting for you: * bug 6000: Performance enhancements for C4::Context and C4::Languages (needs signoff) * bug 6019: Using memoize_memcached to cache slow subroutines (needs signoff) * Bug 6875 - de-nesting C4 packages (needs signoff) -note that each patch is independant and could/should be splitted in a separate bug, 6875 becoming an omnibus * Bug 7170 - Remove use of XML::Simple (needs a patch !) I also have added a page on the wiki (http://wiki.koha-community.org/wiki/Benchmark_for_3.8) with some benchmarking results. I'll continue filling this page everytime I push a patch that has something to do with speed. == Database update == The database update (bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7167) is ready, signed off, and only waiting for some QA from the QA team. As writers of this patch are also members of the QA team (Jonathan & me), I hope the QA will be OK ;-) == Testing sandboxes == When I applied as RM, I announced that I planned to create sandbox to help ppl testing Koha. The idea is to have some sandboxes, and any volunteer could connect to this sandbox, say "I want to test bug XXXX", and, a few minutes later, be could connect to sandbox10.koha-community.org, and test the patches under XXXX Those sandboxes will use git bz (a very handy tool you should use !), see http://wiki.koha-community.org/wiki/Git_bz_configuration, let you choose a test database. The results of the git bz commands will be made available on the home page of the staff interface, to check everything went well. Also note that this will work well only once the new updatedatabase will have been pushed. Without the new DB update system, it won't be possible to tests patches with a DB update in those sandboxes. I couldn't work on those sandboxes this month, but I really plan to work on it next month ! == Patches waiting == A lot of work has been made on bugzilla, and there are "only" 64 patches waiting for signoff and 55 patches waiting for QA. Keep on the good work ! == Hackfest in Europe == In case you missed the news BibLibre (my company, in case you don't know) organize a hackfest in Marseille in March. More information at http://drupal.biblibre.com/en/blog/entry/2012-hackfest-in-europe, feel free to join, all attendees will get a special thanks on this newsletter after the hackfest ;-) I wish each of you the best for 2012 ! including, of course, a lot of fun hacking Koha ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From paul.a at aandc.org Thu Dec 29 22:51:49 2011 From: paul.a at aandc.org (Paul) Date: Thu, 29 Dec 2011 16:51:49 -0500 Subject: [Koha-devel] FIXME in biblio.pm In-Reply-To: References: <5.2.1.1.2.20111216190209.0765c7a8@stormy.ca> Message-ID: <5.2.1.1.2.20111229162655.05e40fa0@localhost> At 10:16 PM 12/16/2011 -0500, Chris Nighswonger wrote: >On Fri, Dec 16, 2011 at 10:12 PM, Chris Nighswonger ><cnighswonger at foundations.edu> wrote: >On Fri, Dec 16, 2011 at 7:09 PM, Paul ><paul.a at aandc.org> wrote: >Lines 3006-3008 of biblio.pm called from >additem.pl: >? ? ? ? # get title of the record (to store the 10 first letters with >the index) >? ? ? ? my ( $titletag, $titlesubfield ) = GetMarcFromKohaField( >'biblio.title', '' ); ? ? # FIXME: should be >GetFrameworkCode($biblionumber) ?? >? ? ? ? $title = lc( $record->subfield( $titletag, $titlesubfield ) ); > >Before I start looking elsewhere, can someone kindly help me with the use >of FIXME comments? [snip] >Based on the commit message it looks like Joe was thinking that the second >argument passed to GetMarcFromKohaField might should be populated with the >results of GetFrameworkCode($biblionumber). In any case, it is still more >likely to be corrupted data than the empty framework parameter passed to >GetMarcFromKohaField that is causing your error. Just back from a few days holidays, I cannot find "corrupted data" (this was an sql dump of our 3.2 data file), EXCEPT that we appear to have completely lost "authorities." Could this be the "empty framework parameter" you mention? While I was away, our most experienced cataloguer entered 25 [biblios + items] at my request for debugging purposes. The biblios went fine, the items all produced the biblio.pm line 3009 error, but both OPAC and staff search find the items perfectly. However our "authorities" (personal names) which has some 15,000 entries is unsearchable (only the latest 25 appear.) Perhaps I'm way off-track, but this may have something to do with re-indexing zebra. I thought I had set up a cron job at 1 min intervals (as on the old server) but using both users (root and Koha) $ crontab -l gives nothing - so I am trying to set it up again, but find at that "Do Either Option#1 [OPTION 1 is Highly RECOMMENDED for Koha version 3.06.02] or Option #2 DO NOT DO BOTH. Option #1: Use the Zebra Queue Daemon to manage indexing." I had always understood that the "daemon" was deprecated in favour of a cron job (has this changed for 3.6?) and am now afraid that the "daemon" may have been working in the background damaging {something} as our searches (staff and OPAC) find titles, authors etc -- just not "authorities." Fearing I'm getting into a potential mess here, could anyone please come up with suggestions? Thanks in advance and happy new year, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielg.koha at gmail.com Thu Dec 29 22:53:48 2011 From: danielg.koha at gmail.com (Daniel Grobani) Date: Thu, 29 Dec 2011 13:53:48 -0800 Subject: [Koha-devel] Official Koha Newsletter: Volume 2, Issue 12: December 2011 Message-ID: Official Koha Newsletter: Volume 2, Issue 12: December 2011 [Below is the text of the newsletter. For active links and a more readable format, please visit http://koha-community.org/koha-newsletter-volume-2-issue-12-december-2011] Official Koha Newsletter (ISSN 2153-8328) Volume 2, Issue 12: December 2012 Edited by Daniel Grobani, Koha Community Newsletter Editor. Please submit news items to danielg.koha at gmail.com. Table of Contents Koha Development Koha 3.6.2 Released Koha 3.4.7 Released Koha 3.2.11 Released Koha 3.4.8 Status Koha Community New Koha Libraries Community Gossip Koha in Fiji Past Koha Events December General IRC Meeting Global Bug Squashing Day 2011-12-07 Upcoming Koha Events January General IRC Meeting Global Bug Squashing Day 2011-01-06 Marseilles Hackfest Koha Development Koha 3.6.2 Released by Chris Nighswonger It is with pleasure that I announce the release of Koha 3.6.2. The package can be retrieved from: http://download.koha-community.org/koha-3.06.02.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.06.02.tar.gz.MD5 http://download.koha-community.org/koha-3.06.02.tar.gz.MD5.asc http://download.koha-community.org/koha-3.06.02.tar.gz.sig Release notes for 3.6.2 are at http://koha-community.org/koha-3-6-2. Koha 3.4.7 Released by Chris Nighswonger It is with pleasure that I announce the release of Koha 3.4.7. The package can be retrieved from: http://download.koha-community.org/koha-3.04.07.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.04.07.tar.gz.MD5 http://download.koha-community.org/koha-3.04.07.tar.gz.MD5.asc http://download.koha-community.org/koha-3.04.07.tar.gz.sig Release notes for 3.4.7 are at http://koha-community.org/koha-3-4-7. Koha 3.2.11 Released by Chris Nighswonger It is with pleasure that I announce the release of Koha 3.2.11. The package can be retrieved from: http://download.koha-community.org/koha-3.02.11.tar.gz You can use the following checksum and signature files to verify the download: http://download.koha-community.org/koha-3.02.11.tar.gz.MD5 http://download.koha-community.org/koha-3.02.11.tar.gz.MD5.asc http://download.koha-community.org/koha-3.02.11.tar.gz.sig Release notes for 3.2.11 are at http://koha-community.org/koha-3-2-11. Koha 3.4.8 Status by Chris Nighswonger Koha 3.4.8 will be released on 14 January 2012. The 3.4.x branch will enter a string freeze on 8 Jan 2012 00:00 UTC. Koha Community New Koha Libraries Centro de Investigaci?n y Educaci?n Popular ? Programa por la Paz (via Organizadatos) Colegio San Bartolom? La Merced (via Organizadatos) Corporaci?n Universitaria CENDA (via Organizadatos) Instituto Amaz?nico de Investigaciones Cient?ficas, SINCHI (via Organizadatos) Red de Museodata para Bibliotecas de Museos (via Organizadatos) Community Gossip Equinox Software has bought a new office building and is moving into it. Kyle Hall has updated his Koha virtual appliances to 3.6, a complete rebuild using Debian 6.0 (Squeeze) instead of Lenny. For more info, see http://millruntech.com/koha/koha-virtual-appliances. Owen Leonard is working on replacing the YUI Library in Koha with jQueryUI. For more info, see his blog post at http://www.myacpl.org/koha/?p=701. Stefano Bargioni has made available MARCgrep.pl, a Perl script to filter or count MARC records based on the contents of tag names, indicators, or subfields. For more info, see http://en.pusc.it/bib/MARCgrep. Koha in Fiji by Smita Biswas I was seconded along with the Manager of Tauranga City Library, Jill Best, to implement Koha in the first public library in Fiji. The Nadi Town Council Library went live on Dec 6 2011 on version 3.6. We did it as a pilot project, which took about 4 months for me to learn and install on a local machine and then assist the Nadi Council IT officer to download a stable release. I then visited Nadi for a week along with Jill for implementation and training. We did a simple LAN set up between the Server and two staff machines, one being used for circulation and other for cataloguing and acquistion. Hopefully they will able to host their database on the web in the future. There is considerable interest among other Fiji public libraries, due to the enthusiastic campaign by Jill, who has been a long-time volunteer and donor of books to the Fiji Libraries. Since I had never worked with Koha or Linux I was finding it quite hard in the beginning just following the downloading instructions from the wiki. I am very grateful for the help provided by Steven and Richard from Technology Wise Ltd, Tauranga, NZ. They were amazing, they took me under their wing and assisted me with the first install. Thereafter I could do a second install under Richard?s guidance. Richard was also very good in assisting the Nadi Council IT officer to do the install, including working on his server remotely when the Council IT officer found it hard going due to lack of experience and knowledge of Linux. I also need to thank Paul Nielsen, Library Manager of Hauraki District Council Library, NZ, for helping me with the system settings. What a great user group we have here!! I am definitely a Koha convert now, seeing how easy it is to install and implement?this coming from a Librarian (with some systems backgroaund). I hope to convince our Council IT to consider Koha in future. I am also happy to talk to any other groups or libraries about my experience of doing this project. Jill is already lining me up for next year for Suva libraries and maybe Solomon Islands. I am just taking a breather at the moment. It was very very hot? Smita Biswas, ALIANZA, RLIANZA Collections & Information Manager Tauranga City Library Tauranga City Council Ph 07 5777260 M 0275999241 E smita.biswas at tauranga.govt.nz www.tauranga.govt.nz Past Koha Events December General IRC Meeting The December general IRC meeting was held on 7 December 2011. For more info, including the agenda and links to the minutes, see http://wiki.koha-community.org/wiki/General_IRC_Meeting,_7_December_2011. Global Bug Squashing Day 2011-12-07 by Magnus Enger A Global Bug Sqashing Day was held on 7 December 2011, and there was much rejoicing. For the numbers, see http://wiki.koha-community.org/wiki/2011-12-07_Global_bug_squashing_day. Upcoming Koha Events January General IRC Meeting The January general IRC meeting will be held on 4 January 2012. For more info, see http://wiki.koha-community.org/wiki/General_IRC_Meeting,_4_January_2012. Global Bug Squashing Day 2012-01-06 by Magnus Enger Global Bug Squashing Days are days designated to a concerted effort to get bugs and patches moving along in the right direction. The next GBSD will be 6 January 2012. For more info, see http://wiki.koha-community.org/wiki/2012-01-06_Global_bug_squashing_day. Marseilles Hackfest by Paul Poulain BibLibre will be hosting a hackfest in Marseilles, France, from Monday to Friday, 19-23 March 2012. For more info, see http://drupal.biblibre.com/en/blog/entry/2012-hackfest-in-europe. From julian.maurice at biblibre.com Fri Dec 30 11:07:50 2011 From: julian.maurice at biblibre.com (Julian Maurice) Date: Fri, 30 Dec 2011 11:07:50 +0100 Subject: [Koha-devel] DataTables How-To Message-ID: <4EFD8D76.6040008@biblibre.com> Hi all! I just wrote a brief explanation on how to use the jQuery library DataTables in Koha pages. Here is the link http://wiki.koha-community.org/wiki/DataTables_HowTo Please feel free to give feedback and to contribute ;-) -- Julian Maurice BibLibre From mjr at phonecoop.coop Fri Dec 30 14:55:53 2011 From: mjr at phonecoop.coop (MJ Ray) Date: Fri, 30 Dec 2011 13:55:53 +0000 Subject: [Koha-devel] software error In-Reply-To: <1325131584953-5106744.post@n5.nabble.com> Message-ID: kazi > Is this a bug or some other error in 3.6.3.001. How to fix it? > > Date::Calc::Add_Delta_Days(): not a valid date at > /usr/share/koha/opac/cgi-bin/opac/opac-user.pl line 113. Hi. Thanks for the question. Basically, you need to find what invalid date was given in opac-user.pl line 113 and where it came fron, but to help with that, we need a bit more information. You probably need to tell us:- * Web address of error, or at least the end bit from /cgi-bin on. * How to obtain the error, step-by-step if possible. * If that process has worked for you before, the version when it worked. (This is copy-pasta which you could avoid by reading the list archives before posting. I see many bug reports that are missing vital info like the above and this seems better than you getting no reply.) Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/