From ashokmishra119 at gmail.com  Fri Jun  1 09:18:01 2012
From: ashokmishra119 at gmail.com (Ashok Mishra)
Date: Fri, 1 Jun 2012 12:48:01 +0530
Subject: [Koha-devel] Fwd: Reminder: please check on your stuff in Failed QA
In-Reply-To: <CAO4qe2MALJb6K3DDrXBSEfg8GhSHVhHGBMMa_YmN36pVLXHWiA@mail.gmail.com>
References: <50B1B576-C923-44C9-93BF-2A79F6926808@nekls.org>
	<CAO4qe2MALJb6K3DDrXBSEfg8GhSHVhHGBMMa_YmN36pVLXHWiA@mail.gmail.com>
Message-ID: <CALQH6wgrq6Mbna4WfLWggQRq1GHuXRYqtZvn97+OnZ4h1T-gew@mail.gmail.com>

hello every body

---------- Forwarded message ----------
From: Owen Leonard <oleonard at myacpl.org>
Date: Fri, Jun 1, 2012 at 2:39 AM
Subject: Re: [Koha-devel] Reminder: please check on your stuff in Failed QA
To: koha-devel at lists.koha-community.org


> I was perusing through bugzilla today and I was surprised at how much
> stuff there was in Failed QA that is just apparently abandoned.

There's a saved search for it:

http://bugs.koha-community.org/bugzilla3/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Failed%20QA&sharer_id=21&list_id=31391

 -- Owen


--
Web Developer
Athens County Public Libraries
http://www.myacpl.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/



-- 
Ashok MIshra
*Librarian*
Bansal College of Pharmacy, Bhopal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120601/5d2b9178/attachment.htm>

From dschust1 at gmail.com  Sun Jun  3 05:50:45 2012
From: dschust1 at gmail.com (David Schuster)
Date: Sat, 2 Jun 2012 22:50:45 -0500
Subject: [Koha-devel] 3.06.05 problem or not?
Message-ID: <CAKpR+xQt9jqvDeR===f+K55Oea29KLOw-_7vXt1XpsC5U26b=g@mail.gmail.com>

Earlier this week on my test system I upgraded from 3.06 to the 3.06.05 -
everything went well and it asked me when I went into the web installer to
do the upgrade.

Today I reloaded the data in the mysql with a fresh database and when I
logged into the web it didn't ask me to upgrade.  In the past it always has
so now I'm wondering if I did something wrong or if there is a problem in
upgrading an older mysql  when running 3.06.05.

I had hoped to go live on Tuesday with 3.06.05, but now I'm concerned that
my database isn't upgraded right.  Is there a way to manually run the
upgrade on the database that you would normally see with the web login?

Dazed and confused - concerned!

-- 
David Schuster
Plano ISD
Library Technology Coordinator
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120602/6ef60f29/attachment.htm>

From danielg.koha at gmail.com  Sun Jun  3 05:57:25 2012
From: danielg.koha at gmail.com (Daniel Grobani)
Date: Sat, 2 Jun 2012 20:57:25 -0700
Subject: [Koha-devel] KohaCon12 conferees: please send news!
Message-ID: <CAOeKewg=7AQe6=vdRErJ9H9x3cm7DSFf1EWyET5oh=PEhK_HHg@mail.gmail.com>

O you fortunate ones attending KohaCon12,

Please remember those left behind and send your accounts of what we
missed for publication in the June newsletter.

Thanks from your community newsletter editor,
Daniel Grobani

From jcamins at cpbibliography.com  Sun Jun  3 13:41:43 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Sun, 3 Jun 2012 07:41:43 -0400
Subject: [Koha-devel] 3.06.05 problem or not?
In-Reply-To: <CAKpR+xQt9jqvDeR===f+K55Oea29KLOw-_7vXt1XpsC5U26b=g@mail.gmail.com>
References: <CAKpR+xQt9jqvDeR===f+K55Oea29KLOw-_7vXt1XpsC5U26b=g@mail.gmail.com>
Message-ID: <CALVDfQw2barpgkY=EANQfMGXPa1hWhxXzNNsYkVc41AVw6oj_Q@mail.gmail.com>

David,

