From paul.poulain at biblibre.com  Mon Jan  2 17:55:29 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Mon, 02 Jan 2012 17:55:29 +0100
Subject: [Koha-devel] sample databases for sandboxes
Message-ID: <4F01E181.4020109@biblibre.com>

Hello,

In my RM application, I spoke of sandboxes that could be used for
non-techies to test and signoff patches.
I've started to work on this system, something should be visible this month.
The system will work that way:
* you reach a dedicated page
* on this page, you enter 3 things (maybe some more to come) :
  - the bugzilla patch number you want to test
  - your email-address (to have a mail once your sandbox is set)
  - the database you want to setup, from a list of available sample
databases
* you hit the "OK" button
* a few minuts later, you get a mail in your mailbox saying it's done
* you connect to the sandbox, and, on the main page, you see if
everything went well and you can work on this sandbox.

QUESTION/REQUEST: if you have a sample database you'd like to see in the
list, just send it to me by email, with some details about the content
of this example database, that will be seen by ppl that want to test
patches.
For example : "this database has 1000 records, 100 patrons, with
IndependantBranches=ON, and holds are not enabled anywhere. login with
test/test to be superlibrarian from library A, and libB/libB to be a
non-superlibrarian from library B"

FAQ about this system:

Q: how will we manage concurrency ?
A: there won't be any automatic checking. But the timestamp of the
creation of every sandbox will be visible on mainpage. So if the sandbox
is very young, use another one ! If you've any doubt, go

Q: what if something went wrong when applying the patch ?
A: just add a comment on bugzilla to say "tried to test this patch with
sandbox system, it does not work, you get the following message:
<copy here the message you saw on mainpage>>". It will mean this patch
must be tested by a developer with larger skills than this basic sandbox
system has.

Q: I want to setup my own sandboxes, how can I do that ?
A: go to http://git.biblibre.com, and you'll see a project here with all
the code (ie: still to be done)

Q: I've tested the patch, and everything went well, what's next ?
A: just go to bugzilla, change the status to "signed-off" and add a
comment to say "i've tested, works well, signed-off". The RM or the QA
team will take care of officially adding your signature to the patch.

Q: how long will last a given sandbox setup ?
A: Every night, everything will be reseted, Koha will be updated against
an uptodate master.

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

From henridamien.laurent at biblibre.com  Wed Jan  4 10:30:11 2012
From: henridamien.laurent at biblibre.com (Henri-Damien LAURENT)
Date: Wed, 04 Jan 2012 10:30:11 +0100
Subject: [Koha-devel] TEST sending email and email administration
Message-ID: <1325669411.20694.9.camel@hdlaurent-laptop>

my little message
-- 
Henri-Damien LAURENT
BibLibre


From paul.poulain at biblibre.com  Wed Jan  4 18:15:15 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 04 Jan 2012 18:15:15 +0100
Subject: [Koha-devel] work on the database (call for wiki discussion)
Message-ID: <4F048923.6030906@biblibre.com>

Hello,

Jonathan & me took 3 hours working on database design. We've created a
wiki page with all the mistakes we've found. The page is
http://wiki.koha-community.org/wiki/DB_schema_bugs
you're welcomed to read it, add anything that could have been forgotten,
or discuss what must be discussed.

There are 2 kinds of entries in this page:
* italic lines => we've found the problem, we don't have a solution,
feel free to add your voice to the discussion tab of the wiki
(http://wiki.koha-community.org/wiki/Talk:DB_schema_bugs, I already have
filled it to ease the talk)
* non italic lines => unless we made a mistake, those don't need to de
discussed, they are obvious mistakes we will fix ASAP (which does not
mean soon ;-) )

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

From M.de.Rooy at rijksmuseum.nl  Thu Jan  5 09:07:57 2012
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Thu, 5 Jan 2012 08:07:57 +0000
Subject: [Koha-devel] work on the database (call for wiki discussion)
In-Reply-To: <4F048923.6030906@biblibre.com>
References: <4F048923.6030906@biblibre.com>
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA313A4F17@S-MAIL-1B.rijksmuseum.intra>

Good work. Added two small remarks for a start..

> -----Oorspronkelijk bericht-----
> Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-
> bounces at lists.koha-community.org] Namens Paul Poulain
> Verzonden: woensdag 4 januari 2012 18:15
> Aan: koha-devel at lists.koha-community.org
> Onderwerp: [Koha-devel] work on the database (call for wiki discussion)
> 
> Hello,
> 
> Jonathan & me took 3 hours working on database design. We've created a
> wiki page with all the mistakes we've found. The page is
> http://wiki.koha-community.org/wiki/DB_schema_bugs
> you're welcomed to read it, add anything that could have been forgotten,
> or discuss what must be discussed.
> 
> There are 2 kinds of entries in this page:
> * italic lines => we've found the problem, we don't have a solution,
> feel free to add your voice to the discussion tab of the wiki
> (http://wiki.koha-community.org/wiki/Talk:DB_schema_bugs, I already have
> filled it to ease the talk)
> * non italic lines => unless we made a mistake, those don't need to de
> discussed, they are obvious mistakes we will fix ASAP (which does not
> mean soon ;-) )
> 
> Enter the game !
> --
> Paul POULAIN
> http://www.biblibre.com
> Expert en Logiciels Libres pour l'info-doc
> Tel : (33) 4 91 81 35 08
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/

From colin.campbell at ptfs-europe.com  Thu Jan  5 11:14:43 2012
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Thu, 5 Jan 2012 10:14:43 +0000
Subject: [Koha-devel] work on the database (call for wiki discussion)
In-Reply-To: <4F048923.6030906@biblibre.com>
References: <4F048923.6030906@biblibre.com>
Message-ID: <20120105101443.GA3398@zazou.config>

On Wed, Jan 04, 2012 at 06:15:15PM +0100, Paul Poulain wrote:
> There are 2 kinds of entries in this page:
> * italic lines => we've found the problem, we don't have a solution,
> feel free to add your voice to the discussion tab of the wiki
> (http://wiki.koha-community.org/wiki/Talk:DB_schema_bugs, I already have
> filled it to ease the talk)

For a propject I generated a dbic schema. It generated a handful of
warnings which I've appended to the talk list.

Colin

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

http://www.ptfs-europe.com

From M.de.Rooy at rijksmuseum.nl  Thu Jan  5 13:29:39 2012
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Thu, 5 Jan 2012 12:29:39 +0000
Subject: [Koha-devel] Cleaning up some files
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA313A5118@S-MAIL-1B.rijksmuseum.intra>

Paul,
If the tests in t/db_dependent/lib and its subdir KohaTest are not working and should not be used anymore, could you please remove them from master?
The files in t/data/db_schemas could be moved to docs/db_schemas, or deleted too. They just show the koha structure on some moments in time.

Thanks,
Marcel

Van: Chris Cormack [mailto:chris at bigballofwax.co.nz]
Verzonden: donderdag 22 december 2011 11:16
Aan: Marcel de Rooy
CC: koha-devel at lists.koha-community.org
Onderwerp: RE: [Koha-devel] Error on test in KohaTest


They shouldn't be anymore, they dont work. Use the .t ones

Chris
On 22 Dec 2011 20:47, "Marcel de Rooy" <M.de.Rooy at rijksmuseum.nl<mailto:M.de.Rooy at rijksmuseum.nl>> wrote:
Thanks, but how should they be run then?

> -----Oorspronkelijk bericht-----
> Van: Chris Cormack [mailto:chris at bigballofwax.co.nz<mailto:chris at bigballofwax.co.nz>]
> Verzonden: donderdag 22 december 2011 02:27
> Aan: Marcel de Rooy
> CC: koha-devel at lists.koha-community.org<mailto:koha-devel at lists.koha-community.org>
> Onderwerp: Re: [Koha-devel] Error on test in KohaTest
>
> 2011/12/20 Marcel de Rooy <M.de.Rooy at rijksmuseum.nl<mailto:M.de.Rooy at rijksmuseum.nl>>:
> > Hi,
> >
> >
> >
> > What am I doing wrong here?
> >
> >
> >
> > [marcel at RKM004 testclone]$ perl
> > t/db_dependent/lib/KohaTest/AuthoritiesMarc.pm
> >
> > Invalid CODE attribute: Test( 1 ) at
> > t/db_dependent/lib/KohaTest/AuthoritiesMarc.pm line 39
> >
> > BEGIN failed--compilation aborted at
> > t/db_dependent/lib/KohaTest/AuthoritiesMarc.pm line 39.
> >
> >
> >
> > [marcel at RKM004 testclone]$ perl t/db_dependent/lib/KohaTest/Search.pm
> >
> > Invalid CODE attribute: Test( 1 ) at t/db_dependent/lib/KohaTest/Search.pm
> > line 35
> >
> > BEGIN failed--compilation aborted at t/db_dependent/lib/KohaTest/Search.pm
> > line 35.
> >
> >
> >
> The tests in that dir are not designed to be run that way, in fact we
> should probably just remove them.
>
> The real tests for those files are
> t/db_dependent/Search.t
> and
> t/AuthoritiesMarc_MARC21.t
> t/AuthoritiesMarc.t
> t/AuthoritiesMarc_UNIMARC.t
>
> Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120105/8aba0c3a/attachment.htm>

From julian.maurice at biblibre.com  Thu Jan  5 16:39:10 2012
From: julian.maurice at biblibre.com (Julian Maurice)
Date: Thu, 05 Jan 2012 16:39:10 +0100
Subject: [Koha-devel] Anonymous OPAC Search History
Message-ID: <4F05C41E.8080002@biblibre.com>

Hello all,

I have a question about this commit (I didn't succeed to find the 
corresponding bug in Bugzilla)

commit feeafa8168965183ba8651cf3113c3c32af863ec
Author:     Henri-Damien LAURENT <henridamien.laurent at biblibre.com>
AuthorDate: Mon Aug 24 22:10:25 2009 +0200
Commit:     Henri-Damien LAURENT <henridamien.laurent at biblibre.com>
CommitDate: Wed Sep 30 11:22:21 2009 +0200

     Adding Opac-SearchHistory feature

     Enables ppl to store their search history and delete the whole history

     Adding Storable required by Opac-Search-History

     Signed-off-by: Galen Charlton <gmcharlt at gmail.com>


It adds the possibility for users to store their search queries. It's 
possible for both logged users and anonymous users.
More than that, if an anonymous user with a search history log in, the 
whole anonymous history is loaded and stored as the user search history.

Isn't there any privacy problems with this feature?
I mean, if user_1 do some search as an anonymous user, and then user_2 
go on the same computer and log in, the whole user_1 search history is 
saved into user_2 search history.

This behaviour has been reported as a bug by some BibLibre customers, 
that's why I ask.

-- 
Julian Maurice <julian.maurice at biblibre.com>
BibLibre

From paul.poulain at biblibre.com  Thu Jan  5 16:55:43 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 05 Jan 2012 16:55:43 +0100
Subject: [Koha-devel] Anonymous OPAC Search History
In-Reply-To: <4F05C41E.8080002@biblibre.com>
References: <4F05C41E.8080002@biblibre.com>
Message-ID: <4F05C7FF.1000208@biblibre.com>

Le 05/01/2012 16:39, Julian Maurice a ?crit :
> Hello all,

> This behaviour has been reported as a bug by some BibLibre customers,
> that's why I ask.
Just to add my voice:
this behaviour was explicitely requested by the BibLibre customer that
funded the feature. The idea behind it was: usually, users start
anonymous, then they find their query interesting, they want to "save"
it, so they say "sh.t, i'm not logged it".
With this behaviour, they just log in and it's OK.

I agree that the problem reported by Julian is a tricky one, because we
would loose this behaviour...

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

From paul.poulain at biblibre.com  Thu Jan  5 17:11:59 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 05 Jan 2012 17:11:59 +0100
Subject: [Koha-devel] work on the database (call for wiki discussion)
In-Reply-To: <20120105101443.GA3398@zazou.config>
References: <4F048923.6030906@biblibre.com>
	<20120105101443.GA3398@zazou.config>
Message-ID: <4F05CBCF.1070208@biblibre.com>

Le 05/01/2012 11:14, Colin Campbell a ?crit :
> On Wed, Jan 04, 2012 at 06:15:15PM +0100, Paul Poulain wrote:
>> There are 2 kinds of entries in this page:
>> * italic lines => we've found the problem, we don't have a solution,
>> feel free to add your voice to the discussion tab of the wiki
>> (http://wiki.koha-community.org/wiki/Talk:DB_schema_bugs, I already have
>> filled it to ease the talk)
> 
> For a propject I generated a dbic schema. It generated a handful of
> warnings which I've appended to the talk list.

I've updated the wiki to move your suggestion to the main page & marcel
comment to the talk page.

thx for the feedback, feel free to continue investigating !

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

From chrisc at catalyst.net.nz  Thu Jan  5 20:11:36 2012
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Fri, 6 Jan 2012 08:11:36 +1300
Subject: [Koha-devel] Anonymous OPAC Search History
In-Reply-To: <4F05C41E.8080002@biblibre.com>
References: <4F05C41E.8080002@biblibre.com>
Message-ID: <20120105191136.GK5534@rorohiko.wgtn.cat-it.co.nz>

* Julian Maurice (julian.maurice at biblibre.com) wrote:
> Hello all,
> 
> I have a question about this commit (I didn't succeed to find the
> corresponding bug in Bugzilla)
> 
> commit feeafa8168965183ba8651cf3113c3c32af863ec
> Author:     Henri-Damien LAURENT <henridamien.laurent at biblibre.com>
> AuthorDate: Mon Aug 24 22:10:25 2009 +0200
> Commit:     Henri-Damien LAURENT <henridamien.laurent at biblibre.com>
> CommitDate: Wed Sep 30 11:22:21 2009 +0200
> 
>     Adding Opac-SearchHistory feature
> 
>     Enables ppl to store their search history and delete the whole history
> 
>     Adding Storable required by Opac-Search-History
> 
>     Signed-off-by: Galen Charlton <gmcharlt at gmail.com>
> 
> 
> It adds the possibility for users to store their search queries.
> It's possible for both logged users and anonymous users.
> More than that, if an anonymous user with a search history log in,
> the whole anonymous history is loaded and stored as the user search
> history.
> 
> Isn't there any privacy problems with this feature?
> I mean, if user_1 do some search as an anonymous user, and then
> user_2 go on the same computer and log in, the whole user_1 search
> history is saved into user_2 search history.
> 
> This behaviour has been reported as a bug by some BibLibre
> customers, that's why I ask.
> 
I can see it as a bug, in that you get history that isnt yours.

But since there is no way to know who it was .. I don't think it is a
privacy issue. Unless you are standing behind someone watching them
search so know who it was before you anyway :-)

Chris

> -- 
> Julian Maurice <julian.maurice at biblibre.com>
> 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/

-- 
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/20120106/054ce18c/attachment.pgp>

From paul.poulain at biblibre.com  Fri Jan  6 10:22:22 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 06 Jan 2012 10:22:22 +0100
Subject: [Koha-devel] Database updates on master [IMPORTANT]
Message-ID: <4F06BD4E.7050007@biblibre.com>

Hello,

a very important information: After a long discussion with chris_c and
chris_n, it seems I made a mistake and have found a hidden problem.

* the hidden problem (that was hidden for me, and probably for most of
you. both chris where aware) :
in 3.4 and 3.6, when a patch with a updatedatabase was backported, it
was backported with another number. It means that when you upgrade from
3.2 to 3.4 then 3.6, you get some error message about duplicate key of
things like that. I've checked, those SQL errors are all harmless (and
chris already had checked in fact).

* my mistake: as I thought patches for 3.6 should have a 3.6 number and
patches for master (future 3.8) should have a 3.7 number, i've pushed 3
patches with an updatedatabase numbered 3.6.x That was a bad idea, and
I'll have to modify those updatedatabase, i'll do it now.
So, anyone running master should get a "free" updatedatabase in the next
hours. By free I mean the 3 DB revs that will be applied have already
been applied, that will just be a number change.
So, 1-take care, 2- don't worry.

Also note that this problem will be solved once the new database
mechanism will be pushed, as it will be non-linear, so the numbering
won't refer to a release number anymore.

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

From ian.walls at bywatersolutions.com  Fri Jan  6 15:37:23 2012
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Fri, 6 Jan 2012 09:37:23 -0500
Subject: [Koha-devel] Proposal to change Bugzilla Status and Patch Status
	values
Message-ID: <CAE2wdZw7vBgThw2E1DZhy0k28BEfd9r_JRrmOhsrVw9urPX4hg@mail.gmail.com>

Fellow Koha-ckers,


A comment on bug 7167 (
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7167) has gotten
my interest re-awakened about a proposed Bugzilla revision that had been
floated earlier this release cycle.

I'd like to remove Patch Status, and move all those values to the regular
Status field.  This has the following advantages:

   - Status is a built-in field, so it's got much richer support in
   Bugzilla.  For example, status workflows can be added.  Patch Status is a
   custom field, and is just a list of values
   - We would no longer lose the Priority value of a bug by having to set
   it to Patch Sent in order to get the Patch Status values visible
   - Statuses can be updated as part of submitting an attachment like a
   patch, streamlining the patch submission process (fewer clicks to keep all
   the fields up to date).

I'd also like to add a new status, "In Discussion", for bug reports that
have deeper procedural, philsophical or technical implications outside that
of mere coding (bug 7167 being an example).

We're not using Status for anything else, so there is no trade-off there.
This is really how the Status field is meant to be used.  We will, however,
have to rebuild the canned searches that look for patches that Need
Signoff, are Signed Off, and are Passed QA/Failed QA.

The other difficulty of this proposal is that we'll need to turn off
automatic bug emails for a bit while we make the bulk changes to the Patch
Statuses; otherwise, we'll all get spammed to high heaven with meaningless
updates when the migration occurs.

What do people think?  Does this sound like a reasonable change to make?
Any objections?

Cheers,


-Ian


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

From cnighswonger at foundations.edu  Fri Jan  6 15:40:58 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Fri, 6 Jan 2012 09:40:58 -0500
Subject: [Koha-devel] Proposal to change Bugzilla Status and Patch
	Status values
In-Reply-To: <CAE2wdZw7vBgThw2E1DZhy0k28BEfd9r_JRrmOhsrVw9urPX4hg@mail.gmail.com>
References: <CAE2wdZw7vBgThw2E1DZhy0k28BEfd9r_JRrmOhsrVw9urPX4hg@mail.gmail.com>
Message-ID: <CAP3yOomnxzEC7njJh7r1jZzxh9gTyOzgStFNd3ZOWQWaFJJ0Hg@mail.gmail.com>

+1 here.

2012/1/6 Ian Walls <ian.walls at bywatersolutions.com>:
> Fellow Koha-ckers,
>
>
> A comment on bug 7167
> (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7167) has gotten
> my interest re-awakened about a proposed Bugzilla revision that had been
> floated earlier this release cycle.
>
> I'd like to remove Patch Status, and move all those values to the regular
> Status field.? This has the following advantages:
>
> Status is a built-in field, so it's got much richer support in Bugzilla.
> For example, status workflows can be added.? Patch Status is a custom field,
> and is just a list of values
> We would no longer lose the Priority value of a bug by having to set it to
> Patch Sent in order to get the Patch Status values visible
> Statuses can be updated as part of submitting an attachment like a patch,
> streamlining the patch submission process (fewer clicks to keep all the
> fields up to date).
>
> I'd also like to add a new status, "In Discussion", for bug reports that
> have deeper procedural, philsophical or technical implications outside that
> of mere coding (bug 7167 being an example).
>
> We're not using Status for anything else, so there is no trade-off there.
> This is really how the Status field is meant to be used.? We will, however,
> have to rebuild the canned searches that look for patches that Need Signoff,
> are Signed Off, and are Passed QA/Failed QA.
>
> The other difficulty of this proposal is that we'll need to turn off
> automatic bug emails for a bit while we make the bulk changes to the Patch
> Statuses; otherwise, we'll all get spammed to high heaven with meaningless
> updates when the migration occurs.
>
> What do people think?? Does this sound like a reasonable change to make?
> Any objections?
>
> Cheers,
>
>
> -Ian
>
>
> -- Ian Walls
>
> Lead Development Specialist
> ByWater Solutions
> ALA Midwinter Booth #2048
> Phone # (888) 900-8944
> http://bywatersolutions.com
> ian.walls at bywatersolutions.com
> Twitter: @sekjal
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/

From nengard at gmail.com  Fri Jan  6 15:42:16 2012
From: nengard at gmail.com (Nicole Engard)
Date: Fri, 6 Jan 2012 09:42:16 -0500
Subject: [Koha-devel] Proposal to change Bugzilla Status and Patch
	Status values
In-Reply-To: <CAP3yOomnxzEC7njJh7r1jZzxh9gTyOzgStFNd3ZOWQWaFJJ0Hg@mail.gmail.com>
References: <CAE2wdZw7vBgThw2E1DZhy0k28BEfd9r_JRrmOhsrVw9urPX4hg@mail.gmail.com>
	<CAP3yOomnxzEC7njJh7r1jZzxh9gTyOzgStFNd3ZOWQWaFJJ0Hg@mail.gmail.com>
Message-ID: <CAC0K6VHXZEkMEL0xQUddd9ziUSE9hX3vKzry5ge7BOtFPhSq=g@mail.gmail.com>

+1

On Fri, Jan 6, 2012 at 9:40 AM, Chris Nighswonger <
cnighswonger at foundations.edu> wrote:

> +1 here.
>
> 2012/1/6 Ian Walls <ian.walls at bywatersolutions.com>:
> > Fellow Koha-ckers,
> >
> >
> > A comment on bug 7167
> > (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7167) has
> gotten
> > my interest re-awakened about a proposed Bugzilla revision that had been
> > floated earlier this release cycle.
> >
> > I'd like to remove Patch Status, and move all those values to the regular
> > Status field.  This has the following advantages:
> >
> > Status is a built-in field, so it's got much richer support in Bugzilla.
> > For example, status workflows can be added.  Patch Status is a custom
> field,
> > and is just a list of values
> > We would no longer lose the Priority value of a bug by having to set it
> to
> > Patch Sent in order to get the Patch Status values visible
> > Statuses can be updated as part of submitting an attachment like a patch,
> > streamlining the patch submission process (fewer clicks to keep all the
> > fields up to date).
> >
> > I'd also like to add a new status, "In Discussion", for bug reports that
> > have deeper procedural, philsophical or technical implications outside
> that
> > of mere coding (bug 7167 being an example).
> >
> > We're not using Status for anything else, so there is no trade-off there.
> > This is really how the Status field is meant to be used.  We will,
> however,
> > have to rebuild the canned searches that look for patches that Need
> Signoff,
> > are Signed Off, and are Passed QA/Failed QA.
> >
> > The other difficulty of this proposal is that we'll need to turn off
> > automatic bug emails for a bit while we make the bulk changes to the
> Patch
> > Statuses; otherwise, we'll all get spammed to high heaven with
> meaningless
> > updates when the migration occurs.
> >
> > What do people think?  Does this sound like a reasonable change to make?
> > Any objections?
> >
> > Cheers,
> >
> >
> > -Ian
> >
> >
> > -- Ian Walls
> >
> > Lead Development Specialist
> > ByWater Solutions
> > ALA Midwinter Booth #2048
> > Phone # (888) 900-8944
> > http://bywatersolutions.com
> > ian.walls at bywatersolutions.com
> > Twitter: @sekjal
> >
> > _______________________________________________
> > Koha-devel mailing list
> > Koha-devel at lists.koha-community.org
> > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> > website : http://www.koha-community.org/
> > git : http://git.koha-community.org/
> > bugs : http://bugs.koha-community.org/
> _______________________________________________
> 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/20120106/1bfdc00b/attachment.htm>

From paul.poulain at biblibre.com  Fri Jan  6 15:45:51 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 06 Jan 2012 15:45:51 +0100
Subject: [Koha-devel] Proposal to change Bugzilla Status and Patch
 Status values
In-Reply-To: <CAE2wdZw7vBgThw2E1DZhy0k28BEfd9r_JRrmOhsrVw9urPX4hg@mail.gmail.com>
References: <CAE2wdZw7vBgThw2E1DZhy0k28BEfd9r_JRrmOhsrVw9urPX4hg@mail.gmail.com>
Message-ID: <4F07091F.1000204@biblibre.com>

Le 06/01/2012 15:37, Ian Walls a ?crit :
> Fellow Koha-ckers,
> I'd like to remove Patch Status, and move all those values to the
> regular Status field.  This has the following advantages:
> 
>   * Status is a built-in field, so it's got much richer support in
>     Bugzilla.  For example, status workflows can be added.  Patch Status
>     is a custom field, and is just a list of values
>   * We would no longer lose the Priority value of a bug by having to set
>     it to Patch Sent in order to get the Patch Status values visible
>   * Statuses can be updated as part of submitting an attachment like a
>     patch, streamlining the patch submission process (fewer clicks to
>     keep all the fields up to date).
+1000, that's a change I really want to have !

> I'd also like to add a new status, "In Discussion", for bug reports that
> have deeper procedural, philsophical or technical implications outside
> that of mere coding (bug 7167 being an example).

> We're not using Status for anything else, so there is no trade-off
> there.  This is really how the Status field is meant to be used.  We
> will, however, have to rebuild the canned searches that look for patches
> that Need Signoff, are Signed Off, and are Passed QA/Failed QA.
rewriting the canned searches is not a big deal ! and the positive thing
is so great !
> 
> The other difficulty of this proposal is that we'll need to turn off
> automatic bug emails for a bit while we make the bulk changes to the
> Patch Statuses; otherwise, we'll all get spammed to high heaven with
> meaningless updates when the migration occurs.

easy : bugzilla > Administration > Parameters > Email >
mail_delivery_method set to none

not really a difficulty, we must just warn ppl !

> What do people think?  Does this sound like a reasonable change to
> make?  Any objections?
it's a desirable new year gift, definetly !

