From robin at catalyst.net.nz  Fri Apr  1 00:13:41 2011
From: robin at catalyst.net.nz (Robin Sheat)
Date: Fri, 01 Apr 2011 11:13:41 +1300
Subject: [Koha-devel] Accounts rewriting - comments wanted.
In-Reply-To: <AANLkTi=6977ppF2WJ2aLHUObL-Ada8_K2jUJ8qp5WtcR@mail.gmail.com>
References: <1301555550.26714.38.camel@zarathud>
	<AANLkTi=6977ppF2WJ2aLHUObL-Ada8_K2jUJ8qp5WtcR@mail.gmail.com>
Message-ID: <1301609621.26714.58.camel@zarathud>

Ian Walls schreef op do 31-03-2011 om 10:01 [-0400]:
> One comment:  $type should be user-definable, not hardcoded values.
> More extensible that way, since libraries are always good at coming up
> with new ways of doing things.  This would allow for statistical
> reports on Accounts to a library-specific level of granularity; I just
> know if we do it hard-coded, someone is going to complain that they
> can't differentiate fine types at all get lumped into 'M'.

There's no logic behind the type, except perhaps 'F' to indicate fines
that should be forgiven/removed when in dropbox mode. What I'll do for
now is make sure I don't put anything in that's restricting them (except
perhaps 'F',) and this will allow a future enhancement that could, say,
pull the possible options from an authorised value or some such.

On that note, what would people suggest for handling fines that should
be cancelled in an accounting-sorta way? So far in my design, the only
way to reduce/remove a charge is to attach a payment to it. The two
options I can see are:
1) create an offset that doesn't link to a payment that cancels out the
charge (this seems like it'll make things unbalanced)
2) add a 'cancelled' flag on the transaction.

I'll probably go for 2, unless someone has opinions.

-- 
Robin Sheat
Catalyst IT Ltd.
? +64 4 803 2204
GPG: 5957 6D23 8B16 EFAB FEF8  7175 14D3 6485 A99C EB6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20110401/363b17ce/attachment.pgp>

From chris at bigballofwax.co.nz  Fri Apr  1 00:19:03 2011
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Fri, 1 Apr 2011 11:19:03 +1300
Subject: [Koha-devel] Accounts rewriting - comments wanted.
In-Reply-To: <1301609621.26714.58.camel@zarathud>
References: <1301555550.26714.38.camel@zarathud>
	<AANLkTi=6977ppF2WJ2aLHUObL-Ada8_K2jUJ8qp5WtcR@mail.gmail.com>
	<1301609621.26714.58.camel@zarathud>
Message-ID: <AANLkTikSTqxLTk96e2gXxoVa0cXgq8h_axuHns4ot3QD@mail.gmail.com>

2011/4/1 Robin Sheat <robin at catalyst.net.nz>:
> Ian Walls schreef op do 31-03-2011 om 10:01 [-0400]:
>> One comment: ?$type should be user-definable, not hardcoded values.
>> More extensible that way, since libraries are always good at coming up
>> with new ways of doing things. ?This would allow for statistical
>> reports on Accounts to a library-specific level of granularity; I just
>> know if we do it hard-coded, someone is going to complain that they
>> can't differentiate fine types at all get lumped into 'M'.
>
> There's no logic behind the type, except perhaps 'F' to indicate fines
> that should be forgiven/removed when in dropbox mode. What I'll do for
> now is make sure I don't put anything in that's restricting them (except
> perhaps 'F',) and this will allow a future enhancement that could, say,
> pull the possible options from an authorised value or some such.
>
> On that note, what would people suggest for handling fines that should
> be cancelled in an accounting-sorta way? So far in my design, the only
> way to reduce/remove a charge is to attach a payment to it. The two
> options I can see are:
> 1) create an offset that doesn't link to a payment that cancels out the
> charge (this seems like it'll make things unbalanced)
> 2) add a 'cancelled' flag on the transaction.
>
> I'll probably go for 2, unless someone has opinions.
>
There definitely needs to be an easy way to write off a charge. It
happens a lot, The way it is done now is with a writeoff payment. But
as long as however it is done allows the same functionality I'm happy

Chris

From kmkale at anantcorp.com  Fri Apr  1 13:28:11 2011
From: kmkale at anantcorp.com (Koustubha Kale)
Date: Fri, 1 Apr 2011 16:58:11 +0530
Subject: [Koha-devel] Accounts rewriting - comments wanted.
In-Reply-To: <AANLkTi=6977ppF2WJ2aLHUObL-Ada8_K2jUJ8qp5WtcR@mail.gmail.com>
References: <1301555550.26714.38.camel@zarathud>
	<AANLkTi=6977ppF2WJ2aLHUObL-Ada8_K2jUJ8qp5WtcR@mail.gmail.com>
Message-ID: <AANLkTikxmnvG5qP4AXMHMgGaY25zXDHQGL9wEOFnA8HH@mail.gmail.com>

2011/3/31 Ian Walls <ian.walls at bywatersolutions.com>:
> One comment:? $type should be user-definable, not hardcoded values.? More
> extensible that way, since libraries are always good at coming up with new
> ways of doing things.? This would allow for statistical reports on Accounts
> to a library-specific level of granularity; I just know if we do it
> hard-coded, someone is going to complain that they can't differentiate fine
> types at all get lumped into 'M'.
>
> Otherwise, looks good.? If I have any more comments after re-reading, I'll
> post.? Thanks, Robin!
>
>
> -Ian
>


+1 for user definable $type. I get that all the time.


Regards,
Koustubha Kale
Anant Corporation

Contact Details :
Address? : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes
Naka, Thane (w),
? ? ? ? ??? ? ? Maharashtra, India, Pin : 400601.
TeleFax? : +91-22-21720108, +91-22-21720109
Mobile? ?? : +919820715876
Website? : http://www.anantcorp.com
Blog : http://www.anantcorp.com/blog/?author=2

From chris at bigballofwax.co.nz  Fri Apr  1 19:47:36 2011
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Sat, 2 Apr 2011 06:47:36 +1300
Subject: [Koha-devel] Restructuring C4
In-Reply-To: <AANLkTi=PN4oPvzpMkm=2JTXh89YPtq+wSieS9ixLgt6T@mail.gmail.com>
References: <AANLkTimjYEY8R8ROiFUjLUGVB-SsMJPtANrchc2fro6+@mail.gmail.com>
	<AANLkTi=PN4oPvzpMkm=2JTXh89YPtq+wSieS9ixLgt6T@mail.gmail.com>
Message-ID: <AANLkTim5ePeiV7poTxA5ekkUotMTSs0bs-4sUH7K-Lva@mail.gmail.com>

On 31 March 2011 16:51, Galen Charlton <gmcharlt at gmail.com> wrote:
> Hi,
>
>
> 2011/3/30 Ian Walls <ian.walls at bywatersolutions.com>:
>> All this indicate to me that we REALLY need to start thinking about imposing
>> some kind of structure on C4.? I'm thinking something with two-levels:
>>
>> Level 1 :? Calls to the database, other direct interaction with stored data
>> Level 2:?? Calls to Level 1 functions to manipulate data
>
> Thanks for doing the analysis. ?Regarding the overall project of
> restructuring C4, I suggest a slightly different way of looking at it:
> *not* restructuring C4 as such, but using it as a springboard for its
> successor.
>
> In other words, we'd still be creating a better structure, just in a
> different namespace. ?Let's pick a name randomly for that namespace.
> I reach into my hat and pull out ... "Koha". ?Fancy that. :)
>
> The Koha namespace would be for Perl modules that meet the following
> mandatory conditions:
>
> - usable by mod_perl (or its equivalent)
> - export the minimum number of routines necessary
> - follow stricture, warnings, documentation, and test case standards
> - separating data access methods from business logic
>
> and preferably the following optional conditions:
>
> - purely OO
>
> Obviously, the conditions and whether they would be mandatory or
> optional is a topic for discussion.
>
> Modules in C4 could use (and would be encouraged to use) routines in
> the Koha namespace. ?Modules in Koha could not in general use C4
> modules; any C4 module that was safe to be depended on by a Koha
> module would be a candidate for being renamed to Koha.
>
> The advantage of carving out a new namespace is that it doesn't
> require that we refactor the entirety of C4 to support persistance or
> to untangle the dependency tree. ?Instead, the only C4 code we would
> have to reimplement for the Koha namespace right away would be
> authentication, basic session management, and basic output. ?That,
> along with data access using DBIx::Class, would allow us to start
> using mod_perl right away for specific functions. ?One example of
> something that would then be easy to transform to a service running
> under mod_perl would be the unapi and OAI-PMH services. ?As
> functionality gets detangled from C4 and moved into Koha, we can
> increase the number of services running under mod_perl while still
> keeping the CGI scripts that still depend on C4.
>
+1 From me

I think this is the way to go.

Chris

From David.W.Hartman at disney.com  Fri Apr  1 19:55:49 2011
From: David.W.Hartman at disney.com (Hartman, David W. - GBTS Library)
Date: Fri, 1 Apr 2011 13:55:49 -0400
Subject: [Koha-devel] Does Koha support anything other than MySQL? We have
 standardized on Oracle and SQL Server.
Message-ID: <3E19441498923443B9DBE2FE1C0E70B60403E85DB0@SM-FLOR-VXMB04B.wdw.disney.com>

Does Koha support anything other than MySQL? We have standardized on Oracle and SQL Server.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110401/24d4d843/attachment.htm>

From chrisc at catalyst.net.nz  Fri Apr  1 20:13:43 2011
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Sat, 2 Apr 2011 07:13:43 +1300
Subject: [Koha-devel] Does Koha support anything other than MySQL? We
 have standardized on Oracle and SQL Server.
In-Reply-To: <3E19441498923443B9DBE2FE1C0E70B60403E85DB0@SM-FLOR-VXMB04B.wdw.disney.com>
References: <3E19441498923443B9DBE2FE1C0E70B60403E85DB0@SM-FLOR-VXMB04B.wdw.disney.com>
Message-ID: <20110401181343.GS8495@rorohiko>

* Hartman, David W. - GBTS Library (David.W.Hartman at disney.com) wrote:
>    Does Koha support anything other than MySQL? We have standardized on
>    Oracle and SQL Server.
> 
>    ?
Hi David

It has been made to work on other databases in the past, but currently
only MySQL is officially supported. It can work with mariadb as well,
which is an dropin MySQL replacement, and there is active work under way
to get it working with more, Postgres at least.

Oracle and SQL Server aren't high on my list, being proprietary, but the
work done on database layer abstraction should allow for even these to
be used. 

You could try them with the current release, and they may work, but you
would have to do some code changes at least in C4/Context.pm and the
config files to get them to work. But I suspect there will be a lot of
little gotchas, so I wouldn't recommend trying to run a current release
of Koha on either.

Chris
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/


-- 
Chris Cormack
Catalyst IT Ltd.
+64 4 803 2238
PO Box 11-053, Manners St, Wellington 6142, New Zealand
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: </pipermail/koha-devel/attachments/20110402/b956d4da/attachment.pgp>

From ian.walls at bywatersolutions.com  Fri Apr  1 20:34:55 2011
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Fri, 1 Apr 2011 14:34:55 -0400
Subject: [Koha-devel] Specifying Email headers per Notice
Message-ID: <AANLkTikbVBuJg12MeED2ZLHu8n5mjOF9TTK_eN_urcn_@mail.gmail.com>

Fellow Developers,


I've had a development request to allow librarians, on a per-Notice level,
to specify the Reply-To address for each message going out.  The goal is to
have conversations around certain kinds of notices to be with certain staff
members (for Holds, talk to this person, for Purchase Suggestions, that
person...)

However, specifying an email address at the Notices level would not work in
a multi-branch environment; it would require that each branch configure
their own copy of a Notice if they wanted their own Reply-To address.  This
could get messy quick.

So, I ask, what's the best way to solve this issue?  Should it be to tie
Notices to specific branches, adding a column in the database and a filter
on that column in the Notices interface?  Or perhaps add an additional
"Notices Reply-to Emails" configuration section in the Branch admin screen?

Thank you in advance for your feedback,


-Ian

-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
ALA Booth 732
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110401/ff4bdd8d/attachment.htm>

From cnighswonger at foundations.edu  Fri Apr  1 20:53:32 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Fri, 1 Apr 2011 14:53:32 -0400
Subject: [Koha-devel] Specifying Email headers per Notice
In-Reply-To: <AANLkTikbVBuJg12MeED2ZLHu8n5mjOF9TTK_eN_urcn_@mail.gmail.com>
References: <AANLkTikbVBuJg12MeED2ZLHu8n5mjOF9TTK_eN_urcn_@mail.gmail.com>
Message-ID: <BANLkTi=s1QnHcQzEvLZRq30QBeFA6O=h2Q@mail.gmail.com>

2011/4/1 Ian Walls <ian.walls at bywatersolutions.com>

<snip>


> So, I ask, what's the best way to solve this issue?  Should it be to tie
> Notices to specific branches, adding a column in the database and a filter
> on that column in the Notices interface?  Or perhaps add an additional
> "Notices Reply-to Emails" configuration section in the Branch admin screen?
>

I'd vote for option #2 as it seems the most straightforward and would allow
for the use of that information in other areas if so desired.

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

From paul.a at aandc.org  Sat Apr  2 22:57:29 2011
From: paul.a at aandc.org (Paul)
Date: Sat, 02 Apr 2011 16:57:29 -0400
Subject: [Koha-devel] 700 and frameworks
Message-ID: <5.2.1.1.2.20110402110633.12f6c480@stormy.ca>

Does anyone know if Marc field 700 has any obscure dependencies in Koha 
that would give, when trying to save a biblio record, the error: " * Field 
700 is mandatory, at least one of its subfields must be filled" despite 
none of the subfields being set to mandatory.

The error appears to come from one of the scripts loaded in the workstation 
GUI because clicking "Save" does not even attempt to access the server 
(this from Apache2 logs.)

We have a new framework that is based on "Default". Following a thread 
(specifically Fri, 1 Apr 2011 10:26:38 +0800) on the Koha users' list 
concerning frameworks, to expand the GUI presentation of Fields with 
multiple sub-fields, we had set the *field* to mandatory for 020, 040, 082, 
100, 245, 250, 260, 300, 520, 521, 650, 700 and 942.

*Only* 700 poses a problem - I have had to set it back to non-mandatory in 
order to save the record. Others that are set to mandatory at field level 
save perfectly with no input (e.g. 020 "ISBN Number" can be left blank) 
unless of course there is a mandatory sub-field.

Is there any [easy] way to set $subfield_data{visibility} (add-biblio.pm 
line 346 to 351) to "" except by setting field to mandatory (or by adding 
valid data through Z39.50)?  I have not [quickly] found another method to 
ensure immediate sub-field visibility in the GUI (which staff and 
volunteers are asking for.)

Thoughts anyone?

Thanks

Paul
Tired old sys-admin  


From paul.a at aandc.org  Sun Apr  3 00:48:43 2011
From: paul.a at aandc.org (Paul)
Date: Sat, 02 Apr 2011 18:48:43 -0400
Subject: [Koha-devel] Error deleting an authority
Message-ID: <5.2.1.1.2.20110402184251.02519f78@stormy.ca>

I'm getting error:
Undefined subroutine &C4::AuthoritiesMarc::prepare called at 
/usr/share/koha/lib/C4/AuthoritiesMarc.pm line 720.

Here's the code from AuthoritiesMarc.pm
           ModZebra($authid,"recordDelete","authorityserver",GetAuthority($authid),undef);
720=>    my $sth = prepare("DELETE FROM auth_header WHERE authid=?");
          $sth->execute($authid);

The authid is being passed [correctly?] as a 4 digit integer|string: 
<http://koha-admin/cgi-bin/koha/authorities/authorities-home.pl?op=delete&amp;authid=2925>

Any thoughts?

Thanks

Paul
Tired old sys-admin 


From chris at bigballofwax.co.nz  Sun Apr  3 01:21:33 2011
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Sun, 3 Apr 2011 11:21:33 +1200
Subject: [Koha-devel] Error deleting an authority
In-Reply-To: <5.2.1.1.2.20110402184251.02519f78@stormy.ca>
References: <5.2.1.1.2.20110402184251.02519f78@stormy.ca>
Message-ID: <BANLkTimgWQv_ERG4aAoQtZZZyH1Or20x8A@mail.gmail.com>

On 3 April 2011 10:48, Paul <paul.a at aandc.org> wrote:
> I'm getting error:
> Undefined subroutine &C4::AuthoritiesMarc::prepare called at
> /usr/share/koha/lib/C4/AuthoritiesMarc.pm line 720.
>
> Here's the code from AuthoritiesMarc.pm
>
> ?ModZebra($authid,"recordDelete","authorityserver",GetAuthority($authid),undef);
> 720=> ? ?my $sth = prepare("DELETE FROM auth_header WHERE authid=?");
> ? ? ? ? $sth->execute($authid);
>
> The authid is being passed [correctly?] as a 4 digit integer|string:
> <http://koha-admin/cgi-bin/koha/authorities/authorities-home.pl?op=delete&amp;authid=2925>
>
What version of Koha Paul?

In the master branch in git, line 720 is
my $sth = $dbh->prepare("DELETE FROM auth_header WHERE authid=?");

The same in the 3.2.x branch.

That line was changed first on the 24th of Feb, which introduced the
bug, it was fixed on the 28th, git blame tells me
2011-02-28 08:30:07 +0000  to be exact.

But that line was fine in both 3.2.4 and 3.2.5 (and earlier releases)
and in fact was never released in the form you have) So I suspect you
must have applied a patch manually, and not the follow up, or
installed from git sometime in the 4 days between the security fix,
and the typo fix.

So I suspect you want to upgrade to 3.2.6 (the latest stable release)
or upgrade your git checkout to the lastest HEAD of the 3.2.x branch

Chris

From paul.a at aandc.org  Sun Apr  3 02:31:42 2011
From: paul.a at aandc.org (Paul)
Date: Sat, 02 Apr 2011 20:31:42 -0400
Subject: [Koha-devel] Error deleting an authority
In-Reply-To: <BANLkTimgWQv_ERG4aAoQtZZZyH1Or20x8A@mail.gmail.com>
References: <5.2.1.1.2.20110402184251.02519f78@stormy.ca>
	<5.2.1.1.2.20110402184251.02519f78@stormy.ca>
Message-ID: <5.2.1.1.2.20110402200233.052e8c28@localhost>

At 11:21 AM 4/3/2011 +1200, Chris Cormack wrote:
>On 3 April 2011 10:48, Paul <paul.a at aandc.org> wrote:
> > I'm getting error:
> > Undefined subroutine &C4::AuthoritiesMarc::prepare called at
> > /usr/share/koha/lib/C4/AuthoritiesMarc.pm line 720.
> >
> > Here's the code from AuthoritiesMarc.pm
> >
> > ? 
> ModZebra($authid,"recordDelete","authorityserver",GetAuthority($authid),undef);
> > 720=> ?  ? my $sth = prepare("DELETE FROM auth_header WHERE authid=?");
> > ?  ?  ?  ?  $sth->execute($authid);
> >
> > The authid is being passed [correctly?] as a 4 digit integer|string:
> > 
> <http://koha-admin/cgi-bin/koha/authorities/authorities-home.pl?op=delete&amp;authid=2925>
> >
>What version of Koha Paul?

Hi Chris,

3.02.05.000

We got koha-3.02.05.tar.gz downloaded 25 Feb at 8:18pm GMT (internal files 
dated 2/24/2011 4.41pm) -  talk about timing ;={

What's involved in upgrading to 3.2.6 ?  When we last did the "upgrade" 
from koha-3.02.03.tar (internal files dated 1/22/2011 6.35pm), it turned 
out to be a complete install - so we had to go back and redo all our mods 
(mostly css and custom modules) but it was still half a day's work. Thank 
$deity Koha adds suffixes to old files, but still...

Or, what's involved with "upgrade your git checkout to the lastest HEAD of 
the 3.2.x branch"? Again, we're in semi-production mode at the moment, 
staff training has started, and I really want to keep as stable as 
possible; and I do not, (for budgetary reasons) have a sandbox available at 
the moment - hopefully Q3 this year.

So - guess I just plug in a new AuthoritiesMarc.pm - for exact reference is 
date/time good enough? Also, are there any other 3.02.05 files that I need 
to look at?

Many thanks - Paul

>In the master branch in git, line 720 is
>my $sth = $dbh->prepare("DELETE FROM auth_header WHERE authid=?");
>
>The same in the 3.2.x branch.
>
>That line was changed first on the 24th of Feb, which introduced the
>bug, it was fixed on the 28th, git blame tells me
>2011-02-28 08:30:07 +0000  to be exact.
>
>But that line was fine in both 3.2.4 and 3.2.5 (and earlier releases)
>and in fact was never released in the form you have) So I suspect you
>must have applied a patch manually, and not the follow up, or
>installed from git sometime in the 4 days between the security fix,
>and the typo fix.
>
>So I suspect you want to upgrade to 3.2.6 (the latest stable release)
>or upgrade your git checkout to the lastest HEAD of the 3.2.x branch
>
>Chris

---
Maritime heritage and history, preservation and conservation,
research and education through the written word and the arts.
<http://UltraMarine.ca>, <http://AandC.org> and <http://MarDoc.ca>


From chrisc at catalyst.net.nz  Sun Apr  3 02:50:17 2011
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Sun, 3 Apr 2011 12:50:17 +1200
Subject: [Koha-devel] Error deleting an authority
In-Reply-To: <5.2.1.1.2.20110402200233.052e8c28@localhost>
References: <5.2.1.1.2.20110402184251.02519f78@stormy.ca>
	<5.2.1.1.2.20110402184251.02519f78@stormy.ca>
	<5.2.1.1.2.20110402200233.052e8c28@localhost>
Message-ID: <20110403005017.GT8495@rorohiko>

* Paul (paul.a at aandc.org) wrote:
> >What version of Koha Paul?
> 
> Hi Chris,
> 
> 3.02.05.000
> 
> We got koha-3.02.05.tar.gz downloaded 25 Feb at 8:18pm GMT (internal
> files dated 2/24/2011 4.41pm) -  talk about timing ;={
> 
> What's involved in upgrading to 3.2.6 ?  When we last did the
> "upgrade" from koha-3.02.03.tar (internal files dated 1/22/2011
> 6.35pm), it turned out to be a complete install - so we had to go
> back and redo all our mods (mostly css and custom modules) but it
> was still half a day's work. Thank $deity Koha adds suffixes to old
> files, but still...

Ahh if you have custom modules then don't do this. I assume you have all
your custom work under version control?
Or maybe not if I read below
> 
> Or, what's involved with "upgrade your git checkout to the lastest
> HEAD of the 3.2.x branch"? Again, we're in semi-production mode at
> the moment, staff training has started, and I really want to keep as
> stable as possible; and I do not, (for budgetary reasons) have a
> sandbox available at the moment - hopefully Q3 this year.
> 

If you were running from git, you could just create a local branch, merge in
the HEAD of the 3.2.x branch test and if all goes well you are done, if not,
just checkout your old branch (and restore your database from the backup
you did). I strongly suggest doing your development in a maintainable
way, under a version control system so that you can merge in from upstream. 
Or just run released versions. 

But untracked (by a version control system) changes will always cause you 
problems any time you go to upgrade.

> So - guess I just plug in a new AuthoritiesMarc.pm - for exact
> reference is date/time good enough? Also, are there any other
> 3.02.05 files that I need to look at?
> 
You could try that, you would need to be careful that no other changes
were made in that file, that rely on changes in other files.
If you find the commit in it, you could cherry-pick or find the patch
file in the koha-patches list and apply that.

Chris


-- 
Chris Cormack
Catalyst IT Ltd.
+64 4 803 2238
PO Box 11-053, Manners St, Wellington 6142, New Zealand
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: </pipermail/koha-devel/attachments/20110403/38ce924c/attachment.pgp>

From bibliwho at gmail.com  Sun Apr  3 21:45:09 2011
From: bibliwho at gmail.com (Cab Vinton)
Date: Sun, 3 Apr 2011 15:45:09 -0400
Subject: [Koha-devel] Deleting patrons
In-Reply-To: <AANLkTi=zUK4GgwyuXBU8BieaU5Kk5xn7Eev2qX6pk5f9@mail.gmail.com>
References: <AANLkTi=zUK4GgwyuXBU8BieaU5Kk5xn7Eev2qX6pk5f9@mail.gmail.com>
Message-ID: <BANLkTin4WxUr=weA2AhfvAxYFh9hajUtzQ@mail.gmail.com>

Will try this query on this list as the main Koha list drew a blank ...

Are there any issues related to deleting patrons that one should be aware of?

I'm thinking particular of the "usual" circulation and & statistical
reports that libraries run for annual reports, etc.

Thank you,

Cab Vinton, Director
Sanbornton Public Library
Sanbornton, NH

From chris at bigballofwax.co.nz  Sun Apr  3 21:58:52 2011
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Mon, 4 Apr 2011 07:58:52 +1200
Subject: [Koha-devel] Deleting patrons
In-Reply-To: <BANLkTin4WxUr=weA2AhfvAxYFh9hajUtzQ@mail.gmail.com>
References: <AANLkTi=zUK4GgwyuXBU8BieaU5Kk5xn7Eev2qX6pk5f9@mail.gmail.com>
	<BANLkTin4WxUr=weA2AhfvAxYFh9hajUtzQ@mail.gmail.com>
Message-ID: <BANLkTikS0dR5XOJ8F5v4PA7hfj8ahy7hZw@mail.gmail.com>

On 4 Apr 2011 07:45, "Cab Vinton" <bibliwho at gmail.com> wrote:
>
> Will try this query on this list as the main Koha list drew a blank ...
>
> Are there any issues related to deleting patrons that one should be aware
of?
>
> I'm thinking particular of the "usual" circulation and & statistical
> reports that libraries run for annual reports, etc.

Yep just the usual you can't report on what doesn't exist issues.

Chris

>
> Thank you,
>
> Cab Vinton, Director
> Sanbornton Public Library
> Sanbornton, NH
> _______________________________________________
> 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/20110404/662d4f10/attachment.htm>

From chris at bigballofwax.co.nz  Sun Apr  3 22:03:12 2011
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Mon, 4 Apr 2011 08:03:12 +1200
Subject: [Koha-devel] Deleting patrons
In-Reply-To: <BANLkTin4WxUr=weA2AhfvAxYFh9hajUtzQ@mail.gmail.com>
References: <AANLkTi=zUK4GgwyuXBU8BieaU5Kk5xn7Eev2qX6pk5f9@mail.gmail.com>
	<BANLkTin4WxUr=weA2AhfvAxYFh9hajUtzQ@mail.gmail.com>
Message-ID: <BANLkTin5CmR9QZhsdGdPW-2Bp5UC3VxKuA@mail.gmail.com>

On 4 Apr 2011 07:45, "Cab Vinton" <bibliwho at gmail.com> wrote:
>
> Will try this query on this list as the main Koha list drew a blank ...
>
> Are there any issues related to deleting patrons that one should be aware
of?
>
> I'm thinking particular of the "usual" circulation and & statistical
> reports that libraries run for annual reports, etc.
>
And this time with an actual useful reply. If you delete them via Koha you
will be fine. They end up in the deletedborrowers table which you can query
over, using a join or union. If you delete them in the db, then that info is
gone.

Statistics will still be in the statistics table but you will no longer be
able to find the borrower with your query to get things like categorycode
etc.

Chris

> Thank you,
>
> Cab Vinton, Director
> Sanbornton Public Library
> Sanbornton, NH
> _______________________________________________
> 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/20110404/1cf13143/attachment.htm>

From bibliwho at gmail.com  Sun Apr  3 22:28:43 2011
From: bibliwho at gmail.com (Cab Vinton)
Date: Sun, 3 Apr 2011 16:28:43 -0400
Subject: [Koha-devel] Deleting patrons
In-Reply-To: <BANLkTin5CmR9QZhsdGdPW-2Bp5UC3VxKuA@mail.gmail.com>
References: <AANLkTi=zUK4GgwyuXBU8BieaU5Kk5xn7Eev2qX6pk5f9@mail.gmail.com>
	<BANLkTin4WxUr=weA2AhfvAxYFh9hajUtzQ@mail.gmail.com>
	<BANLkTin5CmR9QZhsdGdPW-2Bp5UC3VxKuA@mail.gmail.com>
Message-ID: <BANLkTineJbM-V+Qr8b7B2U8iC7Nra3XE2w@mail.gmail.com>

Thanks, Chris.

So, correct to say that a report like the one below would not be
affected by patrons deleted via Koha?

Checkouts by Item Type
SELECT items.itype AS Collection, COUNT( statistics.itemnumber ) AS Count
FROM statistics
LEFT JOIN items ON (statistics.itemnumber = items.itemnumber)
WHERE date(statistics.datetime) between '2009-01-01' and '2009-12-31'
AND statistics.type IN ('issue','renew')
GROUP BY items.itype

(Hmm ... in looking at this, maybe it needs to be revised to take into
account deleted items?)

Cheers,

Cab Vinton, Director
Sanbornton Public Library
Sanbornton, NH


> And this time with an actual useful reply. If you delete them via Koha you
> will be fine. They end up in the deletedborrowers table which you can query
> over, using a join or union. If you delete them in the db, then that info is
> gone.
>
> Statistics will still be in the statistics table but you will no longer be
> able to find the borrower with your query to get things like categorycode
> etc.
>

From chris at bigballofwax.co.nz  Sun Apr  3 22:50:16 2011
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Mon, 4 Apr 2011 08:50:16 +1200
Subject: [Koha-devel] Deleting patrons
In-Reply-To: <BANLkTineJbM-V+Qr8b7B2U8iC7Nra3XE2w@mail.gmail.com>
References: <AANLkTi=zUK4GgwyuXBU8BieaU5Kk5xn7Eev2qX6pk5f9@mail.gmail.com>
	<BANLkTin4WxUr=weA2AhfvAxYFh9hajUtzQ@mail.gmail.com>
	<BANLkTin5CmR9QZhsdGdPW-2Bp5UC3VxKuA@mail.gmail.com>
	<BANLkTineJbM-V+Qr8b7B2U8iC7Nra3XE2w@mail.gmail.com>
Message-ID: <BANLkTi=C0Om8zwh5YQRGXjyi1E+BQEa1JA@mail.gmail.com>

On 4 April 2011 08:28, Cab Vinton <bibliwho at gmail.com> wrote:
> Thanks, Chris.
>
> So, correct to say that a report like the one below would not be
> affected by patrons deleted via Koha?
>
> Checkouts by Item Type
> SELECT items.itype AS Collection, COUNT( statistics.itemnumber ) AS Count
> FROM statistics
> LEFT JOIN items ON (statistics.itemnumber = items.itemnumber)
> WHERE date(statistics.datetime) between '2009-01-01' and '2009-12-31'
> AND statistics.type IN ('issue','renew')
> GROUP BY items.itype

Nope, that would work just fine, as no join to borrowers.

>
> (Hmm ... in looking at this, maybe it needs to be revised to take into
> account deleted items?)
>
Well the left join with items, will mean you will get null rows so one
of your groups will be null
(grouping by items.itype). If you want to know the actual itemtypes
then yeah, you will need to do a union of items and deleteditems and
join to that

Chris

From paul.a at aandc.org  Tue Apr  5 01:01:25 2011
From: paul.a at aandc.org (Paul)
Date: Mon, 04 Apr 2011 19:01:25 -0400
Subject: [Koha-devel] authorised_values.pl
Message-ID: <5.2.1.1.2.20110404185257.052e8c28@stormy.ca>

G'd evening|morning to you all,

In authorised_values.pl, I have modded line 63:

# my $pagesize = 20; modified to 100 Paul 4 April 2011
my $pagesize = 100;

in order to get more records per page (repetitive clicking "next" was 
getting to me...) from line 221:

my @loop_data = ();
         # builds value list
         for (my $i=$offset; $i < 
($offset+$pagesize<$count?$offset+$pagesize:$count); $i++){

However, I'm still only getting 20 records per page (and arthritis in my 
right forefinger.)

Thoughts anyone?

Paul
Tired old sys-admin 


From paul.a at aandc.org  Tue Apr  5 01:07:03 2011
From: paul.a at aandc.org (Paul)
Date: Mon, 04 Apr 2011 19:07:03 -0400
Subject: [Koha-devel] authorised_values.pl
Message-ID: <5.2.1.1.2.20110404190449.20c95a08@aandc.org>

Belay my last (below) - it would have helped if I'd saved the file in the 
correct directory (I default to a temp_test.)

Apologies, it's the end of the day.

Paul


G'd evening|morning to you all,

In authorised_values.pl, I have modded line 63:

# my $pagesize = 20; modified to 100 Paul 4 April 2011
my $pagesize = 100;

in order to get more records per page (repetitive clicking "next" was 
getting to me...) from line 221:

my @loop_data = ();
         # builds value list
         for (my $i=$offset; $i < 
($offset+$pagesize<$count?$offset+$pagesize:$count); $i++){

However, I'm still only getting 20 records per page (and arthritis in my 
right forefinger.)

Thoughts anyone?

Paul
Tired old sys-admin  


From gmcharlt at gmail.com  Tue Apr  5 22:18:31 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Tue, 5 Apr 2011 16:18:31 -0400
Subject: [Koha-devel] Fwd: [OPEN-ILS-GENERAL] Notice of Change to License
	for OpenNCIP
In-Reply-To: <15958069-A836-4375-B107-6FED0FC8B1A7@esilibrary.com>
References: <1888901074.117614.1302033477098.JavaMail.root@hagrid.georgialibraries.org>
	<15958069-A836-4375-B107-6FED0FC8B1A7@esilibrary.com>
Message-ID: <BANLkTinqPmm1NWuewfkXx6LbwxxbjdbrLA@mail.gmail.com>

Hi,

Please see this notice from the Georgia Public Library Service
regarding relicensing OpenNCIP from the GPL v2 to the GPL v2+.  As you
can see, I am seeking confirmation from other copyright holders to
approve the license change.

As we all know, Koha currently embeds a fork of OpenNCIP.  To assist
with ending that situation so that Koha just uses OpenNCIP as a normal
Perl dependency, I also call on any individuals and companies who have
contributed patches to Koha's fork to express their willingness to
have their code incorporated in a GPL2+ OpenNCIP.

Regards,

Galen

---------- Forwarded message ----------
From: Galen Charlton <gmc at esilibrary.com>
Date: Tue, Apr 5, 2011 at 4:04 PM
Subject: Re: [OPEN-ILS-GENERAL] Notice of Change to License for OpenNCIP
To: Evergreen Discussion Group <open-ils-general at list.georgialibraries.org>
Cc: Dan Scott <dan at coffeecode.net>


Hi Elizabeth,

On Apr 5, 2011, at 3:57 PM, McKinney, Elizabeth wrote:
> Evergreen and other Open Source Community Members,
>
> The Georgia Public Library Service (GPLS) is the primary copyright holder on OpenNCIP. ?The source code can be found at the following sites:
>
> http://sourceforge.net/projects/openncip/
> https://github.com/atz/SIPServer
>
> As the director of the PINES program, I want to notify you that GPLS is permitting the change of the license of OpenNCIP from the GNU Public License version 2 to the GNU Public License version 2 or later in order to give it the same license that Evergreen uses. ?This will facilitate easier code sharing between OpenNCIP and Evergreen and thus benefit the Evergreen community.
>
> Feel free to distribute this notice as needed.

Thank you for this. ?I confirm on behalf of Equinox that we are also
willing to relicense any OpenNCIP code that we hold copyright on to
the GPL version 2 or later.

Based on the change logs, the following individuals may have
individual copyright on portions of OpenNCIP. ?I now call on each of
them to either approve the license change, object, or disclaim
copyright interest.

Joe Atzberger
David Fiander
Dan Scott

If anybody is aware of other individuals with a copyright interest in
the OpenNCIP code, please pass this request on to them.

Regards,

Galen
--
Galen Charlton
VP, Data Services
Equinox Software, Inc. / Your Library's Guide to Open Source
email: ?gmc at esilibrary.com
direct: +1 352-215-7548
skype: ?gmcharlt
web: ? ?http://www.esilibrary.com/




-- 
Galen Charlton
gmcharlt at gmail.com

From robin at catalyst.net.nz  Wed Apr  6 06:11:40 2011
From: robin at catalyst.net.nz (Robin Sheat)
Date: Wed, 06 Apr 2011 16:11:40 +1200
Subject: [Koha-devel] Restructuring C4
In-Reply-To: <AANLkTi=PN4oPvzpMkm=2JTXh89YPtq+wSieS9ixLgt6T@mail.gmail.com>
References: <AANLkTimjYEY8R8ROiFUjLUGVB-SsMJPtANrchc2fro6+@mail.gmail.com>
	<AANLkTi=PN4oPvzpMkm=2JTXh89YPtq+wSieS9ixLgt6T@mail.gmail.com>
Message-ID: <1302063100.23346.17.camel@zarathud>

Galen Charlton schreef op wo 30-03-2011 om 20:51 [-0700]:
> Thanks for doing the analysis.  Regarding the overall project of
> restructuring C4, I suggest a slightly different way of looking at it:
> *not* restructuring C4 as such, but using it as a springboard for its
> successor. 

I approve of this idea, and am starting it with my accounts rewrite.

I'll create a Koha/Accounts.pm and am in the process of pulling all the
direct database access to the accounts tables out of other modules and
putting the required functionality into the accounts module. 

Additionally, do we want to split things up within the Koha namespace,
for example database-accessing code vs. the more business logicy stuff?
My personal inclination is to not do that, and it wouldn't be a terrible
refactoring to do at a later stage if it were required.

Oh, something else that's recommended that I tend to do is not export
anything by default, requiring the module to be included like:
 use C4::Accounts qw/ get_users_balance /;
mostly this prevents surprising things getting into your namespace. This
is more a style suggestion though.

-- 
Robin Sheat
Catalyst IT Ltd.
? +64 4 803 2204
GPG: 5957 6D23 8B16 EFAB FEF8  7175 14D3 6485 A99C EB6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20110406/8181642e/attachment.pgp>

From colin.campbell at ptfs-europe.com  Wed Apr  6 10:18:26 2011
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Wed, 06 Apr 2011 09:18:26 +0100
Subject: [Koha-devel] Restructuring C4
In-Reply-To: <1302063100.23346.17.camel@zarathud>
References: <AANLkTimjYEY8R8ROiFUjLUGVB-SsMJPtANrchc2fro6+@mail.gmail.com>	<AANLkTi=PN4oPvzpMkm=2JTXh89YPtq+wSieS9ixLgt6T@mail.gmail.com>
	<1302063100.23346.17.camel@zarathud>
Message-ID: <4D9C21D2.60207@ptfs-europe.com>

On 06/04/11 05:11, Robin Sheat wrote:

> Oh, something else that's recommended that I tend to do is not export
> anything by default, requiring the module to be included like:
>  use C4::Accounts qw/ get_users_balance /;
> mostly this prevents surprising things getting into your namespace. This
> is more a style suggestion though.
More than style I think it generally accepted as good practice and
should be encouraged. One of the downsides of just using default export
lists apart from general namespace pollution is it gets hard to know
what you are using from module X (and sometimes on further investigation
it turns out to be nothing!)
Colin

-- 
Colin Campbell
Chief Software Engineer,
PTFS Europe Limited
Content Management and Library Solutions
+44 (0) 845 557 5634 (phone)
+44 (0) 7759 633626  (mobile)
colin.campbell at ptfs-europe.com
skype: colin_campbell2

http://www.ptfs-europe.com

From gmcharlt at gmail.com  Wed Apr  6 14:30:29 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Wed, 6 Apr 2011 08:30:29 -0400
Subject: [Koha-devel] Restructuring C4
In-Reply-To: <1302063100.23346.17.camel@zarathud>
References: <AANLkTimjYEY8R8ROiFUjLUGVB-SsMJPtANrchc2fro6+@mail.gmail.com>
	<AANLkTi=PN4oPvzpMkm=2JTXh89YPtq+wSieS9ixLgt6T@mail.gmail.com>
	<1302063100.23346.17.camel@zarathud>
Message-ID: <BANLkTimfKGm=Y=KfdKqP0=SVNrj_WdnV3A@mail.gmail.com>

Hi,

On Wed, Apr 6, 2011 at 12:11 AM, Robin Sheat <robin at catalyst.net.nz> wrote:
> Additionally, do we want to split things up within the Koha namespace,
> for example database-accessing code vs. the more business logicy stuff?
> My personal inclination is to not do that, and it wouldn't be a terrible
> refactoring to do at a later stage if it were required.

I'd prefer a separation between business logic and data access,
actually.  Perhaps

# data access - though the choice of naming may better follow whatever
pattern DBIx::Class imposes:
Koha::DB::biblio
Koha::DB::accounts

# business logic
Koha::Acounts
Koha::Cataloging
Koha::Cataloging::Biblio

or the like.  Obviously we could debate the hierarchy ad infinitum,
but as long as names are well-chosen and we don't lump unrelated
things together, we can run with what works.

> Oh, something else that's recommended that I tend to do is not export
> anything by default, requiring the module to be included like:
> ?use C4::Accounts qw/ get_users_balance /;
> mostly this prevents surprising things getting into your namespace. This
> is more a style suggestion though.

I agree with Colin that this should be more than just a style
suggestion.  We shouldn't include more than the bare minimum in
@EXPORT; @EXPORT_OK is to be preferred.

Even better would be an object oriented design.

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From lculber at mdah.state.ms.us  Wed Apr  6 14:49:40 2011
From: lculber at mdah.state.ms.us (Linda Culberson)
Date: Wed, 06 Apr 2011 07:49:40 -0500
Subject: [Koha-devel] Koha - biblioitems
Message-ID: <4D9C6164.1090307@mdah.state.ms.us>

All,
In 3.4 and on, I somehow got the impression (dream/nightmare?) that 
biblioitems was to no longer exist, and that certain MARC fields that 
are repeatable - particularly the 300, will no longer be.  Did I dream 
that or is that the case?  If it is true, will Koha have a way to handle 
those repeatable fields?

I would appreciate hearing from someone about this right away, as it may 
scuttle our whole migration plan.

Thanks!
-- 
Linda Culberson			lculber at mdah.state.ms.us
Archives and Records Services Division
Ms. Dept. of Archives & History
P. O. Box 571
Jackson, MS 39205-0571
Telephone:  601/576-6873
Facsimile:  601/576-6824


From francois.charbonnier at biblibre.com  Wed Apr  6 15:07:01 2011
From: francois.charbonnier at biblibre.com (Francois Charbonnier)
Date: Wed, 06 Apr 2011 15:07:01 +0200
Subject: [Koha-devel] Selenium IDE - firefox extension
Message-ID: <1302095221.9309.16.camel@francois-laptop>

Hello all,

I am currently working on testing bugs during the hackfest hosted by
biblibre, in marseille, and I started working with the firefox extension
"selenium IDE" to replay the tests i'm doing.

I think it would be a good thing to attach these selenium tests to each
bug we are working on. This way, it will be easier to avoid side effects
when we are working on groups of developpement that affect the same
features.

It implies that we should always work on the same dataset (we are
already working on a dataset we could use :
http://git.biblibre.com/?p=data;a=summary)
and that each template change will lead us to make the selenium test
again.

But still, i think it's a good idea for all the "testers"!

What about you? What do you think? Should we all try to work with
selenium tests each time we can?

Thank you for your answers!

-- 
Fran?ois Charbonnier
http://www.biblibre.com/
Expert en Logiciels Libres pour l'info-doc
T?l: 06 17 45 57 76




From ian.walls at bywatersolutions.com  Wed Apr  6 15:12:48 2011
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Wed, 6 Apr 2011 09:12:48 -0400
Subject: [Koha-devel] Restructuring C4
In-Reply-To: <BANLkTimfKGm=Y=KfdKqP0=SVNrj_WdnV3A@mail.gmail.com>
References: <AANLkTimjYEY8R8ROiFUjLUGVB-SsMJPtANrchc2fro6+@mail.gmail.com>
	<AANLkTi=PN4oPvzpMkm=2JTXh89YPtq+wSieS9ixLgt6T@mail.gmail.com>
	<1302063100.23346.17.camel@zarathud>
	<BANLkTimfKGm=Y=KfdKqP0=SVNrj_WdnV3A@mail.gmail.com>
Message-ID: <BANLkTinMEgH1SKYjN_S2BGEXqYVxu99iQw@mail.gmail.com>

I also would like the separation of business logic from data access.  I'm
seeing several tiers in the structure:

Template
Script
Business Logic library
Data Access library
Data structure

We can then have multiple templates to meet the needs of the library.  Bonus
points for making it fully customizable in by the librarians.

For third party integration, like SIP2 or NCIP, we would probably need
separate script level from the normal routines.  This wouldn't be a problem
if core functions were abstracted into the Business Logic library level.
That level would in turn call the data access level, which we could set up
to handle multiple backends (MySQL, Postgres, etc)


Separately, in addition to only exporting the functions needed, what about
moving the "require C4::whatever;" lines out of the BEGIN{} block and into
the subroutine that needs use of whatever's functions?  Right now, we load
all the modules at the beginning, even if only a single subroutine makes use
of that module.  If the script that uses the module only exports a single
function, and it's not the subroutine that's being used, lots of time is
wasted loading extraneous code.

For example, in my profile of circ/circulation.pl, I found that C4::Budgets,
C4::Category, C4::ClassSource, C4::Heading, C4::Heading::MARC21,
C4::ItemType, C4::Message, C4::Print, C4::Search, C4::Search::PazPar2,
C4::Serials, C4::SMS, C4::SQLHelper, C4::Suggestions, C4::VirtualShelves and
C4::XSLT were all loaded, but none of their subroutines used.  This may only
save a few microseconds, but perhaps the simplification would help.

Cheers,



-Ian

On Wed, Apr 6, 2011 at 8:30 AM, Galen Charlton <gmcharlt at gmail.com> wrote:

> Hi,
>
> On Wed, Apr 6, 2011 at 12:11 AM, Robin Sheat <robin at catalyst.net.nz>
> wrote:
> > Additionally, do we want to split things up within the Koha namespace,
> > for example database-accessing code vs. the more business logicy stuff?
> > My personal inclination is to not do that, and it wouldn't be a terrible
> > refactoring to do at a later stage if it were required.
>
> I'd prefer a separation between business logic and data access,
> actually.  Perhaps
>
> # data access - though the choice of naming may better follow whatever
> pattern DBIx::Class imposes:
> Koha::DB::biblio
> Koha::DB::accounts
>
> # business logic
> Koha::Acounts
> Koha::Cataloging
> Koha::Cataloging::Biblio
>
> or the like.  Obviously we could debate the hierarchy ad infinitum,
> but as long as names are well-chosen and we don't lump unrelated
> things together, we can run with what works.
>
> > Oh, something else that's recommended that I tend to do is not export
> > anything by default, requiring the module to be included like:
> >  use C4::Accounts qw/ get_users_balance /;
> > mostly this prevents surprising things getting into your namespace. This
> > is more a style suggestion though.
>
> I agree with Colin that this should be more than just a style
> suggestion.  We shouldn't include more than the bare minimum in
> @EXPORT; @EXPORT_OK is to be preferred.
>
> Even better would be an object oriented design.
>
> Regards,
>
> Galen
> --
> Galen Charlton
> gmcharlt at gmail.com
>



-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
ALA Booth 732
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110406/f347124c/attachment.htm>

From ian.walls at bywatersolutions.com  Wed Apr  6 15:21:06 2011
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Wed, 6 Apr 2011 09:21:06 -0400
Subject: [Koha-devel] Koha - biblioitems
In-Reply-To: <4D9C6164.1090307@mdah.state.ms.us>
References: <4D9C6164.1090307@mdah.state.ms.us>
Message-ID: <BANLkTi==_GJxBPcfFzxdLW3jnYuN6HaUYA@mail.gmail.com>

Linda,


The biblioitems table could really stand to be merged with the biblio table,
as ever since Koha 2.0 and MARC support, the two have been in 1-1
correspondence.  Having them separate introduces complication for
development and for reports.

Unfortunately, I have not seen anything come down the pike to merge them
together for 3.4.

Fortunately, these database tables have nothing to do with the repeatability
of MARC fields.  The full MARC record is stored in biblioitems, true, and
will continue to be until we get a merge in place, at which time it will be
in whatever the merged table is called.

So, do not worry.  You can repeat any MARC subfield that the standard (in
your case, I assume MARC21) will allow to be repeated (so, not 245, for
example), and shall be until MARC is completely wiped from the face of the
earth.

Cheers,


-Ian

On Wed, Apr 6, 2011 at 8:49 AM, Linda Culberson <lculber at mdah.state.ms.us>wrote:

> All,
> In 3.4 and on, I somehow got the impression (dream/nightmare?) that
> biblioitems was to no longer exist, and that certain MARC fields that are
> repeatable - particularly the 300, will no longer be.  Did I dream that or
> is that the case?  If it is true, will Koha have a way to handle those
> repeatable fields?
>
> I would appreciate hearing from someone about this right away, as it may
> scuttle our whole migration plan.
>
> Thanks!
> --
> Linda Culberson                 lculber at mdah.state.ms.us
> Archives and Records Services Division
> Ms. Dept. of Archives & History
> P. O. Box 571
> Jackson, MS 39205-0571
> Telephone:  601/576-6873
> Facsimile:  601/576-6824
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
ALA Booth 732
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110406/65fc5267/attachment.htm>

From gmcharlt at gmail.com  Wed Apr  6 16:21:12 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Wed, 6 Apr 2011 10:21:12 -0400
Subject: [Koha-devel] Restructuring C4
In-Reply-To: <BANLkTinMEgH1SKYjN_S2BGEXqYVxu99iQw@mail.gmail.com>
References: <AANLkTimjYEY8R8ROiFUjLUGVB-SsMJPtANrchc2fro6+@mail.gmail.com>
	<AANLkTi=PN4oPvzpMkm=2JTXh89YPtq+wSieS9ixLgt6T@mail.gmail.com>
	<1302063100.23346.17.camel@zarathud>
	<BANLkTimfKGm=Y=KfdKqP0=SVNrj_WdnV3A@mail.gmail.com>
	<BANLkTinMEgH1SKYjN_S2BGEXqYVxu99iQw@mail.gmail.com>
Message-ID: <BANLkTi=h=UxXU+cf+3sT_LgL=ZXxZqO9MA@mail.gmail.com>

Hi,

On Wed, Apr 6, 2011 at 9:12 AM, Ian Walls
<ian.walls at bywatersolutions.com> wrote:
> I also would like the separation of business logic from data access.? I'm
> seeing several tiers in the structure:
>
> Template
> Script
> Business Logic library
> Data Access library
> Data structure
>
> We can then have multiple templates to meet the needs of the library.? Bonus
> points for making it fully customizable in by the librarians.

But let's be careful not to get too far ahead of ourselves (regarding
fully-customizable templating, which is not strictly an API issue.
And besides, the templates are already fully customizable, albeit with
a higher bar to entry than is desirable).  But in general, I agree:
presentation should be separated from business logic should be
separated from data access.

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From colin.campbell at ptfs-europe.com  Wed Apr  6 16:29:02 2011
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Wed, 06 Apr 2011 15:29:02 +0100
Subject: [Koha-devel] Restructuring C4
In-Reply-To: <BANLkTimfKGm=Y=KfdKqP0=SVNrj_WdnV3A@mail.gmail.com>
References: <AANLkTimjYEY8R8ROiFUjLUGVB-SsMJPtANrchc2fro6+@mail.gmail.com>	<AANLkTi=PN4oPvzpMkm=2JTXh89YPtq+wSieS9ixLgt6T@mail.gmail.com>	<1302063100.23346.17.camel@zarathud>
	<BANLkTimfKGm=Y=KfdKqP0=SVNrj_WdnV3A@mail.gmail.com>
Message-ID: <4D9C78AE.8080204@ptfs-europe.com>

On 06/04/11 13:30, Galen Charlton wrote:
> Hi,
> 
> On Wed, Apr 6, 2011 at 12:11 AM, Robin Sheat <robin at catalyst.net.nz> wrote:
>> Additionally, do we want to split things up within the Koha namespace,
>> for example database-accessing code vs. the more business logicy stuff?
>> My personal inclination is to not do that, and it wouldn't be a terrible
>> refactoring to do at a later stage if it were required.
> 
> I'd prefer a separation between business logic and data access,
> actually.  Perhaps
> 
> # data access - though the choice of naming may better follow whatever
> pattern DBIx::Class imposes:

If anyone wants to experiment with DBIx::Class  using
DBIx::Class::Schema::Loader gives you a
quick way to start:
from the kohaclone directory you use the command
dbicdump -o dump_directory=. Koha::Schema dbi:mysql:dbname=koha
kohaadminuser password
This writes a Koha::Schema class and a Koha::Schema::Results::X class
for every table in the database and you can regenerate it the same way
to reflect db changes (but it preserves any custom code you add)

Colin


-- 
Colin Campbell
Chief Software Engineer,
PTFS Europe Limited
Content Management and Library Solutions
+44 (0) 845 557 5634 (phone)
+44 (0) 7759 633626  (mobile)
colin.campbell at ptfs-europe.com
skype: colin_campbell2

http://www.ptfs-europe.com

From chrisc at catalyst.net.nz  Wed Apr  6 19:17:44 2011
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Thu, 7 Apr 2011 05:17:44 +1200
Subject: [Koha-devel] Koha - biblioitems
In-Reply-To: <4D9C6164.1090307@mdah.state.ms.us>
References: <4D9C6164.1090307@mdah.state.ms.us>
Message-ID: <20110406171744.GE8495@rorohiko>

* Linda Culberson (lculber at mdah.state.ms.us) wrote:
> All,
> In 3.4 and on, I somehow got the impression (dream/nightmare?) that
> biblioitems was to no longer exist, and that certain MARC fields
> that are repeatable - particularly the 300, will no longer be.  Did
> I dream that or is that the case?  If it is true, will Koha have a
> way to handle those repeatable fields?
> 
> I would appreciate hearing from someone about this right away, as it
> may scuttle our whole migration plan.

I can confirm as 3.4 Release Manager that removing repeatable fields was
not ever planned for the 3.4.x series (or any other release series for
that matter).

Merging biblio and biblioitems may happen in the future, (not for 3.4.x)
but it will not ever result in a regression of features like this.

I'm not sure where you got them impression, if you can recall, and
correct anyone else who has this fear also that would be awesome.

The nice thing about Koha is all development and discussion is done in
the open, so at any point anyone can see exactly what is going to be in
3.4.x. No hidden suprises, no unreleased code, it's all there for
everyone to see. Which is why I recommend (well I would wouldn't I,
being Release manager and all) that people run from official Koha
releases. No hidden nasties.

Chris
-- 
Chris Cormack
Catalyst IT Ltd.
+64 4 803 2238
PO Box 11-053, Manners St, Wellington 6142, New Zealand
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: </pipermail/koha-devel/attachments/20110407/428e1d0d/attachment.pgp>

From chris at bigballofwax.co.nz  Wed Apr  6 19:23:41 2011
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Thu, 7 Apr 2011 05:23:41 +1200
Subject: [Koha-devel] Selenium IDE - firefox extension
In-Reply-To: <1302095221.9309.16.camel@francois-laptop>
References: <1302095221.9309.16.camel@francois-laptop>
Message-ID: <BANLkTi=ydgig8RGzEoAdfxxG1XR31Q1yaw@mail.gmail.com>

On 7 April 2011 01:07, Francois Charbonnier
<francois.charbonnier at biblibre.com> wrote:
> Hello all,
>
> I am currently working on testing bugs during the hackfest hosted by
> biblibre, in marseille, and I started working with the firefox extension
> "selenium IDE" to replay the tests i'm doing.
>
> I think it would be a good thing to attach these selenium tests to each
> bug we are working on. This way, it will be easier to avoid side effects
> when we are working on groups of developpement that affect the same
> features.

Definitely, It certainly can't hurt to attach them.
>
> It implies that we should always work on the same dataset (we are
> already working on a dataset we could use :
> http://git.biblibre.com/?p=data;a=summary)
> and that each template change will lead us to make the selenium test
> again.
>
> But still, i think it's a good idea for all the "testers"!
>
> What about you? What do you think? Should we all try to work with
> selenium tests each time we can?
>
Yes :) If possible.

Chris

> Thank you for your answers!
>
> --
> Fran?ois Charbonnier
> http://www.biblibre.com/
> Expert en Logiciels Libres pour l'info-doc
> T?l: 06 17 45 57 76
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/

From chris at bigballofwax.co.nz  Wed Apr  6 19:27:05 2011
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Thu, 7 Apr 2011 05:27:05 +1200
Subject: [Koha-devel] Bug 6085 - For the hackfesters
Message-ID: <BANLkTikvhWzVbAf4Pk=vWdycffQ38-f2Tg@mail.gmail.com>

Hi All

First off thanks to everyone who is signing off/testing patches and
bugs, whether you are at the sprint week or not you are all doing a
fantastic job.
Bug 6085, can't change language in OPAC and Staff was just reported,
this is currently our only blocker for 3.4.x. Could people take a look
at this bug, check it exists, and fix it please.  This will save me
having to hunt down the commit(s) that broke it and remove them from
master before release.

Chris

From cnighswonger at foundations.edu  Wed Apr  6 19:43:20 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Wed, 6 Apr 2011 13:43:20 -0400
Subject: [Koha-devel] Restructuring C4
In-Reply-To: <BANLkTi=h=UxXU+cf+3sT_LgL=ZXxZqO9MA@mail.gmail.com>
References: <AANLkTimjYEY8R8ROiFUjLUGVB-SsMJPtANrchc2fro6+@mail.gmail.com>
	<AANLkTi=PN4oPvzpMkm=2JTXh89YPtq+wSieS9ixLgt6T@mail.gmail.com>
	<1302063100.23346.17.camel@zarathud>
	<BANLkTimfKGm=Y=KfdKqP0=SVNrj_WdnV3A@mail.gmail.com>
	<BANLkTinMEgH1SKYjN_S2BGEXqYVxu99iQw@mail.gmail.com>
	<BANLkTi=h=UxXU+cf+3sT_LgL=ZXxZqO9MA@mail.gmail.com>
Message-ID: <BANLkTi=FMwiz1JbZ_hQGrs6+v6tXkGu2xw@mail.gmail.com>

On Wed, Apr 6, 2011 at 10:21 AM, Galen Charlton <gmcharlt at gmail.com> wrote:

> Hi,
>
> On Wed, Apr 6, 2011 at 9:12 AM, Ian Walls
> <ian.walls at bywatersolutions.com> wrote:
> > I also would like the separation of business logic from data access.  I'm
> > seeing several tiers in the structure:
> >
> > Template
> > Script
> > Business Logic library
> > Data Access library
> > Data structure
> >
> > We can then have multiple templates to meet the needs of the library.
> Bonus
> > points for making it fully customizable in by the librarians.
>
> But let's be careful not to get too far ahead of ourselves (regarding
> fully-customizable templating, which is not strictly an API issue.
> And besides, the templates are already fully customizable, albeit with
> a higher bar to entry than is desirable).  But in general, I agree:
> presentation should be separated from business logic should be
> separated from data access.
>

This sounds like an MVC approach. Aren't we just coming full circle with
earlier discussions about refactoring Koha around a framework like Catalyst,
Moose, etc.?

http://lists.koha-community.org/pipermail/koha-devel/2009-January/031655.html

http://lists.koha-community.org/pipermail/koha-devel/2010-June/034106.html

http://permalink.gmane.org/gmane.education.libraries.koha.devel/5218

Is this the time to bring these and other threads back to the table and move
forward with a concrete decision rather than going at it piecemeal?

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

From gmcharlt at gmail.com  Wed Apr  6 19:52:51 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Wed, 6 Apr 2011 13:52:51 -0400
Subject: [Koha-devel] Restructuring C4
In-Reply-To: <BANLkTi=FMwiz1JbZ_hQGrs6+v6tXkGu2xw@mail.gmail.com>
References: <AANLkTimjYEY8R8ROiFUjLUGVB-SsMJPtANrchc2fro6+@mail.gmail.com>
	<AANLkTi=PN4oPvzpMkm=2JTXh89YPtq+wSieS9ixLgt6T@mail.gmail.com>
	<1302063100.23346.17.camel@zarathud>
	<BANLkTimfKGm=Y=KfdKqP0=SVNrj_WdnV3A@mail.gmail.com>
	<BANLkTinMEgH1SKYjN_S2BGEXqYVxu99iQw@mail.gmail.com>
	<BANLkTi=h=UxXU+cf+3sT_LgL=ZXxZqO9MA@mail.gmail.com>
	<BANLkTi=FMwiz1JbZ_hQGrs6+v6tXkGu2xw@mail.gmail.com>
Message-ID: <BANLkTikb-tpAaEnwGb9sYANgt5c=U2uu-g@mail.gmail.com>

Hi,

On Wed, Apr 6, 2011 at 1:43 PM, Chris Nighswonger
<cnighswonger at foundations.edu> wrote:
> Is this the time to bring these and other threads back to the table and move
> forward with a concrete decision rather than going at it piecemeal?

Given Robin's announcement that he's adopting the Koha namespace for
his accounts rewrite, I think we actually have, or are about to have,
something more concrete.  Obviously, we could turn this into a
discussion of adopting a particular framework, but given that those
discussions have historically not been productive in terms of
producing much code, I think we're best off just setting some broad
guidelines, seeing what emerges in upcoming patches, *then* deciding
if we want to adopt a particular framework.  Is this putting the cart
before the horse?  Perhaps, but I think we're better off coding some
prototypes instead of risking endless discussion.

To make this more explicit: we have time before coding for 3.6
*really* kicks off to do some experimentation collectively.

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From charl at prograbiz.com  Wed Apr  6 19:56:21 2011
From: charl at prograbiz.com (Charl)
Date: Wed, 6 Apr 2011 19:56:21 +0200
Subject: [Koha-devel] Technical question
Message-ID: <89697E806D4E44BF9CCE9406A75F77B4@CharlPC>

?Good day

I need advice please. I have converted a Koha installation from 2 to Koha 3.
Now there is a "syncronization" problem between the items table and the marc record in bibioitems.

To make a long story short, the itemtype appears in the marc record, but not in the items table.
Is there a procedure how to syncronize those 2 "fields"?

Thanks for any advice!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110406/6f8a7714/attachment.htm>

From chrisc at catalyst.net.nz  Wed Apr  6 19:57:12 2011
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Thu, 7 Apr 2011 05:57:12 +1200
Subject: [Koha-devel] Restructuring C4
In-Reply-To: <BANLkTikb-tpAaEnwGb9sYANgt5c=U2uu-g@mail.gmail.com>
References: <AANLkTimjYEY8R8ROiFUjLUGVB-SsMJPtANrchc2fro6+@mail.gmail.com>
	<AANLkTi=PN4oPvzpMkm=2JTXh89YPtq+wSieS9ixLgt6T@mail.gmail.com>
	<1302063100.23346.17.camel@zarathud>
	<BANLkTimfKGm=Y=KfdKqP0=SVNrj_WdnV3A@mail.gmail.com>
	<BANLkTinMEgH1SKYjN_S2BGEXqYVxu99iQw@mail.gmail.com>
	<BANLkTi=h=UxXU+cf+3sT_LgL=ZXxZqO9MA@mail.gmail.com>
	<BANLkTi=FMwiz1JbZ_hQGrs6+v6tXkGu2xw@mail.gmail.com>
	<BANLkTikb-tpAaEnwGb9sYANgt5c=U2uu-g@mail.gmail.com>
Message-ID: <20110406175712.GF8495@rorohiko>

* Galen Charlton (gmcharlt at gmail.com) wrote:
> Hi,
> 
> On Wed, Apr 6, 2011 at 1:43 PM, Chris Nighswonger
> <cnighswonger at foundations.edu> wrote:
> > Is this the time to bring these and other threads back to the table and move
> > forward with a concrete decision rather than going at it piecemeal?
> 
> Given Robin's announcement that he's adopting the Koha namespace for
> his accounts rewrite, I think we actually have, or are about to have,
> something more concrete.  Obviously, we could turn this into a
> discussion of adopting a particular framework, but given that those
> discussions have historically not been productive in terms of
> producing much code, I think we're best off just setting some broad
> guidelines, seeing what emerges in upcoming patches, *then* deciding
> if we want to adopt a particular framework.  Is this putting the cart
> before the horse?  Perhaps, but I think we're better off coding some
> prototypes instead of risking endless discussion.

+1

Chris

-- 
Chris Cormack
Catalyst IT Ltd.
+64 4 803 2238
PO Box 11-053, Manners St, Wellington 6142, New Zealand
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: </pipermail/koha-devel/attachments/20110407/a214feb1/attachment-0001.pgp>

From lculber at mdah.state.ms.us  Wed Apr  6 21:11:15 2011
From: lculber at mdah.state.ms.us (Linda Culberson)
Date: Wed, 06 Apr 2011 14:11:15 -0500
Subject: [Koha-devel] Koha - biblioitems
In-Reply-To: <20110406171744.GE8495@rorohiko>
References: <4D9C6164.1090307@mdah.state.ms.us>
	<20110406171744.GE8495@rorohiko>
Message-ID: <4D9CBAD3.8070101@mdah.state.ms.us>

All,
I  couldn't remember where I'd seen the reference to biblioitems being 
merged with biblio, so went back to my notes.  It was in an RFP on the 
wiki.  Now, I see that  the RFC  has been listed as abandoned. Thanks to 
all for your reassurance.

By way of explanation we have done numerous test migrations, checking 
and rechecking that things convert properly, and then fixing in our 
current catalog what doesn't  work in Koha.  We are getting very close, 
and I've be going over my notes to make sure I didn't miss anything. 
Out of over 100,000 biblios, I'm now down to two (that I know of) that 
have serious problems. One of those has multiple 300 tags, although that 
isn't creating its problem.

It helps to know everyone is out there and so willing to help, and I 
appreciate your patience.

Thanks,
Linda

On 4/6/2011 12:17 PM, Chris Cormack wrote:
> * Linda Culberson (lculber at mdah.state.ms.us) wrote:
>> All,
>> In 3.4 and on, I somehow got the impression (dream/nightmare?) that
>> biblioitems was to no longer exist, and that certain MARC fields
>> that are repeatable - particularly the 300, will no longer be.  Did
>> I dream that or is that the case?  If it is true, will Koha have a
>> way to handle those repeatable fields?
>>
>> I would appreciate hearing from someone about this right away, as it
>> may scuttle our whole migration plan.
>
> I can confirm as 3.4 Release Manager that removing repeatable fields was
> not ever planned for the 3.4.x series (or any other release series for
> that matter).
>
> Merging biblio and biblioitems may happen in the future, (not for 3.4.x)
> but it will not ever result in a regression of features like this.
>
> I'm not sure where you got them impression, if you can recall, and
> correct anyone else who has this fear also that would be awesome.
>
> The nice thing about Koha is all development and discussion is done in
> the open, so at any point anyone can see exactly what is going to be in
> 3.4.x. No hidden suprises, no unreleased code, it's all there for
> everyone to see. Which is why I recommend (well I would wouldn't I,
> being Release manager and all) that people run from official Koha
> releases. No hidden nasties.
>
> Chris

-- 
Linda Culberson			lculber at mdah.state.ms.us
Archives and Records Services Division
Ms. Dept. of Archives & History
P. O. Box 571
Jackson, MS 39205-0571
Telephone:  601/576-6873
Facsimile:  601/576-6824


From mjr at phonecoop.coop  Wed Apr  6 21:27:11 2011
From: mjr at phonecoop.coop (MJ Ray)
Date: Wed,  6 Apr 2011 20:27:11 +0100 (BST)
Subject: [Koha-devel] Koha - biblioitems
In-Reply-To: <20110406171744.GE8495@rorohiko>
Message-ID: <20110406192711.5C9FE5025B@nail.towers.org.uk>

Chris Cormack <chrisc at catalyst.net.nz>
> [...] Which is why I recommend (well I would wouldn't I,
> being Release manager and all) that people run from official Koha
> releases. No hidden nasties.

I think you mean run official Koha releases, not run from them! :)
Thanks for making me smile, though!

Regards,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
http://koha-community.org supporter, web and LMS developer, statistician.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire for Koha work http://www.software.coop/products/koha

From chris at bigballofwax.co.nz  Wed Apr  6 21:50:58 2011
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Thu, 7 Apr 2011 07:50:58 +1200
Subject: [Koha-devel] Koha - biblioitems
In-Reply-To: <20110406192711.5C9FE5025B@nail.towers.org.uk>
References: <20110406171744.GE8495@rorohiko>
	<20110406192711.5C9FE5025B@nail.towers.org.uk>
Message-ID: <BANLkTikfrACOjvKMHxjKoGY+ituca2fwmg@mail.gmail.com>

On 7 Apr 2011 07:27, "MJ Ray" <mjr at phonecoop.coop> wrote:
>
> Chris Cormack <chrisc at catalyst.net.nz>
> > [...] Which is why I recommend (well I would wouldn't I,
> > being Release manager and all) that people run from official Koha
> > releases. No hidden nasties.
>
> I think you mean run official Koha releases, not run from them! :)

I do indeed, or run code from official releases, run away from the non
official, or never even released code :)

> Thanks for making me smile, though!
>
I aim to please :)

Chris

> Regards,
> --
> MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
> http://koha-community.org supporter, web and LMS developer, statistician.
> In My Opinion Only: see http://mjr.towers.org.uk/email.html
> Available for hire for Koha work http://www.software.coop/products/koha
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110407/38535a4a/attachment.htm>

From chris at bigballofwax.co.nz  Wed Apr  6 21:52:53 2011
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Thu, 7 Apr 2011 07:52:53 +1200
Subject: [Koha-devel] Koha - biblioitems
Message-ID: <BANLkTi=7=5OLs6Th0j4HZ5Te9A-XL1C4CA@mail.gmail.com>

On 7 Apr 2011 07:11, "Linda Culberson" <lculber at mdah.state.ms.us> wrote:
>
> All,
> I  couldn't remember where I'd seen the reference to biblioitems being
merged with biblio, so went back to my notes.  It was in an RFP on the wiki.
 Now, I see that  the RFC  has been listed as abandoned. Thanks to all for
your reassurance.
>
The merge will take place eventually, but will never ever kill repeatable
fields... even more reassurance. :)

> By way of explanation we have done numerous test migrations, checking and
rechecking that things convert properly, and then fixing in our current
catalog what doesn't  work in Koha.  We are getting very close, and I've be
going over my notes to make sure I didn't miss anything. Out of over 100,000
biblios, I'm now down to two (that I know of) that have serious problems.
One of those has multiple 300 tags, although that isn't creating its
problem.
>
Thats a darn good ratio, pat yourself on the back.

> It helps to know everyone is out there and so willing to help, and I
appreciate your patience.
>
Without users what the rest of us do is worthless, so we definitely
appreciate you too. Especially users who get involved and ask questions and
point out our mistakes, they are invaluable.

Keep up the good work.

Chris

> Thanks,
> Linda
>
>
> On 4/6/2011 12:17 PM, Chris Cormack wrote:
>>
>> * Linda Culberson (lculber at mdah.state.ms.us) wrote:
>>>
>>> All,
>>> In 3.4 and on, I somehow got the impression (dream/nightmare?) that
>>> biblioitems was to no longer exist, and that certain MARC fields
>>> that are repeatable - particularly the 300, will no longer be.  Did
>>> I dream that or is that the case?  If it is true, will Koha have a
>>> way to handle those repeatable fields?
>>>
>>> I would appreciate hearing from someone about this right away, as it
>>> may scuttle our whole migration plan.
>>
>>
>> I can confirm as 3.4 Release Manager that removing repeatable fields was
>> not ever planned for the 3.4.x series (or any other release series for
>> that matter).
>>
>> Merging biblio and biblioitems may happen in the future, (not for 3.4.x)
>> but it will not ever result in a regression of features like this.
>>
>> I'm not sure where you got them impression, if you can recall, and
>> correct anyone else who has this fear also that would be awesome.
>>
>> The nice thing about Koha is all development and discussion is done in
>> the open, so at any point anyone can see exactly what is going to be in
>> 3.4.x. No hidden suprises, no unreleased code, it's all there for
>> everyone to see. Which is why I recommend (well I would wouldn't I,
>> being Release manager and all) that people run from official Koha
>> releases. No hidden nasties.
>>
>> Chris
>
>
> --
> Linda Culberson                 lculber at mdah.state.ms.us
> Archives and Records Services Division
> Ms. Dept. of Archives & History
> P. O. Box 571
> Jackson, MS 39205-0571
> Telephone:  601/576-6873
> Facsimile:  601/576-6824
>
> _______________________________________________
> 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/20110407/4dab5c65/attachment.htm>

From lculber at mdah.state.ms.us  Wed Apr  6 22:02:20 2011
From: lculber at mdah.state.ms.us (Linda Culberson)
Date: Wed, 06 Apr 2011 15:02:20 -0500
Subject: [Koha-devel] Koha It DOES work. Koha: staff client searching by
	card number
Message-ID: <4D9CC6CC.4010002@mdah.state.ms.us>

All,
It does work in check out!!  It is just in searching the patron's that
it doesn't.  Surely, the staff will accept that.  Surely.  I hope.

I apologize for my panic. We'll just use the name when searching for
patrons and continue with our current procedure when checking out items.

Linda

On 4/6/2011 1:46 PM, Linda Culberson wrote:
> All,
> I tested the various suggestions. On our version, 3.02.02.003, putting
> an asterisk in front of the number made no difference in the result. A
> search of my number pulled up 1540 results. Adding the first letter of
> my last name cut it down to 552. Using the first two letters did cut it
> down to 26. Using my number and my full first name was 28 (mainly
> because it got those "Belinda" and "Malinda" and "Melinda" etc.)
>
> A coworker's results were worse. Her card number pulled up 6358 results,
> adding the first letter of her last name cut it to 2837, and the first
> two letters to 249. Using her number and her full last name (which is
> admittedly a common name - almost as bad as "Linda") got it down to 17.
>
> So basically, for us, searching by cardnumber doesn't really seem to
> work, and so our checkout procedure will have to be reworked. We had
> been swiping the patron's card and then the item's barcode. This won't
> work in Koha, apparently.
>
> Thanks to all who answered.
>
> Linda
>
> On 1:59 PM, Tim McMahon wrote:
>> In the staff interface, you can add an asterisk * before the barcode to
>> get the exact item. Something like *36431 instead of just 36431.
>>
>> On 04/06/2011 11:10 AM, Hal Bright wrote:
>>> In addition, is there a way to force an exact search in the materials
>>> catalog?
>>>
>>> -----Original Message-----
>>> From: koha-bounces at lists.katipo.co.nz
>>> [mailto:koha-bounces at lists.katipo.co.nz] On Behalf Of Linda Culberson
>>> Sent: Tuesday, April 05, 2011 5:18 PM
>>> To: koha
>>> Subject: [Koha] Koha: staff client searching by card number
>>>
>>> Everyone,
>>> Another newbie question: Is there a way in the staff client to search by
>>> the exact card number? It seems to be using wild cards before and
>>> after. For example, a search for "643" pulls up 1643", "36431" and
>>> everything else that contains "643" with 643 in the list. We want it
>>> to pull up only the one 643. I'm assuming it isn't acceptable to
>>> change member.pl?
>>>
>>> Thanks in advance.
>>>
>>
>

-- 
Linda Culberson			lculber at mdah.state.ms.us
Archives and Records Services Division
Ms. Dept. of Archives & History
P. O. Box 571
Jackson, MS 39205-0571
Telephone:  601/576-6873
Facsimile:  601/576-6824


From ian.walls at bywatersolutions.com  Wed Apr  6 23:55:28 2011
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Wed, 6 Apr 2011 17:55:28 -0400
Subject: [Koha-devel] The Many Faces of CheckReserves
Message-ID: <BANLkTi=k3YZG7Qb8dBWfP1cZFYuVq3ct_A@mail.gmail.com>

Fellow Kohackers,


I'll state this boldly and up front:  C4::Reserves::CheckReserves must die.
Read the POD.  It's purpose is unclear, and without a clear purpose, how can
we expect to make coherent use of it?  You feed it an itemnumber (or a
barcode), and it gives you a status and a reserve hash.  It's utilized in 11
places in Koha, each to a different end:

C4::Search::searchResults  - to get determine whether each item is "waiting"
for someone or not

C4::XSLT::buildKohaItemsNamespace  - again, to indicate if the item is
"waiting" or not

C4::Items::GetItemsInfo  -  to populate the count_reserves key in the
returned value

C4::Reserves::GetOtherReserves - returns whether to transfer the item (and
transfers it) if a hold for the passed item exists, and the borrower who
it's meant for

C4::Circulation::transferbook - tell the routine to 'dotransfer' if there
there is a hold and holds aren't being ignored

C4::Circulation::CanBookBeIssued  - indicate that the title is on hold for
someone else, waiting or not

C4::Circulation::AddIssue - marks the reserve as filled and advances the
next, or cancels the hold if told

C4::Circulation::AddReturn - returns the next hold

C4::Circulation::CanBookBeRenewed - block renewals if there is a hold

circ/circulation.pl - add the "renew_error" to the issues table

opac/opac-user.pl - add 'reserved' note to the issued items table


What functions are needed here?

We need a way to indicate that a particular item should be used to fill a
pending hold.  (this will be subject to many rules, and in some cases can
block issuing, transfer or renewal)

We need a mechanism to fill a hold using a particular item, marking it as
'committed', and handling the rest of the holds queue as appropriate

We need some way to indicate that a particular item has been committed to
fill a hold.

That looks like three subroutines to me:

$reservenumber = ReserveItemCanFill($itemnumber)
$messages = FillReserve($reserve, $itemnumber)
$reservenumber = IsItemWaitingForReserve($itemnumber)

The last could even be done as another field in the items table, onhold,
like the onloan field, and populated with the expiration date of the hold.

Yes, this depends on there being a primary key to the reserves table, but
that's in the works, and will open many doors for us once it's in place.


Thoughts?  Comments?  Counterarguments?


-Ian
-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
ALA Booth 732
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110406/b2601a17/attachment-0001.htm>

From robin at catalyst.net.nz  Thu Apr  7 01:11:06 2011
From: robin at catalyst.net.nz (Robin Sheat)
Date: Thu, 07 Apr 2011 11:11:06 +1200
Subject: [Koha-devel] Restructuring C4
In-Reply-To: <BANLkTikb-tpAaEnwGb9sYANgt5c=U2uu-g@mail.gmail.com>
References: <AANLkTimjYEY8R8ROiFUjLUGVB-SsMJPtANrchc2fro6+@mail.gmail.com>
	<AANLkTi=PN4oPvzpMkm=2JTXh89YPtq+wSieS9ixLgt6T@mail.gmail.com>
	<1302063100.23346.17.camel@zarathud>
	<BANLkTimfKGm=Y=KfdKqP0=SVNrj_WdnV3A@mail.gmail.com>
	<BANLkTinMEgH1SKYjN_S2BGEXqYVxu99iQw@mail.gmail.com>
	<BANLkTi=h=UxXU+cf+3sT_LgL=ZXxZqO9MA@mail.gmail.com>
	<BANLkTi=FMwiz1JbZ_hQGrs6+v6tXkGu2xw@mail.gmail.com>
	<BANLkTikb-tpAaEnwGb9sYANgt5c=U2uu-g@mail.gmail.com>
Message-ID: <1302131466.8907.1.camel@zarathud>

Galen Charlton schreef op wo 06-04-2011 om 13:52 [-0400]:
> Perhaps, but I think we're better off coding some
> prototypes instead of risking endless discussion. 

Definitely. Additionally, if we change our minds, refactoring three or
four modules isn't a big task at all.

-- 
Robin Sheat
Catalyst IT Ltd.
? +64 4 803 2204
GPG: 5957 6D23 8B16 EFAB FEF8  7175 14D3 6485 A99C EB6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20110407/b7fe4b01/attachment.pgp>

From robin at catalyst.net.nz  Thu Apr  7 01:22:10 2011
From: robin at catalyst.net.nz (Robin Sheat)
Date: Thu, 07 Apr 2011 11:22:10 +1200
Subject: [Koha-devel] Koha It DOES work. Koha: staff client searching by
 card number
In-Reply-To: <4D9CC6CC.4010002@mdah.state.ms.us>
References: <4D9CC6CC.4010002@mdah.state.ms.us>
Message-ID: <1302132130.8907.3.camel@zarathud>

Linda Culberson schreef op wo 06-04-2011 om 15:02 [-0500]:
> It does work in check out!!  It is just in searching the patron's that
> it doesn't.  Surely, the staff will accept that.  Surely.  I hope. 

A patch along the lines of "if the borrower search value doesn't contain
a space, try a barcode lookup first" could be worthwhile. It'd be
probably quite beneficial.

-- 
Robin Sheat
Catalyst IT Ltd.
? +64 4 803 2204
GPG: 5957 6D23 8B16 EFAB FEF8  7175 14D3 6485 A99C EB6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20110407/3ac387d8/attachment.pgp>

From kmkale at anantcorp.com  Thu Apr  7 06:37:25 2011
From: kmkale at anantcorp.com (Koustubha Kale)
Date: Thu, 7 Apr 2011 10:07:25 +0530
Subject: [Koha-devel] Next irc meeting of Kohacon11 volunteers is on 8th
	April 2011 at 6.00UTC
Message-ID: <BANLkTim2xhpUJbVdws6LaSQE0+yvty1Ovw@mail.gmail.com>

Hi All,
Gentle reminder : Next irc meeting of Kohacon11 volunteers is on 8th
April 2011 at 6.00UTC
Conversions to your local time:
http://www.timeanddate.com/worldclock/fixedtime.html?year=2011&month=4&day=8&hour=06&min=0&sec=0

Agenda at : http://wiki.koha-community.org/wiki/KohaCon11_Volunteers#Agenda_2
Feel free to add to it and see you there..


Regards,
Koustubha Kale
Anant Corporation

Contact Details :
Address? : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes
Naka, Thane (w),
? ? ? ? ??? ? ? Maharashtra, India, Pin : 400601.
TeleFax? : +91-22-21720108, +91-22-21720109
Mobile? ?? : +919820715876
Website? : http://www.anantcorp.com
Blog : http://www.anantcorp.com/blog/?author=2

From claire.hernandez at biblibre.com  Thu Apr  7 09:45:57 2011
From: claire.hernandez at biblibre.com (Claire Hernandez)
Date: Thu, 07 Apr 2011 09:45:57 +0200
Subject: [Koha-devel] Hackfest - 5579 remove items from marcxml
Message-ID: <4D9D6BB5.6040304@biblibre.com>

Hi,

As I said, I setup an unimarc install here: 
http://koha.qa.testing.biblibre.com 
<http://koha.qa.testing.biblibre.com/> http://qa.testing.biblibre.com 
<http://koha.qa.testing.biblibre.com/> with patches related to 5579 ticket.

- The database is the same as http://koha.master.testing.biblibre.com 
<http://koha.qa.testing.biblibre.com/>
- I played the migration script on qa setup 
(misc/maintenance/remove_items_from_biblioitems.pl)
- Rebuild zebra and launch zebra

Please, have a look. We found only one bug in "marcxml export" where we 
would like to see items in export. Matts tries to paitch it this morning.

We had a look on
- items crud operations
- indexing, searching
- circulation basis
- batch modification
- migration scripts
without founding mistakes but it can be not exhaustive.

These modifications needs to be tested with Marc21 too.

Thanks,
Claire.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110407/9c94ffe6/attachment.htm>

From gmcharlt at gmail.com  Thu Apr  7 15:01:34 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Thu, 7 Apr 2011 09:01:34 -0400
Subject: [Koha-devel] Hackfest - 5579 remove items from marcxml
In-Reply-To: <4D9D6BB5.6040304@biblibre.com>
References: <4D9D6BB5.6040304@biblibre.com>
Message-ID: <BANLkTi=6dTTZfJFU37Qy8VmDCPWtNqWnNw@mail.gmail.com>

Hi,

2011/4/7 Claire Hernandez <claire.hernandez at biblibre.com>:
> We had a look on
> - items crud operations
> - indexing, searching
> - circulation basis
> - batch modification
> - migration scripts
> without founding mistakes but it can be not exhaustive.

Thanks for testing.  One area that I had tested but which I feel needs
more testing is serials maintenance and item creation during serials
receiving.

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From lculber at mdah.state.ms.us  Thu Apr  7 15:23:58 2011
From: lculber at mdah.state.ms.us (Linda Culberson)
Date: Thu, 07 Apr 2011 08:23:58 -0500
Subject: [Koha-devel] Koha - Bug 6113 enhancement to keep previous ids in
	bulkmarcimport.pl
Message-ID: <4D9DBAEE.8090600@mdah.state.ms.us>

All,
I have submitted Bug 6113 to bugzilla for a sponsored enhancement.
In communicating with other Koha users, we feel that it would be highly 
beneficial Koha  was enhanced to allow the  library to keep its current 
ids  when loading both bibliographic and authority records. Some of us 
have used our current control numbers in the 76X-78X fields to link 
records.  In our institution, we have also used that number in external 
databases and on other websites to link additional information back to 
the related catalog record. The documentation within bulkmarcimport.pl 
also needs to be amended to better explain the use of the various 
options (for example:  x, y, k, idmap and keepid) since some of us tried 
to use those to keep our ids without success.

Thank you.
-- 
Linda Culberson			lculber at mdah.state.ms.us
Archives and Records Services Division
Ms. Dept. of Archives & History
P. O. Box 571
Jackson, MS 39205-0571
Telephone:  601/576-6873
Facsimile:  601/576-6824


From matthias.meusburger at biblibre.com  Thu Apr  7 15:42:28 2011
From: matthias.meusburger at biblibre.com (Matthias Meusburger)
Date: Thu, 07 Apr 2011 15:42:28 +0200
Subject: [Koha-devel] Hackfest - 5579 remove items from marcxml
In-Reply-To: <4D9D6BB5.6040304@biblibre.com>
References: <4D9D6BB5.6040304@biblibre.com>
Message-ID: <4D9DBF44.1010403@biblibre.com>

Hi,

I applied the attachment :

http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=3780

to this install, so exports from basket, lists and records should now 
behave correctly (ie : include items)

Matthias Meusburger


Le 07/04/2011 09:45, Claire Hernandez a ?crit :
> Hi,
>
> As I said, I setup an unimarc install here:
> http://koha.qa.testing.biblibre.com
> <http://koha.qa.testing.biblibre.com/> http://qa.testing.biblibre.com
> <http://koha.qa.testing.biblibre.com/> with patches related to 5579 ticket.
>
> - The database is the same as http://koha.master.testing.biblibre.com
> <http://koha.qa.testing.biblibre.com/>
> - I played the migration script on qa setup
> (misc/maintenance/remove_items_from_biblioitems.pl)
> - Rebuild zebra and launch zebra
>
> Please, have a look. We found only one bug in "marcxml export" where we
> would like to see items in export. Matts tries to paitch it this morning.
>
> We had a look on
> - items crud operations
> - indexing, searching
> - circulation basis
> - batch modification
> - migration scripts
> without founding mistakes but it can be not exhaustive.
>
> These modifications needs to be tested with Marc21 too.
>
> Thanks,
> Claire.
>
>
>
> _______________________________________________
> 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 oleonard at myacpl.org  Thu Apr  7 15:53:21 2011
From: oleonard at myacpl.org (Owen Leonard)
Date: Thu, 7 Apr 2011 09:53:21 -0400
Subject: [Koha-devel] Warnings about Koha to MARC links
In-Reply-To: <AANLkTikL7O-f_c1r8JBLb8NPZiJ08TOkvQyx5bF3gbZS@mail.gmail.com>
References: <AANLkTikL7O-f_c1r8JBLb8NPZiJ08TOkvQyx5bF3gbZS@mail.gmail.com>
Message-ID: <BANLkTikv8TQH0qGFdoLaR71e31xxQ0K_hA@mail.gmail.com>

> Which is correct? I would
> like to remove the warning from marctagstructure.pl since it pertains
> directly to subfield editing, but I want to make sure the note on
> marc_subfields_structure.pl is accurate.

Thanks to Galen for the answer, on IRC:

<gmcharlt>	oleonard: the former is correct - i.e., you can change it,
but then must run batchRebuildBiblioTables.pl
<oleonard>	Do you think it would be appropriate to move that warning
to marc_subfields_structure.pl ?
<gmcharlt>	oleonard: yes

This issue is now recorded as Bug 6114 and a patch has been submitted:

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

  -- Owen

-- 
Web Developer
Athens County Public Libraries
http://www.myacpl.org

From gmcharlt at gmail.com  Thu Apr  7 16:12:31 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Thu, 7 Apr 2011 10:12:31 -0400
Subject: [Koha-devel] Hackfest - 5579 remove items from marcxml
In-Reply-To: <4D9DBF44.1010403@biblibre.com>
References: <4D9D6BB5.6040304@biblibre.com>
	<4D9DBF44.1010403@biblibre.com>
Message-ID: <BANLkTikitcGKW_XNvw68XBom-cdvhq=0JQ@mail.gmail.com>

Hi,

On Thu, Apr 7, 2011 at 9:42 AM, Matthias Meusburger
<matthias.meusburger at biblibre.com> wrote:
> I applied the attachment :
>
> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=3780
>
> to this install, so exports from basket, lists and records should now behave
> correctly (ie : include items)

Looks good on eyeball. I'll test and sign off if all runs well.

Are you at the point where you're reading to sign off on the initial
patch series?

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From paul.poulain at biblibre.com  Thu Apr  7 17:01:25 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 07 Apr 2011 17:01:25 +0200
Subject: [Koha-devel] Sharing bugzilla queries
Message-ID: <4D9DD1C5.7@biblibre.com>

Hello world,

if you login on bugzilla, then Click on Preferences, then Saved
searches, you'll find the queries you've saved, but also some usefull
shared queries : Needs signoff, Patch pushed, signed off, Does not
apply, Failed QA
Just check the checkbox and you'll get a link to this query on the
footer of your bugzilla entry.

Another hint: if you don't like bugzilla going to your next bug
everytime you validate a form, choose what you want on Bugzilla >
Preferences > After changing a bug

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


From arosello at uci.cu  Thu Apr  7 17:24:41 2011
From: arosello at uci.cu (Adnier Rosello Carrazana)
Date: Thu, 7 Apr 2011 11:24:41 -0400 (CDT)
Subject: [Koha-devel] problem with the main template in tools page
In-Reply-To: <1657938423.11706161302189758382.JavaMail.root@ucimail4.uci.cu>
Message-ID: <1214023748.11707421302189881449.JavaMail.root@ucimail4.uci.cu>

I have this problem in the template "tools-home.tmpl":

the content of this template is inside of labels <!--TMPL_IF-->, for example:
<!-- TMPL_IF NAME="CAN_user_tools_edit_news" -->
      <dt><a href="/cgi-bin/koha/tools/koha-news.pl">Noticias</a></dt>
      <dd>Escriba novedades para el OPAC y la interfaz administrativa</dd>
<!-- /TMPL_IF -->

but  this content doesn't show,  i don't find where the variables are declared (in this case "CAN_user_tools_edit_news"), if anyone can help me I'll be grateful
  

From gmcharlt at gmail.com  Thu Apr  7 17:30:39 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Thu, 7 Apr 2011 11:30:39 -0400
Subject: [Koha-devel] problem with the main template in tools page
In-Reply-To: <1214023748.11707421302189881449.JavaMail.root@ucimail4.uci.cu>
References: <1657938423.11706161302189758382.JavaMail.root@ucimail4.uci.cu>
	<1214023748.11707421302189881449.JavaMail.root@ucimail4.uci.cu>
Message-ID: <BANLkTinM3Jc_dYE7cHT9GubHMKmicrFVFg@mail.gmail.com>

Hi,

On Thu, Apr 7, 2011 at 11:24 AM, Adnier Rosello Carrazana
<arosello at uci.cu> wrote:
> I have this problem in the template "tools-home.tmpl":
>
> the content of this template is inside of labels <!--TMPL_IF-->, for example:
> <!-- TMPL_IF NAME="CAN_user_tools_edit_news" -->
> ? ? ?<dt><a href="/cgi-bin/koha/tools/koha-news.pl">Noticias</a></dt>
> ? ? ?<dd>Escriba novedades para el OPAC y la interfaz administrativa</dd>
> <!-- /TMPL_IF -->
>
> but ?this content doesn't show, ?i don't find where the variables are declared (in this case "CAN_user_tools_edit_news"), if anyone can help me I'll be grateful

Such template variables are set by the user permissions system.  In
this case, it looks like the staff user you're trying to use doesn't
have the tools/edit_news permission.  If you grant that permission,
the link should show up.

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From tomascohen at gmail.com  Thu Apr  7 17:31:25 2011
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Thu, 7 Apr 2011 12:31:25 -0300
Subject: [Koha-devel] Sharing bugzilla queries
In-Reply-To: <4D9DD1C5.7@biblibre.com>
References: <4D9DD1C5.7@biblibre.com>
Message-ID: <BANLkTimjRCe5XHVYF-67wxvZJpUZOZWH6w@mail.gmail.com>

On Thu, Apr 7, 2011 at 12:01 PM, Paul Poulain <paul.poulain at biblibre.com> wrote:
> Hello world,
>
> if you login on bugzilla, then Click on Preferences, then Saved
> searches, you'll find the queries you've saved, but also some usefull
> shared queries : Needs signoff, Patch pushed, signed off, Does not
> apply, Failed QA
> Just check the checkbox and you'll get a link to this query on the
> footer of your bugzilla entry.

:-D

> Another hint: if you don't like bugzilla going to your next bug
> everytime you validate a form, choose what you want on Bugzilla >
> Preferences > After changing a bug

This - is - unbelivable
thanks!
To+

From claire.hernandez at biblibre.com  Thu Apr  7 17:33:40 2011
From: claire.hernandez at biblibre.com (Claire Hernandez)
Date: Thu, 07 Apr 2011 17:33:40 +0200
Subject: [Koha-devel] Hackfest - 5579 remove items from marcxml
In-Reply-To: <BANLkTikitcGKW_XNvw68XBom-cdvhq=0JQ@mail.gmail.com>
References: <4D9D6BB5.6040304@biblibre.com>	<4D9DBF44.1010403@biblibre.com>
	<BANLkTikitcGKW_XNvw68XBom-cdvhq=0JQ@mail.gmail.com>
Message-ID: <4D9DD954.5020905@biblibre.com>

On 07/04/2011 16:12, Galen Charlton wrote:
> Hi,
>
> On Thu, Apr 7, 2011 at 9:42 AM, Matthias Meusburger
> <matthias.meusburger at biblibre.com>  wrote:
>> I applied the attachment :
>>
>> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=3780
>>
>> to this install, so exports from basket, lists and records should now behave
>> correctly (ie : include items)
> Looks good on eyeball. I'll test and sign off if all runs well.
>
> Are you at the point where you're reading to sign off on the initial
> patch series?
>
> Regards,
>
> Galen
Hi Galen,

We spend time on testing between yesterday and today. Functional people 
take time too. I can say I am at the point I could sign off the patches 
(I attached yours on the ticket). Maybe a second or third sign off would 
be great too.

I don't know what does mean  "serials maintenance" but "item creation 
during serials receiving" have been tested. Thanks for asking.

Claire.

From colin.campbell at ptfs-europe.com  Thu Apr  7 17:34:58 2011
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Thu, 07 Apr 2011 16:34:58 +0100
Subject: [Koha-devel] problem with the main template in tools page
In-Reply-To: <1214023748.11707421302189881449.JavaMail.root@ucimail4.uci.cu>
References: <1214023748.11707421302189881449.JavaMail.root@ucimail4.uci.cu>
Message-ID: <4D9DD9A2.2050806@ptfs-europe.com>

On 07/04/11 16:24, Adnier Rosello Carrazana wrote:
> I have this problem in the template "tools-home.tmpl":
> 
> the content of this template is inside of labels <!--TMPL_IF-->, for example:
> <!-- TMPL_IF NAME="CAN_user_tools_edit_news" -->
>       <dt><a href="/cgi-bin/koha/tools/koha-news.pl">Noticias</a></dt>
>       <dd>Escriba novedades para el OPAC y la interfaz administrativa</dd>
> <!-- /TMPL_IF -->
> 
> but  this content doesn't show,  i don't find where the variables are declared (in this case "CAN_user_tools_edit_news"), if anyone can help me I'll be grateful
This is a granular permission on the patron screen under the more tab is
the option Set Permissions, in there you will see a group of tools
permissions one of which is 'edit_news' you can give the member of staff
all the tools permission (just tick tools) or individual permissions in
the group

Cheers
Colin

-- 
Colin Campbell
Chief Software Engineer,
PTFS Europe Limited
Content Management and Library Solutions
+44 (0) 845 557 5634 (phone)
+44 (0) 7759 633626  (mobile)
colin.campbell at ptfs-europe.com
skype: colin_campbell2

http://www.ptfs-europe.com

From mdhafen at tech.washk12.org  Thu Apr  7 17:50:50 2011
From: mdhafen at tech.washk12.org (Mike Hafen)
Date: Thu, 7 Apr 2011 09:50:50 -0600
Subject: [Koha-devel] Technical question
In-Reply-To: <89697E806D4E44BF9CCE9406A75F77B4@CharlPC>
References: <89697E806D4E44BF9CCE9406A75F77B4@CharlPC>
Message-ID: <BANLkTinBN73mHRRW-STjN0ab-bh+vvMgnQ@mail.gmail.com>

The Item Type in Koha 3 has been moved to the items table, with the Item
Type in the biblioitems table being a default for new items.

It wouldn't be difficult to make a command line script to copy the Item Type
from the biblioitems table to the items table, that may be the best way to
go in this case.  It looks like maintenance/touch_all_items.pl would be a
good place to start on such a script.

2011/4/6 Charl <charl at prograbiz.com>

>  Good day
>
> I need advice please. I have converted a Koha installation from 2 to Koha
> 3.
> Now there is a "syncronization" problem between the items table and the
> marc record in bibioitems.
>
> To make a long story short, the itemtype appears in the marc record, but
> not in the items table.
> Is there a procedure how to syncronize those 2 "fields"?
>
> Thanks for any advice!
>
>
>
> _______________________________________________
> 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/20110407/1c0bf79d/attachment.htm>

From charl at prograbiz.com  Thu Apr  7 18:09:25 2011
From: charl at prograbiz.com (Charl)
Date: Thu, 7 Apr 2011 18:09:25 +0200
Subject: [Koha-devel] Technical question
In-Reply-To: <BANLkTinBN73mHRRW-STjN0ab-bh+vvMgnQ@mail.gmail.com>
References: <89697E806D4E44BF9CCE9406A75F77B4@CharlPC>
	<BANLkTinBN73mHRRW-STjN0ab-bh+vvMgnQ@mail.gmail.com>
Message-ID: <C515D07A039E4A46B0FA6DD9DE0165D3@CharlPC>

?Thank you Mike

This should help me sort out this issue.

Another issue that I am trying to sort out:
Alpha characters appear after the barcode in both the marc and item record.

How should I go about removing those alpha characters as a batch procedure?
The item record is not a problem, but I am not sure how to edit the barcode in the marc record (biblioitems).

Thanks again for your help.

----- Original Message ----- 
  From: Mike Hafen 
  To: Charl 
  Cc: koha-devel at lists.koha-community.org 
  Sent: Thursday, April 07, 2011 5:50 PM
  Subject: Re: [Koha-devel] Technical question


  The Item Type in Koha 3 has been moved to the items table, with the Item Type in the biblioitems table being a default for new items.

  It wouldn't be difficult to make a command line script to copy the Item Type from the biblioitems table to the items table, that may be the best way to go in this case.  It looks like maintenance/touch_all_items.pl would be a good place to start on such a script.


  2011/4/6 Charl <charl at prograbiz.com>

    Good day

    I need advice please. I have converted a Koha installation from 2 to Koha 3.
    Now there is a "syncronization" problem between the items table and the marc record in bibioitems.

    To make a long story short, the itemtype appears in the marc record, but not in the items table.
    Is there a procedure how to syncronize those 2 "fields"?

    Thanks for any advice!



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





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



  No virus found in this incoming message.
  Checked by AVG - www.avg.com 
  Version: 8.5.449 / Virus Database: 271.1.1/3557 - Release Date: 04/07/11 10:01:00
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110407/d33d8915/attachment.htm>

From mdhafen at tech.washk12.org  Thu Apr  7 18:19:13 2011
From: mdhafen at tech.washk12.org (Mike Hafen)
Date: Thu, 7 Apr 2011 10:19:13 -0600
Subject: [Koha-devel] Technical question
In-Reply-To: <BANLkTim9-uYRMV14cSjLXU9byV4bykoTJw@mail.gmail.com>
References: <89697E806D4E44BF9CCE9406A75F77B4@CharlPC>
	<BANLkTinBN73mHRRW-STjN0ab-bh+vvMgnQ@mail.gmail.com>
	<C515D07A039E4A46B0FA6DD9DE0165D3@CharlPC>
	<BANLkTim9-uYRMV14cSjLXU9byV4bykoTJw@mail.gmail.com>
Message-ID: <BANLkTimjGby3T0L2Kcy6y1eMj02sxNgrLw@mail.gmail.com>

This is why I suggested modifying the touch_all_items script.  It uses the
C4::Items::ModItem subroutine which changes the database and the marc
records stored in the biblioitems table.  Editing these directly is
difficult at best, and nearly impossible in my opinion.

Along with modifying a copy of touch_all_items for your item type
conversion, you could also add code to strip the alpha characters from the
end of the barcode.  Do all the work in one go.  You'll have to change the
SQL in that script, but you will have to do that anyway to update the item
type.


On Thu, Apr 7, 2011 at 10:09 AM, Charl <charl at prograbiz.com> wrote:

>  Thank you Mike
>
> This should help me sort out this issue.
>
> Another issue that I am trying to sort out:
> Alpha characters appear after the barcode in both the marc and item record.
>
> How should I go about removing those alpha characters as a batch procedure?
> The item record is not a problem, but I am not sure how to edit the barcode
> in the marc record (biblioitems).
>
> Thanks again for your help.
>
> ----- Original Message -----
>
> *From:* Mike Hafen <mdhafen at tech.washk12.org>
> *To:* Charl <charl at prograbiz.com>
> *Cc:* koha-devel at lists.koha-community.org
> *Sent:* Thursday, April 07, 2011 5:50 PM
> *Subject:* Re: [Koha-devel] Technical question
>
> The Item Type in Koha 3 has been moved to the items table, with the Item
> Type in the biblioitems table being a default for new items.
>
> It wouldn't be difficult to make a command line script to copy the Item
> Type from the biblioitems table to the items table, that may be the best way
> to go in this case.  It looks like maintenance/touch_all_items.pl would be
> a good place to start on such a script.
>
> 2011/4/6 Charl <charl at prograbiz.com>
>
>>  Good day
>>
>> I need advice please. I have converted a Koha installation from 2 to Koha
>> 3.
>> Now there is a "syncronization" problem between the items table and the
>> marc record in bibioitems.
>>
>> To make a long story short, the itemtype appears in the marc record, but
>> not in the items table.
>> Is there a procedure how to syncronize those 2 "fields"?
>>
>> Thanks for any advice!
>>
>>
>>
>> _______________________________________________
>> 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/
>>
>
>  ------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.449 / Virus Database: 271.1.1/3557 - Release Date: 04/07/11
> 10:01:00
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110407/dfb1c68c/attachment.htm>

From cnighswonger at foundations.edu  Thu Apr  7 19:03:31 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Thu, 7 Apr 2011 13:03:31 -0400
Subject: [Koha-devel] Technical question
In-Reply-To: <89697E806D4E44BF9CCE9406A75F77B4@CharlPC>
References: <89697E806D4E44BF9CCE9406A75F77B4@CharlPC>
Message-ID: <BANLkTinAyEwGBRj-zPuH+QxUf+imK3-6eQ@mail.gmail.com>

 2011/4/6 Charl <charl at prograbiz.com>

>  Good day
>
> I need advice please. I have converted a Koha installation from 2 to Koha
> 3.
> Now there is a "syncronization" problem between the items table and the
> marc record in bibioitems.
>
> To make a long story short, the itemtype appears in the marc record, but
> not in the items table.
> Is there a procedure how to syncronize those 2 "fields"?
>
> Thanks for any advice!
>
>
>

I think you are looking for misc/maintenance/sync_items_in_marc_bib.pl

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

From cnighswonger at foundations.edu  Thu Apr  7 19:04:51 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Thu, 7 Apr 2011 13:04:51 -0400
Subject: [Koha-devel] Technical question
In-Reply-To: <BANLkTinAyEwGBRj-zPuH+QxUf+imK3-6eQ@mail.gmail.com>
References: <89697E806D4E44BF9CCE9406A75F77B4@CharlPC>
	<BANLkTinAyEwGBRj-zPuH+QxUf+imK3-6eQ@mail.gmail.com>
Message-ID: <BANLkTik07DYO3foWvHB_HBWzBZA49ACnOA@mail.gmail.com>

On Thu, Apr 7, 2011 at 1:03 PM, Chris Nighswonger <
cnighswonger at foundations.edu> wrote:

> 2011/4/6 Charl <charl at prograbiz.com>
>
>>  Good day
>>
>> I need advice please. I have converted a Koha installation from 2 to Koha
>> 3.
>> Now there is a "syncronization" problem between the items table and the
>> marc record in bibioitems.
>>
>> To make a long story short, the itemtype appears in the marc record, but
>> not in the items table.
>> Is there a procedure how to syncronize those 2 "fields"?
>>
>> Thanks for any advice!
>>
>>
>>
>
> I think you are looking for misc/maintenance/sync_items_in_marc_bib.pl
>

Actually, nix that.... I missed the fact that you need to go the other way.

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

From mdhafen at tech.washk12.org  Thu Apr  7 19:27:48 2011
From: mdhafen at tech.washk12.org (Mike Hafen)
Date: Thu, 7 Apr 2011 11:27:48 -0600
Subject: [Koha-devel] Technical question
In-Reply-To: <BANLkTinAyEwGBRj-zPuH+QxUf+imK3-6eQ@mail.gmail.com>
References: <89697E806D4E44BF9CCE9406A75F77B4@CharlPC>
	<BANLkTinAyEwGBRj-zPuH+QxUf+imK3-6eQ@mail.gmail.com>
Message-ID: <BANLkTim4yngyKctPpSnCuSwt=Yroa+oRAA@mail.gmail.com>

Yeah, that's a good option too.  Make the changes to the items table in the
database, and that script will take care of the marc records.

Thanks Chris.

2011/4/7 Chris Nighswonger <cnighswonger at foundations.edu>

> 2011/4/6 Charl <charl at prograbiz.com>
>
>>  Good day
>>
>> I need advice please. I have converted a Koha installation from 2 to Koha
>> 3.
>> Now there is a "syncronization" problem between the items table and the
>> marc record in bibioitems.
>>
>> To make a long story short, the itemtype appears in the marc record, but
>> not in the items table.
>> Is there a procedure how to syncronize those 2 "fields"?
>>
>> Thanks for any advice!
>>
>>
>>
>
> I think you are looking for misc/maintenance/sync_items_in_marc_bib.pl
>
> Kind Regards,
> Chris
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110407/7de9c73e/attachment.htm>

From conan at lugmen.org.ar  Thu Apr  7 19:40:35 2011
From: conan at lugmen.org.ar (Fernando Canizo)
Date: Thu, 07 Apr 2011 14:40:35 -0300
Subject: [Koha-devel] conan's introduction
Message-ID: <4D9DF713.4020003@lugmen.org.ar>

Hi everybody, I'm Fernando Canizo, aka conan, from Argentina. Some might 
have see me semi-lurking at #koha irc channel.

I've been hired by the SID (http://sid.uncu.edu.ar/) which depends on 
UNCuyo (http://www.uncu.edu.ar/) to implement koha for the 22 libraries 
dependent on UNCuyo and to provide modifications requested by librarians 
as they come up, with the idea in mind of trying to bring them upstream 
if they worth it.

I'm still shaking from the shock of meeting koha, MARC21, and other 
behemoths alike, also I'm relearning Perl, language I swore to forget 
some years ago.

I haven't introduced myself yet because I'm currently dealing with 
implementation, and I think I'll be on that for some time still.

However I'm starting to build a list of desired changes for koha so I 
might bother you with questions now and then.

-- 
Fernando Canizo (a.k.a. conan) - http://conan.muriandre.com/
GCS d? s:+ a C++ P--- L++++ E--- W+++ w--- M-- PE-- !tv b+++ h---- y+++

From anne-lena.westrum at kul.oslo.kommune.no  Thu Apr  7 15:17:43 2011
From: anne-lena.westrum at kul.oslo.kommune.no (Anne-Lena Westrum)
Date: Thu, 7 Apr 2011 15:17:43 +0200
Subject: [Koha-devel] Generating transactions
Message-ID: <4D9DB977.5090505@kul.oslo.kommune.no>

Dearest Koha developers!

We have recently started a process of testing and evaluating Koha in the 
perspective of a fairly large public library, with a number of different 
branches and departments. This has proven to be a fairly timeconsuming 
task, as we - amongst other things - need to test all the modules and 
compare it to the functionality of our current ILS :)

After importing our records (Normarc), we need to do a demo of the 
different modules. Thus we are in desperate need of a script to generate 
users (approx 500.000) and transactions (3-4 millions) over a period of 
time (4-5 years).

We have had no luck searching for a script like this. Can someone help 
point us in the right direction?

Thank you! :)

Regards,
Anne-Lena
--
Oslo Public Library

From chris at bigballofwax.co.nz  Thu Apr  7 22:56:00 2011
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Fri, 8 Apr 2011 08:56:00 +1200
Subject: [Koha-devel] Generating transactions
In-Reply-To: <4D9DB977.5090505@kul.oslo.kommune.no>
References: <4D9DB977.5090505@kul.oslo.kommune.no>
Message-ID: <BANLkTi=iBfb3GxiM1XouhJGQ37fcREeB3Q@mail.gmail.com>

On 8 April 2011 01:17, Anne-Lena Westrum
<anne-lena.westrum at kul.oslo.kommune.no> wrote:
> Dearest Koha developers!
>
> We have recently started a process of testing and evaluating Koha in the
> perspective of a fairly large public library, with a number of different
> branches and departments. This has proven to be a fairly timeconsuming
> task, as we - amongst other things - need to test all the modules and
> compare it to the functionality of our current ILS :)
>
> After importing our records (Normarc), we need to do a demo of the
> different modules. Thus we are in desperate need of a script to generate
> users (approx 500.000) and transactions (3-4 millions) over a period of
> time (4-5 years).
>
> We have had no luck searching for a script like this. Can someone help
> point us in the right direction?
>
Hi Anne-Lenna

Magnus our NORMARC export (he wrote all the NORMARC support for Koha
and is from Norway also) is currently trying to sleep of a cold in
Marseille. He has been there for the week with Koha developers from
all around Europe working on a code sprint leading up to the release
of Koha 3.4.0 on April 22 (which will have native NORMARC support).

I am sure he will answer when he wakes up :) As far as I know such a
script does not exist. I would offer to write one, as it sounds like
fun, but I am in the middle of release management work. I am sure
however that one of the other developers could do this.

Chris

From bob at calyx.net.au  Fri Apr  8 08:22:18 2011
From: bob at calyx.net.au (Bob Birchall)
Date: Fri, 08 Apr 2011 16:22:18 +1000
Subject: [Koha-devel] conan's introduction
In-Reply-To: <4D9DF713.4020003@lugmen.org.ar>
References: <4D9DF713.4020003@lugmen.org.ar>
Message-ID: <4D9EA99A.2010607@calyx.net.au>

On 08/04/11 03:40, Fernando Canizo wrote:
> Hi everybody, I'm Fernando Canizo, aka conan, from Argentina. Some might
> have see me semi-lurking at #koha irc channel.

Hi Fernando and welcome to the Koha community.
>
> I've been hired by the SID (http://sid.uncu.edu.ar/) which depends on
> UNCuyo (http://www.uncu.edu.ar/) to implement koha for the 22 libraries
> dependent on UNCuyo and to provide modifications requested by librarians
> as they come up, with the idea in mind of trying to bring them upstream
> if they worth it.
>
> I'm still shaking from the shock of meeting koha, MARC21, and other
> behemoths alike, also I'm relearning Perl, language I swore to forget
> some years ago.
>

Yes, that's a lot to get your head around in a short time.

> I haven't introduced myself yet because I'm currently dealing with
> implementation, and I think I'll be on that for some time still.
>
> However I'm starting to build a list of desired changes for koha so I
> might bother you with questions now and then.
>

You'll find information about proposed changes at:
http://wiki.koha-community.org/wiki/Category:RFCs
and in the archives of this list:
http://lists.koha-community.org/pipermail/koha-devel/

Feel free to chip in any time.

Best wishes for your project.

Bob Birchall
CALYX

From alex.arnaud at biblibre.com  Fri Apr  8 11:09:02 2011
From: alex.arnaud at biblibre.com (Alex Arnaud)
Date: Fri, 08 Apr 2011 11:09:02 +0200
Subject: [Koha-devel] A new component in bugzilla
Message-ID: <4D9ED0AE.5070802@biblibre.com>

Hi all,

It should be interesting to have a new component for bugs related to 
ILSDI in bugzilla ?

proposals are:

    - External services Component
    - ILSDI
    - Web services
    - Other ?
    - or not ?

Any thoughts ?

Thanks

Alex


From claire.hernandez at biblibre.com  Fri Apr  8 11:24:22 2011
From: claire.hernandez at biblibre.com (Claire Hernandez)
Date: Fri, 08 Apr 2011 11:24:22 +0200
Subject: [Koha-devel] A new component in bugzilla
In-Reply-To: <4D9ED0AE.5070802@biblibre.com>
References: <4D9ED0AE.5070802@biblibre.com>
Message-ID: <4D9ED446.6000503@biblibre.com>

Web Services sounds great for me. (It can includes more than only ilsdi 
services)

Claire;

On 08/04/2011 11:09, Alex Arnaud wrote:
> Hi all,
>
> It should be interesting to have a new component for bugs related to 
> ILSDI in bugzilla ?
>
> proposals are:
>
>    - External services Component
>    - ILSDI
>    - Web services
>    - Other ?
>    - or not ?
>
> Any thoughts ?
>
> Thanks
>
> Alex
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/



From gmcharlt at gmail.com  Fri Apr  8 13:58:57 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Fri, 8 Apr 2011 07:58:57 -0400
Subject: [Koha-devel] A new component in bugzilla
In-Reply-To: <4D9ED0AE.5070802@biblibre.com>
References: <4D9ED0AE.5070802@biblibre.com>
Message-ID: <BANLkTimgcfLARb48ZLmMgtSws19szE8xWg@mail.gmail.com>

Hi,

On Fri, Apr 8, 2011 at 5:09 AM, Alex Arnaud <alex.arnaud at biblibre.com> wrote:
> Hi all,
>
> It should be interesting to have a new component for bugs related to ILSDI
> in bugzilla ?
[snip]
> ? - Web services

+1 to Web services.

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From paul.poulain at biblibre.com  Fri Apr  8 14:22:13 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 08 Apr 2011 14:22:13 +0200
Subject: [Koha-devel] A new component in bugzilla
In-Reply-To: <4D9ED0AE.5070802@biblibre.com>
References: <4D9ED0AE.5070802@biblibre.com>
Message-ID: <4D9EFDF5.6060104@biblibre.com>

Le 08/04/2011 11:09, Alex Arnaud a ?crit :
> Hi all,
>
> It should be interesting to have a new component for bugs related to
> ILSDI in bugzilla ?
well, i'm OK with "web services", BUT => I also propose to remove some
components. I think we have too much details.
For example: OPAC comments => OPAC. Patron import => Tools.

So, I'm throwing a proposition to reduce the number of components to 20
maximum.

Your opinoin ?

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


From lculber at mdah.state.ms.us  Fri Apr  8 14:30:12 2011
From: lculber at mdah.state.ms.us (Linda Culberson)
Date: Fri, 08 Apr 2011 07:30:12 -0500
Subject: [Koha-devel] Koha proposals requested Bug 6113 enhancement to keep
 previous ids in bulkmarcimport.pl
In-Reply-To: <4D9DBAEE.8090600@mdah.state.ms.us>
References: <4D9DBAEE.8090600@mdah.state.ms.us>
Message-ID: <4D9EFFD4.4070304@mdah.state.ms.us>

I forgot to say that we are requesting proposals for this.  Sorry, I'm 
still new to this.

On 4/7/2011 8:23 AM, Linda Culberson wrote:
> All,
> I have submitted Bug 6113 to bugzilla for a sponsored enhancement.
> In communicating with other Koha users, we feel that it would be highly
> beneficial Koha was enhanced to allow the library to keep its current
> ids when loading both bibliographic and authority records. Some of us
> have used our current control numbers in the 76X-78X fields to link
> records. In our institution, we have also used that number in external
> databases and on other websites to link additional information back to
> the related catalog record. The documentation within bulkmarcimport.pl
> also needs to be amended to better explain the use of the various
> options (for example: x, y, k, idmap and keepid) since some of us tried
> to use those to keep our ids without success.
>
> Thank you.

-- 
Linda Culberson			lculber at mdah.state.ms.us
Archives and Records Services Division
Ms. Dept. of Archives & History
P. O. Box 571
Jackson, MS 39205-0571
Telephone:  601/576-6873
Facsimile:  601/576-6824


From colin.campbell at ptfs-europe.com  Fri Apr  8 14:56:54 2011
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Fri, 08 Apr 2011 13:56:54 +0100
Subject: [Koha-devel] Fwd: [OPEN-ILS-GENERAL] Notice of Change to
 License for OpenNCIP
In-Reply-To: <BANLkTinqPmm1NWuewfkXx6LbwxxbjdbrLA@mail.gmail.com>
References: <1888901074.117614.1302033477098.JavaMail.root@hagrid.georgialibraries.org>	<15958069-A836-4375-B107-6FED0FC8B1A7@esilibrary.com>
	<BANLkTinqPmm1NWuewfkXx6LbwxxbjdbrLA@mail.gmail.com>
Message-ID: <4D9F0616.4030507@ptfs-europe.com>

On 05/04/11 21:18, Galen Charlton wrote:

> As we all know, Koha currently embeds a fork of OpenNCIP.  To assist
> with ending that situation so that Koha just uses OpenNCIP as a normal
> Perl dependency, I also call on any individuals and companies who have
> contributed patches to Koha's fork to express their willingness to
> have their code incorporated in a GPL2+ OpenNCIP.

I have no objection and welcome the change
Cheers
Colin

-- 
Colin Campbell
Chief Software Engineer,
PTFS Europe Limited
Content Management and Library Solutions
+44 (0) 845 557 5634 (phone)
+44 (0) 7759 633626  (mobile)
colin.campbell at ptfs-europe.com
skype: colin_campbell2

http://www.ptfs-europe.com

From gmcharlt at gmail.com  Fri Apr  8 15:08:16 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Fri, 8 Apr 2011 09:08:16 -0400
Subject: [Koha-devel] A new component in bugzilla
In-Reply-To: <4D9EFDF5.6060104@biblibre.com>
References: <4D9ED0AE.5070802@biblibre.com>
	<4D9EFDF5.6060104@biblibre.com>
Message-ID: <BANLkTinfG_0J8Zwq=PJJwHxY4OY85chnmA@mail.gmail.com>

Hi,

On Fri, Apr 8, 2011 at 8:22 AM, Paul Poulain <paul.poulain at biblibre.com> wrote:
> For example: OPAC comments => OPAC. Patron import => Tools.

+1 to both.

> So, I'm throwing a proposition to reduce the number of components to 20
> maximum.

-1.  We should have as many components as needed, and no more, but I
don't think specifying an arbitrary limit is useful.

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From paul.poulain at biblibre.com  Fri Apr  8 15:24:36 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 08 Apr 2011 15:24:36 +0200
Subject: [Koha-devel] A new component in bugzilla
In-Reply-To: <BANLkTinfG_0J8Zwq=PJJwHxY4OY85chnmA@mail.gmail.com>
References: <4D9ED0AE.5070802@biblibre.com>	<4D9EFDF5.6060104@biblibre.com>
	<BANLkTinfG_0J8Zwq=PJJwHxY4OY85chnmA@mail.gmail.com>
Message-ID: <4D9F0C94.8090402@biblibre.com>

Le 08/04/2011 15:08, Galen Charlton a ?crit :
> Hi,
>
> On Fri, Apr 8, 2011 at 8:22 AM, Paul Poulain <paul.poulain at biblibre.com> wrote:
>> For example: OPAC comments => OPAC. Patron import => Tools.
> +1 to both.
>
>> So, I'm throwing a proposition to reduce the number of components to 20
>> maximum.
> -1.  We should have as many components as needed, and no more, but I
> don't think specifying an arbitrary limit is useful.
Well i've poorly explained my idea. It's not to put an arbitrary limit,
but to think twice when adding a component.
For example, do wee need a specific component for each tool of the Tools
menu ? I don't think so.

As you said +1 to the previous propositions, I could write a more
detailled proposition to reorganise the components if ppl agrees.

-- 
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  Fri Apr  8 15:31:08 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 08 Apr 2011 15:31:08 +0200
Subject: [Koha-devel] (bugzilla)Does Not Apply => remember to change when
	updated
Message-ID: <4D9F0E1C.9090708@biblibre.com>

Hello all,

I'm reviewing all bugs with "does not apply" status.
On the first 8, i've found 4 that have an updated patch, that applies.
Sometimes there's a comment "pls try this"

REMINDER : if you want ppl to signoff the new patch, PLEASE, set again
"Please signoff". Otherwise, it will probably stay pending for some
weeks, and once someone realize it can be tested again, it will probably
not apply again...

HTH

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


From gmcharlt at gmail.com  Fri Apr  8 15:34:44 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Fri, 8 Apr 2011 09:34:44 -0400
Subject: [Koha-devel] A new component in bugzilla
In-Reply-To: <4D9F0C94.8090402@biblibre.com>
References: <4D9ED0AE.5070802@biblibre.com> <4D9EFDF5.6060104@biblibre.com>
	<BANLkTinfG_0J8Zwq=PJJwHxY4OY85chnmA@mail.gmail.com>
	<4D9F0C94.8090402@biblibre.com>
Message-ID: <BANLkTimwoeJnnW+pY8BOF0ZH9yW2wm2e7Q@mail.gmail.com>

Hi,

On Fri, Apr 8, 2011 at 9:24 AM, Paul Poulain <paul.poulain at biblibre.com> wrote:
> For example, do wee need a specific component for each tool of the Tools
> menu ? I don't think so.

Agreed.  Here's link to a report of the number of bugs filed by category:

http://bugs.koha-community.org/bugzilla3/report.cgi?x_axis_field=&y_axis_field=component&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&bug_id=&bug_id_type=anyexact&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&field0-0-0=noop&type0-0-0=noop&value0-0-0=&format=table&action=wrap

As you can see, there are a number of components that have not been
frequently used which would be candidates for merging.  One thing to
note, however, is that if a component might be infrequently used but
should not be merged because there is somebody actively maintaining
it.

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From pete.huerter at gmail.com  Fri Apr  8 16:44:16 2011
From: pete.huerter at gmail.com (pete huerter)
Date: Fri, 8 Apr 2011 10:44:16 -0400
Subject: [Koha-devel] How to resync biblioitem.marc,
	and (modified) biblioitem.marcxml
Message-ID: <BANLkTimxU2JqVJhxLGGtmNc9+ft6vBu2MA@mail.gmail.com>

Hi Koha-devel group,

I just ran some SQL queries that changed the biblioitems.marcxml blob,
but did not change the biblioitems.marc blob.  What are the
implications of this, and how can I fix this?

It seems like I should be able to just do this to 'resync' these two fields:

  for each biblio,
     call biblio = GetBiblio
     call ModBiblio (biblio)

Can someone please confirm?  (or is there a better way to do this?)

(Scroll down for more background info)

Thanks,
Pete.


Background:

During the bulk import process some of our biblios were imported with
incorrect 952$8 Collection code (should be in CCODE authorised values
list), and 952$c Shelving Location Code (should be in LOC authorised
values list).  E.g. "military o/s", should be "military o_s" which
maps to "Military oversized" in the CCODE list.  For this discussion
let's assume that both 952$8, and 952$c need to be changed from
"military o/s" to "military o_s".

I thought I was being clever and used SQL directly to replace "miltary
o/s" with "military o_s" in 4 places:
1. items.location
2. biblioitems.marcxml : field 952$c
3. items.ccode
4. biblioitems.marcxml : field 952$8

Sample SQL queries:

# items.location
UPDATE items
SET items.location = REPLACE(items.location, 'o/s', 'o_s')
WHERE items.location LIKE '%o/s%';

# marcxml blob 952$c
UPDATE biblioitems
SET marcxml = REPLACE(marcxml, 'rare/box', 'rare_box')
WHERE extractvalue(biblioitems.marcxml,'//datafield[@tag="952"]/subfield[@code="c"]')
= 'rare/box';

# items.ccode
UPDATE items
SET items.ccode = REPLACE(items.ccode, 'catalog', 'catalogue')
WHERE items.ccode = 'catalog';

# marc blob: 952$8
UPDATE biblioitems
SET marcxml = REPLACE(marcxml, 'catalog', 'catalogue')
WHERE extractvalue(biblioitems.marcxml,'//datafield[@tag="952"]/subfield[@code="8"]')
= 'catalog';

Then I realized that there is a second marc blob (biblioitems.marc) in
addition to the marcxml blob (biblioitems.marcxml) - which looks like
compiled marc? - that I did not change - yikes!

When I look in lib/C4 it looks like GetBiblio (which calls
GetBiblioMarc) uses the $marcxml to compose a Biblio $record.

Biblio.pm at GetBiblioMarc:
    $record = eval { MARC::Record::new_from_xml( $marcxml, "utf8",
C4::Context->preference('marcflavour') ) };

And it seems that ModBiblio (which calls ModBiblioMarc) compiles the
$record into both formats, the marcxml blob, and the us_marc blob
(compiled MARC?).

Biblio.pm at ModBiblioMarc:
    $sth = $dbh->prepare("UPDATE biblioitems SET marc=?,marcxml=?
WHERE biblionumber=?");
    $sth->execute( $record->as_usmarc(),
$record->as_xml_record($encoding), $biblionumber );
    $sth->finish;

There are also the following functions in Record.pm that look promising:

Record.pm@{marc2marcxml,marcxml2marc, changeEncoding}

It seems that generally biblioitems.marcxml is used more than the
biblioitems.marc blob.

It seems like I should be able to just, for each biblio, call
GetBiblio followed by ModBiblio to 'resync' these two fields.

Can someone please confirm?

From paul.poulain at biblibre.com  Fri Apr  8 16:55:25 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 08 Apr 2011 16:55:25 +0200
Subject: [Koha-devel] patches "does not apply" in bugzilla
Message-ID: <4D9F21DD.5070303@biblibre.com>

Hello all,
(and mainly chris_n, Darell Ulm, gmcharlt, hdl & Claire, Ian Walls,
jwagner, Chris_c & Reed)

i just finished reviewing patches in " does not apply" status in
bugzilla. At time of writing, that's 44 patches. I've revived 8 patches
that were "does not apply " but have a new version submitted.

On the 44 does not apply patches, some are VERY old.

This mail is a call to the original assignees If you don't submit a new
version of the patch, I'll close the patch soon (in something like 2
weeks). If you still want to submit a new version but don't have time
yet, please, add a comment to the bugzilla entry, i'll let it open.

Here is a summary of assignees of patches older than (around) 6 months :

==== Chris Nighswonger ====
5215     maj          Barcode field not cleared when using "Add and
Duplicate" option on additem.pl           Catalogi
5250     enh          Various enhancements to web based checkouts      
    Self che
5263     enh          Add support for including fields from the ISSUES
table in advanced due notices           Notices

==== Darell Ulm ====
5292     enh          Google Preview Option for OPAC           OPAC
5299     enh          Allow patron to update email if they are allowed
to update password           OPAC

==== BibLibre ====
2809     nor          Some search problems           Searchin
3453     maj          Opac authority search have a little problem      
    Searchin
3553     nor          do not allow to create code-less frameworks      
    System A
3656     enh          Specify fields to be omitted from the patron
record           Patrons
4032     enh          XSLT systempreference should take a path to file
rather than YesNo           OPAC
3281     enh          Item's summary parsing should be different      
    Searchin

==== Ian Walls ====
3393     maj          Default branches and overdues notices          
Notices

==== Catalyst ====
4460     nor          Amazon's AssociateID tag not used in links so
referred revenue lost           OPAC
5172     enh          Use other name rather than first name when
referring to the user           OPAC

==== Galen Charlton ====
2488     nor          OPACItemsResultsDisplay sys pref conflicts with
singlebranchmode           Searchin
2943     maj          Search-results give incorrect 'availability' from
missing 'maxItemsinSearchResults' syspref           Searchin
3593     enh          Term highlighting not working for exact term
research and diacritics           Searchin

==== JWAGNER for patches ====
3478     enh          Display patron middle initials           Patrons
3483     enh          Show number of OPAC renewals           Circulat
3486     enh          Checkout timeout button           Circulat
3487     enh          Don't allow payment of fines on items still
checked out           Patrons
3488     enh          Suspend and reactivate holds           Hold req
3490     enh          Billing Notice/Debt Collect           Patrons
3492     enh          Set hold fees by item type and charge when hold
placed           Hold req
3496     enh          Override maximum fine at checkout           Circulat
3500     enh          New Circulation, patron, fines, other granular
permissions           Authenti
3506     enh          Block checkout of items with pending holds (allow
supervisor override)           Circulat
3507     enh          Circ rules enhancements, maximum fine warning    
      Circulat
3508     enh          Limit number of on-shelf holds per day          
Hold req
3510     enh          Allow staff to change checkin date and time      
    Circulat
3658     enh         Allow multiple criteria to be selected in Guided
Reports and Statistics Reports           Reports
3790     enh          Fix item sort to be by library in OPAC record
display, XSLT fix for call number spacing           OPAC
3799     enh          Allow OPAC to use separate advanced search type
settings than staff           OPAC
4237     enh          Add other item statuses           Catalogi
4238     enh          OPAC timeout feature for patron privacy           OPAC
4239     enh          Allow holds on multiple items of selected
titles           Hold req
5193     enh          Add specialized auction indexes and search options
to Advanced Search           Searchin

-- 
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 Apr  8 17:06:23 2011
From: nengard at gmail.com (Nicole Engard)
Date: Fri, 8 Apr 2011 11:06:23 -0400
Subject: [Koha-devel] A new component in bugzilla
In-Reply-To: <BANLkTimwoeJnnW+pY8BOF0ZH9yW2wm2e7Q@mail.gmail.com>
References: <4D9ED0AE.5070802@biblibre.com> <4D9EFDF5.6060104@biblibre.com>
	<BANLkTinfG_0J8Zwq=PJJwHxY4OY85chnmA@mail.gmail.com>
	<4D9F0C94.8090402@biblibre.com>
	<BANLkTimwoeJnnW+pY8BOF0ZH9yW2wm2e7Q@mail.gmail.com>
Message-ID: <BANLkTinr_Qcw2X3u4b=_iwU+vGDbnOvzOg@mail.gmail.com>

Online help and documentation can be merged under documentation since
I handle both of those and they're almost identical :)

Nicole

On Fri, Apr 8, 2011 at 9:34 AM, Galen Charlton <gmcharlt at gmail.com> wrote:
> Hi,
>
> On Fri, Apr 8, 2011 at 9:24 AM, Paul Poulain <paul.poulain at biblibre.com> wrote:
>> For example, do wee need a specific component for each tool of the Tools
>> menu ? I don't think so.
>
> Agreed. ?Here's link to a report of the number of bugs filed by category:
>
> http://bugs.koha-community.org/bugzilla3/report.cgi?x_axis_field=&y_axis_field=component&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&bug_id=&bug_id_type=anyexact&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&field0-0-0=noop&type0-0-0=noop&value0-0-0=&format=table&action=wrap
>
> As you can see, there are a number of components that have not been
> frequently used which would be candidates for merging. ?One thing to
> note, however, is that if a component might be infrequently used but
> should not be merged because there is somebody actively maintaining
> it.
>
> Regards,
>
> Galen
> --
> Galen Charlton
> gmcharlt at gmail.com
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>

From nengard at gmail.com  Fri Apr  8 17:06:45 2011
From: nengard at gmail.com (Nicole Engard)
Date: Fri, 8 Apr 2011 11:06:45 -0400
Subject: [Koha-devel] A new component in bugzilla
In-Reply-To: <BANLkTinr_Qcw2X3u4b=_iwU+vGDbnOvzOg@mail.gmail.com>
References: <4D9ED0AE.5070802@biblibre.com> <4D9EFDF5.6060104@biblibre.com>
	<BANLkTinfG_0J8Zwq=PJJwHxY4OY85chnmA@mail.gmail.com>
	<4D9F0C94.8090402@biblibre.com>
	<BANLkTimwoeJnnW+pY8BOF0ZH9yW2wm2e7Q@mail.gmail.com>
	<BANLkTinr_Qcw2X3u4b=_iwU+vGDbnOvzOg@mail.gmail.com>
Message-ID: <BANLkTink4hwBQ7mz6AUnYOC2AFVTReC98Q@mail.gmail.com>

PS. Developer Documentation needs to stay separate since that is
handled by developers and not me :)

On Fri, Apr 8, 2011 at 11:06 AM, Nicole Engard <nengard at gmail.com> wrote:
> Online help and documentation can be merged under documentation since
> I handle both of those and they're almost identical :)
>
> Nicole
>
> On Fri, Apr 8, 2011 at 9:34 AM, Galen Charlton <gmcharlt at gmail.com> wrote:
>> Hi,
>>
>> On Fri, Apr 8, 2011 at 9:24 AM, Paul Poulain <paul.poulain at biblibre.com> wrote:
>>> For example, do wee need a specific component for each tool of the Tools
>>> menu ? I don't think so.
>>
>> Agreed. ?Here's link to a report of the number of bugs filed by category:
>>
>> http://bugs.koha-community.org/bugzilla3/report.cgi?x_axis_field=&y_axis_field=component&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&bug_id=&bug_id_type=anyexact&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&field0-0-0=noop&type0-0-0=noop&value0-0-0=&format=table&action=wrap
>>
>> As you can see, there are a number of components that have not been
>> frequently used which would be candidates for merging. ?One thing to
>> note, however, is that if a component might be infrequently used but
>> should not be merged because there is somebody actively maintaining
>> it.
>>
>> Regards,
>>
>> Galen
>> --
>> Galen Charlton
>> gmcharlt at gmail.com
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>>
>

From gmcharlt at gmail.com  Fri Apr  8 17:27:58 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Fri, 8 Apr 2011 11:27:58 -0400
Subject: [Koha-devel] A new component in bugzilla
In-Reply-To: <BANLkTinr_Qcw2X3u4b=_iwU+vGDbnOvzOg@mail.gmail.com>
References: <4D9ED0AE.5070802@biblibre.com> <4D9EFDF5.6060104@biblibre.com>
	<BANLkTinfG_0J8Zwq=PJJwHxY4OY85chnmA@mail.gmail.com>
	<4D9F0C94.8090402@biblibre.com>
	<BANLkTimwoeJnnW+pY8BOF0ZH9yW2wm2e7Q@mail.gmail.com>
	<BANLkTinr_Qcw2X3u4b=_iwU+vGDbnOvzOg@mail.gmail.com>
Message-ID: <BANLkTimxpK+aB2dwjjeBiriuoc7Dsx3R5w@mail.gmail.com>

Hi,

On Fri, Apr 8, 2011 at 11:06 AM, Nicole Engard <nengard at gmail.com> wrote:
> Online help and documentation can be merged under documentation since
> I handle both of those and they're almost identical :)

Agreed.  I've merged online help into documentation.

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From gmcharlt at gmail.com  Fri Apr  8 17:31:02 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Fri, 8 Apr 2011 11:31:02 -0400
Subject: [Koha-devel] A new component in bugzilla
In-Reply-To: <BANLkTinfG_0J8Zwq=PJJwHxY4OY85chnmA@mail.gmail.com>
References: <4D9ED0AE.5070802@biblibre.com> <4D9EFDF5.6060104@biblibre.com>
	<BANLkTinfG_0J8Zwq=PJJwHxY4OY85chnmA@mail.gmail.com>
Message-ID: <BANLkTimM5uNrQxg56g68zdJhKTGdmbHvzQ@mail.gmail.com>

Hi,

On Fri, Apr 8, 2011 at 9:08 AM, Galen Charlton <gmcharlt at gmail.com> wrote:
> Hi,
>
> On Fri, Apr 8, 2011 at 8:22 AM, Paul Poulain <paul.poulain at biblibre.com> wrote:
>> For example: OPAC comments => OPAC. Patron import => Tools.
>
> +1 to both.

I've gone ahead and made both changes.

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From fridolyn.somers at gmail.com  Fri Apr  8 17:56:14 2011
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Fri, 8 Apr 2011 17:56:14 +0200
Subject: [Koha-devel] Lyon 2 University features
Message-ID: <BANLkTimdZiLLigFLTbgYogRhq67q_L0dag@mail.gmail.com>

Hie,

This week,
during th HackFest in Marseille,
I started to create patches corresponding to features developed by Progilone
for Lyon 2 university.

First one is in bug
6120<http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6120>,
based on features F10-F11 (see our
git<http://git.progilone.com/?p=koha-lyon2.git;a=commitdiff;h=b51b944eb54fdb811291f1c2c034bb661c400bf8>
).

We have discussed on the other features with Paul Poulain from Biblibre in
order to give them priorities :

More interesting :

   - F10-F11 (done)
   - F16
   - F21-F22
   - C1

Medium interesting :

   - F1-F13

Needs more developement :

   - F18
   - F19
   - C2
   - C5

Not interesting :

   - F5-F6
   - F7
   - F14
   - F17
   - F27
   - F28-F29
   - C4
   - C7
   - C8

Obsolete :

   - F20
   - C6

We will do your best to provide patches for the community version on
interesting features.

Best regards,

PS : git clone works now on our git. (I'm starting to like git).
PS : A* features are not new developments, they come from the Lyon 3 version
managed by Biblibre.
-- 
Fridolyn SOMERS
ICT engineer
PROGILONE - Lyon - France
fridolyn.somers at gmail.com
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20110408/3efde561/attachment.htm>

From paul.poulain at biblibre.com  Fri Apr  8 18:22:54 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 08 Apr 2011 18:22:54 +0200
Subject: [Koha-devel] Hacker's corner, wk14  / Hackfest Europe
Message-ID: <4D9F365E.8090207@biblibre.com>

Hello koha-devel,

This week was a very busy week in Marseille: 25 fellow developers came
from Europe to work on koha. The work done was huge !
Just a few numbers:
* 112 bugs have been set to sign-off
* 128 patches have been signed off
* 92 patches have been pushed by chris
* 90 bugs have been marked "fixed"
The changes on bugzilla have resulted in an astonishing number of 1140
mails in a week ! (note that's not only hackfest activity, but it's
something like 4 times a standard weekly activity)

==== Hackfest news ====
This hackfest has seen some new developers joining us:
* Mark Gavillet, from PTFS-Europe, made his first patches and has
signed/marked fix a lot. He also learned many things, and said before
leaving that it has been an invaluable boost for him.
* Fridolyn Somer, from Progilone, helped a lot, and we spoke of the
patches available at git.progilone.com Some of them should make their
way to git.koha-community.org soon, as they are really interesting (some
will remain local, as they look too specific to Lyon 2 university, the
sponsoring customer)
* Juan and Miguel, from Xercode in spain were here for 2 days.
* Fr?d?ric Durand, from Lyon 2, has made a lot of work testing and checking
* Not really developers, but Pascale Nalon (Mines Paris tech school),
Guillaume Hatt (Ecole des Chartes school) and St?phane Delaye (BibLibre
librarian/project manager) made a lot of work on french translation, as
well as many testings.

All other attendees were already known developers. All of us agree that
it was really cool to work together in small groups of 3 or 4
Just a special thanks to Magnus, that came from Norway, and to Katrin,
that came from Germany. We should send some picture we've taken very soon !

=== Hacker's corner ===
Needs signoff: 112 bugs are awaiting for you sign-off. The number
includes many many patches/fixes that BibLibre did on git.biblibre.com
and that still had to be submitted.

Signed-off: 35 bugs are signed off and should be commited soon by chris

Patch pushed, please test : 102 bugs have been pushed recently and are
awaigint to be marked "fixed" to definetly solve the bug described !

Discussion: i've sent a mail on koha-devel about some bugs that have a
patch that does not apply. Some of them are very old. Unless the author
of the patch (or any other volunteer) rebase and submit a working patch,
i'll mark the bugzilla "fixed, wontfix" in something like 2 weeks. It's
the best solution not to have bugs that stay open and remain here forever.

-- 
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  Fri Apr  8 18:32:00 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 08 Apr 2011 18:32:00 +0200
Subject: [Koha-devel] Lyon 2 University features
In-Reply-To: <BANLkTimdZiLLigFLTbgYogRhq67q_L0dag@mail.gmail.com>
References: <BANLkTimdZiLLigFLTbgYogRhq67q_L0dag@mail.gmail.com>
Message-ID: <4D9F3880.8050809@biblibre.com>

Le 08/04/2011 17:56, Fridolyn SOMERS a ?crit :
> PS : A* features are not new developments, they come from the Lyon 3
> version managed by Biblibre.
Just for everybody information : there are 3 universities in Lyon
Lyon 1 does not use Koha (yet ? ;-) )
Lyon 2 uses Koha with Progilone as support company
Lyon 3 uses Koha with BibLibre as support company

Lyon2, Lyon 3, and StEtienne (that is near Lyon, and will soon go live
on Koha with BibLibre as support company) had a workinggroup and
sponsored some features, sharing their needs and splitting what they
sponsor between them

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


From oleonard at myacpl.org  Fri Apr  8 18:38:10 2011
From: oleonard at myacpl.org (Owen Leonard)
Date: Fri, 8 Apr 2011 12:38:10 -0400
Subject: [Koha-devel] Hacker's corner, wk14 / Hackfest Europe
In-Reply-To: <4D9F365E.8090207@biblibre.com>
References: <4D9F365E.8090207@biblibre.com>
Message-ID: <BANLkTi=ztuf_+hJ_g1=1tvdv3y0+z6Y_mg@mail.gmail.com>

> Unless the author
> of the patch (or any other volunteer) rebase and submit a working patch,
> i'll mark the bugzilla "fixed, wontfix" in something like 2 weeks.

I agree, with this exception: If the bug is a real bug (not an
enhancement) it should be set back to "New."

  -- Owen

-- 
Web Developer
Athens County Public Libraries
http://www.myacpl.org

From dschust1 at gmail.com  Fri Apr  8 18:58:05 2011
From: dschust1 at gmail.com (David Schuster)
Date: Fri, 8 Apr 2011 11:58:05 -0500
Subject: [Koha-devel] Hacker's corner, wk14 / Hackfest Europe
In-Reply-To: <BANLkTi=ztuf_+hJ_g1=1tvdv3y0+z6Y_mg@mail.gmail.com>
References: <4D9F365E.8090207@biblibre.com>
	<BANLkTi=ztuf_+hJ_g1=1tvdv3y0+z6Y_mg@mail.gmail.com>
Message-ID: <BANLkTinpOpGW-Ga3WDkqdrvmaA+Q_A0ASg@mail.gmail.com>

So how are we tracking enhancements we would like to see then still through
bugzilla?

On Fri, Apr 8, 2011 at 11:38 AM, Owen Leonard <oleonard at myacpl.org> wrote:

> > Unless the author
> > of the patch (or any other volunteer) rebase and submit a working patch,
> > i'll mark the bugzilla "fixed, wontfix" in something like 2 weeks.
>
> I agree, with this exception: If the bug is a real bug (not an
> enhancement) it should be set back to "New."
>
>  -- 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/
>



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

From oleonard at myacpl.org  Fri Apr  8 19:03:14 2011
From: oleonard at myacpl.org (Owen Leonard)
Date: Fri, 8 Apr 2011 13:03:14 -0400
Subject: [Koha-devel] Hacker's corner, wk14 / Hackfest Europe
In-Reply-To: <BANLkTinpOpGW-Ga3WDkqdrvmaA+Q_A0ASg@mail.gmail.com>
References: <4D9F365E.8090207@biblibre.com>
	<BANLkTi=ztuf_+hJ_g1=1tvdv3y0+z6Y_mg@mail.gmail.com>
	<BANLkTinpOpGW-Ga3WDkqdrvmaA+Q_A0ASg@mail.gmail.com>
Message-ID: <BANLkTimzTa6J2jyvB88nVRhXWL6vo_DOVA@mail.gmail.com>

> So how are we tracking enhancements we would like to see then still through
> bugzilla?

This change would only apply to enhancements for which someone has
submitted a patch and for which that patch is so out of date that it
can't be considered for inclusion. Anyone who wants to give one of
these bugs a second life can re-open it, but it would be much more
meaningful for some sponsorship to come along with that.

  -- Owen


-- 
Web Developer
Athens County Public Libraries
http://www.myacpl.org

From fridolyn.somers at gmail.com  Fri Apr  8 19:24:16 2011
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Fri, 8 Apr 2011 19:24:16 +0200
Subject: [Koha-devel] Hacker's corner, wk14 / Hackfest Europe
In-Reply-To: <4D9F365E.8090207@biblibre.com>
References: <4D9F365E.8090207@biblibre.com>
Message-ID: <BANLkTi=QHHop8ZYFc3Upvc6V3Sphdk_W3w@mail.gmail.com>

Hie,

Thanks for presenting me Paul.

I really had a good time in Marseille.
It was a pleasure to contribute 3 days at an open source project.

Has I said, the product becomes more and more stable and user friendly.

I'll continue to contribute now that I'm more aware of the workflow and of
git.

Best regards,

On Fri, Apr 8, 2011 at 6:22 PM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Hello koha-devel,
>
> This week was a very busy week in Marseille: 25 fellow developers came
> from Europe to work on koha. The work done was huge !
> Just a few numbers:
> * 112 bugs have been set to sign-off
> * 128 patches have been signed off
> * 92 patches have been pushed by chris
> * 90 bugs have been marked "fixed"
> The changes on bugzilla have resulted in an astonishing number of 1140
> mails in a week ! (note that's not only hackfest activity, but it's
> something like 4 times a standard weekly activity)
>
> ==== Hackfest news ====
> This hackfest has seen some new developers joining us:
> * Mark Gavillet, from PTFS-Europe, made his first patches and has
> signed/marked fix a lot. He also learned many things, and said before
> leaving that it has been an invaluable boost for him.
> * Fridolyn Somer, from Progilone, helped a lot, and we spoke of the
> patches available at git.progilone.com Some of them should make their
> way to git.koha-community.org soon, as they are really interesting (some
> will remain local, as they look too specific to Lyon 2 university, the
> sponsoring customer)
> * Juan and Miguel, from Xercode in spain were here for 2 days.
> * Fr?d?ric Durand, from Lyon 2, has made a lot of work testing and checking
> * Not really developers, but Pascale Nalon (Mines Paris tech school),
> Guillaume Hatt (Ecole des Chartes school) and St?phane Delaye (BibLibre
> librarian/project manager) made a lot of work on french translation, as
> well as many testings.
>
> All other attendees were already known developers. All of us agree that
> it was really cool to work together in small groups of 3 or 4
> Just a special thanks to Magnus, that came from Norway, and to Katrin,
> that came from Germany. We should send some picture we've taken very soon !
>
> === Hacker's corner ===
> Needs signoff: 112 bugs are awaiting for you sign-off. The number
> includes many many patches/fixes that BibLibre did on git.biblibre.com
> and that still had to be submitted.
>
> Signed-off: 35 bugs are signed off and should be commited soon by chris
>
> Patch pushed, please test : 102 bugs have been pushed recently and are
> awaigint to be marked "fixed" to definetly solve the bug described !
>
> Discussion: i've sent a mail on koha-devel about some bugs that have a
> patch that does not apply. Some of them are very old. Unless the author
> of the patch (or any other volunteer) rebase and submit a working patch,
> i'll mark the bugzilla "fixed, wontfix" in something like 2 weeks. It's
> the best solution not to have bugs that stay open and remain here forever.
>
> --
> 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
ICT engineer
PROGILONE - Lyon - France
fridolyn.somers at gmail.com
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20110408/c3524f29/attachment.htm>

From cnighswonger at foundations.edu  Fri Apr  8 19:48:01 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Fri, 8 Apr 2011 13:48:01 -0400
Subject: [Koha-devel] Hacker's corner, wk14 / Hackfest Europe
In-Reply-To: <BANLkTi=ztuf_+hJ_g1=1tvdv3y0+z6Y_mg@mail.gmail.com>
References: <4D9F365E.8090207@biblibre.com>
	<BANLkTi=ztuf_+hJ_g1=1tvdv3y0+z6Y_mg@mail.gmail.com>
Message-ID: <BANLkTimTn9b-F91U-gVVGJNC_JPgQFBYyQ@mail.gmail.com>

On Fri, Apr 8, 2011 at 12:38 PM, Owen Leonard <oleonard at myacpl.org> wrote:

> > Unless the author
> > of the patch (or any other volunteer) rebase and submit a working patch,
> > i'll mark the bugzilla "fixed, wontfix" in something like 2 weeks.
>
> I agree, with this exception: If the bug is a real bug (not an
> enhancement) it should be set back to "New."
>
>
I would add another exception based on David's question:

Enhancement bugs should not be closed in arbitrary fashion. They probably
should have the longest time allowance of all bugs given that it may take a
while for someone(s) to pick up and implement them.

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

From chrisc at catalyst.net.nz  Fri Apr  8 21:40:03 2011
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Sat, 9 Apr 2011 07:40:03 +1200
Subject: [Koha-devel] String freeze is nigh
Message-ID: <20110408194002.GK8495@rorohiko>

Hi All

The string freeze kicks into effect right about now.
What does this mean, any new patches sent now, that touch templates and
are not security related, will be deferred for 3.4.1.
(New features of course are deferred to 3.6.x)

On Monday NZ time, I will be merging the template::toolkit work into
master and calling for lots of testing. I will create another branch
that people can continue to use to sign off on old .tmpl files, and all
ones submitted before Monday will be taken care of.

Post Monday I will be asking that everyone makes patches based on the
.tt files instead. I will post instructions in the mailing list, on the
wiki and on the official Koha site, www.koha-community.org at that point
also. 

Thanks all for your hard work, its looking like over 760 commits between
3.2.0 and 3.4.0 which is pretty amazing for 6 months work, and at last
count nearly 70 people have patches in 3.4.0. 

The project continues to grow both in terms of community, and pace of
development. So thank you all.

Chris
-- 
Chris Cormack
Catalyst IT Ltd.
+64 4 803 2238
PO Box 11-053, Manners St, Wellington 6142, New Zealand
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: </pipermail/koha-devel/attachments/20110409/4c3acaee/attachment.pgp>

From chris at bigballofwax.co.nz  Fri Apr  8 22:02:21 2011
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Sat, 9 Apr 2011 08:02:21 +1200
Subject: [Koha-devel] Fwd:  Generating transactions
In-Reply-To: <4D9F097A.3070504@ccfls.org>
References: <4D9DB977.5090505@kul.oslo.kommune.no>
	<BANLkTi=iBfb3GxiM1XouhJGQ37fcREeB3Q@mail.gmail.com>
	<4D9F097A.3070504@ccfls.org>
Message-ID: <BANLkTim0Wu=mV4trD-aEQ+RXdUyYn_zdcQ@mail.gmail.com>

Forwarding to the list with Johns permission


---------- Forwarded message ----------
From: John Brice <jbrice at ccfls.org>
Date: 9 April 2011 01:11
Subject: Re: [Koha-devel] Generating transactions
To: Chris Cormack <chris at bigballofwax.co.nz>


On 04/07/2011 04:56 PM, Chris Cormack wrote:
>
> On 8 April 2011 01:17, Anne-Lena Westrum
> <anne-lena.westrum at kul.oslo.kommune.no> ?wrote:
>>
>> Dearest Koha developers!
>>
>> We have recently started a process of testing and evaluating Koha in the
>> perspective of a fairly large public library, with a number of different
>> branches and departments. This has proven to be a fairly timeconsuming
>> task, as we - amongst other things - need to test all the modules and
>> compare it to the functionality of our current ILS :)
>>
>> After importing our records (Normarc), we need to do a demo of the
>> different modules. Thus we are in desperate need of a script to generate
>> users (approx 500.000) and transactions (3-4 millions) over a period of
>> time (4-5 years).
>>
>> We have had no luck searching for a script like this. Can someone help
>> point us in the right direction?
>>
> Hi Anne-Lenna
>
> Magnus our NORMARC export (he wrote all the NORMARC support for Koha
> and is from Norway also) is currently trying to sleep of a cold in
> Marseille. He has been there for the week with Koha developers from
> all around Europe working on a code sprint leading up to the release
> of Koha 3.4.0 on April 22 (which will have native NORMARC support).
>
> I am sure he will answer when he wakes up :) As far as I know such a
> script does not exist. I would offer to write one, as it sounds like
> fun, but I am in the middle of release management work. I am sure
> however that one of the other developers could do this.
>
> Chris
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/

Hi Anne-Lenna:

Years ago we tried to write such a script but it was much more
complicated than we expected. ?For proof of concepts and demo purposes
why not just load, from your current ILS, your transaction data into
Koha? ?You will have to learn how to do this anyway so why not work
out the transaction transfer now.

John Brice
Executive Director
Meadville Public Library

From magnus at enger.priv.no  Sat Apr  9 09:55:18 2011
From: magnus at enger.priv.no (Magnus Enger)
Date: Sat, 9 Apr 2011 09:55:18 +0200
Subject: [Koha-devel] Generating transactions
In-Reply-To: <BANLkTi=iBfb3GxiM1XouhJGQ37fcREeB3Q@mail.gmail.com>
References: <4D9DB977.5090505@kul.oslo.kommune.no>
	<BANLkTi=iBfb3GxiM1XouhJGQ37fcREeB3Q@mail.gmail.com>
Message-ID: <BANLkTinuEnTcMnO-4B2LEQK=MB0h6tARVA@mail.gmail.com>

On 7 April 2011 22:56, Chris Cormack <chris at bigballofwax.co.nz> wrote:
> On 8 April 2011 01:17, Anne-Lena Westrum
>> After importing our records (Normarc), we need to do a demo of the
>> different modules. Thus we are in desperate need of a script to generate
>> users (approx 500.000) and transactions (3-4 millions) over a period of
>> time (4-5 years).
>>
>> We have had no luck searching for a script like this. Can someone help
>> point us in the right direction?
>>
> Hi Anne-Lenna
>
> Magnus our NORMARC export (he wrote all the NORMARC support for Koha
> and is from Norway also) is currently trying to sleep of a cold in
> Marseille. He has been there for the week with Koha developers from
> all around Europe working on a code sprint leading up to the release
> of Koha 3.4.0 on April 22 (which will have native NORMARC support).
>
> I am sure he will answer when he wakes up :)

Or a little bit later...

As for NORMARC, let's just say Norway is a small country... ;-)

> As far as I know such a
> script does not exist. I would offer to write one, as it sounds like
> fun, but I am in the middle of release management work. I am sure
> however that one of the other developers could do this.

I thought it sounded like fun too, so I have started to work on one
during the trip to and from Marseille. It's not finished yet, but I
hope to get a long, good wait for the last plane home to Bod?, and I
will let you know when it can be tested.

Best regards,
Magnus

From jcamins at cpbibliography.com  Sat Apr  9 15:23:22 2011
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Sat, 9 Apr 2011 09:23:22 -0400
Subject: [Koha-devel] MARC21 Authority DOM indexing
Message-ID: <BANLkTiny0yZWqxE1Byg5CWLiW_mrzA73mA@mail.gmail.com>

Good morning.

I just wrote a follow-up patch for bug 3072, to fix authority searching now
that Heading-Main is used again. The two files I changed are
etc/zebradb/marc_defs/marc21/authorities/authority-koha-indexdefs.xml and
etc/zebradb/marc_defs/marc21/authorities/authority-zebra-indexdefs.xsl

This is all well and good, but I can find no reference to the first file,
authority-koha-indexdefs (sadly I discovered this *after* I had spent the
time editing it). Does anyone know A) why we have it and B) why we shouldn't
just remove it so that other people don't get confused and spend their time
editing an unused file?

Regards,
Jared

-- 
Jared Camins-Esakov
Freelance bibliographer, C & P Bibliography Services, LLC
(phone) +1 (917) 727-3445
(e-mail) jcamins at cpbibliography.com
(web) http://www.cpbibliography.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110409/eb55a52c/attachment.htm>

From gmcharlt at gmail.com  Sat Apr  9 16:11:25 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Sat, 9 Apr 2011 10:11:25 -0400
Subject: [Koha-devel] MARC21 Authority DOM indexing
In-Reply-To: <BANLkTiny0yZWqxE1Byg5CWLiW_mrzA73mA@mail.gmail.com>
References: <BANLkTiny0yZWqxE1Byg5CWLiW_mrzA73mA@mail.gmail.com>
Message-ID: <BANLkTinAjja=Dop7D9ujabewiBYL6WOf=g@mail.gmail.com>

Hi,

2011/4/9 Jared Camins-Esakov <jcamins at cpbibliography.com>:
> Good morning.
> I just wrote a follow-up patch for bug 3072, to fix authority searching now
> that Heading-Main is used again. The two files I changed are
> etc/zebradb/marc_defs/marc21/authorities/authority-koha-indexdefs.xml
> and?etc/zebradb/marc_defs/marc21/authorities/authority-zebra-indexdefs.xsl
> This is all well and good, but I can find no reference to the first file,
> authority-koha-indexdefs (sadly I discovered this *after* I had spent the
> time editing it). Does anyone know A) why we have it and B) why we shouldn't
> just remove it so that other people don't get confused and spend their time
> editing an unused file?

It's explained in the description of commit cf8c3a84 -
authority-koha-indexdefs.xml is the master set of indexing
definitions, and it expresses those definitions (relatively)
compactly.  authority-zebra-indexdefs.xsl is what is actually used by
Zebra to transform the MARCXML authority record into XML representing
the terms to be stored  in Zebra's indexes.  To generate that
authority-zebra-indexdefs.xsl, you use koha-indexdefs-to-zebra.xsl
XSLT, e.g.,

xsltproc koha-indexdefs-to-zebra.xsl authority-koha-indexdefs.xml >
authority-zebra-indexdefs.xsl

Of course, storing both authority-koha-indexdefs.xml and
authority-zebra-indexdefs.xsl in the repository violates the guideline
that a version control repository shouldn't contain derived files,
just source files and build scripts.  Mea culpa.  One fix would be to
drop authority-zebra-indexdefs.xsl from Git and update the installer
scripts to generate it when needed.

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From dschust1 at gmail.com  Sat Apr  9 16:20:29 2011
From: dschust1 at gmail.com (David Schuster)
Date: Sat, 9 Apr 2011 09:20:29 -0500
Subject: [Koha-devel] conan's introduction
In-Reply-To: <4D9EA99A.2010607@calyx.net.au>
References: <4D9DF713.4020003@lugmen.org.ar> <4D9EA99A.2010607@calyx.net.au>
Message-ID: <4A858046-07D3-40FB-ADB3-5229CFC9B773@gmail.com>

Mr  Canizo gosh that sounds formal with this group!  There is also a LPGA discuss list if you have not found it check out the koha-community.org website.

In my three years of implementing Koha this community has been very helpful and friendly.  I also would recommend as a developer you do whatever you can to get to the KohaCon conference in India where most support companies and many other developers will be.  You will garner friendships to last and that one on one will provide you goodwill beyond your imagination.  Eating and having beverages build lasting friendships.

If there is anything I can do just ask.  I'm just a librarian in the US and dabble with code.

Sincerely
David Schuster

Sent from my iPhone

On Apr 8, 2011, at 1:22 AM, Bob Birchall <bob at calyx.net.au> wrote:

> On 08/04/11 03:40, Fernando Canizo wrote:
>> Hi everybody, I'm Fernando Canizo, aka conan, from Argentina. Some might
>> have see me semi-lurking at #koha irc channel.
> 
> Hi Fernando and welcome to the Koha community.
>> 
>> I've been hired by the SID (http://sid.uncu.edu.ar/) which depends on
>> UNCuyo (http://www.uncu.edu.ar/) to implement koha for the 22 libraries
>> dependent on UNCuyo and to provide modifications requested by librarians
>> as they come up, with the idea in mind of trying to bring them upstream
>> if they worth it.
>> 
>> I'm still shaking from the shock of meeting koha, MARC21, and other
>> behemoths alike, also I'm relearning Perl, language I swore to forget
>> some years ago.
>> 
> 
> Yes, that's a lot to get your head around in a short time.
> 
>> I haven't introduced myself yet because I'm currently dealing with
>> implementation, and I think I'll be on that for some time still.
>> 
>> However I'm starting to build a list of desired changes for koha so I
>> might bother you with questions now and then.
>> 
> 
> You'll find information about proposed changes at:
> http://wiki.koha-community.org/wiki/Category:RFCs
> and in the archives of this list:
> http://lists.koha-community.org/pipermail/koha-devel/
> 
> Feel free to chip in any time.
> 
> Best wishes for your project.
> 
> Bob Birchall
> CALYX
> _______________________________________________
> 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  Sat Apr  9 16:54:22 2011
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Sat, 9 Apr 2011 10:54:22 -0400
Subject: [Koha-devel] MARC21 Authority DOM indexing
In-Reply-To: <BANLkTinAjja=Dop7D9ujabewiBYL6WOf=g@mail.gmail.com>
References: <BANLkTiny0yZWqxE1Byg5CWLiW_mrzA73mA@mail.gmail.com>
	<BANLkTinAjja=Dop7D9ujabewiBYL6WOf=g@mail.gmail.com>
Message-ID: <BANLkTimoCypx86dhZh0NpS1isRc6+uEfGg@mail.gmail.com>

Galen,


> It's explained in the description of commit cf8c3a84 -
> authority-koha-indexdefs.xml is the master set of indexing
> definitions, and it expresses those definitions (relatively)
> compactly.  authority-zebra-indexdefs.xsl is what is actually used by
> Zebra to transform the MARCXML authority record into XML representing
> the terms to be stored  in Zebra's indexes.  To generate that
> authority-zebra-indexdefs.xsl, you use koha-indexdefs-to-zebra.xsl
> XSLT, e.g.,
>
> xsltproc koha-indexdefs-to-zebra.xsl authority-koha-indexdefs.xml >
> authority-zebra-indexdefs.xsl


> Of course, storing both authority-koha-indexdefs.xml and
> authority-zebra-indexdefs.xsl in the repository violates the guideline
> that a version control repository shouldn't contain derived files,
> just source files and build scripts.  Mea culpa.  One fix would be to
> drop authority-zebra-indexdefs.xsl from Git and update the installer
> scripts to generate it when needed.
>

I agree that that should be done, but I do not think that's appropriate for
3.4, at this point, as xsltproc would add at least one additional dependency
to the installation procedure. I am sending a revised patch for bug 3072
which includes the authority-zebra-indexdefs.xsl file generated by
koha-indexdefs-to-zebra.xsl.

Regards,
Jared

-- 
Jared Camins-Esakov
Freelance bibliographer, C & P Bibliography Services, LLC
(phone) +1 (917) 727-3445
(e-mail) jcamins at cpbibliography.com
(web) http://www.cpbibliography.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110409/d9161346/attachment.htm>

From chrisc at catalyst.net.nz  Sun Apr 10 11:36:48 2011
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Sun, 10 Apr 2011 21:36:48 +1200
Subject: [Koha-devel] Master is currently unstable
Message-ID: <20110410093648.GL8495@rorohiko>

Hi All

I have merged the Template::Toolkit changes into master. Anyone running
from master in production is advised not to update at the moment. Anyone
else please do and report any bugs you find.

If you want to sign off on old patches, I have pushed new/old_templates.
I will endeavour to keep it up to date.

I have also tagged the last commit before the merge, the tag is 
html_template_pro
I have also gpg signed it, as I will be doing for any tags I make.
You can get my key from https://launchpad.net/~chris-bigballofwax


Please test, and report any bugs you find.

Chris
-- 
Chris Cormack
Catalyst IT Ltd.
+64 4 803 2238
PO Box 11-053, Manners St, Wellington 6142, New Zealand
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: </pipermail/koha-devel/attachments/20110410/5bdeb448/attachment.pgp>

From chrisc at catalyst.net.nz  Sun Apr 10 13:53:11 2011
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Sun, 10 Apr 2011 23:53:11 +1200
Subject: [Koha-devel] Master is currently unstable
In-Reply-To: <20110410093648.GL8495@rorohiko>
References: <20110410093648.GL8495@rorohiko>
Message-ID: <20110410115311.GM8495@rorohiko>

* Chris Cormack (chrisc at catalyst.net.nz) wrote:
> 
> Please test, and report any bugs you find.
> 
I have found a bug with the translating script, it is missing the last
couple of lines when translated. I will work on this tomorrow

Chris

-- 
Chris Cormack
Catalyst IT Ltd.
+64 4 803 2238
PO Box 11-053, Manners St, Wellington 6142, New Zealand
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: </pipermail/koha-devel/attachments/20110410/32d76f85/attachment.pgp>

From nalon at ensmp.fr  Fri Apr  8 20:02:23 2011
From: nalon at ensmp.fr (nalon at ensmp.fr)
Date: Fri, 08 Apr 2011 20:02:23 +0200
Subject: [Koha-devel] Hacker's corner, wk14  / Hackfest Europe
In-Reply-To: <4D9F365E.8090207@biblibre.com>
References: <4D9F365E.8090207@biblibre.com>
Message-ID: <20110408200223.13584jsxhv824w84@imaper.mines-paristech.fr>

Bonjour,

Back to home after a week in Marseille !
Even i'm not a developper, but a librarian, it's has been very pushy  
to work side to side, and to see the community in real.

Thanks Paul for your invitation !

Pascale Nalon
Mines ParisTech/
Pr?sidente de KohaLa

Quoting Paul Poulain <paul.poulain at biblibre.com>:

> Hello koha-devel,
>
> This week was a very busy week in Marseille: 25 fellow developers came
> from Europe to work on koha. The work done was huge !
> Just a few numbers:
> * 112 bugs have been set to sign-off
> * 128 patches have been signed off
> * 92 patches have been pushed by chris
> * 90 bugs have been marked "fixed"
> The changes on bugzilla have resulted in an astonishing number of 1140
> mails in a week ! (note that's not only hackfest activity, but it's
> something like 4 times a standard weekly activity)
>
> ==== Hackfest news ====
> This hackfest has seen some new developers joining us:
> * Mark Gavillet, from PTFS-Europe, made his first patches and has
> signed/marked fix a lot. He also learned many things, and said before
> leaving that it has been an invaluable boost for him.
> * Fridolyn Somer, from Progilone, helped a lot, and we spoke of the
> patches available at git.progilone.com Some of them should make their
> way to git.koha-community.org soon, as they are really interesting (some
> will remain local, as they look too specific to Lyon 2 university, the
> sponsoring customer)
> * Juan and Miguel, from Xercode in spain were here for 2 days.
> * Fr?d?ric Durand, from Lyon 2, has made a lot of work testing and checking
> * Not really developers, but Pascale Nalon (Mines Paris tech school),
> Guillaume Hatt (Ecole des Chartes school) and St?phane Delaye (BibLibre
> librarian/project manager) made a lot of work on french translation, as
> well as many testings.
>
> All other attendees were already known developers. All of us agree that
> it was really cool to work together in small groups of 3 or 4
> Just a special thanks to Magnus, that came from Norway, and to Katrin,
> that came from Germany. We should send some picture we've taken very soon !
>
> === Hacker's corner ===
> Needs signoff: 112 bugs are awaiting for you sign-off. The number
> includes many many patches/fixes that BibLibre did on git.biblibre.com
> and that still had to be submitted.
>
> Signed-off: 35 bugs are signed off and should be commited soon by chris
>
> Patch pushed, please test : 102 bugs have been pushed recently and are
> awaigint to be marked "fixed" to definetly solve the bug described !
>
> Discussion: i've sent a mail on koha-devel about some bugs that have a
> patch that does not apply. Some of them are very old. Unless the author
> of the patch (or any other volunteer) rebase and submit a working patch,
> i'll mark the bugzilla "fixed, wontfix" in something like 2 weeks. It's
> the best solution not to have bugs that stay open and remain here forever.
>
> --
> 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/
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

From chrisc at catalyst.net.nz  Sun Apr 10 22:42:34 2011
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Mon, 11 Apr 2011 08:42:34 +1200
Subject: [Koha-devel] How to convert a HTML::Template::Pro template to
	Template::Toolkit
Message-ID: <20110410204234.GN8495@rorohiko>

Hi All

There may be a need for people to convert a template to
template::toolkit so they can send a patch that will apply cleanly.

To do so checkout a branch based on commit
d4cd05126da3accef83144d8322fcd455d7eba9b

eg
git checkout -b convert_templates d4cd05126da3accef83144d8322fcd455d7eba9b

Now you have a branch with both sets of templates, you can then
cherry-pick your template change over.

And run 
./installer/html-template-to-template-toolkit.pl  --koharoot /path/to/the/root

This will convert all the templates, if you want to just convert 1 use
-f eg

./installer/html-template-to-template-toolkit.pl  --koharoot /path/to/the/root -f koha-tmpl/opac-tmpl/prog/en/modules/ilsdi.tmpl

So for me
./installer/html-template-to-template-toolkit.pl -c --koharoot /home/chrisc/git/koha/ -f koha-tmpl/opac-tmpl/prog/en/modules/ilsdi.tmpl

Then that file will be in the koha-tt dir and you will now have a
converted file. 

Hope this helps

Chris

-- 
Chris Cormack
Catalyst IT Ltd.
+64 4 803 2238
PO Box 11-053, Manners St, Wellington 6142, New Zealand
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: </pipermail/koha-devel/attachments/20110411/bc70cf87/attachment.pgp>

From magnus at enger.priv.no  Mon Apr 11 13:12:22 2011
From: magnus at enger.priv.no (Magnus Enger)
Date: Mon, 11 Apr 2011 13:12:22 +0200
Subject: [Koha-devel] Hacker's corner, wk14 / Hackfest Europe
In-Reply-To: <4D9F365E.8090207@biblibre.com>
References: <4D9F365E.8090207@biblibre.com>
Message-ID: <BANLkTikym-Z+0SiGyCRs5W2cQcRk+S00_w@mail.gmail.com>

On 8 April 2011 18:22, Paul Poulain <paul.poulain at biblibre.com> wrote:
> Just a special thanks to Magnus, that came from Norway, and to Katrin,
> that came from Germany. We should send some picture we've taken very soon !

Just a special thanks to BibLibre for organizing and hosting the
hackfest in the best way possible! Being the only Koha hacker in
Scandinavia, getting to spend some time with people with similar
interests every now and then is just great! Maybe we could make a
European hackfest a yearly tradition?

Best regards,
Magnus Enger
libriotech.no

From chris at bigballofwax.co.nz  Mon Apr 11 13:14:56 2011
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Mon, 11 Apr 2011 23:14:56 +1200
Subject: [Koha-devel] Hacker's corner, wk14 / Hackfest Europe
In-Reply-To: <BANLkTikym-Z+0SiGyCRs5W2cQcRk+S00_w@mail.gmail.com>
References: <4D9F365E.8090207@biblibre.com>
	<BANLkTikym-Z+0SiGyCRs5W2cQcRk+S00_w@mail.gmail.com>
Message-ID: <BANLkTinsmex6_koUuk34ts4Sov3x7T1Qtw@mail.gmail.com>

On 11 April 2011 23:12, Magnus Enger <magnus at enger.priv.no> wrote:
> On 8 April 2011 18:22, Paul Poulain <paul.poulain at biblibre.com> wrote:
>> Just a special thanks to Magnus, that came from Norway, and to Katrin,
>> that came from Germany. We should send some picture we've taken very soon !
>
> Just a special thanks to BibLibre for organizing and hosting the
> hackfest in the best way possible! Being the only Koha hacker in
> Scandinavia, getting to spend some time with people with similar
> interests every now and then is just great! Maybe we could make a
> European hackfest a yearly tradition?
>
How about 6 monthly  ... a month ahead of each release :)

Chris

From magnus at enger.priv.no  Mon Apr 11 13:24:02 2011
From: magnus at enger.priv.no (Magnus Enger)
Date: Mon, 11 Apr 2011 13:24:02 +0200
Subject: [Koha-devel] Hacker's corner, wk14 / Hackfest Europe
In-Reply-To: <BANLkTinsmex6_koUuk34ts4Sov3x7T1Qtw@mail.gmail.com>
References: <4D9F365E.8090207@biblibre.com>
	<BANLkTikym-Z+0SiGyCRs5W2cQcRk+S00_w@mail.gmail.com>
	<BANLkTinsmex6_koUuk34ts4Sov3x7T1Qtw@mail.gmail.com>
Message-ID: <BANLkTi=+rds7T-Xw-OP_AtihPQQ9wTqe5w@mail.gmail.com>

On 11 April 2011 13:14, Chris Cormack <chris at bigballofwax.co.nz> wrote:
> On 11 April 2011 23:12, Magnus Enger <magnus at enger.priv.no> wrote:
>> On 8 April 2011 18:22, Paul Poulain <paul.poulain at biblibre.com> wrote:
>>> Just a special thanks to Magnus, that came from Norway, and to Katrin,
>>> that came from Germany. We should send some picture we've taken very soon !
>>
>> Just a special thanks to BibLibre for organizing and hosting the
>> hackfest in the best way possible! Being the only Koha hacker in
>> Scandinavia, getting to spend some time with people with similar
>> interests every now and then is just great! Maybe we could make a
>> European hackfest a yearly tradition?
>>
> How about 6 monthly ?... a month ahead of each release :)

That would be absolutely fine by me, it's just that I'm afraid I would
not be able to travel to 2 hackfests and 1 KohaCon every year... ;-)

Best regards,
Magnus

From dschust1 at gmail.com  Mon Apr 11 14:42:04 2011
From: dschust1 at gmail.com (David Schuster)
Date: Mon, 11 Apr 2011 07:42:04 -0500
Subject: [Koha-devel] Hacker's corner, wk14 / Hackfest Europe
In-Reply-To: <BANLkTi=+rds7T-Xw-OP_AtihPQQ9wTqe5w@mail.gmail.com>
References: <4D9F365E.8090207@biblibre.com>
	<BANLkTikym-Z+0SiGyCRs5W2cQcRk+S00_w@mail.gmail.com>
	<BANLkTinsmex6_koUuk34ts4Sov3x7T1Qtw@mail.gmail.com>
	<BANLkTi=+rds7T-Xw-OP_AtihPQQ9wTqe5w@mail.gmail.com>
Message-ID: <BANLkTikVu0ybupT7-EYjuKrRJC-=k6MO8Q@mail.gmail.com>

Just an idea, but what about having the hackfest at the KohaCon happen right
before a release!  That way the release manager would be there to work with
everyone on blockers and possibly get the blockers out of the way.  Then 2
weeks or so after the KohaCon there would be a "release"...


From anne-lena.westrum at kul.oslo.kommune.no  Mon Apr 11 16:22:33 2011
From: anne-lena.westrum at kul.oslo.kommune.no (Anne-Lena Westrum)
Date: Mon, 11 Apr 2011 16:22:33 +0200
Subject: [Koha-devel] Fwd: Generating transactions
Message-ID: <78D65DF90A89FD4A9EE037FB259A4BDDC7C24EAAA4@CL123944.oslofelles.oslo.kommune.no>

Hello,

Thank you Chris, John and Magnus for your reply! :)

Surely the best result would be if we could load our transaction data into Koha. This does however sound like a fairly comprehensive task, and would more or less look like a complete migration. 

That is not what we want at this moment. Mainly because we do not have access to the data, but they are also connected with an intricate privacy policy. It is not a trivial - or cheap - thing for us to get an export of the transaction data.

As you understand; dummydata is still preferable. But I guess I shouldn't get my hopes up for a script like the one I described... :(

It would be very interesting to know if there exists a step-by-step manual for migrating transaction data. What kind of format (or protocol) is used to import this kind of data into Koha?

-AnneLena-


_______________________________________________
Hi Anne-Lenna:

Years ago we tried to write such a script but it was much more
complicated than we expected. ?For proof of concepts and demo purposes
why not just load, from your current ILS, your transaction data into
Koha? ?You will have to learn how to do this anyway so why not work
out the transaction transfer now.

John Brice
Executive Director
Meadville Public Library

From anne-lena.westrum at kul.oslo.kommune.no  Mon Apr 11 16:51:56 2011
From: anne-lena.westrum at kul.oslo.kommune.no (Anne-Lena Westrum)
Date: Mon, 11 Apr 2011 16:51:56 +0200
Subject: [Koha-devel] Generating transactions
In-Reply-To: <4DA311B0.3070509@mdah.state.ms.us>
References: <4D9DB977.5090505@kul.oslo.kommune.no>,
	<4DA311B0.3070509@mdah.state.ms.us>
Message-ID: <78D65DF90A89FD4A9EE037FB259A4BDDC7C24EAAA7@CL123944.oslofelles.oslo.kommune.no>

I think the proper word to describe my word "transactions" with is circulations (pardon my somewhat Norwegian-English use of terms). 

We need to generate loans and submissions, and preferably also some other status changes (fex lost, not in place, ordered, reminder sent). 

We have some pretty heavy requirements as to generating statistics. In order to calm the ones working with this, we need to be able to do a convincing demo :)

How did you transfer your circulation history? I guess the crucial part is to get it from your current ILS-vendor?

-AnneLena-

________________________________________
Fra: Linda Culberson [lculber at mdah.state.ms.us]
Sendt: 11. april 2011 16:35
Til: Anne-Lena Westrum
Emne: Re: [Koha-devel] Generating transactions

I'm not sure what you mean by transactions but we transferred our
circulation histories and a little bit of our cataloging history
(bibliographic/item created/modified by whom date).
Would that help?

On 4/7/2011 8:17 AM, Anne-Lena Westrum wrote:
> Dearest Koha developers!
>
> We have recently started a process of testing and evaluating Koha in the
> perspective of a fairly large public library, with a number of different
> branches and departments. This has proven to be a fairly timeconsuming
> task, as we - amongst other things - need to test all the modules and
> compare it to the functionality of our current ILS :)
>
> After importing our records (Normarc), we need to do a demo of the
> different modules. Thus we are in desperate need of a script to generate
> users (approx 500.000) and transactions (3-4 millions) over a period of
> time (4-5 years).
>
> We have had no luck searching for a script like this. Can someone help
> point us in the right direction?
>
> Thank you! :)
>
> Regards,
> Anne-Lena
> --
> Oslo Public Library
> _______________________________________________
> 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/
>
>

--
Linda Culberson                 lculber at mdah.state.ms.us
Archives and Records Services Division
Ms. Dept. of Archives & History
P. O. Box 571
Jackson, MS 39205-0571
Telephone:  601/576-6873
Facsimile:  601/576-6824

From lculber at mdah.state.ms.us  Mon Apr 11 20:22:37 2011
From: lculber at mdah.state.ms.us (Linda Culberson)
Date: Mon, 11 Apr 2011 13:22:37 -0500
Subject: [Koha-devel] Koha - problem with searches/zebra indexing in second
	instance
Message-ID: <4DA346ED.8080904@mdah.state.ms.us>

All,
We created a second instance of Koha using the instructions at 
http://wiki.koha-community.org/wiki/Installing_Multiple_Instances_of_Koha
We dumped the data from our original instance and then reloaded it into 
the koha_test instance.  We have tried to reindex several time by using 
  rebuild_zebra.pl in koha_test
/var/log/koha_test/koha-zebradaemon-output.log and  koha-zebradaemon.err 
are both empty

The error in koha-opac-error_log is
HTML::Template::Pro:in TMPL_LOOP at pos 416:
  PARAM:LOOP:next_loop(0): callback returned null scope


I think it was our install that had a problem because in koha-error_log
I see for the date of the install:
Thu Apr 07 15:04:37 2011] [error] [client X.X.X.X] [Thu Apr  7 15:04:37 
2011] install.pl: C4::Installer::load_sql returned the following errors 
while attempting to load 
/usr/share/koha_test/intranet/cgi-bin/installer/data/mysql/en/mandatory/sysprefs.sql:, 
referer: 
http://koha_test.mdah.state.ms.us:8080/cgi-bin/koha/installer/install.pl
[Thu Apr 07 15:04:37 2011] [error] [client X.X.X.X] [Thu Apr  7 15:04:37 
2011] install.pl: Warning: something's wrong at 
/usr/share/koha_test/lib/C4/Installer.pm line 530., referer: 
http://koha_test.mdah.state.ms.us:8080/cgi-bin/koha/installer/install.pl
[Thu Apr 07 15:04:38 2011] [error] [client X.X.X.X] [Thu Apr  7 15:04:38 
2011] install.pl: C4::Installer::load_sql returned the following errors 
while attempting to load 
/usr/share/koha_test/intranet/cgi-bin/installer/data/mysql/en/mandatory/userflags.sql:, 
referer: 
http://koha_test.mdah.state.ms.us:8080/cgi-bin/koha/installer/install.pl
[Thu Apr 07 15:04:38 2011] [error] [client X.X.X.X] [Thu Apr  7 15:04:38 
2011] install.pl: Warning: something's wrong at 
/usr/share/koha_test/lib/C4/Installer.pm line 530., referer: 
http://koha_test.mdah.state.ms.us:8080/cgi-bin/koha/installer/install.pl
[Thu Apr 07 15:04:38 2011] [error] [client X.X.X.X] [Thu Apr  7 15:04:38 
2011] install.pl: C4::Installer::load_sql returned the following errors 
while attempting to load 
/usr/share/koha_test/intranet/cgi-bin/installer/data/mysql/en/mandatory/userpermissions.sql:, 
referer: 
http://koha_test.mdah.state.ms.us:8080/cgi-bin/koha/installer/install.pl

Any insight/help would be appreciated.

-- 
Linda Culberson			lculber at mdah.state.ms.us
Archives and Records Services Division
Ms. Dept. of Archives & History
P. O. Box 571
Jackson, MS 39205-0571
Telephone:  601/576-6873
Facsimile:  601/576-6824


From fridolyn.somers at gmail.com  Tue Apr 12 10:45:39 2011
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Tue, 12 Apr 2011 10:45:39 +0200
Subject: [Koha-devel] Koha - problem with searches/zebra indexing in
 second instance
In-Reply-To: <4DA346ED.8080904@mdah.state.ms.us>
References: <4DA346ED.8080904@mdah.state.ms.us>
Message-ID: <BANLkTi=7PtEXQ6bkdZrofQUOWtvjtya8ZA@mail.gmail.com>

Hie,

There is one problem with multi instances that you maybe didn't notice :

The environment variables *KOHA_CONF* and *PERL5LIB* are the same for each
instance
(they are redefined in cronjobs and apache conf).
They are mandatory for lauching perl scripts manually.

I think that's why rebuild_zebra doesn't work, it uses the original
instance.

My solution is to use symbolic links to the currently used instance :
for example, I have 2 instance :
*/usr/share/kohaA/ and /etc/kohaA
/usr/share/kohaB/ and /etc/kohaB
*
Create symbolic links :
*ln -s /usr/share/kohaA /usr/share/koha_current
ln -s /etc/kohaA /etc/koha_current*

And (re)define env vars :
*PERL5LIB="/usr/share/koha_current/lib"
KOHA_CONF="/etc/koha_current"*

Now, when you whan to work manually on a instance, be sure that symbolic
links uses the correct instance.
(You may create a bash to manager that)

Regards,

PS : there might be a solution in creating a user per instance that has env
vars in his bashrc.

On Mon, Apr 11, 2011 at 8:22 PM, Linda Culberson
<lculber at mdah.state.ms.us>wrote:

> All,
> We created a second instance of Koha using the instructions at
> http://wiki.koha-community.org/wiki/Installing_Multiple_Instances_of_Koha
> We dumped the data from our original instance and then reloaded it into the
> koha_test instance.  We have tried to reindex several time by using
> rebuild_zebra.pl in koha_test
> /var/log/koha_test/koha-zebradaemon-output.log and  koha-zebradaemon.err
> are both empty
>
> The error in koha-opac-error_log is
> HTML::Template::Pro:in TMPL_LOOP at pos 416:
>  PARAM:LOOP:next_loop(0): callback returned null scope
>
>
> I think it was our install that had a problem because in koha-error_log
> I see for the date of the install:
> Thu Apr 07 15:04:37 2011] [error] [client X.X.X.X] [Thu Apr  7 15:04:37
> 2011] install.pl: C4::Installer::load_sql returned the following errors
> while attempting to load
> /usr/share/koha_test/intranet/cgi-bin/installer/data/mysql/en/mandatory/sysprefs.sql:,
> referer:
> http://koha_test.mdah.state.ms.us:8080/cgi-bin/koha/installer/install.pl
> [Thu Apr 07 15:04:37 2011] [error] [client X.X.X.X] [Thu Apr  7 15:04:37
> 2011] install.pl: Warning: something's wrong at
> /usr/share/koha_test/lib/C4/Installer.pm line 530., referer:
> http://koha_test.mdah.state.ms.us:8080/cgi-bin/koha/installer/install.pl
> [Thu Apr 07 15:04:38 2011] [error] [client X.X.X.X] [Thu Apr  7 15:04:38
> 2011] install.pl: C4::Installer::load_sql returned the following errors
> while attempting to load
> /usr/share/koha_test/intranet/cgi-bin/installer/data/mysql/en/mandatory/userflags.sql:,
> referer:
> http://koha_test.mdah.state.ms.us:8080/cgi-bin/koha/installer/install.pl
> [Thu Apr 07 15:04:38 2011] [error] [client X.X.X.X] [Thu Apr  7 15:04:38
> 2011] install.pl: Warning: something's wrong at
> /usr/share/koha_test/lib/C4/Installer.pm line 530., referer:
> http://koha_test.mdah.state.ms.us:8080/cgi-bin/koha/installer/install.pl
> [Thu Apr 07 15:04:38 2011] [error] [client X.X.X.X] [Thu Apr  7 15:04:38
> 2011] install.pl: C4::Installer::load_sql returned the following errors
> while attempting to load
> /usr/share/koha_test/intranet/cgi-bin/installer/data/mysql/en/mandatory/userpermissions.sql:,
> referer:
> http://koha_test.mdah.state.ms.us:8080/cgi-bin/koha/installer/install.pl
>
> Any insight/help would be appreciated.
>
> --
> Linda Culberson                 lculber at mdah.state.ms.us
> Archives and Records Services Division
> Ms. Dept. of Archives & History
> P. O. Box 571
> Jackson, MS 39205-0571
> Telephone:  601/576-6873
> Facsimile:  601/576-6824
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



-- 
Fridolyn SOMERS
ICT engineer
PROGILONE - Lyon - France
fridolyn.somers at gmail.com
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20110412/85ab10df/attachment.htm>

From tomascohen at gmail.com  Tue Apr 12 11:38:25 2011
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Tue, 12 Apr 2011 06:38:25 -0300
Subject: [Koha-devel] Koha - problem with searches/zebra indexing in
 second instance
In-Reply-To: <BANLkTi=7PtEXQ6bkdZrofQUOWtvjtya8ZA@mail.gmail.com>
References: <4DA346ED.8080904@mdah.state.ms.us>
	<BANLkTi=7PtEXQ6bkdZrofQUOWtvjtya8ZA@mail.gmail.com>
Message-ID: <BANLkTi=R91mVvitZNLvB-UJciD9CjOU3_g@mail.gmail.com>

2011/4/12 Fridolyn SOMERS <fridolyn.somers at gmail.com>:
> Hie,
>
> There is one problem with multi instances that you maybe didn't notice :
>
> The environment variables KOHA_CONF and PERL5LIB are the same for each
> instance
> (they are redefined in cronjobs and apache conf).
> They are mandatory for lauching perl scripts manually.

This is acknowledged in the instructions when creating the cronjob files.

To+

From magnus at enger.priv.no  Tue Apr 12 12:18:31 2011
From: magnus at enger.priv.no (Magnus Enger)
Date: Tue, 12 Apr 2011 12:18:31 +0200
Subject: [Koha-devel] Generating transactions
In-Reply-To: <BANLkTinuEnTcMnO-4B2LEQK=MB0h6tARVA@mail.gmail.com>
References: <4D9DB977.5090505@kul.oslo.kommune.no>
	<BANLkTi=iBfb3GxiM1XouhJGQ37fcREeB3Q@mail.gmail.com>
	<BANLkTinuEnTcMnO-4B2LEQK=MB0h6tARVA@mail.gmail.com>
Message-ID: <BANLkTi==VFo6hqPXG32eL4B_prvqnz2rsQ@mail.gmail.com>

On 9 April 2011 09:55, Magnus Enger <magnus at enger.priv.no> wrote:
> On 7 April 2011 22:56, Chris Cormack <chris at bigballofwax.co.nz> wrote:
>> As far as I know such a
>> script does not exist. I would offer to write one, as it sounds like
>> fun, but I am in the middle of release management work. I am sure
>> however that one of the other developers could do this.
>
> I thought it sounded like fun too, so I have started to work on one
> during the trip to and from Marseille. It's not finished yet, but I
> hope to get a long, good wait for the last plane home to Bod?, and I
> will let you know when it can be tested.

Here is a basic version of the script for generating patrons:
https://github.com/MagnusEnger/LibrioTools/blob/master/sim/patrons.pl
See here for some context:
https://github.com/MagnusEnger/LibrioTools/tree/master/sim

I'm sort of stuck on the script for the actual transactions, though:
https://github.com/MagnusEnger/LibrioTools/blob/master/sim/circ.pl
The call to C4::Circulation::AddIssue() results in this error:

Can't use an undefined value as a HASH reference at
/home/magnus/scripts/kohanor32/C4/Circulation.pm line 1048.

Line 1048 and it's surroundings in Circulation.pm looks like this:
http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=C4/Circulation.pm;h=b977524b3f871477d2d18f5a8ba4150853ae68f0;hb=HEAD#l1048

1042         unless ($datedue) {
1043             my $itype = (
C4::Context->preference('item-level_itypes') ) ? $biblio->{'itype'} :
$biblio->{'itemtype'};
1044             $datedue = CalcDateDue( C4::Dates->new( $issuedate,
'iso' ), $itype, $branch, $borrower );
1045
1046         }
1047         $sth->execute(
1048             $borrower->{'borrowernumber'},      # borrowernumber
1049             $item->{'itemnumber'},              # itemnumber
1050             $issuedate,                         # issuedate
1051             $datedue->output('iso'),            # date_due
1052             C4::Context->userenv->{'branch'}    # branchcode
1053         );

When i introduce a "die Dumper $borrower;" after line 1046 i get what
looks like a perfectly accpetable representation of a borrower, and I
can't for the life of me understand why it should be undefined two
lines further down.

If anyone with a keener eye than mine should find this to be an
interesting challenge I'm all ears... ;-)

Best regards,
Magnus Enger
libriotech.no

From fridolyn.somers at gmail.com  Tue Apr 12 13:12:56 2011
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Tue, 12 Apr 2011 13:12:56 +0200
Subject: [Koha-devel] Koha - problem with searches/zebra indexing in
 second instance
In-Reply-To: <BANLkTi=R91mVvitZNLvB-UJciD9CjOU3_g@mail.gmail.com>
References: <4DA346ED.8080904@mdah.state.ms.us>
	<BANLkTi=7PtEXQ6bkdZrofQUOWtvjtya8ZA@mail.gmail.com>
	<BANLkTi=R91mVvitZNLvB-UJciD9CjOU3_g@mail.gmail.com>
Message-ID: <BANLkTikHAqhtHNyqppqV=xuRJ443KoeOYA@mail.gmail.com>

On Tue, Apr 12, 2011 at 11:38 AM, Tomas Cohen Arazi <tomascohen at gmail.com>wrote:

> 2011/4/12 Fridolyn SOMERS <fridolyn.somers at gmail.com>:
> > Hie,
> >
> > There is one problem with multi instances that you maybe didn't notice :
> >
> > The environment variables KOHA_CONF and PERL5LIB are the same for each
> > instance
> > (they are redefined in cronjobs and apache conf).
> > They are mandatory for lauching perl scripts manually.
>
> This is acknowledged in the instructions when creating the cronjob files.
>
> To+
>

Yes I agree for cronjobs.
But I understood the problem was when lauching a script manually.
For example, recreating Zebra database :
*perl /usr/share/koha/misc/migration_tools/rebuild_zebra.pl -b -v -r*

In this case, the script looks for C4::Context using the PERL5LIB env var.

Regards,

-- 
Fridolyn SOMERS
ICT engineer
PROGILONE - Lyon - France
fridolyn.somers at gmail.com
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20110412/3e998989/attachment.htm>

From conan at lugmen.org.ar  Tue Apr 12 14:50:54 2011
From: conan at lugmen.org.ar (Fernando Canizo)
Date: Tue, 12 Apr 2011 09:50:54 -0300
Subject: [Koha-devel] bug in marc_subfield_structure table definition?
Message-ID: <4DA44AAE.40105@lugmen.org.ar>

I would file a bug, but since I'm too new here I preferred to ask before.

Current marc_subfield_structure table definition looks like this:

CREATE TABLE `marc_subfield_structure` (
...
   `authorised_value` varchar(20) default NULL,
...);

That column points to 'category' in authorised_values table, which is 
defined like this:

CREATE TABLE `authorised_values` (
...
   `category` varchar(10) NOT NULL default '',
...);

Two questions and a possible digression:

Q1. Shouldn't both be equal?
Q2. Shouldn't authorised_value in marc_subfield_structure be a foreign 
key referencing category on authorised_values table?

The quick solution for this is to make authorised_value a varchar(10) in 
marc_subfield_structure, since all other tables pointing to 
authorised_values.category use that.

Making it also a foreign key would be desirable to add database consistency.

Should I file a bug or I'm seeing this in a wrong way?

Note: the digression grew too extensive, I'll hear answers to before 
going with it.

-- 
Fernando Canizo (a.k.a. conan) - http://conan.muriandre.com/
GCS d? s:+ a C++ P--- L++++ E--- W+++ w--- M-- PE-- !tv b+++ h---- y+++

From gmcharlt at gmail.com  Tue Apr 12 14:58:09 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Tue, 12 Apr 2011 08:58:09 -0400
Subject: [Koha-devel] bug in marc_subfield_structure table definition?
In-Reply-To: <4DA44AAE.40105@lugmen.org.ar>
References: <4DA44AAE.40105@lugmen.org.ar>
Message-ID: <BANLkTi=U5HJkSkuZuKnuCt+_JagmbZP4gg@mail.gmail.com>

Hi,

On Tue, Apr 12, 2011 at 8:50 AM, Fernando Canizo <conan at lugmen.org.ar> wrote:
> Q1. Shouldn't both be equal?

Yes.

> Q2. Shouldn't authorised_value in marc_subfield_structure be a foreign key
> referencing category on authorised_values table?

Yes.  But note that implementing this would mean reshuffling the
installation SQL scripts a bit.

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From lculber at mdah.state.ms.us  Tue Apr 12 16:06:42 2011
From: lculber at mdah.state.ms.us (Linda Culberson)
Date: Tue, 12 Apr 2011 09:06:42 -0500
Subject: [Koha-devel] Koha - problem with searches/zebra indexing in
	second instance
In-Reply-To: <BANLkTikHAqhtHNyqppqV=xuRJ443KoeOYA@mail.gmail.com>
References: <4DA346ED.8080904@mdah.state.ms.us>
	<BANLkTi=7PtEXQ6bkdZrofQUOWtvjtya8ZA@mail.gmail.com>
	<BANLkTi=R91mVvitZNLvB-UJciD9CjOU3_g@mail.gmail.com>
	<BANLkTikHAqhtHNyqppqV=xuRJ443KoeOYA@mail.gmail.com>
Message-ID: <4DA45C72.9000809@mdah.state.ms.us>

Yes, Fridolyn is correct,  the problem is when launching the cronjob 
manually using rebuild_zebra.pl -v -b -r
I added one record manually into the catalog, and that one is showing 
up.  But the ones that were loaded by taking from the primary instance 
(we duplicated the database) don't come up in the searches.

Is duplicating the database the problem?

Thanks again for your help.

On 4/12/2011 6:12 AM, Fridolyn SOMERS wrote:
>
>
> On Tue, Apr 12, 2011 at 11:38 AM, Tomas Cohen Arazi
> <tomascohen at gmail.com <mailto:tomascohen at gmail.com>> wrote:
>
>     2011/4/12 Fridolyn SOMERS <fridolyn.somers at gmail.com
>     <mailto:fridolyn.somers at gmail.com>>:
>      > Hie,
>      >
>      > There is one problem with multi instances that you maybe didn't
>     notice :
>      >
>      > The environment variables KOHA_CONF and PERL5LIB are the same for
>     each
>      > instance
>      > (they are redefined in cronjobs and apache conf).
>      > They are mandatory for lauching perl scripts manually.
>
>     This is acknowledged in the instructions when creating the cronjob
>     files.
>
>     To+
>
>
> Yes I agree for cronjobs.
> But I understood the problem was when lauching a script manually.
> For example, recreating Zebra database :
> /perl /usr/share/koha/misc/migration_tools/rebuild_zebra.pl
> <http://rebuild_zebra.pl> -b -v -r/
>
> In this case, the script looks for C4::Context using the PERL5LIB env var.
>
> Regards,
>
> --
> Fridolyn SOMERS
> ICT engineer
> PROGILONE - Lyon - France
> fridolyn.somers at gmail.com <mailto:fridolyn.somers at gmail.com>

-- 
Linda Culberson			lculber at mdah.state.ms.us
Archives and Records Services Division
Ms. Dept. of Archives & History
P. O. Box 571
Jackson, MS 39205-0571
Telephone:  601/576-6873
Facsimile:  601/576-6824


From lculber at mdah.state.ms.us  Tue Apr 12 16:52:19 2011
From: lculber at mdah.state.ms.us (Linda Culberson)
Date: Tue, 12 Apr 2011 09:52:19 -0500
Subject: [Koha-devel] Koha - problem with searches/zebra indexing in
	second instance
In-Reply-To: <BANLkTikHAqhtHNyqppqV=xuRJ443KoeOYA@mail.gmail.com>
References: <4DA346ED.8080904@mdah.state.ms.us>
	<BANLkTi=7PtEXQ6bkdZrofQUOWtvjtya8ZA@mail.gmail.com>
	<BANLkTi=R91mVvitZNLvB-UJciD9CjOU3_g@mail.gmail.com>
	<BANLkTikHAqhtHNyqppqV=xuRJ443KoeOYA@mail.gmail.com>
Message-ID: <4DA46723.3090109@mdah.state.ms.us>

Yes, Fridolyn is correct,  the problem is when launching the cronjob 
manually using rebuild_zebra.pl -v -b -r
I added one record manually into the catalog, and that one is showing 
up.  But the ones that were loaded by taking from the primary instance 
(we duplicated the database) don't come up in the searches. Is there a 
"correct" or prescribed method of duplicating a database that we should 
be following?

We are going to try Fridolyn's method of dealing with the variables.

Thanks to all for your help.

On 4/12/2011 6:12 AM, Fridolyn SOMERS wrote:
>
>
> On Tue, Apr 12, 2011 at 11:38 AM, Tomas Cohen Arazi
> <tomascohen at gmail.com <mailto:tomascohen at gmail.com>> wrote:
>
>     2011/4/12 Fridolyn SOMERS <fridolyn.somers at gmail.com
>     <mailto:fridolyn.somers at gmail.com>>:
>      > Hie,
>      >
>      > There is one problem with multi instances that you maybe didn't
>     notice :
>      >
>      > The environment variables KOHA_CONF and PERL5LIB are the same for
>     each
>      > instance
>      > (they are redefined in cronjobs and apache conf).
>      > They are mandatory for lauching perl scripts manually.
>
>     This is acknowledged in the instructions when creating the cronjob
>     files.
>
>     To+
>
>
> Yes I agree for cronjobs.
> But I understood the problem was when lauching a script manually.
> For example, recreating Zebra database :
> /perl /usr/share/koha/misc/migration_tools/rebuild_zebra.pl
> <http://rebuild_zebra.pl> -b -v -r/
>
> In this case, the script looks for C4::Context using the PERL5LIB env var.
>
> Regards,
>
> --
> Fridolyn SOMERS
> ICT engineer
> PROGILONE - Lyon - France
> fridolyn.somers at gmail.com <mailto:fridolyn.somers at gmail.com>

-- 
Linda Culberson			lculber at mdah.state.ms.us
Archives and Records Services Division
Ms. Dept. of Archives & History
P. O. Box 571
Jackson, MS 39205-0571
Telephone:  601/576-6873
Facsimile:  601/576-6824


From oleonard at myacpl.org  Tue Apr 12 21:50:45 2011
From: oleonard at myacpl.org (Owen Leonard)
Date: Tue, 12 Apr 2011 15:50:45 -0400
Subject: [Koha-devel] How to convert a HTML::Template::Pro template to
	Template::Toolkit
In-Reply-To: <20110410204234.GN8495@rorohiko>
References: <20110410204234.GN8495@rorohiko>
Message-ID: <BANLkTim=f1wnZSQAPTJxf_mi_t36U9LBaA@mail.gmail.com>

> And run
> ./installer/html-template-to-template-toolkit.pl ?--koharoot /path/to/the/root
>
> This will convert all the templates

I was just working on converting the branch with all my jQueryUI work
and found that at the end of the process I still had to copy my
updated js, css, and image files into the directory with converted TT
files. It turns out I should have been using "-c" to do this
automatically:

./installer/html-template-to-template-toolkit.pl  -c --koharoot
/path/to/the/root

  -- Owen

-- 
Web Developer
Athens County Public Libraries
http://www.myacpl.org

From lculber at mdah.state.ms.us  Tue Apr 12 23:01:25 2011
From: lculber at mdah.state.ms.us (Linda Culberson)
Date: Tue, 12 Apr 2011 16:01:25 -0500
Subject: [Koha-devel] Koha print circulation slips
Message-ID: <4DA4BDA5.3090908@mdah.state.ms.us>

All,
I am trying to find a way to print circulation slips (hold/checkout) 
automatically.  Has anyone else tried to do this?
Thanks!
-- 
Linda Culberson			lculber at mdah.state.ms.us
Archives and Records Services Division
Ms. Dept. of Archives & History
P. O. Box 571
Jackson, MS 39205-0571
Telephone:  601/576-6873
Facsimile:  601/576-6824


From tomascohen at gmail.com  Wed Apr 13 03:01:18 2011
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Tue, 12 Apr 2011 22:01:18 -0300
Subject: [Koha-devel] Koha print circulation slips
In-Reply-To: <4DA4BDA5.3090908@mdah.state.ms.us>
References: <4DA4BDA5.3090908@mdah.state.ms.us>
Message-ID: <BANLkTimsCw68n0g8LEoFRBw8NXyhX9vYKQ@mail.gmail.com>

On Tue, Apr 12, 2011 at 6:01 PM, Linda Culberson
<lculber at mdah.state.ms.us> wrote:
> All,
> I am trying to find a way to print circulation slips (hold/checkout)
> automatically. ?Has anyone else tried to do this?

Take a look at
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4389
I'll rebase it so it (hopefully) hits master.

To+

From srdjan at catalyst.net.nz  Wed Apr 13 03:38:31 2011
From: srdjan at catalyst.net.nz (Srdjan)
Date: Wed, 13 Apr 2011 11:38:31 +1000
Subject: [Koha-devel] Issues table and foreign keys  in general
Message-ID: <4DA4FE97.2040904@catalyst.net.nz>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I have noticed some things:

1. issues table has nullable borrowernumber and itemnumber; foreign
key constraints are consequently declared as "ON DELETE SET NULL ON
UPDATE SET NULL"

2. That is not an isolated issue, there are many cases where foreign
key field/constraints are declared like that

Can anyone shed more light, that looksvery wrong to me.

Thanks,
Srdjan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2k/pcACgkQX6p/D9UE7dy2fQCfZP/QeVQSb7VNNMJvA5yYWdBj
AvAAn0fRuZ1KinfIiIIWCR+EgXhmYBu8
=2WSQ
-----END PGP SIGNATURE-----


From gmcharlt at gmail.com  Wed Apr 13 15:40:01 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Wed, 13 Apr 2011 09:40:01 -0400
Subject: [Koha-devel] Issues table and foreign keys in general
In-Reply-To: <4DA4FE97.2040904@catalyst.net.nz>
References: <4DA4FE97.2040904@catalyst.net.nz>
Message-ID: <BANLkTimXwYo+vy+OKUf12CbZpRq=RDM4Aw@mail.gmail.com>

Hi,

On Tue, Apr 12, 2011 at 9:38 PM, Srdjan <srdjan at catalyst.net.nz> wrote:
> 1. issues table has nullable borrowernumber and itemnumber; foreign
> key constraints are consequently declared as "ON DELETE SET NULL ON
> UPDATE SET NULL"
>
> 2. That is not an isolated issue, there are many cases where foreign
> key field/constraints are declared like that
>
> Can anyone shed more light, that looksvery wrong to me.

And it is very wrong; this should be tightened up.  As to why?
Reasons best hidden in the mists of time, no doubt.

In the case of issues, I think it's pretty clear that both itemnumber
and borrowernumber should be non-NULL and have foreign key
constraints.  I suggest ON DELETE RESTRICT ON UPDATE CASCADE; if you
are deleting an item record or a patron, the application logic needs
to do the right thing if for whatever reason a library really wants to
delete a record that has an outstanding loan on it.

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From lrea at nekls.org  Wed Apr 13 15:47:39 2011
From: lrea at nekls.org (Liz Rea)
Date: Wed, 13 Apr 2011 08:47:39 -0500
Subject: [Koha-devel] Koha print circulation slips
In-Reply-To: <4DA4BDA5.3090908@mdah.state.ms.us>
References: <4DA4BDA5.3090908@mdah.state.ms.us>
Message-ID: <D0C70BB7-3938-4B9E-8060-2DF2FA24ACCE@nekls.org>

Linda,
This configuration information may help you, it is what we do to configure our receipt printers to print automatically.

http://www.nexpresslibrary.org/go-live/configure-your-receipt-printers/

You can also do this with a version of portable firefox, used only for Koha, that has the receipt printer configurations built in. I'm happy to provide direction in how to get that working as well (there are a few tricks to it).

Liz Rea
NEKLS

On Apr 12, 2011, at 4:01 PM, Linda Culberson wrote:

> All,
> I am trying to find a way to print circulation slips (hold/checkout) automatically.  Has anyone else tried to do this?
> Thanks!
> -- 
> Linda Culberson			lculber at mdah.state.ms.us
> Archives and Records Services Division
> Ms. Dept. of Archives & History
> P. O. Box 571
> Jackson, MS 39205-0571
> Telephone:  601/576-6873
> Facsimile:  601/576-6824
> 
> _______________________________________________
> 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/20110413/9fd17e69/attachment.htm>

From lculber at mdah.state.ms.us  Wed Apr 13 15:57:51 2011
From: lculber at mdah.state.ms.us (Linda Culberson)
Date: Wed, 13 Apr 2011 08:57:51 -0500
Subject: [Koha-devel] Koha print circulation slips
In-Reply-To: <D0C70BB7-3938-4B9E-8060-2DF2FA24ACCE@nekls.org>
References: <4DA4BDA5.3090908@mdah.state.ms.us>
	<D0C70BB7-3938-4B9E-8060-2DF2FA24ACCE@nekls.org>
Message-ID: <4DA5ABDF.6090508@mdah.state.ms.us>

What wonderfully detailed information! Thank you!
Linda

On 4/13/2011 8:47 AM, Liz Rea wrote:
> Linda,
> This configuration information may help you, it is what we do to
> configure our receipt printers to print automatically.
>
> http://www.nexpresslibrary.org/go-live/configure-your-receipt-printers/
>
> <http://www.nexpresslibrary.org/go-live/configure-your-receipt-printers/>You
> can also do this with a version of portable firefox, used only for Koha,
> that has the receipt printer configurations built in. I'm happy to
> provide direction in how to get that working as well (there are a few
> tricks to it).
>
> Liz Rea
> NEKLS
>
> On Apr 12, 2011, at 4:01 PM, Linda Culberson wrote:
>
>> All,
>> I am trying to find a way to print circulation slips (hold/checkout)
>> automatically. Has anyone else tried to do this?
>> Thanks!
>> --
>> Linda Culberson lculber at mdah.state.ms.us <mailto:lculber at mdah.state.ms.us>
>> Archives and Records Services Division
>> Ms. Dept. of Archives & History
>> P. O. Box 571
>> Jackson, MS 39205-0571
>> Telephone: 601/576-6873
>> Facsimile: 601/576-6824
>>
>> _______________________________________________
>> 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/
>

-- 
Linda Culberson			lculber at mdah.state.ms.us
Archives and Records Services Division
Ms. Dept. of Archives & History
P. O. Box 571
Jackson, MS 39205-0571
Telephone:  601/576-6873
Facsimile:  601/576-6824


From lrea at nekls.org  Wed Apr 13 16:07:24 2011
From: lrea at nekls.org (Liz Rea)
Date: Wed, 13 Apr 2011 09:07:24 -0500
Subject: [Koha-devel] Koha print circulation slips
In-Reply-To: <4DA5ABDF.6090508@mdah.state.ms.us>
References: <4DA4BDA5.3090908@mdah.state.ms.us>
	<D0C70BB7-3938-4B9E-8060-2DF2FA24ACCE@nekls.org>
	<4DA5ABDF.6090508@mdah.state.ms.us>
Message-ID: <0F6C2516-6E8F-4217-BA85-1E55ADB1B404@nekls.org>

This information can now be found on the Koha wiki as well, at http://wiki.koha-community.org/wiki/Configure_Automatic_Receipt_Printing

:)

Liz Rea
NEKLS

On Apr 13, 2011, at 8:57 AM, Linda Culberson wrote:

> What wonderfully detailed information! Thank you!
> Linda
> 
> On 4/13/2011 8:47 AM, Liz Rea wrote:
>> Linda,
>> This configuration information may help you, it is what we do to
>> configure our receipt printers to print automatically.
>> 
>> http://www.nexpresslibrary.org/go-live/configure-your-receipt-printers/
>> 
>> <http://www.nexpresslibrary.org/go-live/configure-your-receipt-printers/>You
>> can also do this with a version of portable firefox, used only for Koha,
>> that has the receipt printer configurations built in. I'm happy to
>> provide direction in how to get that working as well (there are a few
>> tricks to it).
>> 
>> Liz Rea
>> NEKLS
>> 
>> On Apr 12, 2011, at 4:01 PM, Linda Culberson wrote:
>> 
>>> All,
>>> I am trying to find a way to print circulation slips (hold/checkout)
>>> automatically. Has anyone else tried to do this?
>>> Thanks!
>>> --
>>> Linda Culberson lculber at mdah.state.ms.us <mailto:lculber at mdah.state.ms.us>
>>> Archives and Records Services Division
>>> Ms. Dept. of Archives & History
>>> P. O. Box 571
>>> Jackson, MS 39205-0571
>>> Telephone: 601/576-6873
>>> Facsimile: 601/576-6824
>>> 
>>> _______________________________________________
>>> 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/
>> 
> 
> -- 
> Linda Culberson			lculber at mdah.state.ms.us
> Archives and Records Services Division
> Ms. Dept. of Archives & History
> P. O. Box 571
> Jackson, MS 39205-0571
> Telephone:  601/576-6873
> Facsimile:  601/576-6824
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110413/ec4c08f2/attachment.htm>

From lrea at nekls.org  Wed Apr 13 17:21:06 2011
From: lrea at nekls.org (Liz Rea)
Date: Wed, 13 Apr 2011 10:21:06 -0500
Subject: [Koha-devel] Koha print circulation slips
In-Reply-To: <4DA5ABDF.6090508@mdah.state.ms.us>
References: <4DA4BDA5.3090908@mdah.state.ms.us>
	<D0C70BB7-3938-4B9E-8060-2DF2FA24ACCE@nekls.org>
	<4DA5ABDF.6090508@mdah.state.ms.us>
Message-ID: <D6CEF192-69D0-49FF-AC4E-59FF6A743329@nekls.org>

I also added one more bit of information regarding better use of Firefox as a Koha client:

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

This way you can have a version of firefox with a restricted printer, and a version that can print to any printer.

Liz Rea
NEKLS

On Apr 13, 2011, at 8:57 AM, Linda Culberson wrote:

> What wonderfully detailed information! Thank you!
> Linda
> 
> On 4/13/2011 8:47 AM, Liz Rea wrote:
>> Linda,
>> This configuration information may help you, it is what we do to
>> configure our receipt printers to print automatically.
>> 
>> http://www.nexpresslibrary.org/go-live/configure-your-receipt-printers/
>> 
>> <http://www.nexpresslibrary.org/go-live/configure-your-receipt-printers/>You
>> can also do this with a version of portable firefox, used only for Koha,
>> that has the receipt printer configurations built in. I'm happy to
>> provide direction in how to get that working as well (there are a few
>> tricks to it).
>> 
>> Liz Rea
>> NEKLS
>> 
>> On Apr 12, 2011, at 4:01 PM, Linda Culberson wrote:
>> 
>>> All,
>>> I am trying to find a way to print circulation slips (hold/checkout)
>>> automatically. Has anyone else tried to do this?
>>> Thanks!
>>> --
>>> Linda Culberson lculber at mdah.state.ms.us <mailto:lculber at mdah.state.ms.us>
>>> Archives and Records Services Division
>>> Ms. Dept. of Archives & History
>>> P. O. Box 571
>>> Jackson, MS 39205-0571
>>> Telephone: 601/576-6873
>>> Facsimile: 601/576-6824
>>> 
>>> _______________________________________________
>>> 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/
>> 
> 
> -- 
> Linda Culberson			lculber at mdah.state.ms.us
> Archives and Records Services Division
> Ms. Dept. of Archives & History
> P. O. Box 571
> Jackson, MS 39205-0571
> Telephone:  601/576-6873
> Facsimile:  601/576-6824
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110413/36051799/attachment-0001.htm>

From skushner at mtpl.org  Wed Apr 13 22:50:49 2011
From: skushner at mtpl.org (Scott Kushner)
Date: Wed, 13 Apr 2011 16:50:49 -0400
Subject: [Koha-devel] Installing Koha on a Sun Server?
Message-ID: <3F5DBA7C1433624D870AF4F965358FD660E8A3@exchange.mplmain.mtpl.org>

Does anyone know how to install VirtualBox software on a Sun Solaris
UltraSparc Sunfire 280R server with Solaris 9 OS...? 

 

Any info would be greatly appreciated. 

 

Thanks, 

 

Scott Kushner

Information Systems Librarian

Middletown Public Library

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110413/2dd2b4f4/attachment.htm>

From chris at bigballofwax.co.nz  Wed Apr 13 22:58:12 2011
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Thu, 14 Apr 2011 08:58:12 +1200
Subject: [Koha-devel] Installing Koha on a Sun Server?
In-Reply-To: <3F5DBA7C1433624D870AF4F965358FD660E8A3@exchange.mplmain.mtpl.org>
References: <3F5DBA7C1433624D870AF4F965358FD660E8A3@exchange.mplmain.mtpl.org>
Message-ID: <BANLkTimxUUhsB81fBc7aieOcsFsp4QD_rA@mail.gmail.com>

2011/4/14 Scott Kushner <skushner at mtpl.org>:
> Does anyone know how to install VirtualBox software on a Sun Solaris
> UltraSparc Sunfire 280R server with Solaris 9 OS??
>
>
>
Hmm you'd think it would be doable, given they are all Oracle now.
I have run Koha itself on Solaris before, but not inside virtualbox.

Solaris has its own virtualisation method doesnt it? maybe doing it
with that would be easier

Chris

From glawson at rhcl.org  Wed Apr 13 23:00:32 2011
From: glawson at rhcl.org (glawson)
Date: Wed, 13 Apr 2011 16:00:32 -0500
Subject: [Koha-devel] Installing Koha on a Sun Server?
In-Reply-To: <3F5DBA7C1433624D870AF4F965358FD660E8A3@exchange.mplmain.mtpl.org>
References: <3F5DBA7C1433624D870AF4F965358FD660E8A3@exchange.mplmain.mtpl.org>
Message-ID: <4DA60EF0.8090402@rhcl.org>

You'll probably need to upgrade to the latest version of Solaris, which 
is 10 9/10. That was the word we got from Sun Support when we were 
running an older version of Solaris 10, and had no success getting 
VirtualBox installed.

Once we did that installing VBox was easy, and it's running fine now. We 
have Koha running on Debian in one VM.

http://www.virtualbox.org/wiki/Downloads

Greg
-- 

Greg Lawson
Rolling Hills Consolidated Library
1912 N. Belt Highway
St. Joseph, MO 64506


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



On 04/13/2011 03:50 PM, Scott Kushner wrote:
>
> Does anyone know how to install VirtualBox software on a Sun Solaris 
> UltraSparc Sunfire 280R server with Solaris 9 OS...?
>
> Any info would be greatly appreciated.
>
> Thanks,
>
> Scott Kushner
>
> Information Systems Librarian
>
> Middletown Public Library
>
>
> _______________________________________________
> 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/20110413/f51e3722/attachment.htm>

From dpavlin at rot13.org  Wed Apr 13 23:14:42 2011
From: dpavlin at rot13.org (Dobrica Pavlinusic)
Date: Wed, 13 Apr 2011 23:14:42 +0200
Subject: [Koha-devel] Installing Koha on a Sun Server?
In-Reply-To: <BANLkTimxUUhsB81fBc7aieOcsFsp4QD_rA@mail.gmail.com>
References: <3F5DBA7C1433624D870AF4F965358FD660E8A3@exchange.mplmain.mtpl.org>
	<BANLkTimxUUhsB81fBc7aieOcsFsp4QD_rA@mail.gmail.com>
Message-ID: <20110413211442.GF18963@rot13.org>

On Thu, Apr 14, 2011 at 08:58:12AM +1200, Chris Cormack wrote:
> 2011/4/14 Scott Kushner <skushner at mtpl.org>:
> > Does anyone know how to install VirtualBox software on a Sun Solaris
> > UltraSparc Sunfire 280R server with Solaris 9 OS??
> >
> >
> >
> Hmm you'd think it would be doable, given they are all Oracle now.
> I have run Koha itself on Solaris before, but not inside virtualbox.
> 
> Solaris has its own virtualisation method doesnt it? maybe doing it
> with that would be easier

AFAIK, VirtualBox is x86/amd64 emulator, so it won't work on Sparc
procesor. Download page[1] does provide Solaris version of VirtualBox,
but for x86/amd64.

1: http://www.virtualbox.org/wiki/Downloads

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

From ian.walls at bywatersolutions.com  Thu Apr 14 17:10:22 2011
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Thu, 14 Apr 2011 11:10:22 -0400
Subject: [Koha-devel] Koha Load Testing
Message-ID: <BANLkTim-Woh9HOjOMj36+Jh7CL6rOR1Q3w@mail.gmail.com>

Fellow Kohackers,


Do any of you have a favour script or suite of scripts (or even a method)
for doing load testing against a Koha installation?  I know there are some
scripts available in misc/load_testing, but my understanding is they aren't
terribly useful or current.  Is that correct?

Something that can throw a user-configured amount of punishment at a Koha
server, then report on the results, would be ideal.  The output should
include both the user perspective (response times) and what's happening on
the machine (memory/CPU usage, query times, etc) in the context of the
machine's specifications.

If all this data can be compiled for various configurations, I think we'd
have the makings of a fine, evidence-based Koha Tuning Guide.

Thanks, all!


-Ian

-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
ALA Booth 732
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110414/ddafc066/attachment.htm>

From laurenthdl at alinto.com  Thu Apr 14 17:23:33 2011
From: laurenthdl at alinto.com (LAURENT Henri-Damien)
Date: Thu, 14 Apr 2011 17:23:33 +0200
Subject: [Koha-devel] Koha Load Testing
In-Reply-To: <BANLkTim-Woh9HOjOMj36+Jh7CL6rOR1Q3w@mail.gmail.com>
References: <BANLkTim-Woh9HOjOMj36+Jh7CL6rOR1Q3w@mail.gmail.com>
Message-ID: <4DA71175.6040300@alinto.com>

Le 14/04/2011 17:10, Ian Walls a ?crit :
> Fellow Kohackers,
Hi

> 
> 
> Do any of you have a favour script or suite of scripts (or even a
> method) for doing load testing against a Koha installation?  I know
> there are some scripts available in misc/load_testing, but my
> understanding is they aren't terribly useful or current.  Is that correct?
quite.
I did use ab and siege.
But siege is my favourite.
The nice thing with siege is that you can input a url file that will do
the search with all the url provided.
I used a TransferLog from apache, (One or two days) edited to suit the
siege format for input and that was VERY useful for load testing.
http://opac.distant/cgi-bin/koha/opac-search.pl?idx=&q=l%27explosion+de+la+communication
provides that kind of output

** SIEGE 2.70
** Preparing 30 concurrent users for battle.
The server is now under siege...^C
Lifting the server siege..      done.
Transactions:		         450 hits
Availability:		       100.0 %
Elapsed time:		       64.00 secs
Data transferred:	        2.82 MB
Response time:		        4.25 secs
Transaction rate:	        7.03 trans/sec
Throughput:		        0.04 MB/sec
Concurrency:		       29.92
Successful transactions:       31806
Failed transactions:	           0
Longest transaction:	        7.37
Shortest transaction:	        0.00

The nice thing is that you can use -v to see which elements have errors.

> 
> Something that can throw a user-configured amount of punishment at a
> Koha server, then report on the results, would be ideal.  The output
> should include both the user perspective (response times) and what's
> happening on the machine (memory/CPU usage, query times, etc) in the
> context of the machine's specifications.
Having both in one software would not be possible unless you have a
client and server script to do that... But then ... it could be like an
auditer having some interests in the place. But I may be mislead.

You can use munin or nagios to inspect the server while load testing.

> 
> If all this data can be compiled for various configurations, I think
> we'd have the makings of a fine, evidence-based Koha Tuning Guide.

We already have bits in the koha-devel list for that.
We would need to compile those bits into an administration/setup guide
though on the wiki. #idea
Hope that helps.
-- 
Henri-Damien LAURENT
BibLibre

From lrea at nekls.org  Thu Apr 14 17:37:00 2011
From: lrea at nekls.org (Liz Rea)
Date: Thu, 14 Apr 2011 10:37:00 -0500
Subject: [Koha-devel] Koha Load Testing
In-Reply-To: <4DA71175.6040300@alinto.com>
References: <BANLkTim-Woh9HOjOMj36+Jh7CL6rOR1Q3w@mail.gmail.com>
	<4DA71175.6040300@alinto.com>
Message-ID: <4FC6A241-9CE0-4485-9169-E0E949EF6638@nekls.org>

I created the wiki page... go for it!

(great idea, by the way)

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

Liz
On Apr 14, 2011, at 10:23 AM, LAURENT Henri-Damien wrote:

> Le 14/04/2011 17:10, Ian Walls a ?crit :
>> Fellow Kohackers,
> Hi
> 
>> 
>> 
>> Do any of you have a favour script or suite of scripts (or even a
>> method) for doing load testing against a Koha installation?  I know
>> there are some scripts available in misc/load_testing, but my
>> understanding is they aren't terribly useful or current.  Is that correct?
> quite.
> I did use ab and siege.
> But siege is my favourite.
> The nice thing with siege is that you can input a url file that will do
> the search with all the url provided.
> I used a TransferLog from apache, (One or two days) edited to suit the
> siege format for input and that was VERY useful for load testing.
> http://opac.distant/cgi-bin/koha/opac-search.pl?idx=&q=l%27explosion+de+la+communication
> provides that kind of output
> 
> ** SIEGE 2.70
> ** Preparing 30 concurrent users for battle.
> The server is now under siege...^C
> Lifting the server siege..      done.
> Transactions:		         450 hits
> Availability:		       100.0 %
> Elapsed time:		       64.00 secs
> Data transferred:	        2.82 MB
> Response time:		        4.25 secs
> Transaction rate:	        7.03 trans/sec
> Throughput:		        0.04 MB/sec
> Concurrency:		       29.92
> Successful transactions:       31806
> Failed transactions:	           0
> Longest transaction:	        7.37
> Shortest transaction:	        0.00
> 
> The nice thing is that you can use -v to see which elements have errors.
> 
>> 
>> Something that can throw a user-configured amount of punishment at a
>> Koha server, then report on the results, would be ideal.  The output
>> should include both the user perspective (response times) and what's
>> happening on the machine (memory/CPU usage, query times, etc) in the
>> context of the machine's specifications.
> Having both in one software would not be possible unless you have a
> client and server script to do that... But then ... it could be like an
> auditer having some interests in the place. But I may be mislead.
> 
> You can use munin or nagios to inspect the server while load testing.
> 
>> 
>> If all this data can be compiled for various configurations, I think
>> we'd have the makings of a fine, evidence-based Koha Tuning Guide.
> 
> We already have bits in the koha-devel list for that.
> We would need to compile those bits into an administration/setup guide
> though on the wiki. #idea
> Hope that helps.
> -- 
> Henri-Damien LAURENT
> BibLibre
> _______________________________________________
> 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/20110414/1976f371/attachment.htm>

From paul.a at aandc.org  Fri Apr 15 01:00:48 2011
From: paul.a at aandc.org (Paul)
Date: Thu, 14 Apr 2011 19:00:48 -0400
Subject: [Koha-devel] Koha Load Testing
In-Reply-To: <4DA71175.6040300@alinto.com>
References: <BANLkTim-Woh9HOjOMj36+Jh7CL6rOR1Q3w@mail.gmail.com>
	<BANLkTim-Woh9HOjOMj36+Jh7CL6rOR1Q3w@mail.gmail.com>
Message-ID: <5.2.1.1.2.20110414185522.074a8f28@localhost>

At 05:23 PM 4/14/2011 +0200, LAURENT Henri-Damien wrote:
[snip]
>an input a url file that will do
>the search with all the url provided.
>I used a TransferLog from apache, (One or two days) edited to suit the
>siege format for input and that was VERY useful for load testing.
>http://opac.distant/cgi-bin/koha/opac-search.pl?idx=&q=l%27explosion+de+la+communication
>provides that kind of output
>
>** SIEGE 2.70
>** Preparing 30 concurrent users for battle.
>The server is now under siege...^C
[snip]
>Response time:          4.25 secs
[snip]
>Longest transaction:            7.37
>Shortest transaction:           0.00

Interesting... we have also been doing some timing (imho, one of Koha's 
weaknesses) and had empirically come up with 4-7 seconds. Please see my 
notes para 2. a) at <http://aandc.org/koha/>. (This page also contains 
other questions - if anyone has the time and patience to assist.)

Best regards,

Paul
Tired old sys-admin 


From conan at lugmen.org.ar  Fri Apr 15 13:48:40 2011
From: conan at lugmen.org.ar (Fernando Canizo)
Date: Fri, 15 Apr 2011 08:48:40 -0300
Subject: [Koha-devel] bug in marc_subfield_structure table definition?
In-Reply-To: <BANLkTi=U5HJkSkuZuKnuCt+_JagmbZP4gg@mail.gmail.com>
References: <4DA44AAE.40105@lugmen.org.ar>
	<BANLkTi=U5HJkSkuZuKnuCt+_JagmbZP4gg@mail.gmail.com>
Message-ID: <4DA83098.9020807@lugmen.org.ar>

On 12/04/11 09:58, Galen Charlton wrote:
> On Tue, Apr 12, 2011 at 8:50 AM, Fernando Canizo<conan at lugmen.org.ar>  wrote:
>> Q1. Shouldn't both be equal?
>
> Yes.
>
>> Q2. Shouldn't authorised_value in marc_subfield_structure be a foreign key
>> referencing category on authorised_values table?
>
> Yes.  But note that implementing this would mean reshuffling the
> installation SQL scripts a bit.

With these answers in mind I filed bug 6175. Then added a patch that 
made both equal and varchar(30) because I found data in the SQL scripts 
that added values with more than 20 characters. I also added the constraint.

In fact I got a little ahead of myself and added the constraing for all 
these tables:

auth_subfield_structure
auth_tag_structure
borrower_attribute_types
marc_subfield_structure and
marc_tag_structure

I was too eager and also about to leave work, so I sent the patch 
without testing it, the next day I found the SQL script I modified 
didn't succeded. Then I found that there are insertions which try to 
insert an authorised values (actually they are categories, but the 
column names are authorised_value) which are empty strings, while others 
insert NULL.

I believe the proper set is NULL, since it's the default in the 
definition anyway, but I wanted to ask first here if I should do that 
change: replace all '' insertions with NULL for authorised_value columns 
(which point to category) or either do a nasty insertion in the 
authorised_values table with an empty string category so the other 
insertions can succeed?

Too much words and I don't know if I get myself clear, let's go with 
code better:

Should I replace all lines like:

insert into auth_subfield_structure (..., authorised_value, ...) values 
(..., '', ...)

with:

insert into auth_subfield_structure (..., authorised_value, ...) values 
(..., NULL, ...)

Or should I add this instead:

INSERT INTO authorised_values (category, authorised_value, lib, 
lib_opac, imageurl) VALUES ('', '', '', '', '');

I think the first is the right option, but I want an opinion.

Also I found insertions which point to a non existant categories, like:

INSERT INTO `marc_subfield_structure` (`tagfield`, `tagsubfield`, 
`liblibrarian`, `libopac`, `repeatable`, `mandatory`, `kohafield`, 
`tab`, `authorised_value`, `authtypecode`, `value_builder`, `isurl`, 
`hidden`, `frameworkcode`, `seealso`, `link`, `defaultvalue`) VALUES
('101', 'a', 'langue doc.', '', 1, 1, '', 1, 'LANG', '', '', 0, 0, '', 
'', '', NULL),

For those I'm making this kind of insertions to allow SQL script to succeed:

INSERT INTO authorised_values (category, authorised_value, lib, 
lib_opac, imageurl) VALUES ('LANG', 'FIXME!', 'FIXME!', 'FIXME!', '');

It's "FIXME!" because I don't have the, probably several, values that go 
in there. Is either that or comment the offending lines. What should I 
do, comment them or keep the hackish insertion?

-- 
Fernando Canizo (a.k.a. conan) - http://conan.muriandre.com/
GCS d? s:+ a C++ P--- L++++ E--- W+++ w--- M-- PE-- !tv b+++ h---- y+++

From ian.walls at bywatersolutions.com  Fri Apr 15 14:29:23 2011
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Fri, 15 Apr 2011 08:29:23 -0400
Subject: [Koha-devel] Koha Load Testing
In-Reply-To: <5.2.1.1.2.20110414185522.074a8f28@localhost>
References: <BANLkTim-Woh9HOjOMj36+Jh7CL6rOR1Q3w@mail.gmail.com>
	<4DA71175.6040300@alinto.com>
	<5.2.1.1.2.20110414185522.074a8f28@localhost>
Message-ID: <BANLkTi=ye-541XrJJEStTPkUtRzMmixPGQ@mail.gmail.com>

Paul,


I've also found search to take 4 seconds most times (sometimes higher, if
the system is under some kind of load).  Two recent patches have been
submitted to reduce this to 2 seconds (by disabling Authorized Value images
and search results COinS, which both took up a lot of processing time; these
features can now be toggled with system preferences).

HDL,

I very much look forward to trying out siege, and seeing what data can be
gathered both client side and server side.

Thanks all!


-Ian

On Thu, Apr 14, 2011 at 7:00 PM, Paul <paul.a at aandc.org> wrote:

> At 05:23 PM 4/14/2011 +0200, LAURENT Henri-Damien wrote:
> [snip]
>
>  an input a url file that will do
>> the search with all the url provided.
>> I used a TransferLog from apache, (One or two days) edited to suit the
>> siege format for input and that was VERY useful for load testing.
>>
>> http://opac.distant/cgi-bin/koha/opac-search.pl?idx=&q=l%27explosion+de+la+communication
>> provides that kind of output
>>
>> ** SIEGE 2.70
>> ** Preparing 30 concurrent users for battle.
>> The server is now under siege...^C
>>
> [snip]
>
>  Response time:          4.25 secs
>>
> [snip]
>
>  Longest transaction:            7.37
>> Shortest transaction:           0.00
>>
>
> Interesting... we have also been doing some timing (imho, one of Koha's
> weaknesses) and had empirically come up with 4-7 seconds. Please see my
> notes para 2. a) at <http://aandc.org/koha/>. (This page also contains
> other questions - if anyone has the time and patience to assist.)
>
> Best regards,
>
> Paul
> Tired old sys-admin
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
ALA Booth 732
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110415/1d255fbf/attachment.htm>

From tomascohen at gmail.com  Fri Apr 15 14:43:45 2011
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Fri, 15 Apr 2011 09:43:45 -0300
Subject: [Koha-devel] Koha Load Testing
In-Reply-To: <BANLkTi=ye-541XrJJEStTPkUtRzMmixPGQ@mail.gmail.com>
References: <BANLkTim-Woh9HOjOMj36+Jh7CL6rOR1Q3w@mail.gmail.com>
	<4DA71175.6040300@alinto.com>
	<5.2.1.1.2.20110414185522.074a8f28@localhost>
	<BANLkTi=ye-541XrJJEStTPkUtRzMmixPGQ@mail.gmail.com>
Message-ID: <BANLkTinQCyPRbj=fHKQfya=5bfXH3_3CEw@mail.gmail.com>

2011/4/15 Ian Walls <ian.walls at bywatersolutions.com>:
>
> I very much look forward to trying out siege, and seeing what data can be
> gathered both client side and server side.

Here at UNC we have used 'ab' and 'jmeter' for concurrent load
testing. We used tcpdump on each host and some perl scripts I wrote to
process tcpdum's output (so we can have a measure of completed
connections, completed connections average time, etc).

Saludos
To+

From cnighswonger at foundations.edu  Sat Apr 16 15:50:16 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Sat, 16 Apr 2011 09:50:16 -0400
Subject: [Koha-devel] Koha 3.2.7 is now available
Message-ID: <BANLkTimkR5YkFH7NCM+t_ytt96GNMqbJUQ@mail.gmail.com>

It is with pleasure that I announce the release of Koha 3.2.7.

The package can be retrieved from:

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

You can use the following checksum and signature files to verify the
download:

http://download.koha-community.org/koha-3.02.07.tar.gz.MD5
http://download.koha-community.org/koha-3.02.07.tar.gz.MD5.asc
http://download.koha-community.org/koha-3.02.07.tar.gz.sig

Release notes for 3.2.7 are below the fold.

Come and get it!

RELEASE NOTES FOR KOHA 3.2.7 - 15 April 2011
========================================================================

Koha is the first free and open source software library automation package
(ILS). Development is sponsored by libraries of varying types and sizes,
volunteers, and support companies from around the world.
The website for the Koha project is

http://koha-community.org/

Koha 3.2.7 can be downloaded from:

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

Installation instructions can be found at:

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

Koha 3.2.7 is a bugfix/maintenance release.

Highlights of 3.2.7
======================

Some of the higher profile bugs addressed in this release are:

5646    translated message names on sql level break messaging
5860    Adding duplicate stocknumber will fail silently
6044    Authority is deleted when mergeto and mergefrom are the same
6045    Accepted by is empty when accepting from list
6058    Uncertain price can not be undone

Bugs fixed in 3.2.7
======================

3270    Cancelling a hold request after transfer initiated orphans item
5390    library choice not remaining when searching opac
5555    ISBN search returns bad results
5651    can't use ? character in searches
5817    Malformed author search link breaks sorting on results page
5865    Labels wrap incorrectly when paper width is greater than height
6043    No suggestions showing when independant branches set to OFF
3098    XSLT stylesheet does not obey OPACURLOpenInNewWindow syspref
3203    Some Letters template variables are not available to certain notice
types
3326    xml entity refs display incorrectly in results page if exported and
indexed as xml
3595    Items seen at checkin should always go to 1st priority hold
3629    search limit by group is not OK
3727    If item type is mandatory in marc editor, itemtype is autofilled
4196    Defintion of popularity index into Unimarc setup
4218    Staff client detail page does not show item hold status
4265    Sorting by call number in OPAC is slightly off
4330    Copyright statements out of date
4366    COinS support for MARC21
4870    Damaged status does not prevent items from being selected for
reserves
5305    Resorting results of CCL queries fails in Staff Client
5410    "Right truncation not supported" error when running
link_bibs_to_authorities.pl
5625    late orders report missing titles
5833    opacstylesheet not loading on all pages
5834    Holds link missing when 942$c is not for loan
5862    Incompatibility in ajax.js with "localName" for Internet Explorer
5879    Biblio.pm : fix isbd syspref and default location
5883    UTF-8 characters in items (952) get encoded wrong when the record is
modified.
5889    Allow message names to be translatable
5902    Locations should default to current library in add item screen
5909    Authorities : SetUTF8Flag on any incoming data
5924    Authorities search : Heading Main is defined in unimarc record.abs
5940    Update Help Files for 3.4
5960    Itemtype icons not showing in search results
5962    Budgets are showing when they shouldn't on acqui-home.pl
5989    Funds filter does not remember library choice
6040    opac-export.pl can throw an untrapped error when trying to export an
invalid record
6046    Managed by list in suggestions was not created correctly
6047    Authority not added if subfield 3 in biblio
3735    Wrong search results for a few fields in ccl.properties
4943    Search history cookie size limit
5253    runreport.pl does not work with new options (-to, -from, -email,
-format)
5816    table of contents looking for subfield a
5864    Is C4::Serials::GetSubscriptions searching too generally?
5890    Mismatched operator in C4::Auth
5892    opac-user: minor spelling/html changes
5907    Using default authtypecode for authority display
5965    Make sure opac-detail.pl outputs marc in utf-8
5996    Patron import defaults not being set right
6004    checking in an item that needs to be transferred home, and is
on-hold for a patron, causes dual transfer message box
6026    Remove useless condition for export.pl
4878    Command line tool for getting and setting sysprefs

Translations new/updated in 3.2.7
======================

de-DE
es-ES
el-GR
fr-FR
it-IT
nb-NO
nl-BE
pl-PL
pt-PT
ru-RU
sv-SE
tet-i
uk-UA

======================

   Changes since 3.0:

   * The minimum version of Perl required is now 5.8.8.
   * There are a number of new Perl module dependencies.
     Run ./koha_perl_deps.pl -u -m to get a list of
     any new modules to install during upgrade.

Upgrades
======================

The structure of the acquisitions tables have changed significantly
from 3.0.x.  In particular, the budget hierarchy is quite different.
During an upgrade, a new database table is created called fundmapping
that contains a record of how budgets were mapped.  It is strongly
recommended that users of Koha 3.0.x acquisitions carefully review
the results of the upgrade before resuming ordering in Koha 3.2.x.

Documentation
======================

As of Koha 3.2, the Koha manual is now maintained in DocBook.  The
home page for Koha documentation is

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

As of the date of these release notes, several translations of the
Koha manual are available:

English: http://koha-community.org/documentation/3-2-manual/
Spanish: http://koha-community.org/documentation/3-2-manual-es/
French:  http://koha-community.org/documentation/3-2-manual-fr/

The Git repository for the Koha manual can be found at

http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary

Translations
======================

Complete or near-complete translations of the OPAC and staff
interface are available in this release for the following languages:

 * Chinese
 * Danish
 * English (New Zealand)
 * English (USA)
 * French (France)
 * French (Canada)
 * German
 * Greek
 * Hindi
 * Italian
 * Norwegian
 * Portuguese
 * Spanish
 * Turkish

Partial translations are available for various other languages.

The Koha team welcomes additional translations; please see

http://www.kohadocs.org/usersguide/apb.html

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

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

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

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

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

The release team for Koha 3.2 is

Release Manager:        Galen Charlton <gmcharlt at gmail.com>
Documentation Manager:  Nicole Engard <nengard at gmail.com>
Translation Manager:    Chris Cormack <chris at bigallofwax.co.nz>
Release Maintainer (3.0.x):
                       Henri-Damien Laurent <
henridamien.laurent at biblibre.com>
Release Maintainer (3.2.x):
                       Chris Nighswonger <cnighswonger at foundations.edu>

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

We thank the following individuals who contributed patches to Koha 3.2.7:

Alex Arnaud
D Ruth Bavousett
Jared Camins-Esakov
Colin Campbell
Fr??d??rick Capovilla
Chris Cormack
Christophe Croullebois
fdurand
Fr??d??ric Demians
Marcel de Rooy
Nicole C. Engard
Magnus Enger
Katrin Fischer
Janusz Kaczmarek
Henri-Damien LAURENT
Owen Leonard
Julian Maurice
Matthias Meusburger
Sophie Meynieux
Chris Nighswonger
Paul Poulain
Salvador Zaragoza Rubio
Ian Walls
Jesse Weaver

We regret any omissions.  If a contributor has been inadvertantly missed,
please send patch against these release notes to
koha-patches at lists.koha-community.org.

The 3.2.x Release Maintainer especially thanks the 3.4 Release Team and all
who participated in QA for their diligent labors in testing and pushing well
over 570 patches since the 3.2.0 relese. Their continued work very much
makes
possible the release of 3.2.7 on its announced schedule.

Revision control notes
======================

The Koha project uses Git for version control.  The current development
version of Koha can be retrieved by checking out the master branch of

   git://git.koha-community.org/koha.git

The branch for Koha 3.2.x (i.e., this version of Koha and future bugfix
releases) is 3.2.x.

The next major feature release of Koha will be Koha 3.4.0.

Bugs and feature requests
======================

Bug reports and feature requests can be filed at the Koha bug
tracker at

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

Naku te rourou, nau te rourou, ka ora ai te iwi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110416/ae9b5428/attachment.htm>

From paul.poulain at biblibre.com  Sat Apr 16 15:40:44 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Sat, 16 Apr 2011 15:40:44 +0200
Subject: [Koha-devel] Hacker's corner, wk14 / Hackfest Europe
In-Reply-To: <BANLkTikVu0ybupT7-EYjuKrRJC-=k6MO8Q@mail.gmail.com>
References: <4D9F365E.8090207@biblibre.com>	<BANLkTikym-Z+0SiGyCRs5W2cQcRk+S00_w@mail.gmail.com>	<BANLkTinsmex6_koUuk34ts4Sov3x7T1Qtw@mail.gmail.com>	<BANLkTi=+rds7T-Xw-OP_AtihPQQ9wTqe5w@mail.gmail.com>
	<BANLkTikVu0ybupT7-EYjuKrRJC-=k6MO8Q@mail.gmail.com>
Message-ID: <4DA99C5C.7090400@biblibre.com>

Le 11/04/2011 14:42, David Schuster a ?crit :
> Just an idea, but what about having the hackfest at the KohaCon happen
> right before a release!  That way the release manager would be there
> to work with everyone on blockers and possibly get the blockers out of
> the way.  Then 2 weeks or so after the KohaCon there would be a
> "release"...
>
> From my experience the Release manager does a talk about what to
> expect out of the pending release anyway...
>
> Just talking off the top of my head but that would provide for 2
> travel options only and what a bang for your buck on KohaCon!
well... I'm AFK for one week, and plan to announce that BibLibre will
probably organize a hackfest one month before each spring release. And
when i'm back on my keyboard, someone already suggested this idea...

So, yes, we found very profitable for everybody this hackfest, and are
thinking about organizing such a meeting once a year.
In my idea, it must be an easy place to reach. For ppl coming, the
flight or train was not too expensive, no jet lag, short flight
duration, making the trip "easy". So I think we must keep the idea of a
"local hackfest". Maybe there could be one in US too. if it were during
the same week, we could work 24Hx3days (and chris or the next RM would
be overwhelmed by patches to push ;-) )

Anyway, see you next year in Marseille !

-- 
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  Sat Apr 16 15:45:08 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Sat, 16 Apr 2011 15:45:08 +0200
Subject: [Koha-devel] How to convert a HTML::Template::Pro template to
 Template::Toolkit
In-Reply-To: <20110410204234.GN8495@rorohiko>
References: <20110410204234.GN8495@rorohiko>
Message-ID: <4DA99D64.6000004@biblibre.com>

Le 10/04/2011 22:42, Chris Cormack a ?crit :
> Hi All
Hi All too,
> There may be a need for people to convert a template to
> template::toolkit so they can send a patch that will apply cleanly.
thinking of it, there is another problem: we have patches pending that
contains H::T::P parts (see patches to sign-off on bugzilla...) . How
will we deal with them for 3.4/3.6
The same question arises for 3.2 fixes : should we submit 2 patches :
one for H::T::P, one for TT ? just one for HTP or TT, at your option,
RM(aint) take care of the switch to T::T ?

-- 
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  Sat Apr 16 15:56:13 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Sat, 16 Apr 2011 15:56:13 +0200
Subject: [Koha-devel] Issues table and foreign keys in general
In-Reply-To: <BANLkTimXwYo+vy+OKUf12CbZpRq=RDM4Aw@mail.gmail.com>
References: <4DA4FE97.2040904@catalyst.net.nz>
	<BANLkTimXwYo+vy+OKUf12CbZpRq=RDM4Aw@mail.gmail.com>
Message-ID: <4DA99FFD.9040407@biblibre.com>

Le 13/04/2011 15:40, Galen Charlton a ?crit :
> Hi,
>
> On Tue, Apr 12, 2011 at 9:38 PM, Srdjan <srdjan at catalyst.net.nz> wrote:
>> 1. issues table has nullable borrowernumber and itemnumber; foreign
>> key constraints are consequently declared as "ON DELETE SET NULL ON
>> UPDATE SET NULL"
>>
>> 2. That is not an isolated issue, there are many cases where foreign
>> key field/constraints are declared like that
>>
>> Can anyone shed more light, that looksvery wrong to me.
> And it is very wrong; this should be tightened up.  As to why?
> Reasons best hidden in the mists of time, no doubt.
no, no, they are hidden in my memory, I explain:
koha 2.2 used myISAM tables, so no contraints.
one of the first thing I did for 3.0 was to switch to innoDB and add
constraints. When I did that, all issues were in issues table (including
issues already returned)
Then someone from LibLime added the oldissues table, and wrote the code
to move issues to oldissues were applicable.

The SET NULL *MUST BE KEPT* for statistic purposes on checked-in items :
if you delete the item, you still can have usefull informations !
On issues, I agree that we have a problem now = it contains only
checked-out items, that must not be deleted, otherwise the issue will
never be checked-out.
So we have 3 options :
* use a trigger on item deletion, to move the issues to oldissues if
needed. But with mySQL this is not possible
* switch to ON DELETE CASCADE on item deletion, but that will loose some
information for stats (could we accept this, considering deleting an
item that has not been checked-in is very un-common ?)
* add business logic to Koha to move the issue when the item is deleted.
Isn't this already the case ? if it's already the case, then we don't
care of the constraint on mySQL schema, as there won't be anything in
issues, so the case will never happend.

About
> 2. That is not an isolated issue, there are many cases where foreign
> key field/constraints are declared like that
I wrote many of them with a reason that I think needed. Please tell me
which you consider as a problem, i'll tell you :
* why I choose this option if it's me
* that I was not the author of this choice, the author made a mistake
(and if git blame show you i'm the author of a buggy/wrong choice, i'll
argue that someone stole my identity just for this mistake :D )

HTH

-- 
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  Sat Apr 16 17:34:19 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Sat, 16 Apr 2011 11:34:19 -0400
Subject: [Koha-devel] 3.2.x Roadmap Update
Message-ID: <BANLkTimq-oQPnTOFzGEdV25judHM5=X93g@mail.gmail.com>

Hi all,

With the release of 3.2.7 and the eminent release of 3.4.0, I want to let
the community know what my plans are moving forward.

Due to the excellent work during the recent hack-fest sponsored by Biblibre,
there were a multitude of bugfixes which did not make it into 3.2.7. My
plans are to begin work on getting these backported into the 3.2.x branch
over the next week or so. Because there are such a large number, I will be
releasing 3.2.8 on May 15, 2011. I had originally intended to go to a
bi-monthly release schedule for 3.2.x after the release of 3.2.0. This will
still be the case, but will be delayed until the release of 3.2.8.
Subsequent 3.2.x releases will take place on the 15th of the month with
3.4.x releases taking place on the 22nd of the month.

***Translators please take especial note of the above dates.***

As long as there are commits to backport to 3.2.x, I will release on a
bi-monthly schedule. If there are no commits during a two month period, no
release will be made.

If you have template related bugfixes you want included in 3.2.x, it will be
your responsibility to ensure that they apply correctly to the current 3.2.x
branch. With the switch to TT in master, backporting template commits will
be nigh impossible. Of course any related underlying logic changes should be
applicable to the current 3.2.x branch as well.

After the 3.2.10 release, I will add an agenda item for the next monthly IRC
to discuss EOL of the 3.2.x branch. The results of that discussion will
determine the direction of 3.2.x from that point forward.

I plan to handle 3.4.x maintenance in the same fashion as I have handled
3.2.x. If anyone has any suggestions for improvement, please speak up! I'm
very open to suggestions, critiques, etc.

Thanks to everyone for the hard work being put into Koha lately. Things have
moved along at a fantastic rate! Keep up the good work.

Kind Regards,
Chris Nighswonger
Koha 3.2.x/3.4.x Release Maintainer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110416/d5ff2297/attachment.htm>

From cnighswonger at foundations.edu  Sat Apr 16 17:40:45 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Sat, 16 Apr 2011 11:40:45 -0400
Subject: [Koha-devel] How to convert a HTML::Template::Pro template to
	Template::Toolkit
In-Reply-To: <4DA99D64.6000004@biblibre.com>
References: <20110410204234.GN8495@rorohiko> <4DA99D64.6000004@biblibre.com>
Message-ID: <BANLkTi=ctCxbQK_CGzxDj6Q_r=1nVyYQDQ@mail.gmail.com>

On Sat, Apr 16, 2011 at 9:45 AM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Le 10/04/2011 22:42, Chris Cormack a ?crit :
> > Hi All
> Hi All too,
> > There may be a need for people to convert a template to
> > template::toolkit so they can send a patch that will apply cleanly.
> thinking of it, there is another problem: we have patches pending that
> contains H::T::P parts (see patches to sign-off on bugzilla...) . How
> will we deal with them for 3.4/3.6
> The same question arises for 3.2 fixes : should we submit 2 patches :
> one for H::T::P, one for TT ? just one for HTP or TT, at your option,
> RM(aint) take care of the switch to T::T ?
>
>
Speaking as RMaint, I would prefer that template which apply to maintenance
branches be submitted which cleanly apply to that branch. So that would mean
supplying patches against templates which use H::T::P in that format, and
patches against templates using T::T in that format. The rate at which
cleanly applying patches will show up in maintenance releases will be much
faster than those which do not cleanly apply.

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

From cnighswonger at foundations.edu  Sat Apr 16 19:45:08 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Sat, 16 Apr 2011 13:45:08 -0400
Subject: [Koha-devel] DB number incrementing revisited
Message-ID: <BANLkTinP8LfoNA1ZoBvOqf3+MvYWLC7uuw@mail.gmail.com>

Not to beat a dead horse here, but...

What works very well for me as Release Maintainer regarding DB version
numbers is when the patch to updatedatabase.pl simply uses the format:

3.03.XXX

(which some folks are doing)

and no modification is made to kohaversion.pl

In 99% of cases, this applies cleanly and allows me to follow up with a
single patch to adjust the version number in both places.

So I'd love to see everyone adapt this style.

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

From chrisc at catalyst.net.nz  Sat Apr 16 20:41:15 2011
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Sun, 17 Apr 2011 06:41:15 +1200
Subject: [Koha-devel] Issues table and foreign keys in general
In-Reply-To: <4DA99FFD.9040407@biblibre.com>
References: <4DA4FE97.2040904@catalyst.net.nz>
	<BANLkTimXwYo+vy+OKUf12CbZpRq=RDM4Aw@mail.gmail.com>
	<4DA99FFD.9040407@biblibre.com>
Message-ID: <20110416184115.GZ6680@rorohiko>

* Paul Poulain (paul.poulain at biblibre.com) wrote:
> Le 13/04/2011 15:40, Galen Charlton a ?crit :
> > Hi,
> >
> > On Tue, Apr 12, 2011 at 9:38 PM, Srdjan <srdjan at catalyst.net.nz> wrote:
> >> 1. issues table has nullable borrowernumber and itemnumber; foreign
> >> key constraints are consequently declared as "ON DELETE SET NULL ON
> >> UPDATE SET NULL"
> >>
> >> 2. That is not an isolated issue, there are many cases where foreign
> >> key field/constraints are declared like that
> >>
> >> Can anyone shed more light, that looksvery wrong to me.
> > And it is very wrong; this should be tightened up.  As to why?
> > Reasons best hidden in the mists of time, no doubt.
> no, no, they are hidden in my memory, I explain:
> koha 2.2 used myISAM tables, so no contraints.
> one of the first thing I did for 3.0 was to switch to innoDB and add
> constraints. When I did that, all issues were in issues table (including
> issues already returned)
> Then someone from LibLime added the oldissues table, and wrote the code
> to move issues to oldissues were applicable.
> 
> The SET NULL *MUST BE KEPT* for statistic purposes on checked-in items :
> if you delete the item, you still can have usefull informations !
> On issues, I agree that we have a problem now = it contains only
> checked-out items, that must not be deleted, otherwise the issue will
> never be checked-out.
> So we have 3 options :
> * use a trigger on item deletion, to move the issues to oldissues if
> needed. But with mySQL this is not possible
> * switch to ON DELETE CASCADE on item deletion, but that will loose some
> information for stats (could we accept this, considering deleting an
> item that has not been checked-in is very un-common ?)
> * add business logic to Koha to move the issue when the item is deleted.
> Isn't this already the case ? if it's already the case, then we don't
> care of the constraint on mySQL schema, as there won't be anything in
> issues, so the case will never happend.

I disagree, option 4 is to make the change suggested by Srdjan, in which
the database will enforce integrity and make it impossible to delete an
item that  is checked out (has a row in issues). This covers us from
mistakes in code, and from people making mistakes in the database.
DELETE CASCADE is dangerous and should be avoided in this instance. It
means if we make a mistake anywhere deleting an item that is checked
out, the mistake will be compounded as we now delete the row in issues. The set
NULL is nearly as bad, as we now null the column and still have no idea
what it was linked to.


> 
> About
> > 2. That is not an isolated issue, there are many cases where foreign
> > key field/constraints are declared like that
> I wrote many of them with a reason that I think needed. Please tell me
> which you consider as a problem, i'll tell you :
> * why I choose this option if it's me
> * that I was not the author of this choice, the author made a mistake
> (and if git blame show you i'm the author of a buggy/wrong choice, i'll
> argue that someone stole my identity just for this mistake :D )
> 
I think the database should never do this, I think our code should do it if it
is needed. The database should stop us deleting things that are referred
to elsewhere. We should clean up those references before trying to
delete. The database should be the failsafe for us making mistakes, not
allow us to make bigger mistakes :)

Chris

-- 
Chris Cormack
Catalyst IT Ltd.
+64 4 803 2238
PO Box 11-053, Manners St, Wellington 6142, New Zealand
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: </pipermail/koha-devel/attachments/20110417/24efb288/attachment.pgp>

From cnighswonger at foundations.edu  Sat Apr 16 21:50:02 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Sat, 16 Apr 2011 15:50:02 -0400
Subject: [Koha-devel] Important notice regarding patches intended for
	backporting into 3.2.x
Message-ID: <BANLkTik0XD5g8YOvppznYpFHMWqvB5xH6g@mail.gmail.com>

At present the 3.2.x branch is current with master at all applicable
commits.

Due to many possible pitfalls with the switch to T::T, it is imperative that
those submitting patches indicate exactly which patches should be backported
to 3.2.x. It is possible that a change to an underlying perl script to
correct a bug with a T::T template may apply cleanly to the 3.2.x branch and
break H::T::P functionality.

So, moving forward, I will backport only those patches with notes indicating
that the commits should be backported to 3.2.x.

Please take note of this and be sure to make the indication in your commit
message.

Kind Regards,
Chris
Koha 3.2.x/3.4.x Release Maintainer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110416/426caf34/attachment.htm>

From chrisc at catalyst.net.nz  Sun Apr 17 02:18:25 2011
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Sun, 17 Apr 2011 12:18:25 +1200
Subject: [Koha-devel] How to convert a HTML::Template::Pro template to
 Template::Toolkit
In-Reply-To: <BANLkTi=ctCxbQK_CGzxDj6Q_r=1nVyYQDQ@mail.gmail.com>
References: <20110410204234.GN8495@rorohiko> <4DA99D64.6000004@biblibre.com>
	<BANLkTi=ctCxbQK_CGzxDj6Q_r=1nVyYQDQ@mail.gmail.com>
Message-ID: <20110417001825.GB6680@rorohiko>

* Chris Nighswonger (cnighswonger at foundations.edu) wrote:
>    On Sat, Apr 16, 2011 at 9:45 AM, Paul Poulain
>    <[1]paul.poulain at biblibre.com> wrote:
> 
>      Le 10/04/2011 22:42, Chris Cormack a ?crit :
>      > Hi All
>      Hi All too,
>      > There may be a need for people to convert a template to
>      > template::toolkit so they can send a patch that will apply cleanly.
>      thinking of it, there is another problem: we have patches pending that
>      contains H::T::P parts (see patches to sign-off on bugzilla...) . How
>      will we deal with them for 3.4/3.6

As RM, id appreciate people rebase their own, but if they can't they
will need to be either fixed by the person signing off or myself.
Either way they will get in. Of course this only applies to those
submitted for sign off before the string freeze, any new ones of course
should be submitted in a form that applies cleanly.

Chris

>      The same question arises for 3.2 fixes : should we submit 2 patches :
>      one for H::T::P, one for TT ? just one for HTP or TT, at your option,
>      RM(aint) take care of the switch to T::T ?
> 
>    Speaking as RMaint, I would prefer that template which apply to
>    maintenance branches be submitted which cleanly apply to that branch. So
>    that would mean supplying patches against templates which use H::T::P in
>    that format, and patches against templates using T::T in that format. The
>    rate at which cleanly applying patches will show up in maintenance
>    releases will be much faster than those which do not cleanly apply.
> 
>    Kind Regards,
>    Chris
> 
> References
> 
>    Visible links
>    1. mailto:paul.poulain at biblibre.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/


-- 
Chris Cormack
Catalyst IT Ltd.
+64 4 803 2238
PO Box 11-053, Manners St, Wellington 6142, New Zealand
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: </pipermail/koha-devel/attachments/20110417/b6cf5dc4/attachment-0001.pgp>

From paul.a at aandc.org  Mon Apr 18 16:04:00 2011
From: paul.a at aandc.org (Paul)
Date: Mon, 18 Apr 2011 10:04:00 -0400
Subject: [Koha-devel] Subfields 952 $i, $k
Message-ID: <5.2.1.1.2.20110418094426.076ec578@stormy.ca>

[Apologies for cross-posting, users and devel]

Marc 952 $i, $k are not used in "standard" Koha. They can be added to the 
default framework (allowed by Koha), but this appears to require a 
modification to the Mysql structure. Has anyone tried to do this?

Background:  for Serials, we want to add at *item* level "Extended 
Keywords" (952$z is limited to 255 characters) and "Abstracts" (at *biblio* 
level, we use 520 $a and $b.)

This will require new "Koha Fields" - e.g, in the same way that 952$z uses 
"items.itemnotes" we will need to introduce "items.itemkeywords" and 
"items.itemabstracts".

I am looking for suggestions as to how to best add these fields so that 
they can be usefully searched by the OPAC - and of course for any pitfalls 
or showstoppers.

Thanks

Paul
Tired old sys-admin 


From Katrin.Fischer at bsz-bw.de  Mon Apr 18 16:18:12 2011
From: Katrin.Fischer at bsz-bw.de (Fischer, Katrin)
Date: Mon, 18 Apr 2011 16:18:12 +0200
Subject: [Koha-devel] Subfields 952 $i, $k
In-Reply-To: <5.2.1.1.2.20110418094426.076ec578@stormy.ca>
References: <5.2.1.1.2.20110418094426.076ec578@stormy.ca>
Message-ID: <028B1A54D03E7B4482CDCA4EC8F06BFD0130C99D@Bodensee.bsz-bw.de>

Hi Paul, 

in 3.4 a mapping and a new search index was introduced for 952$i and items.stocknumber.

Bug 5839 - Add mapping for items.stocknumber to MARC21
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5839

You can easily add new subfields in your bibliographic frameworks. If you leave the mapping field empty the data will be stored in the more_subfields_xml column. As the name indicates it's stored in a XML format. 

There are not many lowercase letters left for 952. According to the MARC21 Standard it's also possible to use uppercase letters, but I am not completely sure if Koha works correctly if you do. This would need some more testing, although we have done so in the past without running into problems.

For search you would need to add new indexes to your Zebra configuration. This is independent from the way you store the data in your database.

Hope this makes sense and is helpful for you,

Katrin


> -----Original Message-----
> From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-
> bounces at lists.koha-community.org] On Behalf Of Paul
> Sent: Monday, April 18, 2011 4:04 PM
> To: koha; koha-devel at lists.koha-community.org
> Subject: [Koha-devel] Subfields 952 $i, $k
> 
> [Apologies for cross-posting, users and devel]
> 
> Marc 952 $i, $k are not used in "standard" Koha. They can be added to the
> default framework (allowed by Koha), but this appears to require a
> modification to the Mysql structure. Has anyone tried to do this?
> 
> Background:  for Serials, we want to add at *item* level "Extended
> Keywords" (952$z is limited to 255 characters) and "Abstracts" (at *biblio*
> level, we use 520 $a and $b.)
> 
> This will require new "Koha Fields" - e.g, in the same way that 952$z uses
> "items.itemnotes" we will need to introduce "items.itemkeywords" and
> "items.itemabstracts".
> 
> I am looking for suggestions as to how to best add these fields so that
> they can be usefully searched by the OPAC - and of course for any pitfalls
> or showstoppers.
> 
> Thanks
> 
> Paul
> Tired old sys-admin
> 
> _______________________________________________
> 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 jwagner at liblime.com  Mon Apr 18 16:20:37 2011
From: jwagner at liblime.com (Wagner, Jane)
Date: Mon, 18 Apr 2011 10:20:37 -0400
Subject: [Koha-devel] Subfields 952 $i, $k
In-Reply-To: <5.2.1.1.2.20110418094426.076ec578@stormy.ca>
References: <5.2.1.1.2.20110418094426.076ec578@stormy.ca>
Message-ID: <1a701f47ca42cc98f51af3559be6a43a@mail.gmail.com>

We have used subfield i for our item suppression feature (Bug 4492):

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

and subfield k for our Other Item Status (bug 4237):

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

Neither have made it into head yet, though.

Jane Wagner
Senior Project Manager
LibLime, a division of PTFS
Content Management and Library Solutions
6400 Goldsboro Road, Suite 200
Bethesda, MD  20817
(301) 654-8088 x 151
jwagner at liblime.com


-----Original Message-----
From: koha-devel-bounces at lists.koha-community.org
[mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Paul
Sent: Monday, April 18, 2011 10:04 AM
To: koha; koha-devel at lists.koha-community.org
Subject: [Koha-devel] Subfields 952 $i, $k

[Apologies for cross-posting, users and devel]

Marc 952 $i, $k are not used in "standard" Koha. They can be added to the
default framework (allowed by Koha), but this appears to require a
modification to the Mysql structure. Has anyone tried to do this?

Background:  for Serials, we want to add at *item* level "Extended
Keywords" (952$z is limited to 255 characters) and "Abstracts" (at
*biblio*
level, we use 520 $a and $b.)

This will require new "Koha Fields" - e.g, in the same way that 952$z uses

"items.itemnotes" we will need to introduce "items.itemkeywords" and
"items.itemabstracts".

I am looking for suggestions as to how to best add these fields so that
they can be usefully searched by the OPAC - and of course for any pitfalls

or showstoppers.

Thanks

Paul
Tired old sys-admin

_______________________________________________
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.a at aandc.org  Mon Apr 18 18:19:37 2011
From: paul.a at aandc.org (Paul)
Date: Mon, 18 Apr 2011 12:19:37 -0400
Subject: [Koha-devel] Subfields 952 $i, $k
In-Reply-To: <028B1A54D03E7B4482CDCA4EC8F06BFD0130C99D@Bodensee.bsz-bw.d
 e>
References: <5.2.1.1.2.20110418094426.076ec578@stormy.ca>
	<5.2.1.1.2.20110418094426.076ec578@stormy.ca>
Message-ID: <5.2.1.1.2.20110418114051.03a1dec8@localhost>

At 04:18 PM 4/18/2011 +0200, Fischer, Katrin wrote:
>Hi Paul,
>in 3.4 a mapping and a new search index was introduced for 952$i and 
>items.stocknumber (Bug 5839).

Many thanks for the answers. So if we upgrade to 3.4, I'll have to modify 
kohadb to take out the (varchar 32) constraint? So far, we have endeavoured 
to remain "faithful" to the Master version, but cataloguing our serials is 
an uphill challenge.

>You can easily add new subfields in your bibliographic frameworks. If you 
>leave the mapping field empty the data will be stored in the 
>more_subfields_xml column. As the name indicates it's stored in a XML format.

Perhaps easier to add specific items.xyx - I don't think the XML will be 
problematic, but wonder if these are all concatenated for OPAC display? 
(e.g. at the moment 520 $a and $b ARE concatenated. I'm looking for a way 
to undo this.)

>There are not many lowercase letters left for 952. According to the MARC21 
>Standard it's also possible to use uppercase letters, but I am not 
>completely sure if Koha works correctly if you do. This would need some 
>more testing, although we have done so in the past without running into 
>problems.

This sounds like a possible solution - instead of "local" specialized uses 
(German remapping of
995$j to 952$i in this case) getting into the Master, surely it is more 
logical to leave more flexibility? I don't think everyone has the time to 
follow all bugs (I certainly missed this one), maybe the development team 
could assure us that 952 $[A-Z] are fully working and available for local 
use, while 952 $[a-z] are for Koha use?

Best - Paul


>For search you would need to add new indexes to your Zebra configuration. 
>This is independent from the way you store the data in your database.
>
>Hope this makes sense and is helpful for you,
>
>Katrin
>
>
> > -----Original Message-----
> > From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-
> > bounces at lists.koha-community.org] On Behalf Of Paul
> > Sent: Monday, April 18, 2011 4:04 PM
> > To: koha; koha-devel at lists.koha-community.org
> > Subject: [Koha-devel] Subfields 952 $i, $k
> >
> > [Apologies for cross-posting, users and devel]
> >
> > Marc 952 $i, $k are not used in "standard" Koha. They can be added to the
> > default framework (allowed by Koha), but this appears to require a
> > modification to the Mysql structure. Has anyone tried to do this?
> >
> > Background:  for Serials, we want to add at *item* level "Extended
> > Keywords" (952$z is limited to 255 characters) and "Abstracts" (at *biblio*
> > level, we use 520 $a and $b.)
> >
> > This will require new "Koha Fields" - e.g, in the same way that 952$z uses
> > "items.itemnotes" we will need to introduce "items.itemkeywords" and
> > "items.itemabstracts".
> >
> > I am looking for suggestions as to how to best add these fields so that
> > they can be usefully searched by the OPAC - and of course for any pitfalls
> > or showstoppers.
> >
> > Thanks
> >
> > Paul
> > Tired old sys-admin
> >
> > _______________________________________________
> > Koha-devel mailing list
> > Koha-devel at lists.koha-community.org
> > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> > website : http://www.koha-community.org/
> > git : http://git.koha-community.org/
> > bugs : http://bugs.koha-community.org/
> >


From chris at bigballofwax.co.nz  Mon Apr 18 19:55:18 2011
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Tue, 19 Apr 2011 05:55:18 +1200
Subject: [Koha-devel] Subfields 952 $i, $k
In-Reply-To: <5.2.1.1.2.20110418114051.03a1dec8@localhost>
References: <5.2.1.1.2.20110418094426.076ec578@stormy.ca>
	<5.2.1.1.2.20110418114051.03a1dec8@localhost>
Message-ID: <BANLkTimQ4xUb_H581_0f6R=kViSkiAt12A@mail.gmail.com>

On 19 April 2011 04:19, Paul <paul.a at aandc.org> wrote:
> At 04:18 PM 4/18/2011 +0200, Fischer, Katrin wrote:
>>
>> Hi Paul,
>> in 3.4 a mapping and a new search index was introduced for 952$i and
>> items.stocknumber (Bug 5839).
>
> Many thanks for the answers. So if we upgrade to 3.4, I'll have to modify
> kohadb to take out the (varchar 32) constraint? So far, we have endeavoured
> to remain "faithful" to the Master version, but cataloguing our serials is
> an uphill challenge.
>
If you make local changes that don't go into master, then yes, if you
don't commit them back you will have to reconcile on upgrade. This is
the danger of local unsubmitted changes in any project. You could of
course just remove the mapping in your framework, if its not linked to
a colum in the items table it will just end up in the xml as Katrin
says below.
So if you don't want i to be stocknumber in yours, you can change the mapping.

>> You can easily add new subfields in your bibliographic frameworks. If you
>> leave the mapping field empty the data will be stored in the
>> more_subfields_xml column. As the name indicates it's stored in a XML
>> format.
>
> Perhaps easier to add specific items.xyx - I don't think the XML will be
> problematic, but wonder if these are all concatenated for OPAC display?
> (e.g. at the moment 520 $a and $b ARE concatenated. I'm looking for a way to
> undo this.)

Use the xslt stylesheets you can make them display any way you like
>
>> There are not many lowercase letters left for 952. According to the MARC21
>> Standard it's also possible to use uppercase letters, but I am not
>> completely sure if Koha works correctly if you do. This would need some more
>> testing, although we have done so in the past without running into problems.
>
> This sounds like a possible solution - instead of "local" specialized uses
> (German remapping of
> 995$j to 952$i in this case) getting into the Master, surely it is more
> logical to leave more flexibility?

You totally misread the bug. Katrin suggested we add a stocknumber
using the 952$i field. She pointed out that in UNIMARC they use 995$j.
UNIMARC is a totally different standard to MARC21, there was no
remapping. Marcel (who is dutch) agreed. People from all over the
world also discussed this on IRC.
In no way is this a German localised use.

Chris

From paul.poulain at biblibre.com  Tue Apr 19 14:41:34 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Tue, 19 Apr 2011 14:41:34 +0200
Subject: [Koha-devel] Issues table and foreign keys in general
In-Reply-To: <20110416184115.GZ6680@rorohiko>
References: <4DA4FE97.2040904@catalyst.net.nz>
	<BANLkTimXwYo+vy+OKUf12CbZpRq=RDM4Aw@mail.gmail.com>
	<4DA99FFD.9040407@biblibre.com> <20110416184115.GZ6680@rorohiko>
Message-ID: <4DAD82FE.5040805@biblibre.com>

Le 16/04/2011 20:41, Chris Cormack a ?crit :
> I disagree, option 4 is to make the change suggested by Srdjan, in which
> the database will enforce integrity and make it impossible to delete an
> item that  is checked out (has a row in issues). This covers us from
> mistakes in code, and from people making mistakes in the database.
> DELETE CASCADE is dangerous and should be avoided in this instance. It
> means if we make a mistake anywhere deleting an item that is checked
> out, the mistake will be compounded as we now delete the row in issues. The set
> NULL is nearly as bad, as we now null the column and still have no idea
> what it was linked to.
This problem is a functionnal problem: it's impossible to have an item
that is checked out AND deleted.
So we must find the best way for librarians to deal with the case they
try to do this. I agree that today situation is wrong.

I'm sure librarians will say : "hey, if I delete the item, it means no
one has it anymore, why does not Koha just check-in the pending issue?"
It's the same when you check-out an item that is already checked out :
koha says "item is checked out for XXX, do the check-in before checking
out to YYY?"
I think we should do the same : "you're about to delete an item
checked-out to XXX, do you confirm the check-in before deleting the item?"
>> About
>>> 2. That is not an isolated issue, there are many cases where foreign
>>> key field/constraints are declared like that
>> I wrote many of them with a reason that I think needed. Please tell me
>> which you consider as a problem, i'll tell you :
>> * why I choose this option if it's me
>> * that I was not the author of this choice, the author made a mistake
>> (and if git blame show you i'm the author of a buggy/wrong choice, i'll
>> argue that someone stole my identity just for this mistake :D )
> I think the database should never do this, I think our code should do it if it
> is needed. The database should stop us deleting things that are referred
> to elsewhere. We should clean up those references before trying to
> delete. The database should be the failsafe for us making mistakes, not
> allow us to make bigger mistakes :)
I'm not sure I understand what you mean here, so I explain what I wanted
to achieve with the constraints. I just used DELETE CASCADE or SET NULL
where it's logical. Like, when you delete a auth_tag_structure you
delete the subfields.
I used SET NULL only when I thought it was relevant to keep the entries
(like anonymised issues)


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


From lculber at mdah.state.ms.us  Tue Apr 19 15:01:18 2011
From: lculber at mdah.state.ms.us (Linda Culberson)
Date: Tue, 19 Apr 2011 08:01:18 -0500
Subject: [Koha-devel] Koha move to 3.4
Message-ID: <4DAD879E.3070904@mdah.state.ms.us>

All,
How is  the recommended way to move to the upcoming 3.4?  We were 
thinking of having two instances. One with our current 3.02.02.003 and 
one with 3.4.  Is that a good way to do it or should we upgrade to 3.2.7 
and go from there?

Can we move our data or is it better to do a fresh load?  How different 
is the database in 3.4?

Your advice to this newbie is greatly appreciated.

-- 
Linda Culberson			lculber at mdah.state.ms.us
Archives and Records Services Division
Ms. Dept. of Archives & History
P. O. Box 571
Jackson, MS 39205-0571
Telephone:  601/576-6873
Facsimile:  601/576-6824


From paul.poulain at biblibre.com  Tue Apr 19 15:19:19 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Tue, 19 Apr 2011 15:19:19 +0200
Subject: [Koha-devel] Koha move to 3.4
In-Reply-To: <4DAD879E.3070904@mdah.state.ms.us>
References: <4DAD879E.3070904@mdah.state.ms.us>
Message-ID: <4DAD8BD7.5020103@biblibre.com>

Le 19/04/2011 15:01, Linda Culberson a ?crit :
> All,
Hi Linda,
> How is  the recommended way to move to the upcoming 3.4?
First of all the recommended way is to wait until 3.4 is officially here ;-)
>   We were thinking of having two instances. One with our current
> 3.02.02.003 and one with 3.4.  Is that a good way to do it or should
> we upgrade to 3.2.7 and go from there?
I think it doesn't matter. The database update will take care of this
smoothly.
(For reader under 3.0, I think it should work too, but I suggest to
switch to 3.2 before anyway. For readers running 2.x, wow, upgrade to
3.0, then 3.2 then 3.4)
> Can we move our data or is it better to do a fresh load?  How
> different is the database in 3.4?
the DB is quite different but the upgrade takes care of DB upgrade.
However, depending on your size & how critical it is to have things live
working smoothly, it's always wise to have a test/integration server
before upgrading...
> Your advice to this newbie is greatly appreciated.
Another question you could ask yourself is:
* what's important for me in the 3.4 ? (which killer feature I'm waiting
for impatiently)
* which risk do I accept (ie: if there is a problem that prevents me to
work, how long/critical can it be ?)
* which ressources do I have to solve a problem

Depending on the answers to the previous questions, it may be
better/wise to wait for 3.4.1 or 3.4.2, or even 3.4.4 !
To summarize: "if it works, don't fix it" ;-)

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


From lculber at mdah.state.ms.us  Tue Apr 19 15:23:42 2011
From: lculber at mdah.state.ms.us (Linda Culberson)
Date: Tue, 19 Apr 2011 08:23:42 -0500
Subject: [Koha-devel] Koha move to 3.4
In-Reply-To: <4DAD8BD7.5020103@biblibre.com>
References: <4DAD879E.3070904@mdah.state.ms.us> <4DAD8BD7.5020103@biblibre.com>
Message-ID: <4DAD8CDE.1030804@mdah.state.ms.us>

This is wonderful advice, Paul, and all just what I needed to hear. 
Thank you!

On 4/19/2011 8:19 AM, Paul Poulain wrote:
> Le 19/04/2011 15:01, Linda Culberson a ?crit :
>> All,
> Hi Linda,
>> How is  the recommended way to move to the upcoming 3.4?
> First of all the recommended way is to wait until 3.4 is officially here ;-)
>>    We were thinking of having two instances. One with our current
>> 3.02.02.003 and one with 3.4.  Is that a good way to do it or should
>> we upgrade to 3.2.7 and go from there?
> I think it doesn't matter. The database update will take care of this
> smoothly.
> (For reader under 3.0, I think it should work too, but I suggest to
> switch to 3.2 before anyway. For readers running 2.x, wow, upgrade to
> 3.0, then 3.2 then 3.4)
>> Can we move our data or is it better to do a fresh load?  How
>> different is the database in 3.4?
> the DB is quite different but the upgrade takes care of DB upgrade.
> However, depending on your size&  how critical it is to have things live
> working smoothly, it's always wise to have a test/integration server
> before upgrading...
>> Your advice to this newbie is greatly appreciated.
> Another question you could ask yourself is:
> * what's important for me in the 3.4 ? (which killer feature I'm waiting
> for impatiently)
> * which risk do I accept (ie: if there is a problem that prevents me to
> work, how long/critical can it be ?)
> * which ressources do I have to solve a problem
>
> Depending on the answers to the previous questions, it may be
> better/wise to wait for 3.4.1 or 3.4.2, or even 3.4.4 !
> To summarize: "if it works, don't fix it" ;-)
>

-- 
Linda Culberson			lculber at mdah.state.ms.us
Archives and Records Services Division
Ms. Dept. of Archives & History
P. O. Box 571
Jackson, MS 39205-0571
Telephone:  601/576-6873
Facsimile:  601/576-6824



From gmc at esilibrary.com  Tue Apr 19 15:23:31 2011
From: gmc at esilibrary.com (Galen Charlton)
Date: Tue, 19 Apr 2011 09:23:31 -0400
Subject: [Koha-devel] [Koha] Koha move to 3.4
In-Reply-To: <4DAD879E.3070904@mdah.state.ms.us>
References: <4DAD879E.3070904@mdah.state.ms.us>
Message-ID: <EA1EEA68-9C47-4ED4-A805-9FBEC6C0EA7B@esilibrary.com>

Hi,

On Apr 19, 2011, at 9:01 AM, Linda Culberson wrote:
> How is  the recommended way to move to the upcoming 3.4?  We were 
> thinking of having two instances. One with our current 3.02.02.003 and 
> one with 3.4.  Is that a good way to do it or should we upgrade to 3.2.7 
> and go from there?

Having two instances (production and test) is always a good idea.  I don't think it is necessary per se to upgrade your test database to 3.2.7 first, you should be able to just upgrade from 3.2.2 to 3.4.

> Can we move our data or is it better to do a fresh load?  How different 
> is the database in 3.4?

It will not be necessary to reload your data.  You can just set up your test instance with a full copy of your exiting production database, upgrade the test instance to 3.4, then test.  Once you're happy with the results and have resolved any glitches, you can then run the upgrade process in your production database.

Regards,

Galen
--
Galen Charlton
VP, Data Services
Equinox Software, Inc. / Your Library's Guide to Open Source
email:  gmc at esilibrary.com
direct: +1 352-215-7548
skype:  gmcharlt
web:    http://www.esilibrary.com/


From lculber at mdah.state.ms.us  Wed Apr 20 20:37:24 2011
From: lculber at mdah.state.ms.us (Linda Culberson)
Date: Wed, 20 Apr 2011 13:37:24 -0500
Subject: [Koha-devel] koha: error in MARC Bibliographic Framework Test
Message-ID: <4DAF27E4.4050201@mdah.state.ms.us>

All,
I had done 12 customized frameworks in Koha version 3.02.02.003 and at 
some point  I made an error - and I'm embarrassed that I don't know when 
the error got in since I worked on them pretty much all at once.
  I have only the one error and it is:
Item tag 	There is more than 1 MARC tag related to items tab (10) : 
952,955,956,960,967,980,981,982,983,984,987,990,995,998.

I've gone through every framework and don't  use any of those fields 
except the 952.  I did this sql statement to verify that was the case:
SELECT distinct tagfield
FROM `marc_subfield_structure`
WHERE `tagfield`
IN ('952', '955', '956', '960', '967', '980', '981', '982', '983', 
'984', '987', '990', '995', '998'
)
AND `kohafield` LIKE 'items.%';

and the results was one row: 952.

I've checked all the frameworks and even matched them against the demos 
so kindly posted on  koha-community.org.  I'm thinking that I may not be 
understanding what the error means, because I was assuming that it 
indicated that there might be a duplication in the koha link.  Can 
someone tell me what I should be looking for?

Thanks in advance.

-- 
Linda Culberson			lculber at mdah.state.ms.us
Archives and Records Services Division
Ms. Dept. of Archives & History
P. O. Box 571
Jackson, MS 39205-0571
Telephone:  601/576-6873
Facsimile:  601/576-6824


From lculber at mdah.state.ms.us  Wed Apr 20 21:18:27 2011
From: lculber at mdah.state.ms.us (Linda Culberson)
Date: Wed, 20 Apr 2011 14:18:27 -0500
Subject: [Koha-devel] [Koha] koha: error in MARC Bibliographic Framework
	Test
In-Reply-To: <BANLkTikVs5isgaGQqE8HHeBbFr3TEn37ag@mail.gmail.com>
References: <4DAF27E4.4050201@mdah.state.ms.us>
	<BANLkTikVs5isgaGQqE8HHeBbFr3TEn37ag@mail.gmail.com>
Message-ID: <4DAF3183.6050400@mdah.state.ms.us>

Thanks, Bev!
That was it!  I really appreciate your help.
Linda

On 4/20/2011 2:02 PM, Church, Beverly wrote:
>   Linda,
>
> I haven't seen this message before but it sounds as if the subfields for
> the other tags are linked to Tab 10 instead of Tab 9. Only the tag 952
> subfields should be linked to Tab 10.
>
> Bev
>
> * * * *
> Beverly Church
> LibLime Project Manager
>
> phone: 1-888-564-2457 ext. 717
>              1-301-654-8088 ext. 292
> email: bchurch at liblime.com <mailto:bchurch at liblime.com>
> skype: beverlychurch
>
>
> On Wed, Apr 20, 2011 at 2:37 PM, Linda Culberson
> <lculber at mdah.state.ms.us <mailto:lculber at mdah.state.ms.us>> wrote:
>
>     All,
>     I had done 12 customized frameworks in Koha version 3.02.02.003 and at
>     some point  I made an error - and I'm embarrassed that I don't know when
>     the error got in since I worked on them pretty much all at once.
>       I have only the one error and it is:
>     Item tag        There is more than 1 MARC tag related to items tab
>     (10) :
>     952,955,956,960,967,980,981,982,983,984,987,990,995,998.
>
>     I've gone through every framework and don't  use any of those fields
>     except the 952.  I did this sql statement to verify that was the case:
>     SELECT distinct tagfield
>     FROM `marc_subfield_structure`
>     WHERE `tagfield`
>     IN ('952', '955', '956', '960', '967', '980', '981', '982', '983',
>     '984', '987', '990', '995', '998'
>     )
>     AND `kohafield` LIKE 'items.%';
>
>     and the results was one row: 952.
>
>     I've checked all the frameworks and even matched them against the demos
>     so kindly posted on koha-community.org <http://koha-community.org>.
>       I'm thinking that I may not be
>     understanding what the error means, because I was assuming that it
>     indicated that there might be a duplication in the koha link.  Can
>     someone tell me what I should be looking for?
>
>     Thanks in advance.
>
>     --
>     Linda Culberson lculber at mdah.state.ms.us
>     <mailto:lculber at mdah.state.ms.us>
>     Archives and Records Services Division
>     Ms. Dept. of Archives & History
>     P. O. Box 571
>     Jackson, MS 39205-0571
>     Telephone:  601/576-6873
>     Facsimile:  601/576-6824
>
>     _______________________________________________
>     Koha mailing list http://koha-community.org
>     Koha at lists.katipo.co.nz <mailto:Koha at lists.katipo.co.nz>
>     http://lists.katipo.co.nz/mailman/listinfo/koha
>
>

-- 
Linda Culberson			lculber at mdah.state.ms.us
Archives and Records Services Division
Ms. Dept. of Archives & History
P. O. Box 571
Jackson, MS 39205-0571
Telephone:  601/576-6873
Facsimile:  601/576-6824


From cnighswonger at foundations.edu  Wed Apr 20 21:37:14 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Wed, 20 Apr 2011 15:37:14 -0400
Subject: [Koha-devel] List Cross Posting Trend
Message-ID: <BANLkTimeoWkyQ55OTPzB0z9ytC9XxXC_MA@mail.gmail.com>

Hi everyone,

There seems to be a growing trend lately of cross posting to both the Koha
user's and developer's list of questions which are usage related. Perhaps
this is a good time to remind everyone to please post user questions to the
user list and development/code questions to the developer's list in order to
preserve each list from the clutter of the other.

Only posts truly relevant to both audiences (like this one) should be cross
posted.

Thanks to all, both users and developers, for helping to make Koha the great
ILS that it is!

Kind Regards,
Chris
Koha 3.2.x/3.4.x Release Maintainer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110420/18be5a4a/attachment.htm>

From reedwade at gmail.com  Wed Apr 20 22:37:15 2011
From: reedwade at gmail.com (Reed Wade)
Date: Thu, 21 Apr 2011 08:37:15 +1200
Subject: [Koha-devel] List Cross Posting Trend
In-Reply-To: <BANLkTimeoWkyQ55OTPzB0z9ytC9XxXC_MA@mail.gmail.com>
References: <BANLkTimeoWkyQ55OTPzB0z9ytC9XxXC_MA@mail.gmail.com>
Message-ID: <BANLkTimNz6EeXr-tPoagTThrTUXDuOwtNw@mail.gmail.com>

It's worth mentioning that when in doubt, the users list is probably
the correct one and if you're wrong that's ok because developers tend
to be on both lists so the issue isn't likely to get lost.

-reed



2011/4/21 Chris Nighswonger <cnighswonger at foundations.edu>:
> Hi everyone,
>
> There seems to be a growing trend lately of cross posting to both the Koha
> user's and developer's list of questions which are usage related. Perhaps
> this is a good time to remind everyone to please post user questions to the
> user list and development/code questions to the developer's list in order to
> preserve each list from the clutter of the other.
>
> Only posts truly relevant to both audiences (like this one) should be cross
> posted.
>
> Thanks to all, both users and developers, for helping to make Koha the great
> ILS that it is!
>
> Kind Regards,
> Chris
> Koha 3.2.x/3.4.x Release Maintainer
>
> _______________________________________________
> 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 Cole.Hudson at hc.msu.edu  Thu Apr 21 00:34:33 2011
From: Cole.Hudson at hc.msu.edu (Cole Hudson)
Date: Wed, 20 Apr 2011 18:34:33 -0400
Subject: [Koha-devel] issues with label creator item search
Message-ID: <89A35FEF98F9384BBB1360526A846BC720950E@TEAM-EXCHANGE1.hc.msu.edu>

Hi all,

I seem to be having some trouble with label creator item search tool in Koha 3.02.06, running on Ubuntu 10.10.  When I go to search for items to add to a batch, I have a couple problems.  First, I'm not able to search with the added on date fields.  I select a date, click search, and nothing appears.  Also, when I manage to search for an item, I don't get all of my results.  After about the first 20 or so results appear, I just get blank entries in the form of this:

[],
[],
[],
[],
[],
[],

I checked my koha-error_log file and am getting the following errors.

[Wed Apr 20 15:21:39 2011] [error] [client 35.12.33.50] [Wed Apr 20 15:21:39 2011] label-item-search.pl: Use of uninitialized value $biblionumber in hash element at /usr/share/koha/intranet/cgi-bin/labels/label-item-search.pl line 124., referer: http://koha.com.msu.edu:8080/cgi-bin/koha/labels/label-item-search.pl
[Wed Apr 20 15:21:39 2011] [error] [client 35.12.33.50] [Wed Apr 20 15:21:39 2011] label-item-search.pl: Use of uninitialized value $biblionumber in sprintf at /usr/share/koha/intranet/cgi-bin/labels/label-item-search.pl line 142., referer: http://koha.com.msu.edu:8080/cgi-bin/koha/labels/label-item-search.pl
[Wed Apr 20 15:21:39 2011] [error] [client 35.12.33.50] [Wed Apr 20 15:21:39 2011] label-item-search.pl: No item numbers retrieved for biblio number:  at /usr/share/koha/intranet/cgi-bin/labels/label-item-search.pl line 142., referer: http://koha.com.msu.edu:8080/cgi-bin/koha/labels/label-item-search.pl

I'm not really sure how to go about fixing this.  Any suggestions? Thanks.

Cole

Cole Hudson
Library Assistant
Michigan State University
College of Osteopathic Medicine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110420/fa15ab0c/attachment.htm>

From bchurch at liblime.com  Wed Apr 20 21:02:35 2011
From: bchurch at liblime.com (Church, Beverly)
Date: Wed, 20 Apr 2011 15:02:35 -0400
Subject: [Koha-devel] [Koha] koha: error in MARC Bibliographic Framework
	Test
In-Reply-To: <4DAF27E4.4050201@mdah.state.ms.us>
References: <4DAF27E4.4050201@mdah.state.ms.us>
Message-ID: <BANLkTikVs5isgaGQqE8HHeBbFr3TEn37ag@mail.gmail.com>

Linda,

I haven't seen this message before but it sounds as if the subfields for the
other tags are linked to Tab 10 instead of Tab 9. Only the tag 952 subfields
should be linked to Tab 10.

Bev

* * * *
Beverly Church
LibLime Project Manager

phone: 1-888-564-2457 ext. 717
            1-301-654-8088 ext. 292
email: bchurch at liblime.com
skype: beverlychurch


On Wed, Apr 20, 2011 at 2:37 PM, Linda Culberson
<lculber at mdah.state.ms.us>wrote:

> All,
> I had done 12 customized frameworks in Koha version 3.02.02.003 and at
> some point  I made an error - and I'm embarrassed that I don't know when
> the error got in since I worked on them pretty much all at once.
>  I have only the one error and it is:
> Item tag        There is more than 1 MARC tag related to items tab (10) :
> 952,955,956,960,967,980,981,982,983,984,987,990,995,998.
>
> I've gone through every framework and don't  use any of those fields
> except the 952.  I did this sql statement to verify that was the case:
> SELECT distinct tagfield
> FROM `marc_subfield_structure`
> WHERE `tagfield`
> IN ('952', '955', '956', '960', '967', '980', '981', '982', '983',
> '984', '987', '990', '995', '998'
> )
> AND `kohafield` LIKE 'items.%';
>
> and the results was one row: 952.
>
> I've checked all the frameworks and even matched them against the demos
> so kindly posted on  koha-community.org.  I'm thinking that I may not be
> understanding what the error means, because I was assuming that it
> indicated that there might be a duplication in the koha link.  Can
> someone tell me what I should be looking for?
>
> Thanks in advance.
>
> --
> Linda Culberson                 lculber at mdah.state.ms.us
> Archives and Records Services Division
> Ms. Dept. of Archives & History
> P. O. Box 571
> Jackson, MS 39205-0571
> Telephone:  601/576-6873
> Facsimile:  601/576-6824
>
> _______________________________________________
> Koha mailing list  http://koha-community.org
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110420/3c6f2dc1/attachment.htm>

From cnighswonger at foundations.edu  Thu Apr 21 04:12:12 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Wed, 20 Apr 2011 22:12:12 -0400
Subject: [Koha-devel] issues with label creator item search
In-Reply-To: <89A35FEF98F9384BBB1360526A846BC720950E@TEAM-EXCHANGE1.hc.msu.edu>
References: <89A35FEF98F9384BBB1360526A846BC720950E@TEAM-EXCHANGE1.hc.msu.edu>
Message-ID: <BANLkTikuyRq-=ZgBPdB8gfrP3t5U44HG4A@mail.gmail.com>

Hi Cole,

2011/4/20 Cole Hudson <Cole.Hudson at hc.msu.edu>

>  Hi all,
>
> I seem to be having some trouble with label creator item search tool in
> Koha 3.02.06, running on Ubuntu 10.10.  When I go to search for items to add
> to a batch, I have a couple problems.  First, I'm not able to search with
> the added on date fields.  I select a date, click search, and nothing
> appears.  Also, when I manage to search for an item, I don't get all of my
> results.  After about the first 20 or so results appear, I just get blank
> entries in the form of this:
>

I've just tested this out on my sandbox running 3.03.00.026 and it works
fine. It should also work fine in the latest stable release which is 3.2.7.
I'd recommend upgrading to 3.2.7 in any case.

You could also have an indexing problem. Check out
http://koha-community.org/documentation/faq/searching/ as this information
applies to any search in Koha.

Kind regards,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110420/0c5ba1b2/attachment-0001.htm>

From fridolyn.somers at gmail.com  Thu Apr 21 08:14:55 2011
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Thu, 21 Apr 2011 08:14:55 +0200
Subject: [Koha-devel] [Koha] koha: error in MARC Bibliographic Framework
	Test
In-Reply-To: <4DAF3183.6050400@mdah.state.ms.us>
References: <4DAF27E4.4050201@mdah.state.ms.us>
	<BANLkTikVs5isgaGQqE8HHeBbFr3TEn37ag@mail.gmail.com>
	<4DAF3183.6050400@mdah.state.ms.us>
Message-ID: <BANLkTi=0YRmQD-183tXgOgiGQ6XDqVJ2vg@mail.gmail.com>

Hie,

I'd say you don't test the right query.
The "tab" choosen for subfield in framework configuration is saved in "tab"
field of "marc_subfield_structure" :

Try :
SELECT DISTINCT(tagfield),tab FROM marc_subfield_structure WHERE tab > 9

You should have only "952 | 10".

Regards,

On Wed, Apr 20, 2011 at 9:18 PM, Linda Culberson
<lculber at mdah.state.ms.us>wrote:

> Thanks, Bev!
> That was it!  I really appreciate your help.
> Linda
>
>
> On 4/20/2011 2:02 PM, Church, Beverly wrote:
>
>>  Linda,
>>
>> I haven't seen this message before but it sounds as if the subfields for
>> the other tags are linked to Tab 10 instead of Tab 9. Only the tag 952
>> subfields should be linked to Tab 10.
>>
>> Bev
>>
>> * * * *
>> Beverly Church
>> LibLime Project Manager
>>
>> phone: 1-888-564-2457 ext. 717
>>             1-301-654-8088 ext. 292
>> email: bchurch at liblime.com <mailto:bchurch at liblime.com>
>>
>> skype: beverlychurch
>>
>>
>> On Wed, Apr 20, 2011 at 2:37 PM, Linda Culberson
>> <lculber at mdah.state.ms.us <mailto:lculber at mdah.state.ms.us>> wrote:
>>
>>    All,
>>    I had done 12 customized frameworks in Koha version 3.02.02.003 and at
>>    some point  I made an error - and I'm embarrassed that I don't know
>> when
>>    the error got in since I worked on them pretty much all at once.
>>      I have only the one error and it is:
>>    Item tag        There is more than 1 MARC tag related to items tab
>>    (10) :
>>    952,955,956,960,967,980,981,982,983,984,987,990,995,998.
>>
>>    I've gone through every framework and don't  use any of those fields
>>    except the 952.  I did this sql statement to verify that was the case:
>>    SELECT distinct tagfield
>>    FROM `marc_subfield_structure`
>>    WHERE `tagfield`
>>    IN ('952', '955', '956', '960', '967', '980', '981', '982', '983',
>>    '984', '987', '990', '995', '998'
>>    )
>>    AND `kohafield` LIKE 'items.%';
>>
>>    and the results was one row: 952.
>>
>>    I've checked all the frameworks and even matched them against the demos
>>    so kindly posted on koha-community.org <http://koha-community.org>.
>>
>>      I'm thinking that I may not be
>>    understanding what the error means, because I was assuming that it
>>    indicated that there might be a duplication in the koha link.  Can
>>    someone tell me what I should be looking for?
>>
>>    Thanks in advance.
>>
>>    --
>>    Linda Culberson lculber at mdah.state.ms.us
>>    <mailto:lculber at mdah.state.ms.us>
>>
>>    Archives and Records Services Division
>>    Ms. Dept. of Archives & History
>>    P. O. Box 571
>>    Jackson, MS 39205-0571
>>    Telephone:  601/576-6873
>>    Facsimile:  601/576-6824
>>
>>    _______________________________________________
>>    Koha mailing list http://koha-community.org
>>    Koha at lists.katipo.co.nz <mailto:Koha at lists.katipo.co.nz>
>>
>>    http://lists.katipo.co.nz/mailman/listinfo/koha
>>
>>
>>
> --
> Linda Culberson                 lculber at mdah.state.ms.us
> Archives and Records Services Division
> Ms. Dept. of Archives & History
> P. O. Box 571
> Jackson, MS 39205-0571
> Telephone:  601/576-6873
> Facsimile:  601/576-6824
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



-- 
Fridolyn SOMERS
ICT engineer
PROGILONE - Lyon - France
fridolyn.somers at gmail.com
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: </pipermail/koha-devel/attachments/20110421/764aba40/attachment.htm>

From max_pleva at hotmail.it  Thu Apr 21 12:31:15 2011
From: max_pleva at hotmail.it (Massimo Plevani)
Date: Thu, 21 Apr 2011 12:31:15 +0200
Subject: [Koha-devel] [koha] unable to locate Koha configuration file
	koha-conf.xml
Message-ID: <DUB107-w1394A47D2E9B5628C164F0F6920@phx.gbl>


Hi All,

I am getting the same problem:

When I tried to install Koha 3.2.5 on ubuntu 9.04 and I got the following message in first line after executing the perl Makefile.PL command:

unable to locate Koha configuration file koha-conf.xml at /build/koha-3.2.5/C4/Context.pm line 307.

some help?

thanks


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110421/56a7090d/attachment.htm>

From max_pleva at hotmail.it  Thu Apr 21 14:23:07 2011
From: max_pleva at hotmail.it (Massimo Plevani)
Date: Thu, 21 Apr 2011 14:23:07 +0200
Subject: [Koha-devel] [koha] unable to locate Koha configuration file
	koha-conf.xml
In-Reply-To: <DUB107-w1394A47D2E9B5628C164F0F6920@phx.gbl>
References: <DUB107-w1394A47D2E9B5628C164F0F6920@phx.gbl>
Message-ID: <DUB107-w426F6BD6F7BC1A11DB5570F6920@phx.gbl>


I solved the problem. I modified the file context.pm:

 use constant CONFIG_FNAME => "/ path / to / Koha-conf.xml";

 to

 use constant CONFIG_FNAME => "/ build/koha-3.2.5/etc/koha-conf.xml";

 and does not give me the most problem.

thanks


From: max_pleva at hotmail.it
To: koha-devel at lists.koha-community.org
Subject: [koha] unable to locate Koha configuration file koha-conf.xml
Date: Thu, 21 Apr 2011 12:31:15 +0200








Hi All,

I am getting the same problem:

When I tried to install Koha 3.2.5 on ubuntu 9.04 and I got the following message in first line after executing the perl Makefile.PL command:

unable to locate Koha configuration file koha-conf.xml at /build/koha-3.2.5/C4/Context.pm line 307.

some help?

thanks


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110421/3e1040fd/attachment.htm>

From paul.a at aandc.org  Thu Apr 21 23:44:27 2011
From: paul.a at aandc.org (Paul)
Date: Thu, 21 Apr 2011 17:44:27 -0400
Subject: [Koha-devel] Bug 2453
Message-ID: <5.2.1.1.2.20110421172507.04690e98@stormy.ca>

I've just been reading Bug 2453 - (very) large biblio/item handling; it 
appears to have received no comments since 2010-05-21. If I understand the 
situation correctly (from Paul Poulain's comments) if a biblio/items record 
exceeds 100Kb then zebra may fail. He suggests:

[snip] 2 possibilities :
- fix Koha to limit the size of a biblio/items (check that we don't ge more
than 100kB)
- fix the export during rebuild_zebra.
I think the 1st solution is the best.

I am currently defining our serials cataloguing policy - choices: one 
biblio for perhaps 1,200 items; one biblio per item (probably unmanageable 
in OPAC); or one biblio per year|volume. Currently the third choice is 
preferred, one (perhaps repetitive) biblio with up to 12 items, 
occasionally 52 (we do not handle dailies.)

However, even at twelve items per biblio we will often go beyond 100Kb; we 
are a research library where abstracts, indexes and keywords are, by 
definition, fairly voluminous and are the "bread and butter" of our users. 
Should this bug prompt me to perhaps rethink the policy?  Has 3.4 changed 
this situation?  Is there anything else in the pipeline that I should be 
aware of?

Many thanks for any guidance,

Paul
Tired old sys-admin 


From chris at bigballofwax.co.nz  Thu Apr 21 23:47:54 2011
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Fri, 22 Apr 2011 09:47:54 +1200
Subject: [Koha-devel] Bug 2453
In-Reply-To: <5.2.1.1.2.20110421172507.04690e98@stormy.ca>
References: <5.2.1.1.2.20110421172507.04690e98@stormy.ca>
Message-ID: <BANLkTimOeBWpywdpnCBuXuGb6Bckk3yW_w@mail.gmail.com>

On 22 April 2011 09:44, Paul <paul.a at aandc.org> wrote:
> I've just been reading Bug 2453 - (very) large biblio/item handling; it
> appears to have received no comments since 2010-05-21. If I understand the
> situation correctly (from Paul Poulain's comments) if a biblio/items record
> exceeds 100Kb then zebra may fail. He suggests:
>
> [snip] 2 possibilities :
> - fix Koha to limit the size of a biblio/items (check that we don't ge more
> than 100kB)
> - fix the export during rebuild_zebra.
> I think the 1st solution is the best.
>
> I am currently defining our serials cataloguing policy - choices: one biblio
> for perhaps 1,200 items; one biblio per item (probably unmanageable in
> OPAC); or one biblio per year|volume. Currently the third choice is
> preferred, one (perhaps repetitive) biblio with up to 12 items, occasionally
> 52 (we do not handle dailies.)
>
> However, even at twelve items per biblio we will often go beyond 100Kb; we
> are a research library where abstracts, indexes and keywords are, by
> definition, fairly voluminous and are the "bread and butter" of our users.
> Should this bug prompt me to perhaps rethink the policy? ?Has 3.4 changed
> this situation? ?Is there anything else in the pipeline that I should be
> aware of?
>
If you run rebuild_zebra.pl with the -x switch (just for biblio -x
doesnt work with authorities) this limitation does not exist.

I suggest running 2 rebuild_zebra.pl calls one for biblios
rebuild_zebra.pl -x -b -z
and one for authorities
rebuild_zebra.pl -a -z

Chris

From lculber at mdah.state.ms.us  Thu Apr 21 23:57:44 2011
From: lculber at mdah.state.ms.us (Linda Culberson)
Date: Thu, 21 Apr 2011 16:57:44 -0500
Subject: [Koha-devel] Bug 2453
In-Reply-To: <BANLkTimOeBWpywdpnCBuXuGb6Bckk3yW_w@mail.gmail.com>
References: <5.2.1.1.2.20110421172507.04690e98@stormy.ca>
	<BANLkTimOeBWpywdpnCBuXuGb6Bckk3yW_w@mail.gmail.com>
Message-ID: <4DB0A858.8070604@mdah.state.ms.us>

Chris,
I don't know if this changes in 3.4, because of the feature listed in 
the release_notes_3_4_0.txt about moving items out of biblioitems (line 
151).  But the problem we had with records with large numbers of items 
wasn't just in Zebra, it was in the overall size of the MARC record 
exceeding the 99999 record length.

Does removing the items from biblioitems help?

Thanks.
Linda Culberson

On 4/21/2011 4:47 PM, Chris Cormack wrote:
> On 22 April 2011 09:44, Paul<paul.a at aandc.org>  wrote:
>> I've just been reading Bug 2453 - (very) large biblio/item handling; it
>> appears to have received no comments since 2010-05-21. If I understand the
>> situation correctly (from Paul Poulain's comments) if a biblio/items record
>> exceeds 100Kb then zebra may fail. He suggests:
>>
>> [snip] 2 possibilities :
>> - fix Koha to limit the size of a biblio/items (check that we don't ge more
>> than 100kB)
>> - fix the export during rebuild_zebra.
>> I think the 1st solution is the best.
>>
>> I am currently defining our serials cataloguing policy - choices: one biblio
>> for perhaps 1,200 items; one biblio per item (probably unmanageable in
>> OPAC); or one biblio per year|volume. Currently the third choice is
>> preferred, one (perhaps repetitive) biblio with up to 12 items, occasionally
>> 52 (we do not handle dailies.)
>>
>> However, even at twelve items per biblio we will often go beyond 100Kb; we
>> are a research library where abstracts, indexes and keywords are, by
>> definition, fairly voluminous and are the "bread and butter" of our users.
>> Should this bug prompt me to perhaps rethink the policy? ? Has 3.4 changed
>> this situation? ? Is there anything else in the pipeline that I should be
>> aware of?
>>
> If you run rebuild_zebra.pl with the -x switch (just for biblio -x
> doesnt work with authorities) this limitation does not exist.
>
> I suggest running 2 rebuild_zebra.pl calls one for biblios
> rebuild_zebra.pl -x -b -z
> and one for authorities
> rebuild_zebra.pl -a -z
>
> Chris
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/

-- 
Linda Culberson			lculber at mdah.state.ms.us
Archives and Records Services Division
Ms. Dept. of Archives & History
P. O. Box 571
Jackson, MS 39205-0571
Telephone:  601/576-6873
Facsimile:  601/576-6824



From chris at bigballofwax.co.nz  Fri Apr 22 00:03:38 2011
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Fri, 22 Apr 2011 10:03:38 +1200
Subject: [Koha-devel] Bug 2453
In-Reply-To: <4DB0A858.8070604@mdah.state.ms.us>
References: <5.2.1.1.2.20110421172507.04690e98@stormy.ca>
	<BANLkTimOeBWpywdpnCBuXuGb6Bckk3yW_w@mail.gmail.com>
	<4DB0A858.8070604@mdah.state.ms.us>
Message-ID: <BANLkTinfTFPrVcVE=ZL+3pw9DthyFfBrkQ@mail.gmail.com>

On 22 April 2011 09:57, Linda Culberson <lculber at mdah.state.ms.us> wrote:
> Chris,
> I don't know if this changes in 3.4, because of the feature listed in the
> release_notes_3_4_0.txt about moving items out of biblioitems (line 151).
> ?But the problem we had with records with large numbers of items wasn't just
> in Zebra, it was in the overall size of the MARC record exceeding the 99999
> record length.
>
Hi Linda

Yes it was the size of the record exceeding that, that meant when it
was being exported as iso2709 it was truncated, and broke zebra. If
you export it as xml (-x) then this limitation doesn't happen.

The only other place I am aware of, that this might be a problem was
if you wanted to export all your records as iso2709 for some other
reason.

> Does removing the items from biblioitems help?
>
Yes and No, it speeds everything up, but when you go to index, you
still need to give zebra the entire record, which without -x will
cause it to be truncated on export.

Hope this helps

Chris

From henridamien.laurent at gmail.com  Fri Apr 22 00:04:54 2011
From: henridamien.laurent at gmail.com (LAURENT Henri-Damien)
Date: Fri, 22 Apr 2011 00:04:54 +0200
Subject: [Koha-devel] Bug 2453
In-Reply-To: <BANLkTimOeBWpywdpnCBuXuGb6Bckk3yW_w@mail.gmail.com>
References: <5.2.1.1.2.20110421172507.04690e98@stormy.ca>
	<BANLkTimOeBWpywdpnCBuXuGb6Bckk3yW_w@mail.gmail.com>
Message-ID: <4DB0AA06.3030103@gmail.com>

Le 21/04/2011 23:47, Chris Cormack a ?crit :
> On 22 April 2011 09:44, Paul <paul.a at aandc.org> wrote:
>> I've just been reading Bug 2453 - (very) large biblio/item handling; it
>> appears to have received no comments since 2010-05-21. If I understand the
>> situation correctly (from Paul Poulain's comments) if a biblio/items record
>> exceeds 100Kb then zebra may fail. He suggests:
>>
>> [snip] 2 possibilities :
>> - fix Koha to limit the size of a biblio/items (check that we don't ge more
>> than 100kB)
>> - fix the export during rebuild_zebra.
>> I think the 1st solution is the best.
>>
>> I am currently defining our serials cataloguing policy - choices: one biblio
>> for perhaps 1,200 items; one biblio per item (probably unmanageable in
>> OPAC); or one biblio per year|volume. Currently the third choice is
>> preferred, one (perhaps repetitive) biblio with up to 12 items, occasionally
>> 52 (we do not handle dailies.)
>>
>> However, even at twelve items per biblio we will often go beyond 100Kb; we
>> are a research library where abstracts, indexes and keywords are, by
>> definition, fairly voluminous and are the "bread and butter" of our users.
>> Should this bug prompt me to perhaps rethink the policy?  Has 3.4 changed
>> this situation?  Is there anything else in the pipeline that I should be
>> aware of?
>>
> If you run rebuild_zebra.pl with the -x switch (just for biblio -x
> doesnt work with authorities) this limitation does not exist.
Well, strictly speaking, you are right, with -x, the whole information
will be indexed.
But, since koha internally takes only iso2709 from zebra and not working
directly from marcxml then if your iso2709 is big... and your
biblionumber is at the end of your iso2709, then you will not be able to
get the biblionumber and therefore not be able to get the record.
And then, limiting the quantity of items indexed can be a workaround.
my 2 cents.

> 
> I suggest running 2 rebuild_zebra.pl calls one for biblios
> rebuild_zebra.pl -x -b -z
> and one for authorities
> rebuild_zebra.pl -a -z
> 
> Chris


Henri-Damien LAURENT

From paul.a at aandc.org  Fri Apr 22 01:24:24 2011
From: paul.a at aandc.org (Paul)
Date: Thu, 21 Apr 2011 19:24:24 -0400
Subject: [Koha-devel] Bug 2453
In-Reply-To: <4DB0A858.8070604@mdah.state.ms.us>
References: <BANLkTimOeBWpywdpnCBuXuGb6Bckk3yW_w@mail.gmail.com>
	<5.2.1.1.2.20110421172507.04690e98@stormy.ca>
	<BANLkTimOeBWpywdpnCBuXuGb6Bckk3yW_w@mail.gmail.com>
Message-ID: <5.2.1.1.2.20110421190343.0494eeb8@localhost>

Thank you both Chris and Linda.

We were also intending to use a couple of spare subfields in 952 for these 
keywords and abstracts. I'm now wondering if the [default?] mapping to 
$unlinked_item_subfields will exceed the 99999 limit?

I'll set up a dummy set of entries tomorrow, with more than 10Kb in the 
item abstracts, and more than 100Kb in the biblio/items and give it a spin.

Resetting the cron job for re-indexing zebra will probably present no 
difficulties (set to every minute at the moment.)

Chris: very small point, a typo? at line 120 of release_notes_3_4_0.txt -- 
'like" should be "link"?

Thanks and best regards,
Paul

At 04:57 PM 4/21/2011 -0500, Linda Culberson wrote:
>Chris,
>I don't know if this changes in 3.4, because of the feature listed in the 
>release_notes_3_4_0.txt about moving items out of biblioitems (line 
>151).  But the problem we had with records with large numbers of items 
>wasn't just in Zebra, it was in the overall size of the MARC record 
>exceeding the 99999 record length.
>
>Does removing the items from biblioitems help?
>
>Thanks.
>Linda Culberson
>
>On 4/21/2011 4:47 PM, Chris Cormack wrote:
>>On 22 April 2011 09:44, Paul<paul.a at aandc.org>  wrote:
>>>I've just been reading Bug 2453 - (very) large biblio/item handling; it
>>>appears to have received no comments since 2010-05-21. If I understand the
>>>situation correctly (from Paul Poulain's comments) if a biblio/items record
>>>exceeds 100Kb then zebra may fail. He suggests:
>>>
>>>[snip] 2 possibilities :
>>>- fix Koha to limit the size of a biblio/items (check that we don't ge more
>>>than 100kB)
>>>- fix the export during rebuild_zebra.
>>>I think the 1st solution is the best.
>>>
>>>I am currently defining our serials cataloguing policy - choices: one biblio
>>>for perhaps 1,200 items; one biblio per item (probably unmanageable in
>>>OPAC); or one biblio per year|volume. Currently the third choice is
>>>preferred, one (perhaps repetitive) biblio with up to 12 items, occasionally
>>>52 (we do not handle dailies.)
>>>
>>>However, even at twelve items per biblio we will often go beyond 100Kb; we
>>>are a research library where abstracts, indexes and keywords are, by
>>>definition, fairly voluminous and are the "bread and butter" of our users.
>>>Should this bug prompt me to perhaps rethink the policy? ? Has 3.4 changed
>>>this situation? ? Is there anything else in the pipeline that I should be
>>>aware of?
>>If you run rebuild_zebra.pl with the -x switch (just for biblio -x
>>doesnt work with authorities) this limitation does not exist.
>>
>>I suggest running 2 rebuild_zebra.pl calls one for biblios
>>rebuild_zebra.pl -x -b -z
>>and one for authorities
>>rebuild_zebra.pl -a -z
>>
>>Chris
>>_______________________________________________
>>Koha-devel mailing list
>>Koha-devel at lists.koha-community.org
>>http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>>website : http://www.koha-community.org/
>>git : http://git.koha-community.org/
>>bugs : http://bugs.koha-community.org/
>
>--
>Linda Culberson                 lculber at mdah.state.ms.us
>Archives and Records Services Division
>Ms. Dept. of Archives & History
>P. O. Box 571
>Jackson, MS 39205-0571
>Telephone:  601/576-6873
>Facsimile:  601/576-6824
>
>
>_______________________________________________
>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 chrisc at catalyst.net.nz  Fri Apr 22 12:12:23 2011
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Fri, 22 Apr 2011 22:12:23 +1200
Subject: [Koha-devel] Koha 3.4.0 released
Message-ID: <20110422101223.GS6680@rorohiko>

Kia ora tatou

The Koha development team is happy to announce the release of Koha
3.4.0.

Koha 3.4.0 is a major feature release that contains major changes to
underlying architecture (adoption of Template::Toolkit for templating)
and performance enhancements (removal of item data from biblio records). 

These changes, in addition to the inclusion of many new features, mean a
lot of new strings for translators to translate.

For these reasons we recommend that people who are already running Koha
in
production delay their upgrade until 3.4.1, due May 22, to give the
translators
time to finish, and for the removing of item data to be streamlined. If
you do wish to upgrade please make sure you read the UPGRADE section of
the INSTALL document. 

The development team would like to thank all the people who have made
this release possible. Please take time to read the release notes.

RELEASE NOTES FOR KOHA 3.4.0 - 22 April 2011
========================================================================

Koha is the first free and open source software library automation
package 
(ILS). Development is sponsored by libraries of varying types and sizes, 
volunteers, and support companies from around the world.  
The website for the Koha project is 

    http://koha-community.org/


Koha 3.4.0 is released in memoriam of Elizabeth Mae Gallagher-Mitchell
December 20, 2010 - March 10, 2011.
Haere. M?u tai ata; m?ku tai ahiahi 

Koha 3.4.0 can be downloaded from:

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

Installation instructions can be found at:

    http://wiki.koha-community.org/wiki/Installation_Documentation
    
    OR in the INSTALL files that come in the tarball

Koha 3.4.0 is a major feature release.

New features in 3.4.0
======================

  ACQUISITIONS:
    * Can filter budgets by active status and date on the acquisitions
      homepage
    * Freetext field added to specify one-off delivery
    * addresses/comments
    * Can create multiple orders from a staged MARC file
    * New cronjob to delete old suggestions
    * Warning when ordering from an external source when a catalogue
      record already exists
    * Currency can be set when ordering

  ADMINISTRATION
    * Many additional granular permissions are added
    * Ability to replace the favicon from within the admin interface
    * Ability to import and export MARC frameworks
    * Separate field for library state/province
    * WYSIWYG editor for Koha News
    * Ability to add news items to slips
    * Label batch edit interface allows entry of items by scanning
      barcodes
    * Can choose the MARC framework when importing records
    
  CATALOGING
    * NORMARC support added
    * Edits to Authority records are now logged
    * 005 field updated when a Biblio or Authority record is edited
    * Added edit record/edit items to the search result if logged in 
      user has cataloguing privileges
    * Add support of record linking by record control number in $w
    * 006/008 plugins much improved

  CIRCULATION
    * Callnumbers are displayed when an item is checked in
    * Waiting holds now show the date they were marked waiting
    * Show guarantees checkouts when checking out to a guarantor and
    * vice versa
    * Show holds waiting for a patron on check in
    * New report wizard for Holds
    * Syspref to disable the ability for borrowers to choose their
      pickup library for holds
    * Self Checkout supports login
    * Ability to set 'hard' due dates, which will not allow items to 
      be checked out past that
    * Printed receipts can now include the library phone, address and 
      other fields
    * Fast Add framework at circulation
    * Ability to define due dates in the past
    * Checkin page now lists fines owed by patron
    * Preferences for defining the fine level when a staff
      override is needed
    * Search to Hold feature

  OPAC
    * New system preference added to allow the librarians to hide
      items from the OPAC.  See docs/opac/OpacHiddenItems.txt for
      more information.
    * Authority display improved in OPAC
    * Allow the patron to choose which library they wish to make a
      purchase suggestion for
    * Added the ability to hide the name of a reviewer/commenter in
      the OPAC
    * CSS/HTML and other UI improvements
    * Lists respect the XSLT bibliograhic display preferences
    * Truncation of facets now controllable by a system preference
    * Can use 856$u to store an image URI which Koha can then display in
    * the OPAC
    * User can renew multiple items at once
    * A new librarian-controlled column added to the 'My Summary' page
    * on the OPAC
    * Recent comments view for the OPAC (allow users to see recently
    * reviewed items)
    * Feature to make the OPAC private (allow only logged in users to
    * search/view items)
    * Ability to edit what displays when no results are found
    * Privacy feature allowing the user to specify when their reading
      (or circulation) records are anonymised
    * opacstylesheet can link to a url anywhere, not just a local file
      
  PATRONS
    * Separate field for state/province
    * Ability to duplicate a Patron
    * Print overdue and hold notices for patrons without email addresses
        
  REPORTS
    * Run a report immediately after creation
    * The list of saved reports has pagination and can be sorted
    * SQL formatting improvements when viewing a report
    * Parameters can be set in guided reports

  SEARCHING
    * NoZebra mode is officially deprecated.
    * Added shelf location to the indexes
    * Added a search link for analytics to serial records
    * Subjects can now search complete subfields
    * MARC21 tag 751 (geographical entry) is now searchable
    * UNIMARC EAN/UPC/Music fields added to the indices
    * usecontrolnumber syspref allows you to link the 78X fields to 
      other names of the same serial

  SERIALS
    * 50 bugs fixed in serials management 5508

  STAFF INTERFACE
    * Enumchron added to the biblio detail page
    * Improvements to suggestion management
    * Can use 856$u to store an image URI which Koha can then display in
      the staff interface.
    * Cart is emptied when a user logs out
    * IntranetUserCSS preference added to allow styling of staff
    * interface
    
  INTERFACE
    * New icon set for itemtypes (Nimes)
    * LibLime kids iconset resized to consistent size
    * Seshat itemtype iconset added (Naropa College)
    * CSS classes added to the XSLT results to enable styling
          
  INTERNATIONALIZTION
    * New initialization SQL files for Norwegian

  INTERNALS, PACKAGING AND PERFORMANCE
    * Koha now uses Template::Toolkit rather than HTML::Template::Pro
    * Improvements to test case coverage
    * .packages file for Ubuntu Maverick
    * Testing using Test::Perl::Critic
    * CGI::Session can now be stored in Memcached
    * mod_deflate added to save bandwidth
    * Move items out of biblioitems
      
  COMMAND LINE UTILITIES
    * Script to update all items and biblio
    * Script to set and get system preferences from the command line

  BUGFIXES
    * Approximately 633 tracked bugs and enhancement requests
      are addressed in this release

System Preferences
======================

The following system preferences are new in 3.4.0:
    
    * AllFinesNeedOverride
    * AllowFineOverride
    * AllowPurchaseSuggestionBranchChoice
    * AllowSelfCheckReturns
    * AlternateHoldingsField
    * AlternateHoldingsSeparator
    * AuthoritiesLog
    * COinSinOPACResults
    * Display856uAsImage
    * displayFacetCount
    * FacetLabelTruncationLength
    * FineNotifyAtCheckin
    * HoldNotifyAtCheckin
    * IntranetFavicon
    * IntranetUserCSS
    * itemBarcodeInputFilter
    * maxItemsInSearchResults
    * maxRecordsForFacets
    * OPACAllowUserToChooseBranch
    * OPACDisplay856uAsImage
    * OpacFavicon
    * OpacHiddenItems
    * OPACMySummaryHTML
    * OPACNoResultsFound
    * OpacPrivacy
    * OpacPublic
    * SelfCheckHelpMessage
    * SelfCheckTimeout
    * ShowReviewer
    * StaffAuthorisedValueImages
    * TraceCompleteSubfields
    * TraceSubjectSubdivisions
    * UseAuthoritiesForTracings
    * UseControlNumber
    * UseTablesortForCirc
    * WaitingNotifyAtCheckin

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

    Changes since 3.2:
    
    * Template::Toolkit


Documentation
======================

As of Koha 3.2, the Koha manual is now maintained in DocBook.  The
home page for Koha documentation is 

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

As of the date of these release notes, only the english version of the
Koha manual is available:

    http://koha-community.org/documentation/3-4-manual/

The Git repository for the Koha manual can be found at

    http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary

Translations
======================

Complete or near-complete translations of the OPAC and staff
interface are available in this release for the following languages:

  * Chinese
  * Danish
  * English (New Zealand)
  * English (USA)
  * French (France)
  * French (Canada)
  * German
  * Greek
  * Hindi
  * Italian
  * Norwegian
  * Portuguese
  * Spanish
  * Turkish

Partial translations are available for various other languages.

The Koha team welcomes additional translations; please see

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

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

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

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

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

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

The release team for Koha 3.4 is

Release Manager:        Chris Cormack <chrisc at catalyst.net.nz>
Documentation Manager:  Nicole C Engard <nengard at gmail.com>
Translation Manager:    Fr?d?ric Demians <frederic at tamil.fr>
Release Maintainer (3.2.x):
                        Chris Nighswonger <cnighswonger at foundations.edu>
Release Maintainer (3.4.x):
                        Chris Nighswonger <cnighswonger at foundations.edu>
QA Manager:             Colin Campbell


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

We thank the following libraries who are known to have sponsored
new features in Koha 3.4:

  * Aix-Marseille University, France
  * East Brunswick Public Library, USA
  * Food and Agriculture Organisation of the United Nations
  * Goddard College, USA
  * Hauraki District Council, New Zealand
  * Horowhenua Library Trust, New Zealand
  * La Trappe Monastery, France
  * Lyon3 University, France
  * Marlboro College, USA
  * MassCat, USA
  * Merrill Memorial Library, Maine, USA
  * Middletown Township Public Library, USA
  * Ministry of Culture, Spanish Government, Spain
  * Naropa College, USA
  * Nelsonville Public Library, USA
  * Nimes, France
  * Regionbibliotek Halland, Sweden
  * Rijksmuseum Research Library, Netherlands
  * SAN Ouest Provence, France
  * SAR, USA
  * St Etienne University, France
  * VOKAL, USA
  
We thank the following individuals who contributed patches to
Koha 3.4.0. 

  * Alex Arnaud
  * Amit Gupta
  * Andrew Elwell
  * Bernardo Gonzalez Kriegel
  * Brian Engard
  * Brice Sanchez  
  * Chris Cormack
  * Chris Nighswonger
  * Christophe Croullebois
  * Christopher Hall
  * Cindy Murdock Ames
  * Claudia
  * Colin Campbell
  * D Ruth Bavousett  
  * Daniel Grobani
  * David Schuster
  * Dobrica Pavlinusic
  * Doug Dearden
  * Edward Allen
  * Fr?d?ric Demians
  * Fr?d?rick Capovilla
  * Fr?re S?bastien Marie
  * Galen Charlton
  * Garry Collum
  * Henri-Damien LAURENT
  * Ian Walls
  * Jane Wagner
  * Janusz Kaczmarek
  * Jared Camins-Esakov
  * Jean-Andr? Santoni
  * Jerome Charaoui
  * Jesse Weaver
  * Joe Atzberger
  * Johnboy
  * Jonathan Druart
  * Julian Maurice
  * Katrin Fischer
  * Koustubha Kale
  * Lars Wirzenius
  * Liz Rea
  * Magnus Enger
  * Marcel de Rooy
  * Mark Gavillet
  * Mason James
  * Matthew Hunt
  * Matthias Meusburger
  * MJ Ray
  * Nahuel ANGELINETTI
  * Nate Curulla
  * Nicolas Morin
  * Nicole C. Engard
  * Owen Leonard
  * Paul Poulain
  * Reed Wade
  * Ricardo Dias Marques
  * Robin Sheat
  * Salvador Zaragoza Rubio
  * Savitra Sirohi
  * Serhij Dubyk {?????? ?????}
  * Sophie Meynieux
  * Spartaness
  * Srdjan Jankovic
  * St?phane Delaune
  * Tomas Cohen Arazi
  * Will Stokes
  * Zach Sim
  * Zeno Tajoli


We regret any omissions.  If a contributor has been inadvertantly
missed, please send a patch against these release notes to 
koha-patches at lists.koha-community.org.

Revision control notes
======================

The Koha project uses Git for version control.  The current development 
version of Koha can be retrieved by checking out the master branch of 

    git://git.koha-community.org/koha.git

The branch for Koha 3.4.x (i.e., this version of Koha and future bugfix
releases) is 3.4.x.

The next major feature release of Koha will be Koha 3.6.0.

Bugs and feature requests
======================

Bug reports and feature requests can be filed at the Koha bug
tracker at

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


Ehara taku toa i te toa takitahi, engari he toa takitini
-- 
Chris Cormack
Catalyst IT Ltd.
+64 4 803 2238
PO Box 11-053, Manners St, Wellington 6142, New Zealand
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: </pipermail/koha-devel/attachments/20110422/cdc0e7d3/attachment.pgp>

From gmcharlt at gmail.com  Fri Apr 22 16:36:58 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Fri, 22 Apr 2011 10:36:58 -0400
Subject: [Koha-devel] Koha 3.4.0 released
In-Reply-To: <20110422101223.GS6680@rorohiko>
References: <20110422101223.GS6680@rorohiko>
Message-ID: <BANLkTikiaTkkeh9oM8qh70Unq+n6_qFMhA@mail.gmail.com>

Hi Chris,

2011/4/22 Chris Cormack <chrisc at catalyst.net.nz>:
> Kia ora tatou
>
> The Koha development team is happy to announce the release of Koha
> 3.4.0.

Many congratulations for the release!

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From tomascohen at gmail.com  Fri Apr 22 16:37:43 2011
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Fri, 22 Apr 2011 11:37:43 -0300
Subject: [Koha-devel] Koha 3.4.0 released
In-Reply-To: <BANLkTikiaTkkeh9oM8qh70Unq+n6_qFMhA@mail.gmail.com>
References: <20110422101223.GS6680@rorohiko>
	<BANLkTikiaTkkeh9oM8qh70Unq+n6_qFMhA@mail.gmail.com>
Message-ID: <BANLkTinpdWeoSmfWC7Mb7_a9FSneshsWSw@mail.gmail.com>

RM++
Koha++

To+

On Fri, Apr 22, 2011 at 11:36 AM, Galen Charlton <gmcharlt at gmail.com> wrote:

> Hi Chris,
>
> 2011/4/22 Chris Cormack <chrisc at catalyst.net.nz>:
> > Kia ora tatou
> >
> > The Koha development team is happy to announce the release of Koha
> > 3.4.0.
>
> Many congratulations for the release!
>
> Regards,
>
> Galen
> --
> Galen Charlton
> gmcharlt at gmail.com
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110422/e8179f3b/attachment.htm>

From Cole.Hudson at hc.msu.edu  Fri Apr 22 19:43:15 2011
From: Cole.Hudson at hc.msu.edu (Cole Hudson)
Date: Fri, 22 Apr 2011 13:43:15 -0400
Subject: [Koha-devel] issues with label creator item search
In-Reply-To: <BANLkTikuyRq-=ZgBPdB8gfrP3t5U44HG4A@mail.gmail.com>
References: <89A35FEF98F9384BBB1360526A846BC720950E@TEAM-EXCHANGE1.hc.msu.edu>
	<BANLkTikuyRq-=ZgBPdB8gfrP3t5U44HG4A@mail.gmail.com>
Message-ID: <89A35FEF98F9384BBB1360526A846BC70555A3AA@TEAM-EXCHANGE1.hc.msu.edu>

Hi Chris,

 

Thanks for the reply.  I?ve re-indexed with the appropriate pl script, but it hasn?t fixed the issue (although, just to note, I am running nozebra instead of zebra because the collection I?m working with is not very extensive.)  I know the searching faq link mentioned using a few parameters like ?r, -v, I didn?t see that the same were available when using rebuild_nozebra.pl; I only saw mention of of ?d and ?s with rebuild_nozebra.

 

Cole

 

Note: sorry about posting to the development list, I probably should have directed this to the koha list instead.

From: Chris Nighswonger [mailto:cnighswonger at foundations.edu] 
Sent: Wednesday, April 20, 2011 10:12 PM
To: Cole Hudson
Cc: koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] issues with label creator item search

 

Hi Cole,

2011/4/20 Cole Hudson <Cole.Hudson at hc.msu.edu>

Hi all,

I seem to be having some trouble with label creator item search tool in Koha 3.02.06, running on Ubuntu 10.10.  When I go to search for items to add to a batch, I have a couple problems.  First, I'm not able to search with the added on date fields.  I select a date, click search, and nothing appears.  Also, when I manage to search for an item, I don't get all of my results.  After about the first 20 or so results appear, I just get blank entries in the form of this:


I've just tested this out on my sandbox running 3.03.00.026 and it works fine. It should also work fine in the latest stable release which is 3.2.7. I'd recommend upgrading to 3.2.7 in any case.

You could also have an indexing problem. Check out http://koha-community.org/documentation/faq/searching/ as this information applies to any search in Koha.

Kind regards,
Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110422/946a3e81/attachment-0001.htm>

From cnighswonger at foundations.edu  Fri Apr 22 21:05:41 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Fri, 22 Apr 2011 15:05:41 -0400
Subject: [Koha-devel] Koha 3.4.0 released
In-Reply-To: <20110422101223.GS6680@rorohiko>
References: <20110422101223.GS6680@rorohiko>
Message-ID: <BANLkTi=NP5c1Azsk074AgbJCTcSb4SRiXQ@mail.gmail.com>

2011/4/22 Chris Cormack <chrisc at catalyst.net.nz>

> Kia ora tatou
>
> The Koha development team is happy to announce the release of Koha
> 3.4.0.
>

Congratulations!

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

From cnighswonger at foundations.edu  Fri Apr 22 21:07:12 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Fri, 22 Apr 2011 15:07:12 -0400
Subject: [Koha-devel] issues with label creator item search
In-Reply-To: <89A35FEF98F9384BBB1360526A846BC70555A3AA@TEAM-EXCHANGE1.hc.msu.edu>
References: <89A35FEF98F9384BBB1360526A846BC720950E@TEAM-EXCHANGE1.hc.msu.edu>
	<BANLkTikuyRq-=ZgBPdB8gfrP3t5U44HG4A@mail.gmail.com>
	<89A35FEF98F9384BBB1360526A846BC70555A3AA@TEAM-EXCHANGE1.hc.msu.edu>
Message-ID: <BANLkTinmFm5GMeyBR7BWeE3=exY_nBuF+Q@mail.gmail.com>

On Fri, Apr 22, 2011 at 1:43 PM, Cole Hudson <Cole.Hudson at hc.msu.edu> wrote:

> Hi Chris,
>
>
>
> Thanks for the reply.  I?ve re-indexed with the appropriate pl script, but
> it hasn?t fixed the issue (although, just to note, I am running nozebra
> instead of zebra because the collection I?m working with is not very
> extensive.)  I know the searching faq link mentioned using a few parameters
> like ?r, -v, I didn?t see that the same were available when using
> rebuild_nozebra.pl; I only saw mention of of ?d and ?s with
> rebuild_nozebra.
>
>
Ahh, I'd recommend switching over to Zebra as nozebra is deprecated and has
not been supported for quite some time. I'm not sure what might be the
problem with the search on a nozebra installation.

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

From jransom at library.org.nz  Sat Apr 23 01:47:12 2011
From: jransom at library.org.nz (Joann Ransom)
Date: Sat, 23 Apr 2011 11:47:12 +1200
Subject: [Koha-devel] [Koha] Koha 3.4.0 released
In-Reply-To: <20110422101223.GS6680@rorohiko>
References: <20110422101223.GS6680@rorohiko>
Message-ID: <BANLkTikzOmm2CX0fAQ8iTjDWGvdr3o3HnQ@mail.gmail.com>

Congratulations, well done and thanks to the team who made this happen.

It is heart warming stuff to read all the organisations who sponsored
development and all the individuals who contributed patches.

Thank you.

Cheers Jo.

2011/4/22 Chris Cormack <chrisc at catalyst.net.nz>

> Kia ora tatou
>
> The Koha development team is happy to announce the release of Koha
> 3.4.0.
>
> Koha 3.4.0 is a major feature release that contains major changes to
> underlying architecture (adoption of Template::Toolkit for templating)
> and performance enhancements (removal of item data from biblio records).
>
> These changes, in addition to the inclusion of many new features, mean a
> lot of new strings for translators to translate.
>
> For these reasons we recommend that people who are already running Koha
> in
> production delay their upgrade until 3.4.1, due May 22, to give the
> translators
> time to finish, and for the removing of item data to be streamlined. If
> you do wish to upgrade please make sure you read the UPGRADE section of
> the INSTALL document.
>
> The development team would like to thank all the people who have made
> this release possible. Please take time to read the release notes.
>
> RELEASE NOTES FOR KOHA 3.4.0 - 22 April 2011
> ========================================================================
>
> Koha is the first free and open source software library automation
> package
> (ILS). Development is sponsored by libraries of varying types and sizes,
> volunteers, and support companies from around the world.
> The website for the Koha project is
>
>    http://koha-community.org/
>
>
> Koha 3.4.0 is released in memoriam of Elizabeth Mae Gallagher-Mitchell
> December 20, 2010 - March 10, 2011.
> Haere. M?u tai ata; m?ku tai ahiahi
>
> Koha 3.4.0 can be downloaded from:
>
>    http://download.koha-community.org/koha-3.04.00.tar.gz
>
> Installation instructions can be found at:
>
>    http://wiki.koha-community.org/wiki/Installation_Documentation
>
>    OR in the INSTALL files that come in the tarball
>
> Koha 3.4.0 is a major feature release.
>
> New features in 3.4.0
> ======================
>
>  ACQUISITIONS:
>    * Can filter budgets by active status and date on the acquisitions
>      homepage
>    * Freetext field added to specify one-off delivery
>    * addresses/comments
>    * Can create multiple orders from a staged MARC file
>    * New cronjob to delete old suggestions
>    * Warning when ordering from an external source when a catalogue
>      record already exists
>    * Currency can be set when ordering
>
>  ADMINISTRATION
>    * Many additional granular permissions are added
>    * Ability to replace the favicon from within the admin interface
>    * Ability to import and export MARC frameworks
>    * Separate field for library state/province
>    * WYSIWYG editor for Koha News
>    * Ability to add news items to slips
>    * Label batch edit interface allows entry of items by scanning
>      barcodes
>    * Can choose the MARC framework when importing records
>
>  CATALOGING
>    * NORMARC support added
>    * Edits to Authority records are now logged
>    * 005 field updated when a Biblio or Authority record is edited
>    * Added edit record/edit items to the search result if logged in
>      user has cataloguing privileges
>    * Add support of record linking by record control number in $w
>    * 006/008 plugins much improved
>
>  CIRCULATION
>    * Callnumbers are displayed when an item is checked in
>    * Waiting holds now show the date they were marked waiting
>    * Show guarantees checkouts when checking out to a guarantor and
>    * vice versa
>    * Show holds waiting for a patron on check in
>    * New report wizard for Holds
>    * Syspref to disable the ability for borrowers to choose their
>      pickup library for holds
>    * Self Checkout supports login
>    * Ability to set 'hard' due dates, which will not allow items to
>      be checked out past that
>    * Printed receipts can now include the library phone, address and
>      other fields
>    * Fast Add framework at circulation
>    * Ability to define due dates in the past
>    * Checkin page now lists fines owed by patron
>    * Preferences for defining the fine level when a staff
>      override is needed
>    * Search to Hold feature
>
>  OPAC
>    * New system preference added to allow the librarians to hide
>      items from the OPAC.  See docs/opac/OpacHiddenItems.txt for
>      more information.
>    * Authority display improved in OPAC
>    * Allow the patron to choose which library they wish to make a
>      purchase suggestion for
>    * Added the ability to hide the name of a reviewer/commenter in
>      the OPAC
>    * CSS/HTML and other UI improvements
>    * Lists respect the XSLT bibliograhic display preferences
>    * Truncation of facets now controllable by a system preference
>    * Can use 856$u to store an image URI which Koha can then display in
>    * the OPAC
>    * User can renew multiple items at once
>    * A new librarian-controlled column added to the 'My Summary' page
>    * on the OPAC
>    * Recent comments view for the OPAC (allow users to see recently
>    * reviewed items)
>    * Feature to make the OPAC private (allow only logged in users to
>    * search/view items)
>    * Ability to edit what displays when no results are found
>    * Privacy feature allowing the user to specify when their reading
>      (or circulation) records are anonymised
>    * opacstylesheet can link to a url anywhere, not just a local file
>
>  PATRONS
>    * Separate field for state/province
>    * Ability to duplicate a Patron
>    * Print overdue and hold notices for patrons without email addresses
>
>  REPORTS
>    * Run a report immediately after creation
>    * The list of saved reports has pagination and can be sorted
>    * SQL formatting improvements when viewing a report
>    * Parameters can be set in guided reports
>
>  SEARCHING
>    * NoZebra mode is officially deprecated.
>    * Added shelf location to the indexes
>    * Added a search link for analytics to serial records
>    * Subjects can now search complete subfields
>    * MARC21 tag 751 (geographical entry) is now searchable
>    * UNIMARC EAN/UPC/Music fields added to the indices
>    * usecontrolnumber syspref allows you to link the 78X fields to
>      other names of the same serial
>
>  SERIALS
>    * 50 bugs fixed in serials management 5508
>
>  STAFF INTERFACE
>    * Enumchron added to the biblio detail page
>    * Improvements to suggestion management
>    * Can use 856$u to store an image URI which Koha can then display in
>      the staff interface.
>    * Cart is emptied when a user logs out
>    * IntranetUserCSS preference added to allow styling of staff
>    * interface
>
>  INTERFACE
>    * New icon set for itemtypes (Nimes)
>    * LibLime kids iconset resized to consistent size
>    * Seshat itemtype iconset added (Naropa College)
>    * CSS classes added to the XSLT results to enable styling
>
>  INTERNATIONALIZTION
>    * New initialization SQL files for Norwegian
>
>  INTERNALS, PACKAGING AND PERFORMANCE
>    * Koha now uses Template::Toolkit rather than HTML::Template::Pro
>    * Improvements to test case coverage
>    * .packages file for Ubuntu Maverick
>    * Testing using Test::Perl::Critic
>    * CGI::Session can now be stored in Memcached
>    * mod_deflate added to save bandwidth
>    * Move items out of biblioitems
>
>  COMMAND LINE UTILITIES
>    * Script to update all items and biblio
>    * Script to set and get system preferences from the command line
>
>  BUGFIXES
>    * Approximately 633 tracked bugs and enhancement requests
>      are addressed in this release
>
> System Preferences
> ======================
>
> The following system preferences are new in 3.4.0:
>
>    * AllFinesNeedOverride
>    * AllowFineOverride
>    * AllowPurchaseSuggestionBranchChoice
>    * AllowSelfCheckReturns
>    * AlternateHoldingsField
>    * AlternateHoldingsSeparator
>    * AuthoritiesLog
>    * COinSinOPACResults
>    * Display856uAsImage
>    * displayFacetCount
>    * FacetLabelTruncationLength
>    * FineNotifyAtCheckin
>    * HoldNotifyAtCheckin
>    * IntranetFavicon
>    * IntranetUserCSS
>    * itemBarcodeInputFilter
>    * maxItemsInSearchResults
>    * maxRecordsForFacets
>    * OPACAllowUserToChooseBranch
>    * OPACDisplay856uAsImage
>    * OpacFavicon
>    * OpacHiddenItems
>    * OPACMySummaryHTML
>    * OPACNoResultsFound
>    * OpacPrivacy
>    * OpacPublic
>    * SelfCheckHelpMessage
>    * SelfCheckTimeout
>    * ShowReviewer
>    * StaffAuthorisedValueImages
>    * TraceCompleteSubfields
>    * TraceSubjectSubdivisions
>    * UseAuthoritiesForTracings
>    * UseControlNumber
>    * UseTablesortForCirc
>    * WaitingNotifyAtCheckin
>
> System requirements
> ======================
>
>    Changes since 3.2:
>
>    * Template::Toolkit
>
>
> Documentation
> ======================
>
> As of Koha 3.2, the Koha manual is now maintained in DocBook.  The
> home page for Koha documentation is
>
>    http://koha-community.org/documentation/
>
> As of the date of these release notes, only the english version of the
> Koha manual is available:
>
>    http://koha-community.org/documentation/3-4-manual/
>
> The Git repository for the Koha manual can be found at
>
>    http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary
>
> Translations
> ======================
>
> Complete or near-complete translations of the OPAC and staff
> interface are available in this release for the following languages:
>
>  * Chinese
>  * Danish
>  * English (New Zealand)
>  * English (USA)
>  * French (France)
>  * French (Canada)
>  * German
>  * Greek
>  * Hindi
>  * Italian
>  * Norwegian
>  * Portuguese
>  * Spanish
>  * Turkish
>
> Partial translations are available for various other languages.
>
> The Koha team welcomes additional translations; please see
>
>    http://wiki.koha-community.org/wiki/Translating_Koha
>
> for information about translating Koha, and join the koha-translate
> list to volunteer:
>
>    http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-translate
>
> The most up-to-date translations can be found at:
>
>    http://translate.koha-community.org/
>
> Release Team
> ======================
>
> The release team for Koha 3.4 is
>
> Release Manager:        Chris Cormack <chrisc at catalyst.net.nz>
> Documentation Manager:  Nicole C Engard <nengard at gmail.com>
> Translation Manager:    Fr?d?ric Demians <frederic at tamil.fr>
> Release Maintainer (3.2.x):
>                        Chris Nighswonger <cnighswonger at foundations.edu>
> Release Maintainer (3.4.x):
>                        Chris Nighswonger <cnighswonger at foundations.edu>
> QA Manager:             Colin Campbell
>
>
> Credits
> ======================
>
> We thank the following libraries who are known to have sponsored
> new features in Koha 3.4:
>
>  * Aix-Marseille University, France
>  * East Brunswick Public Library, USA
>  * Food and Agriculture Organisation of the United Nations
>  * Goddard College, USA
>  * Hauraki District Council, New Zealand
>  * Horowhenua Library Trust, New Zealand
>  * La Trappe Monastery, France
>  * Lyon3 University, France
>  * Marlboro College, USA
>  * MassCat, USA
>  * Merrill Memorial Library, Maine, USA
>  * Middletown Township Public Library, USA
>  * Ministry of Culture, Spanish Government, Spain
>  * Naropa College, USA
>  * Nelsonville Public Library, USA
>  * Nimes, France
>  * Regionbibliotek Halland, Sweden
>  * Rijksmuseum Research Library, Netherlands
>  * SAN Ouest Provence, France
>  * SAR, USA
>  * St Etienne University, France
>  * VOKAL, USA
>
> We thank the following individuals who contributed patches to
> Koha 3.4.0.
>
>  * Alex Arnaud
>  * Amit Gupta
>  * Andrew Elwell
>  * Bernardo Gonzalez Kriegel
>  * Brian Engard
>  * Brice Sanchez
>  * Chris Cormack
>  * Chris Nighswonger
>  * Christophe Croullebois
>  * Christopher Hall
>  * Cindy Murdock Ames
>  * Claudia
>  * Colin Campbell
>  * D Ruth Bavousett
>  * Daniel Grobani
>  * David Schuster
>  * Dobrica Pavlinusic
>  * Doug Dearden
>  * Edward Allen
>  * Fr?d?ric Demians
>  * Fr?d?rick Capovilla
>  * Fr?re S?bastien Marie
>  * Galen Charlton
>  * Garry Collum
>  * Henri-Damien LAURENT
>  * Ian Walls
>  * Jane Wagner
>  * Janusz Kaczmarek
>  * Jared Camins-Esakov
>  * Jean-Andr? Santoni
>  * Jerome Charaoui
>  * Jesse Weaver
>  * Joe Atzberger
>  * Johnboy
>  * Jonathan Druart
>  * Julian Maurice
>  * Katrin Fischer
>  * Koustubha Kale
>  * Lars Wirzenius
>  * Liz Rea
>  * Magnus Enger
>  * Marcel de Rooy
>  * Mark Gavillet
>  * Mason James
>  * Matthew Hunt
>  * Matthias Meusburger
>  * MJ Ray
>  * Nahuel ANGELINETTI
>  * Nate Curulla
>  * Nicolas Morin
>  * Nicole C. Engard
>  * Owen Leonard
>  * Paul Poulain
>  * Reed Wade
>  * Ricardo Dias Marques
>  * Robin Sheat
>  * Salvador Zaragoza Rubio
>  * Savitra Sirohi
>  * Serhij Dubyk {?????? ?????}
>  * Sophie Meynieux
>  * Spartaness
>  * Srdjan Jankovic
>  * St?phane Delaune
>  * Tomas Cohen Arazi
>  * Will Stokes
>  * Zach Sim
>  * Zeno Tajoli
>
>
> We regret any omissions.  If a contributor has been inadvertantly
> missed, please send a patch against these release notes to
> koha-patches at lists.koha-community.org.
>
> Revision control notes
> ======================
>
> The Koha project uses Git for version control.  The current development
> version of Koha can be retrieved by checking out the master branch of
>
>    git://git.koha-community.org/koha.git
>
> The branch for Koha 3.4.x (i.e., this version of Koha and future bugfix
> releases) is 3.4.x.
>
> The next major feature release of Koha will be Koha 3.6.0.
>
> Bugs and feature requests
> ======================
>
> Bug reports and feature requests can be filed at the Koha bug
> tracker at
>
>    http://bugs.koha-community.org/
>
>
> Ehara taku toa i te toa takitahi, engari he toa takitini
> --
> Chris Cormack
> Catalyst IT Ltd.
> +64 4 803 2238
> PO Box 11-053, Manners St, Wellington 6142, New Zealand
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk2xVIcACgkQZgbcHEvgMLPntACfakO0TBwRA9ocCFryINn8D8tG
> FwMAmwUqueTzMSiD1sq1hnWUE8lJNxvn
> =G1jF
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Koha mailing list  http://koha-community.org
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>
>


-- 
Joann Ransom RLIANZA
Head of Libraries,
Horowhenua Library Trust.

*Q: Why is this email three sentences or less?
A: http://three.sentenc.es*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110423/f3831c4f/attachment-0001.htm>

From kmkale at anantcorp.com  Sat Apr 23 09:21:51 2011
From: kmkale at anantcorp.com (Koustubha Kale)
Date: Sat, 23 Apr 2011 12:51:51 +0530
Subject: [Koha-devel] How to get CAS based Single Sign On working?
Message-ID: <BANLkTim8qfW0ok4ykHtj_dyJ2F8RMQpr3g@mail.gmail.com>

Hi All,
I have a situation where we have a main website based on Joomla. This
Joomla site uses CAS to authenticate users. We would like users ( who
have already logged in to the Joomla site via CAS) to be able to
follow a link to Koha site and be logged in automatically ( e.g.
Single Sign On ).

I have got simple CAS ( not proxy CAS ) working with Koha ( version
3.2.6 ) using the same CAS server as used by Joomla site. Still when I
login to Joomla site with CAS, and then go to Koha and click on login
and follow the CAS login link, I am asked to fill up CAS login
information again. How can this be avoided by using CAS SSO?
I have read through
http://wiki.koha-community.org/wiki/SSO_CAS_improvements and am
confused by the statement "Note: simple sso cas support (no proxy) has
been done already by biblibre, is in testing and should be released in
Koha 3.2" in there. Does this statement mean that SSO is possible with
simple CAS? If yes how to set it up? If not, I have also read through
bugs 6012, 5630 and the CAS Proxy examples. Frankly I haven't been
able to figure out how I can achieve the above required functionality
based on all the reading. Any help is much appreciated..

Another related query is, Is it possible to automatically create users
in Koha once they have authenticated with CAS?


Regards,
Koustubha Kale
Anant Corporation

Contact Details :
Address? : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes
Naka, Thane (w),
? ? ? ? ??? ? ? Maharashtra, India, Pin : 400601.
TeleFax? : +91-22-21720108, +91-22-21720109
Mobile? ?? : +919820715876
Website? : http://www.anantcorp.com
Blog : http://www.anantcorp.com/blog/?author=2

From kmkale at anantcorp.com  Sat Apr 23 13:21:12 2011
From: kmkale at anantcorp.com (Koustubha Kale)
Date: Sat, 23 Apr 2011 16:51:12 +0530
Subject: [Koha-devel] How to get CAS based Single Sign On working?
In-Reply-To: <BANLkTim8qfW0ok4ykHtj_dyJ2F8RMQpr3g@mail.gmail.com>
References: <BANLkTim8qfW0ok4ykHtj_dyJ2F8RMQpr3g@mail.gmail.com>
Message-ID: <BANLkTinoinRyWuEzfPz2XKsFngDz1HOEuA@mail.gmail.com>

On Sat, Apr 23, 2011 at 12:51 PM, Koustubha Kale <kmkale at anantcorp.com> wrote:
> Hi All,
> I have a situation where we have a main website based on Joomla. This
> Joomla site uses CAS to authenticate users. We would like users ( who
> have already logged in to the Joomla site via CAS) to be able to
> follow a link to Koha site and be logged in automatically ( e.g.
> Single Sign On ).

Hi All,
Figured out the SSO part.
Had to make just one change in
<tomcat_home>/webapps/cas/WEB-INF/spring-configuration/ticketGrantingTicketCookieGenerator.xml
Changed p:cookieSecure="false" from true to false since we are not
using https for Koha's login url.
By default the TGT cookie is sent for only encrypted connections so
browser was not sending the TGT cookie for Koha's http login url..

Now is it possible to create users in Koha after successful login via CAS?

Regards,
Koustubha Kale
Anant Corporation

Contact Details :
Address  : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes
Naka, Thane (w),
                Maharashtra, India, Pin : 400601.
TeleFax  : +91-22-21720108, +91-22-21720109
Mobile     : +919820715876
Website  : http://www.anantcorp.com
Blog : http://www.anantcorp.com/blog/?author=2

From nengard at gmail.com  Sun Apr 24 04:05:13 2011
From: nengard at gmail.com (Nicole Engard)
Date: Sat, 23 Apr 2011 22:05:13 -0400
Subject: [Koha-devel] Perl Docs?
Message-ID: <BANLkTinb9WygzR6aPYk-ZTv_9yNd1=tWcw@mail.gmail.com>

Hi all,

I'm wondering who's managing this page:
http://perldoc.koha-community.org/v3.04.00/ - it looks like it's
repeating things an awful lot.

Nicole

From nengard at gmail.com  Sun Apr 24 04:07:23 2011
From: nengard at gmail.com (Nicole Engard)
Date: Sat, 23 Apr 2011 22:07:23 -0400
Subject: [Koha-devel] DB Documentation
Message-ID: <BANLkTi=-j9S4uo9kQeinXQQbQK39JOXojw@mail.gmail.com>

Hello all,

I see that no one volunteered to do the DB Documentation for Koha 3.6
and I'm willing to take this on under the Documentation Manager role.
I just wanted to ask for a refresher on what we decided was the way we
were going to manage this project.  There is the 'COMMENT' option in
MySQL or we can just use the '--' notation after every field.  Once I
know what we want to use I can start documenting the database to the
best of my ability so that it will make reporting easier on people new
to Koha and Koha language (borrowers instead of patrons, reserves
instead of holds, etc etc).

Thanks
Nicole C. Engard

From nengard at gmail.com  Mon Apr 25 14:20:58 2011
From: nengard at gmail.com (Nicole Engard)
Date: Mon, 25 Apr 2011 08:20:58 -0400
Subject: [Koha-devel] Special 3.4 Issue: Official Koha Newsletter: Volume 2,
	Issue 4: April 2011
Message-ID: <BANLkTinHo-LvwJVyZEYYqZ490g=DFwt65Q@mail.gmail.com>

Official Koha Newsletter (ISSN 2153-8328)
Volume 2, Issue 4: April 2011

Special Issue Table of Contents
    Introduction
    Koha 3.4
        Koha 3.4 Released
        Koha 3.4 Statistics
        Koha 3.4 Documentation
        Koha 3.4 Release Notes


Introduction
by Nicole C. Engard

In honor of the timely release of Koha 3.4 and the amazing community
who made it happen this issue of the Koha Newsletter will focus on the
release. The following articles will provide you with all of the
information you?ll need to learn about Koha 3.4. Please read the
entire newsletter on the official Koha site at:
http://koha-community.org/koha-newsletter-volume-2issue-4-april-2011/




Newsletter edited by Nicole C. Engard, Koha Documentation Manager.
Please send future story ideas to me.

From gmcharlt at gmail.com  Mon Apr 25 22:51:06 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Mon, 25 Apr 2011 16:51:06 -0400
Subject: [Koha-devel] Perl Docs?
In-Reply-To: <BANLkTinb9WygzR6aPYk-ZTv_9yNd1=tWcw@mail.gmail.com>
References: <BANLkTinb9WygzR6aPYk-ZTv_9yNd1=tWcw@mail.gmail.com>
Message-ID: <BANLkTinRRvVv94o7tgf8rOSwH_krxkUDYA@mail.gmail.com>

Hi,

On Sat, Apr 23, 2011 at 10:05 PM, Nicole Engard <nengard at gmail.com> wrote:
> I'm wondering who's managing this page:
> http://perldoc.koha-community.org/v3.04.00/ - it looks like it's
> repeating things an awful lot.

I do.  This is generated by a script, and I've fixed the error that
was resulting in the duplicated entries.

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From conan at lugmen.org.ar  Tue Apr 26 17:59:18 2011
From: conan at lugmen.org.ar (Fernando Canizo)
Date: Tue, 26 Apr 2011 12:59:18 -0300
Subject: [Koha-devel] Request for discussion: bugs 3674, 6220, 6224 and 6218
Message-ID: <4DB6EBD6.702@lugmen.org.ar>

I found bug 6220, the bug is the first paragraph only, the rest is me 
rambling on because I thought there were some default password for newly 
created koha users when no password was provided.

6224 explains the same bug better and without rambling.

3674 is an implementation of users with disabled login from biblibre.

And 6218 has a tiny patch to auto generate logins upon user creation if 
none provided.

These all leave me thinking:
	1. what's the purpose of creating users? and
	2. what would be desirable upon user creation?

And those two questions is what I want to discuss here so answer may 
clear my view on this.

There was some prior talking in the comments to bug 6220 with Katrin 
Fischer.

The answer to my first question is pretty simple to me: we create users 
to use the system! But this leads to some defaults we were not enforcing:

- they will require a login (implemented on my patch for 3674), we 
cannot allow users on database without a login

- they will require a password. I think, but on biblibre it seems they 
need users with no password at all and also disabled users, which was 
implemented by making borrowers.password = '!'. It's not clear to me if 
they need both or just the = '!' one.

This leads to the second question:

- do we need empty passwords? or can we cope with disabled ones (='!')

- if we allow disabled logins, then shouldn't we provide a way to 
disable/enable them (right now you can only get a disabled login upon 
user creation, and you cannot disable it again once you enabled it)

- should it be desirable to have auto-generated passwords? If so, we 
need to decide if they would be viewable by superlibrarian upon creation 
(to tell it to the user), or if we silently will send it by mail 
directly to the user. If the second option is choosen, then we need to 
get sure KohaAdminEmailAddress is a valid email on installation and also 
require upon user creation to provide an email (and what if the user 
doesn't have one?)

- KF also suggested these auto-generated passwords should be made 'one 
time only' and force user to provide a new one on first login, which 
means we would need to add a new column to database, something like 
borrowers.password_valid_until which should be a timestamp.

I might be rambling again, so I'll summarize:

- I think database should not have users which don't have a login 
defined. Then we should enforce it by default making 
systempreferences.BorrowerMandatoryField include OPAC login field, and 
also provide a mechanism to avoid empty logins just in case some 
superlibrarian modifies it.

- I would like to hear from you to know how to close all these 
bugs/enhancements propositions.

-- 
Fernando Canizo (a.k.a. conan) - http://conan.muriandre.com/
GCS d? s:+ a C++ P--- L++++ E--- W+++ w--- M-- PE-- !tv b+++ h---- y+++

From nengard at gmail.com  Tue Apr 26 18:33:57 2011
From: nengard at gmail.com (Nicole Engard)
Date: Tue, 26 Apr 2011 12:33:57 -0400
Subject: [Koha-devel] Request for discussion: bugs 3674, 6220,
	6224 and 6218
In-Reply-To: <4DB6EBD6.702@lugmen.org.ar>
References: <4DB6EBD6.702@lugmen.org.ar>
Message-ID: <BANLkTimYByK3wbbT6Rv0HDYdPuxrhzZafQ@mail.gmail.com>

In the US, some libraries require that parents give their children
permission to access the system this means that if the child doesn't
have permission they shouldn't have a log in - so having all patrons
require a log in would be an issue in this situation.

That said I'm thinking we need a system that emails the patron a link
to activate their account and choose a password - that way we aren't
setting an arbitrary default and the librarians aren't assigning
passwords.  This is very common on sites these days.  Another option
is to allow the patron to register online for a card and when they do
that they choose their log in information - either of these options is
secure, but the latter may be a problem in some libraries that require
a form of identification to get a library card in the first place ....

Also a ranting answer from me, don't know if I made anything clearer
or just added more questions.

Nicole

On Tue, Apr 26, 2011 at 11:59 AM, Fernando Canizo <conan at lugmen.org.ar> wrote:
> I found bug 6220, the bug is the first paragraph only, the rest is me
> rambling on because I thought there were some default password for newly
> created koha users when no password was provided.
>
> 6224 explains the same bug better and without rambling.
>
> 3674 is an implementation of users with disabled login from biblibre.
>
> And 6218 has a tiny patch to auto generate logins upon user creation if none
> provided.
>
> These all leave me thinking:
> ? ? ? ?1. what's the purpose of creating users? and
> ? ? ? ?2. what would be desirable upon user creation?
>
> And those two questions is what I want to discuss here so answer may clear
> my view on this.
>
> There was some prior talking in the comments to bug 6220 with Katrin
> Fischer.
>
> The answer to my first question is pretty simple to me: we create users to
> use the system! But this leads to some defaults we were not enforcing:
>
> - they will require a login (implemented on my patch for 3674), we cannot
> allow users on database without a login
>
> - they will require a password. I think, but on biblibre it seems they need
> users with no password at all and also disabled users, which was implemented
> by making borrowers.password = '!'. It's not clear to me if they need both
> or just the = '!' one.
>
> This leads to the second question:
>
> - do we need empty passwords? or can we cope with disabled ones (='!')
>
> - if we allow disabled logins, then shouldn't we provide a way to
> disable/enable them (right now you can only get a disabled login upon user
> creation, and you cannot disable it again once you enabled it)
>
> - should it be desirable to have auto-generated passwords? If so, we need to
> decide if they would be viewable by superlibrarian upon creation (to tell it
> to the user), or if we silently will send it by mail directly to the user.
> If the second option is choosen, then we need to get sure
> KohaAdminEmailAddress is a valid email on installation and also require upon
> user creation to provide an email (and what if the user doesn't have one?)
>
> - KF also suggested these auto-generated passwords should be made 'one time
> only' and force user to provide a new one on first login, which means we
> would need to add a new column to database, something like
> borrowers.password_valid_until which should be a timestamp.
>
> I might be rambling again, so I'll summarize:
>
> - I think database should not have users which don't have a login defined.
> Then we should enforce it by default making
> systempreferences.BorrowerMandatoryField include OPAC login field, and also
> provide a mechanism to avoid empty logins just in case some superlibrarian
> modifies it.
>
> - I would like to hear from you to know how to close all these
> bugs/enhancements propositions.
>
> --
> Fernando Canizo (a.k.a. conan) - http://conan.muriandre.com/
> GCS d? s:+ a C++ P--- L++++ E--- W+++ w--- M-- PE-- !tv b+++ h---- y+++
> _______________________________________________
> 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 chrisc at catalyst.net.nz  Tue Apr 26 20:57:11 2011
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Wed, 27 Apr 2011 06:57:11 +1200
Subject: [Koha-devel] Request for discussion: bugs 3674, 6220,
 6224 and 6218
In-Reply-To: <BANLkTimYByK3wbbT6Rv0HDYdPuxrhzZafQ@mail.gmail.com>
References: <4DB6EBD6.702@lugmen.org.ar>
	<BANLkTimYByK3wbbT6Rv0HDYdPuxrhzZafQ@mail.gmail.com>
Message-ID: <20110426185711.GH31159@rorohiko>

* Nicole Engard (nengard at gmail.com) wrote:
> In the US, some libraries require that parents give their children
> permission to access the system this means that if the child doesn't
> have permission they shouldn't have a log in - so having all patrons
> require a log in would be an issue in this situation.
> 
I agree, millions of people around the world have no access to the
internet. Making librarians have to make them a login is an unnessecary
task. Also, although we would all like this to be untrue, but the vast
majority of library users never look at, let alone log into the OPAC.
I can imagine that making the login field unmandatory would be the first
thing a lot of libraries would ask for.

Having a login and password that is never used by the intended user,and
probably therefore never changed, means we make an easier attack vector.
For example if we know that pattern of the default login, all we have to do is
get the password, reducing the complexity of the attack a lot.

Chris
-- 
Chris Cormack
Catalyst IT Ltd.
+64 4 803 2238
PO Box 11-053, Manners St, Wellington 6142, New Zealand
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: </pipermail/koha-devel/attachments/20110427/f9e1839f/attachment.pgp>

From conan at lugmen.org.ar  Tue Apr 26 21:15:18 2011
From: conan at lugmen.org.ar (Fernando Canizo)
Date: Tue, 26 Apr 2011 16:15:18 -0300
Subject: [Koha-devel] Request for discussion: bugs 3674, 6220,
 6224 and 6218
In-Reply-To: <20110426185711.GH31159@rorohiko>
References: <4DB6EBD6.702@lugmen.org.ar>	<BANLkTimYByK3wbbT6Rv0HDYdPuxrhzZafQ@mail.gmail.com>
	<20110426185711.GH31159@rorohiko>
Message-ID: <4DB719C6.8010905@lugmen.org.ar>

On 26/04/11 15:57, Chris Cormack wrote:
> * Nicole Engard (nengard at gmail.com) wrote:
>> In the US, some libraries require that parents give their children
>> permission to access the system this means that if the child doesn't
>> have permission they shouldn't have a log in - so having all patrons
>> require a log in would be an issue in this situation.
>>
> I agree, millions of people around the world have no access to the
> internet. Making librarians have to make them a login is an unnessecary
> task. Also, although we would all like this to be untrue, but the vast
> majority of library users never look at, let alone log into the OPAC.
> I can imagine that making the login field unmandatory would be the first
> thing a lot of libraries would ask for.
>
> Having a login and password that is never used by the intended user,and
> probably therefore never changed, means we make an easier attack vector.
> For example if we know that pattern of the default login, all we have to do is
> get the password, reducing the complexity of the attack a lot.

I'm new to koha (and to libraries from the point of view of a librarian) 
and I haven't noticed what was the intended use for that.

So far I'm fiddling with koha installations as superlibrarian and I 
thought everyone would be doing that or at least searching the catalog.

Now I understand why was the way it was and all my rambling is disposable.

-- 
Fernando Canizo (a.k.a. conan) - http://conan.muriandre.com/
GCS d? s:+ a C++ P--- L++++ E--- W+++ w--- M-- PE-- !tv b+++ h---- y+++

From tajoli at cilea.it  Wed Apr 27 10:38:49 2011
From: tajoli at cilea.it (tajoli)
Date: Wed, 27 Apr 2011 10:38:49 +0200
Subject: [Koha-devel] DB Documentation
In-Reply-To: <BANLkTi=-j9S4uo9kQeinXQQbQK39JOXojw@mail.gmail.com>
References: <BANLkTi=-j9S4uo9kQeinXQQbQK39JOXojw@mail.gmail.com>
Message-ID: <9e945072c82c4f1e78b6cb76ee7766c2@cilea.it>

Hi Nicole,

> I see that no one volunteered to do the DB Documentation for Koha 3.6
> and I'm willing to take this on under the Documentation Manager role.
> I just wanted to ask for a refresher on what we decided was the way we
> were going to manage this project.  There is the 'COMMENT' option in
> MySQL or we can just use the '--' notation after every field.  Once I
> know what we want to use I can start documenting the database to the
> best of my ability so that it will make reporting easier on people new
> to Koha and Koha language (borrowers instead of patrons, reserves
> instead of holds, etc etc).

in fact I try to do this role in last months but I don't do a good work.
The place to start is http://wiki.koha-community.org/wiki/DB_Schema

In the file
http://www.koha.it/local--files/working/koha303_schema_and_howto_upload.zip
you can see the work done for 3.0.3 and instructions.

The tool that I  used was SchemaSpy.

My idea was to insert to use the COMMENT option in MYSQL, but the patch
doesn't go into the master.
We need to rewrite it if we want it into the code.

I have same basic files for MySQL Workbench if you prefer this tool.
But I can send them to you (and post in the wiki) only after 2 May 2011.


Bye
Zeno Tajoli


From BShiundu at strathmore.edu  Wed Apr 27 16:30:05 2011
From: BShiundu at strathmore.edu (Bernard Shiundu)
Date: Wed, 27 Apr 2011 14:30:05 +0000
Subject: [Koha-devel] Label Batch Management Broken?
Message-ID: <D2EAB0C4E700FD4796869AA9677B5B2F2EB2B1B6@Thika.strathmore.local>

Hi all,

Just giving 3.4 a spin on a clean install and find that "Manage Batches" does not pick the branch details and therefore breaks. "Manage Templates" et al correctly register the branch and work fine in my cursory test.

Anyone else seen this before I raise a bug report?

Bernard Shiundu
Strathmore University Library
Nairobi, Kenya

________________________________

Strathmore University provides all-round education in an atmosphere of freedom and responsibility.
This email and any files transmitted with it are intended solely for use by the recipient(s) to whom it is addressed and may contain confidential information. If you have received this email in error please notify the sender immediately and permanently delete this email and/or any files attached to it from your computer. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Strathmore University. The University accepts no liability whatsoever for any loss or damages incurred, or suffered, resulting, or arising, from the use of this email and/or its attachments. The University warrants neither the integrity of the e-mail nor its freedom from errors, viruses, interception or any other form of interference.
............................................................................
Website: www.strathmore.edu



From M.de.Rooy at rijksmuseum.nl  Thu Apr 28 14:36:31 2011
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Thu, 28 Apr 2011 12:36:31 +0000
Subject: [Koha-devel] Translation bug 6278 (XSLT subfield select pars)
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA3124A7B4@S-MAIL-1B.rijksmuseum.intra>
References: <809BE39CD64BFD4EB9036172EBCCFA3124A7B4@S-MAIL-1B.rijksmuseum.intra>
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3124A7E3@S-MAIL-1B.rijksmuseum.intra>

Could not reach the translate list, but this may be interesting for dev too:



If your translation file translates the English word "at", please check your XSLT files for >at<. See problem below.





English XSLT contains constructs as:
<xsl:call-template name="subfieldSelect">
<xsl:with-param name="codes">at</xsl:with-param>
</xsl:call-template>



The translated Dutch XSLT contains:
<xsl:call-template name="subfieldSelect">
<xsl:with-param name="codes">bij</xsl:with-param>
</xsl:call-template>



Since at is not a word here, but just two subfields a and t, they should not have been translated of course. Incidentally, bij is the Dutch translation of the English at. The word gets translated and so subfields a and t are replaced by b, i and j. In most cases resulting in no information.

Note: Occurs 5 times in MARC21slim2OPACDetail.xsl. And affects display of fields 490/8XX, 773, 780/785.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110428/b638e40b/attachment.htm>

From cnighswonger at foundations.edu  Thu Apr 28 15:12:20 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Thu, 28 Apr 2011 09:12:20 -0400
Subject: [Koha-devel] Translation bug 6278 (XSLT subfield select pars)
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA3124A7E3@S-MAIL-1B.rijksmuseum.intra>
References: <809BE39CD64BFD4EB9036172EBCCFA3124A7B4@S-MAIL-1B.rijksmuseum.intra>
	<809BE39CD64BFD4EB9036172EBCCFA3124A7E3@S-MAIL-1B.rijksmuseum.intra>
Message-ID: <BANLkTimK-2cY08HgxhU3VeYyr-4qVSYtOQ@mail.gmail.com>

2011/4/28 Marcel de Rooy <M.de.Rooy at rijksmuseum.nl>

>  <xsl:call-template name="subfieldSelect">
> <xsl:with-param name="codes">at</xsl:with-param>
>

I wonder if the translation script could be modified to match this as an
exception and not translate it?

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

From f.demians at tamil.fr  Thu Apr 28 19:28:12 2011
From: f.demians at tamil.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_DEMIANS?=)
Date: Thu, 28 Apr 2011 19:28:12 +0200
Subject: [Koha-devel] Translation bug 6278 (XSLT subfield select pars)
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA3124A7E3@S-MAIL-1B.rijksmuseum.intra>
References: <809BE39CD64BFD4EB9036172EBCCFA3124A7B4@S-MAIL-1B.rijksmuseum.intra>
	<809BE39CD64BFD4EB9036172EBCCFA3124A7E3@S-MAIL-1B.rijksmuseum.intra>
Message-ID: <4DB9A3AC.2010703@tamil.fr>

 > Since at is not a word here, but just two subfields a and t, they
 > should not have been translated of course. Incidentally, bij is the
 > Dutch translation of the English at. The word gets translated and so
 > subfields a and t are replaced by b, i and j. In most cases resulting
 > in no information.

That's why the context (the comment for translator) is so important. A
translator, knowing that 'at' comes from a .xsl file should suspect that
it isn't a isolate word but a parameter, and taking a look at the XSL
file he could see that the text comes from a XSLT template parameter.

I agree that at the first place, there is something wrong in our XSL
file strings extractor. There are also shortcomings in the other file
types strings extractors. The .po files are huge for some of those
reasons. We can discuss how to improve Koha localization/translation
process. The goal could be to: simplify translators work, improve string
extraction, improve Koha 'localizability', reduce .po files size.

For XSL files, we could (1) explicitly mark text to be translated or
(2) pick them up from an external XML file (performance warning).

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


From magnus at enger.priv.no  Fri Apr 29 15:09:33 2011
From: magnus at enger.priv.no (Magnus Enger)
Date: Fri, 29 Apr 2011 15:09:33 +0200
Subject: [Koha-devel] Why is Dewey in the su index?
Message-ID: <BANLkTik1Wf3KYPg7yoEgKn5ysAf3V=t=kQ@mail.gmail.com>

Hi, all!

I just had a library ask me about how they could best search for a
specific Dewey number (and not as part of a call number, but on it's
own). After a bit of head-scratching I discovered that searching for
the Dewey-number as a subject gave good results (e.g.
/cgi-bin/koha/catalogue/search.pl?idx=su&q=355&op=and&idx=kw&op=and&idx=kw&sort_by=relevance).
Now the trouble is I was unable to leave well enough alone, and
started trying to figure out why Dewey is included in the su index.
And I'm still scratching my head...

Normally I would expect to find the answer in one of the following
files, but this seems like a dead end:

etc/zebradb/marc_defs/normarc/biblios/record.abs
melm 082        Dewey-classification:w,Dewey-classification:s

etc/zebradb/biblios/etc/bib1.att
att 13    Dewey-classification

etc/zebradb/ccl.properties
#Classification-Dewey   13  A classification number from    082
#                           the Dewey Decimal
#                           Classification, developed by
#                           Melvyl Dewey.
#Dewey-classification 1=13


I have tried also tried grep'ing throught the source for
Dewey-classification, with meager results (the mention in Search.pm is
just in a list of "available indexes"):

C4/Search.pm:                    'Dewey-classification',
etc/zebradb/biblios/etc/bib1.att:att 13    Dewey-classification
etc/zebradb/ccl.properties:#Dewey-classification 1=13
etc/zebradb/marc_defs/unimarc/biblios/record.abs:melm
676$a		Dewey-classification:w,Dewey-classification:s
etc/zebradb/marc_defs/normarc/biblios/record.abs:melm 082
Dewey-classification:w,Dewey-classification:s
etc/zebradb/marc_defs/marc21/biblios/record.abs:melm 082
Dewey-classification:w,Dewey-classification:s
koha-tmpl/opac-tmpl/prog/en/modules/opac-browser.tt:
 <a href="opac-search.pl?q=Dewey-classification:[%
LEVEL_LOO.classification |uri %]">[% LEVEL_LOO.description |html
%]</a>
koha-tmpl/opac-tmpl/prog/nb-NO/modules/opac-browser.tt: <a
href="opac-search.pl?q=Dewey-classification:[%
LEVEL_LOO.classification |uri %]">[% LEVEL_LOO.description |html
%]</a>

If anyone could shed some light on why Dewey-numbers are available in
the su index I would be eternally grateful!

Best regards,
Magnus Enger
libriotech.no

From gmcharlt at gmail.com  Fri Apr 29 16:48:24 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Fri, 29 Apr 2011 10:48:24 -0400
Subject: [Koha-devel] Why is Dewey in the su index?
In-Reply-To: <BANLkTik1Wf3KYPg7yoEgKn5ysAf3V=t=kQ@mail.gmail.com>
References: <BANLkTik1Wf3KYPg7yoEgKn5ysAf3V=t=kQ@mail.gmail.com>
Message-ID: <BANLkTikxe6EL2oeHBYfpF4zs76H9ASqFBA@mail.gmail.com>

Hi,

On Fri, Apr 29, 2011 at 9:09 AM, Magnus Enger <magnus at enger.priv.no> wrote:
> If anyone could shed some light on why Dewey-numbers are available in
> the su index I would be eternally grateful!

Try looking at it the other way around.  Here are the MARC fields that
are mapped to the Subject index:

melm 600$a      Name-and-title,Name,Personal-name,Subject-name-personal,Subject
melm 600$t      Name-and-title,Title,Subject
melm 600        Name,Personal-name,Subject-name-personal,Subject,Subject:p
melm 610        Name,Subject,Subject:p,Corporate-name
melm 611        Conference-name,Name,Subject,Subject:p
melm 630        Subject,Subject:p
melm 650        Subject,Subject:p
melm 651        Name-geographic,Subject,Subject:p
melm 653        Subject,Subject:p
melm 654        Subject,Subject:p
melm 655        Subject,Subject:p
melm 656        Subject,Subject:p
melm 657        Subject,Subject:p
melm 690        Subject,Subject:p

What's in one of the records that are being retrieved?  Do any of the
subject field (e.g., the 690) contain a copy of the Dewey number?  Or
alternatively, do any of the authorized subject headings contain a $9
with "355" in the link to the authority record?

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From magnus at enger.priv.no  Fri Apr 29 19:05:28 2011
From: magnus at enger.priv.no (Magnus Enger)
Date: Fri, 29 Apr 2011 19:05:28 +0200
Subject: [Koha-devel] Why is Dewey in the su index?
In-Reply-To: <BANLkTikxe6EL2oeHBYfpF4zs76H9ASqFBA@mail.gmail.com>
References: <BANLkTik1Wf3KYPg7yoEgKn5ysAf3V=t=kQ@mail.gmail.com>
	<BANLkTikxe6EL2oeHBYfpF4zs76H9ASqFBA@mail.gmail.com>
Message-ID: <BANLkTi=z6uxyM8A9qOXN4bo+hKMTff02+Q@mail.gmail.com>

On 29 April 2011 16:48, Galen Charlton <gmcharlt at gmail.com> wrote:
> What's in one of the records that are being retrieved? ?Do any of the
> subject field (e.g., the 690) contain a copy of the Dewey number?

That's exactly it! The records that were returned when searching for
the Dewey-number had them in the 600 fields. Thanks for changing my
perspective and saving me from a sleepless night!

And of course uncommenting
#Dewey-classification 1=13
in etc/zebradb/ccl.properties made it possible to use that as an index.

> Or
> alternatively, do any of the authorized subject headings contain a $9
> with "355" in the link to the authority record?

No authorities involved!

Best regards,
Magnus Enger
libriotech.no