You can run installer/data/mysql/updatedatabase.pl directly. That's what I
usually do. I haven't had any problems with upgrading to 3.6.5, but there
have been a few times when for no apparent reason updatedatabase was not
trigged. You may want to check what version the About page reports that
you're running, just in case there's anything peculiar about what it's set
to in your production system (you can manually set it back in the "Local
Use" pane if it's wrong).

Regards,
Jared

On Sat, Jun 2, 2012 at 11:50 PM, David Schuster <dschust1 at gmail.com> wrote:

> Earlier this week on my test system I upgraded from 3.06 to the 3.06.05 -
> everything went well and it asked me when I went into the web installer to
> do the upgrade.
>
> Today I reloaded the data in the mysql with a fresh database and when I
> logged into the web it didn't ask me to upgrade.  In the past it always has
> so now I'm wondering if I did something wrong or if there is a problem in
> upgrading an older mysql  when running 3.06.05.
>
> I had hoped to go live on Tuesday with 3.06.05, but now I'm concerned that
> my database isn't upgraded right.  Is there a way to manually run the
> upgrade on the database that you would normally see with the web login?
>
> Dazed and confused - concerned!
>
> --
> David Schuster
> Plano ISD
> Library Technology Coordinator
>
> _______________________________________________
> 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: </pipermail/koha-devel/attachments/20120603/81143f89/attachment.htm>

From jonathan.druart at biblibre.com  Tue Jun  5 16:07:39 2012
From: jonathan.druart at biblibre.com (Jonathan Druart)
Date: Tue, 5 Jun 2012 16:07:39 +0200
Subject: [Koha-devel] A C4::Logger module would be useful ?
Message-ID: <CAJzKNY4f5aozh_AymUXYMS=GxRkYzHzCzuh7cbYbcWPvJ693pA@mail.gmail.com>

HI all,

I have developped a logging module (based on LogLite). I think it could be
useful for Koha.

A new system preference controls the log level (eg. level warning for
production and debug for development).

It can be used by a simple script or into Koha.

How it works: See Bug 8190 (
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8190)

Please have a look at that, and tell me what do you think about it.
Technically, is it satisfying for you?

I think it could help us to increase the code quality.

Any others ideas are welcome !

++ Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120605/9edb241f/attachment.htm>

From jcamins at cpbibliography.com  Tue Jun  5 16:17:32 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Tue, 5 Jun 2012 09:17:32 -0500
Subject: [Koha-devel] A C4::Logger module would be useful ?
In-Reply-To: <CAJzKNY4f5aozh_AymUXYMS=GxRkYzHzCzuh7cbYbcWPvJ693pA@mail.gmail.com>
References: <CAJzKNY4f5aozh_AymUXYMS=GxRkYzHzCzuh7cbYbcWPvJ693pA@mail.gmail.com>
Message-ID: <CALVDfQw3T0hssZQ696j1UrD-9jsk_eTvaUog4ZEE2iegaFJ0+Q@mail.gmail.com>

Jonathan,

I have developped a logging module (based on LogLite). I think it could be
> useful for Koha.
>
> A new system preference controls the log level (eg. level warning for
> production and debug for development).
>
> It can be used by a simple script or into Koha.
>
> How it works: See Bug 8190 (
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8190)
>
> Please have a look at that, and tell me what do you think about it.
> Technically, is it satisfying for you?
>

+1 from me for the idea. I didn't look at the code, but I love the idea.

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: </pipermail/koha-devel/attachments/20120605/db03ea5d/attachment.htm>

From chris at bigballofwax.co.nz  Tue Jun  5 16:22:20 2012
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Wed, 6 Jun 2012 02:22:20 +1200
Subject: [Koha-devel] A C4::Logger module would be useful ?
In-Reply-To: <CALVDfQw3T0hssZQ696j1UrD-9jsk_eTvaUog4ZEE2iegaFJ0+Q@mail.gmail.com>
References: <CAJzKNY4f5aozh_AymUXYMS=GxRkYzHzCzuh7cbYbcWPvJ693pA@mail.gmail.com>
	<CALVDfQw3T0hssZQ696j1UrD-9jsk_eTvaUog4ZEE2iegaFJ0+Q@mail.gmail.com>
Message-ID: <CA+95qVTv-dicFkAQJ_SxUJ5TZXZW1yyb-EyCr3Sk2K-fUauUxg@mail.gmail.com>

On 6 June 2012 02:17, Jared Camins-Esakov <jcamins at cpbibliography.com> wrote:
> Jonathan,
>
>> I have developped a logging module (based on LogLite). I think it could be
>> useful for Koha.
>>
>> A new system preference controls the log level (eg. level warning for
>> production and debug for development).
>>
>> It can be used by a simple script or into Koha.
>>
>> How it works: See Bug 8190
>> (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8190)
>>
>> Please have a look at that, and tell me what do you think about it.
>> Technically, is it satisfying for you?
>
>
> +1 from me for the idea. I didn't look at the code, but I love the idea.
>
What he said !

Chris

From dpavlin at rot13.org  Tue Jun  5 17:01:24 2012
From: dpavlin at rot13.org (Dobrica Pavlinusic)
Date: Tue, 5 Jun 2012 17:01:24 +0200
Subject: [Koha-devel] A C4::Logger module would be useful ?
In-Reply-To: <CA+95qVTv-dicFkAQJ_SxUJ5TZXZW1yyb-EyCr3Sk2K-fUauUxg@mail.gmail.com>
References: <CAJzKNY4f5aozh_AymUXYMS=GxRkYzHzCzuh7cbYbcWPvJ693pA@mail.gmail.com>
	<CALVDfQw3T0hssZQ696j1UrD-9jsk_eTvaUog4ZEE2iegaFJ0+Q@mail.gmail.com>
	<CA+95qVTv-dicFkAQJ_SxUJ5TZXZW1yyb-EyCr3Sk2K-fUauUxg@mail.gmail.com>
Message-ID: <20120605150124.GA12710@mjesec.ffzg.hr>

On Wed, Jun 06, 2012 at 02:22:20AM +1200, Chris Cormack wrote:
> On 6 June 2012 02:17, Jared Camins-Esakov <jcamins at cpbibliography.com> wrote:
> > Jonathan,
> >
> >> I have developped a logging module (based on LogLite). I think it could be
> >> useful for Koha.
> >>
> >> A new system preference controls the log level (eg. level warning for
> >> production and debug for development).
> >>
> >> It can be used by a simple script or into Koha.
> >>
> >> How it works: See Bug 8190
> >> (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8190)
> >>
> >> Please have a look at that, and tell me what do you think about it.
> >> Technically, is it satisfying for you?
> >
> >
> > +1 from me for the idea. I didn't look at the code, but I love the idea.
> >
> What he said !

+1 from me.

Should we also wrap warn(s) to emit debug output like this?

$SIG{__WARN__} = sub {
	C4::Logger->new->debug( @_ );
}

Right now every warn in code makes patch fail QA (I know that first
hand ;-) and it seems to me it's easier to just put warn instead of

C4::Logger->new->debug( "this used to be warn" );


From robin at catalyst.net.nz  Tue Jun  5 17:09:07 2012
From: robin at catalyst.net.nz (Robin Sheat)
Date: Tue, 05 Jun 2012 16:09:07 +0100
Subject: [Koha-devel] A C4::Logger module would be useful ?
In-Reply-To: <CAJzKNY4f5aozh_AymUXYMS=GxRkYzHzCzuh7cbYbcWPvJ693pA@mail.gmail.com>
References: <CAJzKNY4f5aozh_AymUXYMS=GxRkYzHzCzuh7cbYbcWPvJ693pA@mail.gmail.com>
Message-ID: <70e32c49-7752-4684-a13e-9dc929b5c250@email.android.com>

I approve of the idea, though shouldn't it be in the Koha:: namespace?

Jonathan Druart <jonathan.druart at biblibre.com> wrote:

>HI all,
>
>I have developped a logging module (based on LogLite). I think it could
>be
>useful for Koha.
>
>A new system preference controls the log level (eg. level warning for
>production and debug for development).
>
>It can be used by a simple script or into Koha.
>
>How it works: See Bug 8190 (
>http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8190)
>
>Please have a look at that, and tell me what do you think about it.
>Technically, is it satisfying for you?
>
>I think it could help us to increase the code quality.
>
>Any others ideas are welcome !
>
>++ Jonathan
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>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/

-- 
Sent from Kaiten Mail for Android. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120605/74d63d5e/attachment.htm>

From tomascohen at gmail.com  Tue Jun  5 17:12:26 2012
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Tue, 5 Jun 2012 12:12:26 -0300
Subject: [Koha-devel] A C4::Logger module would be useful ?
In-Reply-To: <70e32c49-7752-4684-a13e-9dc929b5c250@email.android.com>
References: <CAJzKNY4f5aozh_AymUXYMS=GxRkYzHzCzuh7cbYbcWPvJ693pA@mail.gmail.com>
	<70e32c49-7752-4684-a13e-9dc929b5c250@email.android.com>
Message-ID: <CABZfb=VrbK3xUkjGAW8p8Wb8wo6G+dyFObSjNQFrKg28aZ8NoA@mail.gmail.com>

+1 for this good idea
+1 for Koha::Logger

Saludos
To+

On Tue, Jun 5, 2012 at 12:09 PM, Robin Sheat <robin at catalyst.net.nz> wrote:
> I approve of the idea, though shouldn't it be in the Koha:: namespace?
>
> Jonathan Druart <jonathan.druart at biblibre.com> wrote:
>>
>> HI all,
>>
>> I have developped a logging module (based on LogLite). I think it could be
>> useful for Koha.
>>
>> A new system preference controls the log level (eg. level warning for
>> production and debug for development).
>>
>> It can be used by a simple script or into Koha.
>>
>> How it works: See Bug 8190
>> (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8190)
>>
>> Please have a look at that, and tell me what do you think about it.
>> Technically, is it satisfying for you?
>>
>> I think it could help us to increase the code quality.
>>
>> Any others ideas are welcome !
>>
>> ++ Jonathan
>>
>> ________________________________
>>
>> 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/
>
>
> --
> Sent from Kaiten Mail for Android. Please excuse my brevity.
>
> _______________________________________________
> 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  Tue Jun  5 17:16:23 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Tue, 05 Jun 2012 17:16:23 +0200
Subject: [Koha-devel] A C4::Logger module would be useful ?
In-Reply-To: <70e32c49-7752-4684-a13e-9dc929b5c250@email.android.com>
References: <CAJzKNY4f5aozh_AymUXYMS=GxRkYzHzCzuh7cbYbcWPvJ693pA@mail.gmail.com>
	<70e32c49-7752-4684-a13e-9dc929b5c250@email.android.com>
Message-ID: <4FCE22C7.4030405@biblibre.com>

Le 05/06/2012 17:09, Robin Sheat a ?crit :
> I approve of the idea, though shouldn't it be in the Koha:: namespace?
you're perfectly right. and the naming convention for the Koha::
namespace is something I want to discuss during the hackfest to build a
proposal we could agree on in a future vote.

(MJ-slef = I've a list of things i'd like to work on during the
hackfest, will send it to you tomorrow)

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From jonathan.druart at biblibre.com  Tue Jun  5 17:17:54 2012
From: jonathan.druart at biblibre.com (Jonathan Druart)
Date: Tue, 5 Jun 2012 17:17:54 +0200
Subject: [Koha-devel] A C4::Logger module would be useful ?
In-Reply-To: <20120605150124.GA12710@mjesec.ffzg.hr>
References: <CAJzKNY4f5aozh_AymUXYMS=GxRkYzHzCzuh7cbYbcWPvJ693pA@mail.gmail.com>
	<CALVDfQw3T0hssZQ696j1UrD-9jsk_eTvaUog4ZEE2iegaFJ0+Q@mail.gmail.com>
	<CA+95qVTv-dicFkAQJ_SxUJ5TZXZW1yyb-EyCr3Sk2K-fUauUxg@mail.gmail.com>
	<20120605150124.GA12710@mjesec.ffzg.hr>
Message-ID: <CAJzKNY6yroXwe9Ep_tXpEivLYbuurUjWsB+bcNPf5S0-Ey8jcg@mail.gmail.com>

2012/6/5 Dobrica Pavlinusic <dpavlin at rot13.org>

> On Wed, Jun 06, 2012 at 02:22:20AM +1200, Chris Cormack wrote:
> > On 6 June 2012 02:17, Jared Camins-Esakov <jcamins at cpbibliography.com>
> wrote:
> > > Jonathan,
> > >
> > >> I have developped a logging module (based on LogLite). I think it
> could be
> > >> useful for Koha.
> > >>
> > >> A new system preference controls the log level (eg. level warning for
> > >> production and debug for development).
> > >>
> > >> It can be used by a simple script or into Koha.
> > >>
> > >> How it works: See Bug 8190
> > >> (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8190)
> > >>
> > >> Please have a look at that, and tell me what do you think about it.
> > >> Technically, is it satisfying for you?
> > >
> > >
> > > +1 from me for the idea. I didn't look at the code, but I love the
> idea.
> > >
> > What he said !
>
> +1 from me.
>
> Should we also wrap warn(s) to emit debug output like this?
>
> $SIG{__WARN__} = sub {
>        C4::Logger->new->debug( @_ );
> }
>
> Right now every warn in code makes patch fail QA (I know that first
> hand ;-) and it seems to me it's easier to just put warn instead of
>
> C4::Logger->new->debug( "this used to be warn" );



The idea is to use the global variable $log, instead of call each times
C4::Logger->new

Your ligne become:
$log->debug("my debug message");
Yes it's a little bit  longer.

But if you have a structure, you can call debug with a flag in 2nd param
like this:
$hash;
$log->debug($hash, 1);
instead of
warn Data::Dumper::Dumper $hash;
it's shorter ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120605/2afa2cdf/attachment-0001.htm>

From paul.poulain at biblibre.com  Tue Jun  5 17:18:37 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Tue, 05 Jun 2012 17:18:37 +0200
Subject: [Koha-devel] A C4::Logger module would be useful ?
In-Reply-To: <20120605150124.GA12710@mjesec.ffzg.hr>
References: <CAJzKNY4f5aozh_AymUXYMS=GxRkYzHzCzuh7cbYbcWPvJ693pA@mail.gmail.com>
	<CALVDfQw3T0hssZQ696j1UrD-9jsk_eTvaUog4ZEE2iegaFJ0+Q@mail.gmail.com>
	<CA+95qVTv-dicFkAQJ_SxUJ5TZXZW1yyb-EyCr3Sk2K-fUauUxg@mail.gmail.com>
	<20120605150124.GA12710@mjesec.ffzg.hr>
Message-ID: <4FCE234D.9040405@biblibre.com>

Le 05/06/2012 17:01, Dobrica Pavlinusic a ?crit :

> $SIG{__WARN__} = sub {
> 	C4::Logger->new->debug( @_ );
> }
> 
> Right now every warn in code makes patch fail QA (I know that first
> hand ;-) and it seems to me it's easier to just put warn instead of
> 
> C4::Logger->new->debug( "this used to be warn" );

I have nothing against this option, as it achieve the goal of having a
user-defined logging level.
At the moment, what fails QA is unconditional warns that fill everyone's
log file !

-- 
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  Tue Jun  5 17:45:34 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Tue, 05 Jun 2012 17:45:34 +0200
Subject: [Koha-devel] A C4::Logger module would be useful ?
In-Reply-To: <CABZfb=VrbK3xUkjGAW8p8Wb8wo6G+dyFObSjNQFrKg28aZ8NoA@mail.gmail.com>
References: <CAJzKNY4f5aozh_AymUXYMS=GxRkYzHzCzuh7cbYbcWPvJ693pA@mail.gmail.com>
	<70e32c49-7752-4684-a13e-9dc929b5c250@email.android.com>
	<CABZfb=VrbK3xUkjGAW8p8Wb8wo6G+dyFObSjNQFrKg28aZ8NoA@mail.gmail.com>
Message-ID: <4FCE299E.4080003@biblibre.com>

Le 05/06/2012 17:12, Tomas Cohen Arazi a ?crit :
> +1 for this good idea
> +1 for Koha::Logger
While I agree for Koha:: namespace, I disagree for Koha::Logged.pm. We
need a more granular organization of the Koha:: namespace.

Something like Koha::Tools::Logger or Koha::Internal::Logger, or
whatever express that the Logger module is related to internals of Koha.

Reminder : there is an action_log table. A newbie could think that
Koha::Logger is related to this table. (I would favour something like
Koha::Database::Action_log for the table)


-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From cnighswonger at foundations.edu  Tue Jun  5 17:58:37 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Tue, 5 Jun 2012 11:58:37 -0400
Subject: [Koha-devel] A C4::Logger module would be useful ?
In-Reply-To: <4FCE299E.4080003@biblibre.com>
References: <CAJzKNY4f5aozh_AymUXYMS=GxRkYzHzCzuh7cbYbcWPvJ693pA@mail.gmail.com>
	<70e32c49-7752-4684-a13e-9dc929b5c250@email.android.com>
	<CABZfb=VrbK3xUkjGAW8p8Wb8wo6G+dyFObSjNQFrKg28aZ8NoA@mail.gmail.com>
	<4FCE299E.4080003@biblibre.com>
Message-ID: <CAP3yOo=FeZhkbmLsyw9oF_ssbKDhApkBr1vy=yAyxm5WjQVKkQ@mail.gmail.com>

On Tue, Jun 5, 2012 at 11:45 AM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Le 05/06/2012 17:12, Tomas Cohen Arazi a ?crit :
> > +1 for this good idea
> > +1 for Koha::Logger
> While I agree for Koha:: namespace, I disagree for Koha::Logged.pm. We
> need a more granular organization of the Koha:: namespace.
>
> Something like Koha::Tools::Logger or Koha::Internal::Logger, or
> whatever express that the Logger module is related to internals of Koha.
>
>
+1 to the idea and
+1 to something like Koha::Tools::Foo

Kind Regards,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120605/5df25e9d/attachment.htm>

From paul.poulain at biblibre.com  Tue Jun  5 18:02:46 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Tue, 05 Jun 2012 18:02:46 +0200
Subject: [Koha-devel] "The Plack effect" benchmarked
Message-ID: <4FCE2DA6.1010803@biblibre.com>

Hi,

Just in case some of you have doubts about the interest of having Plack
for staff interface, here is a result of
misc/load_testing/benchmark_staff.pl made with and without Plack:

benchmarking WITH Plack:
Step 1: staff client main page     	4178ms	4.786 pages/sec
Step 2: catalog detail page        	9991ms	2.001 biblios/sec
Step 3: catalogue search               	5631ms	3.551 biblios/sec
Step 5: patron detail page         	7037ms	2.842 borrowers/sec
Step 5: patron search page             	11800ms	3.389 borrowers/sec
Step 6a circulation (checkouts)        	8967ms	2.23 checkouts/sec
Step 6b circulation (checkins)         	13880ms	1.44 checkins/sec
all transactions at once               	55433ms	3.247 operations/sec
(note = tests run with plackup, not with starman, the all transaction at
once results would probably be better with starman)

benchmarking WITHOUT Plack:
Step 1: staff client main page     	28576ms	0.699 pages/sec
Step 2: catalog detail page        	39106ms	0.511 biblios/sec
Step 3: catalogue search               	55524ms	0.36 biblios/sec
Step 5: patron detail page         	34610ms	0.577 borrowers/sec
Step 5: patron search page             	64964ms	0.615 borrowers/sec
Step 6a circulation (checkouts)        	37907ms	0.527 checkouts/sec
Step 6b circulation (checkins)         	39129ms	0.511 checkins/sec
all transactions at once               138298ms 1.301 operations/sec

It appears that the speed improvement is more x3 or x4 than x1.5 as I
usually say
-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From jonathan.druart at biblibre.com  Wed Jun  6 08:28:37 2012
From: jonathan.druart at biblibre.com (Jonathan Druart)
Date: Wed, 6 Jun 2012 08:28:37 +0200
Subject: [Koha-devel] A C4::Logger module would be useful ?
In-Reply-To: <4FCE299E.4080003@biblibre.com>
References: <CAJzKNY4f5aozh_AymUXYMS=GxRkYzHzCzuh7cbYbcWPvJ693pA@mail.gmail.com>
	<70e32c49-7752-4684-a13e-9dc929b5c250@email.android.com>
	<CABZfb=VrbK3xUkjGAW8p8Wb8wo6G+dyFObSjNQFrKg28aZ8NoA@mail.gmail.com>
	<4FCE299E.4080003@biblibre.com>
Message-ID: <CAJzKNY40haKhq-Z+qGFf9Ra+Be+bOwZB27te3_m9HWt_mfLkEQ@mail.gmail.com>

To me it is more complicated.
The C4::Logger I proposed is not dependant of Koha (i.e. there is no "use
C4::Module;" or "use Koha::Module;").
I think we need a Lib::Koha and a Lib::External (or Lib::Logger directly or
Lib::What::Ever::Logger).

2012/6/5 Paul Poulain <paul.poulain at biblibre.com>

> Le 05/06/2012 17:12, Tomas Cohen Arazi a ?crit :
> > +1 for this good idea
> > +1 for Koha::Logger
> While I agree for Koha:: namespace, I disagree for Koha::Logged.pm. We
> need a more granular organization of the Koha:: namespace.
>
> Something like Koha::Tools::Logger or Koha::Internal::Logger, or
> whatever express that the Logger module is related to internals of Koha.
>
> Reminder : there is an action_log table. A newbie could think that
> Koha::Logger is related to this table. (I would favour something like
> Koha::Database::Action_log for the table)
>
>
> --
> 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: </pipermail/koha-devel/attachments/20120606/ca33b9b7/attachment.htm>

From paul.poulain at biblibre.com  Wed Jun  6 11:27:04 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 06 Jun 2012 11:27:04 +0200
Subject: [Koha-devel] A C4::Logger module would be useful ?
In-Reply-To: <CAJzKNY40haKhq-Z+qGFf9Ra+Be+bOwZB27te3_m9HWt_mfLkEQ@mail.gmail.com>
References: <CAJzKNY4f5aozh_AymUXYMS=GxRkYzHzCzuh7cbYbcWPvJ693pA@mail.gmail.com>
	<70e32c49-7752-4684-a13e-9dc929b5c250@email.android.com>
	<CABZfb=VrbK3xUkjGAW8p8Wb8wo6G+dyFObSjNQFrKg28aZ8NoA@mail.gmail.com>
	<4FCE299E.4080003@biblibre.com>
	<CAJzKNY40haKhq-Z+qGFf9Ra+Be+bOwZB27te3_m9HWt_mfLkEQ@mail.gmail.com>
Message-ID: <4FCF2268.2090908@biblibre.com>

Le 06/06/2012 08:28, Jonathan Druart a ?crit :
> To me it is more complicated.
> The C4::Logger I proposed is not dependant of Koha (i.e. there is no
> "use C4::Module;" or "use Koha::Module;").
> I think we need a Lib::Koha and a Lib::External (or Lib::Logger directly
> or Lib::What::Ever::Logger).
Are you implying this could be a Perl cpan module, and just become a
dependency of Koha ?
I reviewed your code, and can't see any Koha specifics, so that could be
an option.
-- 
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  Wed Jun  6 13:24:14 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 06 Jun 2012 13:24:14 +0200
Subject: [Koha-devel] [DISCUSSION] Database schema & coding guidelines
In-Reply-To: <4FBFB1E4.3050506@msys.ch>
References: <4FBFAC96.6050906@biblibre.com> <4FBFB1E4.3050506@msys.ch>
Message-ID: <4FCF3DDE.1070106@biblibre.com>

Le 25/05/2012 18:23, Marc Balmer a ?crit :
> I contradict.  This results neither in complexity nor in mistakes.
> Imagine two tables, A and B, which both have an id column, then a select
> would probably look like the following:
> 
> select A.id as aid, B.id as bid from A, B, where ...
> 
> So it's not a problem.

I contradict your contradiction.
If you have branches.id as identifier, then, the FK in borrowers table
(the branch of the patron) can't be id, as, in your proposition, the
identifier of the borrower will be borrower.id

It means instead of :
borrowers(borrower_id,surname,firstname,branch_id) /
branches(branch_id,name) / SELECT * FROM borrowers LEFT JOIN branches
USING(branch_id) and use all field in a hash, your option would result in:

borrowers(id,surname,firstname,branch_fk_id) / branches(id,name) /
SELECT borrowers.*,branches.id as bid,branches.name LEFT JOIN branches
ON (borrowers.branch_fk_id,branches.id), and deal with bid as a hash entry.

So, depending on the part of Koha you'll refer to $borrowers->{bid} or
$branch->{id}

I can't imagine a second that would be easier to read. No gain, big
loss, this option must be forgotten according to me.

-- 
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  Wed Jun  6 15:10:41 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 06 Jun 2012 15:10:41 +0200
Subject: [Koha-devel] "The Plack effect" benchmarked
In-Reply-To: <SNT117-DS2482514F9F76C97DF9474DC60D0@phx.gbl>
References: <4FCE2DA6.1010803@biblibre.com>
	<SNT117-DS2482514F9F76C97DF9474DC60D0@phx.gbl>
Message-ID: <4FCF56D1.3040401@biblibre.com>

Le 06/06/2012 13:36, Mark Tompsett a ?crit :
> Greetings,
Hi Mark,
(answer to koha-devel, as it's of general interest)

> These results look good, but how much memory is on the machine you are
> testing this on? Would it have the same effect in a VM server type
> environment limited to 204MB? Is there an amount of memory which makes
> it behave at similar or worse speeds?
I think you missed a 8, and speak of 2048 and not 204MB :D

I haven't tested/checked memory, but what I know for sure is that it
costs only a small amount of memory.

Plack pre-load a lot of things that are loaded on every page by cgi-bin
anyway. So you would have 'spent' that memory at run time.

Depending on Apache configuration, if 5 ppl are requesting a page at the
same time, 5 cgi-bin are launched and 5x memory is consummed. So if you
run starman instead of plackup (starman being multi-thread, plackup
single thread), the result will be the same.

What we have to be *very* careful with is memory hole that result in an
always increasing memory consumption. In CGI mode, as everything is
freed/deleted after each page, any memory hole is painless. With plack,
memory hole will pile up and, at the end ... booom !


(All of this being not measured, so unguaranteed)
-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From tomascohen at gmail.com  Wed Jun  6 15:41:17 2012
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Wed, 6 Jun 2012 10:41:17 -0300
Subject: [Koha-devel] "The Plack effect" benchmarked
In-Reply-To: <4FCF56D1.3040401@biblibre.com>
References: <4FCE2DA6.1010803@biblibre.com>
	<SNT117-DS2482514F9F76C97DF9474DC60D0@phx.gbl>
	<4FCF56D1.3040401@biblibre.com>
Message-ID: <CABZfb=W+KF4ES5BGKNQ6NOBqSt_yK1HkxNQ2-ZY31UtnL+fCaw@mail.gmail.com>

On Wed, Jun 6, 2012 at 10:10 AM, Paul Poulain <paul.poulain at biblibre.com> wrote:
> Le 06/06/2012 13:36, Mark Tompsett a ?crit :
>> Greetings,
> Hi Mark,
> (answer to koha-devel, as it's of general interest)
>
>> These results look good, but how much memory is on the machine you are
>> testing this on? Would it have the same effect in a VM server type
>> environment limited to 204MB? Is there an amount of memory which makes
>> it behave at similar or worse speeds?
> I think you missed a 8, and speak of 2048 and not 204MB :D
>
> I haven't tested/checked memory, but what I know for sure is that it
> costs only a small amount of memory.
>
> Plack pre-load a lot of things that are loaded on every page by cgi-bin
> anyway. So you would have 'spent' that memory at run time.
>
> Depending on Apache configuration, if 5 ppl are requesting a page at the
> same time, 5 cgi-bin are launched and 5x memory is consummed. So if you
> run starman instead of plackup (starman being multi-thread, plackup
> single thread), the result will be the same.
>
> What we have to be *very* careful with is memory hole that result in an
> always increasing memory consumption. In CGI mode, as everything is
> freed/deleted after each page, any memory hole is painless. With plack,
> memory hole will pile up and, at the end ... booom !

This is usually addressed by setting some reasonable amount of
requests lifespan for the processes. Anyway, we shouldn't have memory
holes!

Regards
To+

From mtompset at hotmail.com  Wed Jun  6 15:53:47 2012
From: mtompset at hotmail.com (Mark Tompsett)
Date: Wed, 6 Jun 2012 21:53:47 +0800
Subject: [Koha-devel] "The Plack effect" benchmarked
In-Reply-To: <CABZfb=W+KF4ES5BGKNQ6NOBqSt_yK1HkxNQ2-ZY31UtnL+fCaw@mail.gmail.com>
References: <4FCE2DA6.1010803@biblibre.com><SNT117-DS2482514F9F76C97DF9474DC60D0@phx.gbl><4FCF56D1.3040401@biblibre.com>
	<CABZfb=W+KF4ES5BGKNQ6NOBqSt_yK1HkxNQ2-ZY31UtnL+fCaw@mail.gmail.com>
Message-ID: <SNT117-DS4F692FEFB2CEF7223B408C60D0@phx.gbl>

Greetings,

The question wasn't about memory holes, though I totally understand the pain 
they could be. The question was:
> Is there an amount of memory which makes [plack] behave at similar or 
> worse speeds [to what we have now]?

Testing for average cases (2GB,4GB,8GB) is fine, but an extreme case or two 
would be nice.
And sadly, I wasn't joking about 204MB. There was no typo. I was wondering, 
would plack behave poorly in such a cramped memory space.

GPML,
Mark Tompsett 


From paul.poulain at biblibre.com  Wed Jun  6 15:54:34 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 06 Jun 2012 15:54:34 +0200
Subject: [Koha-devel] "The Plack effect" benchmarked
In-Reply-To: <CABZfb=W+KF4ES5BGKNQ6NOBqSt_yK1HkxNQ2-ZY31UtnL+fCaw@mail.gmail.com>
References: <4FCE2DA6.1010803@biblibre.com>
	<SNT117-DS2482514F9F76C97DF9474DC60D0@phx.gbl>
	<4FCF56D1.3040401@biblibre.com>
	<CABZfb=W+KF4ES5BGKNQ6NOBqSt_yK1HkxNQ2-ZY31UtnL+fCaw@mail.gmail.com>
Message-ID: <4FCF611A.8010909@biblibre.com>

Le 06/06/2012 15:41, Tomas Cohen Arazi a ?crit :
>> What we have to be *very* careful with is memory hole that result in an
>> always increasing memory consumption. In CGI mode, as everything is
>> freed/deleted after each page, any memory hole is painless. With plack,
>> memory hole will pile up and, at the end ... booom !
> 
> This is usually addressed by setting some reasonable amount of
> requests lifespan for the processes.
Yes, Dobrica suggested 50 pages iirc.

> Anyway, we shouldn't have memory
> holes!
Of course. And maybe we have some since years but never spotted them
because of CGI way of doing things

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From kyle.m.hall at gmail.com  Wed Jun  6 15:55:46 2012
From: kyle.m.hall at gmail.com (Kyle Hall)
Date: Wed, 6 Jun 2012 14:55:46 +0100
Subject: [Koha-devel] [DISCUSSION] Database schema & coding guidelines
In-Reply-To: <4FCF3DDE.1070106@biblibre.com>
References: <4FBFAC96.6050906@biblibre.com> <4FBFB1E4.3050506@msys.ch>
	<4FCF3DDE.1070106@biblibre.com>
Message-ID: <CACpVHfwxHGW+CRT42siZVrqqcyKXE4BZANFEEjwYyYH97US85w@mail.gmail.com>

I agree with paul here. I think in the optimal solution would be a
table prefix for every column, so we have *zero* name clashes for
joins. I doubt we will get there any time soon, but it is something to
thing about. It simplifies queries, whereas having id as the pk for
each table convolutes and complicates queries.

Kyle

http://www.kylehall.info
ByWater Solutions ( http://bywatersolutions.com )
Meadville Public Library ( http://www.meadvillelibrary.org )
Crawford County Federated Library System ( http://www.ccfls.org )
Mill Run Technology Solutions ( http://millruntech.com )


On Wed, Jun 6, 2012 at 12:24 PM, Paul Poulain <paul.poulain at biblibre.com> wrote:
> Le 25/05/2012 18:23, Marc Balmer a ?crit :
>> I contradict. ?This results neither in complexity nor in mistakes.
>> Imagine two tables, A and B, which both have an id column, then a select
>> would probably look like the following:
>>
>> select A.id as aid, B.id as bid from A, B, where ...
>>
>> So it's not a problem.
>
> I contradict your contradiction.
> If you have branches.id as identifier, then, the FK in borrowers table
> (the branch of the patron) can't be id, as, in your proposition, the
> identifier of the borrower will be borrower.id
>
> It means instead of :
> borrowers(borrower_id,surname,firstname,branch_id) /
> branches(branch_id,name) / SELECT * FROM borrowers LEFT JOIN branches
> USING(branch_id) and use all field in a hash, your option would result in:
>
> borrowers(id,surname,firstname,branch_fk_id) / branches(id,name) /
> SELECT borrowers.*,branches.id as bid,branches.name LEFT JOIN branches
> ON (borrowers.branch_fk_id,branches.id), and deal with bid as a hash entry.
>
> So, depending on the part of Koha you'll refer to $borrowers->{bid} or
> $branch->{id}
>
> I can't imagine a second that would be easier to read. No gain, big
> loss, this option must be forgotten according to me.
>
> --
> 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 paul.poulain at biblibre.com  Wed Jun  6 16:11:42 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 06 Jun 2012 16:11:42 +0200
Subject: [Koha-devel] Koha RM newsletter published
Message-ID: <4FCF651E.4040205@biblibre.com>

Hello,

you can find my monthly newsletter on koha website:
http://koha-community.org/koha-release-manager-newsletter-7-2012-05/

-- 
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  Wed Jun  6 17:22:51 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 06 Jun 2012 17:22:51 +0200
Subject: [Koha-devel] [DISCUSSION] Database schema & coding guidelines
In-Reply-To: <CACpVHfwxHGW+CRT42siZVrqqcyKXE4BZANFEEjwYyYH97US85w@mail.gmail.com>
References: <4FBFAC96.6050906@biblibre.com> <4FBFB1E4.3050506@msys.ch>
	<4FCF3DDE.1070106@biblibre.com>
	<CACpVHfwxHGW+CRT42siZVrqqcyKXE4BZANFEEjwYyYH97US85w@mail.gmail.com>
Message-ID: <4FCF75CB.5050208@biblibre.com>

Le 06/06/2012 15:55, Kyle Hall a ?crit :
> I agree with paul here. I think in the optimal solution would be a
> table prefix for every column, so we have *zero* name clashes for
> joins. I doubt we will get there any time soon, but it is something to
> thing about. It simplifies queries, whereas having id as the pk for
> each table convolutes and complicates queries.

Kyle,

I can't remember where I saw this, but it's an old practise, that is not
recommended anymore (SQL generally speaking)

Plus I think this is something we can't introduce now without rewriting
a lot of things everywhere.

OTOH, I think updating primary key names is something more achievable,
even if won't be made in 2 clics, I agree.

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From kyle.m.hall at gmail.com  Wed Jun  6 21:24:56 2012
From: kyle.m.hall at gmail.com (Kyle Hall)
Date: Wed, 6 Jun 2012 20:24:56 +0100
Subject: [Koha-devel] [DISCUSSION] Database schema & coding guidelines
In-Reply-To: <4FCF75CB.5050208@biblibre.com>
References: <4FBFAC96.6050906@biblibre.com> <4FBFB1E4.3050506@msys.ch>
	<4FCF3DDE.1070106@biblibre.com>
	<CACpVHfwxHGW+CRT42siZVrqqcyKXE4BZANFEEjwYyYH97US85w@mail.gmail.com>
	<4FCF75CB.5050208@biblibre.com>
Message-ID: <CACpVHfw4LwNsCqO17HqezAXR7J1yJwvxfA2b4dau5+mSNj0D4A@mail.gmail.com>

My favorite solution is to use DBix::Class. With the proper mappings
only keys should really need to be unique. Eventually, the table
classes could in theory hold much of the model code that is in various
C4 modules, in an object-oriented manner.

Kyle

http://www.kylehall.info
ByWater Solutions ( http://bywatersolutions.com )
Meadville Public Library ( http://www.meadvillelibrary.org )
Crawford County Federated Library System ( http://www.ccfls.org )
Mill Run Technology Solutions ( http://millruntech.com )


On Wed, Jun 6, 2012 at 4:22 PM, Paul Poulain <paul.poulain at biblibre.com> wrote:
> Le 06/06/2012 15:55, Kyle Hall a ?crit :
>> I agree with paul here. I think in the optimal solution would be a
>> table prefix for every column, so we have *zero* name clashes for
>> joins. I doubt we will get there any time soon, but it is something to
>> thing about. It simplifies queries, whereas having id as the pk for
>> each table convolutes and complicates queries.
>
> Kyle,
>
> I can't remember where I saw this, but it's an old practise, that is not
> recommended anymore (SQL generally speaking)
>
> Plus I think this is something we can't introduce now without rewriting
> a lot of things everywhere.
>
> OTOH, I think updating primary key names is something more achievable,
> even if won't be made in 2 clics, I agree.
>
> --
> 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 paul.poulain at biblibre.com  Thu Jun  7 11:08:27 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 07 Jun 2012 11:08:27 +0200
Subject: [Koha-devel] Some things i'd like to work on during the hackfest
Message-ID: <4FD06F8B.1050002@biblibre.com>

Hello koha-devel,

I wrote (with Claire) a list of things I'd like to work on during the
hackfest. I spoke of this list with MJ who told me I should send it
here, so I do...

Hackfest Kohacon 2012

? Discussions:
? how chris is managing patches pushed to master that must be pushed to
stable ? (not like chris_n I think)
? explanations around jenkins = checkstyle, what does it do ? what kind
of tuning is possible ? Same question for Clover Code Coverage.
? Question about unit tests in Koha = how to write them, good practises ?
? naming conventions / organisation for Koha:: namespace (define
business logic / data access directory & file organisation. Use Moose ?)
? Default assignee for bugzilla
? gerrit = chris_c, what would/could be the next step ? (continuing the
discussion & reporting it to koha-devel)


? BibLibre upcoming patches: we have a lot of patches to submit, a chart
showing the progress, present what's pending.
? signoff patches (question = how to order them ? I suggest by date, to
take care of the oldest ones first)
? francharb = want to get explanation for issuing rules behaviour
? solr work already made by BibLibre, next steps

Various/minor:
? The french translation shows 100% done, the translated Koha lack a lot
of translated things. Investigate to understand why.
? bulkmarcimport, option for removing items in records with zillions of
items

-- 
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 Jun  7 11:46:36 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 07 Jun 2012 11:46:36 +0200
Subject: [Koha-devel] Some things i'd like to work on during the hackfest
In-Reply-To: <CANnhVG8Q2_WG1Qj2i2+Hscqz2_y2=SFMc=sDfF9NEgxZVFbtzQ@mail.gmail.com>
References: <CANnhVG8Q2_WG1Qj2i2+Hscqz2_y2=SFMc=sDfF9NEgxZVFbtzQ@mail.gmail.com>
Message-ID: <4FD0787C.5050506@biblibre.com>

An answer John sent to me alone by mistake

(feel free to add your own whishes/thoughts for the hackfest ;-) )
-------- Message original --------
Sujet: 	Re: [Koha-devel] Some things i'd like to work on during the hackfest
Date : 	Thu, 7 Jun 2012 05:40:36 -0400
De : 	Brice, John <jbrice at ccfls.org>
Pour : 	Paul Poulain <paul.poulain at biblibre.com>



To All:

Since I am not a programmer I am willing to work on documentation and
sign off on patches.

I would like to see us carve out 60 or 90 mins to talk about the next
big step.

I currently need to have the capability for storing searching and
serving up ebooks, electronic formats.  I would like to know what we
have to do to get this capability from Koha.

John Brice

On Thu, Jun 7, 2012 at 5:08 AM, Paul Poulain <paul.poulain at biblibre.com
<mailto:paul.poulain at biblibre.com>> wrote:

    Hello koha-devel,

    I wrote (with Claire) a list of things I'd like to work on during the
    hackfest. I spoke of this list with MJ who told me I should send it
    here, so I do...

    Hackfest Kohacon 2012

    ? Discussions:
    ? how chris is managing patches pushed to master that must be pushed to
    stable ? (not like chris_n I think)
    ? explanations around jenkins = checkstyle, what does it do ? what kind
    of tuning is possible ? Same question for Clover Code Coverage.
    ? Question about unit tests in Koha = how to write them, good
    practises ?
    ? naming conventions / organisation for Koha:: namespace (define
    business logic / data access directory & file organisation. Use Moose ?)
    ? Default assignee for bugzilla
    ? gerrit = chris_c, what would/could be the next step ? (continuing the
    discussion & reporting it to koha-devel)


    ? BibLibre upcoming patches: we have a lot of patches to submit, a chart
    showing the progress, present what's pending.
    ? signoff patches (question = how to order them ? I suggest by date, to
    take care of the oldest ones first)
    ? francharb = want to get explanation for issuing rules behaviour
    ? solr work already made by BibLibre, next steps

    Various/minor:
    ? The french translation shows 100% done, the translated Koha lack a lot
    of translated things. Investigate to understand why.
    ? bulkmarcimport, option for removing items in records with zillions of
    items

    --
    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
    <mailto: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/




-- 
/John J. Brice, III/
___________________________________________________________________________________
Executive Director
Meadville Public Library
848 North Main Street
Meadville, PA 16335

814-336-1773 ext 302


-- 
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 Jun  7 11:50:59 2012
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Thu, 7 Jun 2012 21:50:59 +1200
Subject: [Koha-devel] Some things i'd like to work on during the hackfest
In-Reply-To: <4FD0787C.5050506@biblibre.com>
References: <CANnhVG8Q2_WG1Qj2i2+Hscqz2_y2=SFMc=sDfF9NEgxZVFbtzQ@mail.gmail.com>
	<4FD0787C.5050506@biblibre.com>
Message-ID: <CA+95qVSt2kEm6ZPJ3kwJL2fTNx0te-r1MCe6APLMPsS+jtu1HA@mail.gmail.com>

I also want to work on getting more signoffs, so I have started

http://scoreboard.koha-community.org/

Every patch that you sign off, you save one kitten
Every patch you send, another kitten
Every patch you rescue from Failed QA or does not apply, another kitten saved.

Whomever saves the most kittens in the hackfest, wins the bottle of
Crowded House Pinot Noir, I have brought with me from New Zealand.

Chris

On 7 June 2012 21:46, Paul Poulain <paul.poulain at biblibre.com> wrote:
> An answer John sent to me alone by mistake
>
> (feel free to add your own whishes/thoughts for the hackfest ;-) )
> -------- Message original --------
> Sujet: ?Re: [Koha-devel] Some things i'd like to work on during the hackfest
> Date : ?Thu, 7 Jun 2012 05:40:36 -0400
> De : ? ?Brice, John <jbrice at ccfls.org>
> Pour : ?Paul Poulain <paul.poulain at biblibre.com>
>
>
>
> To All:
>
> Since I am not a programmer I am willing to work on documentation and
> sign off on patches.
>
> I would like to see us carve out 60 or 90 mins to talk about the next
> big step.
>
> I currently need to have the capability for storing searching and
> serving up ebooks, electronic formats. ?I would like to know what we
> have to do to get this capability from Koha.
>
> John Brice
>
> On Thu, Jun 7, 2012 at 5:08 AM, Paul Poulain <paul.poulain at biblibre.com
> <mailto:paul.poulain at biblibre.com>> wrote:
>
> ? ?Hello koha-devel,
>
> ? ?I wrote (with Claire) a list of things I'd like to work on during the
> ? ?hackfest. I spoke of this list with MJ who told me I should send it
> ? ?here, so I do...
>
> ? ?Hackfest Kohacon 2012
>
> ? ?? Discussions:
> ? ?? how chris is managing patches pushed to master that must be pushed to
> ? ?stable ? (not like chris_n I think)
> ? ?? explanations around jenkins = checkstyle, what does it do ? what kind
> ? ?of tuning is possible ? Same question for Clover Code Coverage.
> ? ?? Question about unit tests in Koha = how to write them, good
> ? ?practises ?
> ? ?? naming conventions / organisation for Koha:: namespace (define
> ? ?business logic / data access directory & file organisation. Use Moose ?)
> ? ?? Default assignee for bugzilla
> ? ?? gerrit = chris_c, what would/could be the next step ? (continuing the
> ? ?discussion & reporting it to koha-devel)
>
>
> ? ?? BibLibre upcoming patches: we have a lot of patches to submit, a chart
> ? ?showing the progress, present what's pending.
> ? ?? signoff patches (question = how to order them ? I suggest by date, to
> ? ?take care of the oldest ones first)
> ? ?? francharb = want to get explanation for issuing rules behaviour
> ? ?? solr work already made by BibLibre, next steps
>
> ? ?Various/minor:
> ? ?? The french translation shows 100% done, the translated Koha lack a lot
> ? ?of translated things. Investigate to understand why.
> ? ?? bulkmarcimport, option for removing items in records with zillions of
> ? ?items
>
> ? ?--
> ? ?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
> ? ?<mailto: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/
>
>
>
>
> --
> /John J. Brice, III/
> ___________________________________________________________________________________
> Executive Director
> Meadville Public Library
> 848 North Main Street
> Meadville, PA 16335
>
> 814-336-1773 ext 302
>
>
> --
> 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 mtompset at hotmail.com  Thu Jun  7 11:52:29 2012
From: mtompset at hotmail.com (Mark Tompsett)
Date: Thu, 7 Jun 2012 17:52:29 +0800
Subject: [Koha-devel] Some things i'd like to work on during the hackfest
In-Reply-To: <4FD0787C.5050506@biblibre.com>
References: <CANnhVG8Q2_WG1Qj2i2+Hscqz2_y2=SFMc=sDfF9NEgxZVFbtzQ@mail.gmail.com>
	<4FD0787C.5050506@biblibre.com>
Message-ID: <SNT117-DS1199DDA0AAACE6AF77557FC6F30@phx.gbl>

Greetings,

--- SNIP ---
I currently need to have the capability for storing searching and
serving up ebooks, electronic formats.  I would like to know what we
have to do to get this capability from Koha.
--- SNIP ---

Here! Here! I know my librarian colleagues are going to be asking for this. 
It was already mentioned in passing.
++idea

GPML,
Mark Tompsett


From dpavlin at rot13.org  Thu Jun  7 12:51:32 2012
From: dpavlin at rot13.org (Dobrica Pavlinusic)
Date: Thu, 7 Jun 2012 12:51:32 +0200
Subject: [Koha-devel] Some things i'd like to work on during the hackfest
In-Reply-To: <SNT117-DS1199DDA0AAACE6AF77557FC6F30@phx.gbl>
References: <CANnhVG8Q2_WG1Qj2i2+Hscqz2_y2=SFMc=sDfF9NEgxZVFbtzQ@mail.gmail.com>
	<4FD0787C.5050506@biblibre.com>
	<SNT117-DS1199DDA0AAACE6AF77557FC6F30@phx.gbl>
Message-ID: <20120607105132.GB12710@mjesec.ffzg.hr>

On Thu, Jun 07, 2012 at 05:52:29PM +0800, Mark Tompsett wrote:
> Greetings,
> 
> --- SNIP ---
> I currently need to have the capability for storing searching and
> serving up ebooks, electronic formats.  I would like to know what we
> have to do to get this capability from Koha.
> --- SNIP ---
> 
> Here! Here! I know my librarian colleagues are going to be asking
> for this. It was already mentioned in passing.
> ++idea

We had similar question raised yesterday on panel, so I hope that we can
talk about this issue during hackfest (especially since we have similar
need :-)

From cnighswonger at foundations.edu  Thu Jun  7 14:32:19 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Thu, 7 Jun 2012 08:32:19 -0400
Subject: [Koha-devel] Some things i'd like to work on during the hackfest
In-Reply-To: <4FD0787C.5050506@biblibre.com>
References: <CANnhVG8Q2_WG1Qj2i2+Hscqz2_y2=SFMc=sDfF9NEgxZVFbtzQ@mail.gmail.com>
	<4FD0787C.5050506@biblibre.com>
Message-ID: <CAP3yOom8Y5VAYfoPER48NUbjdiNVKJwu6LbNp2HnLmX3pQLZOg@mail.gmail.com>

On Thu, Jun 7, 2012 at 5:46 AM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> An answer John sent to me alone by mistake
>
> (feel free to add your own whishes/thoughts for the hackfest ;-) )
> -------- Message original --------
> Sujet:  Re: [Koha-devel] Some things i'd like to work on during the
> hackfest
> Date :  Thu, 7 Jun 2012 05:40:36 -0400
> De :    Brice, John <jbrice at ccfls.org>
> Pour :  Paul Poulain <paul.poulain at biblibre.com>
>
> I currently need to have the capability for storing searching and
> serving up ebooks, electronic formats.  I would like to know what we
> have to do to get this capability from Koha.
>
>
I'd be much interested in this discussion as well.

I've been messing around with integrating the Openlibrary Bookreader (
http://openlibrary.org/dev/docs/bookreader) with our Koha installation in
order to serve up various Openlibrary ebooks. At this point, I have a
Bookreader server setup and some linkage to it in the associated item
records.

Kind Regards,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120607/fe048038/attachment.htm>

From marc at msys.ch  Sat Jun  9 11:49:36 2012
From: marc at msys.ch (Marc Balmer)
Date: Sat, 09 Jun 2012 11:49:36 +0200
Subject: [Koha-devel] [DISCUSSION] Database schema & coding guidelines
In-Reply-To: <4FCF3DDE.1070106@biblibre.com>
References: <4FBFAC96.6050906@biblibre.com> <4FBFB1E4.3050506@msys.ch>
	<4FCF3DDE.1070106@biblibre.com>
Message-ID: <4FD31C30.6040905@msys.ch>

Am 06.06.12 13:24, schrieb Paul Poulain:
> Le 25/05/2012 18:23, Marc Balmer a ?crit :
>> I contradict.  This results neither in complexity nor in mistakes.
>> Imagine two tables, A and B, which both have an id column, then a select
>> would probably look like the following:
>>
>> select A.id as aid, B.id as bid from A, B, where ...
>>
>> So it's not a problem.
> 
> I contradict your contradiction.
> If you have branches.id as identifier, then, the FK in borrowers table
> (the branch of the patron) can't be id, as, in your proposition, the
> identifier of the borrower will be borrower.id
> 
> It means instead of :
> borrowers(borrower_id,surname,firstname,branch_id) /
> branches(branch_id,name) / SELECT * FROM borrowers LEFT JOIN branches
> USING(branch_id) and use all field in a hash, your option would result in:
> 
> borrowers(id,surname,firstname,branch_fk_id) / branches(id,name) /
> SELECT borrowers.*,branches.id as bid,branches.name LEFT JOIN branches
> ON (borrowers.branch_fk_id,branches.id), and deal with bid as a hash entry.
> 
> So, depending on the part of Koha you'll refer to $borrowers->{bid} or
> $branch->{id}
> 
> I can't imagine a second that would be easier to read. No gain, big
> loss, this option must be forgotten according to me.


From paul.poulain at biblibre.com  Sat Jun  9 11:54:00 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Sat, 09 Jun 2012 11:54:00 +0200
Subject: [Koha-devel] DOM indexing patch pushed (call for more tests !)
Message-ID: <4FD31D38.90308@biblibre.com>

Hello koha-devel,

I just pushed bug 7818, that is related to DOM indexing. This bug
changes nothing or changes a lot of things, depending on your situation.
Anyway, it need a lot of extensive testing, it's a good thing that it's
pushed more than 4 months before the next release.

If you have a Koha already running and don't change your configuration,
it shouldn't change anything.
If you install a new Koha, by default, the configuration will be dom by
default (you still can choose the old grs1 configuration)
If you have a Koha already running and want to get the benefits from DOM
indexing, head to the wiki page:
http://wiki.koha-community.org/wiki/Switching_to_dom_indexing, use it
(and report anything missing)

What does DOM indexing change ?
It gives improved ranking, a more modern way of indexing in zebra and a
tiny speed improvement.
Note that all what is described in bug 7818 has not been made, so if you
read the initial description, don't be surprised.

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From marc at msys.ch  Sat Jun  9 11:54:26 2012
From: marc at msys.ch (Marc Balmer)
Date: Sat, 09 Jun 2012 11:54:26 +0200
Subject: [Koha-devel] [DISCUSSION] Database schema & coding guidelines
In-Reply-To: <CACpVHfw4LwNsCqO17HqezAXR7J1yJwvxfA2b4dau5+mSNj0D4A@mail.gmail.com>
References: <4FBFAC96.6050906@biblibre.com> <4FBFB1E4.3050506@msys.ch>
	<4FCF3DDE.1070106@biblibre.com>
	<CACpVHfwxHGW+CRT42siZVrqqcyKXE4BZANFEEjwYyYH97US85w@mail.gmail.com>
	<4FCF75CB.5050208@biblibre.com>
	<CACpVHfw4LwNsCqO17HqezAXR7J1yJwvxfA2b4dau5+mSNj0D4A@mail.gmail.com>
Message-ID: <4FD31D52.40002@msys.ch>

Am 06.06.12 21:24, schrieb Kyle Hall:
> My favorite solution is to use DBix::Class. With the proper mappings
> only keys should really need to be unique. Eventually, the table
> classes could in theory hold much of the model code that is in various
> C4 modules, in an object-oriented manner.

We have to be careful when introducing ORM-like concepts not to loose
beneficial features of the underlying database.  More often than not a
database abstraction layers lead to a situation where we can only use
the common subset of the databases being used, loosing the advanced
features a database server might have to offer.

And in a complex database based application you most probably want to
make use of such features (and yes, without knowing, we do so when using
e.g. the MySQL query cache).

In practice that means that applications running on multiple databases
will have in some cases different code paths for the respective
databases.  Or using different SQL.

From jcamins at cpbibliography.com  Sat Jun  9 13:51:40 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Sat, 9 Jun 2012 06:51:40 -0500
Subject: [Koha-devel] Authority control - request for comments
Message-ID: <CALVDfQwXwAoU8J94odwXKxx6aMe2HaRpaQ1=pWeQSMX3BXp4gQ@mail.gmail.com>

Good time of day!

I plan to do a great deal of work on the authority module, and I wanted to
request that anyone with thoughts on the matter please share them with me.
The RFC is on the wiki at
http://wiki.koha-community.org/wiki/C_%26_P_Authority_Control_Improvements_RFCand
I have copied the description below.

Description

The development is divided into 14 parts:

   1. A dropdown box will be added to the authority browser in the OPAC
   allowing the user to choose which index to search in authorities: the
   keyword index, the match heading index (i.e. all heading fields), the
   preferred heading index, or the main entry only index. (bug 8206)
   2. Because importing large authority files can result in unused
   authority records overwhelming used authority records in OPAC authority
   browse results, some libraries may want to disable the display of
   authorities which are not used in the bibliographic database. In order to
   make this possible (while still retaining the existing behavior of
   displaying all records in the authority file as a default), a system
   preference OPACShowUnusedAuthorities will be created, and a "Show all
   results" link added to search results when it is enabled. (bug 8205)
   3. Because see also references in authority records are intended to
   refer to other authority records, they really ought to be turned into
   hyperlinks in the various authority displays. They will be made into
   hyperlinks (using the authid in $9 if available, or a search string
   otherwise) in both the OPAC and the staff client. (bug 3462)
   4. At present, the only authority record view available in the OPAC is
   an "expanded MARC" view which is of no use to patrons, and limited use to
   librarians. We propose adding a user-friendly authority details view
   similar in design to the bib details view. (bug 8204)
   5. Although the batch import functionality was originally designed with
   importing both bibliographic and authority records in mind, authority
   import was never actually implemented. This will be done quite simply, by
   adding an option to choose which type of record to import in the Stage MARC
   records tool. (bug 2060)
   6. Match points will also be extended for use with authority records,
   again completing a feature for which stubs already existed. (bug 7475)
   7. There is no way to export authority records other than via a direct
   SQL query, which makes it difficult for hosted libraries to get their data
   out of Koha without the help of their support vendors. We propose to change
   the "Export bibliographic/holdings" tool to the "Export data" tool, and add
   a tab to enable librarians with the proper permissions for the export tool
   to export their authority records directly from the staff client. (bug 8202)
   8. Some librarians have requested the ability to save individual
   authority records, so a "Save authority" button will be added next to the
   "Edit" button when viewing authority records. (bug 8203)
   9. One of the great promises of DOM indexing in Zebra (and the adoption
   of solr as an indexing technology) is the ability to incorporate alternate
   forms of headings into bib records when exporting bibs for indexing. We
   will add the plumbing for arbitrary record filters, and implement a filter
   that checks each heading in bib records for alternate forms, and includes
   them prior to exporting the record for indexing. (bug 7417)
   10. Instead of using only textual strings for see also links, the
   ability to use $9 in see also fields in authority records (5xx in MARC21,
   NORMARC, and UNIMARC) will be added, to simplify heading disambiguation.
   This will enable us to create a value builder plugin using the existing
   thesaurus functionality that will automatically populate the see also
   heading control fields with metadata about the link (broader term, narrower
   term, etc.) (bug 8207)
   11. Right now when cataloging, catalogers have only two options for
   adding a new authority: turn on AutoGenerateAuthorities, and later edit the
   authority record to justify its creation, or save the bib record they are
   working on, create a new authority record in the authority module, wait for
   the new record to be indexed, and open the bib record back up to use the
   authority finder plugin. We intend to add a "Create authority" button to
   the authority finder plugin which will allow the cataloger to create an
   authority in a new window and (similar to fast add in circ) automatically
   fill out the selected heading field in the bib record. (bug 8208)
   12. At times, people may want to search for terms that are related to
   the one they search for. For example, someone interested in books about
   Feet may also be interested in all books about specific parts of feet,
   including books about Toes, Heels, etc. We will add three new special
   pseudo-CCL search prefixes which will first search the authority file for
   the specified heading, then search not just for that term but also for
   broader terms (pseudo-CCL prefix su-br:), narrower terms (pseudo-CCL prefix
   su-na:), or all related terms (pseudo-CCL prefix su-rl:). (bug 8211)
   13. Because patrons may not always realize that they want to search for
   a related term instead of the term they entered, we will also add a "Did
   you mean?" feature to the OPAC, which suggests terms related to authorities
   that match the user's search. (bug 8209)
   14. Although not all authority records contain useful information, many
   do, and depending on the type of collection, access to that information can
   be critical to both librarians and patrons. In order to simplify looking up
   authorities referred to in particular records, a link from subject headings
   to their related authorities will be added to the OPAC. A patch which adds
   this to the "normal" mode bib details display has already Passed QA (bug
   5888), so unless an unsolvable problem is found with that patch,
   implementation will focus on the XSLT view. (bug 8210)

Any questions or comments are welcome.

Regards,
Jared Camins-Esakov

-- 
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: </pipermail/koha-devel/attachments/20120609/f8ebc333/attachment.htm>

From jcamins at cpbibliography.com  Sat Jun  9 13:58:40 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Sat, 9 Jun 2012 06:58:40 -0500
Subject: [Koha-devel] Koha:: namespace
Message-ID: <CALVDfQzvw83=c=izgFV-Un6UFQZHDQQ0=sg+FTcJD9dBiGAzFQ@mail.gmail.com>

Good time of day (again!),

I know Paul is going to be talking about the Koha:: namespace tomorrow, but
since I can't be in KohaCon in person I wanted to share a few of my
thoughts and maybe help him out with getting the conversation started. As
part of the authority control improvements I'll be working on, I'm going to
be doing a fair amount of code cleanup, which in many cases will involve
moving the non-offending parts of the code to the Koha:: namespace (I don't
know if this is an American expression, but there's a saying that you can't
make a silk purse out of a sow's ear, which pretty much sums up how parts
of C4:: are). On the plane on the way back from Lawrence I jotted down a
few notes on how parts of the Koha:: namespace might look, and wanted to
share them. I'm not sure if the ASCII graphics will come through in the
e-mail, but this is also at the end of the authority control improvements
RFC at
http://wiki.koha-community.org/wiki/C_%26_P_Authority_Control_Improvements_RFC

Any suggestions how to improve things (or, even better, consensus!) would
be most welcome.

+ Koha::Cache - object-oriented class for caching data in Koha
|
+--- Koha::Cache::Fastmmap - mmap driver class for Koha caching
|    (implemented in bug 8092)
|
+--- Koha::Cache::Memcached - memcached driver class for Koha caching
|    (implemented by bug 7248)
|
+--- Koha::Cache::Memory - in-process driver class for Koha caching
|    (implemented in bug 8092)
|
+--- Koha::Cache::Memory - in-process driver class for Koha caching
     (implemented in bug 8092)

+ Koha::Calendar - object-oriented class for handling branch opening
  calendars

& Koha::Context - exporter class for basic configuration information
  (note: a better option might be Koha::Koha as an object-oriented
  alternative to Koha::Context; C & P will implement the start of
  the latter, if that is the consensus of the community)

& Koha::DateUtils - exporter shim class to ease migration to DateTime
  from date-only strings

# Koha::Filter - virtual parent class for all record processor filters
|
+--* Koha::Filter::[metadata schema]::* -
   | object-oriented classes extending Koha::RecordProcessor::Base
   | which implement particular record processing functionalities
   \
    +--- Koha::Filter::MARC::EmbedItems - filter for embedding items in
    | bib records for the indexing process
    |
    +--- Koha::Filter::MARC::EmbedSeeFromHeadings - filter for embedding
         see from headings in bib records for the indexing process

+ Koha::Heading - object-oriented class representing
| authority-controlled headings
|
+--- Koha::Heading::MARC21 - object-oriented MARC21 heading handler for
|    Koha::Heading
|
+--- Koha::Heading::UNIMARC - object-oriented UNIMARC heading handler
     for Koha::Heading

+ Koha::Indexer::Utils - indexer utility functions (implemented by
  bug 7818)

# Koha::Linker - virtual parent class for heading-authority linker
| modules
|
+--* Koha::Linker::* - object-oriented linker modules for linking
   | headings to authorities
   \
    +--- Koha::Linker::Default - default linker module
    |
    +--- Koha::Linker::FirstMatch - linker module that always selects
    |    the first match it finds
    |
    +--- Koha::Linker::LastMatch - linker module that always selects the
         last match it finds

# Koha::Record - virtual parent class for all types of records handled
| by Koha
|
+--- Koha::Record::Biblio - object-oriented class representing
|    bibliographic records
|
+--+ Koha::Record::Authority - object-oriented class representing
|  | authority records
|  |
|  &--- Koha::Record::Authority::Handler::MARC21 - exporter class
|  |    with MARC21-specific routines for Koha::Record::Authority
|  |    (should be used only by Koha::Record::Authority)
|  |
|  &--- Koha::Record::Authority::Handler::UNIMARC - exporter class
|       with UNIMARC-specific routines for Koha::Record::Authority
|       (should be used only by Koha::Record::Authority)
|
+--* Koha::Record::Holdings - hypothetical object-oriented class
|    representing holdings records
|
+--- Koha::Record::Item - object-oriented class representing item
     records

+ Koha::RecordProcessor - object-oriented class for processing records
  using various filters

& Koha::Search - exporter class offering access to searching
| functionality via Koha::Search::Engine
|
+--+ Koha::Search::Engine - object-oriented class which dispatches
|  | calls into the specific search engine module
|  |
|  +--- Koha::Search::Engine::Solr - class which interfaces with solr
|  |    for searching
|  |
|  +--- Koha::Search::Engine::Zebra - class which interfaces with Zebra
|       for searching
|
+--# Koha::Search::Plugin - virtual parent class for search plugins
|  |
|  +--- Koha::Search::Plugin::* - plugins implementing particular search
|       functionality
|
+--+ Koha::Search::Query - object-oriented class which generates queries
   |
   +--- Koha::Search::Query::Solr - class to generate Solr queries
   |
   +--- Koha::Search::Query::Zebra - class to generate Zebra queries

+ Koha::Template::Plugin::* - plugins for Template Toolkit

& Koha::Utils - exporter class for utility functions required by many
| parts of Koha (no dependencies other than Koha::Context)
|
&--- Koha::Utils::Authorities - exporter class for utility functions
|    related to authorities that do not act on an individual authority
|
&--- Koha::Utils::Biblios - exporter class for utility functions
     related to bibliographic records that do not act on an individual
     biblio

Legend:
+       indicates an object-oriented class (or classes, in some cases)
+---    indicates an object-oriented class that is further down in the
        hierarchy (may or may not be a subclass)
+--+    indicates an object-oriented subclass that is extended
#       indicates a virtual object-oriented parent class
+--#    indicates a virtual object-oriented parent class which is
        further down in the hierarchy
&       indicates an exporter class
&---    indicates an exporter subclass
*       indicates a hypothetical or example class
\       indicates that the class(es) below this symbol provide (a)
        specific example(s) of the hypothetical or example class above
        the symbol

NOTE: I do not propose to implement all of this as part of the authority
project. C & P's authority development will create the following classes
in the Koha:: namespace:
+ Koha::Filter
+ Koha::Filter::MARC::EmbedSeeFromHeadings
+ Koha::Heading::*
+ Koha::Record::Authority::*
+ Koha::RecordProcessor
+ Koha::Utils::Authorities (possibly)

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: </pipermail/koha-devel/attachments/20120609/50d7bd41/attachment-0001.htm>

From paul.poulain at biblibre.com  Sat Jun  9 17:21:21 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Sat, 09 Jun 2012 17:21:21 +0200
Subject: [Koha-devel] bugzilla default assignee changes
Message-ID: <4FD369F1.5040407@biblibre.com>

Hello,

During the hackfest, we reviewed the default assignee for all
components. Some ppl that were default were at the meeting, some weren't

What appears the best option to us: if you're a default assignee for a
given component, it mean you accept to take care of any new bug opened
on this component (even if taking care means saying you won't fix the bug).
It means we think the best option is to have the koha-bugs mailing list
as default assignee, as it's "anonymous".

We already made the following changes on components:
- removed henridamien & paul default assignee on many (10 ?) components,
set to koha-bugs@ mailing list
- translation component: removed chris_c as default assignee  set
koha-bugs@ mailing list & added Frederic Demians as cc: as he requested
on this list last month
- Circulation and patron: moved Kyle to cc (keeping galen as cc too),
default assignee is now koha-bugs@ ML
- I18N : moved Frederic to cc:, koha-bugs@ ML is default assignee
- contribs, bugs, imported_bugs : removed chris_c and koha-bugs@ ML is
default assignee

GALEN & IAN =
You're default assignee for many/some components. Do you confirm you
want to take care of those bugs or should we put koha-bugs mailing list
as default ?
(Galen, I think you're default because you've been RM for 3.2, and
no-one changes since this time)

OWEN & NICOLE & LIZ & CHRIS_N
We haven't changed the components you're default, because you said last
month it was OK for you.

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From chris.nighswonger at gmail.com  Sat Jun  9 19:11:17 2012
From: chris.nighswonger at gmail.com (Christopher Nighswonger)
Date: Sat, 9 Jun 2012 13:11:17 -0400
Subject: [Koha-devel] bugzilla default assignee changes
In-Reply-To: <4FD369F1.5040407@biblibre.com>
References: <4FD369F1.5040407@biblibre.com>
Message-ID: <CAA7=B8zzhV53e3mJD=p0MbXqK12M92a=AgE0aKfeoDHRZ+apFA@mail.gmail.com>

On Sat, Jun 9, 2012 at 11:21 AM, Paul Poulain <paul.poulain at biblibre.com> wrote:
>
> OWEN & NICOLE & LIZ & CHRIS_N
> We haven't changed the components you're default, because you said last
> month it was OK for you.
>

That sounds good.

Kind Regards,
Chris

From paul.poulain at biblibre.com  Sun Jun 10 16:27:11 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Sun, 10 Jun 2012 16:27:11 +0200
Subject: [Koha-devel] SIP brainstorming during the hackfest
Message-ID: <4FD4AEBF.6020108@biblibre.com>

During the hackfest, we had a discussion/brainstorming around SIP
server, here is a feedback of what we said

Ppl participating the discussion: Marc B, Dobrica, Kyle Hall, Colin C,
Paul P, Matthias M, Adrien S

The SIP server:
 * is not very robust (fail badly if it receive a bad line) bug & patch
already in bugzilla

 * the SIP protocol it's not complete:
    - fees are grouped, "pay 50", it should be "pay 4+3+5..."
    - atm, a patron can't pay a payment if there is no debt. That would
be useful to pay registrations a few days before my account expire
 Marc Balmer goal is to be deal with that, but it's not in the SIP2
protocol (the protocol does not specify how to do it)

 * SIP3 = the new protocol is being developed, and addresses those
problems. 3M has announced that SIP will be placed in the hand of a NPO
and become a NISO protocol

 * We should write a new SIP server for Koha, dealing with SIP3. SIP2
will continue for a while, so we must have (and maintain) both servers.

 *  our SIP2 implementation was shared with Evergreen, but it's no more
the case, and Colin thinks we should not try to merge again, because we
wouldn't gain anything specific.

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From marc at msys.ch  Sun Jun 10 17:43:09 2012
From: marc at msys.ch (Marc Balmer)
Date: Sun, 10 Jun 2012 17:43:09 +0200
Subject: [Koha-devel] Experimental support for MARC records as a proper
 datatype in the PostgreSQL database
Message-ID: <4FD4C08D.6040908@msys.ch>

Sitting in one of the nice pubs in Edinburgh during KohaCon, I had this
idea to add MARC records as a proper datatype to the PostgreSQL database
server.  After a discussion with Marc V?ron and Dobrica Pavlinusic about
what that could mean, I decided to just try it and I have now a basic
implementation (or, more a proof of concept).  So here is some
information on this:

If MARC records are a proper datatype, that means they are stored right
in the database, are backed-up, can be restored, replicated etc. just
with the standard database tools.  If then a function is provided to
access individual fields of a MARC record, then this can be used in SQL
expressions, e.g. for selects or to create views etc.  As PostgreSQL
supports functional indexes, you can create indexes on individual MARC
fields, giving you super fast access to your data.

How does it look?

There is a datatype called 'marc' for now:

CREATE TABLE books (
    id serial,
    sig varchar(16),
    marc_record marc
);

MARC records are loaded into the database as raw, binary records,
encoded in hexadecimal:

INSERT INTO books (sig, marc_record) VALUES ('a01b', '3030383830.....');

To access individual MARC fields, the function 'marc_field()' was
created, it returns VARCHAR:

SELECT id, marc_field(marc_record, '020') AS isbn FROM books WHERE sig =
'a01b';

Of course MARC fields can be used to search data:

SELECT SELECT id, marc_field(marc_record, '020') AS isbn FROM books
WHERE marc_field(marc_record, '245') like 'whatever%';

An index on a specific field can easily be created:

CREATE INDEX books_isbn_idx ON books (marc_field(marc_record, '020'));

As a syntactic sugar, the expression marc_record@'020' is equal to
marc_field(marc_record, '020').

Marijana Glavica kindly let me use a MARC database of ~250'000 records
to make some tests, here are some real world examples:

books=# \d test_marc
                         Table "public.test_marc"
 Column |  Type   |                       Modifiers
--------+---------+--------------------------------------------------------
 id     | integer | not null default nextval('test_marc_id_seq'::regclass)
 marc21 | marc    |

books=# select count(id) from test_marc;
 count
--------
 246727
(1 row)

How many croatian books do they have?

books=# select count(id) from test_marc where
substring(marc_field(marc21, '008'), 37, 3) = 'hrv';
 count
-------
 52582
(1 row)

Of course much more complex queries are possible with this, and using
the right indexes it is really, really fast.  One query I tested when
from 8.4 seconds to 0.21 ms with the right index.  That's a speedup of
40'000.

Thanks to Marijana, Dobrica, and Marc for feedback, interesting
discussions and ideas!

Feedback and suggestions are of course more than welcome.

- Marc

From kyle.m.hall at gmail.com  Sun Jun 10 21:41:26 2012
From: kyle.m.hall at gmail.com (Kyle Hall)
Date: Sun, 10 Jun 2012 20:41:26 +0100
Subject: [Koha-devel] Koha:: namespace
In-Reply-To: <CALVDfQzvw83=c=izgFV-Un6UFQZHDQQ0=sg+FTcJD9dBiGAzFQ@mail.gmail.com>
References: <CALVDfQzvw83=c=izgFV-Un6UFQZHDQQ0=sg+FTcJD9dBiGAzFQ@mail.gmail.com>
Message-ID: <CACpVHfwLww0V8o+V4HxbrXNDpkVYoV1JQKXif7XQyG7pFEXA7g@mail.gmail.com>

I've written up our brainstorming session and put it on the wiki here:
http://wiki.koha-community.org/wiki/Koha_Namespace_RFC
It is a bit difficult to put these ideas down in plain text, so I
apologize if it is not very clear.

Kyle

http://www.kylehall.info
ByWater Solutions ( http://bywatersolutions.com )
Meadville Public Library ( http://www.meadvillelibrary.org )
Crawford County Federated Library System ( http://www.ccfls.org )
Mill Run Technology Solutions ( http://millruntech.com )


On Sat, Jun 9, 2012 at 12:58 PM, Jared Camins-Esakov
<jcamins at cpbibliography.com> wrote:
> Good time of day (again!),
>
> I know Paul is going to be talking about the Koha:: namespace tomorrow, but
> since I can't be in KohaCon in person I wanted to share a few of my thoughts
> and maybe help him out with getting the conversation started. As part of the
> authority control improvements I'll be working on, I'm going to be doing a
> fair amount of code cleanup, which in many cases will involve moving the
> non-offending parts of the code to the Koha:: namespace (I don't know if
> this is an American expression, but there's a saying that you can't make a
> silk purse out of a sow's ear, which pretty much sums up how parts of C4::
> are). On the plane on the way back from Lawrence I jotted down a few notes
> on how parts of the Koha:: namespace might look, and wanted to share them.
> I'm not sure if the ASCII graphics will come through in the e-mail, but this
> is also at the end of the authority control improvements RFC
> at?http://wiki.koha-community.org/wiki/C_%26_P_Authority_Control_Improvements_RFC
>
> Any suggestions how to improve things (or, even better, consensus!) would be
> most welcome.
>
> + Koha::Cache - object-oriented class for caching data in Koha
> |
> +--- Koha::Cache::Fastmmap - mmap driver class for Koha caching
> |    (implemented in bug 8092)
> |
> +--- Koha::Cache::Memcached - memcached driver class for Koha caching
> |    (implemented by bug 7248)
> |
> +--- Koha::Cache::Memory - in-process driver class for Koha caching
> |    (implemented in bug 8092)
> |
> +--- Koha::Cache::Memory - in-process driver class for Koha caching
>      (implemented in bug 8092)
>
> + Koha::Calendar - object-oriented class for handling branch opening
>   calendars
>
> & Koha::Context - exporter class for basic configuration information
>   (note: a better option might be Koha::Koha as an object-oriented
>   alternative to Koha::Context; C & P will implement the start of
>   the latter, if that is the consensus of the community)
>
> & Koha::DateUtils - exporter shim class to ease migration to DateTime
>   from date-only strings
>
> # Koha::Filter - virtual parent class for all record processor filters
> |
> +--* Koha::Filter::[metadata schema]::* -
>    | object-oriented classes extending Koha::RecordProcessor::Base
>    | which implement particular record processing functionalities
>    \
>     +--- Koha::Filter::MARC::EmbedItems - filter for embedding items in
>     | bib records for the indexing process
>     |
>     +--- Koha::Filter::MARC::EmbedSeeFromHeadings - filter for embedding
>          see from headings in bib records for the indexing process
>
> + Koha::Heading - object-oriented class representing
> | authority-controlled headings
> |
> +--- Koha::Heading::MARC21 - object-oriented MARC21 heading handler for
> |    Koha::Heading
> |
> +--- Koha::Heading::UNIMARC - object-oriented UNIMARC heading handler
>      for Koha::Heading
>
> + Koha::Indexer::Utils - indexer utility functions (implemented by
>   bug 7818)
>
> # Koha::Linker - virtual parent class for heading-authority linker
> | modules
> |
> +--* Koha::Linker::* - object-oriented linker modules for linking
>    | headings to authorities
>    \
>     +--- Koha::Linker::Default - default linker module
>     |
>     +--- Koha::Linker::FirstMatch - linker module that always selects
>     |    the first match it finds
>     |
>     +--- Koha::Linker::LastMatch - linker module that always selects the
>          last match it finds
>
> # Koha::Record - virtual parent class for all types of records handled
> | by Koha
> |
> +--- Koha::Record::Biblio - object-oriented class representing
> |    bibliographic records
> |
> +--+ Koha::Record::Authority - object-oriented class representing
> |  | authority records
> |  |
> |  &--- Koha::Record::Authority::Handler::MARC21 - exporter class
> |  |    with MARC21-specific routines for Koha::Record::Authority
> |  |    (should be used only by Koha::Record::Authority)
> |  |
> |  &--- Koha::Record::Authority::Handler::UNIMARC - exporter class
> |       with UNIMARC-specific routines for Koha::Record::Authority
> |       (should be used only by Koha::Record::Authority)
> |
> +--* Koha::Record::Holdings - hypothetical object-oriented class
> |    representing holdings records
> |
> +--- Koha::Record::Item - object-oriented class representing item
>      records
>
> + Koha::RecordProcessor - object-oriented class for processing records
>   using various filters
>
> & Koha::Search - exporter class offering access to searching
> | functionality via Koha::Search::Engine
> |
> +--+ Koha::Search::Engine - object-oriented class which dispatches
> |  | calls into the specific search engine module
> |  |
> |  +--- Koha::Search::Engine::Solr - class which interfaces with solr
> |  |    for searching
> |  |
> |  +--- Koha::Search::Engine::Zebra - class which interfaces with Zebra
> |       for searching
> |
> +--# Koha::Search::Plugin - virtual parent class for search plugins
> |  |
> |  +--- Koha::Search::Plugin::* - plugins implementing particular search
> |       functionality
> |
> +--+ Koha::Search::Query - object-oriented class which generates queries
>    |
>    +--- Koha::Search::Query::Solr - class to generate Solr queries
>    |
>    +--- Koha::Search::Query::Zebra - class to generate Zebra queries
>
> + Koha::Template::Plugin::* - plugins for Template Toolkit
>
> & Koha::Utils - exporter class for utility functions required by many
> | parts of Koha (no dependencies other than Koha::Context)
> |
> &--- Koha::Utils::Authorities - exporter class for utility functions
> |    related to authorities that do not act on an individual authority
> |
> &--- Koha::Utils::Biblios - exporter class for utility functions
>      related to bibliographic records that do not act on an individual
>      biblio
>
> Legend:
> +       indicates an object-oriented class (or classes, in some cases)
> +---    indicates an object-oriented class that is further down in the
>         hierarchy (may or may not be a subclass)
> +--+    indicates an object-oriented subclass that is extended
> #       indicates a virtual object-oriented parent class
> +--#    indicates a virtual object-oriented parent class which is
>         further down in the hierarchy
> &       indicates an exporter class
> &---    indicates an exporter subclass
> *       indicates a hypothetical or example class
> \       indicates that the class(es) below this symbol provide (a)
>         specific example(s) of the hypothetical or example class above
>         the symbol
>
> NOTE: I do not propose to implement all of this as part of the authority
> project. C & P's authority development will create the following classes
> in the Koha:: namespace:
> + Koha::Filter
> + Koha::Filter::MARC::EmbedSeeFromHeadings
> + Koha::Heading::*
> + Koha::Record::Authority::*
> + Koha::RecordProcessor
> + Koha::Utils::Authorities (possibly)
>
> 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/
>
>
> _______________________________________________
> 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 jcamins at cpbibliography.com  Sun Jun 10 22:41:04 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Sun, 10 Jun 2012 16:41:04 -0400
Subject: [Koha-devel] Koha:: namespace
In-Reply-To: <CACpVHfwLww0V8o+V4HxbrXNDpkVYoV1JQKXif7XQyG7pFEXA7g@mail.gmail.com>
References: <CALVDfQzvw83=c=izgFV-Un6UFQZHDQQ0=sg+FTcJD9dBiGAzFQ@mail.gmail.com>
	<CACpVHfwLww0V8o+V4HxbrXNDpkVYoV1JQKXif7XQyG7pFEXA7g@mail.gmail.com>
Message-ID: <CALVDfQxek96=7nmuD=_r8q06WNrnTWs+w4NRWMhRcOkiC_Of2Q@mail.gmail.com>

Kyle,

The writeup made perfect sense to me, and all of that sounds like a good
idea, with one exception: there is nothing about business logic being
object-oriented. Whenever possible, business logic code should be
object-oriented too. At least, that's my thought.

Regards,
Jared

On Sun, Jun 10, 2012 at 3:41 PM, Kyle Hall <kyle.m.hall at gmail.com> wrote:

> I've written up our brainstorming session and put it on the wiki here:
> http://wiki.koha-community.org/wiki/Koha_Namespace_RFC
> It is a bit difficult to put these ideas down in plain text, so I
> apologize if it is not very clear.
>
> Kyle
>
> http://www.kylehall.info
> ByWater Solutions ( http://bywatersolutions.com )
> Meadville Public Library ( http://www.meadvillelibrary.org )
> Crawford County Federated Library System ( http://www.ccfls.org )
> Mill Run Technology Solutions ( http://millruntech.com )


-- 
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: </pipermail/koha-devel/attachments/20120610/a4a09d28/attachment.htm>

From kyle.m.hall at gmail.com  Mon Jun 11 09:16:19 2012
From: kyle.m.hall at gmail.com (Kyle Hall)
Date: Mon, 11 Jun 2012 08:16:19 +0100
Subject: [Koha-devel] Koha:: namespace
In-Reply-To: <CALVDfQxek96=7nmuD=_r8q06WNrnTWs+w4NRWMhRcOkiC_Of2Q@mail.gmail.com>
References: <CALVDfQzvw83=c=izgFV-Un6UFQZHDQQ0=sg+FTcJD9dBiGAzFQ@mail.gmail.com>
	<CACpVHfwLww0V8o+V4HxbrXNDpkVYoV1JQKXif7XQyG7pFEXA7g@mail.gmail.com>
	<CALVDfQxek96=7nmuD=_r8q06WNrnTWs+w4NRWMhRcOkiC_Of2Q@mail.gmail.com>
Message-ID: <CACpVHfw=ZQqGUdn13yicEUJHc8mTEbhEqqqLyv9BOVJk_m7GjQ@mail.gmail.com>

I agree, but the existing rules for the Koha namespace ( what I am
calling Koha::BusinessLogic here ) do not require modules to be
strictly OO, though it is recommended. For that reason, it is not part
of the RFC. Perhaps we will need to discuss this as well.

Kyle

http://www.kylehall.info
ByWater Solutions ( http://bywatersolutions.com )
Meadville Public Library ( http://www.meadvillelibrary.org )
Crawford County Federated Library System ( http://www.ccfls.org )
Mill Run Technology Solutions ( http://millruntech.com )


On Sun, Jun 10, 2012 at 9:41 PM, Jared Camins-Esakov
<jcamins at cpbibliography.com> wrote:
> Kyle,
>
> The writeup made perfect sense to me, and all of that sounds like a good
> idea, with one exception: there is nothing about business logic being
> object-oriented. Whenever possible, business logic code should be
> object-oriented too. At least, that's my thought.
>
> Regards,
> Jared
>
>
> On Sun, Jun 10, 2012 at 3:41 PM, Kyle Hall <kyle.m.hall at gmail.com> wrote:
>>
>> I've written up our brainstorming session and put it on the wiki here:
>> http://wiki.koha-community.org/wiki/Koha_Namespace_RFC
>> It is a bit difficult to put these ideas down in plain text, so I
>> apologize if it is not very clear.
>>
>> Kyle
>>
>> http://www.kylehall.info
>> ByWater Solutions ( http://bywatersolutions.com )
>> Meadville Public Library ( http://www.meadvillelibrary.org )
>> Crawford County Federated Library System ( http://www.ccfls.org )
>> Mill Run Technology Solutions ( http://millruntech.com )
>
>
> --
> 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/
>

From paul.poulain at biblibre.com  Mon Jun 11 10:59:14 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Mon, 11 Jun 2012 10:59:14 +0200
Subject: [Koha-devel] "In discussion" bugs
Message-ID: <4FD5B362.3090207@biblibre.com>

Hello koha-devel,

Looking at bugs that are "In discussion", I see that there are more than
50. When we added this status, we decided that a bug "in discussion" had
to be discussed on the mailing list, it's not supposed to be a
forever-lasting status.

This is a reminder = bug reporter, patch author you're responsible for
managing the discussion ! So I encourage all of you to go to check if
you've a bug that is "in discussion" !

cheers
-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From mtj at kohaaloha.com  Mon Jun 11 12:54:56 2012
From: mtj at kohaaloha.com (Mason James)
Date: Mon, 11 Jun 2012 22:54:56 +1200
Subject: [Koha-devel] Experimental support for MARC records as a proper
	datatype in the PostgreSQL database
In-Reply-To: <4FD4C08D.6040908@msys.ch>
References: <4FD4C08D.6040908@msys.ch>
Message-ID: <4EBBE9EA-4705-44DB-9D7B-6ABE89A4E778@kohaaloha.com>


On 2012-06-11, at 3:43 AM, Marc Balmer wrote:

> Sitting in one of the nice pubs in Edinburgh during KohaCon, I had this
> idea to add MARC records as a proper datatype to the PostgreSQL database
> server.  After a discussion with Marc V?ron and Dobrica Pavlinusic about
> what that could mean, I decided to just try it and I have now a basic
> implementation (or, more a proof of concept).  So here is some
> information on this:
> 
> If MARC records are a proper datatype, that means they are stored right
> in the database, are backed-up, can be restored, replicated etc. just
> with the standard database tools.  If then a function is provided to
> access individual fields of a MARC record, then this can be used in SQL
> expressions, e.g. for selects or to create views etc.  As PostgreSQL
> supports functional indexes, you can create indexes on individual MARC
> fields, giving you super fast access to your data.



> 
> To access individual MARC fields, the function 'marc_field()' was
> created, it returns VARCHAR:
> 


wow, very impressive stuff!

could someone please paste the code of the 'marc_field() function?

-------------- 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: </pipermail/koha-devel/attachments/20120611/b85e8e01/attachment.pgp>

From koha.sekjal at gmail.com  Mon Jun 11 15:16:30 2012
From: koha.sekjal at gmail.com (Ian Walls)
Date: Mon, 11 Jun 2012 09:16:30 -0400
Subject: [Koha-devel] Authority control - request for comments
In-Reply-To: <CALVDfQwXwAoU8J94odwXKxx6aMe2HaRpaQ1=pWeQSMX3BXp4gQ@mail.gmail.com>
References: <CALVDfQwXwAoU8J94odwXKxx6aMe2HaRpaQ1=pWeQSMX3BXp4gQ@mail.gmail.com>
Message-ID: <CANL=k+FF9Tb81c3bBmkxCgUgF7erysLrLXMsO7y+VGLoYJPYeA@mail.gmail.com>

Jared,


All you plans are most excellent, and I've been thinking about (and to some
limited capacity, discussing) them for a while now.  I'm glad to see them
on the road to reality.

A couple comments:

About point 13, adding a "Did you mean?" feature... this should be done in
a way that applies to Biblios, as well, as it has often been requested in
that context, and as we see with points 5 and 6, the mechanisms under
Authorities are very similar to those under Biblios.

I believe a 15th point is required:  fixing Authority Types.  Right now,
they are essentially hardcoded, looking at the presence of specific MARC
field numbers, and determining their Auth Type from that (during import, at
least).  This means that newly created Authority Types wouldn't be
accessible unless:

   1. They used a completely new Main Entry MARC field number
   2. The code was edited to associate that field number with that Auth Type

One prime example:  right now, LCSH and MeSH subject headings are both of
the Topical Term Auth Type.  They have the same MARC structure, but belong
to different thesauri.  As it stands, there is no easy way of
differentiating a heading from one thesaurus from that of another.

This may be out of scope for the work you're currently planning to do, but
I'd ask you to keep it in mind all the same, and do any development with an
eye towards making Authority Types more robustly supported.

All in all, very interesting and encouraging work, and I look forward to
testing it out!

Cheers,


-Ian
On Sat, Jun 9, 2012 at 7:51 AM, Jared Camins-Esakov <
jcamins at cpbibliography.com> wrote:

> Good time of day!
>
> I plan to do a great deal of work on the authority module, and I wanted to
> request that anyone with thoughts on the matter please share them with me.
> The RFC is on the wiki at
> http://wiki.koha-community.org/wiki/C_%26_P_Authority_Control_Improvements_RFCand I have copied the description below.
>
> Description
>
> The development is divided into 14 parts:
>
>    1. A dropdown box will be added to the authority browser in the OPAC
>    allowing the user to choose which index to search in authorities: the
>    keyword index, the match heading index (i.e. all heading fields), the
>    preferred heading index, or the main entry only index. (bug 8206)
>    2. Because importing large authority files can result in unused
>    authority records overwhelming used authority records in OPAC authority
>    browse results, some libraries may want to disable the display of
>    authorities which are not used in the bibliographic database. In order to
>    make this possible (while still retaining the existing behavior of
>    displaying all records in the authority file as a default), a system
>    preference OPACShowUnusedAuthorities will be created, and a "Show all
>    results" link added to search results when it is enabled. (bug 8205)
>    3. Because see also references in authority records are intended to
>    refer to other authority records, they really ought to be turned into
>    hyperlinks in the various authority displays. They will be made into
>    hyperlinks (using the authid in $9 if available, or a search string
>    otherwise) in both the OPAC and the staff client. (bug 3462)
>    4. At present, the only authority record view available in the OPAC is
>    an "expanded MARC" view which is of no use to patrons, and limited use to
>    librarians. We propose adding a user-friendly authority details view
>    similar in design to the bib details view. (bug 8204)
>    5. Although the batch import functionality was originally designed
>    with importing both bibliographic and authority records in mind, authority
>    import was never actually implemented. This will be done quite simply, by
>    adding an option to choose which type of record to import in the Stage MARC
>    records tool. (bug 2060)
>    6. Match points will also be extended for use with authority records,
>    again completing a feature for which stubs already existed. (bug 7475)
>    7. There is no way to export authority records other than via a direct
>    SQL query, which makes it difficult for hosted libraries to get their data
>    out of Koha without the help of their support vendors. We propose to change
>    the "Export bibliographic/holdings" tool to the "Export data" tool, and add
>    a tab to enable librarians with the proper permissions for the export tool
>    to export their authority records directly from the staff client. (bug 8202)
>    8. Some librarians have requested the ability to save individual
>    authority records, so a "Save authority" button will be added next to the
>    "Edit" button when viewing authority records. (bug 8203)
>    9. One of the great promises of DOM indexing in Zebra (and the
>    adoption of solr as an indexing technology) is the ability to incorporate
>    alternate forms of headings into bib records when exporting bibs for
>    indexing. We will add the plumbing for arbitrary record filters, and
>    implement a filter that checks each heading in bib records for alternate
>    forms, and includes them prior to exporting the record for indexing. (bug
>    7417)
>    10. Instead of using only textual strings for see also links, the
>    ability to use $9 in see also fields in authority records (5xx in MARC21,
>    NORMARC, and UNIMARC) will be added, to simplify heading disambiguation.
>    This will enable us to create a value builder plugin using the existing
>    thesaurus functionality that will automatically populate the see also
>    heading control fields with metadata about the link (broader term, narrower
>    term, etc.) (bug 8207)
>    11. Right now when cataloging, catalogers have only two options for
>    adding a new authority: turn on AutoGenerateAuthorities, and later edit the
>    authority record to justify its creation, or save the bib record they are
>    working on, create a new authority record in the authority module, wait for
>    the new record to be indexed, and open the bib record back up to use the
>    authority finder plugin. We intend to add a "Create authority" button to
>    the authority finder plugin which will allow the cataloger to create an
>    authority in a new window and (similar to fast add in circ) automatically
>    fill out the selected heading field in the bib record. (bug 8208)
>    12. At times, people may want to search for terms that are related to
>    the one they search for. For example, someone interested in books about
>    Feet may also be interested in all books about specific parts of feet,
>    including books about Toes, Heels, etc. We will add three new special
>    pseudo-CCL search prefixes which will first search the authority file for
>    the specified heading, then search not just for that term but also for
>    broader terms (pseudo-CCL prefix su-br:), narrower terms (pseudo-CCL prefix
>    su-na:), or all related terms (pseudo-CCL prefix su-rl:). (bug 8211)
>    13. Because patrons may not always realize that they want to search
>    for a related term instead of the term they entered, we will also add a
>    "Did you mean?" feature to the OPAC, which suggests terms related to
>    authorities that match the user's search. (bug 8209)
>    14. Although not all authority records contain useful information,
>    many do, and depending on the type of collection, access to that
>    information can be critical to both librarians and patrons. In order to
>    simplify looking up authorities referred to in particular records, a link
>    from subject headings to their related authorities will be added to the
>    OPAC. A patch which adds this to the "normal" mode bib details display has
>    already Passed QA (bug 5888), so unless an unsolvable problem is found with
>    that patch, implementation will focus on the XSLT view. (bug 8210)
>
> Any questions or comments are welcome.
>
> Regards,
> Jared Camins-Esakov
>
> --
> 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/
>
>
> _______________________________________________
> 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: </pipermail/koha-devel/attachments/20120611/cf24c794/attachment.htm>

From nengard at gmail.com  Mon Jun 11 15:32:38 2012
From: nengard at gmail.com (Nicole Engard)
Date: Mon, 11 Jun 2012 09:32:38 -0400
Subject: [Koha-devel] bugzilla default assignee changes
In-Reply-To: <CAA7=B8zzhV53e3mJD=p0MbXqK12M92a=AgE0aKfeoDHRZ+apFA@mail.gmail.com>
References: <4FD369F1.5040407@biblibre.com>
	<CAA7=B8zzhV53e3mJD=p0MbXqK12M92a=AgE0aKfeoDHRZ+apFA@mail.gmail.com>
Message-ID: <CAC0K6VEnMRSuiUzGSEUJU+1zeYg2uApaZc=QkAbecsHxsYKT9g@mail.gmail.com>

> On Sat, Jun 9, 2012 at 11:21 AM, Paul Poulain <paul.poulain at biblibre.com> wrote:
>>
>> OWEN & NICOLE & LIZ & CHRIS_N
>> We haven't changed the components you're default, because you said last
>> month it was OK for you.

A- OK with me.

Nicole

From jcamins at cpbibliography.com  Mon Jun 11 15:36:53 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Mon, 11 Jun 2012 09:36:53 -0400
Subject: [Koha-devel] Authority control - request for comments
In-Reply-To: <CANL=k+FF9Tb81c3bBmkxCgUgF7erysLrLXMsO7y+VGLoYJPYeA@mail.gmail.com>
References: <CALVDfQwXwAoU8J94odwXKxx6aMe2HaRpaQ1=pWeQSMX3BXp4gQ@mail.gmail.com>
	<CANL=k+FF9Tb81c3bBmkxCgUgF7erysLrLXMsO7y+VGLoYJPYeA@mail.gmail.com>
Message-ID: <CALVDfQwDy7xF-UF32ZuUUZ0=9cw4nhgEyj3btyAvbw8Ep9qd8A@mail.gmail.com>

Ian,

About point 13, adding a "Did you mean?" feature... this should be done in
> a way that applies to Biblios, as well, as it has often been requested in
> that context, and as we see with points 5 and 6, the mechanisms under
> Authorities are very similar to those under Biblios.
>

Drawing "Did you mean?" suggestions from the bibliographic database would
actually be a completely different animal from drawing the suggestions from
authorities. It would require a completely new set of dependencies along
with the ability to extract co-occurrence information and generate
suggestions from them. By using authorities for "Did you mean?" all we have
to do is search authorities, and suggest related terms. Note that the
related terms suggestions will be appearing in the bib searches.

I believe a 15th point is required:  fixing Authority Types.  Right now,
> they are essentially hardcoded, looking at the presence of specific MARC
> field numbers, and determining their Auth Type from that (during import, at
> least).  This means that newly created Authority Types wouldn't be
> accessible unless:
>
>    1. They used a completely new Main Entry MARC field number
>    2. The code was edited to associate that field number with that Auth
>    Type
>
> One prime example:  right now, LCSH and MeSH subject headings are both of
> the Topical Term Auth Type.  They have the same MARC structure, but belong
> to different thesauri.  As it stands, there is no easy way of
> differentiating a heading from one thesaurus from that of another.
>
> This may be out of scope for the work you're currently planning to do, but
> I'd ask you to keep it in mind all the same, and do any development with an
> eye towards making Authority Types more robustly supported.
>
Yes, I've thought about this. That's part of the reason for my proposal to
use an object-oriented Koha::Record::Authority class, which allows us to be
more flexible with our understanding of authorities and authority types.
(follow-up note to clarify the relationship between Koha::Record::Authority
and the MVC divisions discussed at the hackfest: Koha::Record::Authority
would be equivalent to Koha::BusinessLogic::Authority)

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: </pipermail/koha-devel/attachments/20120611/c19c7fb2/attachment-0001.htm>

From koha.sekjal at gmail.com  Mon Jun 11 19:34:44 2012
From: koha.sekjal at gmail.com (Ian Walls)
Date: Mon, 11 Jun 2012 13:34:44 -0400
Subject: [Koha-devel] bugzilla default assignee changes
In-Reply-To: <CAC0K6VEnMRSuiUzGSEUJU+1zeYg2uApaZc=QkAbecsHxsYKT9g@mail.gmail.com>
References: <4FD369F1.5040407@biblibre.com>
	<CAA7=B8zzhV53e3mJD=p0MbXqK12M92a=AgE0aKfeoDHRZ+apFA@mail.gmail.com>
	<CAC0K6VEnMRSuiUzGSEUJU+1zeYg2uApaZc=QkAbecsHxsYKT9g@mail.gmail.com>
Message-ID: <CANL=k+FW5GqrvJ1=XV2WUJv-E4dx0Kaz8GsQJHuSQ2uydp216w@mail.gmail.com>

It would probably be best to take me off as default assignee for any
components, since I have little time for coding lately, and what time I do
have is going towards QA.

Cheers,


-Ian

On Mon, Jun 11, 2012 at 9:32 AM, Nicole Engard <nengard at gmail.com> wrote:

> > On Sat, Jun 9, 2012 at 11:21 AM, Paul Poulain <paul.poulain at biblibre.com>
> wrote:
> >>
> >> OWEN & NICOLE & LIZ & CHRIS_N
> >> We haven't changed the components you're default, because you said last
> >> month it was OK for you.
>
> A- OK with me.
>
> Nicole
> _______________________________________________
> 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: </pipermail/koha-devel/attachments/20120611/baae913a/attachment.htm>

From dschust1 at gmail.com  Mon Jun 11 20:46:38 2012
From: dschust1 at gmail.com (David Schuster)
Date: Mon, 11 Jun 2012 13:46:38 -0500
Subject: [Koha-devel] Error message when deleting items
Message-ID: <CAKpR+xSfyd4seg11LC1o7ROEe-Xa63i6oMKU0wK_Wm4f6SdqDA@mail.gmail.com>

I was using the batch delete in 3.6.5 - by barcode and received this error:



Hints as to why?

-- 
David Schuster
Plano ISD
Library Technology Coordinator
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120611/1b16d273/attachment.htm>

From cnighswonger at foundations.edu  Mon Jun 11 21:59:08 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Mon, 11 Jun 2012 15:59:08 -0400
Subject: [Koha-devel] Error message when deleting items
In-Reply-To: <CAKpR+xSfyd4seg11LC1o7ROEe-Xa63i6oMKU0wK_Wm4f6SdqDA@mail.gmail.com>
References: <CAKpR+xSfyd4seg11LC1o7ROEe-Xa63i6oMKU0wK_Wm4f6SdqDA@mail.gmail.com>
Message-ID: <CAP3yOom45L5QLaAPN0h4ZacQnH66DxmxrH+vriU0PTfbuFZOSA@mail.gmail.com>

On Mon, Jun 11, 2012 at 2:46 PM, David Schuster <dschust1 at gmail.com> wrote:

> I was using the batch delete in 3.6.5 - by barcode and received this error:
>
>
>
> Hints as to why?
>
>
Monday strikes again.... ;-)

It seems we are missing the error in question...

Kind Regards,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120611/45e7af18/attachment.htm>

From marc at msys.ch  Mon Jun 11 22:31:39 2012
From: marc at msys.ch (Marc Balmer)
Date: Mon, 11 Jun 2012 22:31:39 +0200
Subject: [Koha-devel] Experimental support for MARC records as a proper
	datatype in the PostgreSQL database
In-Reply-To: <4EBBE9EA-4705-44DB-9D7B-6ABE89A4E778@kohaaloha.com>
References: <4FD4C08D.6040908@msys.ch>
	<4EBBE9EA-4705-44DB-9D7B-6ABE89A4E778@kohaaloha.com>
Message-ID: <CAE41CFE-DF29-4275-8A12-33BFEF13F90C@msys.ch>

> 
> could someone please paste the code of the 'marc_field() function?
> 

The marc_field() function is part of the MARC integration into PostgreSQL and can not be used separately, since it relies on the internal representation of binary MARC records in the database.

The complete MARC code for PostgreSQL will eventually be available under an open source license.


From dschust1 at gmail.com  Mon Jun 11 22:56:18 2012
From: dschust1 at gmail.com (David Schuster)
Date: Mon, 11 Jun 2012 15:56:18 -0500
Subject: [Koha-devel] Error message when deleting items
In-Reply-To: <CAKpR+xSfyd4seg11LC1o7ROEe-Xa63i6oMKU0wK_Wm4f6SdqDA@mail.gmail.com>
References: <CAKpR+xSfyd4seg11LC1o7ROEe-Xa63i6oMKU0wK_Wm4f6SdqDA@mail.gmail.com>
Message-ID: <CAKpR+xQcVkbZx_GLFi2KYJdB+eGh2PYReC_UKMKZP66iaPrE5A@mail.gmail.com>

Software error:

Can't call method "as_usmarc" on an undefined value at
/home/koha/kohaclone/C4/Items.pm line 588.

 For help, please send mail to the webmaster (webmaster at KOHA), giving this
error message and the time and date of the error.


Huh not sure where my cut and paste went..


On Mon, Jun 11, 2012 at 1:46 PM, David Schuster <dschust1 at gmail.com> wrote:

> I was using the batch delete in 3.6.5 - by barcode and received this error:
>
>
>
> Hints as to why?
>
> --
> David Schuster
> Plano ISD
> Library Technology Coordinator
>



-- 
David Schuster
Plano ISD
Library Technology Coordinator
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120611/b3b39e0c/attachment.htm>

From paul.poulain at biblibre.com  Mon Jun 11 23:00:14 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Mon, 11 Jun 2012 23:00:14 +0200
Subject: [Koha-devel] bugzilla default assignee changes
In-Reply-To: <CANL=k+FW5GqrvJ1=XV2WUJv-E4dx0Kaz8GsQJHuSQ2uydp216w@mail.gmail.com>
References: <4FD369F1.5040407@biblibre.com>
	<CAA7=B8zzhV53e3mJD=p0MbXqK12M92a=AgE0aKfeoDHRZ+apFA@mail.gmail.com>
	<CAC0K6VEnMRSuiUzGSEUJU+1zeYg2uApaZc=QkAbecsHxsYKT9g@mail.gmail.com>
	<CANL=k+FW5GqrvJ1=XV2WUJv-E4dx0Kaz8GsQJHuSQ2uydp216w@mail.gmail.com>
Message-ID: <4FD65C5E.7080608@biblibre.com>

Le 11/06/2012 19:34, Ian Walls a ?crit :
> It would probably be best to take me off as default assignee for any
> components, since I have little time for coding lately, and what time I
> do have is going towards QA.
I removed you from Hold requests and Self checkout

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From mtj at kohaaloha.com  Tue Jun 12 02:22:16 2012
From: mtj at kohaaloha.com (Mason James)
Date: Tue, 12 Jun 2012 12:22:16 +1200
Subject: [Koha-devel] Experimental support for MARC records as a proper
	datatype in the PostgreSQL database
In-Reply-To: <CAE41CFE-DF29-4275-8A12-33BFEF13F90C@msys.ch>
References: <4FD4C08D.6040908@msys.ch>
	<4EBBE9EA-4705-44DB-9D7B-6ABE89A4E778@kohaaloha.com>
	<CAE41CFE-DF29-4275-8A12-33BFEF13F90C@msys.ch>
Message-ID: <5C6AF5FD-734C-44A3-BF49-E5656F309841@kohaaloha.com>


On 2012-06-12, at 8:31 AM, Marc Balmer wrote:

>> 
>> could someone please paste the code of the 'marc_field() function?
>> 
> 
> The marc_field() function is part of the MARC integration into PostgreSQL and can not be used separately, since it relies on the internal representation of binary MARC records in the database.
> 
> The complete MARC code for PostgreSQL will eventually be available under an open source license.


awesome!, i'm looking forward to it
-------------- 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: </pipermail/koha-devel/attachments/20120612/ee69f39d/attachment-0001.pgp>

From claire.hernandez at biblibre.com  Wed Jun 13 16:08:36 2012
From: claire.hernandez at biblibre.com (Claire Hernandez)
Date: Wed, 13 Jun 2012 16:08:36 +0200
Subject: [Koha-devel] Unit tests and continuous integration with Koha
Message-ID: <4FD89EE4.3060009@biblibre.com>

Hello all,

One of discussed subject at kohacon12 was quality control and automated 
tools: Chris presented us how works unit testing in koha and what does 
jenkins.

I tried to summurise both subjects in these two pages:
http://wiki.koha-community.org/wiki/Unit_Tests
http://wiki.koha-community.org/wiki/Continuous_Integration

Surely incomplete and with mistakes but have a look :)

Claire;

From M.de.Rooy at rijksmuseum.nl  Wed Jun 13 16:32:51 2012
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Wed, 13 Jun 2012 14:32:51 +0000
Subject: [Koha-devel] Bug 7167 New updatedatabase
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA310DF89374@S-MAIL-1B.rijksmuseum.intra>

Hi all,

Patch 7167 has been signed off. I have pasted my QA comment here below to get some feedback from you. Note that this patch will impact your future updates !

My comments are not strictly technical, but also on a functional level. Due to the nature of this patch, I think that I should.

Before Paul or Jonathan moves on, you may have some comments. Do you agree with me, or why not? Etc.

Thanks a lot..



Marcel



QA comment:
Larger patch with greater impact.
Good work! Code generally looks good.
Nice idea. Will make testing patches with dbrevs easier.
Because of the impact of this patch, I think that we still need some adjustments before it passes qa. The points below may look like a lot of work, but will not need that much code changes. I believe that it can be done within some hours. (Please note that I would really LIKE to see this feature be pushed soon!)

I change status to In Discussion and will ask for input from the dev list. Before you change the patch, it would be good to have some additional community consensus about it (when given).

My main (functional) point is actually: make a distinction between numbered dbrevs (from master) and unnumbered dbrevs (from test patches or custom development). An upgrade should always run the numbered dbrevs in linear order. The unnumbered ones can be executed in any order from the new update form if you are in dev mode. This makes a wiki with picking dbrev numbers unneeded. The RM still takes care of the numbering (rename a file). A developer just adds a file without dbrev number in a new patch, perhaps referrring to a bug report. There will be no gaps in the numbering scheme. About lists the correct official Koha version and the applied 'custom' dbrevs.

YAML: As I understand, the idea was initially to have dbrevs in a yaml file. In the current implementation, only the version dir is in that file. Additionally, you do not use the dirload, only the fileload. For simplicity, I recommend to remove the YAML file and associated code. The versions directory can be hardcoded in my opinion within the install/data.. region. I would suggest to rename it to dbrev or something similar, and have numbered version subdirectories within it.
Example: This will eventually lead to dirs and files like dbrevs/3.09/3.09.00.001.sql or dbrevs/3.10/3.10.02.003.pl, etc.

Development mode: Currently, you rely on $ENV{DEBUG} from koha-httpd file. I would turn this into a systempref. It is easier for developers to toggle it (compared to restarting httpd service).

Skeleton: I see it in a regex as well as some code inserting into foo. Assume that it was used in testing. Please remove it. In actual use, you will find enough examples to find your way. Or just put some comments into a readme file.

Mainpage: Some code was removed from Auth.pm. The version check is now in mainpage.pl itself. I would rather have that check in an appropriate module. It was in Auth.pm. You could leave it there? I think we should let the version check stay within the scope of the checkauth call included in the get_user_and_template call. (See also comment on Auth.pm below).

Authorization (Auth.pm): I agree that if a user already logged in, it is not needed to check the version every time. The ("new") initial check in checkauth if the db contains a version, is fine. The former moment of the "complete" version check was too early. I think we should leave it in checkauth, but do it at a later moment: If we start a new session and we verified the password, then we should do the extended version check (database versus kohaversion.pl). That is close to line 748 in the adjusted Auth.pm (depending on the value of $return). This will prevent Koha from checking it every time, but only for a new session. If the version check fails at that moment, we should redirect to installer step 3 (updatestructure).

Note that there is some problem in current code, that forces me to login twice when there is an update available. (It redirects to admin/updatedatabase, but I must relogin again.) Please correct. Probably you should only pass the $cookie in your redirect call too. Like:
print $query->redirect(-uri=>"/cgi-bin/koha/admin/updatedatabase.pl",-cookie=>$cookie);

Upgrading: When coming from an older version (before 3.9.0.x), you should run the old updatedatabase and after that you should run the new dbrevs in the dbrev directories. This is currently done in two passes. First it runs the old update. You think that it is ready. When you login, you are prompted to the new update form. It should not be too difficult to merge this into one pass (less confusing). Please adjust install.pl for that: You should check if it is still needed to call the old update before running the new one (for numbered dbrevs only).

Update form: Since numbered dbrevs are run via installer, only allow executing unnumbered dbrevs here (in dev mode). In normal mode, you can only browse history here. (I would suggest to not even show the unnumbered dbrevs if you are in normal mode.)

File structure: As mentioned above, make directories for a Koha release. Getting all updates means fetching the updates from a few directories. This makes the feature more future-proof.

Stable version: The md5 test will be of good use here! If we backport this to 3.8.X, we could already check what updates we already have run from 3.9 folder with the md5 checksum. When upgrading from 3.8 to 3.10, some dbrevs are new, others will be incorporated already. So this remark only serves the purpose of discussing "Should we also get this into stable already (within reasonable time)?".

admin/updatedatabase.pl: Line 33 adds a fixme to new code: Add a new flag?

Commit message: please make it up-to-date. E.g. section on installdir.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120613/073dd89e/attachment.htm>

From jcamins at cpbibliography.com  Wed Jun 13 16:39:44 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Wed, 13 Jun 2012 10:39:44 -0400
Subject: [Koha-devel] Bug 7167 New updatedatabase
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA310DF89374@S-MAIL-1B.rijksmuseum.intra>
References: <809BE39CD64BFD4EB9036172EBCCFA310DF89374@S-MAIL-1B.rijksmuseum.intra>
Message-ID: <CALVDfQysX=c+ndHTOxqeC=2xBDOKqMHAkncjZdXT4fGVwa_oUQ@mail.gmail.com>

Marcel, et. al.,

Patch 7167 has been signed off. I have pasted my QA comment here below to
> get some feedback from you. Note that this patch will impact your future
> updates !
>
> My comments are not strictly technical, but also on a functional level.
> Due to the nature of this patch, I think that I should.
>
> Before Paul or Jonathan moves on, you may have some comments. Do you agree
> with me, or why not? Etc.
>
> Thanks a lot..
>
>
>
> Marcel
>
>
>
> QA comment:
> Larger patch with greater impact.
> Good work! Code generally looks good.
> Nice idea. Will make testing patches with dbrevs easier.
> Because of the impact of this patch, I think that we still need some
> adjustments before it passes qa. The points below may look like a lot of
> work, but will not need that much code changes. I believe that it can be
> done within some hours. (Please note that I would really LIKE to see this
> feature be pushed soon!)
>
> I change status to In Discussion and will ask for input from the dev list.
> Before you change the patch, it would be good to have some additional
> community consensus about it (when given).
>
> My main (functional) point is actually: make a distinction between
> numbered dbrevs (from master) and unnumbered dbrevs (from test patches or
> custom development). An upgrade should always run the numbered dbrevs in
> linear order. The unnumbered ones can be executed in any order from the new
> update form if you are in dev mode. This makes a wiki with picking dbrev
> numbers unneeded. The RM still takes care of the numbering (rename a file).
> A developer just adds a file without dbrev number in a new patch, perhaps
> referrring to a bug report. There will be no gaps in the numbering scheme.
> About lists the correct official Koha version and the applied 'custom'
> dbrevs.
>
I think this is a fantastic idea. I think this would greatly simplify the
development and testing process.

> YAML: As I understand, the idea was initially to have dbrevs in a yaml
> file. In the current implementation, only the version dir is in that file.
> Additionally, you do not use the dirload, only the fileload. For
> simplicity, I recommend to remove the YAML file and associated code. The
> versions directory can be hardcoded in my opinion within the install/data..
> region. I would suggest to rename it to dbrev or something similar, and
> have numbered version subdirectories within it.
> Example: This will eventually lead to dirs and files like
> dbrevs/3.09/3.09.00.001.sql or dbrevs/3.10/3.10.02.003.pl, etc.
>
> Development mode: Currently, you rely on $ENV{DEBUG} from koha-httpd file.
> I would turn this into a systempref. It is easier for developers to toggle
> it (compared to restarting httpd service).
>
It's easier, but also a lot more dangerous in my opinion. The consensus on
the caching configuration was that it was too dangerous to allow access to
it in sysprefs. Based on that logic, I think using an environment variable
would be the way to go.

>  Skeleton: I see it in a regex as well as some code inserting into foo.
> Assume that it was used in testing. Please remove it. In actual use, you
> will find enough examples to find your way. Or just put some comments into
> a readme file.
>
> Mainpage: Some code was removed from Auth.pm. The version check is now in
> mainpage.pl itself. I would rather have that check in an appropriate
> module. It was in Auth.pm. You could leave it there? I think we should let
> the version check stay within the scope of the checkauth call included in
> the get_user_and_template call. (See also comment on Auth.pm below).
>
> Authorization (Auth.pm): I agree that if a user already logged in, it is
> not needed to check the version every time. The ("new") initial check in
> checkauth if the db contains a version, is fine. The former moment of the
> "complete" version check was too early. I think we should leave it in
> checkauth, but do it at a later moment: If we start a new session and we
> verified the password, then we should do the extended version check
> (database versus kohaversion.pl). That is close to line 748 in the
> adjusted Auth.pm (depending on the value of $return). This will prevent
> Koha from checking it every time, but only for a new session. If the
> version check fails at that moment, we should redirect to installer step 3
> (updatestructure).
>
> Note that there is some problem in current code, that forces me to login
> twice when there is an update available. (It redirects to
> admin/updatedatabase, but I must relogin again.) Please correct. Probably
> you should only pass the $cookie in your redirect call too. Like:
> print $query->redirect(-uri=>"/cgi-bin/koha/admin/updatedatabase.pl
> ",-cookie=>$cookie);
>
> Upgrading: When coming from an older version (before 3.9.0.x), you should
> run the old updatedatabase and after that you should run the new dbrevs in
> the dbrev directories. This is currently done in two passes. First it runs
> the old update. You think that it is ready. When you login, you are
> prompted to the new update form. It should not be too difficult to merge
> this into one pass (less confusing). Please adjust install.pl for that:
> You should check if it is still needed to call the old update before
> running the new one (for numbered dbrevs only).
>
> Update form: Since numbered dbrevs are run via installer, only allow
> executing unnumbered dbrevs here (in dev mode). In normal mode, you can
> only browse history here. (I would suggest to not even show the unnumbered
> dbrevs if you are in normal mode.)
>
I disagree here, too. I think unnumbered dbrevs should be shown in normal
mode, so that if a developer switches to normal mode, they're able to spot
"oh, oops, I forgot to reset my database."

> File structure: As mentioned above, make directories for a Koha release.
> Getting all updates means fetching the updates from a few directories. This
> makes the feature more future-proof.
>
> Stable version: The md5 test will be of good use here! If we backport this
> to 3.8.X, we could already check what updates we already have run from 3.9
> folder with the md5 checksum. When upgrading from 3.8 to 3.10, some dbrevs
> are new, others will be incorporated already. So this remark only serves
> the purpose of discussing "Should we also get this into stable already
> (within reasonable time)?".
>
> admin/updatedatabase.pl: Line 33 adds a fixme to new code: Add a new flag?
>
> Commit message: please make it up-to-date. E.g. section on installdir.
>
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: </pipermail/koha-devel/attachments/20120613/76ba1db5/attachment-0001.htm>

From chris at bigballofwax.co.nz  Thu Jun 14 09:13:23 2012
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Thu, 14 Jun 2012 19:13:23 +1200
Subject: [Koha-devel] String freeze for 3.8.2
Message-ID: <CA+95qVQi-5Z8dm+JGs87pRKcM_CN6zoR5OQbukg+ay7dvVUZSQ@mail.gmail.com>

We are almost one week out from the release of 3.8.2, which means that
on the 15th we go into string freeze before the release.

There shouldn't be a huge amount of changes from 3.8.1, but we will
soon find out once the translation manager has updated the .po files.

Happy translating

Chris

From paul.poulain at biblibre.com  Thu Jun 14 09:51:15 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 14 Jun 2012 09:51:15 +0200
Subject: [Koha-devel] About IRC meeting & voting
Message-ID: <4FD997F3.3040409@biblibre.com>

Hello world,

Sorry for missing yesterday IRC meeting, but after 10 days away from
home, my family needed me (and it was 8PM here !)

During the meeting, Owen said, as a joke:
oleonard> 24-hour meeting, votes ever hour, day-end averages win.

but i'm not sure it should be a joke: there is always someone sleeping
or (wanting to) during the IRC meeting.
So shouldn't we vote not during IRC meeting, but just confirm the vote,
that is made during a period before the IRC meeting, on an other tool,
like wiki, gdoc, yell +1 / 0 / -1 on the mailing list, a tool like
http://www.ballotbin.com/ (untested, just found it in google) or
whatever you want.

I think that would also help more people being involved: attending an
IRC meeting is, for some, a too high barrier (in France, there's a
barrier with the language, for example).

More vote, more involvement,... sounds a good deal isn't it ?

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From claire.hernandez at biblibre.com  Thu Jun 14 10:09:02 2012
From: claire.hernandez at biblibre.com (Claire Hernandez)
Date: Thu, 14 Jun 2012 10:09:02 +0200
Subject: [Koha-devel] About IRC meeting & voting
In-Reply-To: <4FD997F3.3040409@biblibre.com>
References: <4FD997F3.3040409@biblibre.com>
Message-ID: <4FD99C1E.2080905@biblibre.com>

On 14/06/2012 09:51, Paul Poulain wrote:
> So shouldn't we vote not during IRC meeting, but just confirm the vote,
> that is made during a period before the IRC meeting, on an other tool,
> like wiki, gdoc, yell +1 / 0 / -1 on the mailing list, a tool like
> http://www.ballotbin.com/ (untested, just found it in google) or
> whatever you want.
Hello,

I like the idea (not because he is my boss!).

I discover few weeks ago http://voteer.com . There is no 
"authentication" but it is the simplest...

HTH.
Claire;

From 5p4m at gmx.de  Thu Jun 14 10:36:14 2012
From: 5p4m at gmx.de (Mirko)
Date: Thu, 14 Jun 2012 10:36:14 +0200
Subject: [Koha-devel] About IRC meeting & voting
In-Reply-To: <4FD997F3.3040409@biblibre.com>
References: <4FD997F3.3040409@biblibre.com>
Message-ID: <4FD9A27E.4030304@gmx.de>

Good morning,

schrieb Paul Poulain am 14.06.2012 09:51:
> Hello world,
> 
> Sorry for missing yesterday IRC meeting, but after 10 days away from
> home, my family needed me (and it was 8PM here !)
> 
> During the meeting, Owen said, as a joke:
> oleonard> 24-hour meeting, votes ever hour, day-end averages win.
> 
> but i'm not sure it should be a joke: there is always someone sleeping
> or (wanting to) during the IRC meeting.
> So shouldn't we vote not during IRC meeting, but just confirm the vote,
> that is made during a period before the IRC meeting, on an other tool,
> like wiki, gdoc, yell +1 / 0 / -1 on the mailing list, a tool like
> http://www.ballotbin.com/ (untested, just found it in google) or
> whatever you want.

+1 for changing to a voting period. We are a community within a lot
of different timezones, everybody should have the chance to vote.

But please let us not outsource this to a service we don't control
ourselves. ballotbin.com requires an account, voteer.com uses
googleapis etc. I suppose there won't be millions of votes suddenly,
so the wiki or mailinglist should be enough for now, or someone sets
up a fancy, privacy unintrusive tool on a server we control.

With the IRC meeting, you have people actually attending, talking to
each other and have a discussion. I think that is very important,
but we could have the discussions on the mailing list too I guess.

I vote strongly against some clicky tool where you just make an 'X'
somewhere and that's it. It would be nice to know who the people are
that vote for something (and that they are real people and no bots).


> 
> I think that would also help more people being involved: attending an
> IRC meeting is, for some, a too high barrier (in France, there's a
> barrier with the language, for example).


To attend an IRC meeting, you have to open the webchat applet, say
"hi", "#info $your_name" and then you can vote. I think it is easier
than joining the mailing list or registering for the wiki, isn't it?



From veron at veron.ch  Thu Jun 14 11:05:16 2012
From: veron at veron.ch (=?ISO-8859-1?Q?Marc_V=E9ron?=)
Date: Thu, 14 Jun 2012 11:05:16 +0200
Subject: [Koha-devel] About IRC meeting & voting
In-Reply-To: <4FD997F3.3040409@biblibre.com>
References: <4FD997F3.3040409@biblibre.com>
Message-ID: <4FD9A94C.3030608@veron.ch>

Good daytime everybody,

Am 14.06.2012 09:51, schrieb Paul Poulain:
(...)
> So shouldn't we vote not during IRC meeting, but just confirm the vote,
> that is made during a period before the IRC meeting, on an other tool,
> like wiki, gdoc, yell +1 / 0 / -1 on the mailing list, a tool like
> http://www.ballotbin.com/ (untested, just found it in google) or
> whatever you want.
(...)


+1 for Paul's great idea.

Question:
Shouldn't it be two voting periods, one before the meeting happens (with 
items that are already known) and one after the meeting (with items that 
show up during the discussion and need a decision within a short time frame)?


Am 14.06.2012 10:36, schrieb Mirko:
(...)
 > But please let us not outsource this to a service we don't control
 > ourselves. ballotbin.com requires an account, voteer.com uses
 > googleapis etc. I suppose there won't be millions of votes suddenly,
 > so the wiki or mailinglist should be enough for now, or someone sets
 > up a fancy, privacy unintrusive tool on a server we control.
(...)

+1 for Mirko


Marc

From paul.poulain at biblibre.com  Thu Jun 14 11:55:50 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 14 Jun 2012 11:55:50 +0200
Subject: [Koha-devel] About IRC meeting & voting
In-Reply-To: <4FD9A27E.4030304@gmx.de>
References: <4FD997F3.3040409@biblibre.com> <4FD9A27E.4030304@gmx.de>
Message-ID: <4FD9B526.4050905@biblibre.com>

Le 14/06/2012 10:36, Mirko a ?crit :

>> I think that would also help more people being involved: attending an
>> IRC meeting is, for some, a too high barrier (in France, there's a
>> barrier with the language, for example).
> 
> To attend an IRC meeting, you have to open the webchat applet, say
> "hi", "#info $your_name" and then you can vote. I think it is easier
> than joining the mailing list or registering for the wiki, isn't it?

I was not refering first to the tool itself, but to the language.

We (BibLibre) would be willing to translate votes to french, and write
to french mailing list with explanations in french even if the vote
itself appear in english only.

Something like :
"ce vote concerne la d?cision blablabla. Les options de vote sont :
choix A = comme ceci (ligne "do like this")
choix B = comme cela (ligne "do like that")
choix C = troisi?me option (ligne "third option")
"

In an IRC meeting (independantly from the time, which is another
barrier), ppl have to speak english

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From matthias.meusburger at biblibre.com  Thu Jun 14 12:11:19 2012
From: matthias.meusburger at biblibre.com (Matthias Meusburger)
Date: Thu, 14 Jun 2012 12:11:19 +0200
Subject: [Koha-devel] Kohacon12: my pics
Message-ID: <4FD9B8C7.9000809@biblibre.com>

Hello !

Here are the photos I've taken (and gathered) from Kohacon12:

http://pub.veggie.fr/biblibre/pics

And here is a zip file:

http://pub.veggie.fr/biblibre/2012_06_05-11_Kohacon_Edinburgh.zip


Cheers,

Matthias Meusburger






From marc at msys.ch  Thu Jun 14 12:27:12 2012
From: marc at msys.ch (Marc Balmer)
Date: Thu, 14 Jun 2012 12:27:12 +0200
Subject: [Koha-devel] About IRC meeting & voting
In-Reply-To: <4FD9A27E.4030304@gmx.de>
References: <4FD997F3.3040409@biblibre.com> <4FD9A27E.4030304@gmx.de>
Message-ID: <06510D63-4A28-4BA6-843B-3CC6B2073CD4@msys.ch>



-- 
Marc Balmer
micro systems, http://www.msys.ch/
Tel. +41 61 383 05 10, Fax +41 61 383 05 12

Am 14.06.2012 um 10:36 schrieb Mirko <5p4m at gmx.de>:

> Good morning,
> 
> schrieb Paul Poulain am 14.06.2012 09:51:
>> Hello world,
>> 
>> Sorry for missing yesterday IRC meeting, but after 10 days away from
>> home, my family needed me (and it was 8PM here !)
>> 
>> During the meeting, Owen said, as a joke:
>> oleonard> 24-hour meeting, votes ever hour, day-end averages win.
>> 
>> but i'm not sure it should be a joke: there is always someone sleeping
>> or (wanting to) during the IRC meeting.
>> So shouldn't we vote not during IRC meeting, but just confirm the vote,
>> that is made during a period before the IRC meeting, on an other tool,
>> like wiki, gdoc, yell +1 / 0 / -1 on the mailing list, a tool like
>> http://www.ballotbin.com/ (untested, just found it in google) or
>> whatever you want.
> 
> +1 for changing to a voting period. We are a community within a lot
> of different timezones, everybody should have the chance to vote.

+1

> 
> But please let us not outsource this to a service we don't control
> ourselves. ballotbin.com requires an account, voteer.com uses
> googleapis etc. I suppose there won't be millions of votes suddenly,
> so the wiki or mailinglist should be enough for now, or someone sets
> up a fancy, privacy unintrusive tool on a server we control.

ack, very much ack, indeed.

> 
> With the IRC meeting, you have people actually attending, talking to
> each other and have a discussion. I think that is very important,
> but we could have the discussions on the mailing list too I guess.
> 
> I vote strongly against some clicky tool where you just make an 'X'
> somewhere and that's it. It would be nice to know who the people are
> that vote for something (and that they are real people and no bots).

ack, again.

> 
> 
>> 
>> I think that would also help more people being involved: attending an
>> IRC meeting is, for some, a too high barrier (in France, there's a
>> barrier with the language, for example).
> 
> 
> To attend an IRC meeting, you have to open the webchat applet, say
> "hi", "#info $your_name" and then you can vote. I think it is easier
> than joining the mailing list or registering for the wiki, isn't it?
> 
> 
> _______________________________________________
> 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 nengard at gmail.com  Thu Jun 14 13:36:52 2012
From: nengard at gmail.com (Nicole Engard)
Date: Thu, 14 Jun 2012 07:36:52 -0400
Subject: [Koha-devel] Kohacon12: my pics
In-Reply-To: <4FD9B8C7.9000809@biblibre.com>
References: <4FD9B8C7.9000809@biblibre.com>
Message-ID: <CAC0K6VHsC7q7CTJY5TzH-Db13NPBPZm0Uf2GBeAfpxEt+R-qeg@mail.gmail.com>

More from others (tagged #kohacon12 on Flickr) Here:
http://www.flickr.com/search/?q=kohacon12&m=tags

Nicole

On Thu, Jun 14, 2012 at 6:11 AM, Matthias Meusburger
<matthias.meusburger at biblibre.com> wrote:
> Hello !
>
> Here are the photos I've taken (and gathered) from Kohacon12:
>
> http://pub.veggie.fr/biblibre/pics
>
> And here is a zip file:
>
> http://pub.veggie.fr/biblibre/2012_06_05-11_Kohacon_Edinburgh.zip
>
>
> Cheers,
>
> Matthias Meusburger
>
>
>
>
>
> _______________________________________________
> 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 nengard at gmail.com  Thu Jun 14 13:47:53 2012
From: nengard at gmail.com (Nicole Engard)
Date: Thu, 14 Jun 2012 07:47:53 -0400
Subject: [Koha-devel] About IRC meeting & voting
In-Reply-To: <06510D63-4A28-4BA6-843B-3CC6B2073CD4@msys.ch>
References: <4FD997F3.3040409@biblibre.com> <4FD9A27E.4030304@gmx.de>
	<06510D63-4A28-4BA6-843B-3CC6B2073CD4@msys.ch>
Message-ID: <CAC0K6VG+OKBtETNffhZcYbx9dmsWGSDOiy1CtVPEqHUU7jZi1A@mail.gmail.com>

I have installed on my server LimeSurvey. It's open source and the
tool we've been using for conference votes for the last few years. We
can use that as a voting tool - I can add other admins to it. Or we
can get LimeSurvey installed on the Koha-Community.org domain and use
it there (either works for me). LimeSurvey allows for translation of
survey questions and answers so it would be great for a worldwide
community like ours.  We actually used it many years ago to talk about
the Koha Governance and someone at BibLibre translated all the
questions for me to French to allow for easy access to more people.

Nicole C. Engard

From magnus at enger.priv.no  Thu Jun 14 14:11:55 2012
From: magnus at enger.priv.no (Magnus Enger)
Date: Thu, 14 Jun 2012 14:11:55 +0200
Subject: [Koha-devel] Koha API for use in mobile app
In-Reply-To: <92EE683C33FE4F7EBF895DDA9D0EB3F3@naygames.com>
References: <92EE683C33FE4F7EBF895DDA9D0EB3F3@naygames.com>
Message-ID: <CABg6UYGurxByCn3jf19gfrZq+uq=PeA2+S1Ppj-Y7TJigjR9yg@mail.gmail.com>

Hi and sorry for the delay!

On 31 May 2012 22:02, Robert Nay <robert at naygames.com> wrote:
> I am looking to create an iPhone/Android app for my local library, and am
> wondering about the best way to go about this. Does Koha have some API that
> can be accessed from a third-party client (in this case, a mobile
> application)? Koha pages seem to have an "unapi" link in them, is this
> something that could be used? I am relatively new to Koha, so any help or
> advice would be greatly appreciated.

I don't know unapi, but what I would recommend looking at is ILS-DI and SRU.

ILS-DI is activated with the ILS-DI syspref, and is self documenting, see e.g.:
http://head.bibkat.no/cgi-bin/koha/ilsdi.pl

To get SRU working you need to enable the Z39.50 server in your
koha-conf.xml file.

Hope that helps!

Best regards,
Magnus Enger
libriotech.no

From jcamins at cpbibliography.com  Thu Jun 14 14:38:14 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Thu, 14 Jun 2012 08:38:14 -0400
Subject: [Koha-devel] String freeze for 3.6.6
Message-ID: <CALVDfQx2eR8VT6gdnnGJLKgT-pqKoiiF8mHXYJZGVGDGsyW2Xw@mail.gmail.com>

Good morning.

On June 15 we will go into string freeze for 3.6.6, which will be released
on June 23. There have not been many changes, so the translation should be
pretty painless.

Regards,
Jared Camins-Esakov

-- 
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: </pipermail/koha-devel/attachments/20120614/a0a2dabe/attachment.htm>

From koha.sekjal at gmail.com  Thu Jun 14 15:22:02 2012
From: koha.sekjal at gmail.com (Ian Walls)
Date: Thu, 14 Jun 2012 09:22:02 -0400
Subject: [Koha-devel] About IRC meeting & voting
In-Reply-To: <CAC0K6VG+OKBtETNffhZcYbx9dmsWGSDOiy1CtVPEqHUU7jZi1A@mail.gmail.com>
References: <4FD997F3.3040409@biblibre.com> <4FD9A27E.4030304@gmx.de>
	<06510D63-4A28-4BA6-843B-3CC6B2073CD4@msys.ch>
	<CAC0K6VG+OKBtETNffhZcYbx9dmsWGSDOiy1CtVPEqHUU7jZi1A@mail.gmail.com>
Message-ID: <CANL=k+EUOEU44GS8q=PGVFOnasH9i9dATWkA6NuEgat4Cq=EEg@mail.gmail.com>

I think we've got two issues here to resolve here:

   1. some kind of asynchronous voting mechanism.  We need to be able to
   create arbitrarily many issues to vote on, with set opening and closing
   datetimes.  We also need some kind of mechanism for preventing spam or
   other abuse.  Personally, I think such a mechanism should be voter
   registration (hence 2).
   2. A database of Koha community members.  This would been to be VERY low
   entry, because we don't want to exclude anyone, and it should track only
   the most minimal information about folks (name and email), with an option
   to add more detail if a person chooses.  One advantage of having this as a
   separate data pool is that we can access it over LDAP, Shibboleth or
   whatever other authentication means we like.  We'd have something that we
   could test our authentication against, as well as a consistent
   username/password across all the authenticated resources we have.

I think I've brought up the need for a People database in the past, and
there are definitely privacy and accessibility concerns we've got to
address.  I was just reading how meritocracies can often turn into
oligarchies (
http://boingboing.net/2012/06/13/meritocracies-become-oligarchi.html), and
while I'm not saying that this necessarily applies to the Koha community,
it's a pattern I think we should be aware of.  Any kind of community users
database would need to be done in such a way that new users can join it
quickly and easily.

Cheers,


-Ian
On Thu, Jun 14, 2012 at 7:47 AM, Nicole Engard <nengard at gmail.com> wrote:

> I have installed on my server LimeSurvey. It's open source and the
> tool we've been using for conference votes for the last few years. We
> can use that as a voting tool - I can add other admins to it. Or we
> can get LimeSurvey installed on the Koha-Community.org domain and use
> it there (either works for me). LimeSurvey allows for translation of
> survey questions and answers so it would be great for a worldwide
> community like ours.  We actually used it many years ago to talk about
> the Koha Governance and someone at BibLibre translated all the
> questions for me to French to allow for easy access to more people.
>
> Nicole C. Engard
> _______________________________________________
> 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: </pipermail/koha-devel/attachments/20120614/f1e0bd12/attachment-0001.htm>

From abesottedphoenix at yahoo.com  Thu Jun 14 17:11:57 2012
From: abesottedphoenix at yahoo.com (BWS Johnson)
Date: Thu, 14 Jun 2012 08:11:57 -0700 (PDT)
Subject: [Koha-devel] About IRC meeting & voting
In-Reply-To: <CAC0K6VG+OKBtETNffhZcYbx9dmsWGSDOiy1CtVPEqHUU7jZi1A@mail.gmail.com>
References: <4FD997F3.3040409@biblibre.com> <4FD9A27E.4030304@gmx.de>
	<06510D63-4A28-4BA6-843B-3CC6B2073CD4@msys.ch>
	<CAC0K6VG+OKBtETNffhZcYbx9dmsWGSDOiy1CtVPEqHUU7jZi1A@mail.gmail.com>
Message-ID: <1339686717.93776.YahooMailNeo@web140805.mail.bf1.yahoo.com>

Salvete!

??? ??? I'm still mulling over the whole voting by proxy thing: I really don't like it, but I need to sort out and share precisely why. (Much of my reservations have to do with an erosion of Community and a ratcheting up of administrative duties.)

??? That said, having LimeSurvey up and available to the community at large would just be so fantastic. I bugged Nicole to use hers to help me do a study months back and it was beautiful. It's so easy to use even I can do it, and it's quite powerful in terms of statistics. I love that it's FOSS to boot. It would be an incredible resource for Librarians.

Cheers,
Brooke


From dpavlin at rot13.org  Thu Jun 14 20:28:29 2012
From: dpavlin at rot13.org (Dobrica Pavlinusic)
Date: Thu, 14 Jun 2012 20:28:29 +0200
Subject: [Koha-devel] using CHI directly to use all of it's advantages
Message-ID: <20120614182829.GA9627@rot13.org>

As some of you allready know, Jonathan Swartz had presentation about CHI: Universal caching for Perl
at YAPC::NA. Video recording is available at:

http://ics.webcast.uwex.edu/mediasite/Viewer/?peid=b503ecb42c18452a9f4a95b7372648711d

It got me thinking about our new Koha::Cache layer. For a start, I would
love to use CHI directly and make it required depenency for Koha since
it has following features which we already use:
- memcached back-end - making our own memcache implementation obsolete
- fastmmap back-end - ditto
- DBI cache - making mysql query cache problem solvable
  way than DBD::Goper suggestion from
  http://wiki.koha-community.org/wiki/Performance#MySQL_tuning
- memoize
- very nice syntax:

my $customer2 = $cache->compute($name2, "10 minutes", sub {
        get_customer_from_db($name2)
});

Which I would prefer to our existing Koha::Cache API. It would also save
us quite a bit of code.

CHI has powerfull statistics which basically obsolete my idea of writing
statistics gathering code through Koha.

I would love to have this in next release, since this is more-or-less my
last major gripe with current Koha code (short-term goal[1]), so if I
would love to hear feedback.

1: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7177

My more long-term goal is to know more about Koha's data-access
patterns (you are again advised to examine performance wiki page if you
haven't up to this point).

In most simple sense, only think which is big unknown is wheater we can
find sane key namespace schema which will allow us to good-enough cache
invalidation scheme. I strongly think that time-outs are useful just for
OPAC, not for intranet use!

It seems to me that CHI redis back-end (which can introspect keyspace
with keys *) and my "weekly push master in production because of plack"
approach might bring us to better understanding how our Model layer
might look like, allmost like reverse engeeniring existing code access
patterns which has proven to bring a lot of low-hanging fruits so far.

Only disadvantage I can think of is that CHI isn't packaged in stable
Debian but it is in wheezy so Robin would not need to package it
forever, just for little while :-)

-- 
Dobrica Pavlinusic               2share!2flame            dpavlin at rot13.org
Unix addict. Internet consultant.             http://www.rot13.org/~dpavlin

From frederic at tamil.fr  Thu Jun 14 21:02:26 2012
From: frederic at tamil.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_Demians?=)
Date: Thu, 14 Jun 2012 21:02:26 +0200
Subject: [Koha-devel] [Koha-translate] String freeze for 3.8.2
In-Reply-To: <CA+95qVQi-5Z8dm+JGs87pRKcM_CN6zoR5OQbukg+ay7dvVUZSQ@mail.gmail.com>
References: <CA+95qVQi-5Z8dm+JGs87pRKcM_CN6zoR5OQbukg+ay7dvVUZSQ@mail.gmail.com>
Message-ID: <4FDA3542.5050706@tamil.fr>

 > We are almost one week out from the release of 3.8.2, which means that
 > on the 15th we go into string freeze before the release.

 > There shouldn't be a huge amount of changes from 3.8.1, but we will
 > soon find out once the translation manager has updated the .po files.

Koha 3.8.2 .po files have been updated on
http://translated.koha-community.org.


From lrea at nekls.org  Thu Jun 14 21:14:14 2012
From: lrea at nekls.org (Liz Rea)
Date: Thu, 14 Jun 2012 14:14:14 -0500
Subject: [Koha-devel] bugzilla default assignee changes
In-Reply-To: <4FD65C5E.7080608@biblibre.com>
References: <4FD369F1.5040407@biblibre.com>
	<CAA7=B8zzhV53e3mJD=p0MbXqK12M92a=AgE0aKfeoDHRZ+apFA@mail.gmail.com>
	<CAC0K6VEnMRSuiUzGSEUJU+1zeYg2uApaZc=QkAbecsHxsYKT9g@mail.gmail.com>
	<CANL=k+FW5GqrvJ1=XV2WUJv-E4dx0Kaz8GsQJHuSQ2uydp216w@mail.gmail.com>
	<4FD65C5E.7080608@biblibre.com>
Message-ID: <BB4E0AB2-DE1C-4BE8-8C9A-99570FA6B325@nekls.org>

All fine by me :)

Liz Rea
lrea at nekls.org



On Jun 11, 2012, at 4:00 PM, Paul Poulain wrote:

> Le 11/06/2012 19:34, Ian Walls a ?crit :
>> It would probably be best to take me off as default assignee for any
>> components, since I have little time for coding lately, and what time I
>> do have is going towards QA.
> I removed you from Hold requests and Self checkout
> 
> -- 
> 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: </pipermail/koha-devel/attachments/20120614/00b7366b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: email_signature.jpeg
Type: image/jpeg
Size: 4862 bytes
Desc: not available
URL: </pipermail/koha-devel/attachments/20120614/00b7366b/attachment.jpeg>

From jcamins at cpbibliography.com  Thu Jun 14 21:23:59 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Thu, 14 Jun 2012 15:23:59 -0400
Subject: [Koha-devel] using CHI directly to use all of it's advantages
In-Reply-To: <20120614182829.GA9627@rot13.org>
References: <20120614182829.GA9627@rot13.org>
Message-ID: <CALVDfQzMCu1p6HJXAu8fER4Bi=OMxfL9Lj1xRcBQbmPR2HU37w@mail.gmail.com>

Dobrica,

> As some of you allready know, Jonathan Swartz had presentation about CHI:
Universal caching for Perl
> at YAPC::NA. Video recording is available at:
>
>
http://ics.webcast.uwex.edu/mediasite/Viewer/?peid=b503ecb42c18452a9f4a95b7372648711d
>
> It got me thinking about our new Koha::Cache layer. For a start, I would
> love to use CHI directly and make it required depenency for Koha since
> it has following features which we already use:
> - memcached back-end - making our own memcache implementation obsolete
> - fastmmap back-end - ditto

We don't actually have a fastmmap implementation yet. That is on my to-do
list, though not very high.

> - DBI cache - making mysql query cache problem solvable
>  way than DBD::Goper suggestion from
>  http://wiki.koha-community.org/wiki/Performance#MySQL_tuning
> - memoize
> - very nice syntax:
>
> my $customer2 = $cache->compute($name2, "10 minutes", sub {
>        get_customer_from_db($name2)
> });
>
> Which I would prefer to our existing Koha::Cache API. It would also save
> us quite a bit of code.

If we were to make CHI a core dependency, I see no reason not to have a
Koha::Cache wrapper subclassing CHI so that if we had to globally adjust
cache settings we could do so. We would use the exact same interface as
that exposed by CHI but would be able to transparently handle Koha-specific
creation options (e.g. any sysprefs for turning the caching on or off, or
selecting a non-default backend).

> CHI has powerfull statistics which basically obsolete my idea of writing
> statistics gathering code through Koha.
>
> I would love to have this in next release, since this is more-or-less my
> last major gripe with current Koha code (short-term goal[1]), so if I
> would love to hear feedback.
>
> 1: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7177
>
> My more long-term goal is to know more about Koha's data-access
> patterns (you are again advised to examine performance wiki page if you
> haven't up to this point).
>
> In most simple sense, only think which is big unknown is wheater we can
> find sane key namespace schema which will allow us to good-enough cache
> invalidation scheme. I strongly think that time-outs are useful just for
> OPAC, not for intranet use!

This is why I do not think memoize is a good idea. Useful cache
invalidation with memoize -- at least as I read the code implementing the
memoize function -- is impossible. Using compute around a method call would
be a much better option. If you want to make it appear seamless without
modifying the underlying function, do the computation in a private method
and surround a call to that with commute in a routine that does nothing
other than run the compute (or invalidate the cache if that is what is
desired).

> It seems to me that CHI redis back-end (which can introspect keyspace
> with keys *) and my "weekly push master in production because of plack"
> approach might bring us to better understanding how our Model layer
> might look like, allmost like reverse engeeniring existing code access
> patterns which has proven to bring a lot of low-hanging fruits so far.
>
> Only disadvantage I can think of is that CHI isn't packaged in stable
> Debian but it is in wheezy so Robin would not need to package it
> forever, just for little while :-)

CHI is very easy to package. I already created packages for myself.

+1 from me on making CHI a core dependency.
-1 on decentralizing cache access with memoize and direct 'use CHI'
throughout the Koha/C4 namespace
+1 on making Koha::Cache a transparent wrapper around CHI and using compute
instead of the existing get/set whenever possible

In summary, I almost entirely agree with you, and would sign off on a patch
changing our caching to CHI only provided it kept the code that interfaces
directly with CHI neatly cordoned off from the rest of the system.

Regards,
Jared

P.S. If we need to replace the SQL query cache with a local cache, doesn't
this mean we're doing it wrong?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120614/f93e38cb/attachment-0001.htm>

From karamqubsi at gmail.com  Fri Jun 15 00:06:58 2012
From: karamqubsi at gmail.com (Karam Qubsi)
Date: Fri, 15 Jun 2012 01:06:58 +0300
Subject: [Koha-devel] [Koha-translate] String freeze for 3.8.2
In-Reply-To: <4FDA3542.5050706@tamil.fr>
References: <CA+95qVQi-5Z8dm+JGs87pRKcM_CN6zoR5OQbukg+ay7dvVUZSQ@mail.gmail.com>
	<4FDA3542.5050706@tamil.fr>
Message-ID: <CAML=htaeQUzU5nBvnH89Oni4OqyBDnBHE0x40LWv4knf_JKGuQ@mail.gmail.com>

Hi
thanks for what you are doing here :)
I wish that in the next release message will contain the Arabic Koha
translation
because  the OPAC is 100% complete and the total translation process is
about 70%.

and we are working on it to make it soon 100% :)

 thanks a lot :)

-- 
Karam Qubsi
Koha Arab Translating Team
http://koha.wikibrary.org/
Wikibrary for Arab Librarians
http://wikibrary.org


On Thu, Jun 14, 2012 at 10:02 PM, Fr?d?ric Demians <frederic at tamil.fr>wrote:

> > We are almost one week out from the release of 3.8.2, which means that
> > on the 15th we go into string freeze before the release.
>
> > There shouldn't be a huge amount of changes from 3.8.1, but we will
> > soon find out once the translation manager has updated the .po files.
>
> Koha 3.8.2 .po files have been updated on
> http://translated.koha-**community.org<http://translated.koha-community.org>
> .
>
> ______________________________**_________________
> Koha-devel mailing list
> Koha-devel at lists.koha-**community.org<Koha-devel at lists.koha-community.org>
> http://lists.koha-community.**org/cgi-bin/mailman/listinfo/**koha-devel<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/ <http://bugs.koha-community.org/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120615/ba09f0e2/attachment.htm>

From bgkriegel at gmail.com  Fri Jun 15 03:07:55 2012
From: bgkriegel at gmail.com (Bernardo Gonzalez Kriegel)
Date: Thu, 14 Jun 2012 22:07:55 -0300
Subject: [Koha-devel] About "Problems on Due date when checking in"
Message-ID: <CADF4kvR9Cg0pG_WV1itwCaV98rXOcTRLcJYdkMPwmQnydQzB4A@mail.gmail.com>

Hi,
we noted a strange behavior: if check out an item and immediately check in
the item then the user is debarred.

Following the code found that user is debarred if ($deltadays
-$grace)->is_positive is true
(_FixFineDaysOnReturn, C4/Circulation.pm)

I think that $deltadays = $calendar->days_between( $dt_due, $dt_today )
needs to be negative if
$dt_due > $dt_today, but is computed on Koha/Calendar.pm as

my $duration = $dateend_temp->delta_days($datestart_temp);
(there is a while that changes $duration but DateTime->compare(
$datestart_temp, $dateend_temp ) = 1 in this case)

Now, the method delta_days() *always returns a positive duration*, even if
$dt_due > $dt_today

If we compute $duration as

my $duration = $dateend_temp->subtract_datetime($datestart_temp);

and add a line on C4/Circulation.pm

my $deltadays = $calendar->days_between( $dt_due, $dt_today );
+return if ( $deltadays->is_negative );

we solved our problem.

Do you think that this is a real bug or we missed some configuration?

(the code examples are from master but the problem is on 3.8.0, where we
found it.
BUG 8045 changes some of the code, but not the use of delta_days() method)

Sincerely
Bernardo

-- 
Bernardo Gonzalez Kriegel
bgkriegel at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120614/a9d2ac03/attachment.htm>

From mtj at kohaaloha.com  Fri Jun 15 06:19:13 2012
From: mtj at kohaaloha.com (Mason James)
Date: Fri, 15 Jun 2012 16:19:13 +1200
Subject: [Koha-devel] About "Problems on Due date when checking in"
In-Reply-To: <CADF4kvR9Cg0pG_WV1itwCaV98rXOcTRLcJYdkMPwmQnydQzB4A@mail.gmail.com>
References: <CADF4kvR9Cg0pG_WV1itwCaV98rXOcTRLcJYdkMPwmQnydQzB4A@mail.gmail.com>
Message-ID: <0360EA56-0023-4AEA-9794-E738318CD3BD@kohaaloha.com>


On 2012-06-15, at 1:07 PM, Bernardo Gonzalez Kriegel wrote:

> Hi,
> we noted a strange behavior: if check out an item and immediately check in the item then the user is debarred.
> 
> Following the code found that user is debarred if ($deltadays -$grace)->is_positive is true 
> (_FixFineDaysOnReturn, C4/Circulation.pm)
> 
> I think that $deltadays = $calendar->days_between( $dt_due, $dt_today ) needs to be negative if
> $dt_due > $dt_today, but is computed on Koha/Calendar.pm as
> 
> my $duration = $dateend_temp->delta_days($datestart_temp);
> (there is a while that changes $duration but DateTime->compare( $datestart_temp, $dateend_temp ) = 1 in this case)
> 
> Now, the method delta_days() always returns a positive duration, even if $dt_due > $dt_today
> 
> If we compute $duration as
> 
> my $duration = $dateend_temp->subtract_datetime($datestart_temp);
> 
> and add a line on C4/Circulation.pm
> 
> my $deltadays = $calendar->days_between( $dt_due, $dt_today );
> +return if ( $deltadays->is_negative );
> 
> we solved our problem.
> 
> Do you think that this is a real bug or we missed some configuration?
> 
> (the code examples are from master but the problem is on 3.8.0, where we found it. 
> BUG 8045 changes some of the code, but not the use of delta_days() method)
> 
> Sincerely
> Bernardo



log a bug > http://bugs.koha-community.org

then attach your patch! :)


-------------- 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: </pipermail/koha-devel/attachments/20120615/6cfe22ba/attachment.pgp>

From frederic at tamil.fr  Fri Jun 15 08:01:51 2012
From: frederic at tamil.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_Demians?=)
Date: Fri, 15 Jun 2012 08:01:51 +0200
Subject: [Koha-devel] [Koha] String freeze for 3.6.6
In-Reply-To: <CALVDfQx2eR8VT6gdnnGJLKgT-pqKoiiF8mHXYJZGVGDGsyW2Xw@mail.gmail.com>
References: <CALVDfQx2eR8VT6gdnnGJLKgT-pqKoiiF8mHXYJZGVGDGsyW2Xw@mail.gmail.com>
Message-ID: <4FDACFCF.10201@tamil.fr>

 > On June 15 we will go into string freeze for 3.6.6, which will be
 > released on June 23. There have not been many changes, so the
 > translation should be pretty painless.

Koha 3.6.6 translation files have been updated on:
http://translate.koha-community.org

Kind regards,
-- 
Fr?d?ric DEMIANS
http://www.tamil.fr/u/fdemians.html

From dpavlin at rot13.org  Fri Jun 15 11:32:09 2012
From: dpavlin at rot13.org (Dobrica Pavlinusic)
Date: Fri, 15 Jun 2012 11:32:09 +0200
Subject: [Koha-devel] using CHI directly to use all of it's advantages
In-Reply-To: <CALVDfQzMCu1p6HJXAu8fER4Bi=OMxfL9Lj1xRcBQbmPR2HU37w@mail.gmail.com>
References: <20120614182829.GA9627@rot13.org>
	<CALVDfQzMCu1p6HJXAu8fER4Bi=OMxfL9Lj1xRcBQbmPR2HU37w@mail.gmail.com>
Message-ID: <20120615093209.GC4532@rot13.org>

On Thu, Jun 14, 2012 at 03:23:59PM -0400, Jared Camins-Esakov wrote:
> > - very nice syntax:
> >
> > my $customer2 = $cache->compute($name2, "10 minutes", sub {
> >        get_customer_from_db($name2)
> > });
> >
> > Which I would prefer to our existing Koha::Cache API. It would also save
> > us quite a bit of code.
> 
> If we were to make CHI a core dependency, I see no reason not to have a
> Koha::Cache wrapper subclassing CHI so that if we had to globally adjust
> cache settings we could do so. We would use the exact same interface as
> that exposed by CHI but would be able to transparently handle Koha-specific
> creation options (e.g. any sysprefs for turning the caching on or off, or
> selecting a non-default backend).

This makes total sense. So, I can expose CHI's ->compute method through
Koha::Cache wrapper and use it that way.

This might even bring us additional benefit of caching for OPAC and not
caching for Intranet for example :-)

> > CHI has powerfull statistics which basically obsolete my idea of writing
> > statistics gathering code through Koha.
> >
> > I would love to have this in next release, since this is more-or-less my
> > last major gripe with current Koha code (short-term goal[1]), so if I
> > would love to hear feedback.
> >
> > 1: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7177
> >
> > My more long-term goal is to know more about Koha's data-access
> > patterns (you are again advised to examine performance wiki page if you
> > haven't up to this point).
> >
> > In most simple sense, only think which is big unknown is wheater we can
> > find sane key namespace schema which will allow us to good-enough cache
> > invalidation scheme. I strongly think that time-outs are useful just for
> > OPAC, not for intranet use!
> 
> This is why I do not think memoize is a good idea. Useful cache
> invalidation with memoize -- at least as I read the code implementing the
> memoize function -- is impossible. Using compute around a method call would
> be a much better option. If you want to make it appear seamless without
> modifying the underlying function, do the computation in a private method
> and surround a call to that with commute in a routine that does nothing
> other than run the compute (or invalidate the cache if that is what is
> desired).

I look at memoize as a easy way to find our which parts of our data
model should be cached. Once we find contended places, we can remove
memoize and implement proper compute for that part of code.

It's more development help than long-term solution.

> +1 from me on making CHI a core dependency.
> -1 on decentralizing cache access with memoize and direct 'use CHI'
> throughout the Koha/C4 namespace
> +1 on making Koha::Cache a transparent wrapper around CHI and using compute
> instead of the existing get/set whenever possible
> 
> In summary, I almost entirely agree with you, and would sign off on a patch
> changing our caching to CHI only provided it kept the code that interfaces
> directly with CHI neatly cordoned off from the rest of the system.

+1 from me about this one.

> P.S. If we need to replace the SQL query cache with a local cache, doesn't
> this mean we're doing it wrong?

Sure, but it's low-hanging fruit, and this is currently a huge
show-stopper if you want to have MySQL on another machine since network
latency is killing our performance.

-- 
Dobrica Pavlinusic               2share!2flame            dpavlin at rot13.org
Unix addict. Internet consultant.             http://www.rot13.org/~dpavlin

From paul.poulain at biblibre.com  Fri Jun 15 11:42:50 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 15 Jun 2012 11:42:50 +0200
Subject: [Koha-devel] using CHI directly to use all of it's advantages
In-Reply-To: <20120615093209.GC4532@rot13.org>
References: <20120614182829.GA9627@rot13.org>
	<CALVDfQzMCu1p6HJXAu8fER4Bi=OMxfL9Lj1xRcBQbmPR2HU37w@mail.gmail.com>
	<20120615093209.GC4532@rot13.org>
Message-ID: <4FDB039A.1050908@biblibre.com>

Le 15/06/2012 11:32, Dobrica Pavlinusic a ?crit :
> I look at memoize as a easy way to find our which parts of our data
> model should be cached. Once we find contended places, we can remove
> memoize and implement proper compute for that part of code.


quick answer (I'll answer more completely later)

About contended places, I see 3:
 * systempreferences that call each syspref one by one. Result in 60 SQL
for each page. It would be better to load all sysprefs in one SQL. The
patch should be easy to write (we had it at BibLibre, it has been lost
in limbo between 3.2 and 3.4 iirc)
 * languages_* stuff. I spoke of this with chris_c during the KohaCon12
hackfest, to know if he understand how this code works. He don't. I
don't. If anyone understand, he is welcomed, but I think (and chris
agrees) that the best option should be to drop all this code and
re-write it from scratch. An acceptable circumvent could be to put in a
hash those tables that never changes (and user can't change through Koha
interface anyway). If a new language arise, just fix the hash !
 * XSLT parsing. That's quite consuming (and first for XSLT result list
!), caching them will have the greatest effect !

So, on the 3 places on my list, 2 are not a problem of caching, in fact ;-)

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From marc at msys.ch  Fri Jun 15 12:02:43 2012
From: marc at msys.ch (Marc Balmer)
Date: Fri, 15 Jun 2012 12:02:43 +0200
Subject: [Koha-devel] using CHI directly to use all of it's advantages
In-Reply-To: <20120615093209.GC4532@rot13.org>
References: <20120614182829.GA9627@rot13.org>
	<CALVDfQzMCu1p6HJXAu8fER4Bi=OMxfL9Lj1xRcBQbmPR2HU37w@mail.gmail.com>
	<20120615093209.GC4532@rot13.org>
Message-ID: <4FDB0843.7060202@msys.ch>

Am 15.06.12 11:32, schrieb Dobrica Pavlinusic:

[...]

>> P.S. If we need to replace the SQL query cache with a local cache, doesn't
>> this mean we're doing it wrong?
> 
> Sure, but it's low-hanging fruit, and this is currently a huge
> show-stopper if you want to have MySQL on another machine since network
> latency is killing our performance.

Actually, when putting the database on a separate machine, the
performance should increase, not decrease, because the load is distributed.

As is, Koha does not scale, since it only runs performant when
everything is one the same machine.

I think an analysis of which SQL statements are executed in which order,
and which are called repeatedly, could be the basis of work to make Koha
talk more efficiently to the database.

To those interested in this, I can higly recommend "Refactoring SQL
Applications" by St?phane Faroult.  Available from O'Reilly in print and
as e-book.

- Marc




From jcamins at cpbibliography.com  Fri Jun 15 13:09:02 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Fri, 15 Jun 2012 07:09:02 -0400
Subject: [Koha-devel] using CHI directly to use all of it's advantages
In-Reply-To: <4FDB039A.1050908@biblibre.com>
References: <20120614182829.GA9627@rot13.org>
	<CALVDfQzMCu1p6HJXAu8fER4Bi=OMxfL9Lj1xRcBQbmPR2HU37w@mail.gmail.com>
	<20120615093209.GC4532@rot13.org> <4FDB039A.1050908@biblibre.com>
Message-ID: <CALVDfQwhhob3AcUQNd6pGB4HocnLx8ObxmzpuLNRj15z2npEKQ@mail.gmail.com>

Paul,

On Fri, Jun 15, 2012 at 5:42 AM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Le 15/06/2012 11:32, Dobrica Pavlinusic a ?crit :
> > I look at memoize as a easy way to find our which parts of our data
> > model should be cached. Once we find contended places, we can remove
> > memoize and implement proper compute for that part of code.
>
>
> quick answer (I'll answer more completely later)
>
> About contended places, I see 3:
>  * systempreferences that call each syspref one by one. Result in 60 SQL
> for each page. It would be better to load all sysprefs in one SQL. The
> patch should be easy to write (we had it at BibLibre, it has been lost
> in limbo between 3.2 and 3.4 iirc)
>

Dobrica said he plans on reimplementing this. It's a showstopper for Plack.
(side note: the Plack-unfriendly hash could easily be replaced by a
Plack-friendly in-process CHI cache, if the consensus were that fastmmap
was a bad idea)


>  * languages_* stuff. I spoke of this with chris_c during the KohaCon12
> hackfest, to know if he understand how this code works. He don't. I
> don't. If anyone understand, he is welcomed, but I think (and chris
> agrees) that the best option should be to drop all this code and
> re-write it from scratch. An acceptable circumvent could be to put in a
> hash those tables that never changes (and user can't change through Koha
> interface anyway). If a new language arise, just fix the hash !
>

This should never have been in the database. Also, there is a 1-1
relationship between almost all the language tables. We should just have
sort of configuration file with that information (maybe in YAML?). Also,
using just one type of language code might be nice.

 * XSLT parsing. That's quite consuming (and first for XSLT result list
> !), caching them will have the greatest effect !
>

It is inefficient, but I have a very surprising performance statistic.
Processing the XSLT for the result list is *not* the most inefficient part
of the results page rendering! Getting authorised value images is the most
inefficient! (I was shocked when I discovered that, too... it makes no
sense at all, but that's what it is)

So, on the 3 places on my list, 2 are not a problem of caching, in fact ;-)


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: </pipermail/koha-devel/attachments/20120615/922010a7/attachment.htm>

From robin at catalyst.net.nz  Fri Jun 15 13:10:44 2012
From: robin at catalyst.net.nz (Robin Sheat)
Date: Fri, 15 Jun 2012 12:10:44 +0100
Subject: [Koha-devel] Bug 7167 New updatedatabase
In-Reply-To: <CALVDfQysX=c+ndHTOxqeC=2xBDOKqMHAkncjZdXT4fGVwa_oUQ@mail.gmail.com>
References: <809BE39CD64BFD4EB9036172EBCCFA310DF89374@S-MAIL-1B.rijksmuseum.intra>
	<CALVDfQysX=c+ndHTOxqeC=2xBDOKqMHAkncjZdXT4fGVwa_oUQ@mail.gmail.com>
Message-ID: <4FDB1834.7060902@catalyst.net.nz>

Op 13-06-12 15:39, Jared Camins-Esakov schreef:
>     Development mode: Currently, you rely on $ENV{DEBUG} from koha-httpd
>     file. I would turn this into a systempref. It is easier for
>     developers to toggle it (compared to restarting httpd service).
> 
> It's easier, but also a lot more dangerous in my opinion. The consensus
> on the caching configuration was that it was too dangerous to allow
> access to it in sysprefs. Based on that logic, I think using an
> environment variable would be the way to go.

My 2p right now is to agree with this, as someone who provides hosted
Koha to people who don't necessarily know the ins-and-outs of it all, I
can see having sysadminny-type options in the sysprefs in general
causing issues.

I'd advocate some standard for these kinds of things in the long
term[0], but for the time being, I think an environment variable could work.

Robin.

[0] other examples I can think of that are impending: the filesystem
location of custom XSLT and files that are attached to bib records but
really live on the filesystem. These should be defined in a location
that only a sysadmin can change them.

From nengard at gmail.com  Fri Jun 15 13:37:41 2012
From: nengard at gmail.com (Nicole Engard)
Date: Fri, 15 Jun 2012 07:37:41 -0400
Subject: [Koha-devel] About "Problems on Due date when checking in"
In-Reply-To: <0360EA56-0023-4AEA-9794-E738318CD3BD@kohaaloha.com>
References: <CADF4kvR9Cg0pG_WV1itwCaV98rXOcTRLcJYdkMPwmQnydQzB4A@mail.gmail.com>
	<0360EA56-0023-4AEA-9794-E738318CD3BD@kohaaloha.com>
Message-ID: <CAC0K6VHvqXqyBHUJPy5E4ftFQMAu5CSf-sSeN=4NaDeqZSNAZg@mail.gmail.com>

This might be this bug:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8243

Nicole

On Fri, Jun 15, 2012 at 12:19 AM, Mason James <mtj at kohaaloha.com> wrote:
>
> On 2012-06-15, at 1:07 PM, Bernardo Gonzalez Kriegel wrote:
>
>> Hi,
>> we noted a strange behavior: if check out an item and immediately check in the item then the user is debarred.
>>
>> Following the code found that user is debarred if ($deltadays -$grace)->is_positive is true
>> (_FixFineDaysOnReturn, C4/Circulation.pm)
>>
>> I think that $deltadays = $calendar->days_between( $dt_due, $dt_today ) needs to be negative if
>> $dt_due > $dt_today, but is computed on Koha/Calendar.pm as
>>
>> my $duration = $dateend_temp->delta_days($datestart_temp);
>> (there is a while that changes $duration but DateTime->compare( $datestart_temp, $dateend_temp ) = 1 in this case)
>>
>> Now, the method delta_days() always returns a positive duration, even if $dt_due > $dt_today
>>
>> If we compute $duration as
>>
>> my $duration = $dateend_temp->subtract_datetime($datestart_temp);
>>
>> and add a line on C4/Circulation.pm
>>
>> my $deltadays = $calendar->days_between( $dt_due, $dt_today );
>> +return if ( $deltadays->is_negative );
>>
>> we solved our problem.
>>
>> Do you think that this is a real bug or we missed some configuration?
>>
>> (the code examples are from master but the problem is on 3.8.0, where we found it.
>> BUG 8045 changes some of the code, but not the use of delta_days() method)
>>
>> Sincerely
>> Bernardo
>
>
>
> log a bug > http://bugs.koha-community.org
>
> then attach your patch! :)
>
>
>
> _______________________________________________
> 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 koha.sekjal at gmail.com  Fri Jun 15 20:31:00 2012
From: koha.sekjal at gmail.com (Ian Walls)
Date: Fri, 15 Jun 2012 14:31:00 -0400
Subject: [Koha-devel] using CHI directly to use all of it's advantages
In-Reply-To: <CALVDfQwhhob3AcUQNd6pGB4HocnLx8ObxmzpuLNRj15z2npEKQ@mail.gmail.com>
References: <20120614182829.GA9627@rot13.org>
	<CALVDfQzMCu1p6HJXAu8fER4Bi=OMxfL9Lj1xRcBQbmPR2HU37w@mail.gmail.com>
	<20120615093209.GC4532@rot13.org> <4FDB039A.1050908@biblibre.com>
	<CALVDfQwhhob3AcUQNd6pGB4HocnLx8ObxmzpuLNRj15z2npEKQ@mail.gmail.com>
Message-ID: <CANL=k+Fti5G8VD9J=bfEhWWcR21B9K-zG4w_0JR+rjQqaTtY+Q@mail.gmail.com>

> This should never have been in the database. Also, there is a 1-1
> relationship between almost all the language tables. We should just have
> sort of configuration file with that information (maybe in YAML?). Also,
> using just one type of language code might be nice.
>
>  * XSLT parsing. That's quite consuming (and first for XSLT result list
>> !), caching them will have the greatest effect !
>>
>
I'd love to see if using Turbomarc would give us a visible XSLT processing
boost.  Index data reports 2x speed increases.



> It is inefficient, but I have a very surprising performance statistic.
> Processing the XSLT for the result list is *not* the most inefficient part
> of the results page rendering! Getting authorised value images is the most
> inefficient! (I was shocked when I discovered that, too... it makes no
> sense at all, but that's what it is)
>

I recall this from a while ago... basically every time you get the
authorised value images, you have to parse out the MARC framework, or some
massively overwrought mechanism.  Before, though, this was done whether or
not you even USED the images, but that's since been patched.  A more
thorough implementation of the auth value images would go a long way here.


-Ian



>
> --
> 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/
>
>
> _______________________________________________
> 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: </pipermail/koha-devel/attachments/20120615/3d3febc3/attachment.htm>

From koha.sekjal at gmail.com  Fri Jun 15 20:51:58 2012
From: koha.sekjal at gmail.com (Ian Walls)
Date: Fri, 15 Jun 2012 14:51:58 -0400
Subject: [Koha-devel] Bug 7167 New updatedatabase
In-Reply-To: <4FDB1834.7060902@catalyst.net.nz>
References: <809BE39CD64BFD4EB9036172EBCCFA310DF89374@S-MAIL-1B.rijksmuseum.intra>
	<CALVDfQysX=c+ndHTOxqeC=2xBDOKqMHAkncjZdXT4fGVwa_oUQ@mail.gmail.com>
	<4FDB1834.7060902@catalyst.net.nz>
Message-ID: <CANL=k+Fv8Xkr+N0e9KiNU3S385YqHiYBRBOyPpbQ_3-eJArjUg@mail.gmail.com>

Just bringing this back to original intent:  it's hard for developers and
testers to work with patches that have DB revs, so we want to fix that.
Basically, that means being able to easily tell what changes have been made
to the DB beyond the natural Koha progression.

The problem with the code we have, I think, is that we're trying to make
this something that can be managed in the staff client.  Our target
audience here isn't Koha users, it's testers and developers.  Whatever
we're doing to address our needs as code maintainers must not effect the
people actually using the software.

I've floated this before, so I will now again:  I think we need to move our
database updates to individual Perl files, with a set API: DESCRIBE, CHECK,
DO and UNDO.  If every atomic update contains the necessary logic to handle
these four functions, we'll be able to:

1.  see what the change is BEFORE applying it
2.  see if the change is necessary BEFORE applying it
3.  revert changes after testing them

updatedatabase, then, becomes the mechanism by which the RM assigns these
Perl files a linear sequence and distinct DB rev number.  Any change that's
running "on top" of the core Koha code won't need a temporary/fake number
assigned to it to get added.  Maintaining it will be the job of the
sysadmin who decided to run non-core code to begin with, but that's nothing
new.

It's very rare that sequence is important for DB revs, as we have few that
change the table structure, and those that do often do not interact in a
short span of time.  If you find a Koha DB rev doesn't apply to your
customized DB structure, it's time for a rebase!  I really don't think this
is a frequent enough occurrence to warrant too much consideration.

In short, I think we should hold off on our eagerness to push this change
through, and wait until we've come up with a different solution.  We're
only putting the users of Koha at risk for serious DB-related bugs, with no
tangible gain in it for them.

Cheers,


-Ian

On Fri, Jun 15, 2012 at 7:10 AM, Robin Sheat <robin at catalyst.net.nz> wrote:

> Op 13-06-12 15:39, Jared Camins-Esakov schreef:
> >     Development mode: Currently, you rely on $ENV{DEBUG} from koha-httpd
> >     file. I would turn this into a systempref. It is easier for
> >     developers to toggle it (compared to restarting httpd service).
> >
> > It's easier, but also a lot more dangerous in my opinion. The consensus
> > on the caching configuration was that it was too dangerous to allow
> > access to it in sysprefs. Based on that logic, I think using an
> > environment variable would be the way to go.
>
> My 2p right now is to agree with this, as someone who provides hosted
> Koha to people who don't necessarily know the ins-and-outs of it all, I
> can see having sysadminny-type options in the sysprefs in general
> causing issues.
>
> I'd advocate some standard for these kinds of things in the long
> term[0], but for the time being, I think an environment variable could
> work.
>
> Robin.
>
> [0] other examples I can think of that are impending: the filesystem
> location of custom XSLT and files that are attached to bib records but
> really live on the filesystem. These should be defined in a location
> that only a sysadmin can change them.
> _______________________________________________
> 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: </pipermail/koha-devel/attachments/20120615/799800c1/attachment-0001.htm>

From danielg.koha at gmail.com  Fri Jun 15 23:40:03 2012
From: danielg.koha at gmail.com (Daniel Grobani)
Date: Fri, 15 Jun 2012 14:40:03 -0700
Subject: [Koha-devel] Call for News for the June Newsletter (especially re
	KohaCon12!)
Message-ID: <CAOeKewgTy46ySAk4z2k0c+4zHkoC7kG9_sYNEmTn+q9AZ0RVZQ@mail.gmail.com>

Dear Koha Kommunitarians,

I'm harvesting news for the June newsletter. Please send me by the
25th anything you think your fellow community members might like to
know about. I'm particularly interested in accounts of happenings at KohaCon12.

"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 for the
gossip/society column about what you're currently working on. And if
you know of a go-live not announced on the list, please be sure to let
me know about it.

Thanks,
Daniel Grobani

From mtj at kohaaloha.com  Sat Jun 16 05:37:45 2012
From: mtj at kohaaloha.com (Mason James)
Date: Sat, 16 Jun 2012 15:37:45 +1200
Subject: [Koha-devel] Bug 7167 New updatedatabase
In-Reply-To: <CANL=k+Fv8Xkr+N0e9KiNU3S385YqHiYBRBOyPpbQ_3-eJArjUg@mail.gmail.com>
References: <809BE39CD64BFD4EB9036172EBCCFA310DF89374@S-MAIL-1B.rijksmuseum.intra>
	<CALVDfQysX=c+ndHTOxqeC=2xBDOKqMHAkncjZdXT4fGVwa_oUQ@mail.gmail.com>
	<4FDB1834.7060902@catalyst.net.nz>
	<CANL=k+Fv8Xkr+N0e9KiNU3S385YqHiYBRBOyPpbQ_3-eJArjUg@mail.gmail.com>
Message-ID: <DEA4C22D-6255-45B5-87DA-C0AFE828CD92@kohaaloha.com>


On 2012-06-16, at 6:51 AM, Ian Walls wrote:

> Just bringing this back to original intent:  it's hard for developers and testers to work with patches that have DB revs, so we want to fix that.  Basically, that means being able to easily tell what changes have been made to the DB beyond the natural Koha progression.
> 
> The problem with the code we have, I think, is that we're trying to make this something that can be managed in the staff client.  Our target audience here isn't Koha users, it's testers and developers.  Whatever we're doing to address our needs as code maintainers must not effect the people actually using the software.
> 
> I've floated this before, so I will now again:  I think we need to move our database updates to individual Perl files, with a set API: DESCRIBE, CHECK, DO and UNDO.  If every atomic update contains the necessary logic to handle these four functions, we'll be able to:
> 
> 1.  see what the change is BEFORE applying it
> 2.  see if the change is necessary BEFORE applying it
> 3.  revert changes after testing them
> 
> updatedatabase, then, becomes the mechanism by which the RM assigns these Perl files a linear sequence and distinct DB rev number.  Any change that's running "on top" of the core Koha code won't need a temporary/fake number assigned to it to get added.  Maintaining it will be the job of the sysadmin who decided to run non-core code to begin with, but that's nothing new.
> 
> It's very rare that sequence is important for DB revs, as we have few that change the table structure, and those that do often do not interact in a short span of time.  If you find a Koha DB rev doesn't apply to your customized DB structure, it's time for a rebase!  I really don't think this is a frequent enough occurrence to warrant too much consideration.
> 
> In short, I think we should hold off on our eagerness to push this change through, and wait until we've come up with a different solution.  We're only putting the users of Koha at risk for serious DB-related bugs, with no tangible gain in it for them.


firstly, 
i love Ian's solution, i think its the ultimate solution for db-upgrades in Koha. (and i think most devs would agree?)

i think we should accept Paul's patch, and plan to add Ian's 'DESCRIBE, CHECK, DO, UNDO'  functionally to it, in a later patch

Paul's solution is missing the ability to CHECK (and UNDO?) db-patches
if we add those features to Paul's patch, we basically have Ian's solution,  am i right here?


surely this is the best way towards a solution here? 
rather than abandoning Paul's patch for a better patch, that does not yet exist


-------------- 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: </pipermail/koha-devel/attachments/20120616/3f6a7d34/attachment.pgp>

From M.de.Rooy at rijksmuseum.nl  Sat Jun 16 08:40:00 2012
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Sat, 16 Jun 2012 06:40:00 +0000
Subject: [Koha-devel] Bug 7167 New updatedatabase
In-Reply-To: <DEA4C22D-6255-45B5-87DA-C0AFE828CD92@kohaaloha.com>
References: <809BE39CD64BFD4EB9036172EBCCFA310DF89374@S-MAIL-1B.rijksmuseum.intra>
	<CALVDfQysX=c+ndHTOxqeC=2xBDOKqMHAkncjZdXT4fGVwa_oUQ@mail.gmail.com>
	<4FDB1834.7060902@catalyst.net.nz>
	<CANL=k+Fv8Xkr+N0e9KiNU3S385YqHiYBRBOyPpbQ_3-eJArjUg@mail.gmail.com>,
	<DEA4C22D-6255-45B5-87DA-C0AFE828CD92@kohaaloha.com>
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA310DF8C26E@S-MAIL-1B.rijksmuseum.intra>

Thanks your feedback until now! 
I tend to agree more with Mason here. If Paul adjusts his patch to meet QA, let's move forward with that patch. Adding the REVERT logic would make it even better later on. 

To get the discussion further, I think we still need two answers: 
1) Should we add the distinction between numbered approved dbrevs and unnumbered ones in testing stage that I suggested in my QA comments?
2) As Jared suggested, should we leave enabling the development mode of this feature in an environment variable (DEBUG, set in Apache conf)? 

Marcel

________________________________________
Van: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] namens Mason James [mtj at kohaaloha.com]
Verzonden: zaterdag 16 juni 2012 5:37
To: Ian Walls
Cc: koha-devel at lists.koha-community.org
Onderwerp: Re: [Koha-devel] Bug 7167 New updatedatabase

On 2012-06-16, at 6:51 AM, Ian Walls wrote:

> Just bringing this back to original intent:  it's hard for developers and testers to work with patches that have DB revs, so we want to fix that.  Basically, that means being able to easily tell what changes have been made to the DB beyond the natural Koha progression.
>
> The problem with the code we have, I think, is that we're trying to make this something that can be managed in the staff client.  Our target audience here isn't Koha users, it's testers and developers.  Whatever we're doing to address our needs as code maintainers must not effect the people actually using the software.
>
> I've floated this before, so I will now again:  I think we need to move our database updates to individual Perl files, with a set API: DESCRIBE, CHECK, DO and UNDO.  If every atomic update contains the necessary logic to handle these four functions, we'll be able to:
>
> 1.  see what the change is BEFORE applying it
> 2.  see if the change is necessary BEFORE applying it
> 3.  revert changes after testing them
>
> updatedatabase, then, becomes the mechanism by which the RM assigns these Perl files a linear sequence and distinct DB rev number.  Any change that's running "on top" of the core Koha code won't need a temporary/fake number assigned to it to get added.  Maintaining it will be the job of the sysadmin who decided to run non-core code to begin with, but that's nothing new.
>
> It's very rare that sequence is important for DB revs, as we have few that change the table structure, and those that do often do not interact in a short span of time.  If you find a Koha DB rev doesn't apply to your customized DB structure, it's time for a rebase!  I really don't think this is a frequent enough occurrence to warrant too much consideration.
>
> In short, I think we should hold off on our eagerness to push this change through, and wait until we've come up with a different solution.  We're only putting the users of Koha at risk for serious DB-related bugs, with no tangible gain in it for them.


firstly,
i love Ian's solution, i think its the ultimate solution for db-upgrades in Koha. (and i think most devs would agree?)

i think we should accept Paul's patch, and plan to add Ian's 'DESCRIBE, CHECK, DO, UNDO'  functionally to it, in a later patch

Paul's solution is missing the ability to CHECK (and UNDO?) db-patches
if we add those features to Paul's patch, we basically have Ian's solution,  am i right here?


surely this is the best way towards a solution here?
rather than abandoning Paul's patch for a better patch, that does not yet exist

From cnighswonger at foundations.edu  Sat Jun 16 13:48:47 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Sat, 16 Jun 2012 07:48:47 -0400
Subject: [Koha-devel] Bug 7167 New updatedatabase
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA310DF8C26E@S-MAIL-1B.rijksmuseum.intra>
References: <809BE39CD64BFD4EB9036172EBCCFA310DF89374@S-MAIL-1B.rijksmuseum.intra>
	<CALVDfQysX=c+ndHTOxqeC=2xBDOKqMHAkncjZdXT4fGVwa_oUQ@mail.gmail.com>
	<4FDB1834.7060902@catalyst.net.nz>
	<CANL=k+Fv8Xkr+N0e9KiNU3S385YqHiYBRBOyPpbQ_3-eJArjUg@mail.gmail.com>
	<DEA4C22D-6255-45B5-87DA-C0AFE828CD92@kohaaloha.com>
	<809BE39CD64BFD4EB9036172EBCCFA310DF8C26E@S-MAIL-1B.rijksmuseum.intra>
Message-ID: <CAP3yOone8ezRFdFSvyM-n8ZTAU0+CzaFmr+jbshYgJbmW0aGYw@mail.gmail.com>

On Sat, Jun 16, 2012 at 2:40 AM, Marcel de Rooy <M.de.Rooy at rijksmuseum.nl>wrote:

> Thanks your feedback until now!
> I tend to agree more with Mason here. If Paul adjusts his patch to meet
> QA, let's move forward with that patch. Adding the REVERT logic would make
> it even better later on.
>
>
I agree w/Mason also. We can build on Paul's work going forward.


> To get the discussion further, I think we still need two answers:
> 1) Should we add the distinction between numbered approved dbrevs and
> unnumbered ones in testing stage that I suggested in my QA comments?
>

+1 I think the RM should have the job of choosing DB numbers in any case.
That removes a bunch of administrative type headaches.


> 2) As Jared suggested, should we leave enabling the development mode of
> this feature in an environment variable (DEBUG, set in Apache conf)?
>

+1 Here again, this is a sysadmin type function. Moving it to sysprefs is
asking for trouble from curious users imho.

Kind Regards,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120616/607b8d32/attachment.htm>

From melia at bywatersolutions.com  Tue Jun 19 22:54:09 2012
From: melia at bywatersolutions.com (Melia Meggs)
Date: Tue, 19 Jun 2012 13:54:09 -0700
Subject: [Koha-devel] urgent call for testing!
Message-ID: <CACv9bVSd_LB30_GhB0qEmVGnJ6hkLXrLSXpKXTrCwhKTTC1oNQ@mail.gmail.com>

Hi Koha developers!

We have hundreds of libraries running 3.8.1, and we've come across several
show-stopper bugs that are really causing problems for these libraries
right now.  Here are the major problems that we've come across so far:

1. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8253
All fines are doubling in 3.8.1.

2. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8267
No overdue notices are going out.

3. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8110
Calendar is not honoring closed days.

We have submitted patches for all of these problems, and we are making an
urgent call for testing to help us get these fixes into 3.8.2 in the next
two days if at all possible.  Please help us with testing/QA if you can!!

Thanks,

Melia

P.S. Also hearing lots of complaints about this one.  It not a show-stopper
but is signed off and needs QA as well:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8043
-- 
Melia Meggs
Chief Operations Officer
ByWater Solutions
bywatersolutions.com
*Visit Us At ALA Booth #323*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120619/07973f24/attachment.htm>

From M.de.Rooy at rijksmuseum.nl  Wed Jun 20 13:18:08 2012
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Wed, 20 Jun 2012 11:18:08 +0000
Subject: [Koha-devel] urgent call for testing!
In-Reply-To: <CACv9bVSd_LB30_GhB0qEmVGnJ6hkLXrLSXpKXTrCwhKTTC1oNQ@mail.gmail.com>
References: <CACv9bVSd_LB30_GhB0qEmVGnJ6hkLXrLSXpKXTrCwhKTTC1oNQ@mail.gmail.com>
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA310DF9C3D4@S-MAIL-1B.rijksmuseum.intra>

At least 8043 passed qa already ;)



________________________________
Van: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] namens Melia Meggs [melia at bywatersolutions.com]
Verzonden: dinsdag 19 juni 2012 22:54
To: koha-devel at lists.koha-community.org
Onderwerp: [Koha-devel] urgent call for testing!

Hi Koha developers!

We have hundreds of libraries running 3.8.1, and we've come across several show-stopper bugs that are really causing problems for these libraries right now.  Here are the major problems that we've come across so far:

1. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8253
All fines are doubling in 3.8.1.

2. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8267
No overdue notices are going out.

3. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8110
Calendar is not honoring closed days.

We have submitted patches for all of these problems, and we are making an urgent call for testing to help us get these fixes into 3.8.2 in the next two days if at all possible.  Please help us with testing/QA if you can!!

Thanks,

Melia

P.S. Also hearing lots of complaints about this one.  It not a show-stopper but is signed off and needs QA as well:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8043
--
Melia Meggs
Chief Operations Officer
ByWater Solutions
bywatersolutions.com<http://bywatersolutions.com>
Visit Us At ALA Booth #323


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120620/06cb8781/attachment.htm>

From mtj at kohaaloha.com  Wed Jun 20 16:18:09 2012
From: mtj at kohaaloha.com (Mason James)
Date: Thu, 21 Jun 2012 02:18:09 +1200
Subject: [Koha-devel] urgent call for testing!
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA310DF9C3D4@S-MAIL-1B.rijksmuseum.intra>
References: <CACv9bVSd_LB30_GhB0qEmVGnJ6hkLXrLSXpKXTrCwhKTTC1oNQ@mail.gmail.com>
	<809BE39CD64BFD4EB9036172EBCCFA310DF9C3D4@S-MAIL-1B.rijksmuseum.intra>
Message-ID: <EF016CB1-BA96-4831-85A0-840C0B4A4A29@kohaaloha.com>


On 2012-06-20, at 11:18 PM, Marcel de Rooy wrote:

> At least 8043 passed qa already ;)

cheers Marcel :)

i've just passed-qa on 8110, too


> 
> Hi Koha developers!
> 
> We have hundreds of libraries running 3.8.1, and we've come across several show-stopper bugs that are really causing problems for these libraries right now.  Here are the major problems that we've come across so far:
> 
> 1. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8253
> All fines are doubling in 3.8.1.
> 
> 2. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8267
> No overdue notices are going out.
> 
> 3. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8110
> Calendar is not honoring closed days.





-------------- 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: </pipermail/koha-devel/attachments/20120621/1a18abf9/attachment.pgp>

From M.de.Rooy at rijksmuseum.nl  Wed Jun 20 16:36:04 2012
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Wed, 20 Jun 2012 14:36:04 +0000
Subject: [Koha-devel] urgent call for testing!
In-Reply-To: <EF016CB1-BA96-4831-85A0-840C0B4A4A29@kohaaloha.com>
References: <CACv9bVSd_LB30_GhB0qEmVGnJ6hkLXrLSXpKXTrCwhKTTC1oNQ@mail.gmail.com>
	<809BE39CD64BFD4EB9036172EBCCFA310DF9C3D4@S-MAIL-1B.rijksmuseum.intra>,
	<EF016CB1-BA96-4831-85A0-840C0B4A4A29@kohaaloha.com>
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA310DF9E671@S-MAIL-1B.rijksmuseum.intra>

8267 too

________________________________________
Van: Mason James [mtj at kohaaloha.com]
Verzonden: woensdag 20 juni 2012 16:18
To: Marcel de Rooy
Cc: koha-devel at lists.koha-community.org
Onderwerp: Re: [Koha-devel] urgent call for testing!

On 2012-06-20, at 11:18 PM, Marcel de Rooy wrote:

> At least 8043 passed qa already ;)

cheers Marcel :)

i've just passed-qa on 8110, too


>
> Hi Koha developers!
>
> We have hundreds of libraries running 3.8.1, and we've come across several show-stopper bugs that are really causing problems for these libraries right now.  Here are the major problems that we've come across so far:
>
> 1. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8253
> All fines are doubling in 3.8.1.
>
> 2. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8267
> No overdue notices are going out.
>
> 3. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8110
> Calendar is not honoring closed days.

From nengard at gmail.com  Wed Jun 20 19:24:08 2012
From: nengard at gmail.com (Nicole Engard)
Date: Wed, 20 Jun 2012 13:24:08 -0400
Subject: [Koha-devel] urgent call for testing!
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA310DF9E671@S-MAIL-1B.rijksmuseum.intra>
References: <CACv9bVSd_LB30_GhB0qEmVGnJ6hkLXrLSXpKXTrCwhKTTC1oNQ@mail.gmail.com>
	<809BE39CD64BFD4EB9036172EBCCFA310DF9C3D4@S-MAIL-1B.rijksmuseum.intra>
	<EF016CB1-BA96-4831-85A0-840C0B4A4A29@kohaaloha.com>
	<809BE39CD64BFD4EB9036172EBCCFA310DF9E671@S-MAIL-1B.rijksmuseum.intra>
Message-ID: <CAC0K6VHyS3kauCk8XWz-NaUzRpvrA87Nt8EB+QF_iks6eFgWEQ@mail.gmail.com>

Woo Hoo!! That just leaves this one:

 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8253

And we've got a little bit more time.

Nicole

On Wed, Jun 20, 2012 at 10:36 AM, Marcel de Rooy
<M.de.Rooy at rijksmuseum.nl> wrote:
> 8267 too
>
> ________________________________________
> Van: Mason James [mtj at kohaaloha.com]
> Verzonden: woensdag 20 juni 2012 16:18
> To: Marcel de Rooy
> Cc: koha-devel at lists.koha-community.org
> Onderwerp: Re: [Koha-devel] urgent call for testing!
>
> On 2012-06-20, at 11:18 PM, Marcel de Rooy wrote:
>
>> At least 8043 passed qa already ;)
>
> cheers Marcel :)
>
> i've just passed-qa on 8110, too
>
>
>>
>> Hi Koha developers!
>>
>> We have hundreds of libraries running 3.8.1, and we've come across several show-stopper bugs that are really causing problems for these libraries right now. ?Here are the major problems that we've come across so far:
>>
>> 1. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8253
>> All fines are doubling in 3.8.1.
>>
>> 2. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8267
>> No overdue notices are going out.
>>
>> 3. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8110
>> Calendar is not honoring closed days.
> _______________________________________________
> 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  Wed Jun 20 19:39:38 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 20 Jun 2012 19:39:38 +0200
Subject: [Koha-devel] urgent call for testing!
In-Reply-To: <CACv9bVSd_LB30_GhB0qEmVGnJ6hkLXrLSXpKXTrCwhKTTC1oNQ@mail.gmail.com>
References: <CACv9bVSd_LB30_GhB0qEmVGnJ6hkLXrLSXpKXTrCwhKTTC1oNQ@mail.gmail.com>
Message-ID: <4FE20ADA.1070108@biblibre.com>

Le 19/06/2012 22:54, Melia Meggs a ?crit :
> Hi Koha developers!
Hi Melia,

> We have hundreds of libraries running 3.8.1, and we've come across
> several show-stopper bugs that are really causing problems for these
> libraries right now.  Here are the major problems that we've come across
> so far:
That's typically the case where "signed-off in the name of libraryX is
relevant" !

(just in case you missed this discussion, I started a thread requesting
that BibLibre 3 project managers could sign-off patches already applied
to a library, and do something like "proxy sign-off", the thread is
"Signing-off a patch for a customer", may 28th)

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From koha.sekjal at gmail.com  Wed Jun 20 20:57:24 2012
From: koha.sekjal at gmail.com (Ian Walls)
Date: Wed, 20 Jun 2012 14:57:24 -0400
Subject: [Koha-devel] urgent call for testing!
In-Reply-To: <4FE20ADA.1070108@biblibre.com>
References: <CACv9bVSd_LB30_GhB0qEmVGnJ6hkLXrLSXpKXTrCwhKTTC1oNQ@mail.gmail.com>
	<4FE20ADA.1070108@biblibre.com>
Message-ID: <CANL=k+FpXB1iEKTDKQxg+Y0bK1pSN41o-3hRTAFeODd9gF_Xng@mail.gmail.com>

Bug 8251 has also been a bit nasty, and is now passed QA.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8251


-Ian

On Wed, Jun 20, 2012 at 1:39 PM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Le 19/06/2012 22:54, Melia Meggs a ?crit :
> > Hi Koha developers!
> Hi Melia,
>
> > We have hundreds of libraries running 3.8.1, and we've come across
> > several show-stopper bugs that are really causing problems for these
> > libraries right now.  Here are the major problems that we've come across
> > so far:
> That's typically the case where "signed-off in the name of libraryX is
> relevant" !
>
> (just in case you missed this discussion, I started a thread requesting
> that BibLibre 3 project managers could sign-off patches already applied
> to a library, and do something like "proxy sign-off", the thread is
> "Signing-off a patch for a customer", may 28th)
>
> --
> 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: </pipermail/koha-devel/attachments/20120620/2b87fb92/attachment.htm>

From chris at bigballofwax.co.nz  Wed Jun 20 22:57:01 2012
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Thu, 21 Jun 2012 08:57:01 +1200
Subject: [Koha-devel] 1 day left to translate for 3.8.2
Message-ID: <CA+95qVQ2SS6+5w=8JBoMDjE5vP2De3h5nVVPCRR+nzyBELY-9w@mail.gmail.com>

Hi all

I plan to release 3.8.2 tomorrow nz time, which should give you all
about 1 more day to translate as much as you can.

Frederic would you be able to send a pull request for the new .po
files at the end of your business day tomorrow?

Thanks very much

Chris

From psm_vu at india.com  Thu Jun 21 10:39:53 2012
From: psm_vu at india.com (Partha Mukhopadhyay)
Date: Thu, 21 Jun 2012 08:39:53 +0000 (UTC)
Subject: [Koha-devel] Acauisition in Koha 3.8.1: Problems
Message-ID: <1132502164.4933.1340267993523.JavaMail.tomcat@be12>

An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120621/45598a93/attachment.htm>

From f.demians at tamil.fr  Thu Jun 21 16:41:34 2012
From: f.demians at tamil.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_Demians?=)
Date: Thu, 21 Jun 2012 16:41:34 +0200
Subject: [Koha-devel] 1 day left to translate for 3.8.2
In-Reply-To: <CA+95qVQ2SS6+5w=8JBoMDjE5vP2De3h5nVVPCRR+nzyBELY-9w@mail.gmail.com>
References: <CA+95qVQ2SS6+5w=8JBoMDjE5vP2De3h5nVVPCRR+nzyBELY-9w@mail.gmail.com>
Message-ID: <4FE3329E.5050309@tamil.fr>