(another reason to do that = if you close a bug that has an needs
signoff because, for example, it's invalid, or a duplicate patch exists,
then it will still appear in the needs signoff list, because the patch
status has nothing to see with the bug status. That's weird)

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

From gmc at esilibrary.com  Fri Jan  6 15:51:08 2012
From: gmc at esilibrary.com (Galen Charlton)
Date: Fri, 06 Jan 2012 09:51:08 -0500
Subject: [Koha-devel] Proposal to change Bugzilla Status and Patch
 Status values
In-Reply-To: <CAE2wdZw7vBgThw2E1DZhy0k28BEfd9r_JRrmOhsrVw9urPX4hg@mail.gmail.com>
References: <CAE2wdZw7vBgThw2E1DZhy0k28BEfd9r_JRrmOhsrVw9urPX4hg@mail.gmail.com>
Message-ID: <4F070A5C.5000306@esilibrary.com>

+1 --gmc

On 01/06/2012 09:37 AM, Ian Walls wrote:
> Fellow Koha-ckers,
>
>
> A comment on bug 7167
> (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7167) has
> gotten my interest re-awakened about a proposed Bugzilla revision that
> had been floated earlier this release cycle.
>
> I'd like to remove Patch Status, and move all those values to the
> regular Status field.  This has the following advantages:
>
>     * Status is a built-in field, so it's got much richer support in
>       Bugzilla.  For example, status workflows can be added.  Patch
>       Status is a custom field, and is just a list of values
>     * We would no longer lose the Priority value of a bug by having to
>       set it to Patch Sent in order to get the Patch Status values visible
>     * Statuses can be updated as part of submitting an attachment like a
>       patch, streamlining the patch submission process (fewer clicks to
>       keep all the fields up to date).
>
> I'd also like to add a new status, "In Discussion", for bug reports that
> have deeper procedural, philsophical or technical implications outside
> that of mere coding (bug 7167 being an example).
>
> We're not using Status for anything else, so there is no trade-off
> there.  This is really how the Status field is meant to be used.  We
> will, however, have to rebuild the canned searches that look for patches
> that Need Signoff, are Signed Off, and are Passed QA/Failed QA.
>
> The other difficulty of this proposal is that we'll need to turn off
> automatic bug emails for a bit while we make the bulk changes to the
> Patch Statuses; otherwise, we'll all get spammed to high heaven with
> meaningless updates when the migration occurs.
>
> What do people think?  Does this sound like a reasonable change to
> make?  Any objections?
>
> Cheers,
>
>
> -Ian
>
>
> -- Ian Walls
>
> Lead Development Specialist
> ByWater Solutions
> ALA Midwinter Booth #2048
> Phone # (888) 900-8944 <tel:%28888%29%20900-8944>
> http://bywatersolutions.com
> ian.walls at bywatersolutions.com <mailto:ian.walls at bywatersolutions.com>
> Twitter: @sekjal
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/


-- 
Galen Charlton
Director of Support and Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org & 
http://evergreen-ils.org

From magnus at enger.priv.no  Fri Jan  6 16:01:16 2012
From: magnus at enger.priv.no (Magnus Enger)
Date: Fri, 6 Jan 2012 16:01:16 +0100
Subject: [Koha-devel] Proposal to change Bugzilla Status and Patch
	Status values
In-Reply-To: <CAE2wdZw7vBgThw2E1DZhy0k28BEfd9r_JRrmOhsrVw9urPX4hg@mail.gmail.com>
References: <CAE2wdZw7vBgThw2E1DZhy0k28BEfd9r_JRrmOhsrVw9urPX4hg@mail.gmail.com>
Message-ID: <CABg6UYFnUFKjfwq=SdBY7DDa9WF4cszaCbJuiCi2V4z9qWQ8Hw@mail.gmail.com>

2012/1/6 Ian Walls <ian.walls at bywatersolutions.com>:
> What do people think?? Does this sound like a reasonable change to make?

+1

From oleonard at myacpl.org  Fri Jan  6 17:00:01 2012
From: oleonard at myacpl.org (Owen Leonard)
Date: Fri, 6 Jan 2012 11:00:01 -0500
Subject: [Koha-devel] Proposal to change Bugzilla Status and Patch
	Status values
In-Reply-To: <CAE2wdZw7vBgThw2E1DZhy0k28BEfd9r_JRrmOhsrVw9urPX4hg@mail.gmail.com>
References: <CAE2wdZw7vBgThw2E1DZhy0k28BEfd9r_JRrmOhsrVw9urPX4hg@mail.gmail.com>
Message-ID: <CAO4qe2Nyerrfzjdvf0ZF+wB_=OCcPobbYothZqtnh9OH_XyX=Q@mail.gmail.com>

> What do people think?? Does this sound like a reasonable change to make?

+1

  -- Owen

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

From julian.maurice at biblibre.com  Fri Jan  6 17:11:58 2012
From: julian.maurice at biblibre.com (Julian Maurice)
Date: Fri, 06 Jan 2012 17:11:58 +0100
Subject: [Koha-devel] Proposal to change Bugzilla Status and Patch
 Status values
In-Reply-To: <CAE2wdZw7vBgThw2E1DZhy0k28BEfd9r_JRrmOhsrVw9urPX4hg@mail.gmail.com>
References: <CAE2wdZw7vBgThw2E1DZhy0k28BEfd9r_JRrmOhsrVw9urPX4hg@mail.gmail.com>
Message-ID: <4F071D4E.2080102@biblibre.com>

Le 06/01/2012 15:37, Ian Walls a ?crit :

> What do people think?  Does this sound like a reasonable change to
> make?  Any objections?

+1

-- 
Julian Maurice <julian.maurice at biblibre.com>
BibLibre

From Katrin.Fischer at bsz-bw.de  Fri Jan  6 17:23:41 2012
From: Katrin.Fischer at bsz-bw.de (Fischer, Katrin)
Date: Fri, 6 Jan 2012 17:23:41 +0100
Subject: [Koha-devel] Proposal to change Bugzilla Status and PatchStatus
	values
References: <CAE2wdZw7vBgThw2E1DZhy0k28BEfd9r_JRrmOhsrVw9urPX4hg@mail.gmail.com>
	<CAO4qe2Nyerrfzjdvf0ZF+wB_=OCcPobbYothZqtnh9OH_XyX=Q@mail.gmail.com>
Message-ID: <028B1A54D03E7B4482CDCA4EC8F06BFD016265E7@Bodensee.bsz-bw.de>

> What do people think?  Does this sound like a reasonable change to make?

+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120106/b94f762f/attachment.htm>

From ian.walls at bywatersolutions.com  Fri Jan  6 17:48:43 2012
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Fri, 6 Jan 2012 11:48:43 -0500
Subject: [Koha-devel] Proposal to change Bugzilla Status and PatchStatus
	values
In-Reply-To: <028B1A54D03E7B4482CDCA4EC8F06BFD016265E7@Bodensee.bsz-bw.de>
References: <CAE2wdZw7vBgThw2E1DZhy0k28BEfd9r_JRrmOhsrVw9urPX4hg@mail.gmail.com>
	<CAO4qe2Nyerrfzjdvf0ZF+wB_=OCcPobbYothZqtnh9OH_XyX=Q@mail.gmail.com>
	<028B1A54D03E7B4482CDCA4EC8F06BFD016265E7@Bodensee.bsz-bw.de>
Message-ID: <CAE2wdZz-wYWMgnvVn22C3WSEAXYfhrKmNPy6gJ=XMJDWAdqMmw@mail.gmail.com>

Given the immediate and positive response to this proposal, I've gone ahead
and started implementing it.  I've created the new Status fields, but
they're currently invisible.  Once they're placed into the Workflow,
they'll appear.

I'd like to schedule adding them to the workflow, modifying the canned
searches and bulk changing the existing bugs for some time in the next week
or two.  Does anyone have a preference on what day of the week or time of
day would have the least negative impact on our work?

Cheers,


-Ian

On Fri, Jan 6, 2012 at 11:23 AM, Fischer, Katrin
<Katrin.Fischer at bsz-bw.de>wrote:

> **
>
> > What do people think?  Does this sound like a reasonable change to make?
>
> +1
>



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

From paul.a at aandc.org  Fri Jan  6 20:46:58 2012
From: paul.a at aandc.org (Paul)
Date: Fri, 06 Jan 2012 14:46:58 -0500
Subject: [Koha-devel] link_bibs_to_authorities.pl can corrupt records
Message-ID: <5.2.1.1.2.20120106111952.00bea128@stormy.ca>

Bug 5683 (link_bibs_to_authorities.pl can corrupt records) was signed off 
some months ago, but is perhaps a little too cryptic for me to follow in 
detail.  Can someone help? As far as I can see, without remedial action, 
this is catastrophic.

Following difficulties we have had migrating 3.2 to 3.6.1, someone on the 
users mailing list suggested we should run link_bibs_to_authorities.pl -- 
(db has ~10k authorities and ~15k biblios) -- so I did just that, and have 
APPARENTLY DEMOLISHED *EVERY* LINK IN THE DB.  From my notes:

paul at nelson:/usr/share/koha$ ./bin/link_bibs_to_authorities.pl

Bib authority heading linking report
------------------------------------
Number of bibs checked:       14911
Number of bibs modified:      14886
Number of bibs with errors:   0

but - the staff interface no longer correctly finds authorities !!!

[1] Manually link (staff client) auth "Lubbock" to bib "Arctic Whalers" -- 
now linked, 35 other Lubbock bibs not linked.  Is this a question of zebra 
re-indexing?

So:  KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib 
./bin/migration_tools/rebuild_zebra.pl -a -r -v
and  KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib 
./bin/migration_tools/rebuild_zebra.pl -b -r -v -x

koha at nelson:/usr/share/koha$ ./bin/link_bibs_to_authorities.pl
... processed 100 records
/ ... /
... processed 14900 records

Bib authority heading linking report
------------------------------------
Number of bibs checked:       14911
Number of bibs modified:      1
Number of bibs with errors:   0
koha at nelson:/usr/share/koha$

All this did was to *un-link" the bib/auth link that I had manually entered 
at [1] above. Could someone involved with signing off bug 5683 please 
explain why link==unlink?

Help - please.

Paul


From chris at bigballofwax.co.nz  Fri Jan  6 20:57:52 2012
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Sat, 7 Jan 2012 08:57:52 +1300
Subject: [Koha-devel] link_bibs_to_authorities.pl can corrupt records
In-Reply-To: <5.2.1.1.2.20120106111952.00bea128@stormy.ca>
References: <5.2.1.1.2.20120106111952.00bea128@stormy.ca>
Message-ID: <CA+95qVSce+C4W8dQaO1SwQZ=+VeaaZitznMAo2g8eWqd8jDzKw@mail.gmail.com>

Im assuming you did this on your testing/staging server right?
Id restore that from backup, then try applying the patch and see if you get
better behaviour.

If so, then do it on your production machine.

Chris
On 7 Jan 2012 08:47, "Paul" <paul.a at aandc.org> wrote:

> Bug 5683 (link_bibs_to_authorities.pl can corrupt records) was signed off
> some months ago, but is perhaps a little too cryptic for me to follow in
> detail.  Can someone help? As far as I can see, without remedial action,
> this is catastrophic.
>
> Following difficulties we have had migrating 3.2 to 3.6.1, someone on the
> users mailing list suggested we should run link_bibs_to_authorities.pl --
> (db has ~10k authorities and ~15k biblios) -- so I did just that, and have
> APPARENTLY DEMOLISHED *EVERY* LINK IN THE DB.  From my notes:
>
> paul at nelson:/usr/share/koha$ ./bin/link_bibs_to_**authorities.pl<http://link_bibs_to_authorities.pl>
>
> Bib authority heading linking report
> ------------------------------**------
> Number of bibs checked:       14911
> Number of bibs modified:      14886
> Number of bibs with errors:   0
>
> but - the staff interface no longer correctly finds authorities !!!
>
> [1] Manually link (staff client) auth "Lubbock" to bib "Arctic Whalers" --
> now linked, 35 other Lubbock bibs not linked.  Is this a question of zebra
> re-indexing?
>
> So:  KOHA_CONF=/etc/koha/koha-conf.**xml PERL5LIB=/usr/share/koha/lib
> ./bin/migration_tools/rebuild_**zebra.pl <http://rebuild_zebra.pl> -a -r
> -v
> and  KOHA_CONF=/etc/koha/koha-conf.**xml PERL5LIB=/usr/share/koha/lib
> ./bin/migration_tools/rebuild_**zebra.pl <http://rebuild_zebra.pl> -b -r
> -v -x
>
> koha at nelson:/usr/share/koha$ ./bin/link_bibs_to_**authorities.pl<http://link_bibs_to_authorities.pl>
> ... processed 100 records
> / ... /
> ... processed 14900 records
>
> Bib authority heading linking report
> ------------------------------**------
> Number of bibs checked:       14911
> Number of bibs modified:      1
> Number of bibs with errors:   0
> koha at nelson:/usr/share/koha$
>
> All this did was to *un-link" the bib/auth link that I had manually
> entered at [1] above. Could someone involved with signing off bug 5683
> please explain why link==unlink?
>
> Help - please.
>
> Paul
>
> ______________________________**_________________
> Koha-devel mailing list
> Koha-devel at lists.koha-**community.org<Koha-devel at lists.koha-community.org>
> http://lists.koha-community.**org/cgi-bin/mailman/listinfo/**koha-devel<http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel>
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.**org/ <http://bugs.koha-community.org/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120107/2ed88cc6/attachment.htm>

From ian.walls at bywatersolutions.com  Fri Jan  6 21:02:00 2012
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Fri, 6 Jan 2012 15:02:00 -0500
Subject: [Koha-devel] link_bibs_to_authorities.pl can corrupt records
In-Reply-To: <CA+95qVSce+C4W8dQaO1SwQZ=+VeaaZitznMAo2g8eWqd8jDzKw@mail.gmail.com>
References: <5.2.1.1.2.20120106111952.00bea128@stormy.ca>
	<CA+95qVSce+C4W8dQaO1SwQZ=+VeaaZitznMAo2g8eWqd8jDzKw@mail.gmail.com>
Message-ID: <CAE2wdZynrJ_u=sjOoa-ou=xC7NjPgxvfWtuMjiXbsiDFNfaj2Q@mail.gmail.com>

Paul,


The link_bibs_to_authorities.pl script is hardcoded to ALWAYS erase manual
links.  I'm not sure what the reasoning is behind that.  But, every time
you run it, any link you've done manually that the script can't
automatically figure out will be removed.  Nature of the beast (for now, at
least).


-Ian

2012/1/6 Chris Cormack <chris at bigballofwax.co.nz>

> Im assuming you did this on your testing/staging server right?
> Id restore that from backup, then try applying the patch and see if you
> get better behaviour.
>
> If so, then do it on your production machine.
>
> Chris
> On 7 Jan 2012 08:47, "Paul" <paul.a at aandc.org> wrote:
>
>> Bug 5683 (link_bibs_to_authorities.pl can corrupt records) was signed
>> off some months ago, but is perhaps a little too cryptic for me to follow
>> in detail.  Can someone help? As far as I can see, without remedial action,
>> this is catastrophic.
>>
>> Following difficulties we have had migrating 3.2 to 3.6.1, someone on the
>> users mailing list suggested we should run link_bibs_to_authorities.pl-- (db has ~10k authorities and ~15k biblios) -- so I did just that, and
>> have APPARENTLY DEMOLISHED *EVERY* LINK IN THE DB.  From my notes:
>>
>> paul at nelson:/usr/share/koha$ ./bin/link_bibs_to_**authorities.pl<http://link_bibs_to_authorities.pl>
>>
>> Bib authority heading linking report
>> ------------------------------**------
>> Number of bibs checked:       14911
>> Number of bibs modified:      14886
>> Number of bibs with errors:   0
>>
>> but - the staff interface no longer correctly finds authorities !!!
>>
>> [1] Manually link (staff client) auth "Lubbock" to bib "Arctic Whalers"
>> -- now linked, 35 other Lubbock bibs not linked.  Is this a question of
>> zebra re-indexing?
>>
>> So:  KOHA_CONF=/etc/koha/koha-conf.**xml PERL5LIB=/usr/share/koha/lib
>> ./bin/migration_tools/rebuild_**zebra.pl <http://rebuild_zebra.pl> -a -r
>> -v
>> and  KOHA_CONF=/etc/koha/koha-conf.**xml PERL5LIB=/usr/share/koha/lib
>> ./bin/migration_tools/rebuild_**zebra.pl <http://rebuild_zebra.pl> -b -r
>> -v -x
>>
>> koha at nelson:/usr/share/koha$ ./bin/link_bibs_to_**authorities.pl<http://link_bibs_to_authorities.pl>
>> ... processed 100 records
>> / ... /
>> ... processed 14900 records
>>
>> Bib authority heading linking report
>> ------------------------------**------
>> Number of bibs checked:       14911
>> Number of bibs modified:      1
>> Number of bibs with errors:   0
>> koha at nelson:/usr/share/koha$
>>
>> All this did was to *un-link" the bib/auth link that I had manually
>> entered at [1] above. Could someone involved with signing off bug 5683
>> please explain why link==unlink?
>>
>> Help - please.
>>
>> Paul
>>
>> ______________________________**_________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-**community.org<Koha-devel at lists.koha-community.org>
>> http://lists.koha-community.**org/cgi-bin/mailman/listinfo/**koha-devel<http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel>
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.**org/<http://bugs.koha-community.org/>
>>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



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

From jcamins at cpbibliography.com  Fri Jan  6 21:24:40 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Fri, 6 Jan 2012 15:24:40 -0500
Subject: [Koha-devel] link_bibs_to_authorities.pl can corrupt records
In-Reply-To: <CAE2wdZynrJ_u=sjOoa-ou=xC7NjPgxvfWtuMjiXbsiDFNfaj2Q@mail.gmail.com>
References: <5.2.1.1.2.20120106111952.00bea128@stormy.ca>
	<CA+95qVSce+C4W8dQaO1SwQZ=+VeaaZitznMAo2g8eWqd8jDzKw@mail.gmail.com>
	<CAE2wdZynrJ_u=sjOoa-ou=xC7NjPgxvfWtuMjiXbsiDFNfaj2Q@mail.gmail.com>
Message-ID: <CALVDfQynvUstLrQzL8GBkt5zKEdmUwO7kLPykSj0POCp7Ff8GQ@mail.gmail.com>

Paul,

Bug 5683 is a different problem. It results in your records being
unrecoverably corrupted. You'd recognize the problem by the fact that after
running link_bibs_to_authorities.pl you wouldn't be able to look at some
records in your catalog. What you are encountering is the
apparently-intended behavior of link_bibs_to_authorities.pl, as Ian says. I
am currently working on bug 7284, which makes the linker actually work.
However, until that is finished and pushed, running
link_bibs_to_authorities.pl is most exceedingly not a good idea. If you're
running this on a dev install, just to experiment, you could pull in my
changes from https://github.com/jcamins/koha/commits/bug_7284

Regards,
Jared

2012/1/6 Ian Walls <ian.walls at bywatersolutions.com>

> Paul,
>
>
> The link_bibs_to_authorities.pl script is hardcoded to ALWAYS erase
> manual links.  I'm not sure what the reasoning is behind that.  But, every
> time you run it, any link you've done manually that the script can't
> automatically figure out will be removed.  Nature of the beast (for now, at
> least).
>
>
> -Ian
>
>
> 2012/1/6 Chris Cormack <chris at bigballofwax.co.nz>
>
>> Im assuming you did this on your testing/staging server right?
>> Id restore that from backup, then try applying the patch and see if you
>> get better behaviour.
>>
>> If so, then do it on your production machine.
>>
>> Chris
>> On 7 Jan 2012 08:47, "Paul" <paul.a at aandc.org> wrote:
>>
>>> Bug 5683 (link_bibs_to_authorities.pl can corrupt records) was signed
>>> off some months ago, but is perhaps a little too cryptic for me to follow
>>> in detail.  Can someone help? As far as I can see, without remedial action,
>>> this is catastrophic.
>>>
>>> Following difficulties we have had migrating 3.2 to 3.6.1, someone on
>>> the users mailing list suggested we should run
>>> link_bibs_to_authorities.pl -- (db has ~10k authorities and ~15k
>>> biblios) -- so I did just that, and have APPARENTLY DEMOLISHED *EVERY* LINK
>>> IN THE DB.  From my notes:
>>>
>>> paul at nelson:/usr/share/koha$ ./bin/link_bibs_to_**authorities.pl<http://link_bibs_to_authorities.pl>
>>>
>>> Bib authority heading linking report
>>> ------------------------------**------
>>> Number of bibs checked:       14911
>>> Number of bibs modified:      14886
>>> Number of bibs with errors:   0
>>>
>>> but - the staff interface no longer correctly finds authorities !!!
>>>
>>> [1] Manually link (staff client) auth "Lubbock" to bib "Arctic Whalers"
>>> -- now linked, 35 other Lubbock bibs not linked.  Is this a question of
>>> zebra re-indexing?
>>>
>>> So:  KOHA_CONF=/etc/koha/koha-conf.**xml PERL5LIB=/usr/share/koha/lib
>>> ./bin/migration_tools/rebuild_**zebra.pl <http://rebuild_zebra.pl> -a
>>> -r -v
>>> and  KOHA_CONF=/etc/koha/koha-conf.**xml PERL5LIB=/usr/share/koha/lib
>>> ./bin/migration_tools/rebuild_**zebra.pl <http://rebuild_zebra.pl> -b
>>> -r -v -x
>>>
>>> koha at nelson:/usr/share/koha$ ./bin/link_bibs_to_**authorities.pl<http://link_bibs_to_authorities.pl>
>>> ... processed 100 records
>>> / ... /
>>> ... processed 14900 records
>>>
>>> Bib authority heading linking report
>>> ------------------------------**------
>>> Number of bibs checked:       14911
>>> Number of bibs modified:      1
>>> Number of bibs with errors:   0
>>> koha at nelson:/usr/share/koha$
>>>
>>> All this did was to *un-link" the bib/auth link that I had manually
>>> entered at [1] above. Could someone involved with signing off bug 5683
>>> please explain why link==unlink?
>>>
>>> Help - please.
>>>
>>> Paul
>>>
>>> ______________________________**_________________
>>> Koha-devel mailing list
>>> Koha-devel at lists.koha-**community.org<Koha-devel at lists.koha-community.org>
>>> http://lists.koha-community.**org/cgi-bin/mailman/listinfo/**koha-devel<http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel>
>>> website : http://www.koha-community.org/
>>> git : http://git.koha-community.org/
>>> bugs : http://bugs.koha-community.**org/<http://bugs.koha-community.org/>
>>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>>
>
>
>
> --
> Ian Walls
> Lead Development Specialist
> ByWater Solutions
> ALA Midwinter Booth #2048
> Phone # (888) 900-8944
> http://bywatersolutions.com
> ian.walls at bywatersolutions.com
> Twitter: @sekjal
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



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

From chris at bigballofwax.co.nz  Fri Jan  6 21:57:15 2012
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Sat, 7 Jan 2012 09:57:15 +1300
Subject: [Koha-devel] link_bibs_to_authorities.pl can corrupt records
In-Reply-To: <5.2.1.1.2.20120106151732.00bea128@localhost>
References: <5.2.1.1.2.20120106111952.00bea128@stormy.ca>
	<CA+95qVSce+C4W8dQaO1SwQZ=+VeaaZitznMAo2g8eWqd8jDzKw@mail.gmail.com>
	<5.2.1.1.2.20120106151732.00bea128@localhost>
Message-ID: <CA+95qVQ5qOs7YLvQmYkucmCnK-0nC-yB1rxxyQdTyXLwm+7brg@mail.gmail.com>

I have successfully use that script to link authorities to biblio records
after doing a migration. But the way it works is to remove all links and
recreate.

Course I didn't do this on a server people were using, which it sounds like
you are, to have lost 100 biblios.

Its included for that use case. Jared is working on a much better linking
script and he gave you the information how to change it.

Its not a total screwup script, and it didn't demolish the whole db, I
think you would find people more willing to help you, in their own free
time, in their weekends if you didn't come across so aggressive and
accusatory in your tone.

Chris
On 7 Jan 2012 09:48, "Archives and Collections Society" <info at aandc.org>
wrote:

>  At 03:02 PM 1/6/2012 -0500, Ian Walls wrote:
>
> Paul,
> The link_bibs_to_authorities.pl script is hardcoded to ALWAYS erase
> manual links.?  I'm not sure what the reasoning is behind that.?  But,
> every time you run it, any link you've done manually that the script can't
> automatically figure out will be removed.?  Nature of the beast (for now,
> at least).
>
>
> What is "any link you've done manually"?, please.  More than 90% of our
> input is Z39.50 and "default" item cataloguing.
>
> OK - a total screw-up that is included without any warning whatsoever in
> the standard distribution of 3.6.1 ???  From the bug report <
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5683>
>
> Chris Cormack 2011-06-01 21:13:23 UTC
> Pushed to master
>
> Jared Camins-Esakov 2011-07-08 14:37:02 UTC
> Seems to be working now. Closing.
>
> If it's "nature of the beast" why isn't the "beast" mentioned somewhere?
> What on earth is the reason for this .pl to be included in any distribution?
>
> More...
>
> 2012/1/6 Chris Cormack <chris at bigballofwax.co.nz>
>  Im assuming you did this on your testing/staging server right?
> Id restore that from backup, then try applying the patch and see if you
> get better behaviour.
> If so, then do it on your production machine.
>
>
> what "patch"???
>
> And yes -- I can restore from a previous sqldump, and only lose +/- 100
> biblios.   We're in pre-production and when we got the zebra indexing
> working properly, I told our volunteers to start inputting to 3.6.1 *only*
> (not duplicate on 3.2) so that I could look into any difficulties they
> experienced as cataloguers.
>
> I had no way at all of knowing that a pl script included in the "latest
> stable distribution" could possibly demolish the whole db.
>
> Again, what "patch" and where do I find it?
>
> Might I suggest that someone re-opens the bug (I have attempted to
> annotate it) and removes this dangerous script from public distribution (or
> at least includes a very visible warning.)
>
> Best - Paul
>
>
>  Chris
> On 7 Jan 2012 08:47, "Paul" <paul.a at aandc.org> wrote:
> Bug 5683 (link_bibs_to_authorities.pl can corrupt records) was signed off
> some months ago, but is perhaps a little too cryptic for me to follow in
> detail. ? Can someone help? As far as I can see, without remedial action,
> this is catastrophic.
>
> Following difficulties we have had migrating 3.2 to 3.6.1, someone on the
> users mailing list suggested we should run link_bibs_to_authorities.pl --
> (db has ~10k authorities and ~15k biblios) -- so I did just that, and have
> APPARENTLY DEMOLISHED *EVERY* LINK IN THE DB. ? From my notes:
>
> paul at nelson:/usr/share/koha$ ./bin/link_bibs_to_authorities.pl
>
> Bib authority heading linking report
> ------------------------------------
> Number of bibs checked: ?  ?  ?  14911
> Number of bibs modified: ?  ?  ? 14886
> Number of bibs with errors: ?  0
>
> but - the staff interface no longer correctly finds authorities !!!
>
> [1] Manually link (staff client) auth "Lubbock" to bib "Arctic Whalers" --
> now linked, 35 other Lubbock bibs not linked. ? Is this a question of zebra
> re-indexing?
>
> So: ? KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib
> ./bin/migration_tools/rebuild_zebra.pl -a -r -v
> and ? KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib
> ./bin/migration_tools/rebuild_zebra.pl -b -r -v -x
>
> koha at nelson:/usr/share/koha$ ./bin/link_bibs_to_authorities.pl
> ... processed 100 records
> / ... /
> ... processed 14900 records
>
> Bib authority heading linking report
> ------------------------------------
> Number of bibs checked: ?  ?  ?  14911
> Number of bibs modified: ?  ?  ? 1
> Number of bibs with errors: ?  0
> koha at nelson:/usr/share/koha$
>
> All this did was to *un-link" the bib/auth link that I had manually
> entered at [1] above. Could someone involved with signing off bug 5683
> please explain why link==unlink?
>
> Help - please.
>
> Paul
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
>
>
>
> --
> Ian Walls
> Lead Development Specialist
> ByWater Solutions
> ALA Midwinter Booth #2048
> Phone # (888) 900-8944
> http://bywatersolutions.com
> ian.walls at bywatersolutions.com
> Twitter: @sekjal
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
> **
>
> ** ---
> Archives and Collections (ACS) Society
> 205, Main Street, Picton, Ontario, K0K 2T0, Canada
> http://www.AandC.org <http://www.aandc.org/>
> Canadian Charitable Organization 88721 9921 RR0001
> Dedicated to maritime conservation and education.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120107/ad84b2e0/attachment-0001.htm>

From paul.a at aandc.org  Fri Jan  6 22:45:29 2012
From: paul.a at aandc.org (Paul)
Date: Fri, 06 Jan 2012 16:45:29 -0500
Subject: [Koha-devel] link_bibs_to_authorities.pl can corrupt  records
In-Reply-To: <CA+95qVQ5qOs7YLvQmYkucmCnK-0nC-yB1rxxyQdTyXLwm+7brg@mail.g
	mail.com>
References: <5.2.1.1.2.20120106151732.00bea128@localhost>
	<5.2.1.1.2.20120106111952.00bea128@stormy.ca>
	<CA+95qVSce+C4W8dQaO1SwQZ=+VeaaZitznMAo2g8eWqd8jDzKw@mail.gmail.com>
	<5.2.1.1.2.20120106151732.00bea128@localhost>
Message-ID: <5.2.1.1.2.20120106161856.00bea980@localhost>

Chris,

Many thanks - picking up on you points below:

At 09:57 AM 1/7/2012 +1300, Chris Cormack wrote:

>I have successfully use that script to link authorities to biblio records 
>after doing a migration. But the way it works is to remove all links and 
>recreate.

Not sure about the "recreate" bit...

>Course I didn't do this on a server people were using, which it sounds 
>like you are, to have lost 100 biblios.

"People" are using it.  After nearly a year of using Koha 3.2, 3.6.1 is up 
and running (kudos to the development team, average LAN response time is 
down from 4.7 secs to well < 1 sec.)  I asked for assistance with zebra for 
authorities, and the assistance from the community allowed me to resolve 
the difficulties.  Then I asked our volunteers to start cataloguing on 
3.6.1 to sort out any remaining "update" glitches -- hence the ~100 biblios 
in the last 24 hours (if you want the nitty-gritty on why we've got to do 
so many per day, I'll oblige off-list)

>Its included for that use case. Jared is working on a much better linking 
>script and he gave you the information how to change it.

Respectfully, it's included in the "current stable release" with no 
warnings (3.6.1 was "current" when I installed it -- I haven't verified 
3.6.2.) and Jared's information came after "horses and barn doors."

>Its not a total screwup script, and it didn't demolish the whole db, I 
>think you would find people more willing to help you, in their own free 
>time, in their weekends if you didn't come across so aggressive and 
>accusatory in your tone.

I humbly apologize to anyone who finds me "aggressive and 
accusatory"  --  it's probably the way I was taught to write (concisely, 
briefly, etc) rather than my feelings.  Most people who know me well find 
me to be a cuddly rather than a grizzly bear.  Again my apologies.

Best - Paul


>Chris
>On 7 Jan 2012 09:48, "Archives and Collections Society" 
><<mailto:info at aandc.org>info at aandc.org> wrote:
>At 03:02 PM 1/6/2012 -0500, Ian Walls wrote:
>>Paul,
>>The <http://link_bibs_to_authorities.pl>link_bibs_to_authorities.pl 
>>script is hardcoded to ALWAYS erase manual links.???  I'm not sure what 
>>the reasoning is behind that.???  But, every time you run it, any link 
>>you've done manually that the script can't automatically figure out will 
>>be removed.???  Nature of the beast (for now, at least).
>
>What is "any link you've done manually"?, please.?  More than 90% of our 
>input is Z39.50 and "default" item cataloguing.
>
>OK - a total screw-up that is included without any warning whatsoever in 
>the standard distribution of 3.6.1 ????  From the bug report 
><<http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5683>http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5683>
>
>Chris Cormack 2011-06-01 21:13:23 UTC
>Pushed to master
>
>Jared Camins-Esakov 2011-07-08 14:37:02 UTC
>Seems to be working now. Closing.
>
>If it's "nature of the beast" why isn't the "beast" mentioned 
>somewhere??  What on earth is the reason for this .pl to be included in 
>any distribution?
>
>More...
>>2012/1/6 Chris Cormack 
>><<mailto:chris at bigballofwax.co.nz>chris at bigballofwax.co.nz>
>>Im assuming you did this on your testing/staging server right?
>>Id restore that from backup, then try applying the patch and see if you 
>>get better behaviour.
>>If so, then do it on your production machine.
>
>what "patch"???
>
>And yes -- I can restore from a previous sqldump, and only lose +/- 100 
>biblios.? ?  We're in pre-production and when we got the zebra indexing 
>working properly, I told our volunteers to start inputting to 3.6.1 *only* 
>(not duplicate on 3.2) so that I could look into any difficulties they 
>experienced as cataloguers.
>
>I had no way at all of knowing that a pl script included in the "latest 
>stable distribution" could possibly demolish the whole db.
>
>Again, what "patch" and where do I find it?
>
>Might I suggest that someone re-opens the bug (I have attempted to 
>annotate it) and removes this dangerous script from public distribution 
>(or at least includes a very visible warning.)
>
>Best - Paul
>
>>Chris
>>On 7 Jan 2012 08:47, "Paul" <<mailto:paul.a at aandc.org>paul.a at aandc.org> 
>>wrote:
>>Bug 5683 (<http://link_bibs_to_authorities.pl>link_bibs_to_authorities.pl 
>>can corrupt records) was signed off some months ago, but is perhaps a 
>>little too cryptic for me to follow in detail. ?? Can someone help? As 
>>far as I can see, without remedial action, this is catastrophic.
>>Following difficulties we have had migrating 3.2 to 3.6.1, someone on the 
>>users mailing list suggested we should run 
>><http://link_bibs_to_authorities.pl>link_bibs_to_authorities.pl -- (db 
>>has ~10k authorities and ~15k biblios) -- so I did just that, and have 
>>APPARENTLY DEMOLISHED *EVERY* LINK IN THE DB. ?? From my notes:
>>paul at nelson:/usr/share/koha$ 
>>./bin/<http://link_bibs_to_authorities.pl>link_bibs_to_authorities.pl
>>Bib authority heading linking report
>>------------------------------------
>>Number of bibs checked: ???  ???  ???  14911
>>Number of bibs modified: ???  ???  ?? 14886
>>Number of bibs with errors: ???  0
>>but - the staff interface no longer correctly finds authorities !!!
>>[1] Manually link (staff client) auth "Lubbock" to bib "Arctic Whalers" 
>>-- now linked, 35 other Lubbock bibs not linked. ?? Is this a question of 
>>zebra re-indexing?
>>So: ?? KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib 
>>./bin/migration_tools/<http://rebuild_zebra.pl>rebuild_zebra.pl -a -r -v
>>and ?? KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib 
>>./bin/migration_tools/<http://rebuild_zebra.pl>rebuild_zebra.pl -b -r -v -x
>>koha at nelson:/usr/share/koha$ 
>>./bin/<http://link_bibs_to_authorities.pl>link_bibs_to_authorities.pl
>>... processed 100 records
>>/ ... /
>>... processed 14900 records
>>Bib authority heading linking report
>>------------------------------------
>>Number of bibs checked: ???  ???  ???  14911
>>Number of bibs modified: ???  ???  ?? 1
>>Number of bibs with errors: ???  0
>>koha at nelson:/usr/share/koha$
>>All this did was to *un-link" the bib/auth link that I had manually 
>>entered at [1] above. Could someone involved with signing off bug 5683 
>>please explain why link==unlink?
>>Help - please.
>>Paul
>>_______________________________________________
>>Koha-devel mailing list
>><mailto:Koha-devel at lists.koha-community.org>Koha-devel at lists.koha-community.org 
>>
>>http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>>website : <http://www.koha-community.org/>http://www.koha-community.org/
>>git : <http://git.koha-community.org/>http://git.koha-community.org/
>>bugs : <http://bugs.koha-community.org/>http://bugs.koha-community.org/
>>
>>
>>_______________________________________________
>>Koha-devel mailing list
>><mailto:Koha-devel at lists.koha-community.org>Koha-devel at lists.koha-community.org
>>http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>>website : <http://www.koha-community.org/>http://www.koha-community.org/
>>git : <http://git.koha-community.org/>http://git.koha-community.org/
>>bugs : <http://bugs.koha-community.org/>http://bugs.koha-community.org/
>>
>>
>>
>>
>>--
>>Ian Walls
>>Lead Development Specialist
>>ByWater Solutions
>>ALA Midwinter Booth #2048
>>Phone # (888) 900-8944
>><http://bywatersolutions.com>http://bywatersolutions.com
>><mailto:ian.walls at bywatersolutions.com>ian.walls at bywatersolutions.com
>>Twitter: @sekjal
>>_______________________________________________
>>Koha-devel mailing list
>><mailto:Koha-devel at lists.koha-community.org>Koha-devel at lists.koha-community.org
>>http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>>website : <http://www.koha-community.org/>http://www.koha-community.org/
>>git : <http://git.koha-community.org/>http://git.koha-community.org/
>>bugs : <http://bugs.koha-community.org/>http://bugs.koha-community.org/
>
>---
>Archives and Collections (ACS) Society
>205, Main Street, Picton, Ontario, K0K 2T0, Canada
><http://www.aandc.org/>http://www.AandC.org
>Canadian Charitable Organization 88721 9921 RR0001
>Dedicated to maritime conservation and education.
>
>_______________________________________________
>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/

---
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120106/caa54d97/attachment.htm>

From magnus at enger.priv.no  Sat Jan  7 12:49:23 2012
From: magnus at enger.priv.no (Magnus Enger)
Date: Sat, 7 Jan 2012 12:49:23 +0100
Subject: [Koha-devel] Proposal to change Bugzilla Status and PatchStatus
	values
In-Reply-To: <CAE2wdZz-wYWMgnvVn22C3WSEAXYfhrKmNPy6gJ=XMJDWAdqMmw@mail.gmail.com>
References: <CAE2wdZw7vBgThw2E1DZhy0k28BEfd9r_JRrmOhsrVw9urPX4hg@mail.gmail.com>
	<CAO4qe2Nyerrfzjdvf0ZF+wB_=OCcPobbYothZqtnh9OH_XyX=Q@mail.gmail.com>
	<028B1A54D03E7B4482CDCA4EC8F06BFD016265E7@Bodensee.bsz-bw.de>
	<CAE2wdZz-wYWMgnvVn22C3WSEAXYfhrKmNPy6gJ=XMJDWAdqMmw@mail.gmail.com>
Message-ID: <CABg6UYFQK2mxrR-2Xi_OH8b6aF4xGAi5cYp189zDv8jysrVMxg@mail.gmail.com>

2012/1/6 Ian Walls <ian.walls at bywatersolutions.com>:
> or two.? Does anyone have a preference on what day of the week or time of
> day would have the least negative impact on our work?

Weekends seem to be pretty quiet all round...
http://blog.bigballofwax.co.nz/2011/11/04/nice-visualisation-of-when-work-is-done-on-koha/

Best regards,
Magnus Enger
libriotech.no

From tomascohen at gmail.com  Sat Jan  7 13:08:22 2012
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Sat, 7 Jan 2012 09:08:22 -0300
Subject: [Koha-devel] Proposal to change Bugzilla Status and PatchStatus
	values
In-Reply-To: <CABg6UYFQK2mxrR-2Xi_OH8b6aF4xGAi5cYp189zDv8jysrVMxg@mail.gmail.com>
References: <CAE2wdZw7vBgThw2E1DZhy0k28BEfd9r_JRrmOhsrVw9urPX4hg@mail.gmail.com>
	<CAO4qe2Nyerrfzjdvf0ZF+wB_=OCcPobbYothZqtnh9OH_XyX=Q@mail.gmail.com>
	<028B1A54D03E7B4482CDCA4EC8F06BFD016265E7@Bodensee.bsz-bw.de>
	<CAE2wdZz-wYWMgnvVn22C3WSEAXYfhrKmNPy6gJ=XMJDWAdqMmw@mail.gmail.com>
	<CABg6UYFQK2mxrR-2Xi_OH8b6aF4xGAi5cYp189zDv8jysrVMxg@mail.gmail.com>
Message-ID: <CABZfb=WGDjMq782ow-sEpATELcjmKKoWPWiqPCMztqJe1GMaaA@mail.gmail.com>

On Sat, Jan 7, 2012 at 8:49 AM, Magnus Enger <magnus at enger.priv.no> wrote:
> 2012/1/6 Ian Walls <ian.walls at bywatersolutions.com>:
>> or two.? Does anyone have a preference on what day of the week or time of
>> day would have the least negative impact on our work?
>
> Weekends seem to be pretty quiet all round...
> http://blog.bigballofwax.co.nz/2011/11/04/nice-visualisation-of-when-work-is-done-on-koha/

Great graphics! :-D

Late +1 for the proposal.
To+

From cnighswonger at foundations.edu  Sat Jan  7 14:27:37 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Sat, 7 Jan 2012 08:27:37 -0500
Subject: [Koha-devel] link_bibs_to_authorities.pl can corrupt records
In-Reply-To: <5.2.1.1.2.20120106161856.00bea980@localhost>
References: <5.2.1.1.2.20120106111952.00bea128@stormy.ca>
	<CA+95qVSce+C4W8dQaO1SwQZ=+VeaaZitznMAo2g8eWqd8jDzKw@mail.gmail.com>
	<5.2.1.1.2.20120106151732.00bea128@localhost>
	<5.2.1.1.2.20120106161856.00bea980@localhost>
Message-ID: <CAP3yOonOVPbnt1KKE3yy_eW48Mrx_rhqQUekLUK9dRw7gBtwCQ@mail.gmail.com>

Just what are probably obvious observations here:

1. *Always* run *any* script (stable or otherwise) which works on
data, on a test db (read "one into which zero records are being added)
*first and before* running it on a live (in *any* sense of the term)
db.

2. If my catalogers were doing 100+ bibs per day, I'd be running a
mysqldump on the db while they were at lunch and when they quit for
the day (and probably anytime they took a coffee break, too).

Just my $0.02 worth.

Kind Regards,
Chris


2012/1/6 Paul <paul.a at aandc.org>:
> Chris,
>
> Many thanks - picking up on you points below:
>
>
> At 09:57 AM 1/7/2012 +1300, Chris Cormack wrote:
>
> I have successfully use that script to link authorities to biblio records
> after doing a migration. But the way it works is to remove all links and
> recreate.
>
>
> Not sure about the "recreate" bit...
>
>
> Course I didn't do this on a server people were using, which it sounds like
> you are, to have lost 100 biblios.
>
>
> "People" are using it.? After nearly a year of using Koha 3.2, 3.6.1 is up
> and running (kudos to the development team, average LAN response time is
> down from 4.7 secs to well < 1 sec.)? I asked for assistance with zebra for
> authorities, and the assistance from the community allowed me to resolve the
> difficulties.? Then I asked our volunteers to start cataloguing on 3.6.1 to
> sort out any remaining "update" glitches -- hence the ~100 biblios in the
> last 24 hours (if you want the nitty-gritty on why we've got to do so many
> per day, I'll oblige off-list)
>
>
> Its included for that use case. Jared is working on a much better linking
> script and he gave you the information how to change it.
>
>
> Respectfully, it's included in the "current stable release" with no warnings
> (3.6.1 was "current" when I installed it -- I haven't verified 3.6.2.) and
> Jared's information came after "horses and barn doors."
>
>
> Its not a total screwup script, and it didn't demolish the whole db, I think
> you would find people more willing to help you, in their own free time, in
> their weekends if you didn't come across so aggressive and accusatory in
> your tone.
>
>
> I humbly apologize to anyone who finds me "aggressive and accusatory"? --
> it's probably the way I was taught to write (concisely, briefly, etc) rather
> than my feelings.? Most people who know me well find me to be a cuddly
> rather than a grizzly bear.? Again my apologies.
>
> Best - Paul
>
>
> Chris
>
> On 7 Jan 2012 09:48, "Archives and Collections Society" <info at aandc.org>
> wrote:
> At 03:02 PM 1/6/2012 -0500, Ian Walls wrote:
>
> Paul,
> The link_bibs_to_authorities.pl script is hardcoded to ALWAYS erase manual
> links.???? I'm not sure what the reasoning is behind that.???? But, every
> time you run it, any link you've done manually that the script can't
> automatically figure out will be removed.???? Nature of the beast (for now,
> at least).
>
>
> What is "any link you've done manually"?, please.?? More than 90% of our
> input is Z39.50 and "default" item cataloguing.
>
> OK - a total screw-up that is included without any warning whatsoever in the
> standard distribution of 3.6.1 ????? From the bug report
> <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5683>
>
> Chris Cormack 2011-06-01 21:13:23 UTC
> Pushed to master
>
> Jared Camins-Esakov 2011-07-08 14:37:02 UTC
> Seems to be working now. Closing.
>
> If it's "nature of the beast" why isn't the "beast" mentioned somewhere??
> What on earth is the reason for this .pl to be included in any distribution?
>
> More...
>
> 2012/1/6 Chris Cormack <chris at bigballofwax.co.nz> Im assuming you did this
> on your testing/staging server right? Id restore that from backup, then try
> applying the patch and see if you get better behaviour. If so, then do it on
> your production machine.
>
>
> what "patch"???
>
> And yes -- I can restore from a previous sqldump, and only lose +/- 100
> biblios.? ?? We're in pre-production and when we got the zebra indexing
> working properly, I told our volunteers to start inputting to 3.6.1 *only*
> (not duplicate on 3.2) so that I could look into any difficulties they
> experienced as cataloguers.
>
>
> I had no way at all of knowing that a pl script included in the "latest
> stable distribution" could possibly demolish the whole db.
>
> Again, what "patch" and where do I find it?
>
> Might I suggest that someone re-opens the bug (I have attempted to annotate
> it) and removes this dangerous script from public distribution (or at least
> includes a very visible warning.)
>
> Best - Paul
>
> Chris
> On 7 Jan 2012 08:47, "Paul" <paul.a at aandc.org> wrote:
> Bug 5683 (link_bibs_to_authorities.pl can corrupt records) was signed off
> some months ago, but is perhaps a little too cryptic for me to follow in
> detail. ?? Can someone help? As far as I can see, without remedial action,
> this is catastrophic.
> Following difficulties we have had migrating 3.2 to 3.6.1, someone on the
> users mailing list suggested we should run link_bibs_to_authorities.pl --
> (db has ~10k authorities and ~15k biblios) -- so I did just that, and have
> APPARENTLY DEMOLISHED *EVERY* LINK IN THE DB. ?? From my notes:
> paul at nelson:/usr/share/koha$ ./bin/link_bibs_to_authorities.pl
> Bib authority heading linking report
> ------------------------------------ Number of bibs checked: ???? ???? ???
> 14911 Number of bibs modified: ???? ???? ?? 14886 Number of bibs with
> errors: ???? 0
> but - the staff interface no longer correctly finds authorities !!!
> [1] Manually link (staff client) auth "Lubbock" to bib "Arctic Whalers" --
> now linked, 35 other Lubbock bibs not linked. ?? Is this a question of zebra
> re-indexing?
> So: ?? KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib
> ./bin/migration_tools/rebuild_zebra.pl -a -r -v and ??
> KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib
> ./bin/migration_tools/rebuild_zebra.pl -b -r -v -x
> koha at nelson:/usr/share/koha$ ./bin/link_bibs_to_authorities.pl ... processed
> 100 records / ... / ... processed 14900 records
> Bib authority heading linking report
> ------------------------------------ Number of bibs checked: ???? ???? ???
> 14911 Number of bibs modified: ???? ???? ?? 1 Number of bibs with errors:
> ???? 0
> koha at nelson:/usr/share/koha$
> All this did was to *un-link" the bib/auth link that I had manually entered
> at [1] above. Could someone involved with signing off bug 5683 please
> explain why link==unlink?
> Help - please.
> Paul
> _______________________________________________ Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website
> : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs :
> http://bugs.koha-community.org/
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
>
>
>
> --
> Ian Walls
> Lead Development Specialist
> ByWater Solutions
> ALA Midwinter Booth #2048
> Phone # (888) 900-8944
> http://bywatersolutions.com
> ian.walls at bywatersolutions.com
> Twitter: @sekjal
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
>
> ---
> Archives and Collections (ACS) Society
> 205, Main Street, Picton, Ontario, K0K 2T0, Canada
> http://www.AandC.org
> Canadian Charitable Organization 88721 9921 RR0001
> Dedicated to maritime conservation and education.
>
> _______________________________________________
> 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/
>
> ---
> 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>
>
>
> _______________________________________________
> 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 ian.walls at bywatersolutions.com  Sat Jan  7 15:45:12 2012
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Sat, 7 Jan 2012 09:45:12 -0500
Subject: [Koha-devel] Proposal to change Bugzilla Status and PatchStatus
	values
In-Reply-To: <CABZfb=WGDjMq782ow-sEpATELcjmKKoWPWiqPCMztqJe1GMaaA@mail.gmail.com>
References: <CAE2wdZw7vBgThw2E1DZhy0k28BEfd9r_JRrmOhsrVw9urPX4hg@mail.gmail.com>
	<CAO4qe2Nyerrfzjdvf0ZF+wB_=OCcPobbYothZqtnh9OH_XyX=Q@mail.gmail.com>
	<028B1A54D03E7B4482CDCA4EC8F06BFD016265E7@Bodensee.bsz-bw.de>
	<CAE2wdZz-wYWMgnvVn22C3WSEAXYfhrKmNPy6gJ=XMJDWAdqMmw@mail.gmail.com>
	<CABg6UYFQK2mxrR-2Xi_OH8b6aF4xGAi5cYp189zDv8jysrVMxg@mail.gmail.com>
	<CABZfb=WGDjMq782ow-sEpATELcjmKKoWPWiqPCMztqJe1GMaaA@mail.gmail.com>
Message-ID: <CAE2wdZyNPPHnrF76oTcoP_e+KthMkBthnASypMD=9pHC7C+GDg@mail.gmail.com>

Okay, so it looks like Saturday/Sunday would be the best option.  But,
rather than rush through and implement this RIGHT NOW, I want to wait until
next weekend to implement the change, so folks have more working, and more
chances to register an opinion on the matter.

How about scheduling this for Jan 15th, 2012 00:00 UTC (or thereabouts)?
 That's Saturday evening for the Americas, early Sunday for Europe and
India, and mid-day Sunday in Australia/New Zealand (assuming I got my time
conversions right...)

The scheduled actions will be as follows:

1.  Add new Statuses to Status Workflow
2.  Turn off bug emails
3.  Bulk edit all tickets with Patch Status values to have the
corresponding Status; note this will only apply to OPEN bug reports
4.  Alter the canned searches to make use of the Status instead of Patch
Status
5.  Reactivate bug emails
6.  Update community documentation where appropriate, and notify everyone
of the change on list

Are there any other bulk editing actions we'd like to add to this
'emailless' window of time?

Cheers,


-Ian


On Sat, Jan 7, 2012 at 7:08 AM, Tomas Cohen Arazi <tomascohen at gmail.com>wrote:

> On Sat, Jan 7, 2012 at 8:49 AM, Magnus Enger <magnus at enger.priv.no> wrote:
> > 2012/1/6 Ian Walls <ian.walls at bywatersolutions.com>:
> >> or two.  Does anyone have a preference on what day of the week or time
> of
> >> day would have the least negative impact on our work?
> >
> > Weekends seem to be pretty quiet all round...
> >
> http://blog.bigballofwax.co.nz/2011/11/04/nice-visualisation-of-when-work-is-done-on-koha/
>
> Great graphics! :-D
>
> Late +1 for the proposal.
> To+
>



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

From M.de.Rooy at rijksmuseum.nl  Mon Jan  9 09:12:56 2012
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Mon, 9 Jan 2012 08:12:56 +0000
Subject: [Koha-devel] Proposal to change Bugzilla Status and Patch
 Status	values
In-Reply-To: <CAE2wdZw7vBgThw2E1DZhy0k28BEfd9r_JRrmOhsrVw9urPX4hg@mail.gmail.com>
References: <CAE2wdZw7vBgThw2E1DZhy0k28BEfd9r_JRrmOhsrVw9urPX4hg@mail.gmail.com>
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA313A6D4E@S-MAIL-1B.rijksmuseum.intra>

No problem with moving the existing patch statuses to Status. But just another thought: isn?t patch status actually a status that should be on the level of attachment? Sometimes we have reports with several patches and it may happen that not all active patches are on the same patch status level. If we make a change now, we could look at those situations..

About status ?In Discussion?: Discussion should be in the beginning of development and could be anywhere later on. As I understand this point now, this relates to a patch with larger impact that could pass qa but may not have community consensus. Just setting the status to In Discussion will not help; mailing the list while the status remains as-is could work as well. If such a patch meets qa standards and would reach Passed QA, it becomes a problem for the RM (even more if the patch came from him ;). The RM could again ask for community response before pushing that patch. In conclusion, I would not per se add this new status.

In the particular case of 7167, I would say that the QA team could ask for more signoff?s (instead of the current Failed QA). This could also be a new status (at attachment level)? If a patch reaches signoff but QA feels that one or two additional signoff?s would be beneficial, QA could set the status ?Needs additional signoff?.


Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Ian Walls
Verzonden: vrijdag 6 januari 2012 15:37
Aan: koha-devel at lists.koha-community.org
Onderwerp: [Koha-devel] Proposal to change Bugzilla Status and Patch Status values

Fellow Koha-ckers,


A comment on bug 7167 (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7167) has gotten my interest re-awakened about a proposed Bugzilla revision that had been floated earlier this release cycle.

I'd like to remove Patch Status, and move all those values to the regular Status field.  This has the following advantages:

  *   Status is a built-in field, so it's got much richer support in Bugzilla.  For example, status workflows can be added.  Patch Status is a custom field, and is just a list of values
  *   We would no longer lose the Priority value of a bug by having to set it to Patch Sent in order to get the Patch Status values visible
  *   Statuses can be updated as part of submitting an attachment like a patch, streamlining the patch submission process (fewer clicks to keep all the fields up to date).

I'd also like to add a new status, "In Discussion", for bug reports that have deeper procedural, philsophical or technical implications outside that of mere coding (bug 7167 being an example).

We're not using Status for anything else, so there is no trade-off there.  This is really how the Status field is meant to be used.  We will, however, have to rebuild the canned searches that look for patches that Need Signoff, are Signed Off, and are Passed QA/Failed QA.

The other difficulty of this proposal is that we'll need to turn off automatic bug emails for a bit while we make the bulk changes to the Patch Statuses; otherwise, we'll all get spammed to high heaven with meaningless updates when the migration occurs.

What do people think?  Does this sound like a reasonable change to make?  Any objections?

Cheers,



-Ian



-- Ian Walls
Lead Development Specialist
ByWater Solutions
ALA Midwinter Booth #2048
Phone # (888) 900-8944<tel:%28888%29%20900-8944>
http://bywatersolutions.com
ian.walls at bywatersolutions.com<mailto:ian.walls at bywatersolutions.com>
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120109/33c4caf3/attachment.htm>

From tajoli at cilea.it  Mon Jan  9 15:44:21 2012
From: tajoli at cilea.it (Zeno Tajoli)
Date: Mon, 09 Jan 2012 15:44:21 +0100
Subject: [Koha-devel] deafult for biblio.frameworkcode
Message-ID: <4F0AFD45.1040402@cilea.it>

Hi to all,

I want to add, in "Koha to MARC mapping"
a link beetween the mysql field biblio.frameworkcode
to a marc21 subfield.

I think it is useful to have this data in the marc record.
I propose to use 997 $a.
The tag 997 is an empty tag.

What do you thing ?

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

From gmc at esilibrary.com  Mon Jan  9 15:55:51 2012
From: gmc at esilibrary.com (Galen Charlton)
Date: Mon, 09 Jan 2012 09:55:51 -0500
Subject: [Koha-devel] deafult for biblio.frameworkcode
In-Reply-To: <4F0AFD45.1040402@cilea.it>
References: <4F0AFD45.1040402@cilea.it>
Message-ID: <4F0AFFF7.90408@esilibrary.com>

Hi,

On 01/09/2012 09:44 AM, Zeno Tajoli wrote:
> I want to add, in "Koha to MARC mapping"
> a link beetween the mysql field biblio.frameworkcode
> to a marc21 subfield.
>
> I think it is useful to have this data in the marc record.

Could you elaborate more on the use case this would support?  The 
framework code is displayed in the bib editor, for example, which is one 
point where a cataloger would need to know about it.  Adding it to the 
MARC framework would make it available for searching and make it a 
little more convenient to display the framework code in XSLT OPAC 
displays -- but to what end?

For MARC21 frameworks, if we were add to this to the default framework, 
I'd prefer that the 942 or the 999 be used, as those are already 
supported for bib-level mappings -- no need to carve out another tag.

Regards,

Galen
-- 
Galen Charlton
Director of Support and Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org & 
http://evergreen-ils.org

From jcamins at cpbibliography.com  Mon Jan  9 16:06:05 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Mon, 9 Jan 2012 10:06:05 -0500
Subject: [Koha-devel] deafult for biblio.frameworkcode
In-Reply-To: <4F0AFFF7.90408@esilibrary.com>
References: <4F0AFD45.1040402@cilea.it>
	<4F0AFFF7.90408@esilibrary.com>
Message-ID: <CALVDfQwFWGXDyJqUqe_6E9d3=hgqT34nFp71=miiYeQoqAMZYg@mail.gmail.com>

Good morning,

On Mon, Jan 9, 2012 at 9:55 AM, Galen Charlton <gmc at esilibrary.com> wrote:

> On 01/09/2012 09:44 AM, Zeno Tajoli wrote:
>
>> I want to add, in "Koha to MARC mapping"
>> a link beetween the mysql field biblio.frameworkcode
>> to a marc21 subfield.
>>
>> I think it is useful to have this data in the marc record.
>>
>
> Could you elaborate more on the use case this would support?  The
> framework code is displayed in the bib editor, for example, which is one
> point where a cataloger would need to know about it.  Adding it to the MARC
> framework would make it available for searching and make it a little more
> convenient to display the framework code in XSLT OPAC displays -- but to
> what end?
>

I have no idea, but I have no particular objection to it being stored in
the MARC record.

For MARC21 frameworks, if we were add to this to the default framework, I'd
> prefer that the 942 or the 999 be used, as those are already supported for
> bib-level mappings -- no need to carve out another tag.
>

+1 on 942

Regards,
Jared

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

From gmc at esilibrary.com  Mon Jan  9 16:08:34 2012
From: gmc at esilibrary.com (Galen Charlton)
Date: Mon, 09 Jan 2012 10:08:34 -0500
Subject: [Koha-devel] deafult for biblio.frameworkcode
In-Reply-To: <CALVDfQwFWGXDyJqUqe_6E9d3=hgqT34nFp71=miiYeQoqAMZYg@mail.gmail.com>
References: <4F0AFD45.1040402@cilea.it>	<4F0AFFF7.90408@esilibrary.com>
	<CALVDfQwFWGXDyJqUqe_6E9d3=hgqT34nFp71=miiYeQoqAMZYg@mail.gmail.com>
Message-ID: <4F0B02F2.5000807@esilibrary.com>

Hi,

On 01/09/2012 10:06 AM, Jared Camins-Esakov wrote:
> On Mon, Jan 9, 2012 at 9:55 AM, Galen Charlton <gmc at esilibrary.com
> <mailto:gmc at esilibrary.com>> wrote:
>     Could you elaborate more on the use case this would support?  The
>     framework code is displayed in the bib editor, for example, which is
>     one point where a cataloger would need to know about it.  Adding it
>     to the MARC framework would make it available for searching and make
>     it a little more convenient to display the framework code in XSLT
>     OPAC displays -- but to what end?
>
>
> I have no idea, but I have no particular objection to it being stored in
> the MARC record.

And to be clear, I don't have a particular objection either, just 
curiosity regarding the use case.

Regards,

Galen
-- 
Galen Charlton
Director of Support and Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org & 
http://evergreen-ils.org

From ian.bays at ptfs-europe.com  Mon Jan  9 16:31:15 2012
From: ian.bays at ptfs-europe.com (Ian Bays)
Date: Mon, 09 Jan 2012 15:31:15 +0000
Subject: [Koha-devel] deafult for biblio.frameworkcode
In-Reply-To: <4F0B02F2.5000807@esilibrary.com>
References: <4F0AFD45.1040402@cilea.it>	<4F0AFFF7.90408@esilibrary.com>
	<CALVDfQwFWGXDyJqUqe_6E9d3=hgqT34nFp71=miiYeQoqAMZYg@mail.gmail.com>
	<4F0B02F2.5000807@esilibrary.com>
Message-ID: <4F0B0843.4050905@ptfs-europe.com>

Hi.
This does open up possibilities for loading bib data directly into a 
particular framework.  Currently for data loading I have not found any 
way to load bib records into anything but default framework and then 
with SQL change the frameworkcode for a range of biblionumbers (if I 
remembered to catch the numbers).  Even if this is not automatically 
done as part of this change we could run sql to change the framework 
dependent on the contents of the subfield of 942 field.  Hopefully the 
act of loading the bib data would not overwrite the 942 subfield as 
"default" (as currently bibs are loaded into default), if you see what I 
mean.

Sounds a positive move to me.

Ian

On 09/01/2012 15:08, Galen Charlton wrote:
> Hi,
>
> On 01/09/2012 10:06 AM, Jared Camins-Esakov wrote:
>> On Mon, Jan 9, 2012 at 9:55 AM, Galen Charlton <gmc at esilibrary.com
>> <mailto:gmc at esilibrary.com>> wrote:
>>     Could you elaborate more on the use case this would support?  The
>>     framework code is displayed in the bib editor, for example, which is
>>     one point where a cataloger would need to know about it.  Adding it
>>     to the MARC framework would make it available for searching and make
>>     it a little more convenient to display the framework code in XSLT
>>     OPAC displays -- but to what end?
>>
>>
>> I have no idea, but I have no particular objection to it being stored in
>> the MARC record.
>
> And to be clear, I don't have a particular objection either, just 
> curiosity regarding the use case.
>
> Regards,
>
> Galen

-- 
Ian Bays
Director of Projects, PTFS Europe Limited
Content Management and Library Solutions
+44 (0) 800 756 6803 (phone)
+44 (0) 7774 995297 (mobile)
+44 (0) 800 756 6384 (fax)
skype: ian.bays
email: ian.bays at ptfs-europe.com


From tajoli at cilea.it  Mon Jan  9 16:32:30 2012
From: tajoli at cilea.it (Zeno Tajoli)
Date: Mon, 09 Jan 2012 16:32:30 +0100
Subject: [Koha-devel] deafult for biblio.frameworkcode
In-Reply-To: <4F0AFFF7.90408@esilibrary.com>
References: <4F0AFD45.1040402@cilea.it> <4F0AFFF7.90408@esilibrary.com>
Message-ID: <4F0B088E.1050502@cilea.it>

Hi to all,

Il 09/01/2012 15:55, Galen Charlton ha scritto:

> Could you elaborate more on the use case this would support?  The
> framework code is displayed in the bib editor, for example, which is one
> point where a cataloger would need to know about it.  Adding it to the
> MARC framework would make it available for searching and make it a
> little more convenient to display the framework code in XSLT OPAC
> displays -- but to what end?

oh, is quite simple.
I want to export data in marc format to import in an other Koha and I
use different frameworks to catalogue.

If I insertr biblio.frameworkcode, I can re-import records in different
frameworks.

Clearly I need to setup 'marc to Koha links' before to import with
bulkmarcimport.pl

> For MARC21 frameworks, if we were add to this to the default framework,
> I'd prefer that the 942 or the 999 be used, as those are already
> supported for bib-level mappings -- no need to carve out another tag.

Well, in theory 999 are repetable, 942 is not repetable.
So for me is better 942.
A new subfield or we re-use $a ?
The subfield used are [default framework]:
-- 942
0 	Koha issues (borrowed),
2 	Source of classification or shelving scheme
6 	Koha normalized classification for sorting
a 	Institution code [OBSOLETE] 	
c 	Koha [default] item type 	
e 	Edition 	
h 	Classification part 	
i 	Item part 	
k 	Call number prefix 	
m 	Call number suffix 	
n 	Suppress in OPAC
s 	Serial record flag

Bye
Zeno Tajoli


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

From jcamins at cpbibliography.com  Mon Jan  9 16:49:50 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Mon, 9 Jan 2012 10:49:50 -0500
Subject: [Koha-devel] deafult for biblio.frameworkcode
In-Reply-To: <4F0B088E.1050502@cilea.it>
References: <4F0AFD45.1040402@cilea.it> <4F0AFFF7.90408@esilibrary.com>
	<4F0B088E.1050502@cilea.it>
Message-ID: <CALVDfQwuGj6oxihMXAUF1xgD25gBcNCNapsviWEqNwvp8h-1Ag@mail.gmail.com>

Zeno, et. al.,

On Mon, Jan 9, 2012 at 10:32 AM, Zeno Tajoli <tajoli at cilea.it> wrote:

> oh, is quite simple.
> I want to export data in marc format to import in an other Koha and I
> use different frameworks to catalogue.
>
> If I insertr biblio.frameworkcode, I can re-import records in different
> frameworks.
>
> Clearly I need to setup 'marc to Koha links' before to import with
> bulkmarcimport.pl
>
> > For MARC21 frameworks, if we were add to this to the default framework,
> > I'd prefer that the 942 or the 999 be used, as those are already
> > supported for bib-level mappings -- no need to carve out another tag.
>
> Well, in theory 999 are repetable, 942 is not repetable.
> So for me is better 942.
> A new subfield or we re-use $a ?
> The subfield used are [default framework]:
> -- 942
>

What about 942$f? For 'F'ramework?

Regards,
Jared

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

From ian.walls at bywatersolutions.com  Mon Jan  9 16:55:23 2012
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Mon, 9 Jan 2012 10:55:23 -0500
Subject: [Koha-devel] deafult for biblio.frameworkcode
In-Reply-To: <CALVDfQwuGj6oxihMXAUF1xgD25gBcNCNapsviWEqNwvp8h-1Ag@mail.gmail.com>
References: <4F0AFD45.1040402@cilea.it> <4F0AFFF7.90408@esilibrary.com>
	<4F0B088E.1050502@cilea.it>
	<CALVDfQwuGj6oxihMXAUF1xgD25gBcNCNapsviWEqNwvp8h-1Ag@mail.gmail.com>
Message-ID: <CAE2wdZyGBfph9UJ_gwfkhsPC_SjhtDcp8JcRG3-7GJnFwKzs=Q@mail.gmail.com>

I support 942$f for the following reasons:

1. best to use an existing tag, and 942 is the best-fit candidate for
non-repeating biblio-level, Koha-specific information

2. New subfields for new content, rather than repurposing an old field (and
possibly having data conflicts on systems that still have the old, obsolete
value)

3. subfield letter is the initial (in English) for the thing being stored;
easy to remember!


-Ian

2012/1/9 Jared Camins-Esakov <jcamins at cpbibliography.com>

> Zeno, et. al.,
>
> On Mon, Jan 9, 2012 at 10:32 AM, Zeno Tajoli <tajoli at cilea.it> wrote:
>
>> oh, is quite simple.
>> I want to export data in marc format to import in an other Koha and I
>> use different frameworks to catalogue.
>>
>> If I insertr biblio.frameworkcode, I can re-import records in different
>> frameworks.
>>
>> Clearly I need to setup 'marc to Koha links' before to import with
>> bulkmarcimport.pl
>>
>> > For MARC21 frameworks, if we were add to this to the default framework,
>> > I'd prefer that the 942 or the 999 be used, as those are already
>> > supported for bib-level mappings -- no need to carve out another tag.
>>
>> Well, in theory 999 are repetable, 942 is not repetable.
>> So for me is better 942.
>> A new subfield or we re-use $a ?
>> The subfield used are [default framework]:
>> -- 942
>>
>
> What about 942$f? For 'F'ramework?
>
> Regards,
> Jared
>
> --
> Jared Camins-Esakov
> Bibliographer, C & P Bibliography Services, LLC
> (phone) +1 (917) 727-3445
> (e-mail) jcamins at cpbibliography.com
> (web) http://www.cpbibliography.com/
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



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

From tajoli at cilea.it  Mon Jan  9 17:00:35 2012
From: tajoli at cilea.it (Zeno Tajoli)
Date: Mon, 09 Jan 2012 17:00:35 +0100
Subject: [Koha-devel] deafult for biblio.frameworkcode
In-Reply-To: <CAE2wdZyGBfph9UJ_gwfkhsPC_SjhtDcp8JcRG3-7GJnFwKzs=Q@mail.gmail.com>
References: <4F0AFD45.1040402@cilea.it> <4F0AFFF7.90408@esilibrary.com>
	<4F0B088E.1050502@cilea.it>
	<CALVDfQwuGj6oxihMXAUF1xgD25gBcNCNapsviWEqNwvp8h-1Ag@mail.gmail.com>
	<CAE2wdZyGBfph9UJ_gwfkhsPC_SjhtDcp8JcRG3-7GJnFwKzs=Q@mail.gmail.com>
Message-ID: <4F0B0F23.9030108@cilea.it>

Hi to all,

Il 09/01/2012 16:55, Ian Walls ha scritto:
> I support 942$f for the following reasons:
> 
> 1. best to use an existing tag, and 942 is the best-fit candidate for
> non-repeating biblio-level, Koha-specific information
> 
> 2. New subfields for new content, rather than repurposing an old field (and
> possibly having data conflicts on systems that still have the old, obsolete
> value)
> 
> 3. subfield letter is the initial (in English) for the thing being stored;
> easy to remember!

for me 942 $f is OK.

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

From gmc at esilibrary.com  Mon Jan  9 17:04:56 2012
From: gmc at esilibrary.com (Galen Charlton)
Date: Mon, 09 Jan 2012 11:04:56 -0500
Subject: [Koha-devel] deafult for biblio.frameworkcode
In-Reply-To: <CAE2wdZyGBfph9UJ_gwfkhsPC_SjhtDcp8JcRG3-7GJnFwKzs=Q@mail.gmail.com>
References: <4F0AFD45.1040402@cilea.it>
	<4F0AFFF7.90408@esilibrary.com>	<4F0B088E.1050502@cilea.it>	<CALVDfQwuGj6oxihMXAUF1xgD25gBcNCNapsviWEqNwvp8h-1Ag@mail.gmail.com>
	<CAE2wdZyGBfph9UJ_gwfkhsPC_SjhtDcp8JcRG3-7GJnFwKzs=Q@mail.gmail.com>
Message-ID: <4F0B1028.20004@esilibrary.com>

Hi,

On 01/09/2012 10:55 AM, Ian Walls wrote:
> I support 942$f for the following reasons:
>
> 1. best to use an existing tag, and 942 is the best-fit candidate for
> non-repeating biblio-level, Koha-specific information
>
> 2. New subfields for new content, rather than repurposing an old field
> (and possibly having data conflicts on systems that still have the old,
> obsolete value)
>
> 3. subfield letter is the initial (in English) for the thing being
> stored; easy to remember!

+1

Regards,

Galen
-- 
Galen Charlton
Director of Support and Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org & 
http://evergreen-ils.org

From gmc at esilibrary.com  Mon Jan  9 17:17:13 2012
From: gmc at esilibrary.com (Galen Charlton)
Date: Mon, 09 Jan 2012 11:17:13 -0500
Subject: [Koha-devel] Repeatable 999? (was Re: deafult for
	biblio.frameworkcode)
In-Reply-To: <4F0B088E.1050502@cilea.it>
References: <4F0AFD45.1040402@cilea.it> <4F0AFFF7.90408@esilibrary.com>
	<4F0B088E.1050502@cilea.it>
Message-ID: <4F0B1309.3040304@esilibrary.com>

Hi,

On 01/09/2012 10:32 AM, Zeno Tajoli wrote:
> Well, in theory 999 are repetable,

Actually, that's a problem.  The 999 is indeed marked as repeatable in 
the (MARC21) frameworks, but since it is used to store the 
biblio(item)number, it really shouldn't be marked as repeatable (or even 
editable by staff users).  Does anybody see any problem making it 
non-repeatable?

Regards,

Galen
-- 
Galen Charlton
Director of Support and Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org & 
http://evergreen-ils.org

From tajoli at cilea.it  Mon Jan  9 17:44:27 2012
From: tajoli at cilea.it (Zeno Tajoli)
Date: Mon, 09 Jan 2012 17:44:27 +0100
Subject: [Koha-devel] Repeatable 999? (was Re: deafult for
	biblio.frameworkcode)
In-Reply-To: <4F0B1309.3040304@esilibrary.com>
References: <4F0AFD45.1040402@cilea.it> <4F0AFFF7.90408@esilibrary.com>
	<4F0B088E.1050502@cilea.it> <4F0B1309.3040304@esilibrary.com>
Message-ID: <4F0B196B.4050606@cilea.it>

Hi to all,

Il 09/01/2012 17:17, Galen Charlton ha scritto:
> On 01/09/2012 10:32 AM, Zeno Tajoli wrote:
>> Well, in theory 999 are repetable,
> 
> Actually, that's a problem.  The 999 is indeed marked as repeatable in
> the (MARC21) frameworks, but since it is used to store the
> biblio(item)number, it really shouldn't be marked as repeatable (or even
> editable by staff users).  Does anybody see any problem making it
> non-repeatable?

no problem for me.

Bye
Zeno Tajoli

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

From paul.a at aandc.org  Mon Jan  9 20:54:42 2012
From: paul.a at aandc.org (Paul)
Date: Mon, 09 Jan 2012 14:54:42 -0500
Subject: [Koha-devel] Repeatable 999? (was Re: deafult for
 biblio.frameworkcode)
In-Reply-To: <4F0B1309.3040304@esilibrary.com>
References: <4F0B088E.1050502@cilea.it> <4F0AFD45.1040402@cilea.it>
	<4F0AFFF7.90408@esilibrary.com> <4F0B088E.1050502@cilea.it>
Message-ID: <5.2.1.1.2.20120109144747.03ea4e80@localhost>

At 11:17 AM 1/9/2012 -0500, Galen Charlton wrote:
>Hi,
>
>On 01/09/2012 10:32 AM, Zeno Tajoli wrote:
>>Well, in theory 999 are repetable,
>
>Actually, that's a problem.  The 999 is indeed marked as repeatable in the 
>(MARC21) frameworks, but since it is used to store the biblio(item)number, 
>it really shouldn't be marked as repeatable (or even editable by staff 
>users).  Does anybody see any problem making it non-repeatable?