For translators working like mad in order to improve their language 
support in coming Koha 3.8.2, you can work until 7pm UTC.

-- 
Fr?d?ric DEMIANS
http://www.tamil.fr/u/fdemians.html


From robin at catalyst.net.nz  Thu Jun 21 19:02:28 2012
From: robin at catalyst.net.nz (Robin Sheat)
Date: Thu, 21 Jun 2012 18:02:28 +0100
Subject: [Koha-devel] New Koha repository for 3.6 series
Message-ID: <4FE353A4.9020000@catalyst.net.nz>

People who are on the debian packages have just had the option of
sitting on the real bleeding edge by running packages from master, or
just a bit back from it by running the newest stable series (currently 3.8.)

This isn't what everyone wants to do however, some people like to be a
bit more conservative. For those people, there is now a section of the
Koha Debian repository called "oldstable." It will track the koha
releases that are stable and supported, but a series behind the most
current one.

Documentation for how to access it is here:
http://wiki.koha-community.org/wiki/Koha_3.8_on_Debian_Squeeze

It will keep up with the current supported release, so when 3.10.0 comes
out, it will jump to 3.8.6 (or whatever is out at the time.)

If you have any issues or questions, please post them here, or report
them on bugzilla: http://bugs.koha-community.org/bugzilla3/

-- 
Robin Sheat
Catalyst IT Ltd.
? +64 4 803 2204
GPG: 5957 6D23 8B16 EFAB FEF8  7175 14D3 6485 A99C EB6D

From chris at bigballofwax.co.nz  Fri Jun 22 00:04:19 2012
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Fri, 22 Jun 2012 10:04:19 +1200
Subject: [Koha-devel] Koha 3.8.2 Released
Message-ID: <CA+95qVQW5H=nH8L5seoWfFPM5R+re9NPVazGYUPP1mpNtAviKg@mail.gmail.com>

The Koha community is proud to release Koha version 3.8.2. This is a
bugfix release, and contains a large number of fixes.

You can obtain Koha 3.8.2 from the  http://download.koha-community.org
site. Debian packages will be available from the
http://debian.koha-community.org shortly also.

Please read the release notes below for more information

RELEASE NOTES FOR KOHA 3.8.2
21 Jun 2012
========================================================================

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.8.2 can be downloaded from:

    http://download.koha-community.org/koha-3.08.02.tar.gz

Installation instructions can be found:

   in the INSTALL files that come in the tarball

Koha 3.8.2 is a bugfix/maintenance release.

Highlights of 3.8.2
======================

8140	blocker		Error when exporting label xml
8247	blocker		adding basket doesn't save basket name, internal or vendor note
7329	critical	The "undo import into catalog" command deletes items
onloan without checking
8056	critical	CircAutoPrintQuickSlip set to clear doesn't work
8062	critical	Cart email broken for non english templates
8135	critical	Services Directory and itemrecorddisplay.pl File Missing
After Install
8144	critical	775 tag in the MARC record causes display issue
5327	major		Unit tests required for all C4 modules
7112	major		Having two prices in 020$c causes basket creation to fail
from staged marc import
8057	major		Error when adding a patron with email address
8082	major		The:  IssuingInProcess  configuration setting is working in reverse.
8145	major		opac-tags.pl fails when DEBUG is set
8182	major		Problem with overdue fine calculations after upgrade
8201	major		can't change receive date