As far as I can see, they already appear to be non-repeatable (unless I 
modded the default framework in 3.2 and it's been imported into 3.6.)  I 
find all four subfields (a, b, c and d) non-repeatable (according to the 
check box) and it doesn't seem to make much difference whether they are 
"ignored" or in tab 0 as no cataloguer will be able to attempt an 
edit|modification.

Am I missing something?  Or have I done something stupid?

Thanks - Paul


>Regards,
>
>Galen
>--
>Galen Charlton
>Director of Support and Implementation
>Equinox Software, Inc. / The Open Source Experts
>email:  gmc at esilibrary.com
>direct: +1 770-709-5581
>cell:   +1 404-984-4366
>skype:  gmcharlt
>web:    http://www.esilibrary.com/
>Supporting Koha and Evergreen: http://koha-community.org & 
>http://evergreen-ils.org
>_______________________________________________
>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/

---
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 bibliwho at gmail.com  Mon Jan  9 21:12:02 2012
From: bibliwho at gmail.com (Cab Vinton)
Date: Mon, 9 Jan 2012 15:12:02 -0500
Subject: [Koha-devel] Active borrowers report
Message-ID: <CABW43USJpu01F7tSA3DgnCjfygnCns633adRfiHQkvQk5C=4_Q@mail.gmail.com>

A couple years ago Jesse Weaver came up with this report for active
borrowers (i.e., patrons checking out materials):

	SELECT YEAR(issuedate), MONTH(issuedate), categorycode,
COUNT(DISTINCT borrowernumber)
	FROM old_issues
	LEFT JOIN borrowers USING (borrowernumber)
	GROUP BY YEAR(issuedate), MONTH(issuedate), categorycode;

I'm wondering if the caveat he notes is still true:

	Because it uses old_issues, it won't include anything that's still
checked out; getting
	around that requires either ugly subqueries or running the report
with old_issues
	and issues and manually combining the results.

Is there a relatively easy way to modify the report so it includes
patrons who may still have items checked out?

Thanks for any assistance!

Cab Vinton, Director
Sanbornton Public Library
Sanbornton, NH

"Politeness and consideration for others is like investing pennies and
getting dollars back." Thomas Sowell

From gmc at esilibrary.com  Mon Jan  9 21:19:56 2012
From: gmc at esilibrary.com (Galen Charlton)
Date: Mon, 09 Jan 2012 15:19:56 -0500
Subject: [Koha-devel] Repeatable 999? (was Re: deafult for
	biblio.frameworkcode)
In-Reply-To: <5.2.1.1.2.20120109144747.03ea4e80@localhost>
References: <4F0B088E.1050502@cilea.it>
	<4F0AFD45.1040402@cilea.it>	<4F0AFFF7.90408@esilibrary.com>
	<4F0B088E.1050502@cilea.it>
	<5.2.1.1.2.20120109144747.03ea4e80@localhost>
Message-ID: <4F0B4BEC.1040904@esilibrary.com>

Hi,

On 01/09/2012 02:54 PM, Paul wrote:
> As far as I can see, they already appear to be non-repeatable (unless I
> modded the default framework in 3.2 and it's been imported into 3.6.) I
> find all four subfields (a, b, c and d) non-repeatable (according to the
> check box) and it doesn't seem to make much difference whether they are
> "ignored" or in tab 0 as no cataloguer will be able to attempt an
> edit|modification.

While the subfields within the field are non-repeatable, the 999 field 
itself is (by default) marked as repeatable.

Regards,

Galen
-- 
Galen Charlton
Director of Support and Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org & 
http://evergreen-ils.org

From tajoli at cilea.it  Mon Jan  9 21:22:56 2012
From: tajoli at cilea.it (tajoli at cilea.it)
Date: Mon, 09 Jan 2012 21:22:56 +0100 (CET)
Subject: [Koha-devel] Repeatable 999? (was Re: deafult for
	biblio.frameworkcode)
In-Reply-To: <5.2.1.1.2.20120109144747.03ea4e80@localhost>
Message-ID: <7fe78954-0146-4226-8479-456dafa77524@esx-revenge>

Hi Paul and all,

>----- Messaggio originale -----
>Da: "Paul" <paul.a at aandc.org>

>As far as I can see, they already appear to be non-repeatable (unless I 
>modded the default framework in 3.2 and it's been imported into 3.6.) 

If you see the definitions of file
installer/data/mysql/en/marcflavour/marc21/mandatory/marc21_framework_DEFAULT.sql
lines 46 - 53:

INSERT INTO `marc_tag_structure` (`tagfield`, `liblibrarian`, `libopac`, `repeatable`, `mandatory`, `authorised_value`, `frameworkcode`) VALUES
 ('999', 'SYSTEM CONTROL NUMBERS (KOHA)', 'SYSTEM CONTROL NUMBERS (KOHA)', 1, 0, '', '');
  
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
('999', 'a', 'Item type [OBSOLETE]', 'Item type [OBSOLETE]', 0, 0, [...]
('999', 'b', 'Koha Dewey Subclass [OBSOLETE]', 'Koha Dewey Subclass [OBSOLETE]', 0, 0, [...]
('999', 'c', 'Koha biblionumber', 'Koha biblionumber', 0, 0, [...]
('999', 'd', 'Koha biblioitemnumber', 'Koha biblioitemnumber', 0, 0, [...] 
 
The result is:
Field 999: repeatable
Subfield 999$a: not repeatable
Subfield 999$b: not repeatable
Subfield 999$c: not repeatable
Subfield 999$d: not repeatable

But it is only the default.
It was so also in 3.2
No problems if you change it.

Bye
Zeno Tajoli
_______________________________________________
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 mdhafen at tech.washk12.org  Mon Jan  9 21:30:31 2012
From: mdhafen at tech.washk12.org (Mike Hafen)
Date: Mon, 9 Jan 2012 13:30:31 -0700
Subject: [Koha-devel] Active borrowers report
In-Reply-To: <CABW43USJpu01F7tSA3DgnCjfygnCns633adRfiHQkvQk5C=4_Q@mail.gmail.com>
References: <CABW43USJpu01F7tSA3DgnCjfygnCns633adRfiHQkvQk5C=4_Q@mail.gmail.com>
Message-ID: <CA+FBf-ED0Gz0MHgVaz+FZPRzQbqmrW5_9j66XyJQ5sRsqFL_5A@mail.gmail.com>

I've seen UNION used to join those two tables in queries.  I'm imaginning
something like:

SELECT YEAR(issuedate), MONTH(issuedate), categorycode, COUNT(DISTINCT
borrowernumber)
FROM (
  SELECT issuedate,categorycode,borrowernumber FROM old_issues
 UNION ALL
  SELECT issuedate,categorycode,borrowernumber FROM issues
 )
LEFT JOIN borrowers USING (borrowernumber)
GROUP BY YEAR(issuedate), MONTH(issuedate), categorycode;

But I'm no database expert, so use this with care.

On Mon, Jan 9, 2012 at 1:12 PM, Cab Vinton <bibliwho at gmail.com> wrote:

> A couple years ago Jesse Weaver came up with this report for active
> borrowers (i.e., patrons checking out materials):
>
>        SELECT YEAR(issuedate), MONTH(issuedate), categorycode,
> COUNT(DISTINCT borrowernumber)
>        FROM old_issues
>        LEFT JOIN borrowers USING (borrowernumber)
>        GROUP BY YEAR(issuedate), MONTH(issuedate), categorycode;
>
> I'm wondering if the caveat he notes is still true:
>
>        Because it uses old_issues, it won't include anything that's still
> checked out; getting
>        around that requires either ugly subqueries or running the report
> with old_issues
>        and issues and manually combining the results.
>
> Is there a relatively easy way to modify the report so it includes
> patrons who may still have items checked out?
>
> Thanks for any assistance!
>
> Cab Vinton, Director
> Sanbornton Public Library
> Sanbornton, NH
>
> "Politeness and consideration for others is like investing pennies and
> getting dollars back." Thomas Sowell
> _______________________________________________
> 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/20120109/540a2da4/attachment-0001.htm>

From gmc at esilibrary.com  Mon Jan  9 21:31:54 2012
From: gmc at esilibrary.com (Galen Charlton)
Date: Mon, 09 Jan 2012 15:31:54 -0500
Subject: [Koha-devel] Active borrowers report
In-Reply-To: <CA+FBf-ED0Gz0MHgVaz+FZPRzQbqmrW5_9j66XyJQ5sRsqFL_5A@mail.gmail.com>
References: <CABW43USJpu01F7tSA3DgnCjfygnCns633adRfiHQkvQk5C=4_Q@mail.gmail.com>
	<CA+FBf-ED0Gz0MHgVaz+FZPRzQbqmrW5_9j66XyJQ5sRsqFL_5A@mail.gmail.com>
Message-ID: <4F0B4EBA.6020807@esilibrary.com>

Hi,

On 01/09/2012 03:30 PM, Mike Hafen wrote:
> I've seen UNION used to join those two tables in queries.  I'm
> imaginning something like:
>
> SELECT YEAR(issuedate), MONTH(issuedate), categorycode, COUNT(DISTINCT
> borrowernumber)
> FROM (
>    SELECT issuedate,categorycode,borrowernumber FROM old_issues
>   UNION ALL
>    SELECT issuedate,categorycode,borrowernumber FROM issues
>   )
> LEFT JOIN borrowers USING (borrowernumber)
> GROUP BY YEAR(issuedate), MONTH(issuedate), categorycode;

A UNION ALL is indeed a valid way to do it.

Regards,

Galen
-- 
Galen Charlton
Director of Support and Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org & 
http://evergreen-ils.org

From mdhafen at tech.washk12.org  Mon Jan  9 21:36:28 2012
From: mdhafen at tech.washk12.org (Mike Hafen)
Date: Mon, 9 Jan 2012 13:36:28 -0700
Subject: [Koha-devel] Active borrowers report
In-Reply-To: <4F0B4EBA.6020807@esilibrary.com>
References: <CABW43USJpu01F7tSA3DgnCjfygnCns633adRfiHQkvQk5C=4_Q@mail.gmail.com>
	<CA+FBf-ED0Gz0MHgVaz+FZPRzQbqmrW5_9j66XyJQ5sRsqFL_5A@mail.gmail.com>
	<4F0B4EBA.6020807@esilibrary.com>
Message-ID: <CA+FBf-GfDFUCZWNaEM5ydsfWvvcRgF5fpwPPAq772g1X6ss8ug@mail.gmail.com>

And now that I've actually tried that query, there are problems with it.
Here is a fixed version:

SELECT YEAR(issuedate), MONTH(issuedate), categorycode, COUNT(DISTINCT
borrowernumber)
FROM (
  SELECT issuedate, borrowernumber FROM old_issues
 UNION ALL
  SELECT issuedate, borrowernumber FROM issues
) AS all_issues
LEFT JOIN borrowers USING (borrowernumber)
GROUP BY YEAR(issuedate), MONTH(issuedate), categorycode

On Mon, Jan 9, 2012 at 1:31 PM, Galen Charlton <gmc at esilibrary.com> wrote:

> Hi,
>
>
> On 01/09/2012 03:30 PM, Mike Hafen wrote:
>
>> I've seen UNION used to join those two tables in queries.  I'm
>> imaginning something like:
>>
>> SELECT YEAR(issuedate), MONTH(issuedate), categorycode, COUNT(DISTINCT
>> borrowernumber)
>> FROM (
>>   SELECT issuedate,categorycode,**borrowernumber FROM old_issues
>>  UNION ALL
>>   SELECT issuedate,categorycode,**borrowernumber FROM issues
>>  )
>> LEFT JOIN borrowers USING (borrowernumber)
>> GROUP BY YEAR(issuedate), MONTH(issuedate), categorycode;
>>
>
> A UNION ALL is indeed a valid way to do it.
>
> Regards,
>
> Galen
> --
> Galen Charlton
> Director of Support and Implementation
> Equinox Software, Inc. / The Open Source Experts
> email:  gmc at esilibrary.com
> direct: +1 770-709-5581
> cell:   +1 404-984-4366
> skype:  gmcharlt
> web:    http://www.esilibrary.com/
> Supporting Koha and Evergreen: http://koha-community.org &
> http://evergreen-ils.org
>
> ______________________________**_________________
> Koha-devel mailing list
> Koha-devel at lists.koha-**community.org<Koha-devel at lists.koha-community.org>
> http://lists.koha-community.**org/cgi-bin/mailman/listinfo/**koha-devel<http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel>
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.**org/ <http://bugs.koha-community.org/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120109/35d32767/attachment.htm>

From bibliwho at gmail.com  Mon Jan  9 21:41:31 2012
From: bibliwho at gmail.com (Cab Vinton)
Date: Mon, 9 Jan 2012 15:41:31 -0500
Subject: [Koha-devel] Active borrowers report
In-Reply-To: <CA+FBf-GfDFUCZWNaEM5ydsfWvvcRgF5fpwPPAq772g1X6ss8ug@mail.gmail.com>
References: <CABW43USJpu01F7tSA3DgnCjfygnCns633adRfiHQkvQk5C=4_Q@mail.gmail.com>
	<CA+FBf-ED0Gz0MHgVaz+FZPRzQbqmrW5_9j66XyJQ5sRsqFL_5A@mail.gmail.com>
	<4F0B4EBA.6020807@esilibrary.com>
	<CA+FBf-GfDFUCZWNaEM5ydsfWvvcRgF5fpwPPAq772g1X6ss8ug@mail.gmail.com>
Message-ID: <CABW43UStz_JoPSW-RLWgp1jY_17-94E92jxvxef5qTpJVS2pmA@mail.gmail.com>

Awesome!

Thank you, Mike -- seems to work perfectly!

Cheers,

Cab Vinton, Director
Sanbornton Public Library
Sanbornton, NH

"Politeness and consideration for others is like investing pennies and
getting dollars back." Thomas Sowell

2012/1/9 Mike Hafen <mdhafen at tech.washk12.org>:
> SELECT YEAR(issuedate), MONTH(issuedate), categorycode, COUNT(DISTINCT
> borrowernumber)
> FROM (
> ? SELECT issuedate, borrowernumber FROM old_issues
> ?UNION ALL
> ? SELECT issuedate, borrowernumber FROM issues
> ) AS all_issues
>
> LEFT JOIN borrowers USING (borrowernumber)
> GROUP BY YEAR(issuedate), MONTH(issuedate), categorycode

From lrea at nekls.org  Mon Jan  9 22:31:24 2012
From: lrea at nekls.org (Liz Rea)
Date: Mon, 9 Jan 2012 15:31:24 -0600
Subject: [Koha-devel] Active borrowers report
In-Reply-To: <CA+FBf-GfDFUCZWNaEM5ydsfWvvcRgF5fpwPPAq772g1X6ss8ug@mail.gmail.com>
References: <CABW43USJpu01F7tSA3DgnCjfygnCns633adRfiHQkvQk5C=4_Q@mail.gmail.com>
	<CA+FBf-ED0Gz0MHgVaz+FZPRzQbqmrW5_9j66XyJQ5sRsqFL_5A@mail.gmail.com>
	<4F0B4EBA.6020807@esilibrary.com>
	<CA+FBf-GfDFUCZWNaEM5ydsfWvvcRgF5fpwPPAq772g1X6ss8ug@mail.gmail.com>
Message-ID: <2939B555-523E-4066-9C21-71B40EEDCB39@nekls.org>

And you know what, that one isn't in the report library so I added it for you. :)

You can see it here: 
http://wiki.koha-community.org/wiki/SQL_Reports_Library#Active_Patrons

Thanks!

Liz Rea
lrea at nekls.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: email_signature.jpeg
Type: image/jpeg
Size: 4862 bytes
Desc: not available
URL: </pipermail/koha-devel/attachments/20120109/0dbbb98c/attachment.jpeg>
-------------- next part --------------


On Jan 9, 2012, at 2:36 PM, Mike Hafen wrote:

> SELECT YEAR(issuedate), MONTH(issuedate), categorycode, COUNT(DISTINCT borrowernumber)
> FROM (
>   SELECT issuedate, borrowernumber FROM old_issues
>  UNION ALL
>   SELECT issuedate, borrowernumber FROM issues
> ) AS all_issues
> LEFT JOIN borrowers USING (borrowernumber)
> GROUP BY YEAR(issuedate), MONTH(issuedate), categorycode


From mdhafen at tech.washk12.org  Mon Jan  9 23:06:57 2012
From: mdhafen at tech.washk12.org (Mike Hafen)
Date: Mon, 9 Jan 2012 15:06:57 -0700
Subject: [Koha-devel] Active borrowers report
In-Reply-To: <2939B555-523E-4066-9C21-71B40EEDCB39@nekls.org>
References: <CABW43USJpu01F7tSA3DgnCjfygnCns633adRfiHQkvQk5C=4_Q@mail.gmail.com>
	<CA+FBf-ED0Gz0MHgVaz+FZPRzQbqmrW5_9j66XyJQ5sRsqFL_5A@mail.gmail.com>
	<4F0B4EBA.6020807@esilibrary.com>
	<CA+FBf-GfDFUCZWNaEM5ydsfWvvcRgF5fpwPPAq772g1X6ss8ug@mail.gmail.com>
	<2939B555-523E-4066-9C21-71B40EEDCB39@nekls.org>
Message-ID: <CA+FBf-Ggs4tr9AC5yfNyb8DOLhK07YO=BN18kEf1SYM3OWMQWQ@mail.gmail.com>

Cool.  Though I would prefer Jesse Weaver get all/joint credit for it.  I
really just changed his sql a bit.

On Mon, Jan 9, 2012 at 2:31 PM, Liz Rea <lrea at nekls.org> wrote:

> And you know what, that one isn't in the report library so I added it for
> you. :)
>
> You can see it here:
> http://wiki.koha-community.org/wiki/SQL_Reports_Library#Active_Patrons
>
> Thanks!
>
> Liz Rea
> lrea at nekls.org
>
>
>
>
> On Jan 9, 2012, at 2:36 PM, Mike Hafen wrote:
>
> > SELECT YEAR(issuedate), MONTH(issuedate), categorycode, COUNT(DISTINCT
> borrowernumber)
> > FROM (
> >   SELECT issuedate, borrowernumber FROM old_issues
> >  UNION ALL
> >   SELECT issuedate, borrowernumber FROM issues
> > ) AS all_issues
> > LEFT JOIN borrowers USING (borrowernumber)
> > GROUP BY YEAR(issuedate), MONTH(issuedate), categorycode
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120109/14af3846/attachment.htm>

From pianohacker at gmail.com  Tue Jan 10 00:20:15 2012
From: pianohacker at gmail.com (Jesse)
Date: Mon, 9 Jan 2012 16:20:15 -0700
Subject: [Koha-devel] Active borrowers report
In-Reply-To: <CA+FBf-Ggs4tr9AC5yfNyb8DOLhK07YO=BN18kEf1SYM3OWMQWQ@mail.gmail.com>
References: <CABW43USJpu01F7tSA3DgnCjfygnCns633adRfiHQkvQk5C=4_Q@mail.gmail.com>
	<CA+FBf-ED0Gz0MHgVaz+FZPRzQbqmrW5_9j66XyJQ5sRsqFL_5A@mail.gmail.com>
	<4F0B4EBA.6020807@esilibrary.com>
	<CA+FBf-GfDFUCZWNaEM5ydsfWvvcRgF5fpwPPAq772g1X6ss8ug@mail.gmail.com>
	<2939B555-523E-4066-9C21-71B40EEDCB39@nekls.org>
	<CA+FBf-Ggs4tr9AC5yfNyb8DOLhK07YO=BN18kEf1SYM3OWMQWQ@mail.gmail.com>
Message-ID: <CAEjTV=97gkZTf6aLhHCs3nqpsyRhA3FYHJ1DShGUkxrEUKYhDA@mail.gmail.com>

Wow, that's an old report. Glad you got some use out of it, and found a way
to make it better!

On the other hand, should we consider promoting the use of the `statistics`
table? Though I've been out of the loop, I think it was easier to design
reports like this around. Spent many frustrating hours and LEFT JOINs
trying to twist the `issues` and `old_issues` tables into the output the
librarians asked for.

2012/1/9 Mike Hafen <mdhafen at tech.washk12.org>

> Cool.  Though I would prefer Jesse Weaver get all/joint credit for it.  I
> really just changed his sql a bit.
>
> On Mon, Jan 9, 2012 at 2:31 PM, Liz Rea <lrea at nekls.org> wrote:
>
>> And you know what, that one isn't in the report library so I added it for
>> you. :)
>>
>> You can see it here:
>> http://wiki.koha-community.org/wiki/SQL_Reports_Library#Active_Patrons
>>
>> Thanks!
>>
>> Liz Rea
>> lrea at nekls.org
>>
>>
>>
>>
>> On Jan 9, 2012, at 2:36 PM, Mike Hafen wrote:
>>
>> > SELECT YEAR(issuedate), MONTH(issuedate), categorycode, COUNT(DISTINCT
>> borrowernumber)
>> > FROM (
>> >   SELECT issuedate, borrowernumber FROM old_issues
>> >  UNION ALL
>> >   SELECT issuedate, borrowernumber FROM issues
>> > ) AS all_issues
>> > LEFT JOIN borrowers USING (borrowernumber)
>> > GROUP BY YEAR(issuedate), MONTH(issuedate), categorycode
>>
>>
>>
>
> _______________________________________________
> 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/
>



-- 
Jesse Weaver
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120109/9ac9f831/attachment-0001.htm>

From jcamins at cpbibliography.com  Tue Jan 10 00:57:12 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Mon, 9 Jan 2012 18:57:12 -0500
Subject: [Koha-devel] Solr integration and kaizen (bug 7430)
Message-ID: <CALVDfQwdkcVGk=gDUYZEEQqHOEkP6rGuf9OUL+FXBhz8A4OnWw@mail.gmail.com>

Good time of day!

In an effort to help myself understand the issues that are facing the solr
integration project, I have written a proof-of-concept patch for bug 7430
that moves ModZebra out of C4::Biblio into Koha::Search::Engine*. Let me
repeat that. This is a proof-of-concept. I may or may not continue working
on it, depending on whether the mood takes me at a moment when I have free
time for playing. However, I wanted to point it out so that people could
look at it, think about it, and maybe discuss it, if anyone had anything
they wanted to discuss. Without further ado, the commit message follows.

This proof-of-concept commit does the following:
* Moves all the functionality from C4::Biblio::ModZebra into a new
  Koha::Search::Engine namespace, breaking it up into Zebra and NoZebra
  classes for the relevant sections.
* Rather than calling ModZebra, callers should now use Koha::Search and
  call AddToIndexQueue() with the same arguments.
* Creates a new Koha::Utils class with GetMarcFromKohaField and GetAuthType
  methods, in an attempt to begin the process of reducing circular
dependencies
* Adds a syspref SearchEngine to specify whether Zebra or NoZebra is to be
  used, based on the setting of NoZebra. This syspref is checked *only*
  in ModZebra replacement code. The NoZebra is still relied upon by *all
other*
  search-related code.

IMPORTANT NOTE: The syspref is added by the atomicupdate in
installer/data/mysql/atomicupdate/bug_7430_add_searchengine_syspref

IMPORTANT NOTE: NoZebra indexing is currently broken due to the lack of a
get_auth_type_location() method that can be used by the
Koha::Search::Engine::NoZebra class.

IMPORTANT NOTE: This patch depends on the patches for bug 7284.

One point on that last important note: the patch for bug 7284 centralizes
calls to GetAuthType, but it has no functional relation to bug 7430, and it
would be easy enough to cherry-pick this patch onto Master by simply
removing the merge conflict, if anyone cared.

Also, possibly the key question: anyone have any ideas on dealing with
get_auth_type_location() so that NoZebra could go back to working as well
as it ever has in recent memory?

Regards,
Jared

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

From jcamins at cpbibliography.com  Wed Jan 11 04:22:26 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Tue, 10 Jan 2012 22:22:26 -0500
Subject: [Koha-devel] link_bibs_to_authorities.pl can corrupt records
In-Reply-To: <5.2.1.1.2.20120106161856.00bea980@localhost>
References: <5.2.1.1.2.20120106111952.00bea128@stormy.ca>
	<CA+95qVSce+C4W8dQaO1SwQZ=+VeaaZitznMAo2g8eWqd8jDzKw@mail.gmail.com>
	<5.2.1.1.2.20120106151732.00bea128@localhost>
	<5.2.1.1.2.20120106161856.00bea980@localhost>
Message-ID: <CALVDfQxvYv6vTSEJVUDQ0HjuWbCjDar-XYQc3+9k9c9dXd4voQ@mail.gmail.com>

Paul (and Koha-devel),

2012/1/6 Paul <paul.a at aandc.org>

> I have successfully use that script to link authorities to biblio records
> after doing a migration. But the way it works is to remove all links and
> recreate.
>
>
> Not sure about the "recreate" bit...
>

Agreed. That's why I'm working on bug 7284.

Incidentally (this is for the whole list), I *always* run anything that is
supposed to make bulk changes for the first time on a test database
(preferred) or using some sort of "test" option. For
link_bibs_to_authorities.pl, that option is --test: "only test the
authority linking and report the results; do not change the bib records."
Is it slow and annoying? Yes. It is better than losing data? Oh my goodness
yes. Having worked on a project where a cowboy decided to run a bulk
modification script without testing first, I can speak with certainty about
that ("Jared, why aren't there any records in the database?" is not
something I ever want to hear again).

Its included for that use case. Jared is working on a much better linking
> script and he gave you the information how to change it.
>
>
> Respectfully, it's included in the "current stable release" with no
> warnings (3.6.1 was "current" when I installed it -- I haven't verified
> 3.6.2.) and Jared's information came after "horses and barn doors."
>

As it happens, you have encountered this problem at the right time. I have
a working replacement linker script that needs testing, if you are so
inclined. In pursuit of better results, I would be willing to host a copy
of your bibliographic and authority databases so that you can look at the
results of the revised linking. Note for the list: THIS OFFER IS OPEN TO
ANYONE, first come, first served. I'd like to test over the next week or
two, so anyone who's interested, let me know and (if I still have testing
slots free) we'll arrange to transfer the files ASAP.

Its not a total screwup script, and it didn't demolish the whole db, I
> think you would find people more willing to help you, in their own free
> time, in their weekends if you didn't come across so aggressive and
> accusatory in your tone.
>
>
You may be glad to know that if bug 5683 were still an issue, your system
would have been completely unusable, rather than simply unlinked.

Regards,
Jared

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

From tajoli at cilea.it  Thu Jan 12 09:55:46 2012
From: tajoli at cilea.it (Zeno Tajoli)
Date: Thu, 12 Jan 2012 09:55:46 +0100
Subject: [Koha-devel] Bugzilla workflow (bug 7245)
Message-ID: <4F0EA012.5040007@cilea.it>

Hi to all,

this questyion is about Bugzilla workflow.
The bug 7245 is fixed, code is updated in HEAD and in 3.6.x

But the status is ASSIGNED and no 'RESOLVED'.

Why ?

Bye
Zeno Tajoli

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

From chris at bigballofwax.co.nz  Thu Jan 12 09:59:16 2012
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Thu, 12 Jan 2012 21:59:16 +1300
Subject: [Koha-devel] Bugzilla workflow (bug 7245)
In-Reply-To: <4F0EA012.5040007@cilea.it>
References: <4F0EA012.5040007@cilea.it>
Message-ID: <CA+95qVSxZ+dCK84JTso3rM9Ng4tDJ3XDzgEMQeuJ6iUKC4vuXg@mail.gmail.com>

On 12 January 2012 21:55, Zeno Tajoli <tajoli at cilea.it> wrote:
> Hi to all,
>
> this questyion is about Bugzilla workflow.
> The bug 7245 is fixed, code is updated in HEAD and in 3.6.x
>
> But the status is ASSIGNED and no 'RESOLVED'.
>
> Why ?
>
Quite simple really, the bug submitter has not tested and marked it resolved.
We are at step 8 of
http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow

(Bug closer: the person who checked that the bug is now fixed. Can be
the reporter, it's preferred that the patch writer is not the closer.)

So if you can confirm it is resolved and fixed, you can mark it so

Chris

From paul.poulain at biblibre.com  Thu Jan 12 10:16:18 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 12 Jan 2012 10:16:18 +0100
Subject: [Koha-devel] Bugzilla workflow (bug 7245)
In-Reply-To: <CA+95qVSxZ+dCK84JTso3rM9Ng4tDJ3XDzgEMQeuJ6iUKC4vuXg@mail.gmail.com>
References: <4F0EA012.5040007@cilea.it>
	<CA+95qVSxZ+dCK84JTso3rM9Ng4tDJ3XDzgEMQeuJ6iUKC4vuXg@mail.gmail.com>
Message-ID: <4F0EA4E2.6010400@biblibre.com>

Le 12/01/2012 09:59, Chris Cormack a ?crit :
> On 12 January 2012 21:55, Zeno Tajoli <tajoli at cilea.it> wrote:
>> Why ?
>>
> Quite simple really, the bug submitter has not tested and marked it resolved.
> We are at step 8 of
> http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow
> 
> (Bug closer: the person who checked that the bug is now fixed. Can be
> the reporter, it's preferred that the patch writer is not the closer.)
> 
> So if you can confirm it is resolved and fixed, you can mark it so
And there are tons of bugs in this status, so if you (zeno) can dedicate
time to this task, you're welcomed ;-)
There is a "Patch pushed" query, that you can add to your footer
(bugzilla > Preferences > saved query > check "Patch pushed"
It shows 437 bugs "pushed but not yet closed"

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

From mjr at phonecoop.coop  Thu Jan 12 16:41:49 2012
From: mjr at phonecoop.coop (MJ Ray)
Date: Thu, 12 Jan 2012 15:41:49 +0000
Subject: [Koha-devel] Bugzilla workflow (bug 7245)
In-Reply-To: <CA+95qVSxZ+dCK84JTso3rM9Ng4tDJ3XDzgEMQeuJ6iUKC4vuXg@mail.gmail.com>
Message-ID: <E1RlMmj-0007Xo-4F@petrol.towers.org.uk>

Chris Cormack <chris at bigballofwax.co.nz>
> Quite simple really, the bug submitter has not tested and marked it resolved.
> We are at step 8 of
> http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow
> 
> (Bug closer: the person who checked that the bug is now fixed. Can be
> the reporter, it's preferred that the patch writer is not the closer.)

One of two things seems a bit confusing there:

 Maybe the "bug closer" is slightly misnamed and should be replaced
by "bug reporter or QA worker" to make it clear who should do this
because I think many of us are used to patch writers closing bugs
in other projects.

 Maybe the task is misdescribed and the patch writer should set it
RESOLVED, then the bug closer sets it to VERIFIED, which would be
more like as described in
http://bugs.koha-community.org/bugzilla3/page.cgi?id=fields.html

Hope that helps,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
http://koha-community.org supporter, web and library systems developer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire (including development) at http://www.software.coop/

From paul.poulain at biblibre.com  Thu Jan 12 16:51:22 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 12 Jan 2012 16:51:22 +0100
Subject: [Koha-devel] Bugzilla workflow (bug 7245)
In-Reply-To: <E1RlMmj-0007Xo-4F@petrol.towers.org.uk>
References: <E1RlMmj-0007Xo-4F@petrol.towers.org.uk>
Message-ID: <4F0F017A.7060806@biblibre.com>

Le 12/01/2012 16:41, MJ Ray a ?crit :
>  Maybe the task is misdescribed and the patch writer should set it
> RESOLVED, then the bug closer sets it to VERIFIED, which would be
> more like as described in
> http://bugs.koha-community.org/bugzilla3/page.cgi?id=fields.html
So the workflow would be:
NEW > Patch sent > signed-off > passed QA > pushed > resolved > fixed
?
I'm OK with it, but i've a question: as the RM set "pushed", couldn't he
move to "resolved" as well, the reporter or someone else saying "fixed".
And the workflow would finally be:
NEW > Patch sent > signed-off > passed QA > resolved (pushed) > fixed

many/most projects work this way I think. Once a patch has been applied,
the problem is resolved from dev point of view. The reporter just
confirm by marking "FIXED".

Question to RMaint = is it worth having one more status I would set, to
tell you, after pushing on master, that you should/must apply the bug
also on stable ?

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

From cnighswonger at foundations.edu  Thu Jan 12 18:00:31 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Thu, 12 Jan 2012 12:00:31 -0500
Subject: [Koha-devel] Bugzilla workflow (bug 7245)
In-Reply-To: <4F0F017A.7060806@biblibre.com>
References: <E1RlMmj-0007Xo-4F@petrol.towers.org.uk>
	<4F0F017A.7060806@biblibre.com>
Message-ID: <CAP3yOom38eAZFrBD-nbwY_sU-oKQ_YK5hyidU0Xfx_zswaSTjw@mail.gmail.com>

On Thu, Jan 12, 2012 at 10:51 AM, Paul Poulain <paul.poulain at biblibre.com>wrote:

>
> Question to RMaint = is it worth having one more status I would set, to
> tell you, after pushing on master, that you should/must apply the bug
> also on stable ?
>
>
That would be fantastic! I'll even buy you lunch sometime for it.

Sorry for being out of the loop for the past few weeks.... my schedule is
super-busy right now.

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

From paul.poulain at biblibre.com  Thu Jan 12 18:29:07 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 12 Jan 2012 18:29:07 +0100
Subject: [Koha-devel] Bugzilla workflow (bug 7245)
In-Reply-To: <CAP3yOom38eAZFrBD-nbwY_sU-oKQ_YK5hyidU0Xfx_zswaSTjw@mail.gmail.com>
References: <E1RlMmj-0007Xo-4F@petrol.towers.org.uk>
	<4F0F017A.7060806@biblibre.com>
	<CAP3yOom38eAZFrBD-nbwY_sU-oKQ_YK5hyidU0Xfx_zswaSTjw@mail.gmail.com>
Message-ID: <4F0F1863.9020202@biblibre.com>

Le 12/01/2012 18:00, Chris Nighswonger a ?crit :
> On Thu, Jan 12, 2012 at 10:51 AM, Paul Poulain
> <paul.poulain at biblibre.com <mailto:paul.poulain at biblibre.com>> wrote:
>     Question to RMaint = is it worth having one more status I would set, to
>     tell you, after pushing on master, that you should/must apply the bug
>     also on stable ?
> That would be fantastic! I'll even buy you lunch sometime for it.
> Sorry for being out of the loop for the past few weeks.... my schedule
> is super-busy right now.
Ian is about to change the workflow next week-end. So Ian => can you add
this as well ?

Chris_n = if you meet ian 1st, then i'm OK if you buy him a lunch
instead of me ;-)
The other option would be to come to the hackfest in Europe in March
(that's a general reminder ;-) Some ppl have expressed the idea to come,
but there are many many chairs that are waiting for you as of today ;-) )


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

From tom at nd.edu  Thu Jan 12 18:39:43 2012
From: tom at nd.edu (Tom Hanstra)
Date: Thu, 12 Jan 2012 12:39:43 -0500
Subject: [Koha-devel] Perl - Files missed on config
Message-ID: <4F0F1ADF.20604@nd.edu>

Koha Developers,

I'm a bit of a lurker on the list and don't do much in the line of 
development.  So, I'm not sure how best to officially get some fixes 
requested.

But each time I install or upgrade a new version of Koha, I consistently 
have to edit a number of files in the koha software because I run a 
different version of perl than the default /usr/bin/perl.  I just 
upgraded one of my instances to 3.6.2 and ran into this again with this 
set of files, which I then have to manually edit:

1029$ find . -type f -exec grep "/usr/bin/perl" {} \; -ls
#!/usr/bin/perl
28955751    4 -rwxr-xr-x   1 root     root         3313 Dec 22 17:55 
./misc/translator/translate
#!/usr/bin/perl
28340370   16 -rw-r--r--   1 root     root         8457 Dec 22 17:55 
./lib/C4/ShelfBrowser.pm
#!/usr/bin/perl
28341122    4 -rwxr-xr-x   1 root     root         3153 Dec 22 17:55 
./bin/maintenance/borrowers-force-messaging-defaults
#!/usr/bin/perl
28341185   16 -rwxr-xr-x   1 root     root         8703 Dec 22 17:55 
./bin/admin/koha-preferences
#!/usr/bin/perl
28337824   12 -rwxr-xr-x   1 root     root         7848 Dec 22 17:55 
./opac/cgi-bin/opac/unapi
#!/usr/bin/perl
5923679    4 -rwxr-xr-x   1 root     root         2775 Dec 22 17:55 
./intranet/cgi-bin/svc/new_bib
#!/usr/bin/perl
5923680    4 -rwxr-xr-x   1 root     root         3255 Dec 22 17:55 
./intranet/cgi-bin/svc/bib
#!/usr/bin/perl
5923681   12 -rwxr-xr-x   1 root     root         4659 Dec 22 17:55 
./intranet/cgi-bin/svc/bib_profile
#!/usr/bin/perl
5923685    4 -rwxr-xr-x   1 root     root         2709 Dec 22 17:55 
./intranet/cgi-bin/svc/config/systempreferences
#!/usr/bin/perl
5923684    4 -rwxr-xr-x   1 root     root         1948 Dec 22 17:55 
./intranet/cgi-bin/svc/authentication
#!/usr/bin/perl
5923910   16 -rwxr-xr-x   1 root     root         9502 Dec 22 17:55 
./intranet/cgi-bin/acqui/pdfformat/layout2pages.pm
#!/usr/bin/perl
5923914   24 -rwxr-xr-x   1 root     root        16999 Dec 22 17:55 
./intranet/cgi-bin/acqui/pdfformat/layout3pages.pm
#!/usr/bin/perl
28948350    4 -rwxr-xr-x   1 root     root         3407 Dec 22 17:55 
./intranet/cgi-bin/reports/itemtypes.plugin
#!/usr/bin/perl
28948413   12 -rwxr-xr-x   1 root     root         7939 Dec 22 17:55 
./intranet/cgi-bin/reports/issues_by_borrower_category.plugin

Is there a (preferably low overhead) way to report these other than the 
way I'm doing by hitting the list?

Thanks,
Tom

-- 

-----------------------------------------------------------------------------
      Tom Hanstra                              Systems Administrator
      University Libraries of Notre Dame       Phone: (574)631-4686
      213 Hesburgh Library                     Email: tom at nd.edu
      Notre Dame, IN  46556

           Time flies like an arrow.  Fruit flies like a banana.
-----------------------------------------------------------------------------


From chris at bigballofwax.co.nz  Thu Jan 12 18:44:50 2012
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Fri, 13 Jan 2012 06:44:50 +1300
Subject: [Koha-devel] Perl - Files missed on config
In-Reply-To: <4F0F1ADF.20604@nd.edu>
References: <4F0F1ADF.20604@nd.edu>
Message-ID: <CA+95qVSgPYQS8bod_Wwy7G9HXoS2b7-K3LzQDYSAUTqHxLemnw@mail.gmail.com>

On 13 January 2012 06:39, Tom Hanstra <tom at nd.edu> wrote:
> Koha Developers,
>
> I'm a bit of a lurker on the list and don't do much in the line of
> development. ?So, I'm not sure how best to officially get some fixes
> requested.

Hi Tom

There are multiple ways to do it.
File a bug at bugs.koha-community.org  and attach a patch fixing it
File a bug at bugs.koha-community.org and pay someone else to write a patch
File a bug at bugs.koha-community.org and wait for someone to have
time to fix it on their own time.

You will notice a common theme here :)

I'd encourage you to file a bug with as much information as you can.

Chris

From nomankazidu at yahoo.com  Fri Jan 13 18:28:23 2012
From: nomankazidu at yahoo.com (kazi)
Date: Fri, 13 Jan 2012 09:28:23 -0800 (PST)
Subject: [Koha-devel] software error
In-Reply-To: <E1Rgcw5-0000fs-0R@petrol.towers.org.uk>
References: <1325131584953-5106744.post@n5.nabble.com>
	<E1Rgcw5-0000fs-0R@petrol.towers.org.uk>
Message-ID: <1326475703708-5143166.post@n5.nabble.com>

Dear Mr. MJ Ray-2,

Thank you for your reply. I've got this error in 3.07.00.007 again here; 

Software error:

Date::Calc::Add_Delta_Days(): not a valid date at
/usr/share/koha/opac/cgi-bin/opac/opac-user.pl line 124.

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

This error only shows when I open staff-client interface as well as opac,
and by clicking my summary option. And when I close staff-client interface,
this problem doesn't show, and never get this type of error. 

It's unpleasant for me to reply with delay.

thank you once again MJ Ray-2

Best regards,
Kazi  

--
View this message in context: http://koha.1045719.n5.nabble.com/software-error-tp5106744p5143166.html
Sent from the Koha-devel mailing list archive at Nabble.com.

From Eric.Begin at inLibro.com  Fri Jan 13 18:41:28 2012
From: Eric.Begin at inLibro.com (=?ISO-8859-1?Q?Eric_B=E9gin?=)
Date: Fri, 13 Jan 2012 12:41:28 -0500
Subject: [Koha-devel] Perl - Files missed on config
In-Reply-To: <4F0F1ADF.20604@nd.edu>
References: <4F0F1ADF.20604@nd.edu>
Message-ID: <4F106CC8.7000506@inLibro.com>

Tom,

What type of modifications do you have to do in those files when you are 
updating your version?

Eric

On 2012-01-12 12:39, Tom Hanstra wrote:
> Koha Developers,
>
> I'm a bit of a lurker on the list and don't do much in the line of 
> development.  So, I'm not sure how best to officially get some fixes 
> requested.
>
> But each time I install or upgrade a new version of Koha, I 
> consistently have to edit a number of files in the koha software 
> because I run a different version of perl than the default 
> /usr/bin/perl.  I just upgraded one of my instances to 3.6.2 and ran 
> into this again with this set of files, which I then have to manually 
> edit:
>
> 1029$ find . -type f -exec grep "/usr/bin/perl" {} \; -ls
> #!/usr/bin/perl
> 28955751    4 -rwxr-xr-x   1 root     root         3313 Dec 22 17:55 
> ./misc/translator/translate
> #!/usr/bin/perl
> 28340370   16 -rw-r--r--   1 root     root         8457 Dec 22 17:55 
> ./lib/C4/ShelfBrowser.pm
> #!/usr/bin/perl
> 28341122    4 -rwxr-xr-x   1 root     root         3153 Dec 22 17:55 
> ./bin/maintenance/borrowers-force-messaging-defaults
> #!/usr/bin/perl
> 28341185   16 -rwxr-xr-x   1 root     root         8703 Dec 22 17:55 
> ./bin/admin/koha-preferences
> #!/usr/bin/perl
> 28337824   12 -rwxr-xr-x   1 root     root         7848 Dec 22 17:55 
> ./opac/cgi-bin/opac/unapi
> #!/usr/bin/perl
> 5923679    4 -rwxr-xr-x   1 root     root         2775 Dec 22 17:55 
> ./intranet/cgi-bin/svc/new_bib
> #!/usr/bin/perl
> 5923680    4 -rwxr-xr-x   1 root     root         3255 Dec 22 17:55 
> ./intranet/cgi-bin/svc/bib
> #!/usr/bin/perl
> 5923681   12 -rwxr-xr-x   1 root     root         4659 Dec 22 17:55 
> ./intranet/cgi-bin/svc/bib_profile
> #!/usr/bin/perl
> 5923685    4 -rwxr-xr-x   1 root     root         2709 Dec 22 17:55 
> ./intranet/cgi-bin/svc/config/systempreferences
> #!/usr/bin/perl
> 5923684    4 -rwxr-xr-x   1 root     root         1948 Dec 22 17:55 
> ./intranet/cgi-bin/svc/authentication
> #!/usr/bin/perl
> 5923910   16 -rwxr-xr-x   1 root     root         9502 Dec 22 17:55 
> ./intranet/cgi-bin/acqui/pdfformat/layout2pages.pm
> #!/usr/bin/perl
> 5923914   24 -rwxr-xr-x   1 root     root        16999 Dec 22 17:55 
> ./intranet/cgi-bin/acqui/pdfformat/layout3pages.pm
> #!/usr/bin/perl
> 28948350    4 -rwxr-xr-x   1 root     root         3407 Dec 22 17:55 
> ./intranet/cgi-bin/reports/itemtypes.plugin
> #!/usr/bin/perl
> 28948413   12 -rwxr-xr-x   1 root     root         7939 Dec 22 17:55 
> ./intranet/cgi-bin/reports/issues_by_borrower_category.plugin
>
> Is there a (preferably low overhead) way to report these other than 
> the way I'm doing by hitting the list?
>
> Thanks,
> Tom
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120113/d9e98e78/attachment.htm>

From mjr at phonecoop.coop  Sat Jan 14 18:23:58 2012
From: mjr at phonecoop.coop (MJ Ray)
Date: Sat, 14 Jan 2012 17:23:58 +0000
Subject: [Koha-devel] Bugzilla workflow (bug 7245)
In-Reply-To: <4F0F017A.7060806@biblibre.com>
Message-ID: <E1Rm7Kg-00058H-Vy@petrol.towers.org.uk>

Paul Poulain <paul.poulain at biblibre.com>
> And the workflow would finally be:
> NEW > Patch sent > signed-off > passed QA > resolved (pushed) > fixed
> 
> many/most projects work this way I think. Once a patch has been applied,
> the problem is resolved from dev point of view. The reporter just
> confirm by marking "FIXED".

I don't mind but I would really like the bugzilla workflow to match
the intended workflow.  It confuses me a bit that we move into the
patch status attribute and the person who sets the final state in
that (the RM, patch pushed) does not change the main status at all...
and I suspect I am not alone if there are many bugs stuck in the
Assigned+Pushed state.

This would have the benefit of making the bugzilla-produced report
tables more useful, too.

A backport-needed status may be a good move for that, too.

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

From mjr at phonecoop.coop  Sat Jan 14 18:26:35 2012
From: mjr at phonecoop.coop (MJ Ray)
Date: Sat, 14 Jan 2012 17:26:35 +0000
Subject: [Koha-devel] software error
In-Reply-To: <1326475703708-5143166.post@n5.nabble.com>
Message-ID: <E1Rm7ND-00059b-OB@petrol.towers.org.uk>

kazi <nomankazidu at yahoo.com>
> Date::Calc::Add_Delta_Days(): not a valid date at
> /usr/share/koha/opac/cgi-bin/opac/opac-user.pl line 124.
> 
> For help, please send mail to the webmaster (webmaster at libtechbd), giving
> this error message and the time and date of the error. 
> 
> This error only shows when I open staff-client interface as well as opac,
> and by clicking my summary option. And when I close staff-client interface,
> this problem doesn't show, and never get this type of error. 

I am sorry but this is not enough information for me to be able to
reproduce this error message.  I hope someone else reading this may
be able to help.

Regrets,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
http://koha-community.org supporter, web and library systems developer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire (including development) at http://www.software.coop/

From ian.walls at bywatersolutions.com  Sun Jan 15 01:52:47 2012
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Sat, 14 Jan 2012 19:52:47 -0500
Subject: [Koha-devel] Making bulk changes to bugs.koha-community.org;
 bug emails will be turned off briefly
Message-ID: <CAE2wdZxoR7W1nPgi6qRwTvrpe1MDXRxfAgdc1OE-Ok_TH_DTLg@mail.gmail.com>

Everyone,


As I mentioned in my previous thread about updating Bugzilla to better make
use of the Status field, I'll be taking bug emails offline for a period of
time while I make bulk changes to the statuses.  This is to prevent
everyone from being horribly spammed.  I will reactivate the emails once
the changes are complete.

I'll try to be on IRC for the duration of this maintenance job, in case
anyone has any emergency questions.

Cheers,


-Ian

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

From ian.walls at bywatersolutions.com  Sun Jan 15 02:28:27 2012
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Sat, 14 Jan 2012 20:28:27 -0500
Subject: [Koha-devel] Making bulk changes to bugs.koha-community.org;
 bug emails will be turned off briefly
In-Reply-To: <CAE2wdZxoR7W1nPgi6qRwTvrpe1MDXRxfAgdc1OE-Ok_TH_DTLg@mail.gmail.com>
References: <CAE2wdZxoR7W1nPgi6qRwTvrpe1MDXRxfAgdc1OE-Ok_TH_DTLg@mail.gmail.com>
Message-ID: <CAE2wdZzpYbX+9AHB9aZk3AueM-nnFSaD13PG0WKqKQWJXsXL0w@mail.gmail.com>

Bulk changes are complete.  Bug emails have been turned back on.  Hopefully
no one's inbox has been flooded.

Summary of changes:

   - Moved 'patch status' values into their new corresponding Status values
      - Note that "patch pushed" is mapped to "Pushed to Master" now
      - Created two new statuses:
      - In Discussion:  for things with deeper ramifications that we need
      to discuss as a community before committing to the codebase
      - Pushed to Stable:  a status to be used by the Release Maintainer to
      indicate that a patch is now in the stable release.  Workflow
should follow
      this from after "Pushed to Master"
   - Created patch status workflows to match, well, our workflow.  You
   can't set a bug report directly to Passed QA unless it's been Signed Off,
   etc.
   - Obsoleted 'patch status' and it's dependency on Importance

Work remaining to be done:

   - Shared reports need to be updated.  Since I'm not the creator of
   these, I cannot edit them for everyone else.  Most of the key ones are owed
   by either Paul P. or Chris C.
   - New reports for other statuses, like "In Discussion", "Pushed to
   Stable" or "Does not apply"
   - Updating community and personal documentation to reflect the new
   change in patch submission paperwork.  I'm hoping that we'll now be able to
   auto-set the Status with git-bz, for example, which will streamline our
   process as developers.

   - Updating bugs that have already been pushed to stable from the
   defauled "Pushed to Master" value (or, better yet, they could be closed...
   hint hint)
   - Restoring lost Importance data on Needs Signoff, Signed Off, Passed QA
   and other statuses.  There is a history link for changes to a bug report,
   available in the right column above the "see also" and "change sponsored?"
   fields, but doing this cleanup will likely need to be manual.


Please let me know if any other complications have arisen because of this
change.  Discussion of additional fields to add can be put into separate
threads, for easy readability.

Cheers,


-Ian

On Sat, Jan 14, 2012 at 7:52 PM, Ian Walls
<ian.walls at bywatersolutions.com>wrote:

> Everyone,
>
>
> As I mentioned in my previous thread about updating Bugzilla to better
> make use of the Status field, I'll be taking bug emails offline for a
> period of time while I make bulk changes to the statuses.  This is to
> prevent everyone from being horribly spammed.  I will reactivate the emails
> once the changes are complete.
>
> I'll try to be on IRC for the duration of this maintenance job, in case
> anyone has any emergency questions.
>
> Cheers,
>
>
> -Ian
>
> --
> Ian Walls
> Lead Development Specialist
> ByWater Solutions
> ALA Midwinter Booth #2048
> Phone # (888) 900-8944
> http://bywatersolutions.com
> ian.walls at bywatersolutions.com
> Twitter: @sekjal
>



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

From chrisc at catalyst.net.nz  Sun Jan 15 02:46:58 2012
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Sun, 15 Jan 2012 14:46:58 +1300
Subject: [Koha-devel] Making bulk changes to bugs.koha-community.org;
 bug emails will be turned off briefly
In-Reply-To: <CAE2wdZzpYbX+9AHB9aZk3AueM-nnFSaD13PG0WKqKQWJXsXL0w@mail.gmail.com>
References: <CAE2wdZxoR7W1nPgi6qRwTvrpe1MDXRxfAgdc1OE-Ok_TH_DTLg@mail.gmail.com>
	<CAE2wdZzpYbX+9AHB9aZk3AueM-nnFSaD13PG0WKqKQWJXsXL0w@mail.gmail.com>
Message-ID: <20120115014658.GT5534@rorohiko.wgtn.cat-it.co.nz>

* Ian Walls (ian.walls at bywatersolutions.com) wrote:
>    Bulk changes are complete.A  Bug emails have been turned back on.A 
>    Hopefully no one's inbox has been flooded.
> 
>    Work remaining to be done:
>      * Shared reports need to be updated.A  Since I'm not the creator of
>        these, I cannot edit them for everyone else.A  Most of the key ones
>        are owed by either Paul P. or Chris C.

I have updated the existing ones, new ones still need to be made for
any not in the footer now

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/20120115/e5b8050a/attachment.pgp>

From jcamins at cpbibliography.com  Sun Jan 15 14:52:59 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Sun, 15 Jan 2012 08:52:59 -0500
Subject: [Koha-devel] Making bulk changes to bugs.koha-community.org;
 bug emails will be turned off briefly
In-Reply-To: <20120115014658.GT5534@rorohiko.wgtn.cat-it.co.nz>
References: <CAE2wdZxoR7W1nPgi6qRwTvrpe1MDXRxfAgdc1OE-Ok_TH_DTLg@mail.gmail.com>
	<CAE2wdZzpYbX+9AHB9aZk3AueM-nnFSaD13PG0WKqKQWJXsXL0w@mail.gmail.com>
	<20120115014658.GT5534@rorohiko.wgtn.cat-it.co.nz>
Message-ID: <CALVDfQyCUmzRXv5aZ6gRXQKh=4RkO+KgLvJr=6iy3zKT92FZ9w@mail.gmail.com>

Who has the permissions to change the "My bugs" search? Bugs with the new
statuses do not appear in the "My bugs" saved search.

Regards,
Jared

2012/1/14 Chris Cormack <chrisc at catalyst.net.nz>

> * Ian Walls (ian.walls at bywatersolutions.com) wrote:
> >    Bulk changes are complete.A  Bug emails have been turned back on.A
> >    Hopefully no one's inbox has been flooded.
> >
> >    Work remaining to be done:
> >      * Shared reports need to be updated.A  Since I'm not the creator of
> >        these, I cannot edit them for everyone else.A  Most of the key
> ones
> >        are owed by either Paul P. or Chris C.
>
> I have updated the existing ones, new ones still need to be made for
> any not in the footer now
>
> Chris
>
> --
> Chris Cormack
> Catalyst IT Ltd.
> +64 4 803 2238
> PO Box 11-053, Manners St, Wellington 6142, New Zealand
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



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

From M.de.Rooy at rijksmuseum.nl  Mon Jan 16 10:30:56 2012
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Mon, 16 Jan 2012 09:30:56 +0000
Subject: [Koha-devel] Making bulk changes to bugs.koha-community.org;
 bug emails will be turned off briefly
In-Reply-To: <CAE2wdZzpYbX+9AHB9aZk3AueM-nnFSaD13PG0WKqKQWJXsXL0w@mail.gmail.com>
References: <CAE2wdZxoR7W1nPgi6qRwTvrpe1MDXRxfAgdc1OE-Ok_TH_DTLg@mail.gmail.com>,
	<CAE2wdZzpYbX+9AHB9aZk3AueM-nnFSaD13PG0WKqKQWJXsXL0w@mail.gmail.com>
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3101E64499@S-MAIL-1A.rijksmuseum.intra>

First, thanks for making the changes.



About: Created patch status workflows to match our workflow: Could you add Passed QA to the statuses listed at Needs signoff? Sometimes the QA team can do this in one time. Similarly, ASSIGNED could be handy at Needs signoff as well as at Signed off.



Changed: Since all reports changed, we lost the last change date (which I [mis]used heavily..)  Would it be possible to add a column on Bugzilla for the date associated with the last attachment ? I think it would be very useful for bug wranglers and QAers. This field is displayed now under each attachment in the Attachments block.



What did you think of "Needs additional signoff" by the way?



Marcel



________________________________
Van: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] namens Ian Walls [ian.walls at bywatersolutions.com]
Verzonden: zondag 15 januari 2012 2:28
To: koha-devel at lists.koha-community.org
Onderwerp: Re: [Koha-devel] Making bulk changes to bugs.koha-community.org; bug emails will be turned off briefly

Bulk changes are complete.  Bug emails have been turned back on.  Hopefully no one's inbox has been flooded.

Summary of changes:

  *   Moved 'patch status' values into their new corresponding Status values
     *   Note that "patch pushed" is mapped to "Pushed to Master" now
  *   Created two new statuses:
     *   In Discussion:  for things with deeper ramifications that we need to discuss as a community before committing to the codebase
     *   Pushed to Stable:  a status to be used by the Release Maintainer to indicate that a patch is now in the stable release.  Workflow should follow this from after "Pushed to Master"
  *   Created patch status workflows to match, well, our workflow.  You can't set a bug report directly to Passed QA unless it's been Signed Off, etc.
  *   Obsoleted 'patch status' and it's dependency on Importance

Work remaining to be done:

  *   Shared reports need to be updated.  Since I'm not the creator of these, I cannot edit them for everyone else.  Most of the key ones are owed by either Paul P. or Chris C.
  *   New reports for other statuses, like "In Discussion", "Pushed to Stable" or "Does not apply"
  *   Updating community and personal documentation to reflect the new change in patch submission paperwork.  I'm hoping that we'll now be able to auto-set the Status with git-bz, for example, which will streamline our process as developers.

  *   Updating bugs that have already been pushed to stable from the defauled "Pushed to Master" value (or, better yet, they could be closed... hint hint)
  *   Restoring lost Importance data on Needs Signoff, Signed Off, Passed QA and other statuses.  There is a history link for changes to a bug report, available in the right column above the "see also" and "change sponsored?" fields, but doing this cleanup will likely need to be manual.

Please let me know if any other complications have arisen because of this change.  Discussion of additional fields to add can be put into separate threads, for easy readability.

Cheers,


-Ian

On Sat, Jan 14, 2012 at 7:52 PM, Ian Walls <ian.walls at bywatersolutions.com<mailto:ian.walls at bywatersolutions.com>> wrote:
Everyone,


As I mentioned in my previous thread about updating Bugzilla to better make use of the Status field, I'll be taking bug emails offline for a period of time while I make bulk changes to the statuses.  This is to prevent everyone from being horribly spammed.  I will reactivate the emails once the changes are complete.

I'll try to be on IRC for the duration of this maintenance job, in case anyone has any emergency questions.

Cheers,


-Ian

--
Ian Walls
Lead Development Specialist
ByWater Solutions
ALA Midwinter Booth #2048
Phone # (888) 900-8944<tel:%28888%29%20900-8944>
http://bywatersolutions.com
ian.walls at bywatersolutions.com<mailto:ian.walls at bywatersolutions.com>
Twitter: @sekjal



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

From info at AandC.org  Fri Jan  6 21:48:02 2012
From: info at AandC.org (Archives and Collections Society)
Date: Fri, 06 Jan 2012 15:48:02 -0500
Subject: [Koha-devel] link_bibs_to_authorities.pl can corrupt  records
In-Reply-To: <CAE2wdZynrJ_u=sjOoa-ou=xC7NjPgxvfWtuMjiXbsiDFNfaj2Q@mail.g
	mail.com>
References: <CA+95qVSce+C4W8dQaO1SwQZ=+VeaaZitznMAo2g8eWqd8jDzKw@mail.gmail.com>
	<5.2.1.1.2.20120106111952.00bea128@stormy.ca>
	<CA+95qVSce+C4W8dQaO1SwQZ=+VeaaZitznMAo2g8eWqd8jDzKw@mail.gmail.com>
Message-ID: <5.2.1.1.2.20120106151732.00bea128@localhost>

At 03:02 PM 1/6/2012 -0500, Ian Walls wrote:
>Paul,
>The <http://link_bibs_to_authorities.pl>link_bibs_to_authorities.pl script 
>is hardcoded to ALWAYS erase manual links.?  I'm not sure what the 
>reasoning is behind that.?  But, every time you run it, any link you've 
>done manually that the script can't automatically figure out will be 
>removed.?  Nature of the beast (for now, at least).

What is "any link you've done manually"?, please.  More than 90% of our 
input is Z39.50 and "default" item cataloguing.

OK - a total screw-up that is included without any warning whatsoever in 
the standard distribution of 3.6.1 ???  From the bug report 
<http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5683>

Chris Cormack 2011-06-01 21:13:23 UTC
Pushed to master

Jared Camins-Esakov 2011-07-08 14:37:02 UTC
Seems to be working now. Closing.

If it's "nature of the beast" why isn't the "beast" mentioned 
somewhere?  What on earth is the reason for this .pl to be included in any 
distribution?

More...
>2012/1/6 Chris Cormack 
><<mailto:chris at bigballofwax.co.nz>chris at bigballofwax.co.nz>
>Im assuming you did this on your testing/staging server right?
>Id restore that from backup, then try applying the patch and see if you 
>get better behaviour.
>If so, then do it on your production machine.

what "patch"???

And yes -- I can restore from a previous sqldump, and only lose +/- 100 
biblios.   We're in pre-production and when we got the zebra indexing 
working properly, I told our volunteers to start inputting to 3.6.1 *only* 
(not duplicate on 3.2) so that I could look into any difficulties they 
experienced as cataloguers.

I had no way at all of knowing that a pl script included in the "latest 
stable distribution" could possibly demolish the whole db.

Again, what "patch" and where do I find it?

Might I suggest that someone re-opens the bug (I have attempted to annotate 
it) and removes this dangerous script from public distribution (or at least 
includes a very visible warning.)

Best - Paul


>Chris
>On 7 Jan 2012 08:47, "Paul" <<mailto:paul.a at aandc.org>paul.a at aandc.org> wrote:
>Bug 5683 (<http://link_bibs_to_authorities.pl>link_bibs_to_authorities.pl 
>can corrupt records) was signed off some months ago, but is perhaps a 
>little too cryptic for me to follow in detail. ? Can someone help? As far 
>as I can see, without remedial action, this is catastrophic.
>
>Following difficulties we have had migrating 3.2 to 3.6.1, someone on the 
>users mailing list suggested we should run 
><http://link_bibs_to_authorities.pl>link_bibs_to_authorities.pl -- (db has 
>~10k authorities and ~15k biblios) -- so I did just that, and have 
>APPARENTLY DEMOLISHED *EVERY* LINK IN THE DB. ? From my notes:
>
>paul at nelson:/usr/share/koha$ 
>./bin/<http://link_bibs_to_authorities.pl>link_bibs_to_authorities.pl
>
>Bib authority heading linking report
>------------------------------------
>Number of bibs checked: ?  ?  ?  14911
>Number of bibs modified: ?  ?  ? 14886
>Number of bibs with errors: ?  0
>
>but - the staff interface no longer correctly finds authorities !!!
>
>[1] Manually link (staff client) auth "Lubbock" to bib "Arctic Whalers" -- 
>now linked, 35 other Lubbock bibs not linked. ? Is this a question of 
>zebra re-indexing?
>
>So: ? KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib 
>./bin/migration_tools/<http://rebuild_zebra.pl>rebuild_zebra.pl -a -r -v
>and ? KOHA_CONF=/etc/koha/koha-conf.xml PERL5LIB=/usr/share/koha/lib 
>./bin/migration_tools/<http://rebuild_zebra.pl>rebuild_zebra.pl -b -r -v -x
>
>koha at nelson:/usr/share/koha$ 
>./bin/<http://link_bibs_to_authorities.pl>link_bibs_to_authorities.pl
>... processed 100 records
>/ ... /
>... processed 14900 records
>
>Bib authority heading linking report
>------------------------------------
>Number of bibs checked: ?  ?  ?  14911
>Number of bibs modified: ?  ?  ? 1
>Number of bibs with errors: ?  0
>koha at nelson:/usr/share/koha$
>
>All this did was to *un-link" the bib/auth link that I had manually 
>entered at [1] above. Could someone involved with signing off bug 5683 
>please explain why link==unlink?
>
>Help - please.
>
>Paul
>
>_______________________________________________
>Koha-devel mailing list
><mailto:Koha-devel at lists.koha-community.org>Koha-devel at lists.koha-community.org
>http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>website : <http://www.koha-community.org/>http://www.koha-community.org/
>git : <http://git.koha-community.org/>http://git.koha-community.org/
>bugs : <http://bugs.koha-community.org/>http://bugs.koha-community.org/
>
>
>_______________________________________________
>Koha-devel mailing list
><mailto:Koha-devel at lists.koha-community.org>Koha-devel at lists.koha-community.org
>http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>website : <http://www.koha-community.org/>http://www.koha-community.org/
>git : <http://git.koha-community.org/>http://git.koha-community.org/
>bugs : <http://bugs.koha-community.org/>http://bugs.koha-community.org/
>
>
>
>
>--
>Ian Walls
>Lead Development Specialist
>ByWater Solutions
>ALA Midwinter Booth #2048
>Phone # (888) 900-8944
><http://bywatersolutions.com>http://bywatersolutions.com
><mailto:ian.walls at bywatersolutions.com>ian.walls at bywatersolutions.com
>Twitter: @sekjal
>_______________________________________________
>Koha-devel mailing list
>Koha-devel at lists.koha-community.org
>http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>website : http://www.koha-community.org/
>git : http://git.koha-community.org/
>bugs : http://bugs.koha-community.org/

---
Archives and Collections (ACS) Society
205, Main Street, Picton, Ontario, K0K 2T0, Canada
http://www.AandC.org
Canadian Charitable Organization 88721 9921 RR0001
Dedicated to maritime conservation and education. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120106/f9528d00/attachment-0001.htm>

From sales at bywatersolutions.com  Mon Jan  9 13:53:36 2012
From: sales at bywatersolutions.com (Nathan Curulla)
Date: Mon, 9 Jan 2012 07:53:36 -0500
Subject: [Koha-devel] Position Open with ByWater Solutions
Message-ID: <7156A264-7529-41C5-B2A6-AA439962272C@bywatersolutions.com>

Greetings!

We are currently seeking an individual to fulfill a Development Specialist role with ByWater Solutions. The candidate must be self motivated and comfortable with working from home. The core responsibilities of this position will include:
Determination of the root of support ticket issues and resolving the problem
Identification and resolution of bugs within development projects
Creation of bug reports and patches, and submittal of these fixes to the Koha community
Determination of the technical requirements needed to get the end goal the client expects from a development project
Identify and resolve multiple recurring issues, and creating a solution that will fix all issues simultaneously. 
Required skills:
Perl experience, including working with Modules and Object Oriented Perl
Extensive experience with Debian Linux command line operations
MySQL
XHTML/CSS
Git version control
knowledge of MARC21
Library/Library Software experience 
Excellent communication skills
Excellent problem solving skills
Commitment to open source
Comfortable working from home
Preferred:
Knowledge of the Koha open source ILS 
MLIS/MIS/MLS from ALA accredited library school
5+ years library experience
experience with:
Indexdata's Zebra
Selenium
Bugzilla
Postfix/exim4 or other MTAs
Template Toolkit
JQuery
HTML5 and CSS3
NYTProf
Please let us know if you have any questions regarding this position, or if you would like to schedule an interview, and we will get back to you directly. Thank you very much and have a great day!

All the best,

-Nate


> Nathan A. Curulla
> Executive Vice President
> ByWater Solutions
> VISIT US AT ALA MIDWINTER BOOTH # 2048
> Support and Consulting for Open Source Software
> Headquarters: Santa Barbara, CA.
> Office: West Haven, CT.
> Phone/Fax # (888) 900-8944 xt 2
> Cell # (203) 685-7207
> http://bywatersolutions.com
> nate at bywatersolutions.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120109/56afc9b0/attachment.htm>

From paul.poulain at biblibre.com  Mon Jan 16 13:55:11 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Mon, 16 Jan 2012 13:55:11 +0100
Subject: [Koha-devel] Making bulk changes to bugs.koha-community.org;
 bug emails will be turned off briefly
In-Reply-To: <CAE2wdZzpYbX+9AHB9aZk3AueM-nnFSaD13PG0WKqKQWJXsXL0w@mail.gmail.com>
References: <CAE2wdZxoR7W1nPgi6qRwTvrpe1MDXRxfAgdc1OE-Ok_TH_DTLg@mail.gmail.com>
	<CAE2wdZzpYbX+9AHB9aZk3AueM-nnFSaD13PG0WKqKQWJXsXL0w@mail.gmail.com>
Message-ID: <4F141E2F.2030307@biblibre.com>

Le 15/01/2012 02:28, Ian Walls a ?crit :
>       o Pushed to Stable:  a status to be used by the Release Maintainer
>         to indicate that a patch is now in the stable release.  Workflow
>         should follow this from after "Pushed to Master"
For more complete information:
* when I push, i'll set "Pushed to master". If the patch does not have
to be pushed to 3.6, (ie: an ENH for 3.8), i'll set version to rel_3_8.
If the RMaint should deal with it, i'll set version to rel_3_6 (if it's
not already the case)

Reminder: rel_3_8 version is, for instance, used only by me. If you've
something to say against master, then set version=master.
(when 3.8 will be released though, everyone will be encouraged to use
rel_3_8, of course)

>   * Obsoleted 'patch status' and it's dependency on Importance
(it's not importance, it's priority)

So, if you want something to be on top of our list, you can set Priority
to 1. I often recieve pm from ppl asking for QA or pushing of bug XXXX.
Please don't use pm now, but priority !!!
I'll use it too to set a low priority on what i'll investigate on the
bottom of my pile.
Note that I also use the last modification date as a sorter, to avoid
having a bug staying "forever" in the bottom of the pile. low priority
does not mean that I don't care !!! (and I hope it's the same thing for
others !)

>   * Shared reports need to be updated.  Since I'm not the creator of
>     these, I cannot edit them for everyone else.  Most of the key ones
>     are owed by either Paul P. or Chris C.
done for those i'm the author of.

>   * New reports for other statuses, like "In Discussion",
done
> "Pushed to
>     Stable" or "Does not apply"
I think it's something that is for the RMaint mainly. I haven't made it
myself.
-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From M.de.Rooy at rijksmuseum.nl  Mon Jan 16 14:29:26 2012
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Mon, 16 Jan 2012 13:29:26 +0000
Subject: [Koha-devel] Bugzilla
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3101E6A923@S-MAIL-1A.rijksmuseum.intra>

Hi all,

I personally would like to have a wider Status column in Bugzilla.

Now I have to know that  e.g. "Patc"  means Patch does not apply.
The other terms like Need, Sign (meaning Signed off), Pass, etc. are somewhat cryptical too..

Is that possible?

Regards,

Marcel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120116/1bdebebc/attachment.htm>

From paul.poulain at biblibre.com  Mon Jan 16 14:42:29 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Mon, 16 Jan 2012 14:42:29 +0100
Subject: [Koha-devel] Making bulk changes to bugs.koha-community.org;
 bug emails will be turned off briefly
In-Reply-To: <20120115014658.GT5534@rorohiko.wgtn.cat-it.co.nz>
References: <CAE2wdZxoR7W1nPgi6qRwTvrpe1MDXRxfAgdc1OE-Ok_TH_DTLg@mail.gmail.com>
	<CAE2wdZzpYbX+9AHB9aZk3AueM-nnFSaD13PG0WKqKQWJXsXL0w@mail.gmail.com>
	<20120115014658.GT5534@rorohiko.wgtn.cat-it.co.nz>
Message-ID: <4F142945.8030408@biblibre.com>

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

Le 15/01/2012 02:46, Chris Cormack a ?crit :
> * Ian Walls (ian.walls at bywatersolutions.com) wrote:
>> Bulk changes are complete.A  Bug emails have been turned back
>> on.A Hopefully no one's inbox has been flooded.
>> 
>> Work remaining to be done: * Shared reports need to be updated.A
>> Since I'm not the creator of these, I cannot edit them for
>> everyone else.A  Most of the key ones are owed by either Paul P.
>> or Chris C.
> 
> I have updated the existing ones, new ones still need to be made
> for any not in the footer now
Chris, the passed QA one still has "priority=patch sent" in it, could
you fix it ?
You also haven't updated at all the "no status" query. I suspect it
can be removed.


- -- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPFClEAAoJEK81SonuhyGo7TQIAL6jyyBr9pCfzkkP+elphiyV
9uMh26r3MIDgssooEv4C/uIj1907W7MW7ujQCZgox7CeBpjsx6Bvo3H86HFZBF05
RCDZMUJTKIrLCkRvOUE0TygBc//HSrF/js49T7X8XHRtH11qVlIJxzCuhU60Og4B
GA7UHhobC3C0rZExqPnU3m/sbHjj76nuTLehKoJf9KaibmMW7CKGIrKwA9ZVKKYU
TZmEVrBITUcm9c5hBfENnikfxNHu+22E8dFvTAshNkatPgByLXboCKRiThmkcTg1
uw8ww3KwM5i6SRFX5qPd+/uUYoAvt0hEu3JRDwkhJPrZdqMw8LGNSHVVosdIUO0=
=f1rH
-----END PGP SIGNATURE-----

From M.de.Rooy at rijksmuseum.nl  Mon Jan 16 14:49:30 2012
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Mon, 16 Jan 2012 13:49:30 +0000
Subject: [Koha-devel] Making bulk changes to bugs.koha-community.org;
 bug emails will be turned off briefly
In-Reply-To: <4F142945.8030408@biblibre.com>
References: <CAE2wdZxoR7W1nPgi6qRwTvrpe1MDXRxfAgdc1OE-Ok_TH_DTLg@mail.gmail.com>
	<CAE2wdZzpYbX+9AHB9aZk3AueM-nnFSaD13PG0WKqKQWJXsXL0w@mail.gmail.com>
	<20120115014658.GT5534@rorohiko.wgtn.cat-it.co.nz>
	<4F142945.8030408@biblibre.com>
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3101E6A982@S-MAIL-1A.rijksmuseum.intra>

Same for No status..

-----Oorspronkelijk bericht-----
Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Paul Poulain
Verzonden: maandag 16 januari 2012 14:42
Aan: koha-devel at lists.koha-community.org
Onderwerp: Re: [Koha-devel] Making bulk changes to bugs.koha-community.org; bug emails will be turned off briefly

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

Le 15/01/2012 02:46, Chris Cormack a ?crit :
> * Ian Walls (ian.walls at bywatersolutions.com) wrote:
>> Bulk changes are complete.A  Bug emails have been turned back on.A 
>> Hopefully no one's inbox has been flooded.
>> 
>> Work remaining to be done: * Shared reports need to be updated.A 
>> Since I'm not the creator of these, I cannot edit them for everyone 
>> else.A  Most of the key ones are owed by either Paul P.
>> or Chris C.
> 
> I have updated the existing ones, new ones still need to be made for 
> any not in the footer now
Chris, the passed QA one still has "priority=patch sent" in it, could you fix it ?
You also haven't updated at all the "no status" query. I suspect it can be removed.


- --
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPFClEAAoJEK81SonuhyGo7TQIAL6jyyBr9pCfzkkP+elphiyV
9uMh26r3MIDgssooEv4C/uIj1907W7MW7ujQCZgox7CeBpjsx6Bvo3H86HFZBF05
RCDZMUJTKIrLCkRvOUE0TygBc//HSrF/js49T7X8XHRtH11qVlIJxzCuhU60Og4B
GA7UHhobC3C0rZExqPnU3m/sbHjj76nuTLehKoJf9KaibmMW7CKGIrKwA9ZVKKYU
TZmEVrBITUcm9c5hBfENnikfxNHu+22E8dFvTAshNkatPgByLXboCKRiThmkcTg1
uw8ww3KwM5i6SRFX5qPd+/uUYoAvt0hEu3JRDwkhJPrZdqMw8LGNSHVVosdIUO0=
=f1rH
-----END PGP SIGNATURE-----
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/

From paul.poulain at biblibre.com  Mon Jan 16 14:49:39 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Mon, 16 Jan 2012 14:49:39 +0100
Subject: [Koha-devel] Bugzilla
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA3101E6A923@S-MAIL-1A.rijksmuseum.intra>
References: <809BE39CD64BFD4EB9036172EBCCFA3101E6A923@S-MAIL-1A.rijksmuseum.intra>
Message-ID: <4F142AF3.9020404@biblibre.com>

Le 16/01/2012 14:29, Marcel de Rooy a ?crit :
> Hi all,
> 
>  
> 
> I personally would like to have a wider Status column in Bugzilla.
I also like to change that. I've digged in bugzilla admin, and could not
find how to change this.

> Now I have to know that  e.g. ?Patc?  means Patch does not apply.
at the very least, we can use understandable codes like "DNA" for Does
Not apply,...

If someone knows how to change, feel free to say. Otherwise i'll
investigate the code on 4 letters idea.

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

From ian.walls at bywatersolutions.com  Mon Jan 16 15:00:50 2012
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Mon, 16 Jan 2012 09:00:50 -0500
Subject: [Koha-devel] Bugzilla
In-Reply-To: <4F142AF3.9020404@biblibre.com>
References: <809BE39CD64BFD4EB9036172EBCCFA3101E6A923@S-MAIL-1A.rijksmuseum.intra>
	<4F142AF3.9020404@biblibre.com>
Message-ID: <CAE2wdZwyQwdAqviCeD+L_eg9QM2AVrDRue072AuQg-6wwhy-Bw@mail.gmail.com>

I don't believe this is something you can edit in administration; you have
to set it directly in the template.  This link has some information on
that:
http://groups.google.com/group/mozilla.support.bugzilla/browse_thread/thread/8acead76b18c224a?pli=1


-Ian

On Mon, Jan 16, 2012 at 8:49 AM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Le 16/01/2012 14:29, Marcel de Rooy a ?crit :
> > Hi all,
> >
> >
> >
> > I personally would like to have a wider Status column in Bugzilla.
> I also like to change that. I've digged in bugzilla admin, and could not
> find how to change this.
>
> > Now I have to know that  e.g. ?Patc?  means Patch does not apply.
> at the very least, we can use understandable codes like "DNA" for Does
> Not apply,...
>
> If someone knows how to change, feel free to say. Otherwise i'll
> investigate the code on 4 letters idea.
>
> --
> Paul POULAIN
> http://www.biblibre.com
> Expert en Logiciels Libres pour l'info-doc
> Tel : (33) 4 91 81 35 08
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



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

From paul.poulain at biblibre.com  Mon Jan 16 15:16:33 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Mon, 16 Jan 2012 15:16:33 +0100
Subject: [Koha-devel] Missing possibilities in bugzilla status
Message-ID: <4F143141.8080408@biblibre.com>

As you've read, Ian has updated the workflow to add some dependancies in
status (ie: you can't jump from assigned to patch pushed, for example)

I've found that a usefull possibility was missing: we couldn't go back
to "ASSIGNED" once we've moved forward.
I've updated the workflow to re-enable this possibility.

In some cases, like bug 7143, once a patch has been pushed, we just want
to go back to assigned because another patch may have to be submitted,
the 7143 is an omnibus.

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

From gmc at esilibrary.com  Mon Jan 16 15:40:27 2012
From: gmc at esilibrary.com (Galen Charlton)
Date: Mon, 16 Jan 2012 09:40:27 -0500
Subject: [Koha-devel] Bugzilla
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA3101E6A923@S-MAIL-1A.rijksmuseum.intra>
References: <809BE39CD64BFD4EB9036172EBCCFA3101E6A923@S-MAIL-1A.rijksmuseum.intra>
Message-ID: <4F1436DB.4030304@esilibrary.com>

Hi Marcel,

On 01/16/2012 08:29 AM, Marcel de Rooy wrote:
> I personally would like to have a wider Status column in Bugzilla.

It looks like somebody has gone ahead and made the template change, at 
lest for the bug display page.  Can you confirm that it's now looking wider?

Thanks,

Galen
-- 
Galen Charlton
Director of Support and Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org & 
http://evergreen-ils.org

From alen at irb.hr  Mon Jan 16 16:57:17 2012
From: alen at irb.hr (Alen Vodopijevec)
Date: Mon, 16 Jan 2012 16:57:17 +0100
Subject: [Koha-devel] Fwd: Koha 3.4.7. // additem.pl
In-Reply-To: <CAECksMwzqpjjU2xKnnqzG5ajJ0jL8LjdyjO2RtynfsMm68kkDA@mail.gmail.com>
References: <CAECksMwzqpjjU2xKnnqzG5ajJ0jL8LjdyjO2RtynfsMm68kkDA@mail.gmail.com>
Message-ID: <CAECksMzzn9scJ5H9nVgxuHwbNUPbKXtOt50KfPrBBz0YGod-gQ@mail.gmail.com>

Hi all!

I suspect that changes in cataloguing/additem.pl caused problem with
visibility of other fields on the form that have "hidden" value other
then "0" (Marc bib framework). Please see detailed description sent on
Koha users list below.

Change that caused it:
http://git.koha-community.org/gitweb/?p=koha.git;a=blobdiff;f=cataloguing/additem.pl;h=4442ed328acdd24c79782eb057517f9fe78926ea;hp=6229f0c52715a6c007ca51301f057708a40372ed;hb=4770555855930e45eeaedd1e25a9a39af0861604;hpb=41928b088075a5da9bffb19edf906e94aa84466f



---------- Forwarded message ----------

Hi!

We have a strange behaviour on test upgrade 3.4.4 -> 3.4.7. with
adding an item (additem.pl)

Select options for all fields that have value >0 (2 or 4 for example)
for "hidden" variable in subfield constraints in MARC bibliographic
framework are not shown on Additem form. I'm not sure if this is a
feature or bug.

The only thing that I can see is an addition at around line 203 of additem.pl:

? ? ? ? ? ?if ($subfieldlib->{'hidden'}) {
? ? ? ? ? ? ? ?$subfield_data{marc_value} = qq(<input type="hidden"
$attributes /> $authorised_lib{$value});
? ? ? ? ? ?}
? ? ? ? ? ?else {
? ? ? ? ? ? ? ?$subfield_data{marc_value} =CGI::scrolling_list(
# FIXME: factor out scrolling_list
? ? ? ? ? ? ? ? ? ?-name ? ? => "field_value",
? ? ? ? ? ? ? ? ? ?-values ? => \@authorised_values,
? ? ? ? ? ? ? ? ? ?-default ?=> $value,
? ? ? ? ? ? ? ? ? ?-labels ? => \%authorised_lib,
? ? ? ? ? ? ? ? ? ?-override => 1,
? ? ? ? ? ? ? ? ? ?-size ? ? => 1,
? ? ? ? ? ? ? ? ? ?-multiple => 0,
? ? ? ? ? ? ? ? ? ?-tabindex => 1,
? ? ? ? ? ? ? ? ? ?-id ? ? ? =>
"tag_".$tag."_subfield_".$subfieldtag."_".$index_subfield,
? ? ? ? ? ? ? ? ? ?-class ? ?=> "input_marceditor",
? ? ? ? ? ? ? ?);
? ? ? ? ? ?}

If I remove the first IF statement or if I set "hidden" to "0" in MARC
bibliographic framework settings for that particular subfield, select
options are shown.

We have a same issue with 3.6.2 testing Koha. Any suggestions are welcome :).

regards,
alen

--
Alen Vodopijevec (alen at irb.hr)
Library, Rudjer Boskovic Institute
tel.: +385 1 456 0954 (x1293) gsm: +385 98 584 045
http://lib.irb.hr
http://katalog.irb.hr

From M.de.Rooy at rijksmuseum.nl  Mon Jan 16 18:35:53 2012
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Mon, 16 Jan 2012 17:35:53 +0000
Subject: [Koha-devel] Bugzilla
In-Reply-To: <4F1436DB.4030304@esilibrary.com>
References: <809BE39CD64BFD4EB9036172EBCCFA3101E6A923@S-MAIL-1A.rijksmuseum.intra>,
	<4F1436DB.4030304@esilibrary.com>
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA3101E6AACA@S-MAIL-1A.rijksmuseum.intra>

Hi Galen,
Unfortunately. but no, it did not change yet.

Marcel

________________________________________
Van: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] namens Galen Charlton [gmc at esilibrary.com]
Verzonden: maandag 16 januari 2012 15:40
To: koha-devel at lists.koha-community.org
Onderwerp: Re: [Koha-devel] Bugzilla