Bugs fixed in 3.8.2
======================

3638	normal		Status of hold not changed when item checked in via SIP2 Interface
4330	normal		Copyright statements out of date
4838	normal		Repeated authority headings break biblio record data entry form
5795	normal		Missing ReservesControlBranch system pref in database installer
6858	normal		Adds staticfines.pl for static fines processing
7127	normal		Templates must be valid XHTML
7178	normal		Improve order item creation
7586	normal		Search: Language restriction does  NOT show expected
results (no items shown)
7599	normal		Cart JavaScript contains untranslatable English strings
7810	normal		C4/Auth.pm - on plack restart session is undefined
7872	normal		C4::Items should use C4::Koha methods instead of
duplicating SQL queries
7951	normal		Suspending holds needs a system preference
7952	normal		PDF::Reuse under plack writes to console STDOUT instead to browser
7961	normal		Local cover images should support CSV link files
8005	normal		Lost item is not anonymized when checked in
8111	normal		Language chooser display problem in self-checkout
8116	normal		z3950 empty search causes silent warning in koha-error_log
8124	normal		Hide option to download results of items with no checkouts report
8129	normal		quick slips issuing does not work
8136	normal		Changes the expected lenght of 100$a in rebuild_zebra.pl
8160	normal		Link to cataloging appears for users without cataloging permission
8161	normal		Cataloging home page should be accessible to users with
permission to edit catalog or edit items
8171	normal		Improper escaping of quotes during z39.50 queries leads
to broken html
8176	normal		$sqlwhere is undefined in C4::Serials in GetSubscriptions
8184	normal		Duplicate budget page lacks heading and breadcrumbs
8197	normal		Software error when you have cleaned cookies in your
browser and try to past the url to opac-topissues.pl
8226	normal		'OpacFooter' markup/css improvements
5312	minor	XHTML correction in authority summary
6141	minor	html glitches causing problems to translator
7815	minor	Order pickup library list by name rather than by code
7948	minor	Printing transfer slip loses barcode field focus
8009	minor	Item descriptive data not populated on pay.pl
8014	minor	On the patron entry form hide "restricted until" field if
"Restricted: No" is checked
8040	minor	a menu misnamed in budgets
8119	minor	Show hint when disabling active currency checkbox
8122	minor	Add a link to new library group creation from empty groups message
8139	minor	Fix the CSS for the recent comments to prevent leftmenu
overlapping it.
8150	minor	Patron circulation history has a fossil navagation bar
8166	minor	Adding new currencies & exchange rates if not fill any
field it save blank record
8195	minor	The selected link in include menus must be bold
8217	minor	Focus on search box in Detail page (staff search)
3521	trivial	Items table in catalogue/detail.pl and
cataloguing/additem.pl is sorted nonsensically
6267	trivial	custom http user-agent in check-url.pl (fix for
books.google.com 401 error)
7368	trivial	General staff client typo omnibus
8222	trivial	The zip code field is mandatory by default
6684	enhancement	koha-remove should check the number of arguments it gets
7444	enhancement	Use T::T date plugin to display dates omnibus
7788	enhancement	Tiny problems with calling GetShelf
7847	enhancement	OPAC search dies with plack
7926	enhancement	Acq search results show empty parenthesis for orders
without basket group
7941	enhancement	Fix version numbers in modules and set up a system to
keep them up to date
8080	enhancement	login and password is pre-filled by the browser when
creating a new patron
8107	enhancement	Disabled buttons not distinguishable from enabled buttons.
8138	enhancement	Add 773$t field to xslt
8178	enhancement	circ/circulation.pl under plack duplicates checkout rows