Hi Marcel,

On 01/16/2012 08:29 AM, Marcel de Rooy wrote:
> I personally would like to have a wider Status column in Bugzilla.

It looks like somebody has gone ahead and made the template change, at
lest for the bug display page.  Can you confirm that it's now looking wider?

Thanks,

Galen
--
Galen Charlton
Director of Support and Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

From paul.poulain at biblibre.com  Mon Jan 16 18:53:45 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Mon, 16 Jan 2012 18:53:45 +0100
Subject: [Koha-devel] Bugzilla
In-Reply-To: <4F1436DB.4030304@esilibrary.com>
References: <809BE39CD64BFD4EB9036172EBCCFA3101E6A923@S-MAIL-1A.rijksmuseum.intra>
	<4F1436DB.4030304@esilibrary.com>
Message-ID: <4F146429.6090003@biblibre.com>

Le 16/01/2012 15:40, Galen Charlton a ?crit :
> Hi Marcel,
> 
> On 01/16/2012 08:29 AM, Marcel de Rooy wrote:
>> I personally would like to have a wider Status column in Bugzilla.
> 
> It looks like somebody has gone ahead and made the template change, at
> lest for the bug display page.  Can you confirm that it's now looking
> wider?
we don't speak of bug display page, but of result list after a search.
(before reaching bug display page then)

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