New system preferences in 3.8.2
=================================

  * ReservesControlBranch
  * SuspendHoldsIntranet
  * SuspendHoldsOpac


System requirements
======================

    Changes since 3.6:

    * No new system requirements


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.8/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:

the following languages:
  * Chinese -Taiwan- (100%, OPAC 100%)
  * German (100%, OPAC 100%)
  * Italian (100%, OPAC 100%)
  * French (99%, OPAC 100%)
  * Portuguese (Brazil) (90%, OPAC 100%)
  * Spanish (87%, OPAC 100%)
  * English -nz- (78%, OPAC 100%)
  * Arabic (76%, OPAC 100%)
  * Danish (75%, OPAC 100%)
  * Greek (69%, OPAC 100%)
  * French -canada- (68%, OPAC 70%)
  * Armenian (68%, OPAC 100%)
  * Norwegian (67%, OPAC 100%)

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.8 is

  Release Manager:       Paul Poulain <paul.poulain at biblibre.com>
  Documentation Manager: Nicole C Engard <nengard at gmail.com>
  Translation Manager:   Fr??d??ric Demians <frederic at tamil.fr>
  QA Manager:            Ian Walls <koha.sekjal at gmail.com>
  QA team:               Marcel de Rooy <M.de.Rooy at rijksmuseum.nl>,
  Jonathan Druart <jonathan.druart at biblibre.com>
  Bug Wranglers:         Katrin Fischer, Magnus Enger

  Release Maintainer (3.4.x): Chris Nighswonger <cnighswonger at foundations.edu>
  Release Maintainer (3.6.x): Jared Camins-Esakov <jcamins at cpbibliography.com>
  Release Maintainer (3.8.x): Chris Cormack <chrisc at catalyst.net.nz>


Credits
======================

We thank the following individuals who contributed patches to
Koha 3.8.2.

     1	D Ruth Bavousett
     1	Jared Camins-Esakov
     4	Colin Campbell
    20	Chris Cormack
     4	Christophe Croullebois
     1	St??phane Delaune
     4	Fr??d??ric Demians
     4	Jonathan Druart
     3	Katrin Fischer
     2	Amit Gupta
    10	Kyle M Hall
     2	Mason James
     2	Srdjan Jankovic
     1	Piotr Kowalski
    12	Owen Leonard
     2	Julian Maurice
     1	Matthias Meusburger
     3	Sophie Meynieux
     7	Dobrica Pavlinusic
     6	Paul Poulain
     1	Liz Rea
     3	Marcel de Rooy
     1	Fridolyn SOMERS
     1	Adrien Saurat
     2	Robin Sheat
     1	Simon Story
     1	Marc Veron
     1	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.8.x (i.e., this version of Koha and future bugfix
releases) is 3.8.x.

The next major feature release of Koha will be Koha 3.10.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

From chrisc at catalyst.net.nz  Fri Jun 22 00:11:43 2012
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Fri, 22 Jun 2012 10:11:43 +1200
Subject: [Koha-devel] [Koha] Koha 3.8.2 Released
In-Reply-To: <CA+95qVQW5H=nH8L5seoWfFPM5R+re9NPVazGYUPP1mpNtAviKg@mail.gmail.com>
References: <CA+95qVQW5H=nH8L5seoWfFPM5R+re9NPVazGYUPP1mpNtAviKg@mail.gmail.com>
Message-ID: <20120621221143.GZ20097@rorohiko.wgtn.cat-it.co.nz>

>      1	St??phane Delaune
>      4	Fr??d??ric Demians

That should be

1   St?phane Delaune
4   Fr?d?ric Demians

Chris

-- 
Chris Cormack
Catalyst IT Ltd.
+64 4 803 2238
PO Box 11-053, Manners St, Wellington 6142, New Zealand

From bargioni at pusc.it  Fri Jun 22 16:11:15 2012
From: bargioni at pusc.it (Stefano Bargioni)
Date: Fri, 22 Jun 2012 16:11:15 +0200
Subject: [Koha-devel] Model for wiki JQuery_Library
Message-ID: <F8F78749-B241-406F-B34D-D1B76E8BFAFA@pusc.it>

In http://wiki.koha-community.org/wiki/JQuery_Library#JQuery_Title
the proposed model for contributed scripts is

Developer: Name of JQuery developer
Purpose: Purpose of the JQuery
Status: Completed / In progress
Intranet or OPAC?:
Version: (The version you are using this with, or Any, if applicable)

I'd like to suggest some modifications:

Developer: Name of JQuery developer
Creation Date: the date you entered the script (YYYY-MM-DD)
Purpose: Purpose of the JQuery script
Status: Completed / In progress
Intranet or OPAC?:
Version: (The Koha version you are using this with, or Any, if applicable)

Thanks. Stefano

__________________________________________________
Il tuo 5x1000 al Patronato di San Girolamo della Carita' e' un gesto semplice ma di grande valore.
Una tua firma aiutera' i sacerdoti ad essere piu' vicini alle esigenze di tutti noi.
Aiutaci a formare sacerdoti e seminaristi provenienti dai 5 continenti indicando nella dichiarazione dei redditi il codice fiscale 97023980580.


From mjr at phonecoop.coop  Fri Jun 22 17:39:19 2012
From: mjr at phonecoop.coop (MJ Ray)
Date: Fri, 22 Jun 2012 16:39:19 +0100
Subject: [Koha-devel] Model for wiki JQuery_Library
In-Reply-To: <F8F78749-B241-406F-B34D-D1B76E8BFAFA@pusc.it>
Message-ID: <E1Si5x9-00011V-8n@petrol.towers.org.uk>

Stefano Bargioni <bargioni at pusc.it>
> In http://wiki.koha-community.org/wiki/JQuery_Library#JQuery_Title
> the proposed model for contributed scripts is [...]
> I'd like to suggest some modifications: [...]

Looks fine to me.  I'll go post them.  In future, please edit the page
(or bug someone on #koha to edit it for you if you've been hurt by
the registration email bug) and anyone interested in the topic should
get told because they've clicked "Watch" on the page.

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 nguyenquocuy_1102 at yahoo.com  Fri Jun 22 23:40:34 2012
From: nguyenquocuy_1102 at yahoo.com (Uy)
Date: Sat, 23 Jun 2012 01:40:34 +0400
Subject: [Koha-devel] Social library
Message-ID: <EC0C8C91-0DC5-484E-A4E3-5971A798DFD9@yahoo.com>

 Hi everyone!
I have worked with Koha for 4 month. I am not a programer, i just know php mysql and html. Love koha and i want to share some ideas with you guys. Hope that some developer get the same ideas and will make it come true.
   We know now facebook is really famous, and how do you think about the social library? I think, if we have a social library, the patrons will be interested more and more with our library. Let me give you example in my opinion: A patron join into OPAC site, and they will see that in 5 days from his last checkout, how many his friends came to library, what kinds of books they borrowed? It looks like a small wall on facebook. Now i can see that the OPAC when an user login in KOHA is quite sad, i mean there is a very little thing, which can make them stay on our library'site longer! 
   I know that we are working with a library managment system, i can't dream more and more, but i think our student really love it. Thanks for reading, and i love to receive your reply.

Kindest Regards!
Nguyen Quoc Uy

From 5p4m at gmx.de  Sat Jun 23 00:10:52 2012
From: 5p4m at gmx.de (Mirko)
Date: Sat, 23 Jun 2012 00:10:52 +0200
Subject: [Koha-devel] Social library
In-Reply-To: <EC0C8C91-0DC5-484E-A4E3-5971A798DFD9@yahoo.com>
References: <EC0C8C91-0DC5-484E-A4E3-5971A798DFD9@yahoo.com>
Message-ID: <4FE4ED6C.5050201@gmx.de>

Hello!

Just a little showstopper: at least where I live it is not allowed
to gather and share this kind of information about patrons. We are
not allowed to log the borrowing history of our patrons due to data
protection laws.

I don't mean to keep you from dreaming and sharing your ideas
thought. Feel free to elaborate on this or other ideas you might have.

- Mirko



schrieb Uy am 22.06.2012 23:40:
> Hi everyone! I have worked with Koha for 4 month. I am not a
> programer, i just know php mysql and html. Love koha and i want
> to share some ideas with you guys. Hope that some developer get
> the same ideas and will make it come true. We know now facebook
> is really famous, and how do you think about the social library?
> I think, if we have a social library, the patrons will be
> interested more and more with our library. Let me give you
> example in my opinion: A patron join into OPAC site, and they
> will see that in 5 days from his last checkout, how many his
> friends came to library, what kinds of books they borrowed? It
> looks like a small wall on facebook. Now i can see that the OPAC
> when an user login in KOHA is quite sad, i mean there is a very
> little thing, which can make them stay on our library'site
> longer! I know that we are working with a library managment
> system, i can't dream more and more, but i think our student
> really love it. Thanks for reading, and i love to receive your
> reply.
> 
> Kindest Regards! Nguyen Quoc Uy 
> _______________________________________________ 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 abesottedphoenix at yahoo.com  Sat Jun 23 04:50:44 2012
From: abesottedphoenix at yahoo.com (BWS Johnson)
Date: Fri, 22 Jun 2012 19:50:44 -0700 (PDT)
Subject: [Koha-devel] Social library
In-Reply-To: <4FE4ED6C.5050201@gmx.de>
References: <EC0C8C91-0DC5-484E-A4E3-5971A798DFD9@yahoo.com>
	<4FE4ED6C.5050201@gmx.de>
Message-ID: <1340419844.9414.YahooMailNeo@web140804.mail.bf1.yahoo.com>

Salvete!

??? Two things. The first is that Paul is not only French, but also quite modest. So, he will probably not tell you that he was working on making Koha and SOPAC work together (at least a few years back.) This *might* satisfy your needs (or you might think it's lipstick on the pig.)

http://thesocialopac.net/

??? The second thing. *begins the not a lawyer dance* I am not a lawyer, so this should not be considered legal advice, BUT, I should think that this could be worked around with a multi lock [as in canal] system should folks feel like working on it. The first lock would be ensuring that it was a system preference that a Library could toggle on or off. That should keep you out of sweeping legal trouble in the case that your country or locality forbids collection of data. The second lock of sorts would be that individual Patrons could choose to opt in should they feel like doing so. In theory, this might be layered. That way, I could share the information with my friends, but in the event that the Library as a whole had summat like a large screen at the Library, I might be able to opt out of just that feature.
???? I would think that anonymised data in the US would be fine if kept as a general statistic anyway, specifically reader's advisory suggestions. (As in did you like X? then try Y.)

??? Please keep the new ideas coming, that's how we get better :D


Cheers,
Brooke



----- Original Message -----
> From: Mirko <5p4m at gmx.de>
> To: "Koha-devel at lists.koha-community.org" <Koha-devel at lists.koha-community.org>
> Cc: 
> Sent: Friday, June 22, 2012 6:10 PM
> Subject: Re: [Koha-devel] Social library
> 
> Hello!
> 
> Just a little showstopper: at least where I live it is not allowed
> to gather and share this kind of information about patrons. We are
> not allowed to log the borrowing history of our patrons due to data
> protection laws.
> 
> I don't mean to keep you from dreaming and sharing your ideas
> thought. Feel free to elaborate on this or other ideas you might have.
> 
> - Mirko
> 
> 
> 
> schrieb Uy am 22.06.2012 23:40:
>>  Hi everyone! I have worked with Koha for 4 month. I am not a
>>  programer, i just know php mysql and html. Love koha and i want
>>  to share some ideas with you guys. Hope that some developer get
>>  the same ideas and will make it come true. We know now facebook
>>  is really famous, and how do you think about the social library?
>>  I think, if we have a social library, the patrons will be
>>  interested more and more with our library. Let me give you
>>  example in my opinion: A patron join into OPAC site, and they
>>  will see that in 5 days from his last checkout, how many his
>>  friends came to library, what kinds of books they borrowed? It
>>  looks like a small wall on facebook. Now i can see that the OPAC
>>  when an user login in KOHA is quite sad, i mean there is a very
>>  little thing, which can make them stay on our library'site
>>  longer! I know that we are working with a library managment
>>  system, i can't dream more and more, but i think our student
>>  really love it. Thanks for reading, and i love to receive your
>>  reply.
>> 
>>  Kindest Regards! Nguyen Quoc Uy 
>>  _______________________________________________ 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/
> 

From nguyenquocuy_1102 at yahoo.com  Sat Jun 23 12:46:36 2012
From: nguyenquocuy_1102 at yahoo.com (Quoc Uy)
Date: Sat, 23 Jun 2012 03:46:36 -0700 (PDT)
Subject: [Koha-devel] Social library
In-Reply-To: <mailman.5.1340445603.22863.koha-devel@lists.koha-community.org>
References: <mailman.5.1340445603.22863.koha-devel@lists.koha-community.org>
Message-ID: <1340448396.28442.YahooMailNeo@web160206.mail.bf1.yahoo.com>

??? ??? Fisrt, thanks for sharing this: http://thesocialopac.net/. It's really nice way to find some help. I agree with you about the law's problem. We can solve it with some option for user to choose like "sharing you action to your friends, not sharing...". And if u ask, where we can put this Wall on the Opac website, i think we can creat one more little menu like- "My friend's action" above the "My summary" on the menu.
??? ??? We can make a default like sharing your actions with your classmates (for shool's library or university's library). After friend's action, you can comment, like (it looks like in facebook). I think, the main idea is that, you can share your opinion about some books, recommend it to friends... We did have all databases, how can we make it comes true? I hope some programmer can do it and i think they really can.

Best regard!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120623/a319fc2c/attachment.htm>

From abesottedphoenix at yahoo.com  Sat Jun 23 14:10:01 2012
From: abesottedphoenix at yahoo.com (BWS Johnson)
Date: Sat, 23 Jun 2012 05:10:01 -0700 (PDT)
Subject: [Koha-devel] Social library
In-Reply-To: <1340448396.28442.YahooMailNeo@web160206.mail.bf1.yahoo.com>
References: <mailman.5.1340445603.22863.koha-devel@lists.koha-community.org>
	<1340448396.28442.YahooMailNeo@web160206.mail.bf1.yahoo.com>
Message-ID: <1340453401.3352.YahooMailNeo@web140803.mail.bf1.yahoo.com>

Salve!


>??? ??? Fisrt, thanks for sharing this: http://thesocialopac.net/. It's really nice way to find some help. I agree with you about the law's problem. We can solve it with some option for user to choose like "sharing you action to your friends, not sharing...". And if u ask, where we can put this Wall on the Opac website, i think we can creat one more little menu like- "My friend's action" above the "My summary" on the menu.
>??? ??? We can make a default like sharing your actions with your classmates (for shool's library or university's library). After friend's action, you can comment, like (it looks like in facebook). I think, the main idea is that, you can share your opinion about some books, recommend it to friends... We did have all databases, how can we make it comes true? I hope some programmer can do it and i think they really can.
>

??? Well hmm. Now I'm just wondering if you're viewing an older version of Koha, perhaps... Have you seen:

http://catalog.losgatosca.gov/cgi-bin/koha/opac-detail.pl?biblionumber=117395

???? Be sure and scroll down to the bottom of the page and click on all of the tabs and stuff. I'm not entirely sure that I'm fully understanding precisely what enhancements you want, but we might already be doing part of what you propose. :)

Cheers,
Brooke


From jcamins at cpbibliography.com  Sat Jun 23 23:16:34 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Sat, 23 Jun 2012 17:16:34 -0400
Subject: [Koha-devel] Regression considered harmful
Message-ID: <CALVDfQzZJcvNeACujXROLhpnEafMyoBBw_hvj_DN2K+w+0OgXA@mail.gmail.com>

Hello.

Regardless of your stance on goto statements (and I would note that they
are thankfully pretty scarce in the Koha codebase, with the exception of
sms/sms_listen.pl, which has a surprising number for a 126-line script), I
think we can all agree that regressions in Koha's functionality are a very
bad thing. Well, I have a proposal for one way we might go about cutting
down on regressions, *and* saving testers time: Test::WWW::Mechanize.

By adding tests that use Test::WWW::Mechanize, it would be possible to
include unit tests that confirm that the interface (at least the parts that
are not Javascript-dependent) continues to function as intended. I find
this an extremely promising concept, and one that I would *love* to put
into practice in my Release Maintaining of 3.6.x (whether the tests are
committed to Koha, or whether they are in a separate repository).

So, what can you do to help us reach our lofty goal of no regressions,
ever, and no simple regressions requiring people-hours to identify? Easy!
Start writing those tests! I filed a bug (
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8300) and attached
a unit test that checks the stage MARC import tool is still looking. Take a
look, and think about whether you could come up with some scripts.

Lest you think that writing this sort of unit test has to be hard, I have
good news! It's not actually all that hard. Documented on the wiki we have
instructions for setting up an http-recorder proxy to simplify your test
writing to the very basics: go through the steps with your web browser,
save the resulting file, and change get() to get_ok() and click() to
click_ok() (yes, it really can be that simple). Moreover, I have documented
the two gotchas that we have encountered with this so far on the wiki, and
I will continue to document the solutions to problems I encounter. So, what
are you waiting for? Get thee to the wiki and begin testing!
http://wiki.koha-community.org/wiki/Interface_testing_with_WWW::Mechanize

Regards,
Jared Camins-Esakov

-- 
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: </pipermail/koha-devel/attachments/20120623/c0c42eaf/attachment.htm>

From Smita.Biswas at tauranga.govt.nz  Sun Jun 24 12:20:32 2012
From: Smita.Biswas at tauranga.govt.nz (Smita Biswas)
Date: Sun, 24 Jun 2012 10:20:32 +0000
Subject: [Koha-devel] Koha-devel Digest, Vol 79, Issue 28-unsubscribe
Message-ID: <2387906A85F61047B2FC58EA5CDF3E502D4A5B@Exchange01.tauranga.govt.nz>


________________________________________
From: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] on behalf of koha-devel-request at lists.koha-community.org [koha-devel-request at lists.koha-community.org]
Sent: Sunday, June 24, 2012 10:00 PM
To: koha-devel at lists.koha-community.org
Subject: Koha-devel Digest, Vol 79, Issue 28

Send Koha-devel mailing list submissions to
        koha-devel at lists.koha-community.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
or, via email, send a message with subject or body 'help' to
        koha-devel-request at lists.koha-community.org

You can reach the person managing the list at
        koha-devel-owner at lists.koha-community.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Koha-devel digest..."


Today's Topics:

   1. Re: Social library (Quoc Uy)
   2. Re: Social library (BWS Johnson)
   3. Regression considered harmful (Jared Camins-Esakov)


----------------------------------------------------------------------

Message: 1
Date: Sat, 23 Jun 2012 03:46:36 -0700 (PDT)
From: Quoc Uy <nguyenquocuy_1102 at yahoo.com>
Subject: Re: [Koha-devel] Social library
To: "koha-devel at lists.koha-community.org"
        <koha-devel at lists.koha-community.org>,  "abesottedphoenix at yahoo.com"
        <abesottedphoenix at yahoo.com>
Message-ID:
        <1340448396.28442.YahooMailNeo at web160206.mail.bf1.yahoo.com>
Content-Type: text/plain; charset="iso-8859-1"

??? ??? Fisrt, thanks for sharing this: http://thesocialopac.net/. It's really nice way to find some help. I agree with you about the law's problem. We can solve it with some option for user to choose like "sharing you action to your friends, not sharing...". And if u ask, where we can put this Wall on the Opac website, i think we can creat one more little menu like- "My friend's action" above the "My summary" on the menu.
??? ??? We can make a default like sharing your actions with your classmates (for shool's library or university's library). After friend's action, you can comment, like (it looks like in facebook). I think, the main idea is that, you can share your opinion about some books, recommend it to friends... We did have all databases, how can we make it comes true? I hope some programmer can do it and i think they really can.

Best regard!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120623/a319fc2c/attachment.html>

------------------------------

Message: 2
Date: Sat, 23 Jun 2012 05:10:01 -0700 (PDT)
From: BWS Johnson <abesottedphoenix at yahoo.com>
Subject: Re: [Koha-devel] Social library
To: Quoc Uy <nguyenquocuy_1102 at yahoo.com>,
        "koha-devel at lists.koha-community.org"
        <koha-devel at lists.koha-community.org>
Message-ID:
        <1340453401.3352.YahooMailNeo at web140803.mail.bf1.yahoo.com>
Content-Type: text/plain; charset=iso-8859-1

Salve!


>??? ??? Fisrt, thanks for sharing this: http://thesocialopac.net/. It's really nice way to find some help. I agree with you about the law's problem. We can solve it with some option for user to choose like "sharing you action to your friends, not sharing...". And if u ask, where we can put this Wall on the Opac website, i think we can creat one more little menu like- "My friend's action" above the "My summary" on the menu.
>??? ??? We can make a default like sharing your actions with your classmates (for shool's library or university's library). After friend's action, you can comment, like (it looks like in facebook). I think, the main idea is that, you can share your opinion about some books, recommend it to friends... We did have all databases, how can we make it comes true? I hope some programmer can do it and i think they really can.
>

??? Well hmm. Now I'm just wondering if you're viewing an older version of Koha, perhaps... Have you seen:

http://catalog.losgatosca.gov/cgi-bin/koha/opac-detail.pl?biblionumber=117395

???? Be sure and scroll down to the bottom of the page and click on all of the tabs and stuff. I'm not entirely sure that I'm fully understanding precisely what enhancements you want, but we might already be doing part of what you propose. :)

Cheers,
Brooke



------------------------------

Message: 3
Date: Sat, 23 Jun 2012 17:16:34 -0400
From: Jared Camins-Esakov <jcamins at cpbibliography.com>
Subject: [Koha-devel] Regression considered harmful
To: koha-devel at lists.koha-community.org
Message-ID:
        <CALVDfQzZJcvNeACujXROLhpnEafMyoBBw_hvj_DN2K+w+0OgXA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello.

Regardless of your stance on goto statements (and I would note that they
are thankfully pretty scarce in the Koha codebase, with the exception of
sms/sms_listen.pl, which has a surprising number for a 126-line script), I
think we can all agree that regressions in Koha's functionality are a very
bad thing. Well, I have a proposal for one way we might go about cutting
down on regressions, *and* saving testers time: Test::WWW::Mechanize.

By adding tests that use Test::WWW::Mechanize, it would be possible to
include unit tests that confirm that the interface (at least the parts that
are not Javascript-dependent) continues to function as intended. I find
this an extremely promising concept, and one that I would *love* to put
into practice in my Release Maintaining of 3.6.x (whether the tests are
committed to Koha, or whether they are in a separate repository).

So, what can you do to help us reach our lofty goal of no regressions,
ever, and no simple regressions requiring people-hours to identify? Easy!
Start writing those tests! I filed a bug (
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8300) and attached
a unit test that checks the stage MARC import tool is still looking. Take a
look, and think about whether you could come up with some scripts.

Lest you think that writing this sort of unit test has to be hard, I have
good news! It's not actually all that hard. Documented on the wiki we have
instructions for setting up an http-recorder proxy to simplify your test
writing to the very basics: go through the steps with your web browser,
save the resulting file, and change get() to get_ok() and click() to
click_ok() (yes, it really can be that simple). Moreover, I have documented
the two gotchas that we have encountered with this so far on the wiki, and
I will continue to document the solutions to problems I encounter. So, what
are you waiting for? Get thee to the wiki and begin testing!
http://wiki.koha-community.org/wiki/Interface_testing_with_WWW::Mechanize

Regards,
Jared Camins-Esakov

--
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: </pipermail/koha-devel/attachments/20120623/c0c42eaf/attachment-0001.htm>

------------------------------

_______________________________________________
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/

End of Koha-devel Digest, Vol 79, Issue 28
******************************************
*****************************************************************************
The contents of this e-mail and any attachments is confidential and may
be privileged and/or subject to copyright.  Unauthorised use, distribution
or copying of the contents is expressly prohibited.  If you are not the
intended recipient, notify the sender immediately, delete the email and
attachments and all copies from your system, and do not use, read,
distribute, disclose or copy its contents.  Violation of this notice may
be unlawful.  Views expressed in this e-mail and attachments are those of
the author, and not necessarily those of Tauranga City Council.
Tauranga City Council does not accept liability for any loss, damage or
consequence arising from this email and/or attachments containing any
virus, defect, data corruption or transmission error.
*****************************************************************************

______________________________________________________________________________

This email has been scrubbed for your protection by SMX.
For more information visit http://smxemail.com
______________________________________________________________________________



From jcamins at cpbibliography.com  Sun Jun 24 23:18:47 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Sun, 24 Jun 2012 17:18:47 -0400
Subject: [Koha-devel] Koha 3.6.6 released
Message-ID: <CALVDfQyLXysOsHC5jLrAMDnfBSaSieuyEWo7TBsej2+ZYs70-g@mail.gmail.com>

The Koha community is proud to release Koha version 3.6.6. This is a
bugfix release, and contains a number of important fixes

You can obtain Koha 3.6.6 from the  http://download.koha-community.org
site. Debian packages will be available from the
http://debian.koha-community.org shortly also.

Please read the release notes below for more information

RELEASE NOTES FOR KOHA 3.6.6
24 Jun 2012
========================================================================

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.6 can be downloaded from:

    http://download.koha-community.org/koha-3.06.06.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.6 is a bugfix/maintenance release.

Highlights of 3.6.6
======================

7016 blocker CanBookBeReserved uses GetItemsInfo unnecessarily
7354 critical Can't edit local use system preferences
7528 critical amount subtracting 1 cent
7927 critical library not showing on subscription full history anymore
2012 major Add bilio crashes under no zebra
3969 major Budget Search Doesn't Work
5327 major Unit tests required for all C4 modules
6496 major authors appearing incorrectly in OPAC and Staff Client
6931 major hardcoded insert incompatible with UNIMARC


Bugs fixed in 3.6.6
======================

2399 normal All status fields in the item edit interface offer two
blank/null entries per dropdown instead of one
3337 normal RSS link is not correct
3413 normal repeatable tickbox not sticking 1st time round
7722 normal Insidious problem with searching
7820 normal Missing packages from install_misc/debian.packages
7833 normal unique holiday link broken
7845 normal Multiple 260s don't display properly in search results
7922 normal Fixing typos and improving translations in German sample data
8022 normal Permissions test doesn't check all languages
8025 normal Patron attribute not selected if value is zero
1577 enhancement installer and language
7213 enhancement Document /svc/ HTTP API and provide example command-line
client
7990 enhancement bad html attribute into aqplan.tt : styl= insted of style=


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 (China)
  * Chinese (Taiwan)
  * Danish
  * English (USA)
  * English (UK)
  * English (New Zealand)
  * French (Canada)
  * French (France)
  * German
  * Greek
  * Italian
  * Portuguese (Brazil)
  * Spanish

Partial translations are available for various other languages.

The Koha team welcomes additional translations; please see

    http://wiki.koha-community.org/wiki/Translating_Koha

for information about translating Koha, and join the koha-translate
list to volunteer:

    http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate

The most up-to-date translations can be found at:

    http://translate.koha-community.org/

Release Team
======================

The release team for Koha 3.6 is

Release Manager:        Chris Cormack <chrisc at catalyst.net.nz>
Documentation Manager:  Nicole C Engard <nengard at gmail.com>
Translation Manager:    Fr?d?ric Demians <frederic at tamil.fr>
QA Manager:             Ian Walls <ian.walls at bywatersolutions.com>
Bug Wranglers:          MJ Ray, Marcel de Rooy, Paul Poulain, Mason James

Past Release Maintainer (3.6.x):
                        Chris Nighswonger <cnighswonger at foundations.edu>
Release Maintainer (3.6.x):
                        Jared Camins-Esakov <jcamins at cpbibliography.com>




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.6.

     1 Gaetan Boisson
     3 Jared Camins-Esakov
     1 Colin Campbell
     1 Galen Charlton
     3 Chris Cormack
     1 St?phane Delaune
     1 Jonathan Druart
     1 Magnus Enger
    11 Katrin Fischer
     2 Kyle M Hall
     1 Dobrica Pavlinusic
     3 Paul Poulain
     2 MJ Ray
     1 Adrien Saurat
     2 Robin Sheat
     2 Ian Walls
     1 mveron


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.

Koha 3.8.0 was released on April 23, 2012. The next major feature release of
Koha will be Koha 3.10.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120624/17ab8461/attachment-0001.htm>

From nguyenquocuy_1102 at yahoo.com  Mon Jun 25 00:47:11 2012
From: nguyenquocuy_1102 at yahoo.com (Quoc Uy)
Date: Sun, 24 Jun 2012 15:47:11 -0700 (PDT)
Subject: [Koha-devel] Opac's interface can change with user's information?
Message-ID: <1340578031.94627.YahooMailNeo@web160205.mail.bf1.yahoo.com>

I have a problems- or maybe an idea. I have for example, 20 libraries on my host website- i mean 20 home branches libraries (Library A, B, C....). But i can change my OPAC site for only one interface. Is there some ways to change OPAC's interface associate with the user's information?