From gmc at esilibrary.com  Mon Jan 16 19:09:32 2012
From: gmc at esilibrary.com (Galen Charlton)
Date: Mon, 16 Jan 2012 13:09:32 -0500
Subject: [Koha-devel] Bugzilla
In-Reply-To: <4F146429.6090003@biblibre.com>
References: <809BE39CD64BFD4EB9036172EBCCFA3101E6A923@S-MAIL-1A.rijksmuseum.intra>	<4F1436DB.4030304@esilibrary.com>
	<4F146429.6090003@biblibre.com>
Message-ID: <4F1467DC.1030908@esilibrary.com>

Hi Paul,

On 01/16/2012 12:53 PM, Paul Poulain wrote:
> we don't speak of bug display page, but of result list after a search.
> (before reaching bug display page then)

Thanks for clarifying.  I've increased the width of that column; please 
take a look.

Regards,

Galen
-- 
Galen Charlton
Director of Support and Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org & 
http://evergreen-ils.org

From chris at bigballofwax.co.nz  Mon Jan 16 20:12:37 2012
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Tue, 17 Jan 2012 08:12:37 +1300
Subject: [Koha-devel] Making bulk changes to bugs.koha-community.org;
 bug emails will be turned off briefly
In-Reply-To: <4F142945.8030408@biblibre.com>
References: <CAE2wdZxoR7W1nPgi6qRwTvrpe1MDXRxfAgdc1OE-Ok_TH_DTLg@mail.gmail.com>
	<CAE2wdZzpYbX+9AHB9aZk3AueM-nnFSaD13PG0WKqKQWJXsXL0w@mail.gmail.com>
	<20120115014658.GT5534@rorohiko.wgtn.cat-it.co.nz>
	<4F142945.8030408@biblibre.com>
Message-ID: <CA+95qVT+eT83y2C=P+N_ZEGfmsyfqP8b7YAadKQCrN-ptHaprg@mail.gmail.com>

On 17 January 2012 02:42, Paul Poulain <paul.poulain at biblibre.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Le 15/01/2012 02:46, Chris Cormack a ?crit :
>> * Ian Walls (ian.walls at bywatersolutions.com) wrote:
>>> Bulk changes are complete.A ?Bug emails have been turned back
>>> on.A Hopefully no one's inbox has been flooded.
>>>
>>> Work remaining to be done: * Shared reports need to be updated.A
>>> Since I'm not the creator of these, I cannot edit them for
>>> everyone else.A ?Most of the key ones are owed by either Paul P.
>>> or Chris C.
>>
>> I have updated the existing ones, new ones still need to be made
>> for any not in the footer now
> Chris, the passed QA one still has "priority=patch sent" in it, could
> you fix it ?
> You also haven't updated at all the "no status" query. I suspect it
> can be removed.
>
Done to both

Chris

From christianjcj at gmail.com  Mon Jan 16 22:08:19 2012
From: christianjcj at gmail.com (Christian Calle Jahuira)
Date: Mon, 16 Jan 2012 21:08:19 +0000
Subject: [Koha-devel] I need to enter through a WebService data users who
	enroll in the University
Message-ID: <CAOph5hZGfQ+7dLxUm+vgEuiBepQ9wisKzBF5ku9-F5pz6kdQtw@mail.gmail.com>

Dear Friends

Congratulations on the 2012 and have plenty of glory.

I have the following problem, I'm using Koha and need to incorporate
data through
a WebService users who enroll in college to my mysql database, I inject the
Borrowers table.

PD. We have updated users every management and is a constant problem.

I would appreciate any help please.


-- 
Christian Jhonny Calle Jahuira
TUTOR ELEARNING  - UMSA
Consultor Sistemas de Informacion de Bibliotecas de la UMSA
Email: christianjcj at gmail.com
Cel: 73017301 - 65151595
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120116/0a0c295a/attachment.htm>

From semarie-koha at latrappe.fr  Tue Jan 17 06:11:55 2012
From: semarie-koha at latrappe.fr (=?iso-8859-1?Q?Fr=E8re_S=E9bastien?= Marie)
Date: Tue, 17 Jan 2012 06:11:55 +0100
Subject: [Koha-devel] Bugzilla
In-Reply-To: <4F142AF3.9020404@biblibre.com>
References: <809BE39CD64BFD4EB9036172EBCCFA3101E6A923@S-MAIL-1A.rijksmuseum.intra>
	<4F142AF3.9020404@biblibre.com>
Message-ID: <20120117051102.GA15748@latrappe.fr>

On Mon, Jan 16, 2012 at 02:49:39PM +0100, Paul Poulain wrote:
> Le 16/01/2012 14:29, Marcel de Rooy a ?crit :
> > 
> > I personally would like to have a wider Status column in Bugzilla.
> I also like to change that. I've digged in bugzilla admin, and could not
> find how to change this.
> 
> > Now I have to know that  e.g. ?Patc?  means Patch does not apply.
> at the very least, we can use understandable codes like "DNA" for Does
> Not apply,...
> 
> If someone knows how to change, feel free to say. Otherwise i'll
> investigate the code on 4 letters idea.

It is a template customization. The modification will need filesystem access to edit template...

see http://www.bugzilla.org/docs/tip/en/html/cust-templates.html

The Status lengthe in the buglist is in file: "list/table.html.tmpl"

and search for the line like:
|    "bug_status"           => { maxlength => 4 } , 

-- 
Fr?re S?bastien Marie
Abbaye Notre Dame de La Trappe
61380 Soligny-la-Trappe
T?l: 02.33.84.17.00
Fax: 02.33.34.98.57
Web: http://www.latrappe.fr/

From paul.poulain at biblibre.com  Tue Jan 17 09:14:05 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Tue, 17 Jan 2012 09:14:05 +0100
Subject: [Koha-devel] Bugzilla
In-Reply-To: <4F1467DC.1030908@esilibrary.com>
References: <809BE39CD64BFD4EB9036172EBCCFA3101E6A923@S-MAIL-1A.rijksmuseum.intra>	<4F1436DB.4030304@esilibrary.com>
	<4F146429.6090003@biblibre.com> <4F1467DC.1030908@esilibrary.com>
Message-ID: <4F152DCD.2050305@biblibre.com>

Le 16/01/2012 19:09, Galen Charlton a ?crit :
> Hi Paul,
> 
> On 01/16/2012 12:53 PM, Paul Poulain wrote:
>> we don't speak of bug display page, but of result list after a search.
>> (before reaching bug display page then)
> 
> Thanks for clarifying.  I've increased the width of that column; please
> take a look.
That's perfect ! thanks galen !

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

From paul.poulain at biblibre.com  Tue Jan 17 09:22:24 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Tue, 17 Jan 2012 09:22:24 +0100
Subject: [Koha-devel] Hackfest in Europe in march (reminder)
Message-ID: <4F152FC0.6080909@biblibre.com>

Hello everybody,

A reminder about the hackfest BibLibre organize in Marseille in March.
It's in 2 months, it's time to book your flights/trains/car/horse/boat,
and tell us if you're coming.
We already have 6 ppl (+ all BibLibre, of course) that should come, from
4 different countries (France, Germany, Croatia and USA), we've a lot of
chairs & desktops still available !

If you hope to come but still are not sure, don't hesitate to send me a
mail with the information. I'm happy when I see my list growing ;-)

(full details at:
http://drupal.biblibre.com/en/blog/entry/2012-hackfest-in-europe)

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

From fridolyn.somers at gmail.com  Tue Jan 17 15:08:04 2012
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Tue, 17 Jan 2012 15:08:04 +0100
Subject: [Koha-devel] I need to enter through a WebService data users
 who enroll in the University
In-Reply-To: <CAOph5hZGfQ+7dLxUm+vgEuiBepQ9wisKzBF5ku9-F5pz6kdQtw@mail.gmail.com>
References: <CAOph5hZGfQ+7dLxUm+vgEuiBepQ9wisKzBF5ku9-F5pz6kdQtw@mail.gmail.com>
Message-ID: <CAN6cLAVRmoh1ijFFtjQSQV-jKZHAXESskuv0rE3D8P5WcoCwbw@mail.gmail.com>

Hie,

We have develop a webservice connexion from Koha to another server.
We used SOAP-Lite lib : http://search.cpan.org/dist/SOAP-Lite/

Be carefull when you modify users, password is encrypted, it cant be
recreated.

Good luke.

2012/1/16 Christian Calle Jahuira <christianjcj at gmail.com>

> Dear Friends
>
> Congratulations on the 2012 and have plenty of glory.
>
> I have the following problem, I'm using Koha and need to incorporate data through
> a WebService users who enroll in college to my mysql database, I inject
> the Borrowers table.
>
> PD. We have updated users every management and is a constant problem.
>
> I would appreciate any help please.
>
>
> --
> Christian Jhonny Calle Jahuira
> TUTOR ELEARNING  - UMSA
> Consultor Sistemas de Informacion de Bibliotecas de la UMSA
> Email: christianjcj at gmail.com
> Cel: 73017301 - 65151595
>
>
> _______________________________________________
> 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/20120117/e5c9613b/attachment.htm>

From tajoli at cilea.it  Tue Jan 17 15:19:13 2012
From: tajoli at cilea.it (Zeno Tajoli)
Date: Tue, 17 Jan 2012 15:19:13 +0100
Subject: [Koha-devel] Tables from InnoDB to MYISAM
Message-ID: <4F158361.5070208@cilea.it>

Hi to all,

to mantain a good Koha system is import to use the cron job
'cleanup_database.pl'.

This script delete lines from tables

message_queue
need_merge_authorities
sessions
zebraqueue

The engine of those tables is InnoDB.

What do you think about change the engine to MYISAM ?
I think that MYISAM is a better engine for table with many write/delete.

For thi is an ehancement and I don't insert it in updatedatabase.pl.
This a change only for new installations.
Or to do by hand for update.

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

From dpavlin at rot13.org  Tue Jan 17 16:32:04 2012
From: dpavlin at rot13.org (Dobrica Pavlinusic)
Date: Tue, 17 Jan 2012 16:32:04 +0100
Subject: [Koha-devel] stocknumber and invertory books in Koha
Message-ID: <20120117153204.GG7924@rot13.org>

I need help from people who use stocknumbers in their Koha's installs.

I assume this is mostly Europe-specific since we are required by low to
keep invetory books with each item in our library but I hope that
other people might have similar legal requirements.

For a start, why is index defined on items.stocknumber non-unique?
I would assume that it has to be unique like barcode is (at least that's
our legal requirement).

Other than that, we need to have some representation of "inventory book"
which I plan to implement using additional local table in which I will
record stocknumber, biblionumber and various other fields required for
invertory book reporting. This duplicates data (which is bad if you ever
heard for normal forms in RDBMS), but it's required to cover case of
erasing items. If we don't have a copy of item, erased it would also
erase entry from invetory book which is very, very bad.

During implementation of this feature, I stumbled upon bug 7451[1] which
breaks AJAX value_builder in which I plan to implement assigment of next
invetory number and copying of data into separate invetory audit table.

Would this value_builder be useful to other Koha users, or is it too specific
for our use-case?

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

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

From tajoli at cilea.it  Tue Jan 17 16:42:38 2012
From: tajoli at cilea.it (Zeno Tajoli)
Date: Tue, 17 Jan 2012 16:42:38 +0100
Subject: [Koha-devel] stocknumber and invertory books in Koha
In-Reply-To: <20120117153204.GG7924@rot13.org>
References: <20120117153204.GG7924@rot13.org>
Message-ID: <4F1596EE.8060008@cilea.it>

Hi Dobrica,

Il 17/01/2012 16:32, Dobrica Pavlinusic ha scritto:
> I need help from people who use stocknumbers in their Koha's installs.
[..]
> For a start, why is index defined on items.stocknumber non-unique?
> I would assume that it has to be unique like barcode is (at least that's
> our legal requirement).

I think it is impossiblr to ask for a unique value at MySQL level.
In my experience I see US libraries with not-unique or NULL inventories.

In fact in Aleph500 there is the same situation (barcode unique,
inventory what do you want).

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

From tomascohen at gmail.com  Tue Jan 17 17:26:22 2012
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Tue, 17 Jan 2012 13:26:22 -0300
Subject: [Koha-devel] On memcached/memoize
Message-ID: <CABZfb=U2j61=V6kSPa2KDVtsXnQtZq1CreDX1GsMUHDno+pNRw@mail.gmail.com>

We are using memcached in two different ways accross Koha code:


1) The traditional way, explicitly using memcached inside the
method/function code (just a mock):

sub get_key
{
  my $data;

  if (C4::Context->ismemcached) {
      $data = C4::Context->memcached->get('key');
  }

  $data = slow_routine_to_get_data_from_db &&
C4::Context->memcached->set('key',$data) unless defined $data;

  return $data;
}


2) Using memoize/dynamic programming:

eval {
    if (C4::Context->ismemcached) {
        require Memoize::Memcached;
        import Memoize::Memcached qw(memoize_memcached);

        memoize_memcached( 'get_key,
                            memcached => C4::Context->memcached,
                            expire_time => 600 );    #cache for 10 minutes
    }
};


sub get_key
{
  my $data slow_routine_to_get_data_from_db;

  return $data;
}


The second method is really handy, in the sense that we need to just
need a new call to memoize_memcached to make get_key use memcached.
The problem with this approach (and the reason of this writing) is
data invalidation, that is sometimes needed. Setting expire_time seems
not enough for several cases (for example preferences change).

With the first method, we can use the the method 'delete' to
invalidate data on the setter function.
Using memoize on data we should be able to invalidate means we have to
use flush_cache(get_key => qw( key )) on methods/functions that write
data. But then we need to hook our methods and I can't decide if we
should continue using memoize... as it is less transparent for us who
read other peoples code...

I wrote to the author of Memoize (who didn't actually answer me) to
ask him if we could add a parameter to memoize_memcached: a list of
references to functions that invalidate data for this memoized
function. This way we could just continue using this. Otherwise I'd
recommend just using memcache the classic way.

Hope we have a discussion on this as there are plenty of places we can
benefit from this.

To+





julian.maurice at biblibre.com

From colin.campbell at ptfs-europe.com  Tue Jan 17 17:43:21 2012
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Tue, 17 Jan 2012 16:43:21 +0000
Subject: [Koha-devel] Tables from InnoDB to MYISAM
In-Reply-To: <4F158361.5070208@cilea.it>
References: <4F158361.5070208@cilea.it>
Message-ID: <20120117164321.GA12583@zazou.config>

On Tue, Jan 17, 2012 at 03:19:13PM +0100, Zeno Tajoli wrote:
> Hi to all,
> 
> to mantain a good Koha system is import to use the cron job
> 'cleanup_database.pl'.
> 
> This script delete lines from tables
> 
> message_queue
> need_merge_authorities
> sessions
> zebraqueue
> 
> The engine of those tables is InnoDB.
> 
> What do you think about change the engine to MYISAM ?
> I think that MYISAM is a better engine for table with many write/delete.

MyISAM locks the table rather than the row for update/insert so its
generally less optimal for tables which are getting lots of inserts.

I did some benchmarking on an application that was using some mysql
tables for high throughput logging and innodb was handling that workload
better. 
C.

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

http://www.ptfs-europe.com

From paul.poulain at biblibre.com  Tue Jan 17 17:54:33 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Tue, 17 Jan 2012 17:54:33 +0100
Subject: [Koha-devel] Tables from InnoDB to MYISAM
In-Reply-To: <4F158361.5070208@cilea.it>
References: <4F158361.5070208@cilea.it>
Message-ID: <4F15A7C9.40701@biblibre.com>

Le 17/01/2012 15:19, Zeno Tajoli a ?crit :
> Hi to all,
> 
> to mantain a good Koha system is import to use the cron job
> 'cleanup_database.pl'.
> 
> This script delete lines from tables
> 
> message_queue
> need_merge_authorities
> sessions
> zebraqueue
I'm for it:
* innoDB has a *big* problem with deletion, and space is not retrived.
so those tables, that have temporary data only are good candidates to be
myISAM
* those tables don't have any foreign constraint, that myISAM don't
manage, so it's OK
* those tables are very small, fast to write, so the lock table issue
that Colin rises is not a big deal.

We have this on all our customers, without any performance issue. (not
sure for merge_authorities, but sure for sessions & zebraqueue)

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

From gmc at esilibrary.com  Tue Jan 17 18:12:13 2012
From: gmc at esilibrary.com (Galen Charlton)
Date: Tue, 17 Jan 2012 12:12:13 -0500
Subject: [Koha-devel] Tables from InnoDB to MYISAM
In-Reply-To: <4F15A7C9.40701@biblibre.com>
References: <4F158361.5070208@cilea.it> <4F15A7C9.40701@biblibre.com>
Message-ID: <4F15ABED.1000503@esilibrary.com>

Hi,

On 01/17/2012 11:54 AM, Paul Poulain wrote:
> * innoDB has a *big* problem with deletion, and space is not retrived.
> so those tables, that have temporary data only are good candidates to be
> myISAM

Although as long as one uses the innodb_file_per_table option, 
recovering space from InnoDB scratch tables is easy.

> * those tables don't have any foreign constraint, that myISAM don't
> manage, so it's OK

message_queue does have constraints, actually, and justifiably so if one 
uses it as a log of notifications sent to the patron.

> * those tables are very small, fast to write, so the lock table issue
> that Colin rises is not a big deal.

Well, depends on scale.  I could imagine very large Koha sites that 
retain message history having large message_queue tables.

> We have this on all our customers, without any performance issue. (not
> sure for merge_authorities, but sure for sessions&  zebraqueue)

Faster yet, of course, is to not store sessions in MySQL at all, and use 
memcached.  Of course, the tradeoff is a little more work if one wishes 
to run reports on OPAC sessions.

All of that said, MyISAM is a reasonable choice for a default storage 
enginge for sessions, zebraqueue, and need_merge_authorities.

Regards,

Galen
-- 
Galen Charlton
Director of Support and Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org & 
http://evergreen-ils.org

From danielg.koha at gmail.com  Tue Jan 17 20:08:48 2012
From: danielg.koha at gmail.com (Daniel Grobani)
Date: Tue, 17 Jan 2012 11:08:48 -0800
Subject: [Koha-devel] Call for News for the January Newsletter
Message-ID: <CAOeKewimkaUe-zPEG8PQgZOYOnPg6kiDTBx-xVvBYVQ0zut-sg@mail.gmail.com>

Dear Koha Kommunitarians,

I'm harvesting news for the January newsletter. Please send me by the
25th anything you think your fellow community members might like to
know about.

"News" can be as short as a sentence or as long as a paper. I
especially encourage you to send me a line or two about what you're
currently working on for publication in the gossip/society column. And
if you know of a go-live not announced on the list, please be sure to
let me know about it.

Thanks,
Daniel Grobani

From dpavlin at rot13.org  Tue Jan 17 20:46:12 2012
From: dpavlin at rot13.org (Dobrica Pavlinusic)
Date: Tue, 17 Jan 2012 20:46:12 +0100
Subject: [Koha-devel] stocknumber and invertory books in Koha
In-Reply-To: <4F1596EE.8060008@cilea.it>
References: <20120117153204.GG7924@rot13.org>
 <4F1596EE.8060008@cilea.it>
Message-ID: <20120117194612.GA4824@rot13.org>

On Tue, Jan 17, 2012 at 04:42:38PM +0100, Zeno Tajoli wrote:
> Hi Dobrica,
> 
> Il 17/01/2012 16:32, Dobrica Pavlinusic ha scritto:
> > I need help from people who use stocknumbers in their Koha's installs.
> [..]
> > For a start, why is index defined on items.stocknumber non-unique?
> > I would assume that it has to be unique like barcode is (at least that's
> > our legal requirement).
> 
> I think it is impossiblr to ask for a unique value at MySQL level.

It's not totally impossible. You just have to use trasactions and
additional table to hold last value[1] or in case on invetory all values
and a little bit of additional meta data[2]

1: http://git.rot13.org/?p=koha.git;a=commitdiff;h=01580945128cb727a404249c7898e6d101f10ceb

This is first implementation of sequences which uses mysql routine to
provide increment but also requires modification of CGI code to call it
on save action.

2: http://git.rot13.org/?p=koha.git;a=blob;f=cataloguing/value_builder/ffzg-stocknumber.pl;h=0239f37984bf5f5b43016a5db288af84466b9f86

This is a value_builder only implementation which moves mysql routine
into AJAX callback with transaction.

This nicely side-steps problem with uniqueness (since every AJAX request
will produce new value and populate one row in invetory table)
but it's triggered on plugin invocation (dots in Koha interface) as
opposed to save time.

I would really love if value builder plugins would have some kind of
"on_save" hook, in which I can get item record and save some additional
data into inventory table. This would also help with cases in which
plugin is activated (and number reserved) but item is never saved.

For now I will have to do this via cron script (which I plan to run daily,
so you can tweak item data during same day when new stock number is issued
and invetory will reflect state at end of this day).

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

From cnighswonger at foundations.edu  Wed Jan 18 04:50:12 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Tue, 17 Jan 2012 22:50:12 -0500
Subject: [Koha-devel] 3.6.3 Update
Message-ID: <CAP3yOomvdr7UtjTV2JvUS_aGQRD0kSJWaZxeA89VWEyzF9fraw@mail.gmail.com>

Hi all,

Just an update here on the status of 3.6.3.

My schedule has been extremely busy since I returned to work the first of
the month. As a result, I have been working in fits and starts to get
commits picked out of master and into 3.6.x in preparation for the release
of 3.6.3. After finally getting several hours today devoted to the work, I
have royally screwed up my local maintenance branch from which I push to
the main repo. As those who eat and drink git know, this is not a fatal
disaster, but it is certainly one which will now require another large
block of time to correct: a resource I am sadly short on at the moment.

Long story short: 3.6.3 will not be released on time this month. Very
likely it will be near the end of the month before I can get things sorted
out and announce a string freeze for the translators. This pushes the
release into the second week of February.

Please accept my sincerest apologies for the delay.

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

From chris at bigballofwax.co.nz  Wed Jan 18 07:20:20 2012
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Wed, 18 Jan 2012 19:20:20 +1300
Subject: [Koha-devel] stocknumber and invertory books in Koha
In-Reply-To: <20120117194612.GA4824@rot13.org>
References: <20120117153204.GG7924@rot13.org> <4F1596EE.8060008@cilea.it>
	<20120117194612.GA4824@rot13.org>
Message-ID: <CA+95qVQtfcM_wHGYHQUab3VsC5fOJaNJMjEQLYZq7oQ2i+m47Q@mail.gmail.com>

Hi Dobrica

I think Zeno didn't mean technically impossible to provide uniqueness at
the DB level, just that lots of libraries do not want unique stock numbers,
so enforcing it at db level (with a unique constraint isn't possible in
Koha).

Enforcing it in the code, as you have done, with the caveat that it needs
to be controlled by a syspref so that those who want it unique or not can
both be satisfied is certainly possibly

Chris

On Wednesday, 18 January 2012, Dobrica Pavlinusic wrote:

> On Tue, Jan 17, 2012 at 04:42:38PM +0100, Zeno Tajoli wrote:
> > Hi Dobrica,
> >
> > Il 17/01/2012 16:32, Dobrica Pavlinusic ha scritto:
> > > I need help from people who use stocknumbers in their Koha's installs.
> > [..]
> > > For a start, why is index defined on items.stocknumber non-unique?
> > > I would assume that it has to be unique like barcode is (at least
> that's
> > > our legal requirement).
> >
> > I think it is impossiblr to ask for a unique value at MySQL level.
>
> It's not totally impossible. You just have to use trasactions and
> additional table to hold last value[1] or in case on invetory all values
> and a little bit of additional meta data[2]
>
> 1:
> http://git.rot13.org/?p=koha.git;a=commitdiff;h=01580945128cb727a404249c7898e6d101f10ceb
>
> This is first implementation of sequences which uses mysql routine to
> provide increment but also requires modification of CGI code to call it
> on save action.
>
> 2:
> http://git.rot13.org/?p=koha.git;a=blob;f=cataloguing/value_builder/ffzg-stocknumber.pl;h=0239f37984bf5f5b43016a5db288af84466b9f86
>
> This is a value_builder only implementation which moves mysql routine
> into AJAX callback with transaction.
>
> This nicely side-steps problem with uniqueness (since every AJAX request
> will produce new value and populate one row in invetory table)
> but it's triggered on plugin invocation (dots in Koha interface) as
> opposed to save time.
>
> I would really love if value builder plugins would have some kind of
> "on_save" hook, in which I can get item record and save some additional
> data into inventory table. This would also help with cases in which
> plugin is activated (and number reserved) but item is never saved.
>
> For now I will have to do this via cron script (which I plan to run daily,
> so you can tweak item data during same day when new stock number is issued
> and invetory will reflect state at end of this day).
>
> --
> Dobrica Pavlinusic               2share!2flame
> dpavlin at rot13.org <javascript:;>
> Unix addict. Internet consultant.
> http://www.rot13.org/~dpavlin
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org <javascript:;>
> 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/20120118/e15e120f/attachment.htm>

From paul.poulain at biblibre.com  Wed Jan 18 09:26:57 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 18 Jan 2012 09:26:57 +0100
Subject: [Koha-devel] Bugzilla (small) change
Message-ID: <4F168251.9030307@biblibre.com>

Hello all,

The changes made by Ian last week-end are great, but someone made a
small mistake with "PATCH sent" priority that was still visible. This
field should not be used anymore, as it's replaced by the bug status
"needs signoff".

I made a small change in bugzilla parameters:
* the priority "patch sent" is now invisible for new bugs
* all open bugs still have the "patch sent" priority, but i've updated
the description, and it's not "patch sent (DO NOT USE)", and it's at the
end of the list.

We could also repeat what Ian did last week:
* suspend any mail
* bulkupdate priority to set "Priority 3 (medium)" for all entries
* remove "Patch sent" priority
* restore mail sending
but I'm not sure it's worth it, as this change has a small but nasty
side effect= all bugs would have the same "last modification date", and
this information is sometimes usefull (at least for me) : if a bug stays
for a long time in a given status, then I tend to take care of it 1st !
-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From M.de.Rooy at rijksmuseum.nl  Wed Jan 18 13:16:38 2012
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Wed, 18 Jan 2012 12:16:38 +0000
Subject: [Koha-devel] Bugzilla (small) change
In-Reply-To: <4F168251.9030307@biblibre.com>
References: <4F168251.9030307@biblibre.com>
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31033C37B7@S-MAIL-1A.rijksmuseum.intra>

I would favor removing Patch-sent. The modification date has been updated for a lot of reports anyway because of the last change. 

And repeating my question of a few days ago to Ian and the list: Could we add a field for creation date of last attachment? This would be even more accurate than last change date. The information must be in Bugzilla somewhere because it is displayed in the Attachments block. 

________________________________________
Van: koha-devel-bounces at lists.koha-community.org [koha-devel-bounces at lists.koha-community.org] namens Paul Poulain [paul.poulain at biblibre.com]
Verzonden: woensdag 18 januari 2012 9:26
To: koha-devel at lists.koha-community.org
Onderwerp: [Koha-devel] Bugzilla (small) change

Hello all,

The changes made by Ian last week-end are great, but someone made a
small mistake with "PATCH sent" priority that was still visible. This
field should not be used anymore, as it's replaced by the bug status
"needs signoff".

I made a small change in bugzilla parameters:
* the priority "patch sent" is now invisible for new bugs
* all open bugs still have the "patch sent" priority, but i've updated
the description, and it's not "patch sent (DO NOT USE)", and it's at the
end of the list.

We could also repeat what Ian did last week:
* suspend any mail
* bulkupdate priority to set "Priority 3 (medium)" for all entries
* remove "Patch sent" priority
* restore mail sending
but I'm not sure it's worth it, as this change has a small but nasty
side effect= all bugs would have the same "last modification date", and
this information is sometimes usefull (at least for me) : if a bug stays
for a long time in a given status, then I tend to take care of it 1st !
--
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

From paul.poulain at biblibre.com  Wed Jan 18 13:50:33 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 18 Jan 2012 13:50:33 +0100
Subject: [Koha-devel] Bugzilla (small) change
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA31033C37B7@S-MAIL-1A.rijksmuseum.intra>
References: <4F168251.9030307@biblibre.com>
	<809BE39CD64BFD4EB9036172EBCCFA31033C37B7@S-MAIL-1A.rijksmuseum.intra>
Message-ID: <4F16C019.9090002@biblibre.com>

Le 18/01/2012 13:16, Marcel de Rooy a ?crit :
> I would favor removing Patch-sent. The modification date has been updated for a lot of reports anyway because of the last change. 
> 
> And repeating my question of a few days ago to Ian and the list: Could we add a field for creation date of last attachment? This would be even more accurate than last change date. The information must be in Bugzilla somewhere because it is displayed in the Attachments block. 
I've investigated bugzilla configuration, and I can't find anything
about that.
I suspect we can display only informations that is related to the bug
itself. For anything with a 1-n relation => you can't have it on the
list. it seems to be true for comments, modif history, patches


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

From M.de.Rooy at rijksmuseum.nl  Wed Jan 18 14:26:27 2012
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Wed, 18 Jan 2012 13:26:27 +0000
Subject: [Koha-devel] Bug-enhancement patch Workflow
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31033C4E48@S-MAIL-1A.rijksmuseum.intra>

Hi All,



See http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow



What should we add to this page about the new Pushed to Master / Pushed to Stable status?



How can we prevent that further development on a report (followups etc.) interferes with the process of selecting patches for the maintenance branch?

Example: If I have a new followup 2 after patch 1 has been pushed to master, I would like to change status directly to Needs Signoff for patch 2. (But in the meantime Chris N may select patch 1 for maintenance. How? )



Any input is welcome, especially from Chris N here, I suppose..



Marcel


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

From cnighswonger at foundations.edu  Wed Jan 18 15:35:54 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Wed, 18 Jan 2012 09:35:54 -0500
Subject: [Koha-devel] Bug-enhancement patch Workflow
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA31033C4E48@S-MAIL-1A.rijksmuseum.intra>
References: <809BE39CD64BFD4EB9036172EBCCFA31033C4E48@S-MAIL-1A.rijksmuseum.intra>
Message-ID: <CAP3yOo=4PgPE8nsQ5ZkwMbx7+nsozo64v2yX2azDozXGFn7xGQ@mail.gmail.com>

2012/1/18 Marcel de Rooy <M.de.Rooy at rijksmuseum.nl>

>  How can we prevent that further development on a report (followups etc.)
> interferes with the process of selecting patches for the maintenance branch?
>
> Example: If I have a new followup 2 after patch 1 has been pushed to
> master, I would like to change status directly to Needs Signoff for patch
> 2. (But in the meantime Chris N may select patch 1 for maintenance. How? )
>
>
>
Good question.

This ties in with another "problem:" that of filing bugs against an
enhancement but tagging the bugs as "bugs" rather than "ehn."

I wonder if the consistent use of "dependencies" would help in both cases.
For example:

Case #1: Follow-up patches submitted after pushing to the maintenance branch

A new bug is opened for the followup and linked back to the original bug
via dependency.

Case #2: A bug is filed which applies to a previous enh.

The new bug is linked to the enh bug via dependency.

These relationships could then be tracked via reports.

Make sense?

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

From tajoli at cilea.it  Wed Jan 18 15:51:06 2012
From: tajoli at cilea.it (Zeno Tajoli)
Date: Wed, 18 Jan 2012 15:51:06 +0100
Subject: [Koha-devel] stocknumber and invertory books in Koha
In-Reply-To: <CA+95qVQtfcM_wHGYHQUab3VsC5fOJaNJMjEQLYZq7oQ2i+m47Q@mail.gmail.com>
References: <20120117153204.GG7924@rot13.org> <4F1596EE.8060008@cilea.it>
	<20120117194612.GA4824@rot13.org>
	<CA+95qVQtfcM_wHGYHQUab3VsC5fOJaNJMjEQLYZq7oQ2i+m47Q@mail.gmail.com>
Message-ID: <4F16DC5A.7060208@cilea.it>

Hi to all,

Il 18/01/2012 07:20, Chris Cormack ha scritto:
> I think Zeno didn't mean technically impossible to provide uniqueness at
> the DB level, just that lots of libraries do not want unique stock
> numbers, so enforcing it at db level (with a unique constraint isn't
> possible in Koha).
> 
> Enforcing it in the code, as you have done, with the caveat that it
> needs to be controlled by a syspref so that those who want it unique or
> not can both be satisfied is certainly possibly

sorry for delay, but Chris writes exactly what I means.
The problem is that is not possible to enforce unique stock
numbers at db level (like barcode).

BUT I like very much the idea to give the option to enforce it at code
level, with a syspref to swith ON/OFF.

For Dobrica:
Can you write the translation of 'signatura zatvorenog spremista' and
'Implementirati vi?estruke nizove signatura prema formatu'.
from:
http://git.rot13.org/?p=koha.git;a=commitdiff;h=01580945128cb727a404249c7898e6d101f10ceb

Google translate doesn't help.

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

From cnighswonger at foundations.edu  Wed Jan 18 16:18:20 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Wed, 18 Jan 2012 10:18:20 -0500
Subject: [Koha-devel] 3.6.x String Freeze [WAS: 3.6.3 Update]
Message-ID: <CAP3yOomKiR6XzR2t4nU3DoWp=cEsb-9H3MaNqeQAkThY76meqg@mail.gmail.com>

Ok, in spite of my worst fears, the issues mentioned below have been
resolved and the 3.6.x branch is now in a string freeze.

I'm planning to release on 25 Jan 2012, giving the translators a week to
update translations.

See you in a week! :-)

Kind Regards,
Chris
Koha 3.4.x/3.6.x Release Maintainer


On Tue, Jan 17, 2012 at 10:50 PM, Chris Nighswonger <
cnighswonger at foundations.edu> wrote:

> Hi all,
>
> Just an update here on the status of 3.6.3.
>
> My schedule has been extremely busy since I returned to work the first of
> the month. As a result, I have been working in fits and starts to get
> commits picked out of master and into 3.6.x in preparation for the release
> of 3.6.3. After finally getting several hours today devoted to the work, I
> have royally screwed up my local maintenance branch from which I push to
> the main repo. As those who eat and drink git know, this is not a fatal
> disaster, but it is certainly one which will now require another large
> block of time to correct: a resource I am sadly short on at the moment.
>
> Long story short: 3.6.3 will not be released on time this month. Very
> likely it will be near the end of the month before I can get things sorted
> out and announce a string freeze for the translators. This pushes the
> release into the second week of February.
>
> Please accept my sincerest apologies for the delay.
>
> Kind Regards,
> Chris
> Koha 3.4.x/3.6.x Release Maintainer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120118/211b64ae/attachment.htm>

From dpavlin at rot13.org  Wed Jan 18 19:10:15 2012
From: dpavlin at rot13.org (Dobrica Pavlinusic)
Date: Wed, 18 Jan 2012 19:10:15 +0100
Subject: [Koha-devel] stocknumber and invertory books in Koha
In-Reply-To: <4F16DC5A.7060208@cilea.it>
References: <20120117153204.GG7924@rot13.org> <4F1596EE.8060008@cilea.it>
	<20120117194612.GA4824@rot13.org>
	<CA+95qVQtfcM_wHGYHQUab3VsC5fOJaNJMjEQLYZq7oQ2i+m47Q@mail.gmail.com>
	<4F16DC5A.7060208@cilea.it>
Message-ID: <20120118181015.GC3643@rot13.org>

On Wed, Jan 18, 2012 at 03:51:06PM +0100, Zeno Tajoli wrote:
> Il 18/01/2012 07:20, Chris Cormack ha scritto:
> > I think Zeno didn't mean technically impossible to provide uniqueness at
> > the DB level, just that lots of libraries do not want unique stock
> > numbers, so enforcing it at db level (with a unique constraint isn't
> > possible in Koha).
> > 
> > Enforcing it in the code, as you have done, with the caveat that it
> > needs to be controlled by a syspref so that those who want it unique or
> > not can both be satisfied is certainly possibly
> 
> sorry for delay, but Chris writes exactly what I means.
> The problem is that is not possible to enforce unique stock
> numbers at db level (like barcode).