Let me tell u more about this. In our country, it's expensive and impossible to have 1 hosting for 1 library (1 school), so we want to make a hosting for 20 libraries (20 schools) with one website like http://systemlibrary.edu.com. In this Koha library, we have 20 branches libraries with 20 staffs - not superlibrarian. Is there some ways, when patron A (branch library A) login in OPAC site, he can see messages, icon, schoolA's Logo... And when patron B (branch library B) login in the OPAC site, he saw absolutely other things (schoolB's logo, icon and messages...).

Sorry for my bad english.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120624/5e777d8f/attachment.htm>

From mtj at kohaaloha.com  Mon Jun 25 12:47:05 2012
From: mtj at kohaaloha.com (Mason James)
Date: Mon, 25 Jun 2012 22:47:05 +1200
Subject: [Koha-devel] Opac's interface can change with user's
	information?
In-Reply-To: <1340578031.94627.YahooMailNeo@web160205.mail.bf1.yahoo.com>
References: <1340578031.94627.YahooMailNeo@web160205.mail.bf1.yahoo.com>
Message-ID: <97BF49FF-38BF-4E7E-891B-781D53866F5B@kohaaloha.com>


On 2012-06-25, at 10:47 AM, Quoc Uy wrote:

> I have a problems- or maybe an idea. I have for example, 20 libraries on my host website- i mean 20 home branches libraries (Library A, B, C....). But i can change my OPAC site for only one interface. Is there some ways to change OPAC's interface associate with the user's information?


hmmm, i think that's not currently possible with Koha... 

but, it's a great idea! :)


you should log this as an 'enhancement' in Koha's bugzilla -> http://bugs.koha-community.org

-------------- 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: </pipermail/koha-devel/attachments/20120625/5b78dfc8/attachment.pgp>

From nguyenquocuy_1102 at yahoo.com  Mon Jun 25 12:56:06 2012
From: nguyenquocuy_1102 at yahoo.com (Uy)
Date: Mon, 25 Jun 2012 14:56:06 +0400
Subject: [Koha-devel] Opac's interface can change with user's
	information?
In-Reply-To: <97BF49FF-38BF-4E7E-891B-781D53866F5B@kohaaloha.com>
References: <1340578031.94627.YahooMailNeo@web160205.mail.bf1.yahoo.com>
	<97BF49FF-38BF-4E7E-891B-781D53866F5B@kohaaloha.com>
Message-ID: <DAA6810F-0C5B-4259-97C2-A865D6A3A118@yahoo.com>

Thanks. I think we can create first a system opac's interface (When user did login in)
Then we have a staff's permission, allow them to change their branch's Opac interface.

Current koha has the same Opac's interface (i mean the header, the bottom...) when patrons access website and when they logged in. Hope our developers can do it!
Kindest Regards!
Nguyen Quoc Uy

On 25-06-2012, at 14:47, Mason James <mtj at kohaaloha.com> wrote:

> 
> On 2012-06-25, at 10:47 AM, Quoc Uy wrote:
> 
>> I have a problems- or maybe an idea. I have for example, 20 libraries on my host website- i mean 20 home branches libraries (Library A, B, C....). But i can change my OPAC site for only one interface. Is there some ways to change OPAC's interface associate with the user's information?
> 
> 
> hmmm, i think that's not currently possible with Koha... 
> 
> but, it's a great idea! :)
> 
> 
> you should log this as an 'enhancement' in Koha's bugzilla -> http://bugs.koha-community.org
> 

From tajoli at cilea.it  Mon Jun 25 13:00:34 2012
From: tajoli at cilea.it (Zeno Tajoli)
Date: Mon, 25 Jun 2012 13:00:34 +0200
Subject: [Koha-devel] Opac's interface can change with user's
	information?
In-Reply-To: <1340578031.94627.YahooMailNeo@web160205.mail.bf1.yahoo.com>
References: <1340578031.94627.YahooMailNeo@web160205.mail.bf1.yahoo.com>
Message-ID: <4FE844D2.9000501@cilea.it>

Hi Quoc Uy,

Il 25/06/2012 00:47, Quoc Uy ha scritto:
> I have a problems- or maybe an idea. I have for example, 20 libraries on
> my host website- i mean 20 home branches libraries (Library A, B,
> C....). But i can change my OPAC site for only one interface. Is there
> some ways to change OPAC's interface associate with the user's information?
> 
> Let me tell u more about this. In our country, it's expensive and
> impossible to have 1 hosting for 1 library (1 school), so we want to
> make a hosting for 20 libraries (20 schools) with one website like
> http://systemlibrary.edu.com. In this Koha library, we have 20 branches
> libraries with 20 staffs - not superlibrarian. Is there some ways, when
> patron A (branch library A) login in OPAC site, he can see messages,
> icon, schoolA's Logo... And when patron B (branch library B) login in
> the OPAC site, he saw absolutely other things (schoolB's logo, icon and
> messages...).

the easy solution to this problem is to install 20 time Koha on your
server, (so 20 MysQL d, 20 different user at command line, etc.).
Is it possibile to do this with one Koha db ?
Out of the box, no.

But if:
-- you set up a 21 site and force here the login for all
-- you are skilled on apache setup (the main work)
-- you setup IndependetBranches
-- you can do change on templese and perl scripts
-- same tuning on Zebra

probalbly you can optain this result with one Koha db.

You can also ask about this type of develop to a Koha vendor.
The list his here:
http://koha-community.org/support/paid-support/

Bye
Zeno Tajoli
-- 
Dott. Zeno Tajoli
tajoliAT_SPAM_no_prendiATcilea.it
fax +39 02 2135520
CILEA - Consorzio Interuniversitario
http://www.cilea.it/disclaimer

From paul.poulain at biblibre.com  Mon Jun 25 13:22:54 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Mon, 25 Jun 2012 13:22:54 +0200
Subject: [Koha-devel] Opac's interface can change with user's
	information?
In-Reply-To: <DAA6810F-0C5B-4259-97C2-A865D6A3A118@yahoo.com>
References: <1340578031.94627.YahooMailNeo@web160205.mail.bf1.yahoo.com>
	<97BF49FF-38BF-4E7E-891B-781D53866F5B@kohaaloha.com>
	<DAA6810F-0C5B-4259-97C2-A865D6A3A118@yahoo.com>
Message-ID: <4FE84A0E.8040809@biblibre.com>

Le 25/06/2012 12:56, Uy a ?crit :
> Thanks. I think we can create first a system opac's interface (When user did login in)
> Then we have a staff's permission, allow them to change their branch's Opac interface.
The way it could (should?) be made, imo is by adding a mechanism of
syspref at branchlevel-level

How I see it :
systempreferences would have a branchcode column
When calling C4::Context->preference('mysyspref'), if there is a syspref
for branchcode = loggedinbranchcode => use it, otherwise, use the common
syspref.

At OPAC, this could be achieved through branchcode of logged user or/and
through a Apache level ENV variable (thus, you would have 20 apache OPAC)

I think there is bugzilla entry for this, but not sure

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08



From robin at catalyst.net.nz  Mon Jun 25 13:32:13 2012
From: robin at catalyst.net.nz (Robin Sheat)
Date: Mon, 25 Jun 2012 12:32:13 +0100
Subject: [Koha-devel] Opac's interface can change with user's
	information?
In-Reply-To: <4FE844D2.9000501@cilea.it>
References: <1340578031.94627.YahooMailNeo@web160205.mail.bf1.yahoo.com>
	<4FE844D2.9000501@cilea.it>
Message-ID: <4FE84C3D.9090402@catalyst.net.nz>

Op 25-06-12 12:00, Zeno Tajoli schreef:
> the easy solution to this problem is to install 20 time Koha on your
> server, (so 20 MysQL d, 20 different user at command line, etc.).
> Is it possibile to do this with one Koha db ?
> Out of the box, no.

It's quite possible to do this out of the box. Use the packages, and use
koha-create to create the libraries you want. However, this isn't so
great if you want to make it easy to share information between them.

Whether this is the right solution depends on your use cases though.

-- 
Robin Sheat
Catalyst IT Ltd.
? +64 4 803 2204
GPG: 5957 6D23 8B16 EFAB FEF8  7175 14D3 6485 A99C EB6D

From paul.poulain at biblibre.com  Mon Jun 25 15:17:43 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Mon, 25 Jun 2012 15:17:43 +0200
Subject: [Koha-devel] http://wiki.koha-community.org/wiki/Koha_Namespace_RFC,
	moving ahead
Message-ID: <4FE864F7.3090007@biblibre.com>

Hello koha-devel,

After our discussions during the hackfest, a wiki page has been written.
Now, it's time for the first patches, to see how it could look like.
I made some work on bug 8309.
That's not a request for signoff, but to look at the code, comment,
discuss, ...

Note: if you want to play with those patches, look in
admin/categories.pl and testrelations.pl. You'll have to install Moose
and DBIx::Class, (available on probably all linux distros)
-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08


From mdhafen at tech.washk12.org  Mon Jun 25 19:18:23 2012
From: mdhafen at tech.washk12.org (Mike Hafen)
Date: Mon, 25 Jun 2012 11:18:23 -0600
Subject: [Koha-devel] Opac's interface can change with user's
	information?
In-Reply-To: <CA+FBf-G+ucehzxaa==UNS-mdRcUGeBJk9risP7WM+fBzMCaA=Q@mail.gmail.com>
References: <1340578031.94627.YahooMailNeo@web160205.mail.bf1.yahoo.com>
	<4FE844D2.9000501@cilea.it> <4FE84C3D.9090402@catalyst.net.nz>
	<CA+FBf-G+ucehzxaa==UNS-mdRcUGeBJk9risP7WM+fBzMCaA=Q@mail.gmail.com>
Message-ID: <CA+FBf-HsKhhJoh=JgTFcNN1C3NNRE89p16Thb2Vqz2sHxSTZgA@mail.gmail.com>

We can do something similar in Koha currently, which is to have a custom
css and search limit in an apache virtual host for each library.  I see in
etc/koha-httpd.conf these lines in the opac virtualhost:

 #  Repeat this virtualhost stanza changing the following environment vars
to
#  create multiple OPAC interfaces with custom css and/or search limits:
#  SetEnv OPAC_CSS_OVERRIDE mystyle.css
#  SetEnv OPAC_SEARCH_LIMIT branch:CODE
#  SetEnv OPAC_LIMIT_OVERRIDE 1

The custom css could be used to set icons I believe, and could easily be
used to change the color scheme.

It doesn't change the interface according to the user, but maybe with some
javascript you can redirect a user after they have logged in to the opac
virtual host for their branch.


On Mon, Jun 25, 2012 at 5:32 AM, Robin Sheat <robin at catalyst.net.nz> wrote:

> Op 25-06-12 12:00, Zeno Tajoli schreef:
> > the easy solution to this problem is to install 20 time Koha on your
> > server, (so 20 MysQL d, 20 different user at command line, etc.).
> > Is it possibile to do this with one Koha db ?
> > Out of the box, no.
>
> It's quite possible to do this out of the box. Use the packages, and use
> koha-create to create the libraries you want. However, this isn't so
> great if you want to make it easy to share information between them.
>
> Whether this is the right solution depends on your use cases though.
>
> --
> Robin Sheat
> Catalyst IT Ltd.
> ? +64 4 803 2204
> GPG: 5957 6D23 8B16 EFAB FEF8  7175 14D3 6485 A99C EB6D
> _______________________________________________
> 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: </pipermail/koha-devel/attachments/20120625/6e51e0e3/attachment.htm>

From nguyenquocuy_1102 at yahoo.com  Mon Jun 25 23:53:15 2012
From: nguyenquocuy_1102 at yahoo.com (Quoc Uy)
Date: Mon, 25 Jun 2012 14:53:15 -0700 (PDT)
Subject: [Koha-devel] Social library
In-Reply-To: <1340658919.41535.YahooMailNeo@web140801.mail.bf1.yahoo.com>
References: <mailman.5.1340445603.22863.koha-devel@lists.koha-community.org>
	<1340448396.28442.YahooMailNeo@web160206.mail.bf1.yahoo.com>
	<1340453401.3352.YahooMailNeo@web140803.mail.bf1.yahoo.com>
	<1340455441.49785.YahooMailNeo@web160206.mail.bf1.yahoo.com>
	<1340460932.46669.YahooMailNeo@web140806.mail.bf1.yahoo.com>
	<3C87AE40-6411-464C-94E6-9E965CF4008A@yahoo.com>
	<1340658919.41535.YahooMailNeo@web140801.mail.bf1.yahoo.com>
Message-ID: <1340661195.9088.YahooMailNeo@web160201.mail.bf1.yahoo.com>

??? Thanks. It's very hard to find some volunteer to help, but i think i can call someone working with me working together. I just try to tell everyone what i really want and hope. Maybe i need time to make it come true, but i think, who love Koha must answer a question: What should we do with Koha, to make our patrons stay longer and longer in our website (it means that our website is not only the place for search some books, which is easier with google, but also the place for them to talk more and more about their favorite books, share them with friends). Of course they can do with sharing on facebook, on twitter, but it's really perfect if it shares automatically with Koha.

??? When i was young, i stayed in a library, looked at a nice girl, wondered what kind of book she was reading. Now with Koha, if i know her, it's perfect when i can see what kind of books my friends are reading, how do they think about it?... right?
??? I know, maybe some people thought about this before but it's quite difficult. Hope that if anyone want to make it, i can help about expanding some ideas, collect some experiences. Thanks all!



________________________________
 From: BWS Johnson <abesottedphoenix at yahoo.com>
To: Quocuy <nguyenquocuy_1102 at yahoo.com> 
Sent: Tuesday, June 26, 2012 1:15 AM
Subject: Re: Social library
 
Salve!


> Ok! I will wait for u. If u have time, we gonna talk about it more and more 
> then.

??? I'm back now.

??? I think the overarching thing that I have to say is that it sounds like part of what you want is already done, and the parts that aren't yet done sound like logical extensions. Stephen Johnson talks about the notion of the adjacent possible in innovation, and what you seem to be talking about all seems to fall in that realm. To me, it would boil down to a few different options if you discover that precisely what you want doesn't exist yet. You could pay for support so that a developer that does know Koha can just code what you want. You could find a volunteer somewhere that knows how to code, but doesn't necessarily know Koha. The last option is to learn everything yourself and then just do it. Whatever happens, if you ensure that you upstream what you change, it would be great. 

???? I will say that your attitude helps a whole lot. You sound very positive to me. As long as you're very patient, people might get around to implementing different ideas, but the free route tends to take a very long time. There's an olde sign here that reads

Fast
Cheap
Good

You can have any 2.

??? It's very true for Koha. :) Half the battle is trying to chunk things out to allow for easy consumption and describing precisely what you want the best that you can so that a developer can get a bead on what exactly you need. If you do a good job with the division of tasks, then it's easy for people to pick up a little scrap as in quilting and stitch things together.

Cheers,
Brooke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120625/89907a8a/attachment-0001.htm>

From danielg.koha at gmail.com  Tue Jun 26 00:10:47 2012
From: danielg.koha at gmail.com (Daniel Grobani)
Date: Mon, 25 Jun 2012 15:10:47 -0700
Subject: [Koha-devel] Official Koha Newsletter: Volume 3, Issue 6: June 2012
Message-ID: <CAOeKewiOqmEFnZX3eVo7gF-EL1zQ_aWafOn2ADExecT3RJ-iTQ@mail.gmail.com>

Official Koha Newsletter: Volume 3, Issue 6: June 2012

[Below is the text of the newsletter. For active links and a more
readable format, please visit
http://koha-community.org/koha-newsletter-volume-3-issue-6-june-2012]

Official Koha Newsletter (ISSN 2153-8328)
Volume 3, Issue 6: June 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.8.2 Released
        Koha 3.6.5 Released
        Koha 3.6.6 Released
        Koha Statistics
        Release Manager?s Newsletter
        MARC Records in PostgreSQL
        Adding VIAF Autosuggest for New NAME Authorities
    Koha Community
        New Koha Libraries
        Community Gossip
        Koha-Kobli News
    Past Koha Events
        June General IRC Meeting
        KohaCon12
    Upcoming Koha Events
        July General IRC Meeting
        KohaCon13

Koha Development

Koha 3.8.2 Released
by Chris Cormack

The Koha community is proud to release Koha version 3.8.2.

This is a bugfix release, and contains a large number of fixes.

You can obtain Koha 3.8.2 here.

Release notes are here.

Koha 3.6.5 Released
by Jared Camins-Esakov

The Koha release team is happy to announce the release of Koha 3.6.5.

This is a stable release and contains bugfixes as well as updated translations.

You can download Koha 3.6.5 here.

Release notes are here.

Koha 3.6.6 Released
by Jared Camins-Esakov

The Koha release team is happy to announce the release of Koha 3.6.6.

This is a stable release and contains bugfixes as well as updated translations.

You can download Koha 3.6.6 here.

Release notes are here.

Koha Statistics

Chris Cormack, unofficial Koha Community Statistics Wizard, has posted
statistics for Koha 3.6.5, May bugs & enhancements, Koha 3.8.2, and
Koha 3.6.6.

Release Manager Newsletter

Paul Poulain, Koha 3.8 Release Manager, is publishing a monthly
newsletter dedicated to Koha 3.8 development. It can be found on the
Koha Community website in the Koha News category.

The latest issue is here.

Experimental Support for MARC Records as a Proper Datatype in the
PostgreSQL Database
by Marc Balmer

Sitting in one of the nice pubs in Edinburgh during KohaCon, I had
this idea to add MARC records as a proper datatype to the PostgreSQL
database server. After a discussion with Marc V?ron and Dobrica
Pavlinusic about what that could mean, I decided to just try it and I
have now a basic implementation (or, more a proof of concept). Here is
some information on this:

If MARC records are a proper datatype, that means they are stored
right in the database, are backed-up, can be restored, replicated,
etc., just with the standard database tools. If a function is provided
to access individual fields of a MARC record, then this can be used in
SQL expressions, e.g. for selects or to create views, etc. As
PostgreSQL supports functional indexes, you can create indexes on
individual MARC fields, giving you super fast access to your data.

How does it look?

There is a datatype called ?marc? for now:

CREATE TABLE books ( id serial, sig varchar(16), marc_record marc );

MARC records are loaded into the database as raw, binary records,
encoded in hexadecimal:

INSERT INTO books (sig, marc_record) VALUES (?a01b?, ?3030383830?..?);

To access individual MARC fields, the function ?marc_field()? was
created; it returns VARCHAR:

SELECT id, marc_field(marc_record, ?020') AS isbn FROM books WHERE sig = ?a01b?;

Of course MARC fields can be used to search data:

SELECT id, marc_field(marc_record, ?020') AS isbn FROM books WHERE
marc_field(marc_record, ?245') like ?whatever%?;

An index on a specific field can easily be created:

CREATE INDEX books_isbn_idx ON books (marc_field(marc_record, ?020'));

As syntactic sugar, the expression marc_record@?020' is equal to
marc_field(marc_record, ?020').

Marijana Glavica kindly let me use a MARC database of ~250,000 records
to make some tests, here are some real world examples:

books=# \d test_marc
Table ?public.test_marc?
Column | Type | Modifiers
???+???+???????????????????
id | integer | not null default nextval(?test_marc_id_seq?::regclass)
marc21 | marc |

books=# select count(id) from test_marc;
count
???
246727
(1 row)

How many Croatian books do they have?

books=# select count(id) from test_marc where
substring(marc_field(marc21, ?008'), 37, 3) = ?hrv?; count

??- 52582 (1 row)

Of course much more complex queries are possible with this, and using
the right indexes it is really, really fast. One query I tested went
from 8.4 seconds to 0.21 ms with the right index. That?s a speedup of
40,000 times.

Thanks to Marijana, Dobrica, and Marc for feedback, interesting
discussions and ideas!

Feedback and suggestions are of course more than welcome at marc at msys.ch.

Adding VIAF Autosuggest for New NAME Authorities
by Stefano Bargioni

The Pontificia Universit? della Santa Croce has written a script to
enhance authority cataloguing using VIAF.

While adding new authorities of type *NAME, the VIAF catalog can be
browsed using its autosuggest API. The script adds a field on top of
the /cgi-bin/koha/authorities/authorities.pl page. Typing three or
more letters, a popup will be populated with the first ten names. Upon
selecting a name, information about the sources of the authority name
will be displayed, as well as the full authority record from VIAF, or
LC if available.

This is an initial version. The next version will try to copy the VIAF
authority record into Koha. Comments and help to bargioni at pusc.it will
be appreciated.
Koha Community

New Koha Libraries

    Bethlehem Public Library (via ByWater Solutions)
    Cooperative Information Network (via ByWater Solutions)
    Fresnes-en-Wo?vre (via BibLibre)
    New Zealand Education Institute Te Riu Roa Library (via Catalyst)
    New Zealand Ministry of Education Library (via Catalyst)
    Pierrefitte-sur-Aire (via BibLibre)
    San Francisco Maritime National Historical Park (via ByWater Solutions)
    Spincourt (via BibLibre)
    Universit? Rennes 2 (via BibLibre)
    Valley Automated Library Network (via ByWater Solutions)
    Vigneulles-les-Hattonchatel (via BibLibre)

Community Gossip

Silvia Giannitrapani, a student of Library and Information Studies at
London?s UCL, is researching open source library management systems
for her dissertation ?Can Koha and other open source library
management systems compete with proprietary systems?? To support her
research she is inviting Koha community members to share their views
and overall satisfaction with Koha in a brief survey. For more
information, email silviag at bu.edu.

Four French libraries are now using Koha with Solr.

Nicole Engard has created a version of Koha 3.8 release notes
addressed to users and librarians.

A discussion on the Koha-devel list addressed alternatives to having
to participate in an IRC meeting in order to vote on a question before
the community.

D Ruth Bavousett posted her thoughts on diversity in open-source communities.

Mirko Tietgen has Koha running on a Raspberry Pi, ?An ARM GNU/Linux
box for $25?. More information is here.

Heather Hernandez, Technical Services Librarian at San Francisco
Maritime National Historical Park, blogged about her experience with
setting up Koha.

An RFC on the Koha namespace has been posted to the wiki.

Gaetan Boisson reports that Biblibre recently submitted to the Drupal
community an opac module that allows Drupal to connect to Koha (or
other ILS?s). More information is here.

Koha-Kobli News
by Domingo Arroyo

The Koha-Kobli release team is happy to announce the second stable
release of Koha-Kobli 1.8, based on Koha 3.8. Kobli is a customized
version of Koha ILS developed by the Working Group of BAGEs (Spanish
General State Authority Libraries). Kobli 1.8 is released in two
versions: one for normal installation, and one as a VMware virtual
appliance.

Koha-Kobli?s 1.8 download is here. More information is here.

Recent implementations of Koha-Kobli include the Spanish Ministry of
the Presidency Library and the Library of the Center for Analysis and
Forescasting of the Spanish Civil Guard. More information is here and
here.
Past Koha Events

June General IRC Meeting

The June general IRC meeting was held on 13 June 2012.

More information, including the agenda and links to the minutes, is here.

KohaCon12

KohaCon12 has come and gone! David Nind (with others) has done an
excellent job of updating the conference?s schedule page with lots of
links to blog posts, photos, slides, and more. The Hackfest page has
also been updated with links to some slides, posts, and tools.
Upcoming Koha Events

July General IRC Meeting

Details on the July general IRC meeting are not yet available as we go to press.

KohaCon13

The deadline for posting bids to host KohaCon2013 is almost here. See
the conference?s wiki page for the current bids or to add yours.

From nguyenquocuy_1102 at yahoo.com  Tue Jun 26 10:30:18 2012
From: nguyenquocuy_1102 at yahoo.com (Uy)
Date: Tue, 26 Jun 2012 12:30:18 +0400
Subject: [Koha-devel] Koha on Ubuntu server
In-Reply-To: <mailman.82.1340699225.11177.koha@lists.katipo.co.nz>
References: <mailman.82.1340699225.11177.koha@lists.katipo.co.nz>
Message-ID: <1C9E5DAF-9E9F-4D7D-AB9E-AC6AB64BF070@yahoo.com>


> 
> I am trying install Koha on ubuntu server. I did install koha 3.8.1 in ubuntu server and desktop. It all works. I can add record with a Marc framework. I added patrons... I can check out, check in... All functions work like magic, but only the " Search the catalog" doesn't work :(. Is there anyone are using Koha on Ubuntu server with all work out ok? I follow all steps on http://wiki.koha-community.org/wiki/Koha_on_Ubuntu especially these steps settup zebra index and zebra server. I saw all works well, but nothing i can search! Anyone help? I'm newbie!
> 
> Kindest Regards!
> Nguyen Quoc Uy

From gonzalez at famaf.unc.edu.ar  Tue Jun 26 12:37:45 2012
From: gonzalez at famaf.unc.edu.ar (Bernardo Gonzalez Kriegel)
Date: Tue, 26 Jun 2012 07:37:45 -0300
Subject: [Koha-devel] Koha on Ubuntu server
In-Reply-To: <1C9E5DAF-9E9F-4D7D-AB9E-AC6AB64BF070@yahoo.com>
References: <mailman.82.1340699225.11177.koha@lists.katipo.co.nz>
	<1C9E5DAF-9E9F-4D7D-AB9E-AC6AB64BF070@yahoo.com>
Message-ID: <CADF4kvR-vbY8x01wR_AcQ9O26xP0CjkWcVx30dgpd_j4KXLheA@mail.gmail.com>

On Tue, Jun 26, 2012 at 5:30 AM, Uy <nguyenquocuy_1102 at yahoo.com> wrote:

>
> org/wiki/Koha_on_Ubuntu<http://wiki.koha-community.org/wiki/Koha_on_Ubuntu>especially these steps settup zebra index and zebra server. I saw all works
> well, but nothing i can search!


How do you see that all works well?

Is the zebra server running? (ps wuax | grep zebra)
Are there any errors reported by zebra? ( look at
/var/log/koha/koha-zebradaemon.err)
Have you done correctly the index?
(misc/migration_tools/rebuild_zebra.pl-r -a -b -v )

On the other hand I believe  that these messages should be sent to the koha
list, no koha-devel.

Sincerely

Bernardo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120626/c081e8a9/attachment.htm>

From fridolyn.somers at gmail.com  Tue Jun 26 17:40:18 2012
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Tue, 26 Jun 2012 17:40:18 +0200
Subject: [Koha-devel] Koha on Ubuntu server
In-Reply-To: <CADF4kvR-vbY8x01wR_AcQ9O26xP0CjkWcVx30dgpd_j4KXLheA@mail.gmail.com>
References: <mailman.82.1340699225.11177.koha@lists.katipo.co.nz>
	<1C9E5DAF-9E9F-4D7D-AB9E-AC6AB64BF070@yahoo.com>
	<CADF4kvR-vbY8x01wR_AcQ9O26xP0CjkWcVx30dgpd_j4KXLheA@mail.gmail.com>
Message-ID: <CAN6cLAUB6+Z2-40VHh8ZvAWB7rdZq1MZjHwKF6rfj1utbN6xyg@mail.gmail.com>

Hie,

Check search on both intranet and OPAC please.

Welcom on board.
(+ like Ubuntu)

On Tue, Jun 26, 2012 at 12:37 PM, Bernardo Gonzalez Kriegel <
gonzalez at famaf.unc.edu.ar> wrote:

> On Tue, Jun 26, 2012 at 5:30 AM, Uy <nguyenquocuy_1102 at yahoo.com> wrote:
>
>>
>> org/wiki/Koha_on_Ubuntu<http://wiki.koha-community.org/wiki/Koha_on_Ubuntu>especially these steps settup zebra index and zebra server. I saw all works
>> well, but nothing i can search!
>
>
> How do you see that all works well?
>
> Is the zebra server running? (ps wuax | grep zebra)
> Are there any errors reported by zebra? ( look at
> /var/log/koha/koha-zebradaemon.err)
> Have you done correctly the index? (misc/migration_tools/rebuild_zebra.pl-r -a -b -v )
>
> On the other hand I believe  that these messages should be sent to the
> koha list, no koha-devel.
>
> Sincerely
>
> Bernardo
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



-- 
Fridolyn SOMERS
fridolyn.somers at gmail.com
Marsillargues - France
<fridolyn.somers at gmail.com>
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20120626/d5c4f03a/attachment.htm>

From fridolyn.somers at gmail.com  Wed Jun 27 10:54:07 2012
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Wed, 27 Jun 2012 10:54:07 +0200
Subject: [Koha-devel] Modern Perl blog article
Message-ID: <CAN6cLAU61+D9OZa5L2tjES5XhgSaW5td0HKfg3R29StFh85xFg@mail.gmail.com>

Here is an interesting short article on "modern Perl" :
http://www.josetteorama.com/perl/what-is-modern-perl/

It may give some ideas.

-- 
Fridolyn SOMERS
fridolyn.somers at gmail.com
Marsillargues - France
<fridolyn.somers at gmail.com>
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20120627/7bceaaf0/attachment.htm>

From paul.poulain at biblibre.com  Wed Jun 27 12:25:40 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 27 Jun 2012 12:25:40 +0200
Subject: [Koha-devel] Modern Perl blog article
In-Reply-To: <CAN6cLAU61+D9OZa5L2tjES5XhgSaW5td0HKfg3R29StFh85xFg@mail.gmail.com>
References: <CAN6cLAU61+D9OZa5L2tjES5XhgSaW5td0HKfg3R29StFh85xFg@mail.gmail.com>
Message-ID: <4FEADFA4.7050204@biblibre.com>

Le 27/06/2012 10:54, Fridolyn SOMERS a ?crit :

Just FYI = Fridolyn will soon (july 10th) have a @biblibre.com email, as
we hire him

(he left progilone something like 1 year ago, and misses Koha so much
that we had to fix this ;-) )

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08



From gaetan.boisson at biblibre.com  Wed Jun 27 12:53:13 2012
From: gaetan.boisson at biblibre.com (Gaetan Boisson)
Date: Wed, 27 Jun 2012 12:53:13 +0200
Subject: [Koha-devel] Official Koha Newsletter: Volume 3,
 Issue 6: June 2012
In-Reply-To: <CAOeKewiOqmEFnZX3eVo7gF-EL1zQ_aWafOn2ADExecT3RJ-iTQ@mail.gmail.com>
References: <CAOeKewiOqmEFnZX3eVo7gF-EL1zQ_aWafOn2ADExecT3RJ-iTQ@mail.gmail.com>
Message-ID: <1340794393.2529.14.camel@Asmara>

Just a small erratum, if i may ;)

There are not 4 but 6 libraries in France using Koha with Solr. (The
earliest adopter being the municipal library of Limoges, online since
may 2011!)

Curious people can have a look at the Solr version BibLibre developed on
our public git repository:
http://git.biblibre.com/?p=koha;a=shortlog;h=refs/heads/dev/solr

Or check out how the integration to the community is going on there:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8233



Le lundi 25 juin 2012 ? 15:10 -0700, Daniel Grobani a ?crit :
> Official Koha Newsletter: Volume 3, Issue 6: June 2012
> 
> [Below is the text of the newsletter. For active links and a more
> readable format, please visit
> http://koha-community.org/koha-newsletter-volume-3-issue-6-june-2012]
> 
> Official Koha Newsletter (ISSN 2153-8328)
> Volume 3, Issue 6: June 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.8.2 Released
>         Koha 3.6.5 Released
>         Koha 3.6.6 Released
>         Koha Statistics
>         Release Manager?s Newsletter
>         MARC Records in PostgreSQL
>         Adding VIAF Autosuggest for New NAME Authorities
>     Koha Community
>         New Koha Libraries
>         Community Gossip
>         Koha-Kobli News
>     Past Koha Events
>         June General IRC Meeting
>         KohaCon12
>     Upcoming Koha Events
>         July General IRC Meeting
>         KohaCon13
> 
> Koha Development
> 
> Koha 3.8.2 Released
> by Chris Cormack
> 
> The Koha community is proud to release Koha version 3.8.2.
> 
> This is a bugfix release, and contains a large number of fixes.
> 
> You can obtain Koha 3.8.2 here.
> 
> Release notes are here.
> 
> Koha 3.6.5 Released
> by Jared Camins-Esakov
> 
> The Koha release team is happy to announce the release of Koha 3.6.5.
> 
> This is a stable release and contains bugfixes as well as updated translations.
> 
> You can download Koha 3.6.5 here.
> 
> Release notes are here.
> 
> Koha 3.6.6 Released
> by Jared Camins-Esakov
> 
> The Koha release team is happy to announce the release of Koha 3.6.6.
> 
> This is a stable release and contains bugfixes as well as updated translations.
> 
> You can download Koha 3.6.6 here.
> 
> Release notes are here.
> 
> Koha Statistics
> 
> Chris Cormack, unofficial Koha Community Statistics Wizard, has posted
> statistics for Koha 3.6.5, May bugs & enhancements, Koha 3.8.2, and
> Koha 3.6.6.
> 
> Release Manager Newsletter
> 
> Paul Poulain, Koha 3.8 Release Manager, is publishing a monthly
> newsletter dedicated to Koha 3.8 development. It can be found on the
> Koha Community website in the Koha News category.
> 
> The latest issue is here.
> 
> Experimental Support for MARC Records as a Proper Datatype in the
> PostgreSQL Database
> by Marc Balmer
> 
> Sitting in one of the nice pubs in Edinburgh during KohaCon, I had
> this idea to add MARC records as a proper datatype to the PostgreSQL
> database server. After a discussion with Marc V?ron and Dobrica
> Pavlinusic about what that could mean, I decided to just try it and I
> have now a basic implementation (or, more a proof of concept). Here is
> some information on this:
> 
> If MARC records are a proper datatype, that means they are stored
> right in the database, are backed-up, can be restored, replicated,
> etc., just with the standard database tools. If a function is provided
> to access individual fields of a MARC record, then this can be used in
> SQL expressions, e.g. for selects or to create views, etc. As
> PostgreSQL supports functional indexes, you can create indexes on
> individual MARC fields, giving you super fast access to your data.
> 
> How does it look?
> 
> There is a datatype called ?marc? for now:
> 
> CREATE TABLE books ( id serial, sig varchar(16), marc_record marc );
> 
> MARC records are loaded into the database as raw, binary records,
> encoded in hexadecimal:
> 
> INSERT INTO books (sig, marc_record) VALUES (?a01b?, ?3030383830?..?);
> 
> To access individual MARC fields, the function ?marc_field()? was
> created; it returns VARCHAR:
> 
> SELECT id, marc_field(marc_record, ?020') AS isbn FROM books WHERE sig = ?a01b?;
> 
> Of course MARC fields can be used to search data:
> 
> SELECT id, marc_field(marc_record, ?020') AS isbn FROM books WHERE
> marc_field(marc_record, ?245') like ?whatever%?;
> 
> An index on a specific field can easily be created:
> 
> CREATE INDEX books_isbn_idx ON books (marc_field(marc_record, ?020'));
> 
> As syntactic sugar, the expression marc_record@?020' is equal to
> marc_field(marc_record, ?020').
> 
> Marijana Glavica kindly let me use a MARC database of ~250,000 records
> to make some tests, here are some real world examples:
> 
> books=# \d test_marc
> Table ?public.test_marc?
> Column | Type | Modifiers
> ???+???+???????????????????
> id | integer | not null default nextval(?test_marc_id_seq?::regclass)
> marc21 | marc |
> 
> books=# select count(id) from test_marc;
> count
> ???
> 246727
> (1 row)
> 
> How many Croatian books do they have?
> 
> books=# select count(id) from test_marc where
> substring(marc_field(marc21, ?008'), 37, 3) = ?hrv?; count
> 
> ??- 52582 (1 row)
> 
> Of course much more complex queries are possible with this, and using
> the right indexes it is really, really fast. One query I tested went
> from 8.4 seconds to 0.21 ms with the right index. That?s a speedup of
> 40,000 times.
> 
> Thanks to Marijana, Dobrica, and Marc for feedback, interesting
> discussions and ideas!
> 
> Feedback and suggestions are of course more than welcome at marc at msys.ch.
> 
> Adding VIAF Autosuggest for New NAME Authorities
> by Stefano Bargioni
> 
> The Pontificia Universit? della Santa Croce has written a script to
> enhance authority cataloguing using VIAF.
> 
> While adding new authorities of type *NAME, the VIAF catalog can be
> browsed using its autosuggest API. The script adds a field on top of
> the /cgi-bin/koha/authorities/authorities.pl page. Typing three or
> more letters, a popup will be populated with the first ten names. Upon
> selecting a name, information about the sources of the authority name
> will be displayed, as well as the full authority record from VIAF, or
> LC if available.
> 
> This is an initial version. The next version will try to copy the VIAF
> authority record into Koha. Comments and help to bargioni at pusc.it will
> be appreciated.
> Koha Community
> 
> New Koha Libraries
> 
>     Bethlehem Public Library (via ByWater Solutions)
>     Cooperative Information Network (via ByWater Solutions)
>     Fresnes-en-Wo?vre (via BibLibre)
>     New Zealand Education Institute Te Riu Roa Library (via Catalyst)
>     New Zealand Ministry of Education Library (via Catalyst)
>     Pierrefitte-sur-Aire (via BibLibre)
>     San Francisco Maritime National Historical Park (via ByWater Solutions)
>     Spincourt (via BibLibre)
>     Universit? Rennes 2 (via BibLibre)
>     Valley Automated Library Network (via ByWater Solutions)
>     Vigneulles-les-Hattonchatel (via BibLibre)
> 
> Community Gossip
> 
> Silvia Giannitrapani, a student of Library and Information Studies at
> London?s UCL, is researching open source library management systems
> for her dissertation ?Can Koha and other open source library
> management systems compete with proprietary systems?? To support her
> research she is inviting Koha community members to share their views
> and overall satisfaction with Koha in a brief survey. For more
> information, email silviag at bu.edu.
> 
> Four French libraries are now using Koha with Solr.
> 
> Nicole Engard has created a version of Koha 3.8 release notes
> addressed to users and librarians.
> 
> A discussion on the Koha-devel list addressed alternatives to having
> to participate in an IRC meeting in order to vote on a question before
> the community.
> 
> D Ruth Bavousett posted her thoughts on diversity in open-source communities.
> 
> Mirko Tietgen has Koha running on a Raspberry Pi, ?An ARM GNU/Linux
> box for $25?. More information is here.
> 
> Heather Hernandez, Technical Services Librarian at San Francisco
> Maritime National Historical Park, blogged about her experience with
> setting up Koha.
> 
> An RFC on the Koha namespace has been posted to the wiki.
> 
> Gaetan Boisson reports that Biblibre recently submitted to the Drupal
> community an opac module that allows Drupal to connect to Koha (or
> other ILS?s). More information is here.
> 
> Koha-Kobli News
> by Domingo Arroyo
> 
> The Koha-Kobli release team is happy to announce the second stable
> release of Koha-Kobli 1.8, based on Koha 3.8. Kobli is a customized
> version of Koha ILS developed by the Working Group of BAGEs (Spanish
> General State Authority Libraries). Kobli 1.8 is released in two
> versions: one for normal installation, and one as a VMware virtual
> appliance.
> 
> Koha-Kobli?s 1.8 download is here. More information is here.
> 
> Recent implementations of Koha-Kobli include the Spanish Ministry of
> the Presidency Library and the Library of the Center for Analysis and
> Forescasting of the Spanish Civil Guard. More information is here and
> here.
> Past Koha Events
> 
> June General IRC Meeting
> 
> The June general IRC meeting was held on 13 June 2012.
> 
> More information, including the agenda and links to the minutes, is here.
> 
> KohaCon12
> 
> KohaCon12 has come and gone! David Nind (with others) has done an
> excellent job of updating the conference?s schedule page with lots of
> links to blog posts, photos, slides, and more. The Hackfest page has
> also been updated with links to some slides, posts, and tools.
> Upcoming Koha Events
> 
> July General IRC Meeting
> 
> Details on the July general IRC meeting are not yet available as we go to press.
> 
> KohaCon13
> 
> The deadline for posting bids to host KohaCon2013 is almost here. See
> the conference?s wiki page for the current bids or to add yours.
> _______________________________________________
> 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/

-- 
Gaetan Boisson
Chef de projet biblioth?caire
BibLibre
06 52 42 51 29
108 avenue Breteuil 13006 Marseille
gaetan.boisson at biblibre.com


From fridolyn.somers at gmail.com  Wed Jun 27 15:13:25 2012
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Wed, 27 Jun 2012 15:13:25 +0200
Subject: [Koha-devel] Modern Perl blog article
In-Reply-To: <4FEADFA4.7050204@biblibre.com>
References: <CAN6cLAU61+D9OZa5L2tjES5XhgSaW5td0HKfg3R29StFh85xFg@mail.gmail.com>
	<4FEADFA4.7050204@biblibre.com>
Message-ID: <CAN6cLAW-xb24ioSwGP387ANjSj5d5EUPDh5Fn5bKvC6okt4ssg@mail.gmail.com>

Thanks Paul,

Indeed.
July 9th I will present myself as Biblibre and be more active on Koha.
I bring with me 7 years of experience in software development with 2 on
Koha.
I hope my job will be appreciated by everyone.
I will be proud to work for an open-source and international software.

FYI I was born in Germany, I'm belgian and I studied and live in France.

Best regards,

Fridolyn

On Wed, Jun 27, 2012 at 12:25 PM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Le 27/06/2012 10:54, Fridolyn SOMERS a ?crit :
>
> Just FYI = Fridolyn will soon (july 10th) have a @biblibre.com email, as
> we hire him
>
> (he left progilone something like 1 year ago, and misses Koha so much
> that we had to fix this ;-) )
>
> --
> 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/
>



-- 
Fridolyn SOMERS
fridolyn.somers at gmail.com
Marsillargues - France
 <fridolyn.somers at gmail.com>
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20120627/76908d98/attachment.htm>

From claire.hernandez at biblibre.com  Wed Jun 27 17:38:27 2012
From: claire.hernandez at biblibre.com (Claire Hernandez)
Date: Wed, 27 Jun 2012 17:38:27 +0200
Subject: [Koha-devel]
 http://wiki.koha-community.org/wiki/Koha_Namespace_RFC, moving ahead
In-Reply-To: <4FE864F7.3090007@biblibre.com>
References: <4FE864F7.3090007@biblibre.com>
Message-ID: <4FEB28F3.8000000@biblibre.com>

On 25/06/2012 15:17, Paul Poulain wrote:
> Hello koha-devel,
>
> After our discussions during the hackfest, a wiki page has been written.
> Now, it's time for the first patches, to see how it could look like.
> I made some work on bug 8309.
> That's not a request for signoff, but to look at the code, comment,
> discuss, ...
>
> Note: if you want to play with those patches, look in
> admin/categories.pl and testrelations.pl. You'll have to install Moose
> and DBIx::Class, (available on probably all linux distros)
Hello,

I would rename things to have easier and smaller names to remember and 
would move things:

- BusinessLogic renamed in Service
- DBObject renamed in Data
- DB tables in Schema

Like this, we have one "layer" less (KISS):
before: BusinessLogic -> DBObject -> DB -> Schema (-> means "use")
after: Service -> Data -> Schema

Data become the only thing to call Schema DBIx::Class and seems to me 
more clear (if object needs only one table, ok, we'll have a very simple 
object and crud sub if object needs more agregation, the crud sub can 
become - a little bit - more complex).

If I take time I could propose new patches but discussion before is 
important too ;)

In France we have "fpw" this weekend (2 days only for perl conferences 
and hacking), 6 from BibLibre will attend. It will be a place to ask 
about modern ways to do perl nowadays and feelings about some libraries 
we could use will be welcomed.

Claire.

From paul.poulain at biblibre.com  Fri Jun 29 10:30:16 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 29 Jun 2012 10:30:16 +0200
Subject: [Koha-devel] Request for moremember page...
Message-ID: <4FED6798.6010608@biblibre.com>

Hello Koha-devel,

The moremember.pl page, that display a patron detail, contain a lot of
informations : patron detailled information (including some that are not
daily useful), Patron image management (if activated), patron extended
attributes (if used), patron messaging preferences (if used), checkout
fines, holds
I just pushed a new feature, that let the library upload any file
attached to the patron (bug 8130)

Overall, if someone want to relook this page, I think many ppl would
applaude ! My suggestion (but I'm not a designer) : add tabs. The first
tab displaying basic information & checkout/fines/holds, other
displaying other less important informations.

Note : on my 22" screen, the checkouts/fines/hold does not appear on the
visible part of the screen, it's a shame, that's a major information.
-- 
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  Fri Jun 29 14:14:58 2012
From: nengard at gmail.com (Nicole Engard)
Date: Fri, 29 Jun 2012 08:14:58 -0400
Subject: [Koha-devel] Request for moremember page...
In-Reply-To: <4FED6798.6010608@biblibre.com>
References: <4FED6798.6010608@biblibre.com>
Message-ID: <CAC0K6VFPE0LViRJZ_mZ=r7HKRQ3H5OegCC6d_jDHJs6BuQ8sbg@mail.gmail.com>

On Fri, Jun 29, 2012 at 4:30 AM, Paul Poulain <paul.poulain at biblibre.com> wrote:
> Overall, if someone want to relook this page, I think many ppl would
> applaude ! My suggestion (but I'm not a designer) : add tabs. The first
> tab displaying basic information & checkout/fines/holds, other
> displaying other less important informations.

+1 from me!! Do we have an enhancement request for this? Also, the
BorrowerUnwantedField should effect the display and the OPAC display
in addition to the add/edit form.

Nicole

From paul.poulain at biblibre.com  Fri Jun 29 16:02:44 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 29 Jun 2012 16:02:44 +0200
Subject: [Koha-devel] Bug 6557 pushed, please check localised frameworks
Message-ID: <4FEDB584.3000100@biblibre.com>

Hello devel & translate,

I just pushed the patch for
bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6557 . It fixes a
nasty long-lasting problem, BUT will work only if your frameworks are OK.

The popularity is based on biblioitems.totalissues field, that *must* be
linked to 942$0 field.
It's the default for MARC21 in english, I've fixed UNIMARC in french,
*please* check your language/marc flavour.

If the biblioitems.totalissues is not linked to 942$0, you'll get a
nasty (and unclear, i've asked for a follow-up to have something more
understandable):

Tag "0" is not a valid tag. at
/home/paul/koha.dev/koha-community//C4/Biblio.pm line 3870

*nengard* = this one will need a large/complete documentation !

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08


From colin.campbell at ptfs-europe.com  Fri Jun 29 17:04:38 2012
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Fri, 29 Jun 2012 16:04:38 +0100
Subject: [Koha-devel]
 http://wiki.koha-community.org/wiki/Koha_Namespace_RFC, moving ahead
In-Reply-To: <4FEB28F3.8000000@biblibre.com>
References: <4FE864F7.3090007@biblibre.com>
 <4FEB28F3.8000000@biblibre.com>
Message-ID: <20120629150438.GA23062@zazou.cscnet.co.uk>

On Wed, Jun 27, 2012 at 05:38:27PM +0200, Claire Hernandez wrote:
> I would rename things to have easier and smaller names to remember
> and would move things:
> 
> - BusinessLogic renamed in Service
> - DBObject renamed in Data
> - DB tables in Schema
> 
> Like this, we have one "layer" less (KISS):
> before: BusinessLogic -> DBObject -> DB -> Schema (-> means "use")
> after: Service -> Data -> Schema
> 

I agree wholeheartedly. Its much more succinct and captures what we're
trying to model. (plus I'm sure I'll get sick of fixing my missspellings
of BusinessLogic)  

Colin

-- 
Colin Campbell
Chief Software Engineer,
PTFS Europe Limited
Content Management and Library Solutions
+44 (0) 800 756 6803 (phone)
+44 (0) 7759 633626  (mobile)
colin.campbell at ptfs-europe.com
skype: colin_campbell2

http://www.ptfs-europe.com


From jcamins at cpbibliography.com  Fri Jun 29 17:16:46 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Fri, 29 Jun 2012 11:16:46 -0400
Subject: [Koha-devel]
 http://wiki.koha-community.org/wiki/Koha_Namespace_RFC, moving ahead
In-Reply-To: <4FEB28F3.8000000@biblibre.com>
References: <4FE864F7.3090007@biblibre.com>
	<4FEB28F3.8000000@biblibre.com>
Message-ID: <CALVDfQwKMv8exqtxkNT0f5GtsG9AhedXs_68kzmV-3gDZUOjww@mail.gmail.com>

> I would rename things to have easier and smaller names to remember and
would move things:
>
> - BusinessLogic renamed in Service
> - DBObject renamed in Data
> - DB tables in Schema
>
> Like this, we have one "layer" less (KISS):
> before: BusinessLogic -> DBObject -> DB -> Schema (-> means "use")
> after: Service -> Data -> Schema
>
> Data become the only thing to call Schema DBIx::Class and seems to me
more clear (if object needs only one table, ok, we'll have a very simple
object and crud sub if object needs more agregation, the crud sub can
become - a little bit - more complex).

+1 from me as well.

Regards,
Jared
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120629/1daafa54/attachment.htm>