Sorry, I was probably too much into code that day :-)

> BUT I like very much the idea to give the option to enforce it at code
> level, with a syspref to swith ON/OFF.

Chris, do we allready have some mechanisam to enforce uniqueness at code
level for fields in MARC or items table?

I'm asking this because we are mostly dropping MySQL errors on the floor
as opposed to returning errors to users (adding items in acquisition is
my current example of this) so enforcing it with unique index on
database field is not really a solution...

> For Dobrica:
> Can you write the translation of 'signatura zatvorenog spremista' and
> 'Implementirati vi?estruke nizove signatura prema formatu'.
> from:
> http://git.rot13.org/?p=koha.git;a=commitdiff;h=01580945128cb727a404249c7898e6d101f10ceb
> 
> Google translate doesn't help.

We have closed stocks on basement level in our library where
shelfing system and callnumbers are based on physical dymensions of
items (prefix in callnumber).

In next iteration of this, I will probably also rewrite this plugin to
use AJAX instread of mysql functions. This will make it database
independent, and mysqldump doesn't drop function by defaults (and flag
is called --routines just to be confusing), so backups are also tricky
(and reson to abondon mysql functions).

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

From M.de.Rooy at rijksmuseum.nl  Thu Jan 19 11:39:51 2012
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Thu, 19 Jan 2012 10:39:51 +0000
Subject: [Koha-devel] Problem when removing subfield in biblio editor
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31033C7ACD@S-MAIL-1A.rijksmuseum.intra>

Found it. Problem is in TransformHtmlToMarc (Biblio.pm).
Submitted a patch under report 3264.
Now looking for someone to sign off ...

Van: koha-bounces at lists.katipo.co.nz [mailto:koha-bounces at lists.katipo.co.nz] Namens Marcel de Rooy
Verzonden: woensdag 18 januari 2012 15:41
Aan: koha at lists.katipo.co.nz
Onderwerp: [Koha] Problem when removing subfield in biblio editor


Hi,

Does anyone of you recognize this (rather serious) problem.

If I have a field say 710 with $4 relator code followed by $9 authid and $a name, and I clear the $4 with Delete this subfield and save the record, I also loose the other subfields!!

This does not happen when the subfield order is different like $9 $a $4 and clearing $4.



Came across old Bugzilla reports 3264 and 5707 but they seem to focus on authorities editor. This problem above is in the biblio editor.



Any comments welcome,



Marcel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120119/41faa191/attachment-0001.htm>

From M.de.Rooy at rijksmuseum.nl  Thu Jan 19 13:42:01 2012
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Thu, 19 Jan 2012 12:42:01 +0000
Subject: [Koha-devel] Bugzilla: My Bugs
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31033C8015@S-MAIL-1A.rijksmuseum.intra>

Hi,
Jared already asked this question earlier on, but could My Bugs be adjusted (after the change of status) ? By someone having the necessary permissions ..

Now, it is something like:
*         Status: UNCONFIRMED, NEW, ASSIGNED, REOPENED
*         Assignee: m.de.rooy at rijksmuseum.nl
*         Reporter: m.de.rooy at rijksmuseum.nl
*         Status: (is not equal to) UNCONFIRMED
*         Reporter: m.de.rooy at rijksmuseum.nl
And it should become something like:
*         Assignee: m.de.rooy at rijksmuseum.nl
*         Reporter: m.de.rooy at rijksmuseum.nl
*         Status: (is not equal to) RESOLVED
*         Status: (is not equal to) CLOSED
Of course, replacing my email with that of the active user ;)

Thanks,

Marcel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120119/74fd459f/attachment.htm>

From paul.poulain at biblibre.com  Thu Jan 19 14:29:12 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 19 Jan 2012 14:29:12 +0100
Subject: [Koha-devel] Bugzilla: My Bugs
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA31033C8015@S-MAIL-1A.rijksmuseum.intra>
References: <809BE39CD64BFD4EB9036172EBCCFA31033C8015@S-MAIL-1A.rijksmuseum.intra>
Message-ID: <4F181AA8.1050404@biblibre.com>

Le 19/01/2012 13:42, Marcel de Rooy a ?crit :
> Hi,
> 
> Jared already asked this question earlier on, but could My Bugs be
> adjusted (after the change of status) ? By someone having the necessary
> permissions ..
Done. Please confirm it's OK


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

From M.de.Rooy at rijksmuseum.nl  Thu Jan 19 15:07:52 2012
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Thu, 19 Jan 2012 14:07:52 +0000
Subject: [Koha-devel] Bugzilla: My Bugs
In-Reply-To: <4F181AA8.1050404@biblibre.com>
References: <809BE39CD64BFD4EB9036172EBCCFA31033C8015@S-MAIL-1A.rijksmuseum.intra>
	<4F181AA8.1050404@biblibre.com>
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA31033C808B@S-MAIL-1A.rijksmuseum.intra>

Already better!
I would personally only exclude status Resolved Closed Verified.  But others may think differently? 
The other statuses like Patch doesn't apply are good to show too. Stimulates working on them too  ;)
Same for Pushed. (If I reported them, I should test and close, isn't it? )
Thanks. 

-----Oorspronkelijk bericht-----
Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Paul Poulain
Verzonden: donderdag 19 januari 2012 14:29
Aan: koha-devel at lists.koha-community.org
Onderwerp: Re: [Koha-devel] Bugzilla: My Bugs

Le 19/01/2012 13:42, Marcel de Rooy a ?crit :
> Hi,
> 
> Jared already asked this question earlier on, but could My Bugs be 
> adjusted (after the change of status) ? By someone having the 
> necessary permissions ..
Done. Please confirm it's OK


--
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 _______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/

From tajoli at cilea.it  Thu Jan 19 15:56:08 2012
From: tajoli at cilea.it (Zeno Tajoli)
Date: Thu, 19 Jan 2012 15:56:08 +0100
Subject: [Koha-devel] To check the quality of bib records during cataloguing
Message-ID: <4F182F08.9050600@cilea.it>

Hi to all,

my cataloguers are new to MARC21 and they find difficult remenber to
insert punctation at the end of subfield (in 245 for example).
Do anyone develop a checker about puntaction ?
Something like MARC::Lint but integrated in Koha.

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

From juan.sieira at xercode.es  Thu Jan 19 18:05:08 2012
From: juan.sieira at xercode.es (Juan Francisco Romay Sieira)
Date: Thu, 19 Jan 2012 18:05:08 +0100
Subject: [Koha-devel] To check the quality of bib records during
	cataloguing
In-Reply-To: <4F182F08.9050600@cilea.it>
References: <4F182F08.9050600@cilea.it>
Message-ID: <CABi05VvvHp_DBTgF4Lb4Vf5fANc0bPd0JXhQ6n=YBYCCJxQdvw@mail.gmail.com>

Hi Zeno,
some time ago we add a enhancement to show local help and isbd punctuation
automatically when cataloguing

You can check it here:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6138

Regards,

2012/1/19 Zeno Tajoli <tajoli at cilea.it>

> Hi to all,
>
> my cataloguers are new to MARC21 and they find difficult remenber to
> insert punctation at the end of subfield (in 245 for example).
> Do anyone develop a checker about puntaction ?
> Something like MARC::Lint but integrated in Koha.
>
> Bye
> Zeno Tajoli
> --
> Dott. Zeno Tajoli
> tajoliAT_SPAM_no_prendiATcilea.it
> fax +39 02 2135520
> CILEA - Consorzio Interuniversitario
> http://www.cilea.it/disclaimer
> _______________________________________________
> 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/
>



-- 


-- 
*

Juan Francisco Romay Sieira*

*Chief Technology Officer*
juan.sieira at xercode.es
Mov. (+34) 607 332 910

Rosal?a de Castro, 53 4?C  |  15895  |  Milladoiro - A Coru?a - Spain
www.xercode.es  |  info at xercode.es
Tel. (+34) 881 975 576





La informaci?n contenida en este mensaje y sus posibles documentos adjuntos
es privada y confidencial y est? dirigida ?nicamente a su destinatario/a.
Si usted no es el/la destinatario/a original de este mensaje, por favor
elim?nelo. La distribuci?n o copia de este mensaje no est? autorizada.

The information contained in this message and any attachments are private
and confidential and is intended solely for the receiver. If you are not
the  original receiver to this message, please delete it. The distribution
or copying of this message is not authorized.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120119/fefc119f/attachment-0001.htm>

From tajoli at cilea.it  Thu Jan 19 18:13:16 2012
From: tajoli at cilea.it (Zeno Tajoli)
Date: Thu, 19 Jan 2012 18:13:16 +0100
Subject: [Koha-devel] To check the quality of bib records during
	cataloguing
In-Reply-To: <CABi05VvvHp_DBTgF4Lb4Vf5fANc0bPd0JXhQ6n=YBYCCJxQdvw@mail.gmail.com>
References: <4F182F08.9050600@cilea.it>
	<CABi05VvvHp_DBTgF4Lb4Vf5fANc0bPd0JXhQ6n=YBYCCJxQdvw@mail.gmail.com>
Message-ID: <4F184F2C.9030208@cilea.it>

Hi Juan,

Il 19/01/2012 18:05, Juan Francisco Romay Sieira ha scritto:
> some time ago we add a enhancement to show local help and isbd punctuation
> automatically when cataloguing
> 
> You can check it here:
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6138

your libraries use Unimarc Or MARC21 ?
The problem is that in 245 subfield $b can start with different puntaction.

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

From juan.sieira at xercode.es  Thu Jan 19 18:22:48 2012
From: juan.sieira at xercode.es (Juan Francisco Romay Sieira)
Date: Thu, 19 Jan 2012 18:22:48 +0100
Subject: [Koha-devel] To check the quality of bib records during
	cataloguing
In-Reply-To: <4F184F2C.9030208@cilea.it>
References: <4F182F08.9050600@cilea.it>
	<CABi05VvvHp_DBTgF4Lb4Vf5fANc0bPd0JXhQ6n=YBYCCJxQdvw@mail.gmail.com>
	<4F184F2C.9030208@cilea.it>
Message-ID: <CABi05Vui9biwYRxW=wscun8mbjS6g+7Mju3wdt2pSEiMNCgaMA@mail.gmail.com>

MARC21 . The punctuation is stored in marc_subfield_structure, so its the
same using MARC21 or UNIMARC. In administration->MARC Bibliographic
framework->Marc Structure->Subfields->Edit subfields there are two new
fields, punctuacion and help. We have to fill those fields with some help
and the isbd punctuation to a determinate subfield. Those values will
appear when we are cataloguing.

2012/1/19 Zeno Tajoli <tajoli at cilea.it>

> Hi Juan,
>
> Il 19/01/2012 18:05, Juan Francisco Romay Sieira ha scritto:
> > some time ago we add a enhancement to show local help and isbd
> punctuation
> > automatically when cataloguing
> >
> > You can check it here:
> > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6138
>
> your libraries use Unimarc Or MARC21 ?
> The problem is that in 245 subfield $b can start with different puntaction.
>
> Bye
> Zeno Tajoli
> --
> Dott. Zeno Tajoli
> tajoliAT_SPAM_no_prendiATcilea.it
> fax +39 02 2135520
> CILEA - Consorzio Interuniversitario
> http://www.cilea.it/disclaimer
> _______________________________________________
> 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/
>



-- 


-- 
*

Juan Francisco Romay Sieira*

*Chief Technology Officer*
juan.sieira at xercode.es
Mov. (+34) 607 332 910

Rosal?a de Castro, 53 4?C  |  15895  |  Milladoiro - A Coru?a - Spain
www.xercode.es  |  info at xercode.es
Tel. (+34) 881 975 576





La informaci?n contenida en este mensaje y sus posibles documentos adjuntos
es privada y confidencial y est? dirigida ?nicamente a su destinatario/a.
Si usted no es el/la destinatario/a original de este mensaje, por favor
elim?nelo. La distribuci?n o copia de este mensaje no est? autorizada.

The information contained in this message and any attachments are private
and confidential and is intended solely for the receiver. If you are not
the  original receiver to this message, please delete it. The distribution
or copying of this message is not authorized.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120119/232b48f0/attachment.htm>

From mtj at kohaaloha.com  Fri Jan 20 08:59:36 2012
From: mtj at kohaaloha.com (Mason James)
Date: Fri, 20 Jan 2012 20:59:36 +1300
Subject: [Koha-devel] add the Smart::Comments perl module to Koha,
	a good idea?
Message-ID: <E9EA3709-8746-485B-9ED4-B419F33052B8@kohaaloha.com>

hiya Devs

i've secretly wanted Smart::Comments to replace Data::Dumper as the preferred debug tool of Koha

(why you ask?, because its heaps more useful than Data::Dumper!!! )


what do other people think?

i think i'm gonna send a patch to add the S::C module as a Koha dependency, a good idea?


Mason
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 535 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20120120/4fc8be60/attachment.pgp>

From cnighswonger at foundations.edu  Fri Jan 20 15:02:58 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Fri, 20 Jan 2012 09:02:58 -0500
Subject: [Koha-devel] add the Smart::Comments perl module to Koha,
	a good idea?
In-Reply-To: <E9EA3709-8746-485B-9ED4-B419F33052B8@kohaaloha.com>
References: <E9EA3709-8746-485B-9ED4-B419F33052B8@kohaaloha.com>
Message-ID: <CAP3yOonwNjXyBVHTQ+yw6h8dYAKCpd2fjPjpjTSRcWRXFKy5eA@mail.gmail.com>

That's pretty slick. I'd have no objection to adding it in. I don't think
we should slash Data::Dumper simply because there are many places it is
currently used. We could work toward eliminating it, though.

Kind Regards,
Chris

2012/1/20 Mason James <mtj at kohaaloha.com>

> hiya Devs
>
> i've secretly wanted Smart::Comments to replace Data::Dumper as the
> preferred debug tool of Koha
>
> (why you ask?, because its heaps more useful than Data::Dumper!!! )
>
>
> what do other people think?
>
> i think i'm gonna send a patch to add the S::C module as a Koha
> dependency, a good idea?
>
>
> Mason
>
> _______________________________________________
> 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/20120120/160b329b/attachment.htm>

From colin.campbell at ptfs-europe.com  Fri Jan 20 15:25:50 2012
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Fri, 20 Jan 2012 14:25:50 +0000
Subject: [Koha-devel] add the Smart::Comments perl module to Koha,
 a good idea?
In-Reply-To: <CAP3yOonwNjXyBVHTQ+yw6h8dYAKCpd2fjPjpjTSRcWRXFKy5eA@mail.gmail.com>
References: <E9EA3709-8746-485B-9ED4-B419F33052B8@kohaaloha.com>
	<CAP3yOonwNjXyBVHTQ+yw6h8dYAKCpd2fjPjpjTSRcWRXFKy5eA@mail.gmail.com>
Message-ID: <20120120142549.GA5794@zazou.config>

On Fri, Jan 20, 2012 at 09:02:58AM -0500, Chris Nighswonger wrote:
> That's pretty slick. I'd have no objection to adding it in. I don't think
> we should slash Data::Dumper simply because there are many places it is
> currently used. We could work toward eliminating it, though.

Data::Dumper is a dependency for Smart::Comments so you need it anyhow

Colin

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

http://www.ptfs-europe.com

From gmc at esilibrary.com  Fri Jan 20 15:48:36 2012
From: gmc at esilibrary.com (Galen Charlton)
Date: Fri, 20 Jan 2012 09:48:36 -0500
Subject: [Koha-devel] add the Smart::Comments perl module to Koha,
	a good idea?
In-Reply-To: <E9EA3709-8746-485B-9ED4-B419F33052B8@kohaaloha.com>
References: <E9EA3709-8746-485B-9ED4-B419F33052B8@kohaaloha.com>
Message-ID: <92F32793-12CD-48D8-8160-E4CF5BE4AD12@esilibrary.com>

Hi,

On Jan 20, 2012, at 2:59 AM, Mason James wrote:
> i think i'm gonna send a patch to add the S::C module as a Koha dependency, a good idea?

As an optional dependency, maybe.  But there's nothing stopping anybody from using it for their debugging now, right?

Smart::Comments is a source filter -- and consequently may cause a modest but measurable performance hit if it were enabled across the board -- and some cursory Googling suggests that it may not have played well with mod_perl in the past.  I don't know, and haven't yet tested, whether that's still the case, but I do think that should be checked before such a patch is accepted.

Thinking aloud, perhaps (for Debian and friends) maybe it belongs as a dependency brought in by a new koha-dev-tools package?

Regards,

Galen
--
Galen Charlton
Director of Support and Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org


From gmc at esilibrary.com  Fri Jan 20 15:55:19 2012
From: gmc at esilibrary.com (Galen Charlton)
Date: Fri, 20 Jan 2012 09:55:19 -0500
Subject: [Koha-devel] add the Smart::Comments perl module to Koha,
	a good idea?
In-Reply-To: <CAP3yOonwNjXyBVHTQ+yw6h8dYAKCpd2fjPjpjTSRcWRXFKy5eA@mail.gmail.com>
References: <E9EA3709-8746-485B-9ED4-B419F33052B8@kohaaloha.com>
	<CAP3yOonwNjXyBVHTQ+yw6h8dYAKCpd2fjPjpjTSRcWRXFKy5eA@mail.gmail.com>
Message-ID: <3E30520E-E859-4570-8257-F448D95C23D3@esilibrary.com>

Hi,

On Jan 20, 2012, at 9:02 AM, Chris Nighswonger wrote:
> That's pretty slick. I'd have no objection to adding it in. I don't think we should slash Data::Dumper simply because there are many places it is currently used. We could work toward eliminating it, though.

Data::Dumper isn't just a debug tool, though -- more broadly, it's a way of serializing Perl data structures.  Not the only way, of course -- we've already got YAML and JSON modules as dependencies that can serve the same purpose, but since Data::Dumper is also a core module, I don't think making a point of eliminating its use would gain us much.  Of course, it doesn't hurt to continually evaluate usage of Koha's many Perl modules.

Regards,

Galen
--
Galen Charlton
Director of Support and Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org


From cnighswonger at foundations.edu  Fri Jan 20 17:11:46 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Fri, 20 Jan 2012 11:11:46 -0500
Subject: [Koha-devel] add the Smart::Comments perl module to Koha,
	a good idea?
In-Reply-To: <3E30520E-E859-4570-8257-F448D95C23D3@esilibrary.com>
References: <E9EA3709-8746-485B-9ED4-B419F33052B8@kohaaloha.com>
	<CAP3yOonwNjXyBVHTQ+yw6h8dYAKCpd2fjPjpjTSRcWRXFKy5eA@mail.gmail.com>
	<3E30520E-E859-4570-8257-F448D95C23D3@esilibrary.com>
Message-ID: <CAP3yOo=0xsGLq4q4wNpW-r2iLgwbwAWCo8Vo8sVYUKQgYsQQSQ@mail.gmail.com>

On Fri, Jan 20, 2012 at 9:55 AM, Galen Charlton <gmc at esilibrary.com> wrote:

> Hi,
>
> On Jan 20, 2012, at 9:02 AM, Chris Nighswonger wrote:
> > That's pretty slick. I'd have no objection to adding it in. I don't
> think we should slash Data::Dumper simply because there are many places it
> is currently used. We could work toward eliminating it, though.
>
> Data::Dumper isn't just a debug tool, though -- more broadly, it's a way
> of serializing Perl data structures.  Not the only way, of course -- we've
> already got YAML and JSON modules as dependencies that can serve the same
> purpose, but since Data::Dumper is also a core module, I don't think making
> a point of eliminating its use would gain us much.  Of course, it doesn't
> hurt to continually evaluate usage of Koha's many Perl modules.
>
>
And there is a nagging half-memory which tells me we use it for things
other than debugging already...

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

From jcamins at cpbibliography.com  Fri Jan 20 17:17:17 2012
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Fri, 20 Jan 2012 11:17:17 -0500
Subject: [Koha-devel] add the Smart::Comments perl module to Koha,
	a good idea?
In-Reply-To: <CAP3yOo=0xsGLq4q4wNpW-r2iLgwbwAWCo8Vo8sVYUKQgYsQQSQ@mail.gmail.com>
References: <E9EA3709-8746-485B-9ED4-B419F33052B8@kohaaloha.com>
	<CAP3yOonwNjXyBVHTQ+yw6h8dYAKCpd2fjPjpjTSRcWRXFKy5eA@mail.gmail.com>
	<3E30520E-E859-4570-8257-F448D95C23D3@esilibrary.com>
	<CAP3yOo=0xsGLq4q4wNpW-r2iLgwbwAWCo8Vo8sVYUKQgYsQQSQ@mail.gmail.com>
Message-ID: <CALVDfQzBkcBC=LEd0YfXsKyGr-fSTjA_WOxU7kUMHGJte6m4xA@mail.gmail.com>

Chris,

2012/1/20 Chris Nighswonger <cnighswonger at foundations.edu>

> And there is a nagging half-memory which tells me we use it for things
> other than debugging already...
>

I think Data::Dumper is used for the logs. That is something we would not
want to lose.

Regards,
Jared

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

From cnighswonger at foundations.edu  Sat Jan 21 14:57:00 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Sat, 21 Jan 2012 08:57:00 -0500
Subject: [Koha-devel] 3.4.x Branch and 3.4.8 Release Update
Message-ID: <CAP3yOo=b5SYy4Mo=PvWGcumDKNBbUzrvQ0q1JWXuAeoz5FmYrw@mail.gmail.com>

Hi All,

I've just had time to bring the 3.4.x branch current with master. We will
be releasing 3.4.8 next Saturday.

There are a huge number of commits made in the last 8 hours, so I'd like to
call for some testing on 3.4.x before the release next Saturday just to
avoid any obvious bugs.
So if you have a chance to, please test and let me know if you discover
anything.

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

From mtj at kohaaloha.com  Sun Jan 22 06:37:04 2012
From: mtj at kohaaloha.com (Mason James)
Date: Sun, 22 Jan 2012 18:37:04 +1300
Subject: [Koha-devel] add the Smart::Comments perl module to Koha,
	a good idea?
In-Reply-To: <92F32793-12CD-48D8-8160-E4CF5BE4AD12@esilibrary.com>
References: <E9EA3709-8746-485B-9ED4-B419F33052B8@kohaaloha.com>
	<92F32793-12CD-48D8-8160-E4CF5BE4AD12@esilibrary.com>
Message-ID: <1B32F5C7-E4C6-402B-A296-13F9FEA5CC05@kohaaloha.com>


On 2012-01-21, at 3:48 AM, Galen Charlton wrote:

> Hi,
> 
> On Jan 20, 2012, at 2:59 AM, Mason James wrote:
>> i think i'm gonna send a patch to add the S::C module as a Koha dependency, a good idea?
> 
> As an optional dependency, maybe.  But there's nothing stopping anybody from using it for their debugging now, right?
> 
> Smart::Comments is a source filter -- and consequently may cause a modest but measurable performance hit if it were enabled across the board -- and some cursory Googling suggests that it may not have played well with mod_perl in the past.  I don't know, and haven't yet tested, whether that's still the case, but I do think that should be checked before such a patch is accepted.
> 
> Thinking aloud, perhaps (for Debian and friends) maybe it belongs as a dependency brought in by a new koha-dev-tools package?
> 
> Regards,
> 
> Galen


cool, thanks for the replies everyone :)

so, lets use both Smart::Comments and Data::Dumper


hmmm, shall we start wrapping the loading of Koha debug modules in a 'if ($DEBUG) {use Smart::Comments}' type code block - as a performance tweak?


would that work?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 535 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20120122/05b21905/attachment.pgp>

From chrisc at catalyst.net.nz  Sun Jan 22 06:40:08 2012
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Sun, 22 Jan 2012 18:40:08 +1300
Subject: [Koha-devel] add the Smart::Comments perl module to Koha,
 a good idea?
In-Reply-To: <1B32F5C7-E4C6-402B-A296-13F9FEA5CC05@kohaaloha.com>
References: <E9EA3709-8746-485B-9ED4-B419F33052B8@kohaaloha.com>
	<92F32793-12CD-48D8-8160-E4CF5BE4AD12@esilibrary.com>
	<1B32F5C7-E4C6-402B-A296-13F9FEA5CC05@kohaaloha.com>
Message-ID: <20120122054008.GD5534@rorohiko.wgtn.cat-it.co.nz>

* Mason James (mtj at kohaaloha.com) wrote:
> 
> On 2012-01-21, at 3:48 AM, Galen Charlton wrote:
> 
> > Hi,
> > 
> > On Jan 20, 2012, at 2:59 AM, Mason James wrote:
> >> i think i'm gonna send a patch to add the S::C module as a Koha dependency, a good idea?
> > 
> > As an optional dependency, maybe.  But there's nothing stopping anybody from using it for their debugging now, right?
> > 
> > Smart::Comments is a source filter -- and consequently may cause a modest but measurable performance hit if it were enabled across the board -- and some cursory Googling suggests that it may not have played well with mod_perl in the past.  I don't know, and haven't yet tested, whether that's still the case, but I do think that should be checked before such a patch is accepted.
> > 
> > Thinking aloud, perhaps (for Debian and friends) maybe it belongs as a dependency brought in by a new koha-dev-tools package?
> > 
> > Regards,
> > 
> > Galen
> 
> 
> cool, thanks for the replies everyone :)
> 
> so, lets use both Smart::Comments and Data::Dumper
> 
> 
> hmmm, shall we start wrapping the loading of Koha debug modules in a 'if ($DEBUG) {use Smart::Comments}' type code block - as a performance tweak?
> 
> 
> would that work?

No because the use is called anyway, you can conditionally use a use
call. You would need to do require and import.

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/20120122/f9930ee0/attachment.pgp>

From gmc at esilibrary.com  Sun Jan 22 22:40:07 2012
From: gmc at esilibrary.com (Galen Charlton)
Date: Sun, 22 Jan 2012 15:40:07 -0600
Subject: [Koha-devel] add the Smart::Comments perl module to Koha,
	a good idea?
In-Reply-To: <20120122054008.GD5534@rorohiko.wgtn.cat-it.co.nz>
References: <E9EA3709-8746-485B-9ED4-B419F33052B8@kohaaloha.com>
	<92F32793-12CD-48D8-8160-E4CF5BE4AD12@esilibrary.com>
	<1B32F5C7-E4C6-402B-A296-13F9FEA5CC05@kohaaloha.com>
	<20120122054008.GD5534@rorohiko.wgtn.cat-it.co.nz>
Message-ID: <0796A9E9-FC46-4991-BFFA-F65788AEFFDC@esilibrary.com>

Hi,

On Jan 21, 2012, at 11:40 PM, Chris Cormack wrote:
> * Mason James (mtj at kohaaloha.com) wrote:
>> hmmm, shall we start wrapping the loading of Koha debug modules in a 'if ($DEBUG) {use Smart::Comments}' type code block - as a performance tweak?
>> 
>> 
>> would that work?
> 
> No because the use is called anyway, you can conditionally use a use
> call. You would need to do require and import.

_Cannot_ conditionally use a use call, I assume. 

Mason: "use Foo;" is equivalent to

BEGIN {
   require Foo;
   import Foo;
};

The implicit BEGIN block is why one can put a use call anywhere in the source file, including after code that makes use of the module one is use'ing.

Regards,

Galen
--
Galen Charlton
Director of Support and Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org


From mtj at kohaaloha.com  Mon Jan 23 03:22:33 2012
From: mtj at kohaaloha.com (Mason James)
Date: Mon, 23 Jan 2012 15:22:33 +1300
Subject: [Koha-devel] add the Smart::Comments perl module to Koha,
	a good idea?
In-Reply-To: <0796A9E9-FC46-4991-BFFA-F65788AEFFDC@esilibrary.com>
References: <E9EA3709-8746-485B-9ED4-B419F33052B8@kohaaloha.com>
	<92F32793-12CD-48D8-8160-E4CF5BE4AD12@esilibrary.com>
	<1B32F5C7-E4C6-402B-A296-13F9FEA5CC05@kohaaloha.com>
	<20120122054008.GD5534@rorohiko.wgtn.cat-it.co.nz>
	<0796A9E9-FC46-4991-BFFA-F65788AEFFDC@esilibrary.com>
Message-ID: <B06408A3-A1FA-43CE-B432-0ACA21FD5C65@kohaaloha.com>


On 2012-01-23, at 10:40 AM, Galen Charlton wrote:

> Hi,
> 
> On Jan 21, 2012, at 11:40 PM, Chris Cormack wrote:
>> * Mason James (mtj at kohaaloha.com) wrote:
>>> hmmm, shall we start wrapping the loading of Koha debug modules in a 'if ($DEBUG) {use Smart::Comments}' type code block - as a performance tweak?
>>> 
>>> 
>>> would that work?
>> 
>> No because the use is called anyway, you can conditionally use a use
>> call. You would need to do require and import.
> 
> _Cannot_ conditionally use a use call, I assume. 
> 
> Mason: "use Foo;" is equivalent to
> 
> BEGIN {
>   require Foo;
>   import Foo;
> };
> 
> The implicit BEGIN block is why one can put a use call anywhere in the source file, including after code that makes use of the module one is use'ing.
> 

aaah, yep - thats sounds very familiar to me :p


hmmm, would using 'Module::Load::Conditional' be a nice clean way to conditionally load debug modules when needed?

http://search.cpan.org/dist/Module-Load-Conditional/lib/Module/Load/Conditional.pm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 535 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20120123/591c793a/attachment.pgp>

From mtj at kohaaloha.com  Tue Jan 24 02:20:01 2012
From: mtj at kohaaloha.com (Mason James)
Date: Tue, 24 Jan 2012 14:20:01 +1300
Subject: [Koha-devel] [Koha-bugs] [Bug 7098] powered by koha not styled
	on sco
In-Reply-To: <bug-7098-70-A8LTpu09xF@http.bugs.koha-community.org/bugzilla3/>
References: <bug-7098-70@http.bugs.koha-community.org/bugzilla3/>
	<bug-7098-70-A8LTpu09xF@http.bugs.koha-community.org/bugzilla3/>
Message-ID: <19E2F3DC-D694-44F1-B26C-2DD18B8145CA@kohaaloha.com>


On 2012-01-24, at 6:12 AM, bugzilla-daemon at bugs.koha-community.org wrote:

> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7098
> 
> Paul Poulain <paul.poulain at biblibre.com> changed:
> 
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Status|Passed QA                   |Pushed to Master
>                 CC|                            |paul.poulain at biblibre.com
>            Version|master                      |rel_3_6


i just noticed Paul change the status here to 'Pushed to Master' - should this really not be a 'Pushed to Stable' change?


the 3.6 branch of Koha is currently the 'stable' branch? - with 3.8 (currently 'Master') being the 'Unstable' branch?
is that right??

so a status change to 'rel_3_6' is really a 'push-to-stable' change...
...not 'push-to-master' change?

no...? :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 535 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20120124/1b41a93e/attachment.pgp>

From cnighswonger at foundations.edu  Tue Jan 24 02:56:24 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Mon, 23 Jan 2012 20:56:24 -0500
Subject: [Koha-devel] [Koha-bugs] [Bug 7098] powered by koha not styled
	on sco
In-Reply-To: <19E2F3DC-D694-44F1-B26C-2DD18B8145CA@kohaaloha.com>
References: <bug-7098-70@http.bugs.koha-community.org/bugzilla3/>
	<bug-7098-70-A8LTpu09xF@http.bugs.koha-community.org/bugzilla3/>
	<19E2F3DC-D694-44F1-B26C-2DD18B8145CA@kohaaloha.com>
Message-ID: <CAP3yOo=D8xTryV=8P0fE2BH1RcpT=oUBw+5RxJd7d-w_w2P2hA@mail.gmail.com>

2012/1/23 Mason James <mtj at kohaaloha.com>

>
> On 2012-01-24, at 6:12 AM, bugzilla-daemon at bugs.koha-community.org wrote:
>
> > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7098
> >
> > Paul Poulain <paul.poulain at biblibre.com> changed:
> >
> >           What    |Removed                     |Added
> >
> ----------------------------------------------------------------------------
> >             Status|Passed QA                   |Pushed to Master
> >                 CC|                            |
> paul.poulain at biblibre.com
> >            Version|master                      |rel_3_6
>
>
> i just noticed Paul change the status here to 'Pushed to Master' - should
> this really not be a 'Pushed to Stable' change?
>

No...


>
>
> the 3.6 branch of Koha is currently the 'stable' branch? - with 3.8
> (currently 'Master') being the 'Unstable' branch?
> is that right??
>

Yes...


>
> so a status change to 'rel_3_6' is really a 'push-to-stable' change...
> ...not 'push-to-master' change?
>
> no...? :)
>

No... ;-)

Notice that the version was master when Paul marked pushed-to-master. At
the same time Paul changed the version to rel_3_6 which now tells the
RMaint (your's truly) that the commit needs to be backported to 3.6 branch.
Once I port the commit, I (or some kind volunteer) will change the status
to pushed-to-stable.

Clear as much? :)

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

From mtj at kohaaloha.com  Tue Jan 24 03:03:46 2012
From: mtj at kohaaloha.com (Mason James)
Date: Tue, 24 Jan 2012 15:03:46 +1300
Subject: [Koha-devel] [Koha-bugs] [Bug 7098] powered by koha not styled
	on sco
In-Reply-To: <CAP3yOo=D8xTryV=8P0fE2BH1RcpT=oUBw+5RxJd7d-w_w2P2hA@mail.gmail.com>
References: <bug-7098-70@http.bugs.koha-community.org/bugzilla3/>
	<bug-7098-70-A8LTpu09xF@http.bugs.koha-community.org/bugzilla3/>
	<19E2F3DC-D694-44F1-B26C-2DD18B8145CA@kohaaloha.com>
	<CAP3yOo=D8xTryV=8P0fE2BH1RcpT=oUBw+5RxJd7d-w_w2P2hA@mail.gmail.com>
Message-ID: <EAB0FBCF-BA30-4E7F-9285-25223B5B3CA3@kohaaloha.com>


On 2012-01-24, at 2:56 PM, Chris Nighswonger wrote:

> 2012/1/23 Mason James <mtj at kohaaloha.com>
> 
> On 2012-01-24, at 6:12 AM, bugzilla-daemon at bugs.koha-community.org wrote:
> 
> > http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7098
> >
> > Paul Poulain <paul.poulain at biblibre.com> changed:
> >
> >           What    |Removed                     |Added
> > ----------------------------------------------------------------------------
> >             Status|Passed QA                   |Pushed to Master
> >                 CC|                            |paul.poulain at biblibre.com
> >            Version|master                      |rel_3_6
> 
> 
> i just noticed Paul change the status here to 'Pushed to Master' - should this really not be a 'Pushed to Stable' change?
> 
> No...
>  
> No... ;-)
> 
> Notice that the version was master when Paul marked pushed-to-master. At the same time Paul changed the version to rel_3_6 which now tells the RMaint (your's truly) that the commit needs to be backported to 3.6 branch. Once I port the commit, I (or some kind volunteer) will change the status to pushed-to-stable.
> 
> Clear as much? :)


yep!, i got it 

(and it makes good sense to me, too :p )
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 535 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20120124/b33b61db/attachment.pgp>

From mtj at kohaaloha.com  Tue Jan 24 06:27:18 2012
From: mtj at kohaaloha.com (Mason James)
Date: Tue, 24 Jan 2012 18:27:18 +1300
Subject: [Koha-devel] add the Smart::Comments perl module to Koha,
	a good idea?
In-Reply-To: <92F32793-12CD-48D8-8160-E4CF5BE4AD12@esilibrary.com>
References: <E9EA3709-8746-485B-9ED4-B419F33052B8@kohaaloha.com>
	<92F32793-12CD-48D8-8160-E4CF5BE4AD12@esilibrary.com>
Message-ID: <FB43538D-03C5-40DE-B4FF-8FAD80F074A3@kohaaloha.com>


On 2012-01-21, at 3:48 AM, Galen Charlton wrote:

> Hi,
> 
> On Jan 20, 2012, at 2:59 AM, Mason James wrote:
>> i think i'm gonna send a patch to add the S::C module as a Koha dependency, a good idea?
> 
> As an optional dependency, maybe.  But there's nothing stopping anybody from using it for their debugging now, right?
> 
> Smart::Comments is a source filter -- and consequently may cause a modest but measurable performance hit if it were enabled across the board -- and some cursory Googling suggests that it may not have played well with mod_perl in the past.  I don't know, and haven't yet tested, whether that's still the case, but I do think that should be checked before such a patch is accepted.

i was curious and did a google-search too...

looks like the thread below, is the only mention of smart::comments not behaving on mod-perl
http://www.perlmonks.org/?node_id=850248


and in the same thread, someone else challenges that idea, saying s::c looks mod-perl clean


> 
> Thinking aloud, perhaps (for Debian and friends) maybe it belongs as a dependency brought in by a new koha-dev-tools package?


so, if smart-comments works on mod-perl and we can use a system where the module is loaded only when $DBUG is set - it's a useful addition to Koha debugging


> 
> Regards,
> 
> Galen
> --
> Galen Charlton
> Director of Support and Implementation
> Equinox Software, Inc. / The Open Source Experts
> email:  gmc at esilibrary.com
> direct: +1 770-709-5581
> cell:   +1 404-984-4366
> skype:  gmcharlt
> web:    http://www.esilibrary.com/
> Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
> 


cheers, Mason
-- 
KohaAloha, NZ

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 535 bytes
Desc: This is a digitally signed message part
URL: </pipermail/koha-devel/attachments/20120124/7be644c3/attachment.pgp>

From danielg.koha at gmail.com  Thu Jan 26 01:51:23 2012
From: danielg.koha at gmail.com (Daniel Grobani)
Date: Wed, 25 Jan 2012 16:51:23 -0800
Subject: [Koha-devel] Official Koha Newsletter: Volume 3,
	Issue 1: January 2012
Message-ID: <CAOeKewge2Zwg9YB_xRjWLwf3nCTriq3j229Ad4FHdC=butY_qg@mail.gmail.com>

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

Official Koha Newsletter (ISSN 2153-8328)
Volume 3, Issue 1: January 2012

Edited by Daniel Grobani, Koha Community Newsletter Editor.

Please submit news items to danielg.koha at gmail.com.

Table of Contents

    Koha Development
        Koha 3.6.3 Status
        Koha 3.4.8 Status
        Database Schema Bugs
        PostgreSQL Support
    Koha Community
        New Koha Libraries
        Community Gossip
        Donum: a Norwegian Koha Co-op
        Catalyst Open Source Academy 2012
    Past Koha Events
        January General IRC Meeting
        Global Bug Squashing Day 2012-01-06
    Upcoming Koha Events
        February General IRC Meeting
        Global Bug Squashing Day 2012-02-08
        Marseille Hackfest
        KohaCon12

Koha Development

Koha 3.6.3 Status
by Chris Nighswonger

The 3.6.x branch is in a string freeze. Koha 3.6.3 is scheduled for
release on 25 January 2012.

Koha 3.4.8 Status
by Chris Nighswonger

Koha 3.4.8 is scheduled for release on 28 January 2012.

Database Schema Bugs

Paul Poulain and Jonathan Druart have created a new wiki page,
http://wiki.koha-community.org/wiki/DB_schema_bugs, documenting
problems they?ve identified with Koha?s database design. They invite
the community to read, add to, or discuss this page.

PostgreSQL Support

Marc Balmer plans to begin work on PostgreSQL support during the March
hackfest in Marseille in order to pave the way for future PostgreSQL
support in Koha. For more info, see
http://wiki.koha-community.org/wiki/PostgreSQL.
Koha Community

New Koha Libraries

    Bethel University (via ByWater Solutions)
    Mental Health and Education Resource Centre, Christchurch (via Catalyst)
    New Zealand Institute of Chartered Accountants (via Catalyst)
    246 libraries in the Philippines went live with Koha in the last
year. For more info, see http://web.nlp.gov.ph/nlp/?q=node/2300.

Community Gossip

ByWater Solutions has an opening for a Development Specialist.

Chris Cormack has posted a summary of Koha accomplishments in the year
2011 at http://blog.bigballofwax.co.nz/2012/01/01/2011-and-koha-by-the-numbers/.

Chris has also posted sign-off statistics for December at
http://blog.bigballofwax.co.nz/2012/01/23/sign-off-statistics-for-december/.

Nicole Engard has been promoted to Vice President of Education at
ByWater Solutions.

Melia Meggs has been promoted to Chief Operations Officer at ByWater Solutions.

Equinox Software has formed a Canadian subsidiary.

Ian Walls, Koha 3.8 QA manager, has left ByWater Solutions for a
position at the University of Massachusetts Amherst.

Bob and Irma Birchall from Calyx and Chris Cormack and Kathryn Tyree
from Catalyst will be holding a combined Koha stand at Vala2012 in
Melbourne from 6-9 February. For more info, see
http://www.vala.org.au/vala2012/conf2012.

Donum: a Norwegian Koha Co-op
by Magnus Enger

Donum ? Frie biblioteksystemer SA is a co-op that aims to further its
members? economic interests by cooperating in building, developing,
and managing software, translations, knowledge, and networks.

The co-op will also mediate relevant contracts and generate spin-offs
and user utility by helping to promote and increase knowledge about
free library systems and the values they build upon, both in the
private and public sector. It also aims to assist with the development
and delivery of services related to such systems.

The main activities will be to carry out, organize, maintain, and
quality check translations, as well as marketing, training and
development of Koha and other free software for the library sector in
Norway. The co-op will function as a network and maintainer of fora
and meeting places through activities such as organizing user
meetings, seminars, and conferences.

The co-op will benefit its members through prioritized and possibly
discounted access to training, conferences etc. It will also aid in
organizing cost-sharing for new developments related to relevant
software.

For more info, see http://donum.no/.

Catalyst Open Source Academy 2012
by Chris Hall, Chris Cormack, Grant Patterson, Javier Romero

Twenty-three high school students from around New Zealand took the
opportunity to learn more about open source software development
during their summer holidays by participating in the Catalyst Open
Source Academy 2012.

In the first week, the students learned to install Ubuntu Linux on
their training laptops, familiarised themselves with what the terms
Freedom and Community mean for open source projects, and learned basic
programming principles and how the web works.

During the second week students worked on an open source project of
their choosing. Amongst others there was a Koha group and a group who
worked on kiritakikoha, an Android app for Koha (system and end)
users.

Four students from the Koha project group used jQuery to create graphs
for many of the popular SQL reports at
http://wiki.koha-community.org/wiki/SQL_Reports_Library. A sample of
the graphs made by one student can be viewed at
http://opac.koha.workbuffer.org/. These can be adapted to graph almost
any SQL report and display it on the OPAC and/or the intranet.

The other two students working on the Koha project went through the
HTML test report page to improve unit testing coverage. The goal for
the week was to increase the percentage of unit testing coverage of
Koha by at least 2%, which they did!

By the end of the week the Koha project group had:

    Committed 16 unit tests
    Changed 300 lines of Koha code
    Tested 598 lines of Koha code not previously tested (+2.1%)
    Tested 85 subroutines not previously tested (+2.6%)

The group working on kiritakikoha made suggestions for future
improvements in the client and in its appearance, e.g. customised
icons for small devices. They worked collaboratively to implement the
following features:

    Splitting up the existing search interface into simple and advanced search
    Highlighting search terms in the search results
    Displaying book covers from OpenLibrary and Google in the search results
    Providing a date picker for the place hold dates
    Displaying currently checked out/overdue
    Improved support for low-resolution devices
    Importing library settings via a Quick Response code (2D barcodes
which upon scanning with a phone camera can configure kiritakikoha
with that library?s settings)

The Academy was an opportunity for these students to experience the
software development cycle within the open source community and to
make valuable contributions to open source projects.
Past Koha Events

January General IRC Meeting

The January general IRC meeting was held on 4 January 2012.

For more info, including the agenda and links to the minutes, see
http://wiki.koha-community.org/wiki/General_IRC_Meeting,_4_January_2012.

Global Bug Squashing Day 2012-01-06
by Magnus Enger

Global Bug Squashing Day 2012-01-06
by Magnus Enger

A Global bug squashing day was held on Friday, 6 January 2012, and
there was much rejoicing.

For the numbers, see
http://wiki.koha-community.org/wiki/2012-01-06_Global_bug_squashing_day.
Upcoming Koha Events

February General IRC Meeting

The February general IRC meeting will be held on 8 February 2012.

For more info, see
http://wiki.koha-community.org/wiki/General_IRC_Meeting,_8_February_2012.

Global Bug Squashing Day 2012-02-08
by Magnus Enger

Global Bug Squashing Days are days designated to a concerted effort to
get bugs and patches moving along in the right direction.

The next GBSD will be 8 February 2012. For more info, see
http://wiki.koha-community.org/wiki/2012-02-08_Global_bug_squashing_day.

Marseille Hackfest
by Paul Poulain

A reminder about the hackfest BibLibre is organizing in Marseille in March!

It?s time to book your flights/trains/car/horse/boat, and tell us if
you?re coming. We already have 6 people coming (plus all BibLibre
staff, of course) from 4 different countries (France, Germany,
Croatia, and USA). We have a lot of chairs and desktops still
available!

If you hope to come but still are not sure, don?t hesitate to email
kim.nguyen -at- biblibre.com.

Full details are at
http://drupal.biblibre.com/en/blog/entry/2012-hackfest-in-europe.

KohaCon12

KohaCon12 will take place this June in central Edinburgh, Scotland, UK.

The main conference will be held Tuesday, 5 June to Thursday, 7 June.

A hackfest will be held Saturday, 9 June to Monday, 11 June.

For more info, see
http://wiki.koha-community.org/wiki/Category:KohaCon12 and
http://wiki.koha-community.org/wiki/Wishlist_for_KohaCon12.

From cnighswonger at foundations.edu  Thu Jan 26 16:49:36 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Thu, 26 Jan 2012 10:49:36 -0500
Subject: [Koha-devel] Koha 3.6.3 is now available
Message-ID: <CAP3yOommMwdSGj6gxpYKMBO4BO4=8F540c=Jcr4szVXzezm8Dw@mail.gmail.com>

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

The package can be retrieved from:

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

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

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

Release notes for 3.6.3 are below.

Come and get it!

RELEASE NOTES FOR KOHA 3.6.3
26 Jan 2012
========================================================================

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

http://koha-community.org/

Koha 3.6.3 can be downloaded from:

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

Installation instructions can be found at:

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

OR in the INSTALL files that come in the tarball

Koha 3.6.3 is a bugfix/maintenance release.

Highlights of 3.6.3
======================

6627 blocker [security] insecure file creation
2830 critical Hold not removed when "trapped" item on hold shelf is
checked out to a different patron in the holds queue
3651 critical Require patron login to send shelves and baskets
5533 critical marking item lost diff in two places
6292 critical Overdue notices have a bug when multiple overdues exist
7193 critical can't remove end date from subscriptions
7360 critical Importing a SQL file for frameworks based on Default
Framework deletes the default framework
7370 critical Longoverdue cronjob claims Undefined subroutine &main::LostItem
7394 critical Broken detail page for last link from result page
7407 critical HidePatronName not working anymore
2012 major Add bilio crashes under no zebra
6302 major Failing to send email notices - to_address not set
7226 major Can't add tags on list
7282 major invalid language selection

Bugs fixed in 3.6.3
======================

2307 normal Calendar widget cannot be translated
3431 normal Catalog by itemtype report pulling from holdingbranch
4300 normal Display 866z summary holdings public note in OPAC
5226 normal MARC21 field 545 missing
5369 normal se queries with paranthesis fail
6098 normal zebra conf NSB NSE indexed as space
6142 normal CanBookBeReserved function is redefined in C4/ILSDI/Utility.pm
6374 normal Use "size" as names/hash keys leads to an unexpected
results when using Template::Toolkit (name of a virtual method there)
6466 normal hung socket read causes SIP tests to fail
6700 normal Better handling of version numbers in updatedatabase
6717 normal Sub total doubled up on borrower pay fines page
6885 normal Superlibrarian users can't delete items from another
library when IndependantBranches
7097 normal HidePatronName not hiding in all places
7266 normal overdue.pl : filter on flags "debarred" "suspended" and
"gonenoaddress" not working
7276 normal member entry Performance improvement
7277 normal keyword mapping needs spaces in the OPAC
7311 normal Error when records have UNIMARC 461$0 or 773$0 for
something other than bibnumber
7313 normal Untranslatable strings in 'search to hold' feature
7328 normal Expanded options in advanced search
7332 normal Translated title (MARC21 field 242) doesn't display
7338 normal link to serial detail wrong
7349 normal Sorting patron search result by cardnumber doesn't work
7356 normal Fix various typos and mis-spellings
7361 normal 'Default' encoding in staged marc import breaks diacritics
7363 normal Downloading a list in CSV format doesn't work
7381 normal wrong isbn showing on the staff search results
1623 enhancement Retain history of approved comments
3184 enhancement Show creator and budget receiving a document
5327 enhancement Unit tests required for all C4 modules
5565 enhancement Default OAI UNIMARC to Dublin Core XSL adds superfluous blanks
5607 enhancement Make fields from issues table available in overdues
5729 enhancement Add coins information to the intranet
6015 enhancement Enhancing the performance test suite
6193 enhancement Use memcached cache koha-conf.xml configuration variables
6787 enhancement NORMARC needs a Fast Add framework
6990 enhancement TransformKohaToMarc enhancement
7079 enhancement Default values for German system preferences (web installer)
7143 enhancement Bug for tracking changes to the about page
7220 enhancement Add IDs to check-in message dialogs to facilitate CSS
customization
7240 enhancement Cleaning up import tables and action_logs
7247 enhancement rebuild_zebra.pl -v should show all Zebra log output
7278 enhancement In the items table, make items.materials of type
text, and show its contents at circulation
7324 enhancement Show alternate email as mailto link on patron summary
7326 enhancement longoverdue.pl was hardcoded to 1 year, is now a parameter
7364 enhancement Fast-Add framework doesn't always get the branch for
item creation
7373 enhancement new bridge icons
7439 enhancement Mailmap for git shortlog
System requirements
======================

Changes since 3.4:

* Perl 5.10 is required
Documentation
======================

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

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

As of the date of these release notes, only the English version of the
Koha manual is available:

http://manual.koha-community.org/3.6/en/

The Git repository for the Koha manual can be found at

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

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

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

* Chinese (Taiwan)
* Danish
* English (USA)
* English (UK)
* French (France)
* German
* Italian
* Portuguese (Brazil)
* Spanish

Partial translations are available for various other languages.

The Koha team welcomes additional translations; please see

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

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

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

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

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

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

The release team for Koha 3.6 is

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

Release Maintainer (3.4.x):
Chris Nighswonger <cnighswonger at foundations.edu>
Release Maintainer (3.6.x):
Chris Nighswonger <cnighswonger at foundations.edu>



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

We thank the following libraries who are known to have sponsored
new features in Koha 3.6:
* Los Gatos Public Library
* NEKLS
* East Brunswick Public Library
* Athens County Public Libraries
* Horowhenua Library Trust
* Halton Borough Council
* South Taranaki District Council

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

1 Tomas Cohen Arazi
1 Alex Arnaud
2 Marc Balmer
2 D Ruth Bavousett
6 Jared Camins-Esakov
1 Fr?d?rick Capovilla
1 Garry Collum
15 Chris Cormack
1 Christophe Croullebois
8 Fr?d?ric Demians
3 Connor Dewar
2 Nicole Engard
2 Magnus Enger
14 Katrin Fischer
4 Chris Hall
1 Srdjan Jankovic
1 Admin User Koha
2 Henri-Damien Laurent
12 Owen Leonard
1 Fr?re S?bastien Marie
1 Jesse Maseto
1 James Mason
2 Julian Maurice
3 Sophie Meynieux
5 Chris Nighswonger
1 Albert Oller
1 Dobrica Pavlinusic
10 Paul Poulain
2 Liz Rea
7 Marcel de Rooy
1 Fridolyn SOMERS
1 Sam Sanders
5 Adrien Saurat
11 Duncan Tyler
5 Ian Walls
We regret any omissions. If a contributor has been inadvertantly missed,
please send a patch against these release notes to
koha-patches at lists.koha-community.org.

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

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

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

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

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

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

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

http://bugs.koha-community.org/
Ehara taku toa i te toa takitahi, engari he toa takitini

##### Autogenerated release notes updated last on 26 Jan 2012 15:06:56 Z #####

From cnighswonger at foundations.edu  Fri Jan 27 15:31:01 2012
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Fri, 27 Jan 2012 09:31:01 -0500
Subject: [Koha-devel] Koha 3.4.8 is now available
Message-ID: <CAP3yOomFaSoDddJP0wwh2mDUGL0SZUrxE-LbvcBUgeLc_e_arQ@mail.gmail.com>

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

The package can be retrieved from:

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

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

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

Release notes for 3.4.8 are below.

Come and get it!



RELEASE NOTES FOR KOHA 3.4.8
27 Jan 2012
========================================================================

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

http://koha-community.org/

Koha 3.4.8 can be downloaded from:

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

Highlights of 3.4.8
======================

6627 blocker [security] insecure file creation
2830 critical Hold not removed when "trapped" item on hold shelf is
checked out to a different patron in the holds queue
3651 critical Require patron login to send shelves and baskets
5533 critical marking item lost diff in two places
6292 critical Overdue notices have a bug when multiple overdues exist
7093 critical Placeholders for suggestion table in suggestion related
mails broken
7160 critical paying fines throws error
7193 critical can't remove end date from subscriptions
7316 critical Missing escaping in search results
7360 critical Importing a SQL file for frameworks based on Default
Framework deletes the default framework
7370 critical Longoverdue cronjob claims Undefined subroutine &main::LostItem
7407 critical HidePatronName not working anymore
2012 major Add bilio crashes under no zebra
6302 major Failing to send email notices - to_address not set
6923 major can't load help files
7202 major z39.50 search on bib edit not working
7226 major Can't add tags on list
7275 major Pagination lost when click in the option "Show more" of facets column
Bugs fixed in 3.4.8
======================

2307 normal Calendar widget cannot be translated
2534 normal Viewing items table on item edit screen requires
horizontal scrolling
3431 normal Catalog by itemtype report pulling from holdingbranch
5226 normal MARC21 field 545 missing
5369 normal se queries with paranthesis fail
6098 normal zebra conf NSB NSE indexed as space
6142 normal CanBookBeReserved function is redefined in C4/ILSDI/Utility.pm
6374 normal Use "size" as names/hash keys leads to an unexpected
results when using Template::Toolkit (name of a virtual method there)
6466 normal hung socket read causes SIP tests to fail
6700 normal Better handling of version numbers in updatedatabase
6717 normal Sub total doubled up on borrower pay fines page
6885 normal Superlibrarian users can't delete items from another
library when IndependantBranches
6917 normal Acquisitions reports: Dates filters doesn't work when they
are not selected on row or column
7097 normal HidePatronName not hiding in all places
7198 normal overdue report does not display patron name if firstname
and/or surname are null
7215 normal callnumber versus itemcallnumber
7245 normal Errors in MySQL tables population with mandatory data for
italian installation
7262 normal No calendar present in holidays module when there are
quotes in title or description
7276 normal member entry Performance improvement
7277 normal keyword mapping needs spaces in the OPAC
7287 normal overdue notification is processed several times if some
sites do not have rules
7313 normal Untranslatable strings in 'search to hold' feature
7332 normal Translated title (MARC21 field 242) doesn't display
7338 normal link to serial detail wrong
7349 normal Sorting patron search result by cardnumber doesn't work
7361 normal 'Default' encoding in staged marc import breaks diacritics
7363 normal Downloading a list in CSV format doesn't work
7381 normal wrong isbn showing on the staff search results
1623 enhancement Retain history of approved comments
2011 enhancement Link patron extra sort fields to authorized values
3184 enhancement Show creator and budget receiving a document
5327 enhancement Unit tests required for all C4 modules
5565 enhancement Default OAI UNIMARC to Dublin Core XSL adds superfluous blanks
5607 enhancement Make fields from issues table available in overdues
6193 enhancement Use memcached cache koha-conf.xml configuration variables
6663 enhancement would be nice to put ranges of dates in the calendar
6716 enhancement Database Documentation
6787 enhancement NORMARC needs a Fast Add framework
6865 enhancement Replace image-based gradient backgrounds with CSS3 gradients
6975 enhancement OPACBaseURL called as OPACBaseurl in many templates
7135 enhancement in addbiblio, make save button floating to have it on
always on screen
7139 enhancement Log circulation messags
7143 enhancement Bug for tracking changes to the about page
7159 enhancement Add branchcode to circulation.pl search
7164 enhancement add Koha history timeline tab to 'About' page
7197 enhancement ES translation of the Debian readme
7220 enhancement Add IDs to check-in message dialogs to facilitate CSS
customization
7240 enhancement Cleaning up import tables and action_logs
7247 enhancement rebuild_zebra.pl -v should show all Zebra log output
7309 enhancement Add NORMARCslim2intranetDetail.xsl for detail view in intranet
7324 enhancement Show alternate email as mailto link on patron summary
7326 enhancement longoverdue.pl was hardcoded to 1 year, is now a parameter
7373 enhancement new bridge icons
7439 enhancement Mailmap for git shortlog
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 individuals who contributed patches to
Koha 3.4.8 (The numeral in the first column represents the number
of patches included in this release):

1 Tomas Cohen Arazi
2 Alex Arnaud
1 Marc Balmer
3 Brendan
5 Jared Camins-Esakov
1 Fr?d?rick Capovilla
1 Galen Charlton
1 Garry Collum
17 Chris Cormack
2 Christophe Croullebois
7 Fr?d?ric Demians
3 Connor Dewar
8 Nicole Engard
3 Magnus Enger
12 Katrin Fischer
5 Chris Hall
1 Mason James
1 Srdjan Jankovic
1 Admin User Koha
1 Henri-Damien Laurent
20 Owen Leonard
1 Fr?re S?bastien Marie
1 Jesse Maseto
1 James Mason
2 Julian Maurice
4 Sophie Meynieux
3 Chris Nighswonger
1 Albert Oller
1 Dobrica Pavlinusic
9 Paul Poulain
3 Liz Rea
8 Marcel de Rooy
1 Fridolyn SOMERS
4 Adrien Saurat
1 Robin Sheat
2 Juan Sieira
11 Duncan Tyler
8 Ian Walls
We regret any omissions. If a contributor has been inadvertantly missed,
please send a patch against these release notes to
koha-patches at lists.koha-community.org.

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

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

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

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

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

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

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

http://bugs.koha-community.org/
Ehara taku toa i te toa takitahi, engari he toa takitini

##### Autogenerated release notes updated last on 27 Jan 2012 14:02:53 Z #####

From paul.poulain at biblibre.com  Fri Jan 27 16:01:47 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 27 Jan 2012 16:01:47 +0100
Subject: [Koha-devel] deafult for biblio.frameworkcode
In-Reply-To: <4F0AFD45.1040402@cilea.it>
References: <4F0AFD45.1040402@cilea.it>
Message-ID: <4F22BC5B.1050301@biblibre.com>

Le 09/01/2012 15:44, Zeno Tajoli a ?crit :
> Hi to all,
> 
> I want to add, in "Koha to MARC mapping"
> a link beetween the mysql field biblio.frameworkcode
> to a marc21 subfield.
> 
> I think it is useful to have this data in the marc record.
> I propose to use 997 $a.
> The tag 997 is an empty tag.
Seeing this message just now, sorry for the delay: Just a big warning =
be carefull that just mapping won't probably work well. It will need a
lot of testing, but I fear that, frameworkcode being managed not like
other fields, it won't work from scratch, you'll have to change many
things in the core of Koha.

Maybe I'm too anxious though... but just double or triple check !


-- 
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 Jan 27 16:07:18 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 27 Jan 2012 16:07:18 +0100
Subject: [Koha-devel] link_bibs_to_authorities.pl can corrupt  records
In-Reply-To: <5.2.1.1.2.20120106161856.00bea980@localhost>
References: <5.2.1.1.2.20120106151732.00bea128@localhost>
	<5.2.1.1.2.20120106111952.00bea128@stormy.ca>
	<CA+95qVSce+C4W8dQaO1SwQZ=+VeaaZitznMAo2g8eWqd8jDzKw@mail.gmail.com>
	<5.2.1.1.2.20120106151732.00bea128@localhost>
	<5.2.1.1.2.20120106161856.00bea980@localhost>
Message-ID: <4F22BDA6.4070902@biblibre.com>

Le 06/01/2012 22:45, Paul a ?crit :

Hi Paul, it's Paul ;-)

I don't understand what you mean here:
> (kudos to the development team, average LAN response time
> is down from 4.7 secs to well < 1 sec.)
Do you mean you have 4.7s response time on 3.2 and now have <1sec on 3.6
? I can't figure why you get a so big boost, I must have misunderstood
something !
-- 
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 Jan 27 16:12:41 2012
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 27 Jan 2012 16:12:41 +0100
Subject: [Koha-devel] RM monthly newsletter #2 (2012 january)
Message-ID: <4F22BEE9.3090706@biblibre.com>

Welcome to my 3rd RM monthly newsletter. There has been a *LOT* of
*important* things pushed this month.

Everybody should read this newsletter in detail.
If you're planning to submit patches, you *must*. If you're just a user
of Koha, there are some interesting announcements too, you can read it
as well !

==== Bugzilla news ====
There are 87 bugs waiting to be signed-off. That's too much ! and a
problem is that is seems that hard-to-test patches can be lost in the
wilderness for a long time. Small/easy patches are usually quickly
signed-off.
The patches to QA pile show a correct 30 patches. Unfortunatly, that's
the hardest ones too, as I QAed a lot of 'trivial' patches this month...

==== Bugzilla ====
Earlier this month Ian, our QA manager made important changes to our
bugzilla setup.
The "patch status" field has been removed in favor of the "status" field.
The previous "patch status" have all be moved to "status".
2 new status have been added:
  - in discussion = will be used when a patch need a deeper discussion
to see if it can/should be added into Koha. The discussion can be
functional (is the feature desirable in Koha ?) or technical (is the way
it's made OK ?) The "in discussion" bugs will be discussed on the
monthly meeting.
  - 'pushed to stable': pushed has been splitted in "pushed to master"
and "pushed to stable". The RMaint (Chris N. for now) will use "Pushed
to stable" when he pushed a patch to stable (3.6). The "pushed to
master" is used by me when pushing to master (for the future 3.8)

The only side effect of this bulkchange is that date of last change of
each bug has been reseted to the date of the bulkchange. That's annoying
if you want to see which patch to signoff is the oldest.

==== Coding guidelines ====
I've updated the code guideline page on the wiki
(http://wiki.koha-community.org/wiki/Coding_Guidelines)

I've removed all deprecated guidelines, and added some that we already
use, and that were not written.
I've added a general rule for QA:

General rule: if you submit code that fixes an existing code that
violates those guidelines, the QA can still be passed. You don't have to
fix everything. If you want to fix more than just your fix, to respect
current guidelines, you're welcomed of course. But in this case, please
to it in a 2nd patch, to have reviewers being able to distinguish easily
what's related to your bugfix and what is related to your
guidelines-violation fixing.

==== Important technical patches pushed ====
Some important internal changes have been pushed.
Those change won't be visible for users, but are important for developers

=== Date formatting & displaying ===
Chris has written a nice Template::Toolkit plugin that will take care of
date formatting for you.

Before the patch, you had to format dates before sending them to the
template, something like:
    my $entrydate = C4::Dates->new( $data->{'entrydate'}, 'iso' );
    $data->{'entrydate'} = $entrydate->output("syspref");
    # entrydate is now available
Now, you still can do it that way, but that would be a really bad idea:
just send the date as it's provided by mySQL (iso format), and, in the
template, write [% MyDate | $KohaDates %]
don't forget to put [% USE KohaDates %] at the beginning of your page to
tell Template::Toolkit you'll use this plugin.

What must/can be done now is ... update all code & templates displaying
dates to use this plugin !

Bug 7444 has been created to reflect all the patches that will be made
to switch to KohaDates template.

*Coding Guideline rule*
  * all new code displaying date *MUST* use this plugin
  * existing code can still use previous option, but cleaning is highly
welcomed

=== Datatable jquery plugin ===
We've decided some months ago to get rid of the various jquery plugins
we use to display large tables, in favor of Datatable.
Datatable has been pushed into master, with a first page using it
(patron reading record), and some documentation on the wiki
(http://wiki.koha-community.org/wiki/DataTables_HowTo)

*Coding guideline rule*
  * all new code displaying potentially large tables *MUST* use this
plugin (preferably the "server side processing" option)
  * existing code can still use old plugins, but cleaning is highly
welcomed !

==== Important functionnal patches pushed ====
Some patches that contains important new features have been pushed.
Don't hesitate to test them again and again if you've a sandbox. They'll
be available in Koha 3.8

=== UnwantedFields in member entry (bug 6190) ===
A new syspref now let you choose fields that you don't want to have in
patron forms. A very interesting feature as there are *many* fields
available.
Note that this is a syspref, so you can't remove some fields for a given
category and keep it for another. But that's a nice first step anyway !

=== Acquisition changes ===
Some changes, coming from the stuff made by BibLibre for StEtienne
university have been pushed:
  * show cancelled order in basket page (bug 5358): after the list of
orders, you now also have the list of cancelled lines, on every basket
  * late order management (bug 5347): Koha now keep track of how many
claims you've made on a given order line, and the date of the last
claim. The default claim notification has been updated and your claim
will have to be updated when upgrading to 3.8

The breakdown of budget spending has also been reintroduced (Bug 929) :
on acqui-home.pl page, on each budget you can now see how the budget has
been spent.

=== Local cover images (bug 1633) ===
You can now upload images to your biblios, that will be displayed as
cover image. You can also zoom on the image, and, if you've uploaded
more than just one, see all of them. This feature can be activated on
staff and OPAC independantly.

=== j2a.pl script ===
The j2a.pl script, that is in misc/cronjobs was previously very basic,
upgrading Childs to Adult (hardcoded category) when they reached 18. The
script now has many new option to make it much more usefull

==== Hackfest in Europe ====
Again, in case you missed the news BibLibre (my company, in case you
don't know) organize a hackfest in Marseille in March. More information
at http://drupal.biblibre.com/en/blog/entry/2012-hackfest-in-europe,
feel free to join, all attendees will get a special thanks on this
newsletter after the hackfest. We already have Owen coming from USA,
Marc, coming from Switzerland, Katrin coming from Germany, Dobrika and
Marijana coming from Croatia, and -probably- Zeno coming from Italy.
It's still time to join, don't hesitate anymore !!!


See you next month for the #4 and in the meantime, happy hacking !!!
-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

From tajoli at cilea.it  Fri Jan 27 17:02:02 2012
From: tajoli at cilea.it (Zeno Tajoli)
Date: Fri, 27 Jan 2012 17:02:02 +0100
Subject: [Koha-devel] deafult for biblio.frameworkcode
In-Reply-To: <4F22BC5B.1050301@biblibre.com>
References: <4F0AFD45.1040402@cilea.it> <4F22BC5B.1050301@biblibre.com>
Message-ID: <4F22CA7A.4080001@cilea.it>

Hi Paul and all,
Il 27/01/2012 16:01, Paul Poulain ha scritto:
>> I want to add, in "Koha to MARC mapping"
>> a link beetween the mysql field biblio.frameworkcode
>> to a marc21 subfield.
>>
>> I think it is useful to have this data in the marc record.
>> I propose to use 997 $a.
>> The tag 997 is an empty tag.
> Seeing this message just now, sorry for the delay: Just a big warning =
> be carefull that just mapping won't probably work well. It will need a
> lot of testing, but I fear that, frameworkcode being managed not like
> other fields, it won't work from scratch, you'll have to change many
> things in the core of Koha.
> 
> Maybe I'm too anxious though... but just double or triple check !

do you have any idea where can I start to check ?

At present I use 942$f linked with biblio.frameworkcode and I don't see
problems.

In fact I use it in mass import.
My MARC Bibliographic frameworks have a 942$f with a default value taken
from an authorized list, a different value fro every framework.
And catalogue don't change the value, so every update is a confirmation
of the first input.

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

From paul.a at aandc.org  Fri Jan 27 19:41:00 2012
From: paul.a at aandc.org (Paul)
Date: Fri, 27 Jan 2012 13:41:00 -0500
Subject: [Koha-devel] link_bibs_to_authorities.pl can corrupt   records
In-Reply-To: <4F22BDA6.4070902@biblibre.com>
References: <5.2.1.1.2.20120106161856.00bea980@localhost>
	<5.2.1.1.2.20120106151732.00bea128@localhost>
	<5.2.1.1.2.20120106111952.00bea128@stormy.ca>
	<CA+95qVSce+C4W8dQaO1SwQZ=+VeaaZitznMAo2g8eWqd8jDzKw@mail.gmail.com>
	<5.2.1.1.2.20120106151732.00bea128@localhost>
	<5.2.1.1.2.20120106161856.00bea980@localhost>
Message-ID: <5.2.1.1.2.20120127131446.06f198f0@localhost>

At 04:07 PM 1/27/2012 +0100, Paul Poulain wrote:
>Le 06/01/2012 22:45, Paul a ?crit :
>
>Hi Paul, it's Paul ;-)
>
>I don't understand what you mean here:
> > (kudos to the development team, average LAN response time
> > is down from 4.7 secs to well < 1 sec.)
>Do you mean you have 4.7s response time on 3.2 and now have <1sec on 3.6
>? I can't figure why you get a so big boost, I must have misunderstood
>something !

Bonjour cher homonyme,

It also involved a change in server, but other usage did not show anywhere 
near the same gain e.g. a mysql based ap to dynamically list our "used 
books for sale" from a static webpage went from 0.8 to 0.6 secs.  There 
could be some latency issues here, but I have tried to sort out why Koha 
improved so much, and while this is not definitive, here are some areas 
that we noted:

         - memcached appears to *not* have worked -- or at least not 
properly -- on 3.2.  I think this was a serious issue for zebra
         - I installed Apache as worker + fastcgi rather than prefork
         - we use a few custom modules (barcode and call number in 
particular).  For 3.2, we had used them as a subroutine of the standard 
Koha code -- now I have written them as standalone replacements.

Additionally, we have noticed that the "old" 3.2 which we still use as a 
sandbox and for training purposes, is getting slower and slower.  I am 
*guessing* that it's crud in the mysql which seems to retain a lot of 
"history" and/or I did not do a clean install after removing wine (a keen 
volunteer had installed that so as to be able to use MarcEdit which still 
didn't work), but have not yet had time to look in detail.

But the gain is still very real.  Our cataloguers' rate has improved 
dramatically (in part I am sure the psychological effect of a system that 
appears much slicker.)

Avec mes meilleurs voeux pour cette nouvelle ann?e,
Paul 


From bogus@does.not.exist.com  Wed Jan  4 10:30:06 2012
From: bogus@does.not.exist.com ()
Date: Wed, 04 Jan 2012 09:30:06 -0000
Subject: No subject
Message-ID: <mailman.26.1333723439.15477.koha-devel@lists.koha-community.org>

I will open separate bug)

2) smarter memoize with per-request and persistent cache

Existing memoize does not have correct cache invalidation under plack
(--max-requests is gross hack and I would recommend running only
anonymous OPAC with that ;-) so I will write alternative memoize which
will call unmemoize on each request. This mimics CGI, provides
performance improvement and should be safe to run.

Existing memoize_memcached functions will become memoize_persistent
which will be able to cache in memcache, shared memory (why run memcache
when you don't need to for small instances), Redis or DB_File (Ian
mentioned files). We could use Memoize::Expire for that purpose to keep
in-memory cache under control.

My goal it to have pluggable caching back-ends without changing Koha
code (or via system preference!)

Q: for this I will try to submit bug perl memoize function, together
with cache invalidation hooks needed to make it work under plack. OK?

I would really love to move to Redis (with which I have very good
experience since I'm original author of perl bindings ;-) mostly because
it has per-key cache invalidation which memcache lacks (and this
invalidates whole cache at once). Redis ability to lookup cache keys
using globs (e.g. *item*12342*) might help a *lot* in cache
invalidation.

memoize_persistant definitions should be accompanied with calls to
invalidation. I do agree that inserting new value into cache is better
solution so I will have that in mind.

3) caching of full database tables

This point is subtly different than memoize: sometimes we benefit from
caching whole data structure from database (frameworks, itemtypes,
languages, systempreferences) but in a way that allows us to retrieve single
items.

Another example are functions which would be memoizable but use some
kind of parameter ($opac, $user, $branch, $selected or so) which would
require to memoize whole structure again and again.

This is now we are using our $cache variables now.
I propose to move all of them to Koha::Persistent so we can do
full_size on that class to get memory usage and enable correct
invalidation in single place (per-request) or have proper invalidation
functions.

This is also a reason why sql_cache function tries to create proper
multi-level hash with cached values instead of just memoizing
$sth->fetchrow_hashref.

With proper invalidation those values might be stored in shared memory
so that all plack threads have access to them.

4) performance patches

Non-caching related but still important, like missing indexes or
my favorite example of this (so far):

Bug 7846 - get_batch_summary reimplements GROUP BY in perl code
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7846

(which needs SO :-)

5) testing and statistics

I do intend to run this code in production. To be honest, plack didn't
bright all performance improvements I was hoping for, and I think that
we can fix it in 3.10 release cycle (search page in my favorite one to
test with).

To achieve that, I will collect statistical data about cache usage
(hit/miss). I found it very valuable for developing so far and it's always
nice to have some idea how cache is performing.

I must say that developing under plack is a joy: fast page load time is
nice and you get used to it quite quickly, so slow parts of code pop up
even without DBIProfile or NYTProf :-)

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