From lculber at mdah.state.ms.us  Tue Feb  1 15:07:26 2011
From: lculber at mdah.state.ms.us (Linda Culberson)
Date: Tue, 01 Feb 2011 08:07:26 -0600
Subject: [Koha-devel] trying to maintain our control numbers as biblionumber
Message-ID: <4D48139E.5060507@mdah.state.ms.us>

  Our local perl guru has managed to load our control numbers into the 
biblio.biblionumber, biblioitems.biblionumber, and items.biblionumber,
However, it isn't matching the biblioitems.marcxml field for the 999 
subfield c.
I'm assuming it needs to match.
Right?

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



From gmcharlt at gmail.com  Tue Feb  1 15:20:46 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Tue, 1 Feb 2011 09:20:46 -0500
Subject: [Koha-devel] trying to maintain our control numbers as
	biblionumber
In-Reply-To: <4D48139E.5060507@mdah.state.ms.us>
References: <4D48139E.5060507@mdah.state.ms.us>
Message-ID: <AANLkTimRpbNBA3q8-awyeezXbJucQFyQ0Gk+Rdg7RqXT@mail.gmail.com>

Hi,

On Tue, Feb 1, 2011 at 9:07 AM, Linda Culberson
<lculber at mdah.state.ms.us> wrote:
> ?Our local perl guru has managed to load our control numbers into the
> biblio.biblionumber, biblioitems.biblionumber, and items.biblionumber,
> However, it isn't matching the biblioitems.marcxml field for the 999
> subfield c.
> I'm assuming it needs to match.
> Right?

Right.  You can run the batchRepairMissingBiblionumbers.pl batch job
to update the MARC and MARXML blobs.  After that, you should also
reindex your database using rebuild_zebra.pl.

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From lculber at mdah.state.ms.us  Tue Feb  1 15:24:01 2011
From: lculber at mdah.state.ms.us (Linda Culberson)
Date: Tue, 01 Feb 2011 08:24:01 -0600
Subject: [Koha-devel] trying to maintain our control numbers as
	biblionumber
In-Reply-To: <AANLkTimRpbNBA3q8-awyeezXbJucQFyQ0Gk+Rdg7RqXT@mail.gmail.com>
References: <4D48139E.5060507@mdah.state.ms.us>
	<AANLkTimRpbNBA3q8-awyeezXbJucQFyQ0Gk+Rdg7RqXT@mail.gmail.com>
Message-ID: <4D481781.8030004@mdah.state.ms.us>

  That helps a great deal, Galen. Thanks!

On 2/1/2011 8:20 AM, Galen Charlton wrote:
> Hi,
>
> On Tue, Feb 1, 2011 at 9:07 AM, Linda Culberson
> <lculber at mdah.state.ms.us>  wrote:
>> ? Our local perl guru has managed to load our control numbers into the
>> biblio.biblionumber, biblioitems.biblionumber, and items.biblionumber,
>> However, it isn't matching the biblioitems.marcxml field for the 999
>> subfield c.
>> I'm assuming it needs to match.
>> Right?
> Right.  You can run the batchRepairMissingBiblionumbers.pl batch job
> to update the MARC and MARXML blobs.  After that, you should also
> reindex your database using rebuild_zebra.pl.
>
> Regards,
>
> Galen

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




From nengard at gmail.com  Wed Feb  2 13:32:04 2011
From: nengard at gmail.com (Nicole Engard)
Date: Wed, 2 Feb 2011 07:32:04 -0500
Subject: [Koha-devel] Vote for KohaCon 2011
Message-ID: <AANLkTi=9097=wTxq=5OgDq6MqGYWWNBMK3UG=DN0mWLC@mail.gmail.com>

Hello all,

I have published the official vote for the location of KohaCon 2011.
The vote will remain open until the 17th of February (EST).  Please
enter one vote per person and rank your options with your most
favorite as 1 and your least favorite as 4. If you won't go somewhere
no matter what then don't vote for that location.  Read the proposals
before you vote:
http://wiki.koha-community.org/wiki/KohaCon2011_Proposals

Vote here: http://survey.web2learning.net/limesurvey/index.php?sid=15529&lang=en

Thanks
Nicole C. Engard
Documentation Manager

From mjr at phonecoop.coop  Wed Feb  2 16:00:08 2011
From: mjr at phonecoop.coop (MJ Ray)
Date: Wed,  2 Feb 2011 15:00:08 +0000 (GMT)
Subject: [Koha-devel] [Koha] Vote for KohaCon 2011
In-Reply-To: <afc10fa1123fca410ccb5aa67f0fb494.squirrel@wmail.agogme.com>
Message-ID: <20110202150008.3383E5028C@nail.towers.org.uk>

Thomas Dukleth wrote:
> I would appreciate people adding some informal range of expected
> accommodation prices either to the wiki,
> http://wiki.koha-community.org/wiki/KohaCon2011_Proposals , or on the
> mailing list.

I've done this for the UK offer. I estimate median hotel price is
?65/room/night and lowest I've seen so far is ?18.  Restaurant dinners
are mostly ?15-?50/person, a good take-away meal is ?5/person, a
bad one is cheaper ;-) and you can, of course, spend much much more!

That's all assuming we're in the seaside resort rather than the city,
but it should be do-able.

It would be nice to have more links to hotels at least from the other
venues besides us and Kolkata, too.

Regards,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire for Koha work http://www.software.coop/products/koha

From kmkale at anantcorp.com  Thu Feb  3 07:17:11 2011
From: kmkale at anantcorp.com (Koustubha Kale)
Date: Thu, 3 Feb 2011 11:47:11 +0530
Subject: [Koha-devel] [Koha] Vote for KohaCon 2011
In-Reply-To: <20110202150008.3383E5028C@nail.towers.org.uk>
References: <afc10fa1123fca410ccb5aa67f0fb494.squirrel@wmail.agogme.com>
	<20110202150008.3383E5028C@nail.towers.org.uk>
Message-ID: <AANLkTik8CD4fm9aQWq0BuLd=Y+9mzvx2KS4t=QbuZ9C6@mail.gmail.com>

Hi,
I have updated the information at
http://wiki.koha-community.org/wiki/KohaCon2011_Proposals for VPM, Thane, India.

Also thanks to Thomas Dukleth for updating some information..

Regards,
Koustubha Kale
Anant Corporation

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

From ecarrazana at uci.cu  Thu Feb  3 17:48:16 2011
From: ecarrazana at uci.cu (Edisnel Carrazana Castro)
Date: Thu, 3 Feb 2011 11:48:16 -0500 (CST)
Subject: [Koha-devel] Save user visits in Opac
In-Reply-To: <204057158.153151296751318348.JavaMail.root@ucimail1.uci.cu>
Message-ID: <338669340.157151296751696185.JavaMail.root@ucimail1.uci.cu>


  I want to register in a table the user visits to the site after logged in. In wich place of the source code of Koha can I do that? 

I push the function to insert the visit in a page [in opac-user.pl] , but several insertions occur 
whenever this page is accessed. What can I do?

Thanks

From tomascohen at gmail.com  Thu Feb  3 18:17:55 2011
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Thu, 3 Feb 2011 14:17:55 -0300
Subject: [Koha-devel] Save user visits in Opac
In-Reply-To: <338669340.157151296751696185.JavaMail.root@ucimail1.uci.cu>
References: <204057158.153151296751318348.JavaMail.root@ucimail1.uci.cu>
	<338669340.157151296751696185.JavaMail.root@ucimail1.uci.cu>
Message-ID: <AANLkTi=MU0aTB1RuvBSvikhLpiUEJ1ZcJzBhcq_qjBpY@mail.gmail.com>

On Thu, Feb 3, 2011 at 1:48 PM, Edisnel Carrazana Castro
<ecarrazana at uci.cu> wrote:
>
> ?I want to register in a table the user visits to the site after logged in. In wich place of the source code of Koha can I do that?
>
> I push the function to insert the visit in a page [in opac-user.pl] , but several insertions occur
> whenever this page is accessed. What can I do?

If I was you, I would rather enable the apache's access log and
process it from the outside with some specialized tool like awstats.
That way you can be sure you count several visits as different ones
and such.

If you want to do it visit-then-insert-into-table, the I would create
a page (the language you prefer) and call it from a javascript
function in 'opacuserjs' configuration variable. You can even use
Google Analytics the same way.

To+

From nfredsell at gmail.com  Mon Feb  7 16:00:04 2011
From: nfredsell at gmail.com (Nelson Fredsell)
Date: Mon, 7 Feb 2011 10:00:04 -0500
Subject: [Koha-devel] Install hurdle, OpenSUSE on virtualbox
Message-ID: <001f01cbc6d7$b4e55db0$1eb01910$@com>

Dear all,

I've been repeatedly working through install steps at
http://wiki.koha-community.org/wiki/Koha_3.0.0_on_openSUSE_11.3, and keep
getting stuck.  Currently, my Windows 7 laptop can't see the apache LAMP
server on the OpenSUSE 11.3 virtualbox.  With ifconfig I can see eth0 inet
addr 192.168.1.16 Bcast 192.168.1.255 Mask 255.255.255.0.  When I ping from
the Windows side, I get request timed out.  As indicated in the steps, I
have a minimum install with no gui.  Using yast to configure network.

As an added step I changed from NAT to Bridged adapter in the VirtualBox
config, but this didn't help.

Any suggestions would be much appreciated.  My current goal w/ Koha is to
"simply" install the software, including Zebra.

Nelson
(nfred - irc)




From oleonard at myacpl.org  Mon Feb  7 16:06:03 2011
From: oleonard at myacpl.org (Owen Leonard)
Date: Mon, 7 Feb 2011 10:06:03 -0500
Subject: [Koha-devel] Install hurdle, OpenSUSE on virtualbox
In-Reply-To: <001f01cbc6d7$b4e55db0$1eb01910$@com>
References: <001f01cbc6d7$b4e55db0$1eb01910$@com>
Message-ID: <AANLkTinYaa4xtZ02FmS358V+xKnr_he_U=Bhh3tZC8nw@mail.gmail.com>

> Currently, my Windows 7 laptop can't see the apache LAMP
> server on the OpenSUSE 11.3 virtualbox.

This is not a problem with Koha installation, this is a problem with
VirtualBox. I would recommend asking your question in their forum:

http://forums.virtualbox.org/

Why not work on your Koha installation problems at the same time? Ask
here about those while you're waiting to figure out your VirtualBox
problems.

  -- Owen


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

From reedwade at gmail.com  Mon Feb  7 19:06:10 2011
From: reedwade at gmail.com (Reed Wade)
Date: Tue, 8 Feb 2011 07:06:10 +1300
Subject: [Koha-devel] Install hurdle, OpenSUSE on virtualbox
In-Reply-To: <AANLkTinYaa4xtZ02FmS358V+xKnr_he_U=Bhh3tZC8nw@mail.gmail.com>
References: <001f01cbc6d7$b4e55db0$1eb01910$@com>
	<AANLkTinYaa4xtZ02FmS358V+xKnr_he_U=Bhh3tZC8nw@mail.gmail.com>
Message-ID: <AANLkTimKzv882Ogw7GqZ8_fWiwdb2cDJz9vGbbxKmSV0@mail.gmail.com>

is getting slightly off the Koha topic but--

I tend to set up 2 network devices. One set for NAT and the other for
Host-Only. The NAT interface normally gets a 10.x.x.x address
(assigned via dhcp)and allows the guest OS to reach out to the outside
world and get software updates and for other outgoing things. The
Host-Only device normally gets a 192.x.x.x address assigned via dhcp
and is used to connect inbound from the host machine.

-reed


On Tue, Feb 8, 2011 at 4:06 AM, Owen Leonard <oleonard at myacpl.org> wrote:
>> Currently, my Windows 7 laptop can't see the apache LAMP
>> server on the OpenSUSE 11.3 virtualbox.
>
> This is not a problem with Koha installation, this is a problem with
> VirtualBox. I would recommend asking your question in their forum:
>
> http://forums.virtualbox.org/
>
> Why not work on your Koha installation problems at the same time? Ask
> here about those while you're waiting to figure out your VirtualBox
> problems.
>
> ?-- Owen
>
>
> --
> Web Developer
> Athens County Public Libraries
> http://www.myacpl.org
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>

From nengard at gmail.com  Tue Feb  8 04:14:33 2011
From: nengard at gmail.com (Nicole Engard)
Date: Mon, 7 Feb 2011 19:14:33 -0800
Subject: [Koha-devel] Call for Articles: February Newsletter
Message-ID: <AANLkTik4_pEkve76TX6guxZtCvwioyOb91JF1mddRTfa@mail.gmail.com>

Hi all,

It's that time again - please get me your newsletter articles by the
23rd (your time zone) of February so that I can include them in the
newsletter.

Thanks a bunch,
Nicole C. Engard

From henridamien.laurent at biblibre.com  Tue Feb  8 10:05:44 2011
From: henridamien.laurent at biblibre.com (LAURENT Henri-Damien)
Date: Tue, 08 Feb 2011 10:05:44 +0100
Subject: [Koha-devel] Workgroup on data persistence
Message-ID: <4D510768.2070401@biblibre.com>

Hi
back in 2010, we talked about data persistance.
And soon release is coming soon.
So it is now time we make something about Data Persistance.
Some tests have been done.
Some results can be used.
I propose we set some meeting next week any day in the morning between
8AM UTC to 12AM UTC.
I donot set up a doodle. You can answer this message, I will try to
gather trends.
Hope that helps.
-- 
Henri-Damien LAURENT

From henridamien.laurent at biblibre.com  Tue Feb  8 10:29:08 2011
From: henridamien.laurent at biblibre.com (LAURENT Henri-Damien)
Date: Tue, 08 Feb 2011 10:29:08 +0100
Subject: [Koha-devel] Solr and Z3950 server some news.
Message-ID: <4D510CE4.70409@biblibre.com>

Hi
We are getting a pretty nice working z3950 server for solr there.
We are parsing RPN queries quite generally using a perl module
Regexp::Grammars::Z3950::RPN
and  RPN2Solr
It is working quite well for simple usage (no exp1 or gils queries).

But at the moment it is serving right only marcxml and not ISO2709. I
think we may have to try and determine exactly what type of data the
Z3950 server is supposed to send to yaz-client when serving "MARC" data.
It comes with the wip/solr branch.
I hope I will be able to add some information as of how to set a box on
that branch soon.
Hope that helps.
-- 
Henri-Damien LAURENT

From paul.poulain at biblibre.com  Tue Feb  8 10:56:23 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Tue, 08 Feb 2011 10:56:23 +0100
Subject: [Koha-devel] Introducing Marc::Loader
Message-ID: <4D511347.3030000@biblibre.com>

Hello,

We are happy (and proud) to announce the release of MARC::Loader 0.001001
It's a small lirary that transforms a hash into a MARC record.

http://search.cpan.org/~reiveune/MARC-Loader-0.001001/lib/MARC/Loader.pm

Feedback is welcomed either here or directly at perl at biblibre.com

We plan to release some/many other tools around MARC in the next months.
They are tools we use internally for our migrations.

Hoping that will be usefull for many ppl !

(you can send congratulations to Stephane D: That's its first cpan
contribution ;-) )

-- 
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  Tue Feb  8 11:42:59 2011
From: mjr at phonecoop.coop (MJ Ray)
Date: Tue,  8 Feb 2011 10:42:59 +0000 (GMT)
Subject: [Koha-devel] Workgroup on data persistence
In-Reply-To: <4D510768.2070401@biblibre.com>
Message-ID: <20110208104259.5E0005028C@nail.towers.org.uk>

LAURENT Henri-Damien <henridamien.laurent at biblibre.com>
> So it is now time we make something about Data Persistance.
> Some tests have been done.
> Some results can be used.
> I propose we set some meeting next week any day in the morning between
> 8AM UTC to 12AM UTC.

I would prefer Monday, Tuesday or Friday (strongly), 10-12 (weakly).

Hope that helps,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire for Koha work http://www.software.coop/products/koha

From bmb at mail.libs.uga.edu  Tue Feb  8 14:41:41 2011
From: bmb at mail.libs.uga.edu (Brad Baxter)
Date: Tue, 8 Feb 2011 08:41:41 -0500
Subject: [Koha-devel] Introducing Marc::Loader
In-Reply-To: <4D511347.3030000@biblibre.com>
References: <4D511347.3030000@biblibre.com>
Message-ID: <AANLkTin4zyS3iqZXKwn5hj5AsvPG8a=Dwdhs9hJf=j65@mail.gmail.com>

Hello,

I wonder why the hash structure you're proposing
doesn't match the MARC-in-JSON proposal,

http://dilettantes.code4lib.org/blog/2010/09/a-proposal-to-serialize-marc-in-json/

At first glance, it looks to me that your structure
can't retain the order of fields or subfields.

I realize that it's a first release, but it looks like
the source is using modules that it isn't, well,
using, e.g.,  YAML, Carp, Scalar::Util::reftype.
But I may have missed something.

Regards,

Brad

On Tue, Feb 8, 2011 at 4:56 AM, Paul Poulain <paul.poulain at biblibre.com> wrote:
> Hello,
>
> We are happy (and proud) to announce the release of MARC::Loader 0.001001
> It's a small lirary that transforms a hash into a MARC record.
>
> http://search.cpan.org/~reiveune/MARC-Loader-0.001001/lib/MARC/Loader.pm
>
> Feedback is welcomed either here or directly at perl at biblibre.com
>
> We plan to release some/many other tools around MARC in the next months.
> They are tools we use internally for our migrations.
>
> Hoping that will be usefull for many ppl !
>
> (you can send congratulations to Stephane D: That's its first cpan
> contribution ;-) )
>
> --
> Paul POULAIN
> http://www.biblibre.com
> Expert en Logiciels Libres pour l'info-doc
> Tel : (33) 4 91 81 35 08
>
>

From oleonard at myacpl.org  Tue Feb  8 17:46:51 2011
From: oleonard at myacpl.org (Owen Leonard)
Date: Tue, 8 Feb 2011 11:46:51 -0500
Subject: [Koha-devel] Seeking comments on Bug 5234 - Remove unused CSS files
Message-ID: <AANLkTimYGn4r9vsHF7Z6DDQEgRd6S4RFn9E5Hure8D=i@mail.gmail.com>

These CSS files look like they're a relic of pre-3.0 days:

intranet-print.css
intranet.css
intranet2.css
intranet2popup.css

This one hasn't been touched sine 2007:

staff-global2.css

...Is it used by anyone?

What about blue.css?

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

Thanks,

  Owen

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

From ian.walls at bywatersolutions.com  Tue Feb  8 18:14:42 2011
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Tue, 8 Feb 2011 12:14:42 -0500
Subject: [Koha-devel] Seeking comments on Bug 5234 - Remove unused CSS
	files
In-Reply-To: <AANLkTimYGn4r9vsHF7Z6DDQEgRd6S4RFn9E5Hure8D=i@mail.gmail.com>
References: <AANLkTimYGn4r9vsHF7Z6DDQEgRd6S4RFn9E5Hure8D=i@mail.gmail.com>
Message-ID: <AANLkTi=x_WGE273-VPBQsgT6gR+Yq4n+uMTuGXYhRoeJ@mail.gmail.com>

Owen,


I know one library that uses blue.css.  It either needs some work, or they
need to use intranetusercss to do the eye-pleasing colour change.


-Ian

On Tue, Feb 8, 2011 at 11:46 AM, Owen Leonard <oleonard at myacpl.org> wrote:

> These CSS files look like they're a relic of pre-3.0 days:
>
> intranet-print.css
> intranet.css
> intranet2.css
> intranet2popup.css
>
> This one hasn't been touched sine 2007:
>
> staff-global2.css
>
> ...Is it used by anyone?
>
> What about blue.css?
>
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5234
>
> Thanks,
>
>  Owen
>
> --
> Web Developer
> Athens County Public Libraries
> http://www.myacpl.org
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



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

From bob at calyx.net.au  Tue Feb  8 22:12:57 2011
From: bob at calyx.net.au (Bob Birchall)
Date: Wed, 09 Feb 2011 08:12:57 +1100
Subject: [Koha-devel] Seeking comments on Bug 5234 - Remove unused CSS
 files
In-Reply-To: <AANLkTi=x_WGE273-VPBQsgT6gR+Yq4n+uMTuGXYhRoeJ@mail.gmail.com>
References: <AANLkTimYGn4r9vsHF7Z6DDQEgRd6S4RFn9E5Hure8D=i@mail.gmail.com>
	<AANLkTi=x_WGE273-VPBQsgT6gR+Yq4n+uMTuGXYhRoeJ@mail.gmail.com>
Message-ID: <4D51B1D9.8060007@calyx.net.au>

We also have one client using blue.css but they intend to change back at 
the next upgrade.

Bob Birchall
Calyx


On 09/02/11 04:14, Ian Walls wrote:
> Owen,
>
>
> I know one library that uses blue.css.  It either needs some work, or
> they need to use intranetusercss to do the eye-pleasing colour change.
>
>
> -Ian
>
> On Tue, Feb 8, 2011 at 11:46 AM, Owen Leonard <oleonard at myacpl.org
> <mailto:oleonard at myacpl.org>> wrote:
>
>     These CSS files look like they're a relic of pre-3.0 days:
>
>     intranet-print.css
>     intranet.css
>     intranet2.css
>     intranet2popup.css
>
>     This one hasn't been touched sine 2007:
>
>     staff-global2.css
>
>     ...Is it used by anyone?
>
>     What about blue.css?
>
>     http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5234
>
>     Thanks,
>
>       Owen

From laurenthdl at alinto.com  Tue Feb  8 22:18:25 2011
From: laurenthdl at alinto.com (LAURENT Henri-Damien)
Date: Tue, 08 Feb 2011 22:18:25 +0100
Subject: [Koha-devel] Seeking comments on Bug 5234 - Remove unused CSS
 files
In-Reply-To: <AANLkTi=x_WGE273-VPBQsgT6gR+Yq4n+uMTuGXYhRoeJ@mail.gmail.com>
References: <AANLkTimYGn4r9vsHF7Z6DDQEgRd6S4RFn9E5Hure8D=i@mail.gmail.com>
	<AANLkTi=x_WGE273-VPBQsgT6gR+Yq4n+uMTuGXYhRoeJ@mail.gmail.com>
Message-ID: <4D51B321.1010505@alinto.com>

Hi
blue.css was left quite unmaintained, though it brought along more
colors and therefore was warmer.
But well would need work.
-- 
Henri-Damien LAURENT
BibLibre

Le 08/02/2011 18:14, Ian Walls a ?crit :
> Owen,
> 
> 
> I know one library that uses blue.css.  It either needs some work, or
> they need to use intranetusercss to do the eye-pleasing colour change.
> 
> 
> -Ian
> 
> On Tue, Feb 8, 2011 at 11:46 AM, Owen Leonard <oleonard at myacpl.org
> <mailto:oleonard at myacpl.org>> wrote:
> 
>     These CSS files look like they're a relic of pre-3.0 days:

> 
>     intranet-print.css
>     intranet.css
>     intranet2.css
>     intranet2popup.css
> 
>     This one hasn't been touched sine 2007:
> 
>     staff-global2.css
> 
>     ...Is it used by anyone?
> 
>     What about blue.css?
> 
>     http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5234
> 
>     Thanks,
> 
>      Owen
> 


From paul.poulain at biblibre.com  Wed Feb  9 09:22:31 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 09 Feb 2011 09:22:31 +0100
Subject: [Koha-devel] Seeking comments on Bug 5234 - Remove unused CSS
 files
In-Reply-To: <4D51B321.1010505@alinto.com>
References: <AANLkTimYGn4r9vsHF7Z6DDQEgRd6S4RFn9E5Hure8D=i@mail.gmail.com>	<AANLkTi=x_WGE273-VPBQsgT6gR+Yq4n+uMTuGXYhRoeJ@mail.gmail.com>
	<4D51B321.1010505@alinto.com>
Message-ID: <4D524EC7.3020104@biblibre.com>

Le 08/02/2011 22:18, LAURENT Henri-Damien a ?crit :
> Hi
> blue.css was left quite unmaintained, though it brought along more
> colors and therefore was warmer.
> But well would need work.
My opinion is that the standard "white and black" colors are not fancy
enough.
I changed my mind on this subject : I thought fancyness was just
something for tv ppl that must hide their emptyness behing fancy colors.
I still think that in fact. But when competing another ILS in a RFP,
when the librarians have a demo, I have heard some librarians saying
"your interface is sad, more colors/pictures would be better,..."
I know *for sure* we already have lost one RFP just because of the look
of our librarian interface.
The library project manager was very annoyed by this reason, thinking
Koha was the best in terms of features, but the librarians were
convinced by another ILS, and the main reason was ... the colors.
I agree it's really stupid/silly/whatever you want, but I think we have
to deal with that : I think Koha 3.4 with a new librarian default color
style could be advertised as "we changed everything, look how fancy it
is", and that would work much better than "in Koha 3.4 we now have this
great feature".

So, the next question is, imo: who could write a nice&fancy color
stylesheet ? (no-one at BibLibre :( )

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


From paul.poulain at biblibre.com  Wed Feb  9 10:27:32 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Wed, 09 Feb 2011 10:27:32 +0100
Subject: [Koha-devel] Koha 3.4 sprint-week organised by BibLibre
Message-ID: <4D525E04.80602@biblibre.com>

Hello,

For those not following our blog, pls take a look at:
http://www.biblibre.com/en/blog/entry/koha-34-sprint-week-from-apr-4th-to-8th

All BibLibre will work on this sprint week, and we hope many ppl will
join us !

If someone in America,Oceania, Asia, Africa, or Artica  want to join, he
will be welcomed, but maybe it's even better to organize your own
sprint-week in your area ;-)

friendly

-- 
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  Wed Feb  9 14:36:49 2011
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Wed, 9 Feb 2011 08:36:49 -0500
Subject: [Koha-devel] Seeking comments on Bug 5234 - Remove unused CSS
	files
In-Reply-To: <4D524EC7.3020104@biblibre.com>
References: <AANLkTimYGn4r9vsHF7Z6DDQEgRd6S4RFn9E5Hure8D=i@mail.gmail.com>
	<AANLkTi=x_WGE273-VPBQsgT6gR+Yq4n+uMTuGXYhRoeJ@mail.gmail.com>
	<4D51B321.1010505@alinto.com> <4D524EC7.3020104@biblibre.com>
Message-ID: <AANLkTingaKoJwkAxWgAhNjvxHixWL_XEyoGoBrf09uOa@mail.gmail.com>

yes, unfortunately "how it looks" is a factor in the decision.  The OPAC
gets lots of attention, and there are some gorgeous ones out there, but not
a lot of folks customize the staff client, since just the librarains see it.

I'd love to spend more time on the staff interface, but I'm hardly a CSS
artist.  I'll happily test and provide feedback, and work in depth on small
details like rounded edges with CSS3 or adjusting margins, if anyone else
can provide the initial design.

I'd also like to see a new feature that allows librarians to upload their
own CSS file through the GUI.  Provide a template to download, them them go
to town, and then upload.  Same with XSLT, now that I mention it.


-Ian

On Wed, Feb 9, 2011 at 3:22 AM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Le 08/02/2011 22:18, LAURENT Henri-Damien a ?crit :
> > Hi
> > blue.css was left quite unmaintained, though it brought along more
> > colors and therefore was warmer.
> > But well would need work.
> My opinion is that the standard "white and black" colors are not fancy
> enough.
> I changed my mind on this subject : I thought fancyness was just
> something for tv ppl that must hide their emptyness behing fancy colors.
> I still think that in fact. But when competing another ILS in a RFP,
> when the librarians have a demo, I have heard some librarians saying
> "your interface is sad, more colors/pictures would be better,..."
> I know *for sure* we already have lost one RFP just because of the look
> of our librarian interface.
> The library project manager was very annoyed by this reason, thinking
> Koha was the best in terms of features, but the librarians were
> convinced by another ILS, and the main reason was ... the colors.
> I agree it's really stupid/silly/whatever you want, but I think we have
> to deal with that : I think Koha 3.4 with a new librarian default color
> style could be advertised as "we changed everything, look how fancy it
> is", and that would work much better than "in Koha 3.4 we now have this
> great feature".
>
> So, the next question is, imo: who could write a nice&fancy color
> stylesheet ? (no-one at BibLibre :( )
>
> --
> Paul POULAIN
> http://www.biblibre.com
> Expert en Logiciels Libres pour l'info-doc
> Tel : (33) 4 91 81 35 08
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



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

From dschust1 at gmail.com  Wed Feb  9 18:40:01 2011
From: dschust1 at gmail.com (David Schuster)
Date: Wed, 9 Feb 2011 11:40:01 -0600
Subject: [Koha-devel] Koha 3.4 sprint-week organised by BibLibre
In-Reply-To: <4D525E04.80602@biblibre.com>
References: <4D525E04.80602@biblibre.com>
Message-ID: <AANLkTi=cG6CX_cu7vhXMK+XHuzP5CKyMPpt11PSYqrLj@mail.gmail.com>

Wonderful idea!  Wish I could come, but then again I wouldn't be of much
use!  Well guess I could document and wrangle bugs!

David

On Wed, Feb 9, 2011 at 3:27 AM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Hello,
>
> For those not following our blog, pls take a look at:
>
> http://www.biblibre.com/en/blog/entry/koha-34-sprint-week-from-apr-4th-to-8th
>
> All BibLibre will work on this sprint week, and we hope many ppl will
> join us !
>
> If someone in America,Oceania, Asia, Africa, or Artica  want to join, he
> will be welcomed, but maybe it's even better to organize your own
> sprint-week in your area ;-)
>
> friendly
>
> --
> 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/
>



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

From chris at bigballofwax.co.nz  Wed Feb  9 18:41:21 2011
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Thu, 10 Feb 2011 06:41:21 +1300
Subject: [Koha-devel] Koha 3.4 sprint-week organised by BibLibre
In-Reply-To: <AANLkTi=cG6CX_cu7vhXMK+XHuzP5CKyMPpt11PSYqrLj@mail.gmail.com>
References: <4D525E04.80602@biblibre.com>
	<AANLkTi=cG6CX_cu7vhXMK+XHuzP5CKyMPpt11PSYqrLj@mail.gmail.com>
Message-ID: <AANLkTikJQtnXuZ5qrpMV6GzSdFEFM6Z=XoTCLQa4fYLF@mail.gmail.com>

2011/2/10 David Schuster <dschust1 at gmail.com>:
> Wonderful idea!? Wish I could come, but then again I wouldn't be of much
> use!? Well guess I could document and wrangle bugs!
>
>
You can do that anyway :) The sprint is a great idea, but we need
people testing and closing bugs NOW also :)

Chris

From dschust1 at gmail.com  Wed Feb  9 19:09:27 2011
From: dschust1 at gmail.com (David Schuster)
Date: Wed, 9 Feb 2011 12:09:27 -0600
Subject: [Koha-devel] Workgroup on data persistence
In-Reply-To: <20110208104259.5E0005028C@nail.towers.org.uk>
References: <4D510768.2070401@biblibre.com>
	<20110208104259.5E0005028C@nail.towers.org.uk>
Message-ID: <AANLkTik7=h7-tRGsgLhgpj1RL2CNaaQUmAnYoNGrOwSp@mail.gmail.com>

Is this a programmer type thing or are there things lay librarians could
help with?

On Tue, Feb 8, 2011 at 4:42 AM, MJ Ray <mjr at phonecoop.coop> wrote:

> LAURENT Henri-Damien <henridamien.laurent at biblibre.com>
> > So it is now time we make something about Data Persistance.
> > Some tests have been done.
> > Some results can be used.
> > I propose we set some meeting next week any day in the morning between
> > 8AM UTC to 12AM UTC.
>
> I would prefer Monday, Tuesday or Friday (strongly), 10-12 (weakly).
>
> Hope that helps,
> --
> MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
> Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster.
> In My Opinion Only: see http://mjr.towers.org.uk/email.html
> Available for hire for Koha work http://www.software.coop/products/koha
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



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

From kohadevel at agogme.com  Fri Feb 11 01:08:11 2011
From: kohadevel at agogme.com (Thomas Dukleth)
Date: Fri, 11 Feb 2011 00:08:11 -0000 (UCT)
Subject: [Koha-devel] Solr and Z3950 server some news.
In-Reply-To: <4D510CE4.70409@biblibre.com>
References: <4D510CE4.70409@biblibre.com>
Message-ID: <4ef2c1d826b8ef42ff870d0fba44be54.squirrel@wmail.agogme.com>

Reply inline:


On Tue, February 8, 2011 09:29, LAURENT Henri-Damien wrote:
> Hi
> We are getting a pretty nice working z3950 server for solr there.
> We are parsing RPN queries quite generally using a perl module
> Regexp::Grammars::Z3950::RPN
> and  RPN2Solr
> It is working quite well for simple usage (no exp1 or gils queries).

Hooray.  I greatly appreciate the work which BibLibre are doing for
supporting a Z39.50/SRU server using Solr/Lucene.

I note that the tests for SimpleServer using Solr/Lucene,
http://wiki.koha-community.org/wiki/SimpleServer_as_a_Z39.50/SRU_Server_Test_Queries_for_Koha_with_Solr/Lucene
, are as underpopulated as I had left them when I had to return to working
on a non-library project.  I took the time to write this message but I do
not have the time to completely populate the tests presently.

An important point of the few tests which I had included is that useful
functionality such as stemming should not be activated for a Z39.50/SRU
query unless specifically specified in the query.  In the case of copy
cataloguing, avoiding matches not specifically specified in the query is
very important.  Copy cataloguing use might need the opposite defaults to
what may most often benefit OPAC users.  If providing or avoiding various
forms of query expansion cannot be specified at query time for
Solr/Lucene, then we will need separate indexes with different defaults to
which queries may be directed as appropriate to the query.

>
> But at the moment it is serving right only marcxml and not ISO2709. I
> think we may have to try and determine exactly what type of data the
> Z3950 server is supposed to send to yaz-client when serving "MARC" data.

YAZ can convert between MARCXML and ISO 2709.  YAZ can perform both server
and  client functions.  I have not investigated precisely how to pass
MARCXML to YAZ for returning ISO 2709 as a server side function, although,
I have implemented such conversions as client functionality.  I do not
have time to investigate presently.

A Z39.50/SRU server should return records in accordances whatever record
syntaxes are specified as supported in the explain record.

Universal practise for Z39.50 server support of record syntax differs from
the standard in that a single Z39.50 server database is only expected to
support one record syntax.  Support for different record syntaxes over
Z39.50 is obtained in practise by providing different database targets on
the server which may be specified by the server as different database
names or the same database name but running on a different port.  In the
case of SRU, it is common for a single database target to support multiple
record syntaxes and return the record syntax which is specified in the SRU
query.

We are still a long ways from an ISO 2709 free world, therefore, a server
which only returns MARCXML is insufficient.  I note that the default Zebra
Z39.50 server configuration in Koha seems to only return MARCXML, but that
is a configuration deficiency.  We should also not presume that a
Z39.50/SRU client is using YAZ, although, a YAZ based client would be best
as the primary client for testing.

[...]


Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY  10003
USA
http://www.agogme.com
+1 212-674-3783



From henridamien.laurent at biblibre.com  Fri Feb 11 09:14:29 2011
From: henridamien.laurent at biblibre.com (LAURENT Henri-Damien)
Date: Fri, 11 Feb 2011 09:14:29 +0100
Subject: [Koha-devel] Solr and Z3950 server some news.
In-Reply-To: <4ef2c1d826b8ef42ff870d0fba44be54.squirrel@wmail.agogme.com>
References: <4D510CE4.70409@biblibre.com>
	<4ef2c1d826b8ef42ff870d0fba44be54.squirrel@wmail.agogme.com>
Message-ID: <4D54EFE5.2070403@biblibre.com>

Le 11/02/2011 01:08, Thomas Dukleth a ?crit :
> Reply inline:
> 
> 
> On Tue, February 8, 2011 09:29, LAURENT Henri-Damien wrote:
>> Hi
>> We are getting a pretty nice working z3950 server for solr there.
>> We are parsing RPN queries quite generally using a perl module
>> Regexp::Grammars::Z3950::RPN
>> and  RPN2Solr
>> It is working quite well for simple usage (no exp1 or gils queries).
> 
> Hooray.  I greatly appreciate the work which BibLibre are doing for
> supporting a Z39.50/SRU server using Solr/Lucene.
> 
> I note that the tests for SimpleServer using Solr/Lucene,
> http://wiki.koha-community.org/wiki/SimpleServer_as_a_Z39.50/SRU_Server_Test_Queries_for_Koha_with_Solr/Lucene
> , are as underpopulated as I had left them when I had to return to working
> on a non-library project.  I took the time to write this message but I do
> not have the time to completely populate the tests presently.
> 
> An important point of the few tests which I had included is that useful
> functionality such as stemming should not be activated for a Z39.50/SRU
> query unless specifically specified in the query.  In the case of copy
> cataloguing, avoiding matches not specifically specified in the query is
> very important.  Copy cataloguing use might need the opposite defaults to
> what may most often benefit OPAC users.  If providing or avoiding various
> forms of query expansion cannot be specified at query time for
> Solr/Lucene, then we will need separate indexes with different defaults to
> which queries may be directed as appropriate to the query.
Yes, could be achieved with separate indexes and some tweaking to the query.
But at the moment, we have not embedded Stemming or approximative
search, so it would be the default behaviour.

> 
>>
>> But at the moment it is serving right only marcxml and not ISO2709. I
>> think we may have to try and determine exactly what type of data the
>> Z3950 server is supposed to send to yaz-client when serving "MARC" data.
> 
> YAZ can convert between MARCXML and ISO 2709.  YAZ can perform both server
> and  client functions.  I have not investigated precisely how to pass
> MARCXML to YAZ for returning ISO 2709 as a server side function, although,
> I have implemented such conversions as client functionality.  I do not
> have time to investigate presently.
Problem is that simply sending the marc generated by koha leads to this
BAD MARC error. So we are looking for information in order to know WHAT
SimpleServer should be sending.
We are still investigating.
Friendly
-- 
Henri-Damien LAURENT

> 
> A Z39.50/SRU server should return records in accordances whatever record
> syntaxes are specified as supported in the explain record.
> 
> Universal practise for Z39.50 server support of record syntax differs from
> the standard in that a single Z39.50 server database is only expected to
> support one record syntax.  Support for different record syntaxes over
> Z39.50 is obtained in practise by providing different database targets on
> the server which may be specified by the server as different database
> names or the same database name but running on a different port.  In the
> case of SRU, it is common for a single database target to support multiple
> record syntaxes and return the record syntax which is specified in the SRU
> query.
> 
> We are still a long ways from an ISO 2709 free world, therefore, a server
> which only returns MARCXML is insufficient.  I note that the default Zebra
> Z39.50 server configuration in Koha seems to only return MARCXML, but that
> is a configuration deficiency.  We should also not presume that a
> Z39.50/SRU client is using YAZ, although, a YAZ based client would be best
> as the primary client for testing.
> 
> [...]

From kohadevel at agogme.com  Fri Feb 11 10:31:52 2011
From: kohadevel at agogme.com (Thomas Dukleth)
Date: Fri, 11 Feb 2011 09:31:52 -0000 (UCT)
Subject: [Koha-devel] Solr and Z3950 server some news.
In-Reply-To: <4D54EFE5.2070403@biblibre.com>
References: <4D510CE4.70409@biblibre.com>
	<4ef2c1d826b8ef42ff870d0fba44be54.squirrel@wmail.agogme.com>
	<4D54EFE5.2070403@biblibre.com>
Message-ID: <02ac1f4ee319671a732cc1440d28be21.squirrel@wmail.agogme.com>

Reply inline:


On Fri, February 11, 2011 08:14, LAURENT Henri-Damien wrote:

[...]

> Problem is that simply sending the marc generated by koha leads to this
> BAD MARC error.

What part of the server or client is reporting the "BAD MARC" error when
sending ISO 2709 records but not reporting an error when sending MARCXML
records?

> So we are looking for information in order to know WHAT
> SimpleServer should be sending.
> We are still investigating.

[...]


Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY  10003
USA
http://www.agogme.com
+1 212-674-3783



From savitra.sirohi at osslabs.biz  Fri Feb 11 18:12:29 2011
From: savitra.sirohi at osslabs.biz (savitra sirohi)
Date: Fri, 11 Feb 2011 22:42:29 +0530
Subject: [Koha-devel] Koha and IE7
Message-ID: <AANLkTi=ZRLeH+w+ajKf8e4dKeHQkj-W32E+7hG9R6gks@mail.gmail.com>

Folks, one of our customers is looking to use Koha with IE7. We will
probably need to test Koha on IE7 and then fix all significant issues
in a short period of time.

We don't want to overcommit, so should we take this on? How many
issues are we likely to find? And of what type - css, js?

I really appreciate any input on this.

- Savitra

From oleonard at myacpl.org  Fri Feb 11 18:32:25 2011
From: oleonard at myacpl.org (Owen Leonard)
Date: Fri, 11 Feb 2011 12:32:25 -0500
Subject: [Koha-devel] Koha and IE7
In-Reply-To: <AANLkTi=ZRLeH+w+ajKf8e4dKeHQkj-W32E+7hG9R6gks@mail.gmail.com>
References: <AANLkTi=ZRLeH+w+ajKf8e4dKeHQkj-W32E+7hG9R6gks@mail.gmail.com>
Message-ID: <AANLkTinSG63hzkNnEFYst0=PQneYS6Bb8+Z4r2=PXD0U@mail.gmail.com>

> We don't want to overcommit, so should we take this on? How many
> issues are we likely to find? And of what type - css, js?


From oleonard at myacpl.org  Fri Feb 11 18:44:17 2011
From: oleonard at myacpl.org (Owen Leonard)
Date: Fri, 11 Feb 2011 12:44:17 -0500
Subject: [Koha-devel] Koha and IE7
In-Reply-To: <AANLkTinSG63hzkNnEFYst0=PQneYS6Bb8+Z4r2=PXD0U@mail.gmail.com>
References: <AANLkTi=ZRLeH+w+ajKf8e4dKeHQkj-W32E+7hG9R6gks@mail.gmail.com>
	<AANLkTinSG63hzkNnEFYst0=PQneYS6Bb8+Z4r2=PXD0U@mail.gmail.com>
Message-ID: <AANLkTi=qrKb3zWq8UxgmsMmBPxWD2BS+FjfqC3LqP3ss@mail.gmail.com>

I wrote:
> We have tried to correct
> JavaScript problems with Internet Explorer whenever we find them, but
> it's likely you'll find more.

...and it didn't take me long to find one. I've submitted a patch, but
take a look:

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

This is probably the most common JavaScript problem in Internet
Explorer we've seen in the past.

  -- Owen

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

From kohadevel at agogme.com  Fri Feb 11 20:01:04 2011
From: kohadevel at agogme.com (Thomas Dukleth)
Date: Fri, 11 Feb 2011 19:01:04 -0000 (UCT)
Subject: [Koha-devel] Solr and Z3950 server some news.
In-Reply-To: <4D550BB2.1090801@gmail.com>
References: <4D510CE4.70409@biblibre.com>
	<4ef2c1d826b8ef42ff870d0fba44be54.squirrel@wmail.agogme.com>
	<4D54EFE5.2070403@biblibre.com>
	<02ac1f4ee319671a732cc1440d28be21.squirrel@wmail.agogme.com>
	<4D550BB2.1090801@gmail.com>
Message-ID: <35132216e858a2e00a6b966fa9552380.squirrel@wmail.agogme.com>

When briefly testing the BibLibre test configuration of SimpleServer
Z39.50 server I have found same problem as BibLibre are reporting when
using yaz-client.  I have also noted some other issues.

1.  BAD MARC ERROR.

When setting format to UNIMARC in yaz-client, the following error message
is returned along with the record when displaying a record with the show
command.

"[]Record type: Unimarc

bad MARC. Dumping as it is:"

When setting format to XML in yaz-client, no error message is returned
when displaying a  record with the show command.

"[]Record type: XML"

The issue seems to be consistent for all records in the result set.

YAZ is converting between ISO 2709 and MARCXML on the client side.

yaz-client does not report a "bad MARC" error when displaying UNIMARC
MARCXML records returned from Zebra in ISO 2709 form.

Whatever the MARC error may be, it prevents YAZ from parsing the records
properly in ISO 2709.  Consequently, unlike yaz-client, my very well
tested PHP YAZ based Z39.50 client obtains the result set but cannot even
attempt to display the records because it relies upon YAZ for parsing
them.


2.  INVARIANT RESULT SET.

In the configuration which I tested, any query would return exactly the
same 1011 record result set whether or not there would be any legitimate
matches.


3.  MISSING EXPLAIN RECORD.

Lack of an Explain record should not be fatal but might be helpful for
obtaining more debugging information from YAZ.


4.  DEBUGGING.

I do not have time to try intensive tests myself.

First, fix the issue where the result set is an invariant 1011 records.

I suggest having yaz-client save the ISO 2709 records, then attempt to
validate them with MARC::Lint keeping in mind that most errors would be
from the MARC 21 checks in MARC::Lint.

I have not verified that MARCXML is working with SimpleServer using
Solr/Lucene but I would be happy to test that if some SimpleServer target
would be configured to return only MARCXML.

If all else fails, Index Data can help solve the problems for a very
significant fee.


Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY  10003
USA
http://www.agogme.com
+1 212-674-3783



From savitra.sirohi at osslabs.biz  Sun Feb 13 12:08:44 2011
From: savitra.sirohi at osslabs.biz (savitra sirohi)
Date: Sun, 13 Feb 2011 16:38:44 +0530
Subject: [Koha-devel] Koha and IE7
In-Reply-To: <AANLkTi=qrKb3zWq8UxgmsMmBPxWD2BS+FjfqC3LqP3ss@mail.gmail.com>
References: <AANLkTi=ZRLeH+w+ajKf8e4dKeHQkj-W32E+7hG9R6gks@mail.gmail.com>
	<AANLkTinSG63hzkNnEFYst0=PQneYS6Bb8+Z4r2=PXD0U@mail.gmail.com>
	<AANLkTi=qrKb3zWq8UxgmsMmBPxWD2BS+FjfqC3LqP3ss@mail.gmail.com>
Message-ID: <AANLkTikoBqWMSDm8-+2F5ZX_JLGJVPWeyMKXO-fhrk5Y@mail.gmail.com>

Owen, thanks very much for the input, this makes me more comfortable.
I think we should be able to resolve this type of JS issues quickly
and we may get the customer to accept the IE CSS rendering as is.

If we do this we will create bugs and submit patches for your signoff.

Thanks,
Savitra

On Fri, Feb 11, 2011 at 11:14 PM, Owen Leonard <oleonard at myacpl.org> wrote:
> I wrote:
>> We have tried to correct
>> JavaScript problems with Internet Explorer whenever we find them, but
>> it's likely you'll find more.
>
> ...and it didn't take me long to find one. I've submitted a patch, but
> take a look:
>
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5741
>
> This is probably the most common JavaScript problem in Internet
> Explorer we've seen in the past.
>
> ?-- Owen
>
> --
> Web Developer
> Athens County Public Libraries
> http://www.myacpl.org
>

From cnighswonger at foundations.edu  Mon Feb 14 03:51:20 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Sun, 13 Feb 2011 21:51:20 -0500
Subject: [Koha-devel] 3.2.4 Release Schedule
Message-ID: <AANLkTiksBOqbYxHP6+B6X=TLmo5fH9YQ9GSvweeht2rS@mail.gmail.com>

Well, its that time again!

3.2.4 is on track to be released on February 22, 2011, however, there is
another important date between now and then which you should be aware of.

On February 15, 2011, 3.2.4 will enter a string freeze to facilitate
finalization of translation updates. After this date the only patches
introducing string changes which will be pushed for 3.2.4 will be those
addressing blocker bugs or security issues. All others will be pushed to
3.2.5.

Patches not introducing string changes will be pushed up to the time of the
release.

Keep up the good work!

Kind Regards,
Chris Nighswonger
3.2 Release Maintainer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110213/bd8feb57/attachment.htm>

From nengard at gmail.com  Mon Feb 14 15:49:05 2011
From: nengard at gmail.com (Nicole Engard)
Date: Mon, 14 Feb 2011 09:49:05 -0500
Subject: [Koha-devel] Vote for KohaCon 2011
In-Reply-To: <AANLkTi=9097=wTxq=5OgDq6MqGYWWNBMK3UG=DN0mWLC@mail.gmail.com>
References: <AANLkTi=9097=wTxq=5OgDq6MqGYWWNBMK3UG=DN0mWLC@mail.gmail.com>
Message-ID: <AANLkTi=Rr9N0PeT80BoDH9XPMA044T80f-W4Xo48PPN6@mail.gmail.com>

Hello all, we already have over 400 votes.  If you want your vote
counted be sure to vote before the 17th (this week).

Nicole

On Wed, Feb 2, 2011 at 7:32 AM, Nicole Engard <nengard at gmail.com> wrote:
> Hello all,
>
> I have published the official vote for the location of KohaCon 2011.
> The vote will remain open until the 17th of February (EST). ?Please
> enter one vote per person and rank your options with your most
> favorite as 1 and your least favorite as 4. If you won't go somewhere
> no matter what then don't vote for that location. ?Read the proposals
> before you vote:
> http://wiki.koha-community.org/wiki/KohaCon2011_Proposals
>
> Vote here: http://survey.web2learning.net/limesurvey/index.php?sid=15529&lang=en
>
> Thanks
> Nicole C. Engard
> Documentation Manager
>

From paul.poulain at biblibre.com  Mon Feb 14 18:26:50 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Mon, 14 Feb 2011 18:26:50 +0100
Subject: [Koha-devel] Partneship between BibLibre and Catalyst to sponsor
 development on Koha
Message-ID: <4D5965DA.7010506@biblibre.com>

Just FYI :
http://www.biblibre.com/en/blog/entry/partneship-between-biblibre-and-catalyst-to-sponsor-development-on-koha

Friendly

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


From dearden at sarsf.org  Mon Feb 14 20:15:22 2011
From: dearden at sarsf.org (Doug Dearden)
Date: Mon, 14 Feb 2011 12:15:22 -0700
Subject: [Koha-devel] Intro and question
Message-ID: <EB1FA927F4970C429F73A7BF63B7F9FA22FFB5A33C@sar-mail>

Hello all,

I realized I had never introduced myself on this list.  I am the "do everything" guy at the School for Advanced Research in Santa Fe, New Mexico, USA.  We are a non-profit research facility and have an on-campus library where we are currently running Koha.  I am responsible for all computer support, networks, servers, etc. on campus except for our public web site - that is handled by a couple of other very capable guys.  As such I get into programming infrequently, but have enough of a history coding in different languages that I can usually figure out what I need to do by hitting online references and such.  I would definitely not characterize myself as a full time developer, but feel comfortable tweaking existing code to get things working the way we want.  On our current Koha install I modified the xsl files to display links stored in the 856u field as images instead of text link, a feature our librarian wanted to function on a particular database that she is using to catalog some archival photos.  I am now working on getting this working in a way that I can contribute back and hopefully have integrated into Koha - see bug 5738.

I have this working for the MARC21 files - I got it working on the OPAC last week and on the Staff Client today, but also wanted to get the unimarc files modified as well.   I have done some coding but realized I needed to test this.  And here is my question.  I did another DEV install, and chose unimarc during the when answering the questions.  That question only seemed to apply to zebra though.  Looking at the koha-conf.xml it looks like it is pointing to the MARC21 xsl files.  What do I need to do to get a unimarc dev install working?  I have not yet connected to the admin page as I didn't want to populate the database with MARC21 info.  Does it happen automatically there?  Any guidance appreciated.

Thanks,

Doug Dearden
Director, IT
School for Advanced Research
(505)954-7220
sarweb.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110214/861f9075/attachment.htm>

From jransom at library.org.nz  Mon Feb 14 21:14:23 2011
From: jransom at library.org.nz (Joann Ransom)
Date: Tue, 15 Feb 2011 09:14:23 +1300
Subject: [Koha-devel] [Koha] Partneship between BibLibre and Catalyst to
 sponsor development on Koha
In-Reply-To: <AANLkTinefkZFiECAG80v=WWYW57KDPjwV2gnMHjrdavB@mail.gmail.com>
References: <4D5965DA.7010506@biblibre.com>
	<AANLkTinefkZFiECAG80v=WWYW57KDPjwV2gnMHjrdavB@mail.gmail.com>
Message-ID: <AANLkTiksG3nMtmHD7Q-FfF_gDRV66Ai9P=tHxaQ1Sd_E@mail.gmail.com>

yay!

I love the Koha community so much :)

Go Biblibre and go Catalyst :)

Cheers Jo.

2011/2/15 Lori Bowen Ayre <lori.ayre at galecia.com>

> BibLibre and Catalyst +++
>
>
> On Mon, Feb 14, 2011 at 9:26 AM, Paul Poulain <paul.poulain at biblibre.com>wrote:
>
>> Just FYI :
>>
>> http://www.biblibre.com/en/blog/entry/partneship-between-biblibre-and-catalyst-to-sponsor-development-on-koha
>>
>> Friendly
>>
>> --
>> Paul POULAIN
>> http://www.biblibre.com
>> Expert en Logiciels Libres pour l'info-doc
>> Tel : (33) 4 91 81 35 08
>>
>> _______________________________________________
>> Koha mailing list  http://koha-community.org
>> Koha at lists.katipo.co.nz
>> http://lists.katipo.co.nz/mailman/listinfo/koha
>>
>
>
>
> --
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=
> Lori Bowen Ayre // Library Technology Consultant
> The Galecia Group // www.galecia.com
> (707) 763-6869 // Lori.Ayre at galecia.com
>
> <Lori.Ayre at galecia.com>Specializing in open source ILS solutions, RFID,
> filtering,
> workflow optimization, and materials handling
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
>
> _______________________________________________
> Koha mailing list  http://koha-community.org
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>
>


-- 
Joann Ransom RLIANZA
Head of Libraries,
Horowhenua Library Trust.

*Q: Why is this email three sentences or less?
A: http://three.sentenc.es*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110215/dbc0307e/attachment.htm>

From gmcharlt at gmail.com  Mon Feb 14 22:46:32 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Mon, 14 Feb 2011 16:46:32 -0500
Subject: [Koha-devel] Intro and question
In-Reply-To: <EB1FA927F4970C429F73A7BF63B7F9FA22FFB5A33C@sar-mail>
References: <EB1FA927F4970C429F73A7BF63B7F9FA22FFB5A33C@sar-mail>
Message-ID: <AANLkTinMnEHvXRMq2RgaRzPeTNTo9NRKtbDeUFxohH7f@mail.gmail.com>

Hi Doug,

2011/2/14 Doug Dearden <dearden at sarsf.org>:
> I have this working for the MARC21 files ? I got it working on the OPAC last
> week and on the Staff Client today, but also wanted to get the unimarc files
> modified as well.?? I have done some coding but realized I needed to test
> this.? And here is my question.? I did another DEV install, and chose
> unimarc during the when answering the questions.? That question only seemed
> to apply to zebra though.? Looking at the koha-conf.xml it looks like it is
> pointing to the MARC21 xsl files.? What do I need to do to get a unimarc dev
> install working?? I have not yet connected to the admin page as I didn?t
> want to populate the database with MARC21 info.? Does it happen
> automatically there?? Any guidance appreciated.

Good on you for thinking of the UNIMARC users.  In this case, the
references to the MARC21 stylesheets that you see even after choosing
UNIMARC can be ignored for your immediate purposes.  They are used
only if you are using requesting on-the-fly conversion of the MARC
records to other formats such as RDF, MODS, and so forth from Koha's
Z39.50 server.  However, Koha's OPAC itself doesn't use that
functionality, so if you're working on the OPAC display XSLT, the fact
that you chose UNIMARC during installation is enough to get Koha to
point to the correct stylesheets.

Obviously, it *is* a bug that the stylesheets referenced in
koha-conf.xml don't have UNIMARC equivalents, but that's a bug that
quite possibly has never been encountered in practice.

For your reference, what it's doing is checking the marcflavour system
preference to determine if the database is UNIMARC or MARC21.

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From reedwade at gmail.com  Tue Feb 15 00:54:17 2011
From: reedwade at gmail.com (Reed Wade)
Date: Tue, 15 Feb 2011 12:54:17 +1300
Subject: [Koha-devel] reminder when editing JS -- (IE hates you)
In-Reply-To: <AANLkTikE9BXR7ehK3uefHb=BmpjzPwezYdWUqb-+u1iK@mail.gmail.com>
References: <AANLkTikE9BXR7ehK3uefHb=BmpjzPwezYdWUqb-+u1iK@mail.gmail.com>
Message-ID: <AANLkTin9i3UTTENTkRZLPqaWoW20bL_cRJ1tySST0BCE@mail.gmail.com>

And, if I learned how to read mail better I'd notice this was already
a recent topic of discussion.

Nevermind,
-reed



On Tue, Feb 15, 2011 at 12:08 PM, Reed Wade <reed at catalyst.net.nz> wrote:
> I've just been fixing some of these which cause random versions of IE
> to fail in random ways so thought I'd send a reminder to the list.
>
> Compare this:
>
>
> Calendar.setup({
> ? ?blah ?: "pie",
> ? ?blarg : "cake",
> });
>
>
> with this:
>
>
> Calendar.setup({
> ? ?blah ?: "pie",
> ? ?blarg : "cake"
> });
>
>
> That spare comma after the cake in the first example will cause some
> flavours of IE to choke. Most browsers aren't so fragile on that
> point.
>
> It's easy to accidentally leave these laying around when changing args
> around and they don't tend to break for most browsers. Maybe we can
> add in a test for these at some point in the future. I can imagine a
> regex that should catch the bulk if not all of them.
>
> -reed
>

From kohalist at agogme.com  Wed Feb  2 13:43:01 2011
From: kohalist at agogme.com (Thomas Dukleth)
Date: Wed, 2 Feb 2011 12:43:01 -0000 (UCT)
Subject: [Koha-devel] [Koha] Vote for KohaCon 2011
In-Reply-To: <AANLkTi=9097=wTxq=5OgDq6MqGYWWNBMK3UG=DN0mWLC@mail.gmail.com>
References: <AANLkTi=9097=wTxq=5OgDq6MqGYWWNBMK3UG=DN0mWLC@mail.gmail.com>
Message-ID: <afc10fa1123fca410ccb5aa67f0fb494.squirrel@wmail.agogme.com>

I would appreciate people adding some informal range of expected
accommodation prices either to the wiki,
http://wiki.koha-community.org/wiki/KohaCon2011_Proposals , or on the
mailing list.


Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY  10003
USA
http://www.agogme.com
+1 212-674-3783



From lori.ayre at galecia.com  Mon Feb 14 19:22:31 2011
From: lori.ayre at galecia.com (Lori Bowen Ayre)
Date: Mon, 14 Feb 2011 10:22:31 -0800
Subject: [Koha-devel] [Koha] Partneship between BibLibre and Catalyst to
 sponsor development on Koha
In-Reply-To: <4D5965DA.7010506@biblibre.com>
References: <4D5965DA.7010506@biblibre.com>
Message-ID: <AANLkTinefkZFiECAG80v=WWYW57KDPjwV2gnMHjrdavB@mail.gmail.com>

BibLibre and Catalyst +++

On Mon, Feb 14, 2011 at 9:26 AM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Just FYI :
>
> http://www.biblibre.com/en/blog/entry/partneship-between-biblibre-and-catalyst-to-sponsor-development-on-koha
>
> Friendly
>
> --
> Paul POULAIN
> http://www.biblibre.com
> Expert en Logiciels Libres pour l'info-doc
> Tel : (33) 4 91 81 35 08
>
> _______________________________________________
> Koha mailing list  http://koha-community.org
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>



-- 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=
Lori Bowen Ayre // Library Technology Consultant
The Galecia Group // www.galecia.com
(707) 763-6869 // Lori.Ayre at galecia.com

<Lori.Ayre at galecia.com>Specializing in open source ILS solutions, RFID,
filtering,
workflow optimization, and materials handling
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110214/becaeb05/attachment.htm>

From reed at catalyst.net.nz  Tue Feb 15 00:08:52 2011
From: reed at catalyst.net.nz (Reed Wade)
Date: Tue, 15 Feb 2011 12:08:52 +1300
Subject: [Koha-devel] reminder when editing JS -- (IE hates you)
Message-ID: <AANLkTikE9BXR7ehK3uefHb=BmpjzPwezYdWUqb-+u1iK@mail.gmail.com>

I've just been fixing some of these which cause random versions of IE
to fail in random ways so thought I'd send a reminder to the list.

Compare this:


Calendar.setup({
    blah  : "pie",
    blarg : "cake",
});


with this:


Calendar.setup({
    blah  : "pie",
    blarg : "cake"
});


That spare comma after the cake in the first example will cause some
flavours of IE to choke. Most browsers aren't so fragile on that
point.

It's easy to accidentally leave these laying around when changing args
around and they don't tend to break for most browsers. Maybe we can
add in a test for these at some point in the future. I can imagine a
regex that should catch the bulk if not all of them.

-reed

From mjr at phonecoop.coop  Tue Feb 15 10:37:09 2011
From: mjr at phonecoop.coop (MJ Ray)
Date: Tue, 15 Feb 2011 09:37:09 +0000 (GMT)
Subject: [Koha-devel] Devel list admin OK? was: [Koha] Vote for KohaCon 2011
Message-ID: <20110215093709.367DC5028C@nail.towers.org.uk>

> Date: Wed, 2 Feb 2011 12:43:01 -0000 (UCT)
> From: "Thomas Dukleth" <kohalist at agogme.com>
[...]
> X-Mailman-Approved-At: Tue, 15 Feb 2011 09:32:02 +0100

15-2 = 13 days.  Does the devel list need more admins?

Thanks,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire for Koha work http://www.software.coop/products/koha

From henridamien.laurent at gmail.com  Tue Feb 15 11:18:06 2011
From: henridamien.laurent at gmail.com (LAURENT Henri-Damien)
Date: Tue, 15 Feb 2011 11:18:06 +0100
Subject: [Koha-devel] Devel list admin OK? was: [Koha] Vote for KohaCon
 2011
In-Reply-To: <20110215093709.367DC5028C@nail.towers.org.uk>
References: <20110215093709.367DC5028C@nail.towers.org.uk>
Message-ID: <4D5A52DE.7090503@gmail.com>

Le 15/02/2011 10:37, MJ Ray a ?crit :
>> Date: Wed, 2 Feb 2011 12:43:01 -0000 (UCT)
>> From: "Thomas Dukleth" <kohalist at agogme.com>
> [...]
>> X-Mailman-Approved-At: Tue, 15 Feb 2011 09:32:02 +0100
> 
> 15-2 = 13 days.  Does the devel list need more admins?
> 
> Thanks,
Are you putting your name on that ?
kind regards.

-- 
Henri-Damien LAURENT

From semarie-koha at latrappe.fr  Tue Feb 15 11:53:30 2011
From: semarie-koha at latrappe.fr (=?iso-8859-1?Q?Fr=E8re_S=E9bastien?= Marie)
Date: Tue, 15 Feb 2011 11:53:30 +0100
Subject: [Koha-devel] Imported MARC notice and Authorities: :
	inconsistent database
In-Reply-To: <alpine.DEB.2.00.1101291154510.12662@feipbzzhanhgr.ybpny.yngenccr.se>
References: <alpine.DEB.2.00.1101291154510.12662@feipbzzhanhgr.ybpny.yngenccr.se>
Message-ID: <20110215105330.GB20709@latrappe.fr>

Hello,

As we obtain no reply for an inconsistent database, I will explain again the problem, with SQL for examples.

Currently, after using imported set of notices and using it we have the following results:

SELECT count(*) 
 FROM biblioitems
 WHERE extractvalue(biblioitems.marcxml, '/record/datafield[@tag="700"]/subfield[@code="9"]') != ''
   AND extractvalue(biblioitems.marcxml, '/record/datafield[@tag="700"]/subfield[@code="9"]') NOT IN (
    SELECT authid FROM auth_header );
+----------+
| count(*) |
+----------+
|      121 |
+----------+

english-version: If I extract from MarcXML (on table biblioitems) the 700.9 (Primary Author, koha_internal_code) and search in auth_header, we currently have 121 items with no-existent 700.9 .

This is only a part of the problem: some 700.9 are existent but wrong (points to bad authority).

SELECT count(*)
 FROM biblioitems, auth_header
 WHERE extractvalue(biblioitems.marcxml, '/record/datafield[@tag="700"]/subfield[@code="9"]') = auth_header.authid
   AND extractvalue(biblioitems.marcxml, '/record/datafield[@tag="700"]/subfield[@code="a"]') != extractvalue(auth_header.marcxml, '/record/datafield[@tag="200"]/subfield[@code="a"]');
+----------+
| count(*) |
+----------+
|        3 |
+----------+

Any suggestions ? This seems a bug (in import of notices where old koha_internal_code is not removed), but I would prefered have your opinion before submit a bugreport.

And I will like some clues to correct the inconsitences !

Thanks.

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

On Sat, Jan 29, 2011 at 12:13:28PM +0100, Fr?re S?bastien Marie wrote:
> Hello,
> 
> Recently, we have imported a set of notices, from another abbey, in
> the reservoir.
> 
> When we create a new examplar using the previous imported notices,
> the field 700.9 (authority - internal koha number) refering the
> auth_id isn't updated or removed (still reference the old authority
> number, in the other catalog).
> 
> As result, we have an examplar with 700.a (authority name) correct,
> but with an internal reference wrong (not valid in us catalog).
> 
> If we search all notices linked with an authority, there is wrong
> attribution.
> 
> Next an example.
> 
> Starting with:
>  - Notices in reservoir:
>    - Title_A / Author_A (auth_id = 1) [from import]
> 
>  - Authority in catalog:
>    - Author_B (auth_id = 1) [created locally]
> 
>  - Notice in catalog:
>    - Title_B / Author_B (auth_id = 1)
> 
> 
> Next, we create a new examplar based on notice in reservoir, result:
>  - Authority in catalog:
>    - Author_B (auth_id = 1) [created locally]
> 
>  - Notice in catalog:
>    - Title_A / Author_A (auth_id = 1)
>    - Title_B / Author_B (auth_id = 1)
> 
> (doubt if Author_A added in authorities or not)
> 
> Now, if search notice attached with Author_B (auth_id = 1):
>  results:
>   - Title_A / Author_A (auth_id = 1)
>   - Title_B / Author_B (auth_id = 1)
> 
> The database is inconsistent.
> 
> Where is the problem:
>  - a misused of imported MARC: an option somewhere should be set...
>  - a bug in importing MARC: 700.9 should be cleaned before import...
>  - another possibility ?
> 
> Currently, no bug report filled, as I don't no if it is a misusing
> or a bug.
> 
> Thanks.
> -- 
> 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 fridolyn.somers at gmail.com  Tue Feb 15 12:44:22 2011
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Tue, 15 Feb 2011 12:44:22 +0100
Subject: [Koha-devel] Imported MARC notice and Authorities: :
	inconsistent database
In-Reply-To: <20110215105330.GB20709@latrappe.fr>
References: <alpine.DEB.2.00.1101291154510.12662@feipbzzhanhgr.ybpny.yngenccr.se>
	<20110215105330.GB20709@latrappe.fr>
Message-ID: <AANLkTi=z=nLd9ZZmoxaEk4TC_3ZoVx-EiXzsZRc8_we3@mail.gmail.com>

Hie,

I see what you meen.

But has far as I know, the link between biblio and authorities is not
managed during import (it would be quite difficult I think).
Subfield 700$9 is considered as a normal data.

You may find a script in Koha to synchronise the biblio fields with the
existing authorities.
If not, you'll have to create it. Maybe a SQL script is enought.

Tell us if you suceed.

Best regards,

2011/2/15 Fr?re S?bastien <semarie-koha at latrappe.fr>

> Hello,
>
> As we obtain no reply for an inconsistent database, I will explain again
> the problem, with SQL for examples.
>
> Currently, after using imported set of notices and using it we have the
> following results:
>
> SELECT count(*)
>  FROM biblioitems
>  WHERE extractvalue(biblioitems.marcxml,
> '/record/datafield[@tag="700"]/subfield[@code="9"]') != ''
>   AND extractvalue(biblioitems.marcxml,
> '/record/datafield[@tag="700"]/subfield[@code="9"]') NOT IN (
>    SELECT authid FROM auth_header );
> +----------+
> | count(*) |
> +----------+
> |      121 |
> +----------+
>
> english-version: If I extract from MarcXML (on table biblioitems) the 700.9
> (Primary Author, koha_internal_code) and search in auth_header, we currently
> have 121 items with no-existent 700.9 .
>
> This is only a part of the problem: some 700.9 are existent but wrong
> (points to bad authority).
>
> SELECT count(*)
>  FROM biblioitems, auth_header
>  WHERE extractvalue(biblioitems.marcxml,
> '/record/datafield[@tag="700"]/subfield[@code="9"]') = auth_header.authid
>   AND extractvalue(biblioitems.marcxml,
> '/record/datafield[@tag="700"]/subfield[@code="a"]') !=
> extractvalue(auth_header.marcxml,
> '/record/datafield[@tag="200"]/subfield[@code="a"]');
> +----------+
> | count(*) |
> +----------+
> |        3 |
> +----------+
>
> Any suggestions ? This seems a bug (in import of notices where old
> koha_internal_code is not removed), but I would prefered have your opinion
> before submit a bugreport.
>
> And I will like some clues to correct the inconsitences !
>
> Thanks.
>
> --
> 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/
>
> On Sat, Jan 29, 2011 at 12:13:28PM +0100, Fr?re S?bastien Marie wrote:
> > Hello,
> >
> > Recently, we have imported a set of notices, from another abbey, in
> > the reservoir.
> >
> > When we create a new examplar using the previous imported notices,
> > the field 700.9 (authority - internal koha number) refering the
> > auth_id isn't updated or removed (still reference the old authority
> > number, in the other catalog).
> >
> > As result, we have an examplar with 700.a (authority name) correct,
> > but with an internal reference wrong (not valid in us catalog).
> >
> > If we search all notices linked with an authority, there is wrong
> > attribution.
> >
> > Next an example.
> >
> > Starting with:
> >  - Notices in reservoir:
> >    - Title_A / Author_A (auth_id = 1) [from import]
> >
> >  - Authority in catalog:
> >    - Author_B (auth_id = 1) [created locally]
> >
> >  - Notice in catalog:
> >    - Title_B / Author_B (auth_id = 1)
> >
> >
> > Next, we create a new examplar based on notice in reservoir, result:
> >  - Authority in catalog:
> >    - Author_B (auth_id = 1) [created locally]
> >
> >  - Notice in catalog:
> >    - Title_A / Author_A (auth_id = 1)
> >    - Title_B / Author_B (auth_id = 1)
> >
> > (doubt if Author_A added in authorities or not)
> >
> > Now, if search notice attached with Author_B (auth_id = 1):
> >  results:
> >   - Title_A / Author_A (auth_id = 1)
> >   - Title_B / Author_B (auth_id = 1)
> >
> > The database is inconsistent.
> >
> > Where is the problem:
> >  - a misused of imported MARC: an option somewhere should be set...
> >  - a bug in importing MARC: 700.9 should be cleaned before import...
> >  - another possibility ?
> >
> > Currently, no bug report filled, as I don't no if it is a misusing
> > or a bug.
> >
> > Thanks.
> > --
> > 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/
> _______________________________________________
> 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/20110215/83d1e5a3/attachment.htm>

From fridolyn.somers at gmail.com  Tue Feb 15 13:25:28 2011
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Tue, 15 Feb 2011 13:25:28 +0100
Subject: [Koha-devel] Install hurdle, OpenSUSE on virtualbox
In-Reply-To: <AANLkTimKzv882Ogw7GqZ8_fWiwdb2cDJz9vGbbxKmSV0@mail.gmail.com>
References: <001f01cbc6d7$b4e55db0$1eb01910$@com>
	<AANLkTinYaa4xtZ02FmS358V+xKnr_he_U=Bhh3tZC8nw@mail.gmail.com>
	<AANLkTimKzv882Ogw7GqZ8_fWiwdb2cDJz9vGbbxKmSV0@mail.gmail.com>
Message-ID: <AANLkTinG29HdPFa7+ou6yuENjxe5XKydM-79SaRVChQo@mail.gmail.com>

Hie,

We also have problems with Win7 and VirtualBox (3.3 and 4).
The most working mode for network is "bridge" : the network is used on guest
like a new machine (new IP in DHCP).
The problem is only when pc is not connected to a network.

For your developers, we use Linux installed laptops.

Best regards,

On Mon, Feb 7, 2011 at 7:06 PM, Reed Wade <reedwade at gmail.com> wrote:

> is getting slightly off the Koha topic but--
>
> I tend to set up 2 network devices. One set for NAT and the other for
> Host-Only. The NAT interface normally gets a 10.x.x.x address
> (assigned via dhcp)and allows the guest OS to reach out to the outside
> world and get software updates and for other outgoing things. The
> Host-Only device normally gets a 192.x.x.x address assigned via dhcp
> and is used to connect inbound from the host machine.
>
> -reed
>
>
> On Tue, Feb 8, 2011 at 4:06 AM, Owen Leonard <oleonard at myacpl.org> wrote:
> >> Currently, my Windows 7 laptop can't see the apache LAMP
> >> server on the OpenSUSE 11.3 virtualbox.
> >
> > This is not a problem with Koha installation, this is a problem with
> > VirtualBox. I would recommend asking your question in their forum:
> >
> > http://forums.virtualbox.org/
> >
> > Why not work on your Koha installation problems at the same time? Ask
> > here about those while you're waiting to figure out your VirtualBox
> > problems.
> >
> >  -- Owen
> >
> >
> > --
> > Web Developer
> > Athens County Public Libraries
> > http://www.myacpl.org
> > _______________________________________________
> > Koha-devel mailing list
> > Koha-devel at lists.koha-community.org
> > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> > website : http://www.koha-community.org/
> > git : http://git.koha-community.org/
> > bugs : http://bugs.koha-community.org/
> >
> _______________________________________________
> 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/20110215/8ee571ab/attachment.htm>

From henridamien.laurent at gmail.com  Tue Feb 15 15:45:11 2011
From: henridamien.laurent at gmail.com (LAURENT Henri-Damien)
Date: Tue, 15 Feb 2011 15:45:11 +0100
Subject: [Koha-devel] Workgroup on data persistence
In-Reply-To: <20110208104259.5E0005028C@nail.towers.org.uk>
References: <20110208104259.5E0005028C@nail.towers.org.uk>
Message-ID: <4D5A9177.5000605@gmail.com>

Le 08/02/2011 11:42, MJ Ray a ?crit :
> LAURENT Henri-Damien <henridamien.laurent at biblibre.com>
>> So it is now time we make something about Data Persistance.
>> Some tests have been done.
>> Some results can be used.
>> I propose we set some meeting next week any day in the morning between
>> 8AM UTC to 12AM UTC.
> 
> I would prefer Monday, Tuesday or Friday (strongly), 10-12 (weakly).
> 
> Hope that helps,
Since MJ was the only one to answer, let's set that on Friday, 10-12.

-- 
Henri-Damien LAURENT

From mjr at phonecoop.coop  Tue Feb 15 15:45:55 2011
From: mjr at phonecoop.coop (MJ Ray)
Date: Tue, 15 Feb 2011 14:45:55 +0000 (GMT)
Subject: [Koha-devel] Devel list admin OK? was: [Koha] Vote for KohaCon
 2011
In-Reply-To: <4D5A52DE.7090503@gmail.com>
Message-ID: <20110215144555.55E9F5028C@nail.towers.org.uk>

LAURENT Henri-Damien wrote:
> Le 15/02/2011 10:37, MJ Ray a ?crit :
> >> Date: Wed, 2 Feb 2011 12:43:01 -0000 (UCT)
> >> From: "Thomas Dukleth" <kohalist at agogme.com>
> > [...]
> >> X-Mailman-Approved-At: Tue, 15 Feb 2011 09:32:02 +0100
> > 
> > 15-2 = 13 days.  Does the devel list need more admins?
> > 
> > Thanks,
> Are you putting your name on that ?

If the devel list needs more admins and there are no other volunteers,
I would do it.  I'd prefer someone to say clearly whether the list
needs more admins because I would resign another moderation to make
time.  Does it?

Hope that explains,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire for Koha work http://www.software.coop/products/koha

From chrisc at catalyst.net.nz  Tue Feb 15 20:27:01 2011
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Wed, 16 Feb 2011 08:27:01 +1300
Subject: [Koha-devel] Imported MARC notice and Authorities: :
 inconsistent database
In-Reply-To: <AANLkTi=z=nLd9ZZmoxaEk4TC_3ZoVx-EiXzsZRc8_we3@mail.gmail.com>
References: <alpine.DEB.2.00.1101291154510.12662@feipbzzhanhgr.ybpny.yngenccr.se>
	<20110215105330.GB20709@latrappe.fr>
	<AANLkTi=z=nLd9ZZmoxaEk4TC_3ZoVx-EiXzsZRc8_we3@mail.gmail.com>
Message-ID: <20110215192701.GK27877@rorohiko>

* Fridolyn SOMERS (fridolyn.somers at gmail.com) wrote:
>    Hie,
> 
>    I see what you meen.
> 
>    But has far as I know, the link between biblio and authorities is not
>    managed during import (it would be quite difficult I think).
>    Subfield 700$9 is considered as a normal data.
> 
>    You may find a script in Koha to synchronise the biblio fields with the
>    existing authorities.
>    If not, you'll have to create it. Maybe a SQL script is enought.
> 
>    Tell us if you suceed.

Hi All

There is a script in misc link_bibs_to_authorities.pl which should
create the linkages for you

Chris

> 
>    Best regards,
> 
>    2011/2/15 Fr?re S?bastien <[1]semarie-koha at latrappe.fr>
> 
>      Hello,
> 
>      As we obtain no reply for an inconsistent database, I will explain again
>      the problem, with SQL for examples.
> 
>      Currently, after using imported set of notices and using it we have the
>      following results:
> 
>      SELECT count(*)
>      ?FROM biblioitems
>      ?WHERE extractvalue(biblioitems.marcxml,
>      '/record/datafield[@tag="700"]/subfield[@code="9"]') != ''
>      ? AND extractvalue(biblioitems.marcxml,
>      '/record/datafield[@tag="700"]/subfield[@code="9"]') NOT IN (
>      ? ?SELECT authid FROM auth_header );
>      +----------+
>      | count(*) |
>      +----------+
>      | ? ? ?121 |
>      +----------+
> 
>      english-version: If I extract from MarcXML (on table biblioitems) the
>      700.9 (Primary Author, koha_internal_code) and search in auth_header, we
>      currently have 121 items with no-existent 700.9 .
> 
>      This is only a part of the problem: some 700.9 are existent but wrong
>      (points to bad authority).
> 
>      SELECT count(*)
>      ?FROM biblioitems, auth_header
>      ?WHERE extractvalue(biblioitems.marcxml,
>      '/record/datafield[@tag="700"]/subfield[@code="9"]') =
>      auth_header.authid
>      ? AND extractvalue(biblioitems.marcxml,
>      '/record/datafield[@tag="700"]/subfield[@code="a"]') !=
>      extractvalue(auth_header.marcxml,
>      '/record/datafield[@tag="200"]/subfield[@code="a"]');
>      +----------+
>      | count(*) |
>      +----------+
>      | ? ? ? ?3 |
>      +----------+
> 
>      Any suggestions ? This seems a bug (in import of notices where old
>      koha_internal_code is not removed), but I would prefered have your
>      opinion before submit a bugreport.
> 
>      And I will like some clues to correct the inconsitences !
>      Thanks.
> 
>      --
>      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: [2]http://www.latrappe.fr/
> 
>      On Sat, Jan 29, 2011 at 12:13:28PM +0100, Fr?re S?bastien Marie wrote:
>      > Hello,
>      >
>      > Recently, we have imported a set of notices, from another abbey, in
>      > the reservoir.
>      >
>      > When we create a new examplar using the previous imported notices,
>      > the field 700.9 (authority - internal koha number) refering the
>      > auth_id isn't updated or removed (still reference the old authority
>      > number, in the other catalog).
>      >
>      > As result, we have an examplar with 700.a (authority name) correct,
>      > but with an internal reference wrong (not valid in us catalog).
>      >
>      > If we search all notices linked with an authority, there is wrong
>      > attribution.
>      >
>      > Next an example.
>      >
>      > Starting with:
>      > ?- Notices in reservoir:
>      > ? ?- Title_A / Author_A (auth_id = 1) [from import]
>      >
>      > ?- Authority in catalog:
>      > ? ?- Author_B (auth_id = 1) [created locally]
>      >
>      > ?- Notice in catalog:
>      > ? ?- Title_B / Author_B (auth_id = 1)
>      >
>      >
>      > Next, we create a new examplar based on notice in reservoir, result:
>      > ?- Authority in catalog:
>      > ? ?- Author_B (auth_id = 1) [created locally]
>      >
>      > ?- Notice in catalog:
>      > ? ?- Title_A / Author_A (auth_id = 1)
>      > ? ?- Title_B / Author_B (auth_id = 1)
>      >
>      > (doubt if Author_A added in authorities or not)
>      >
>      > Now, if search notice attached with Author_B (auth_id = 1):
>      > ?results:
>      > ? - Title_A / Author_A (auth_id = 1)
>      > ? - Title_B / Author_B (auth_id = 1)
>      >
>      > The database is inconsistent.
>      >
>      > Where is the problem:
>      > ?- a misused of imported MARC: an option somewhere should be set...
>      > ?- a bug in importing MARC: 700.9 should be cleaned before import...
>      > ?- another possibility ?
>      >
>      > Currently, no bug report filled, as I don't no if it is a misusing
>      > or a bug.
>      >
>      > Thanks.
>      > --
>      > 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: [3]http://www.latrappe.fr/
>      _______________________________________________
>      Koha-devel mailing list
>      [4]Koha-devel at lists.koha-community.org
>      [5]http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>      website : [6]http://www.koha-community.org/
>      git : [7]http://git.koha-community.org/
>      bugs : [8]http://bugs.koha-community.org/
> 
>    --
>    Fridolyn SOMERS
>    ICT engineer
>    PROGILONE - Lyon - France
>    [9]fridolyn.somers at gmail.com
> 
> References
> 
>    Visible links
>    1. mailto:semarie-koha at latrappe.fr
>    2. http://www.latrappe.fr/
>    3. http://www.latrappe.fr/
>    4. mailto:Koha-devel at lists.koha-community.org
>    5. http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>    6. http://www.koha-community.org/
>    7. http://git.koha-community.org/
>    8. http://bugs.koha-community.org/
>    9. mailto:fridolyn.somers at gmail.com

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


-- 
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/20110216/421ee5be/attachment.pgp>

From reedwade at gmail.com  Tue Feb 15 20:39:16 2011
From: reedwade at gmail.com (Reed Wade)
Date: Wed, 16 Feb 2011 08:39:16 +1300
Subject: [Koha-devel] Install hurdle, OpenSUSE on virtualbox
In-Reply-To: <AANLkTinG29HdPFa7+ou6yuENjxe5XKydM-79SaRVChQo@mail.gmail.com>
References: <001f01cbc6d7$b4e55db0$1eb01910$@com>
	<AANLkTinYaa4xtZ02FmS358V+xKnr_he_U=Bhh3tZC8nw@mail.gmail.com>
	<AANLkTimKzv882Ogw7GqZ8_fWiwdb2cDJz9vGbbxKmSV0@mail.gmail.com>
	<AANLkTinG29HdPFa7+ou6yuENjxe5XKydM-79SaRVChQo@mail.gmail.com>
Message-ID: <AANLkTinjCf+oj-czTt85TswEfqV99QBjHkMOM1+CEnNF@mail.gmail.com>

In bridge mode the virtual machine will be looking your machine for
address assignment via DHCP so -- I would expect taking it off the
network to cause trouble.

-reed

On Wed, Feb 16, 2011 at 1:25 AM, Fridolyn SOMERS
<fridolyn.somers at gmail.com> wrote:
> Hie,
>
> We also have problems with Win7 and VirtualBox (3.3 and 4).
> The most working mode for network is "bridge" : the network is used on guest
> like a new machine (new IP in DHCP).
> The problem is only when pc is not connected to a network.
>
> For your developers, we use Linux installed laptops.
>
> Best regards,
>
> On Mon, Feb 7, 2011 at 7:06 PM, Reed Wade <reedwade at gmail.com> wrote:
>>
>> is getting slightly off the Koha topic but--
>>
>> I tend to set up 2 network devices. One set for NAT and the other for
>> Host-Only. The NAT interface normally gets a 10.x.x.x address
>> (assigned via dhcp)and allows the guest OS to reach out to the outside
>> world and get software updates and for other outgoing things. The
>> Host-Only device normally gets a 192.x.x.x address assigned via dhcp
>> and is used to connect inbound from the host machine.
>>
>> -reed
>>
>>
>> On Tue, Feb 8, 2011 at 4:06 AM, Owen Leonard <oleonard at myacpl.org> wrote:
>> >> Currently, my Windows 7 laptop can't see the apache LAMP
>> >> server on the OpenSUSE 11.3 virtualbox.
>> >
>> > This is not a problem with Koha installation, this is a problem with
>> > VirtualBox. I would recommend asking your question in their forum:
>> >
>> > http://forums.virtualbox.org/
>> >
>> > Why not work on your Koha installation problems at the same time? Ask
>> > here about those while you're waiting to figure out your VirtualBox
>> > problems.
>> >
>> > ?-- Owen
>> >
>> >
>> > --
>> > Web Developer
>> > Athens County Public Libraries
>> > http://www.myacpl.org
>> > _______________________________________________
>> > Koha-devel mailing list
>> > Koha-devel at lists.koha-community.org
>> > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> > website : http://www.koha-community.org/
>> > git : http://git.koha-community.org/
>> > bugs : http://bugs.koha-community.org/
>> >
>> _______________________________________________
>> 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
>

From reedwade at gmail.com  Tue Feb 15 20:39:58 2011
From: reedwade at gmail.com (Reed Wade)
Date: Wed, 16 Feb 2011 08:39:58 +1300
Subject: [Koha-devel] Install hurdle, OpenSUSE on virtualbox
In-Reply-To: <AANLkTinjCf+oj-czTt85TswEfqV99QBjHkMOM1+CEnNF@mail.gmail.com>
References: <001f01cbc6d7$b4e55db0$1eb01910$@com>
	<AANLkTinYaa4xtZ02FmS358V+xKnr_he_U=Bhh3tZC8nw@mail.gmail.com>
	<AANLkTimKzv882Ogw7GqZ8_fWiwdb2cDJz9vGbbxKmSV0@mail.gmail.com>
	<AANLkTinG29HdPFa7+ou6yuENjxe5XKydM-79SaRVChQo@mail.gmail.com>
	<AANLkTinjCf+oj-czTt85TswEfqV99QBjHkMOM1+CEnNF@mail.gmail.com>
Message-ID: <AANLkTik03UzBMVwwnnFcxH+sEq5UT05aiEPK2SMpTXgc@mail.gmail.com>

sorry-- "...looking beyond your machine..."

On Wed, Feb 16, 2011 at 8:39 AM, Reed Wade <reedwade at gmail.com> wrote:
> In bridge mode the virtual machine will be looking your machine for
> address assignment via DHCP so -- I would expect taking it off the
> network to cause trouble.
>
> -reed
>
> On Wed, Feb 16, 2011 at 1:25 AM, Fridolyn SOMERS
> <fridolyn.somers at gmail.com> wrote:
>> Hie,
>>
>> We also have problems with Win7 and VirtualBox (3.3 and 4).
>> The most working mode for network is "bridge" : the network is used on guest
>> like a new machine (new IP in DHCP).
>> The problem is only when pc is not connected to a network.
>>
>> For your developers, we use Linux installed laptops.
>>
>> Best regards,
>>
>> On Mon, Feb 7, 2011 at 7:06 PM, Reed Wade <reedwade at gmail.com> wrote:
>>>
>>> is getting slightly off the Koha topic but--
>>>
>>> I tend to set up 2 network devices. One set for NAT and the other for
>>> Host-Only. The NAT interface normally gets a 10.x.x.x address
>>> (assigned via dhcp)and allows the guest OS to reach out to the outside
>>> world and get software updates and for other outgoing things. The
>>> Host-Only device normally gets a 192.x.x.x address assigned via dhcp
>>> and is used to connect inbound from the host machine.
>>>
>>> -reed
>>>
>>>
>>> On Tue, Feb 8, 2011 at 4:06 AM, Owen Leonard <oleonard at myacpl.org> wrote:
>>> >> Currently, my Windows 7 laptop can't see the apache LAMP
>>> >> server on the OpenSUSE 11.3 virtualbox.
>>> >
>>> > This is not a problem with Koha installation, this is a problem with
>>> > VirtualBox. I would recommend asking your question in their forum:
>>> >
>>> > http://forums.virtualbox.org/
>>> >
>>> > Why not work on your Koha installation problems at the same time? Ask
>>> > here about those while you're waiting to figure out your VirtualBox
>>> > problems.
>>> >
>>> > ?-- Owen
>>> >
>>> >
>>> > --
>>> > Web Developer
>>> > Athens County Public Libraries
>>> > http://www.myacpl.org
>>> > _______________________________________________
>>> > Koha-devel mailing list
>>> > Koha-devel at lists.koha-community.org
>>> > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>>> > website : http://www.koha-community.org/
>>> > git : http://git.koha-community.org/
>>> > bugs : http://bugs.koha-community.org/
>>> >
>>> _______________________________________________
>>> 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
>>
>

From fridolyn.somers at gmail.com  Wed Feb 16 08:47:22 2011
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Wed, 16 Feb 2011 08:47:22 +0100
Subject: [Koha-devel] Imported MARC notice and Authorities: :
	inconsistent database
In-Reply-To: <20110215192701.GK27877@rorohiko>
References: <alpine.DEB.2.00.1101291154510.12662@feipbzzhanhgr.ybpny.yngenccr.se>
	<20110215105330.GB20709@latrappe.fr>
	<AANLkTi=z=nLd9ZZmoxaEk4TC_3ZoVx-EiXzsZRc8_we3@mail.gmail.com>
	<20110215192701.GK27877@rorohiko>
Message-ID: <AANLkTinKHDcpF-_cZL5pPja+J1VHVr00nNH1x5Wm=dor@mail.gmail.com>

Hie,

Thanks for the solution.

I have a question :
In this script, it seems that if the authority is changed, the items are
deleted :
            # delete any item tags
            my ($itemtag, $itemsubfield) =
GetMarcFromKohaField("items.itemnumber", '');
            foreach my $field ($bib->field($itemtag)) {
                $bib->delete_field($field);
            }

Why is that ?

Regards,

2011/2/15 Chris Cormack <chrisc at catalyst.net.nz>

> * Fridolyn SOMERS (fridolyn.somers at gmail.com) wrote:
> >    Hie,
> >
> >    I see what you meen.
> >
> >    But has far as I know, the link between biblio and authorities is not
> >    managed during import (it would be quite difficult I think).
> >    Subfield 700$9 is considered as a normal data.
> >
> >    You may find a script in Koha to synchronise the biblio fields with
> the
> >    existing authorities.
> >    If not, you'll have to create it. Maybe a SQL script is enought.
> >
> >    Tell us if you suceed.
>
> Hi All
>
> There is a script in misc link_bibs_to_authorities.pl which should
> create the linkages for you
>
> Chris
>
> >
> >    Best regards,
> >
> >    2011/2/15 Fr?re S?bastien <[1]semarie-koha at latrappe.fr>
> >
> >      Hello,
> >
> >      As we obtain no reply for an inconsistent database, I will explain
> again
> >      the problem, with SQL for examples.
> >
> >      Currently, after using imported set of notices and using it we have
> the
> >      following results:
> >
> >      SELECT count(*)
> >      ?FROM biblioitems
> >      ?WHERE extractvalue(biblioitems.marcxml,
> >      '/record/datafield[@tag="700"]/subfield[@code="9"]') != ''
> >      ? AND extractvalue(biblioitems.marcxml,
> >      '/record/datafield[@tag="700"]/subfield[@code="9"]') NOT IN (
> >      ? ?SELECT authid FROM auth_header );
> >      +----------+
> >      | count(*) |
> >      +----------+
> >      | ? ? ?121 |
> >      +----------+
> >
> >      english-version: If I extract from MarcXML (on table biblioitems)
> the
> >      700.9 (Primary Author, koha_internal_code) and search in
> auth_header, we
> >      currently have 121 items with no-existent 700.9 .
> >
> >      This is only a part of the problem: some 700.9 are existent but
> wrong
> >      (points to bad authority).
> >
> >      SELECT count(*)
> >      ?FROM biblioitems, auth_header
> >      ?WHERE extractvalue(biblioitems.marcxml,
> >      '/record/datafield[@tag="700"]/subfield[@code="9"]') =
> >      auth_header.authid
> >      ? AND extractvalue(biblioitems.marcxml,
> >      '/record/datafield[@tag="700"]/subfield[@code="a"]') !=
> >      extractvalue(auth_header.marcxml,
> >      '/record/datafield[@tag="200"]/subfield[@code="a"]');
> >      +----------+
> >      | count(*) |
> >      +----------+
> >      | ? ? ? ?3 |
> >      +----------+
> >
> >      Any suggestions ? This seems a bug (in import of notices where old
> >      koha_internal_code is not removed), but I would prefered have your
> >      opinion before submit a bugreport.
> >
> >      And I will like some clues to correct the inconsitences !
> >      Thanks.
> >
> >      --
> >      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: [2]http://www.latrappe.fr/
> >
> >      On Sat, Jan 29, 2011 at 12:13:28PM +0100, Fr?re S?bastien Marie
> wrote:
> >      > Hello,
> >      >
> >      > Recently, we have imported a set of notices, from another abbey,
> in
> >      > the reservoir.
> >      >
> >      > When we create a new examplar using the previous imported notices,
> >      > the field 700.9 (authority - internal koha number) refering the
> >      > auth_id isn't updated or removed (still reference the old
> authority
> >      > number, in the other catalog).
> >      >
> >      > As result, we have an examplar with 700.a (authority name)
> correct,
> >      > but with an internal reference wrong (not valid in us catalog).
> >      >
> >      > If we search all notices linked with an authority, there is wrong
> >      > attribution.
> >      >
> >      > Next an example.
> >      >
> >      > Starting with:
> >      > ?- Notices in reservoir:
> >      > ? ?- Title_A / Author_A (auth_id = 1) [from import]
> >      >
> >      > ?- Authority in catalog:
> >      > ? ?- Author_B (auth_id = 1) [created locally]
> >      >
> >      > ?- Notice in catalog:
> >      > ? ?- Title_B / Author_B (auth_id = 1)
> >      >
> >      >
> >      > Next, we create a new examplar based on notice in reservoir,
> result:
> >      > ?- Authority in catalog:
> >      > ? ?- Author_B (auth_id = 1) [created locally]
> >      >
> >      > ?- Notice in catalog:
> >      > ? ?- Title_A / Author_A (auth_id = 1)
> >      > ? ?- Title_B / Author_B (auth_id = 1)
> >      >
> >      > (doubt if Author_A added in authorities or not)
> >      >
> >      > Now, if search notice attached with Author_B (auth_id = 1):
> >      > ?results:
> >      > ? - Title_A / Author_A (auth_id = 1)
> >      > ? - Title_B / Author_B (auth_id = 1)
> >      >
> >      > The database is inconsistent.
> >      >
> >      > Where is the problem:
> >      > ?- a misused of imported MARC: an option somewhere should be
> set...
> >      > ?- a bug in importing MARC: 700.9 should be cleaned before
> import...
> >      > ?- another possibility ?
> >      >
> >      > Currently, no bug report filled, as I don't no if it is a misusing
> >      > or a bug.
> >      >
> >      > Thanks.
> >      > --
> >      > 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: [3]http://www.latrappe.fr/
> >      _______________________________________________
> >      Koha-devel mailing list
> >      [4]Koha-devel at lists.koha-community.org
> >      [5]
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> >      website : [6]http://www.koha-community.org/
> >      git : [7]http://git.koha-community.org/
> >      bugs : [8]http://bugs.koha-community.org/
> >
> >    --
> >    Fridolyn SOMERS
> >    ICT engineer
> >    PROGILONE - Lyon - France
> >    [9]fridolyn.somers at gmail.com
> >
> > References
> >
> >    Visible links
> >    1. mailto:semarie-koha at latrappe.fr
> >    2. http://www.latrappe.fr/
> >    3. http://www.latrappe.fr/
> >    4. mailto:Koha-devel at lists.koha-community.org
> >    5.
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> >    6. http://www.koha-community.org/
> >    7. http://git.koha-community.org/
> >    8. http://bugs.koha-community.org/
> >    9. mailto:fridolyn.somers at gmail.com
>
> > _______________________________________________
> > Koha-devel mailing list
> > Koha-devel at lists.koha-community.org
> > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> > website : http://www.koha-community.org/
> > git : http://git.koha-community.org/
> > bugs : http://bugs.koha-community.org/
>
>
> --
> Chris Cormack
> Catalyst IT Ltd.
> +64 4 803 2238
> PO Box 11-053, Manners St, Wellington 6142, New Zealand
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk1a04UACgkQZgbcHEvgMLP8wgCgk+uADfW1pIdH4bg3NqhRJBy4
> VEkAmgLTX84coNwkJT7j18YgXV2OOiCt
> =3N0Z
> -----END PGP SIGNATURE-----
>
>


-- 
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/20110216/d6e84293/attachment-0001.htm>

From chrisc at catalyst.net.nz  Wed Feb 16 09:02:28 2011
From: chrisc at catalyst.net.nz (Chris Cormack)
Date: Wed, 16 Feb 2011 21:02:28 +1300
Subject: [Koha-devel] Imported MARC notice and Authorities: :
 inconsistent database
In-Reply-To: <AANLkTinKHDcpF-_cZL5pPja+J1VHVr00nNH1x5Wm=dor@mail.gmail.com>
References: <alpine.DEB.2.00.1101291154510.12662@feipbzzhanhgr.ybpny.yngenccr.se>
	<20110215105330.GB20709@latrappe.fr>
	<AANLkTi=z=nLd9ZZmoxaEk4TC_3ZoVx-EiXzsZRc8_we3@mail.gmail.com>
	<20110215192701.GK27877@rorohiko>
	<AANLkTinKHDcpF-_cZL5pPja+J1VHVr00nNH1x5Wm=dor@mail.gmail.com>
Message-ID: <20110216080228.GX27877@rorohiko>

* Fridolyn SOMERS (fridolyn.somers at gmail.com) wrote:
>    Hie,
> 
>    Thanks for the solution.
> 
>    I have a question :
>    In this script, it seems that if the authority is changed, the items are
>    deleted :
>    ??????????? # delete any item tags
>    ??????????? my ($itemtag, $itemsubfield) =
>    GetMarcFromKohaField("items.itemnumber", '');
>    ??????????? foreach my $field ($bib->field($itemtag)) {
>    ??????????????? $bib->delete_field($field);
>    ??????????? }
> 
>    Why is that ?

Hi Fridolyn

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

If you want to know more check out commit 
6858da97c361fe9a5fddfed7c6d9b1103b27dca0

The commit message is
    bug 2258 - do not duplicate embedded items

    If a MARC bib is modified by this batch job,
    do not duplicate the item tags embedded in
    it (e.g., 952 for MARC21).  When modifying
    a bib record, any embedded item tags must
    be removed before calling ModBiblio - perhaps
    this should be moved to ModBiblio itself.

    Also removed an error in the job's help
    text.

FYI I found this information using git blame.

Chris

> 
>    Regards,
> 
>    2011/2/15 Chris Cormack <[1]chrisc at catalyst.net.nz>
> 
>      * Fridolyn SOMERS ([2]fridolyn.somers at gmail.com) wrote:
>      > ? ?Hie,
>      >
>      > ? ?I see what you meen.
>      >
>      > ? ?But has far as I know, the link between biblio and authorities is
>      not
>      > ? ?managed during import (it would be quite difficult I think).
>      > ? ?Subfield 700$9 is considered as a normal data.
>      >
>      > ? ?You may find a script in Koha to synchronise the biblio fields with
>      the
>      > ? ?existing authorities.
>      > ? ?If not, you'll have to create it. Maybe a SQL script is enought.
>      >
>      > ? ?Tell us if you suceed.
> 
>      Hi All
> 
>      There is a script in misc [3]link_bibs_to_authorities.pl which should
>      create the linkages for you
> 
>      Chris
> 
>      >
>      > ? ?Best regards,
>      >
>      > ? ?2011/2/15 Fr?re S?bastien <[1][4]semarie-koha at latrappe.fr>
>      >
>      > ? ? ?Hello,
>      >
>      > ? ? ?As we obtain no reply for an inconsistent database, I will
>      explain again
>      > ? ? ?the problem, with SQL for examples.
>      >
>      > ? ? ?Currently, after using imported set of notices and using it we
>      have the
>      > ? ? ?following results:
>      >
>      > ? ? ?SELECT count(*)
>      > ? ? ??FROM biblioitems
>      > ? ? ??WHERE extractvalue(biblioitems.marcxml,
>      > ? ? ?'/record/datafield[@tag="700"]/subfield[@code="9"]') != ''
>      > ? ? ?? AND extractvalue(biblioitems.marcxml,
>      > ? ? ?'/record/datafield[@tag="700"]/subfield[@code="9"]') NOT IN (
>      > ? ? ?? ?SELECT authid FROM auth_header );
>      > ? ? ?+----------+
>      > ? ? ?| count(*) |
>      > ? ? ?+----------+
>      > ? ? ?| ? ? ?121 |
>      > ? ? ?+----------+
>      >
>      > ? ? ?english-version: If I extract from MarcXML (on table biblioitems)
>      the
>      > ? ? ?700.9 (Primary Author, koha_internal_code) and search in
>      auth_header, we
>      > ? ? ?currently have 121 items with no-existent 700.9 .
>      >
>      > ? ? ?This is only a part of the problem: some 700.9 are existent but
>      wrong
>      > ? ? ?(points to bad authority).
>      >
>      > ? ? ?SELECT count(*)
>      > ? ? ??FROM biblioitems, auth_header
>      > ? ? ??WHERE extractvalue(biblioitems.marcxml,
>      > ? ? ?'/record/datafield[@tag="700"]/subfield[@code="9"]') =
>      > ? ? ?auth_header.authid
>      > ? ? ?? AND extractvalue(biblioitems.marcxml,
>      > ? ? ?'/record/datafield[@tag="700"]/subfield[@code="a"]') !=
>      > ? ? ?extractvalue(auth_header.marcxml,
>      > ? ? ?'/record/datafield[@tag="200"]/subfield[@code="a"]');
>      > ? ? ?+----------+
>      > ? ? ?| count(*) |
>      > ? ? ?+----------+
>      > ? ? ?| ? ? ? ?3 |
>      > ? ? ?+----------+
>      >
>      > ? ? ?Any suggestions ? This seems a bug (in import of notices where
>      old
>      > ? ? ?koha_internal_code is not removed), but I would prefered have
>      your
>      > ? ? ?opinion before submit a bugreport.
>      >
>      > ? ? ?And I will like some clues to correct the inconsitences !
>      > ? ? ?Thanks.
>      >
>      > ? ? ?--
>      > ? ? ?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: [2][5]http://www.latrappe.fr/
>      >
>      > ? ? ?On Sat, Jan 29, 2011 at 12:13:28PM +0100, Fr?re S?bastien Marie
>      wrote:
>      > ? ? ?> Hello,
>      > ? ? ?>
>      > ? ? ?> Recently, we have imported a set of notices, from another
>      abbey, in
>      > ? ? ?> the reservoir.
>      > ? ? ?>
>      > ? ? ?> When we create a new examplar using the previous imported
>      notices,
>      > ? ? ?> the field 700.9 (authority - internal koha number) refering the
>      > ? ? ?> auth_id isn't updated or removed (still reference the old
>      authority
>      > ? ? ?> number, in the other catalog).
>      > ? ? ?>
>      > ? ? ?> As result, we have an examplar with 700.a (authority name)
>      correct,
>      > ? ? ?> but with an internal reference wrong (not valid in us catalog).
>      > ? ? ?>
>      > ? ? ?> If we search all notices linked with an authority, there is
>      wrong
>      > ? ? ?> attribution.
>      > ? ? ?>
>      > ? ? ?> Next an example.
>      > ? ? ?>
>      > ? ? ?> Starting with:
>      > ? ? ?> ?- Notices in reservoir:
>      > ? ? ?> ? ?- Title_A / Author_A (auth_id = 1) [from import]
>      > ? ? ?>
>      > ? ? ?> ?- Authority in catalog:
>      > ? ? ?> ? ?- Author_B (auth_id = 1) [created locally]
>      > ? ? ?>
>      > ? ? ?> ?- Notice in catalog:
>      > ? ? ?> ? ?- Title_B / Author_B (auth_id = 1)
>      > ? ? ?>
>      > ? ? ?>
>      > ? ? ?> Next, we create a new examplar based on notice in reservoir,
>      result:
>      > ? ? ?> ?- Authority in catalog:
>      > ? ? ?> ? ?- Author_B (auth_id = 1) [created locally]
>      > ? ? ?>
>      > ? ? ?> ?- Notice in catalog:
>      > ? ? ?> ? ?- Title_A / Author_A (auth_id = 1)
>      > ? ? ?> ? ?- Title_B / Author_B (auth_id = 1)
>      > ? ? ?>
>      > ? ? ?> (doubt if Author_A added in authorities or not)
>      > ? ? ?>
>      > ? ? ?> Now, if search notice attached with Author_B (auth_id = 1):
>      > ? ? ?> ?results:
>      > ? ? ?> ? - Title_A / Author_A (auth_id = 1)
>      > ? ? ?> ? - Title_B / Author_B (auth_id = 1)
>      > ? ? ?>
>      > ? ? ?> The database is inconsistent.
>      > ? ? ?>
>      > ? ? ?> Where is the problem:
>      > ? ? ?> ?- a misused of imported MARC: an option somewhere should be
>      set...
>      > ? ? ?> ?- a bug in importing MARC: 700.9 should be cleaned before
>      import...
>      > ? ? ?> ?- another possibility ?
>      > ? ? ?>
>      > ? ? ?> Currently, no bug report filled, as I don't no if it is a
>      misusing
>      > ? ? ?> or a bug.
>      > ? ? ?>
>      > ? ? ?> Thanks.
>      > ? ? ?> --
>      > ? ? ?> 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: [3][6]http://www.latrappe.fr/
>      > ? ? ?_______________________________________________
>      > ? ? ?Koha-devel mailing list
>      > ? ? ?[4][7]Koha-devel at lists.koha-community.org
>      > ? ?
>      ?[5][8]http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>      > ? ? ?website : [6][9]http://www.koha-community.org/
>      > ? ? ?git : [7][10]http://git.koha-community.org/
>      > ? ? ?bugs : [8][11]http://bugs.koha-community.org/
>      >
>      > ? ?--
>      > ? ?Fridolyn SOMERS
>      > ? ?ICT engineer
>      > ? ?PROGILONE - Lyon - France
>      > ? ?[9][12]fridolyn.somers at gmail.com
>      >
>      > References
>      >
>      > ? ?Visible links
>      > ? ?1. mailto:[13]semarie-koha at latrappe.fr
>      > ? ?2. [14]http://www.latrappe.fr/
>      > ? ?3. [15]http://www.latrappe.fr/
>      > ? ?4. mailto:[16]Koha-devel at lists.koha-community.org
>      > ? ?5.
>      [17]http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>      > ? ?6. [18]http://www.koha-community.org/
>      > ? ?7. [19]http://git.koha-community.org/
>      > ? ?8. [20]http://bugs.koha-community.org/
>      > ? ?9. mailto:[21]fridolyn.somers at gmail.com
>      > _______________________________________________
>      > Koha-devel mailing list
>      > [22]Koha-devel at lists.koha-community.org
>      >
>      [23]http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>      > website : [24]http://www.koha-community.org/
>      > git : [25]http://git.koha-community.org/
>      > bugs : [26]http://bugs.koha-community.org/
> 
>      --
>      Chris Cormack
>      Catalyst IT Ltd.
>      [27]+64 4 803 2238
>      PO Box 11-053, Manners St, Wellington 6142, New Zealand
>      -----BEGIN PGP SIGNATURE-----
>      Version: GnuPG v1.4.10 (GNU/Linux)
> 
>      iEYEARECAAYFAk1a04UACgkQZgbcHEvgMLP8wgCgk+uADfW1pIdH4bg3NqhRJBy4
>      VEkAmgLTX84coNwkJT7j18YgXV2OOiCt
>      =3N0Z
>      -----END PGP SIGNATURE-----
> 
>    --
>    Fridolyn SOMERS
>    ICT engineer
>    PROGILONE - Lyon - France
>    [28]fridolyn.somers at gmail.com
> 
> References
> 
>    Visible links
>    1. mailto:chrisc at catalyst.net.nz
>    2. mailto:fridolyn.somers at gmail.com
>    3. http://link_bibs_to_authorities.pl/
>    4. mailto:semarie-koha at latrappe.fr
>    5. http://www.latrappe.fr/
>    6. http://www.latrappe.fr/
>    7. mailto:Koha-devel at lists.koha-community.org
>    8. http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>    9. http://www.koha-community.org/
>   10. http://git.koha-community.org/
>   11. http://bugs.koha-community.org/
>   12. mailto:fridolyn.somers at gmail.com
>   13. mailto:semarie-koha at latrappe.fr
>   14. http://www.latrappe.fr/
>   15. http://www.latrappe.fr/
>   16. mailto:Koha-devel at lists.koha-community.org
>   17. http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>   18. http://www.koha-community.org/
>   19. http://git.koha-community.org/
>   20. http://bugs.koha-community.org/
>   21. mailto:fridolyn.somers at gmail.com
>   22. mailto:Koha-devel at lists.koha-community.org
>   23. http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>   24. http://www.koha-community.org/
>   25. http://git.koha-community.org/
>   26. http://bugs.koha-community.org/
>   27. file:///tmp/tel:%2B64%204%20803%202238
>   28. mailto:fridolyn.somers at gmail.com

-- 
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/20110216/b336ebce/attachment.pgp>

From semarie-koha at latrappe.fr  Wed Feb 16 09:08:29 2011
From: semarie-koha at latrappe.fr (=?iso-8859-1?Q?Fr=E8re_S=E9bastien?= Marie)
Date: Wed, 16 Feb 2011 09:08:29 +0100
Subject: [Koha-devel] Imported MARC notice and Authorities: :
 inconsistent database
In-Reply-To: <AANLkTi=z=nLd9ZZmoxaEk4TC_3ZoVx-EiXzsZRc8_we3@mail.gmail.com>
References: <alpine.DEB.2.00.1101291154510.12662@feipbzzhanhgr.ybpny.yngenccr.se>
	<20110215105330.GB20709@latrappe.fr>
	<AANLkTi=z=nLd9ZZmoxaEk4TC_3ZoVx-EiXzsZRc8_we3@mail.gmail.com>
Message-ID: <20110216080829.GH20709@latrappe.fr>

On Tue, Feb 15, 2011 at 12:44:22PM +0100, Fridolyn SOMERS wrote:
>
> But has far as I know, the link between biblio and authorities is not
> managed during import (it would be quite difficult I think).
> Subfield 700$9 is considered as a normal data.

I think a better behavior should be to strip 700$9 (in the export stage, where its known unambigiously that 700$9 is really the koha_internal_number) ? Its resolv inconsistences in the import stage (no reference to a wrong authority), and should simplify future relinking.

> 
> You may find a script in Koha to synchronise the biblio fields with the
> existing authorities.
> If not, you'll have to create it. Maybe a SQL script is enought.
> 

misc/link_bibs_to_authorities.pl should be the right (thanks Chris), but it failed with UNIMARC flavour...

$ ./link_bibs_to_authorities.pl --test --verbose
Can't locate object method "new" via package "C4::Heading::UNIMARC" (perhaps you forgot to load "C4::Heading::UNIMARC"?) at /srv/koha/koha-git-tree/C4/Heading.pm line 168.

In my repository, there is no "C4/Heading/UNIMARC.pm" ... only "C4/Heading/MARC21.pm".
But "C4/Heading.pm" refers to C4::Heading::UNIMARC .

----- BEGIN C4/Heading.pm: lines 164-173 -----
sub _marc_format_handler {
  my $marcflavour = shift;

  if ($marcflavour eq 'UNIMARC') {
    return C4::Heading::UNIMARC->new();
  } else {
    return C4::Heading::MARC21->new();
  }

}
----- END C4/Heading.pm -----

And I can't verify against the git tree (git.koha-community.org seem currently hanged: ping ok, connect 80 ok, but no responses from server), but my current version its from Jan 6, 2011 , and the _marc_format_handler function dated to 2008 (date based with git blame) : so I think ok, but its lacks UNIMARC support for ./link_bibs_to_authorities.pl .

> Tell us if you suceed.

Working progress...

Thanks.
-- 
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 kohadevel at agogme.com  Wed Feb 16 11:54:03 2011
From: kohadevel at agogme.com (Thomas Dukleth)
Date: Wed, 16 Feb 2011 10:54:03 -0000 (UCT)
Subject: [Koha-devel] SimpleServer using Solr progress
In-Reply-To: <35132216e858a2e00a6b966fa9552380.squirrel@wmail.agogme.com>
References: <4D510CE4.70409@biblibre.com>
	<4ef2c1d826b8ef42ff870d0fba44be54.squirrel@wmail.agogme.com>
	<4D54EFE5.2070403@biblibre.com>
	<02ac1f4ee319671a732cc1440d28be21.squirrel@wmail.agogme.com>
	<4D550BB2.1090801@gmail.com>
	<35132216e858a2e00a6b966fa9552380.squirrel@wmail.agogme.com>
Message-ID: <439451ef82533d45c001261e04ffc069.squirrel@wmail.agogme.com>

[Original subject: Re: [Koha-devel] Solr and Z3950 server some news.]


1.  YAZ CONFIGURATION.

SimpleServer, like all IndexData products is dependent upon YAZ.

My thought on the bad MARC error from testing BibLibre work on
SimpleServer as a Z39.50/SRU server using Solr/Lucene is that the record
syntax/schema serialisation is not working correctly because no GFS
configuration file has been specified for YAZ.  A SimpleServer
implementation without a configuration file for YAZ would lack CQL to PQF
conversion, Explain support, etc.  The built in defaults seem to be
insufficient for proper record syntax/schema serialisation.

SimpleServer can be started with the -f option to specify a GFS
configuration file for YAZ,
http://www.indexdata.com/yaz/doc/server.vhosts.html .  YAZ retrieval
facility documentation,
http://www.indexdata.com/yaz/doc/tools.retrieval.html , is needed to help
understand serialisation for the GFS configuration file.  Z39.50 object
identifiers (OIDs) are listed at
http://www.loc.gov/z3950/agency/defns/oids.html .

A YAZ GFS configuration example is in etc/yazgfs.xml in the YAZ source
code.  Other needed configuration files such as pqf.properties,
cqlpass.properties, and maps.xml are linked from yazgfs.xml.  In Koha, the
YAZ GFS configuration file is etc/koha-conf.xml which links to other
files, such as etc/zebradb/explain-biblios.xml, and differently named
files, such as etc/zebradb/cql.properties.

The Koha examples have several mistakes and omissions including the
following.  Generic XML might include MARCXML and Dublin Core along with
any other XML schema  , therefore, generic XML should not be conflated
with MARCXML which have distinctive serialisations.  UNIMARC and USMARC
are distinctive and having UNIMARC use USMARC  defaults causes confusion
and may lead to bugs.  There are other mistakes and omissions for Koha YAZ
configuration but those seem most relevant to BibLibre's current work on
SimpleServer.

The ambiguity of the Z39.50 standard over whether records from the result
set would need to be retrieved again from the server for the present
command if they had already been retrieved as part of the response to the
search command complicates my understanding of what may be happening on
the server and client side when using the present command.  YAZ behaviour
is expected to parse MARCXML records in a distinctive MARC formatted
manner also used to parse ISO 2709 records when the present command is
issued.  In the current state of work on SimpleServer, with the apparent
absence of proper serialisation, the present command returns incompletely
parsed MARC records.  YAZ does not attempt parsing for generic XML. 
Saving MARCXML in raw format would avoid the MARC parsing from present.


2.  INVARIANT RESULT SET.

A more important problem remains that any SimpleServer query has been
returning exactly the same result set whether or not there would be any
legitimate matches.  1011 records had always been returned on when I
tested on Friday.  1027 records were always being returned when I tested
on Monday.


3.  DIRECTION FOR NOW.

I hope that my testing and direction to a possible solution has been
helpful to people working on SimpleServer using Solr/Lucene at BibLibre. 
As much fun as more actively helping to fix the problems would be, I have
to return to some non-library commitments presently.


Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY  10003
USA
http://www.agogme.com
+1 212-674-3783



From henridamien.laurent at gmail.com  Wed Feb 16 12:27:38 2011
From: henridamien.laurent at gmail.com (LAURENT Henri-Damien)
Date: Wed, 16 Feb 2011 12:27:38 +0100
Subject: [Koha-devel] SimpleServer using Solr progress
In-Reply-To: <439451ef82533d45c001261e04ffc069.squirrel@wmail.agogme.com>
References: <4D510CE4.70409@biblibre.com>
	<4ef2c1d826b8ef42ff870d0fba44be54.squirrel@wmail.agogme.com>
	<4D54EFE5.2070403@biblibre.com>
	<02ac1f4ee319671a732cc1440d28be21.squirrel@wmail.agogme.com>
	<4D550BB2.1090801@gmail.com>
	<35132216e858a2e00a6b966fa9552380.squirrel@wmail.agogme.com>
	<439451ef82533d45c001261e04ffc069.squirrel@wmail.agogme.com>
Message-ID: <4D5BB4AA.3080502@gmail.com>

Le 16/02/2011 11:54, Thomas Dukleth a ?crit :
> [Original subject: Re: [Koha-devel] Solr and Z3950 server some news.]
> 
> 
> 1.  YAZ CONFIGURATION.
> 
> SimpleServer, like all IndexData products is dependent upon YAZ.
> 
> My thought on the bad MARC error from testing BibLibre work on
> SimpleServer as a Z39.50/SRU server using Solr/Lucene is that the record
> syntax/schema serialisation is not working correctly because no GFS
> configuration file has been specified for YAZ.  A SimpleServer
> implementation without a configuration file for YAZ would lack CQL to PQF
> conversion, Explain support, etc.  The built in defaults seem to be
> insufficient for proper record syntax/schema serialisation.
> 
> SimpleServer can be started with the -f option to specify a GFS
> configuration file for YAZ,
> http://www.indexdata.com/yaz/doc/server.vhosts.html .  YAZ retrieval
> facility documentation,
> http://www.indexdata.com/yaz/doc/tools.retrieval.html , is needed to help
> understand serialisation for the GFS configuration file.  Z39.50 object
> identifiers (OIDs) are listed at
> http://www.loc.gov/z3950/agency/defns/oids.html .
> 
> A YAZ GFS configuration example is in etc/yazgfs.xml in the YAZ source
> code.  Other needed configuration files such as pqf.properties,
> cqlpass.properties, and maps.xml are linked from yazgfs.xml.  In Koha, the
> YAZ GFS configuration file is etc/koha-conf.xml which links to other
> files, such as etc/zebradb/explain-biblios.xml, and differently named
> files, such as etc/zebradb/cql.properties.
> 
> The Koha examples have several mistakes and omissions including the
> following.  Generic XML might include MARCXML and Dublin Core along with
> any other XML schema  , therefore, generic XML should not be conflated
> with MARCXML which have distinctive serialisations.  UNIMARC and USMARC
> are distinctive and having UNIMARC use USMARC  defaults causes confusion
> and may lead to bugs.  There are other mistakes and omissions for Koha YAZ
> configuration but those seem most relevant to BibLibre's current work on
> SimpleServer.
> 
> The ambiguity of the Z39.50 standard over whether records from the result
> set would need to be retrieved again from the server for the present
> command if they had already been retrieved as part of the response to the
> search command complicates my understanding of what may be happening on
> the server and client side when using the present command.  YAZ behaviour
> is expected to parse MARCXML records in a distinctive MARC formatted
> manner also used to parse ISO 2709 records when the present command is
> issued.  In the current state of work on SimpleServer, with the apparent
> absence of proper serialisation, the present command returns incompletely
> parsed MARC records.  YAZ does not attempt parsing for generic XML. 
> Saving MARCXML in raw format would avoid the MARC parsing from present.
> 

Many thanks for your time invested, your feedback and thoughtfull hints.
We will try and get things out of this.
And we will try adding a yaz xml file and make that file used in the
SimpleServer.


> 
> 2.  INVARIANT RESULT SET.
> 
> A more important problem remains that any SimpleServer query has been
> returning exactly the same result set whether or not there would be any
> legitimate matches.  1011 records had always been returned on when I
> tested on Friday.  1027 records were always being returned when I tested
> on Monday.
I think this problem comes from the fact that whatever the query is, if
there is no answer possible, we are exposing the whole lot.

> 
> 
> 3.  DIRECTION FOR NOW.
> 
> I hope that my testing and direction to a possible solution has been
> helpful to people working on SimpleServer using Solr/Lucene at BibLibre. 
> As much fun as more actively helping to fix the problems would be, I have
> to return to some non-library commitments presently.
> 
Thanks Thomas.

-- 
Henri-Damien LAURENT

From nengard at gmail.com  Thu Feb 17 14:18:53 2011
From: nengard at gmail.com (Nicole Engard)
Date: Thu, 17 Feb 2011 08:18:53 -0500
Subject: [Koha-devel] KohaCon 2011 : The Votes Are In
Message-ID: <AANLkTi=0RJqhc+9kzrSUJXebEbwXT9bcXC2tMMHDRT7R@mail.gmail.com>

Hello all,

The KohaCon 2011 Location Survey is closed.  We had a total of 877
responses. If you voted for a location as your first choice it got 4
points, your second choice 3 points, and so on. Below is the break
down in points.

** Thane, India [ End October - Beginning November ] 2640+150+62+33= 2885 **
Kathmandu, Nepal [ November / December 2011 ] 432+96+186+24= 738
Kolkata, India [ November / December 2011 ] 156+339+104+33= 632
Somerset or Bristol, UK [ September / October 2011 ] 160+141+72+108 = 481

The raw results will be posted to the wiki (I can't upload a CSV file
- I need some admin help). I do want to know what your opinions are
about posting the full CSV file to the wiki - it does have all our
email addresses.  I might remove that column before posting if enough
people express a concern about that or just email the CSV to those who
want to see the raw results and not worry about posting it publicly at
all.

 Even if we ignore votes from those who didn't fill in all the
information I'm pretty sure we have a winner.

Thanks
Nicole C. Engard

PS. I recommend that we soon move on to voting for the location for
2012 so that we can get on top of things and conference planners have
more time to prepare.

From gmcharlt at gmail.com  Thu Feb 17 14:39:04 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Thu, 17 Feb 2011 08:39:04 -0500
Subject: [Koha-devel] KohaCon 2011 : The Votes Are In
In-Reply-To: <AANLkTi=0RJqhc+9kzrSUJXebEbwXT9bcXC2tMMHDRT7R@mail.gmail.com>
References: <AANLkTi=0RJqhc+9kzrSUJXebEbwXT9bcXC2tMMHDRT7R@mail.gmail.com>
Message-ID: <AANLkTim2+4HB9ZNQ4L31PJkbG7SF3PQz4HNRD-g7-ObC@mail.gmail.com>

Hi,

On Thu, Feb 17, 2011 at 8:18 AM, Nicole Engard <nengard at gmail.com> wrote:
> The raw results will be posted to the wiki (I can't upload a CSV file
> - I need some admin help). I do want to know what your opinions are
> about posting the full CSV file to the wiki - it does have all our
> email addresses. ?I might remove that column before posting if enough
> people express a concern about that or just email the CSV to those who
> want to see the raw results and not worry about posting it publicly at
> all.

I prefer that we not post the version with the email addresses
publicly.  It can be made available on request if a question arises.

Congratulations to the organizers of the Thane bid - I look forward to
Koha 2011 in Thane, India.

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From M.de.Rooy at rijksmuseum.nl  Thu Feb 17 15:24:38 2011
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Thu, 17 Feb 2011 14:24:38 +0000
Subject: [Koha-devel] zebra / Heading-Main
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA311DFFBF@S-MAIL-1B.rijksmuseum.intra>

Hi,

Some time ago Heading-Main was introduced in both authorities and biblios record.abs in marc_defs/marc21 and marc_defs/unimarc.
Apparently, it was added to extend authority search with the option to search only in 100a, 110a, .. fields.
But Heading-Main is not listed in one the attsets (bib1,..)

This gives the warning: zebraidx(18056) [warn] Index 'Heading-Main' not found in attset(s)

This bug was reported March 2009 (!) under:  http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3072
Related reports are: 3052, 3386 and 3429.
We still have the following temporary fix in AuthoritiesMarc.pm :
            ##If mainentry search $a tag
                if (@$tags[$i] eq "mainmainentry") {

# FIXME: 'Heading-Main' index not yet defined in zebra
#                $attr =" \@attr 1=Heading-Main ";
                $attr =" \@attr 1=Heading ";


Would anyone of you object against defining a new 8XXX field in authorities bib1.att to activate Heading-Main and at the same time fixing AuthoritiesMarc.pm ?
We now have there:

att 8001    Heading
att 8002    See-from
att 8003    See-also-from
att 8804    Match-heading
att 8805    Match-subdivision
att 8806    Subdivision
att 8807    Subdivision-see-also-from
att 8808    Subdivision-see-from
att 8809    Match-heading-see-from
att 8810    Match-subdivision-see-from

BTW, an interesting way of incrementing from 8001 to 8810? We could add 8004 for Heading-Main ? Better idea?

Regards,

Marcel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110217/3dd53953/attachment.htm>

From M.de.Rooy at rijksmuseum.nl  Thu Feb 17 15:39:04 2011
From: M.de.Rooy at rijksmuseum.nl (Marcel de Rooy)
Date: Thu, 17 Feb 2011 14:39:04 +0000
Subject: [Koha-devel] FW: zebra / Heading-Main
Message-ID: <809BE39CD64BFD4EB9036172EBCCFA311E0262@S-MAIL-1B.rijksmuseum.intra>

Only in authorities..

Van: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] Namens Marcel de Rooy
Verzonden: donderdag 17 februari 2011 15:25
Aan: koha-devel at lists.koha-community.org
Onderwerp: [Koha-devel] zebra / Heading-Main

Hi,

Some time ago Heading-Main was introduced in both authorities and biblios record.abs in marc_defs/marc21 and marc_defs/unimarc.
Apparently, it was added to extend authority search with the option to search only in 100a, 110a, .. fields.
But Heading-Main is not listed in one the attsets (bib1,..)

This gives the warning: zebraidx(18056) [warn] Index 'Heading-Main' not found in attset(s)

This bug was reported March 2009 (!) under:  http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3072
Related reports are: 3052, 3386 and 3429.
We still have the following temporary fix in AuthoritiesMarc.pm :
            ##If mainentry search $a tag
                if (@$tags[$i] eq "mainmainentry") {

# FIXME: 'Heading-Main' index not yet defined in zebra
#                $attr =" \@attr 1=Heading-Main ";
                $attr =" \@attr 1=Heading ";


Would anyone of you object against defining a new 8XXX field in authorities bib1.att to activate Heading-Main and at the same time fixing AuthoritiesMarc.pm ?
We now have there:

att 8001    Heading
att 8002    See-from
att 8003    See-also-from
att 8804    Match-heading
att 8805    Match-subdivision
att 8806    Subdivision
att 8807    Subdivision-see-also-from
att 8808    Subdivision-see-from
att 8809    Match-heading-see-from
att 8810    Match-subdivision-see-from

BTW, an interesting way of incrementing from 8001 to 8810? We could add 8004 for Heading-Main ? Better idea?

Regards,

Marcel

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

From gmcharlt at gmail.com  Thu Feb 17 15:45:26 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Thu, 17 Feb 2011 09:45:26 -0500
Subject: [Koha-devel] KohaCon 2011 : The Votes Are In
In-Reply-To: <AANLkTi=0RJqhc+9kzrSUJXebEbwXT9bcXC2tMMHDRT7R@mail.gmail.com>
References: <AANLkTi=0RJqhc+9kzrSUJXebEbwXT9bcXC2tMMHDRT7R@mail.gmail.com>
Message-ID: <AANLkTi=LX0qACF9YTS9tDZX6_2zY-Z9GrtxpM0s6Em93@mail.gmail.com>

Hi,

On Thu, Feb 17, 2011 at 8:18 AM, Nicole Engard <nengard at gmail.com> wrote:

> The raw results will be posted to the wiki (I can't upload a CSV file
> - I need some admin help). I do want to know what your opinions are
> about posting the full CSV file to the wiki - it does have all our
> email addresses. ?I might remove that column before posting if enough
> people express a concern about that or just email the CSV to those who
> want to see the raw results and not worry about posting it publicly at
> all.

An anonymized CSV file with the survey responses can now be found at

http://wiki.koha-community.org/w/images/Kohacon2011-site-survey-results-anonymized.csv

This file includes the site preferences and the voter's institutional
affiliation but does not include the voter's name or email address.

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From ian.walls at bywatersolutions.com  Thu Feb 17 16:55:05 2011
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Thu, 17 Feb 2011 10:55:05 -0500
Subject: [Koha-devel] FW: zebra / Heading-Main
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA311E0262@S-MAIL-1B.rijksmuseum.intra>
References: <809BE39CD64BFD4EB9036172EBCCFA311E0262@S-MAIL-1B.rijksmuseum.intra>
Message-ID: <AANLkTinYxBpr3b6Nnsic0tVOD60_k8ZcTySG1trKCgue@mail.gmail.com>

I'd be happy to stop getting those warning messages in my inbox... so if
what you propose will accomplish that, I'm game for testing.


-Ian

2011/2/17 Marcel de Rooy <M.de.Rooy at rijksmuseum.nl>

>  Only in authorities..
>
>
>
> *Van:* koha-devel-bounces at lists.koha-community.org [mailto:
> koha-devel-bounces at lists.koha-community.org] *Namens *Marcel de Rooy
> *Verzonden:* donderdag 17 februari 2011 15:25
> *Aan:* koha-devel at lists.koha-community.org
> *Onderwerp:* [Koha-devel] zebra / Heading-Main
>
>
>
> Hi,
>
>
>
> Some time ago Heading-Main was introduced in both authorities and biblios
> record.abs in marc_defs/marc21 and marc_defs/unimarc.
>
> Apparently, it was added to extend authority search with the option to
> search only in 100a, 110a, .. fields.
>
> But Heading-Main is not listed in one the attsets (bib1,..)
>
>
>
> This gives the warning: zebraidx(18056) [warn] Index 'Heading-Main' not
> found in attset(s)
>
>
>
> This bug was reported March 2009 (!) under:
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3072
>
> Related reports are: 3052, 3386 and 3429.
>
> We still have the following temporary fix in AuthoritiesMarc.pm :
>
>             ##If mainentry search $a tag
>
>                 if (@$tags[$i] eq "mainmainentry") {
>
>
>
> # FIXME: 'Heading-Main' index not yet defined in zebra
>
> #                $attr =" \@attr 1=Heading-Main ";
>
>                 $attr =" \@attr 1=Heading ";
>
>
>
>
>
> Would anyone of you object against defining a new 8XXX field in authorities
> bib1.att to activate Heading-Main and at the same time fixing
> AuthoritiesMarc.pm ?
>
> We now have there:
>
>
>
> att 8001    Heading
>
> att 8002    See-from
>
> att 8003    See-also-from
>
> att 8804    Match-heading
>
> att 8805    Match-subdivision
>
> att 8806    Subdivision
>
> att 8807    Subdivision-see-also-from
>
> att 8808    Subdivision-see-from
>
> att 8809    Match-heading-see-from
>
> att 8810    Match-subdivision-see-from
>
>
>
> BTW, an interesting way of incrementing from 8001 to 8810? We could add
> 8004 for Heading-Main ? Better idea?
>
>
>
> Regards,
>
>
>
> Marcel
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



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

From tomascohen at gmail.com  Thu Feb 17 17:08:43 2011
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Thu, 17 Feb 2011 13:08:43 -0300
Subject: [Koha-devel] FW: zebra / Heading-Main
In-Reply-To: <809BE39CD64BFD4EB9036172EBCCFA311E0262@S-MAIL-1B.rijksmuseum.intra>
References: <AcvOrmhq+4IjmCyISAywxqOYmH34hwAAfTcg>
	<809BE39CD64BFD4EB9036172EBCCFA311E0262@S-MAIL-1B.rijksmuseum.intra>
Message-ID: <AANLkTikcp0uXgDM3pKj=w4KzwbsQ44EHtsFqj2petKos@mail.gmail.com>

2011/2/17 Marcel de Rooy <M.de.Rooy at rijksmuseum.nl>:
> Only in authorities..

+1

From oleonard at myacpl.org  Thu Feb 17 18:51:55 2011
From: oleonard at myacpl.org (Owen Leonard)
Date: Thu, 17 Feb 2011 12:51:55 -0500
Subject: [Koha-devel] Seeking opinions on Koha's calendar widget
Message-ID: <AANLkTi=g7vCO04mqAPtbre02GnKZu0FUEq0-uPG1jR3A@mail.gmail.com>

I would like to propose that we stop using the calendar widget which
is currently included with Koha and start using the jQuery UI version
at the same time that we incorporate jQuery UI into other areas of
Koha (see bug 5481 - Replace YUI JS libraries with Jquery UI
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5481).

Some reasons:

- It's simpler to manage a single group of jQuery UI widgets than to
continue to maintain a separate set of files just for the calendar.
- jQueryUI is actively developed and packaged with Debian
- Our current calendar widget is not longer being developed under GPL.
The author asks $80 per domain for the current version.
- The current calendar widget uses now-deprecated CSS properties which
are causing problems in some browsers.

The jQueryUI calendar widget can be tested here:

http://jqueryui.com/demos/datepicker/

The configuration which most closely approaches the version we use is this one:

http://jqueryui.com/demos/datepicker/#dropdown-month-year

Note that when we implement jQuery UI we will be creating a "theme"
for all jQuery UI widgets which will be consistent with Koha's colors.
In other words, it doesn't have to be orange :)

Can anyone suggest any reasons why we should not switch?

  -- Owen

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

From ian.walls at bywatersolutions.com  Thu Feb 17 18:55:40 2011
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Thu, 17 Feb 2011 12:55:40 -0500
Subject: [Koha-devel] Seeking opinions on Koha's calendar widget
In-Reply-To: <AANLkTi=g7vCO04mqAPtbre02GnKZu0FUEq0-uPG1jR3A@mail.gmail.com>
References: <AANLkTi=g7vCO04mqAPtbre02GnKZu0FUEq0-uPG1jR3A@mail.gmail.com>
Message-ID: <AANLkTi=iB6No_mkEYpBsii7W49ChxzdVQD3QLXO10t6D@mail.gmail.com>

Owen,


I can't see any compelling reason not to make the switch.  Thanks for laying
it out clearly for us!


-Ian

On Thu, Feb 17, 2011 at 12:51 PM, Owen Leonard <oleonard at myacpl.org> wrote:

> I would like to propose that we stop using the calendar widget which
> is currently included with Koha and start using the jQuery UI version
> at the same time that we incorporate jQuery UI into other areas of
> Koha (see bug 5481 - Replace YUI JS libraries with Jquery UI
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5481).
>
> Some reasons:
>
> - It's simpler to manage a single group of jQuery UI widgets than to
> continue to maintain a separate set of files just for the calendar.
> - jQueryUI is actively developed and packaged with Debian
> - Our current calendar widget is not longer being developed under GPL.
> The author asks $80 per domain for the current version.
> - The current calendar widget uses now-deprecated CSS properties which
> are causing problems in some browsers.
>
> The jQueryUI calendar widget can be tested here:
>
> http://jqueryui.com/demos/datepicker/
>
> The configuration which most closely approaches the version we use is this
> one:
>
> http://jqueryui.com/demos/datepicker/#dropdown-month-year
>
> Note that when we implement jQuery UI we will be creating a "theme"
> for all jQuery UI widgets which will be consistent with Koha's colors.
> In other words, it doesn't have to be orange :)
>
> Can anyone suggest any reasons why we should not switch?
>
>  -- Owen
>
> --
> Web Developer
> Athens County Public Libraries
> http://www.myacpl.org
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



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

From gmcharlt at gmail.com  Thu Feb 17 19:21:44 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Thu, 17 Feb 2011 13:21:44 -0500
Subject: [Koha-devel] Seeking opinions on Koha's calendar widget
In-Reply-To: <AANLkTi=g7vCO04mqAPtbre02GnKZu0FUEq0-uPG1jR3A@mail.gmail.com>
References: <AANLkTi=g7vCO04mqAPtbre02GnKZu0FUEq0-uPG1jR3A@mail.gmail.com>
Message-ID: <AANLkTi=hc4J2Bf=dmT9aNc=Sb33neV6M3iL07V6XNVqy@mail.gmail.com>

Hi,

On Thu, Feb 17, 2011 at 12:51 PM, Owen Leonard <oleonard at myacpl.org> wrote:
> Can anyone suggest any reasons why we should not switch?

For the calendar widget qua date-picker, switching to the jQuery UI
widget makes sense for the reasons you've mentioned.  I do have a
question -- have you checked whether it can be made to work as a
stand-alone calendar widget that is not tied to a form's input field,
e.g., the way the current calendar widget is used on the holidays
page?

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From reedwade at gmail.com  Thu Feb 17 20:38:16 2011
From: reedwade at gmail.com (Reed Wade)
Date: Fri, 18 Feb 2011 08:38:16 +1300
Subject: [Koha-devel] Seeking opinions on Koha's calendar widget
In-Reply-To: <AANLkTi=hc4J2Bf=dmT9aNc=Sb33neV6M3iL07V6XNVqy@mail.gmail.com>
References: <AANLkTi=g7vCO04mqAPtbre02GnKZu0FUEq0-uPG1jR3A@mail.gmail.com>
	<AANLkTi=hc4J2Bf=dmT9aNc=Sb33neV6M3iL07V6XNVqy@mail.gmail.com>
Message-ID: <AANLkTi=KJ9NacwqnUte81ghMioR+_j3c2KFSYdUzrtLc@mail.gmail.com>

On Fri, Feb 18, 2011 at 7:21 AM, Galen Charlton <gmcharlt at gmail.com> wrote:
> Hi,
>
> On Thu, Feb 17, 2011 at 12:51 PM, Owen Leonard <oleonard at myacpl.org> wrote:
>> Can anyone suggest any reasons why we should not switch?
>
> For the calendar widget qua date-picker, switching to the jQuery UI
> widget makes sense for the reasons you've mentioned. ?I do have a
> question -- have you checked whether it can be made to work as a
> stand-alone calendar widget that is not tied to a form's input field,
> e.g., the way the current calendar widget is used on the holidays
> page?


I'd like to add my voice to the 'yes, definitely you want to switch'.

I've had a large project going that is eventually migrating from
exactly that old stinky calendar widget to the jQuery UI calendar
widget -- much more please to use from the user and developer ends.

The only issue we've had is the old stinky widget support time and
date setting so needed to handle time inputs separately.

Galen, it can be used inline and I suspect would work how you're thinking. See:
 http://jqueryui.com/demos/datepicker/#inline

-reed

From gmcharlt at gmail.com  Thu Feb 17 20:55:37 2011
From: gmcharlt at gmail.com (Galen Charlton)
Date: Thu, 17 Feb 2011 14:55:37 -0500
Subject: [Koha-devel] Seeking opinions on Koha's calendar widget
In-Reply-To: <AANLkTi=KJ9NacwqnUte81ghMioR+_j3c2KFSYdUzrtLc@mail.gmail.com>
References: <AANLkTi=g7vCO04mqAPtbre02GnKZu0FUEq0-uPG1jR3A@mail.gmail.com>
	<AANLkTi=hc4J2Bf=dmT9aNc=Sb33neV6M3iL07V6XNVqy@mail.gmail.com>
	<AANLkTi=KJ9NacwqnUte81ghMioR+_j3c2KFSYdUzrtLc@mail.gmail.com>
Message-ID: <AANLkTikm0X54k7-LcHczYAMjbkcK-tbtv1CmJLFBC9p=@mail.gmail.com>

Hi,

On Thu, Feb 17, 2011 at 2:38 PM, Reed Wade <reedwade at gmail.com> wrote:
> Galen, it can be used inline and I suspect would work how you're thinking. See:
> ?http://jqueryui.com/demos/datepicker/#inline

Thanks for confirming.

+1 to the switch.

Regards,

Galen
-- 
Galen Charlton
gmcharlt at gmail.com

From reedwade at gmail.com  Thu Feb 17 21:02:10 2011
From: reedwade at gmail.com (Reed Wade)
Date: Fri, 18 Feb 2011 09:02:10 +1300
Subject: [Koha-devel] Seeking opinions on Koha's calendar widget
In-Reply-To: <AANLkTi=KJ9NacwqnUte81ghMioR+_j3c2KFSYdUzrtLc@mail.gmail.com>
References: <AANLkTi=g7vCO04mqAPtbre02GnKZu0FUEq0-uPG1jR3A@mail.gmail.com>
	<AANLkTi=hc4J2Bf=dmT9aNc=Sb33neV6M3iL07V6XNVqy@mail.gmail.com>
	<AANLkTi=KJ9NacwqnUte81ghMioR+_j3c2KFSYdUzrtLc@mail.gmail.com>
Message-ID: <AANLkTi=VgthQGydF02WgG8w6r=sT4L7rOX6BmWPpJoi-@mail.gmail.com>

Further---

It's well worth considering a whole hog shift to the jQuery UI widgets
throughout.

-reed



On Fri, Feb 18, 2011 at 8:38 AM, Reed Wade <reedwade at gmail.com> wrote:
> On Fri, Feb 18, 2011 at 7:21 AM, Galen Charlton <gmcharlt at gmail.com> wrote:
>> Hi,
>>
>> On Thu, Feb 17, 2011 at 12:51 PM, Owen Leonard <oleonard at myacpl.org> wrote:
>>> Can anyone suggest any reasons why we should not switch?
>>
>> For the calendar widget qua date-picker, switching to the jQuery UI
>> widget makes sense for the reasons you've mentioned. ?I do have a
>> question -- have you checked whether it can be made to work as a
>> stand-alone calendar widget that is not tied to a form's input field,
>> e.g., the way the current calendar widget is used on the holidays
>> page?
>
>
> I'd like to add my voice to the 'yes, definitely you want to switch'.
>
> I've had a large project going that is eventually migrating from
> exactly that old stinky calendar widget to the jQuery UI calendar
> widget -- much more please to use from the user and developer ends.
>
> The only issue we've had is the old stinky widget support time and
> date setting so needed to handle time inputs separately.
>
> Galen, it can be used inline and I suspect would work how you're thinking. See:
> ?http://jqueryui.com/demos/datepicker/#inline
>
> -reed
>

From henridamien.laurent at gmail.com  Thu Feb 17 22:04:50 2011
From: henridamien.laurent at gmail.com (LAURENT Henri-Damien)
Date: Thu, 17 Feb 2011 22:04:50 +0100
Subject: [Koha-devel] Seeking opinions on Koha's calendar widget
In-Reply-To: <AANLkTikm0X54k7-LcHczYAMjbkcK-tbtv1CmJLFBC9p=@mail.gmail.com>
References: <AANLkTi=g7vCO04mqAPtbre02GnKZu0FUEq0-uPG1jR3A@mail.gmail.com>	<AANLkTi=hc4J2Bf=dmT9aNc=Sb33neV6M3iL07V6XNVqy@mail.gmail.com>	<AANLkTi=KJ9NacwqnUte81ghMioR+_j3c2KFSYdUzrtLc@mail.gmail.com>
	<AANLkTikm0X54k7-LcHczYAMjbkcK-tbtv1CmJLFBC9p=@mail.gmail.com>
Message-ID: <4D5D8D72.60609@gmail.com>

Le 17/02/2011 20:55, Galen Charlton a ?crit :
> Hi,
> 
> On Thu, Feb 17, 2011 at 2:38 PM, Reed Wade <reedwade at gmail.com> wrote:
>> Galen, it can be used inline and I suspect would work how you're thinking. See:
>>  http://jqueryui.com/demos/datepicker/#inline
> 
> Thanks for confirming.
> 
> +1 to the switch.
> 
> Regards,
> 
> Galen

I have seen #localize...
+1 for the switch.
(and as far as I am concerned, everything that comes to unification and
simplification of the tools used, you can count on me)
-- 
Henri-Damien LAURENT

From colin.campbell at ptfs-europe.com  Thu Feb 17 22:18:23 2011
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Thu, 17 Feb 2011 21:18:23 +0000
Subject: [Koha-devel] Seeking opinions on Koha's calendar widget
In-Reply-To: <AANLkTi=g7vCO04mqAPtbre02GnKZu0FUEq0-uPG1jR3A@mail.gmail.com>
References: <AANLkTi=g7vCO04mqAPtbre02GnKZu0FUEq0-uPG1jR3A@mail.gmail.com>
Message-ID: <4D5D909F.3030707@ptfs-europe.com>

On 17/02/11 17:51, Owen Leonard wrote:
> I would like to propose that we stop using the calendar widget which
> is currently included with Koha and start using the jQuery UI version
> at the same time that we incorporate jQuery UI into other areas of
> Koha (see bug 5481 - Replace YUI JS libraries with Jquery UI
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5481).
Definitely concur +1

Colin

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

http://www.ptfs-europe.com

From mao at lins.fju.edu.tw  Fri Feb 18 05:32:13 2011
From: mao at lins.fju.edu.tw (=?UTF-8?B?5q+b5oW256aO?=)
Date: Fri, 18 Feb 2011 12:32:13 +0800
Subject: [Koha-devel] KohaCon 2011 : The Votes Are In
In-Reply-To: <AANLkTi=LX0qACF9YTS9tDZX6_2zY-Z9GrtxpM0s6Em93@mail.gmail.com>
References: <AANLkTi=0RJqhc+9kzrSUJXebEbwXT9bcXC2tMMHDRT7R@mail.gmail.com>
	<AANLkTi=LX0qACF9YTS9tDZX6_2zY-Z9GrtxpM0s6Em93@mail.gmail.com>
Message-ID: <AANLkTin_AyN16YN2XkPLtX6+4XpPn65m0Fk6ukqguahE@mail.gmail.com>

Congratulations to the organizers of the Thane.
What happen if we remove those who vote for himself?

A lot of vote come from the organizers themselves.
http://wiki.koha-community.org/w/images/Kohacon2011-site-survey-results-anonymized.csv

2011/2/17 Galen Charlton <gmcharlt at gmail.com>:
> Hi,
>
> On Thu, Feb 17, 2011 at 8:18 AM, Nicole Engard <nengard at gmail.com> wrote:
>
>> The raw results will be posted to the wiki (I can't upload a CSV file
>> - I need some admin help). I do want to know what your opinions are
>> about posting the full CSV file to the wiki - it does have all our
>> email addresses. ?I might remove that column before posting if enough
>> people express a concern about that or just email the CSV to those who
>> want to see the raw results and not worry about posting it publicly at
>> all.
>
> An anonymized CSV file with the survey responses can now be found at
>
> http://wiki.koha-community.org/w/images/Kohacon2011-site-survey-results-anonymized.csv
>
> This file includes the site preferences and the voter's institutional
> affiliation but does not include the voter's name or email address.
>
> Regards,
>
> Galen
> --
> Galen Charlton
> gmcharlt at gmail.com
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/



-- 
Wishing you all the best. . . .


Anthony Mao ??? http://bit.ly/maolins
Department of Library and Information Science
Fu Jen Catholic University ?http://bit.ly/lins
510 Jhongjheng Rd., Sinjhuang City,
Taipei County 24205,
Taiwan

From fridolyn.somers at gmail.com  Fri Feb 18 07:23:23 2011
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Fri, 18 Feb 2011 07:23:23 +0100
Subject: [Koha-devel] FW: zebra / Heading-Main
In-Reply-To: <AANLkTikcp0uXgDM3pKj=w4KzwbsQ44EHtsFqj2petKos@mail.gmail.com>
References: <809BE39CD64BFD4EB9036172EBCCFA311E0262@S-MAIL-1B.rijksmuseum.intra>
	<AANLkTikcp0uXgDM3pKj=w4KzwbsQ44EHtsFqj2petKos@mail.gmail.com>
Message-ID: <AANLkTikqfb6igo2W0-piXg7oFHeSG6UA7OQyA8ua+Z9u@mail.gmail.com>

By the way,
why isn't the query for authorities searching in CCL ?
I would be more clear and use named-indexes.

Regards,

On Thu, Feb 17, 2011 at 5:08 PM, Tomas Cohen Arazi <tomascohen at gmail.com>wrote:

> 2011/2/17 Marcel de Rooy <M.de.Rooy at rijksmuseum.nl>:
> > Only in authorities..
>
> +1
> _______________________________________________
> 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/20110218/46b16da6/attachment.htm>

From chris at bigballofwax.co.nz  Fri Feb 18 08:51:20 2011
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Fri, 18 Feb 2011 20:51:20 +1300
Subject: [Koha-devel] KohaCon 2011 : The Votes Are In
In-Reply-To: <AANLkTin_AyN16YN2XkPLtX6+4XpPn65m0Fk6ukqguahE@mail.gmail.com>
References: <AANLkTi=0RJqhc+9kzrSUJXebEbwXT9bcXC2tMMHDRT7R@mail.gmail.com>
	<AANLkTi=LX0qACF9YTS9tDZX6_2zY-Z9GrtxpM0s6Em93@mail.gmail.com>
	<AANLkTin_AyN16YN2XkPLtX6+4XpPn65m0Fk6ukqguahE@mail.gmail.com>
Message-ID: <AANLkTi=SynVeW4VMLv2aerZ=RzByHy2j-4BZQhr6Zf_a@mail.gmail.com>

On 18 February 2011 17:32, ??? <mao at lins.fju.edu.tw> wrote:
> Congratulations to the organizers of the Thane.
> What happen if we remove those who vote for himself?
>
> A lot of vote come from the organizers themselves.
> http://wiki.koha-community.org/w/images/Kohacon2011-site-survey-results-anonymized.csv
>

For a purely academic exercise, lets say we decided to discard those
votes (NOTE Im not saying we should do that. this is just for an
exercise)

That leaves 209 first place votes for Thane = 836 points

Next closest is Nepal with 107 = 428
Then with 32 second place votes for nepal = 96 = 524
93 third place votes = 186 = 710
24 fourth place votes = 734

So throwing out all the votes for Thane from VPM Thane, and not
counting any of the 2nd, 3rd and forth place votes for it, it still
wins.

Chris

From cnighswonger at foundations.edu  Fri Feb 18 13:36:55 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Fri, 18 Feb 2011 07:36:55 -0500
Subject: [Koha-devel] Seeking opinions on Koha's calendar widget
In-Reply-To: <AANLkTikm0X54k7-LcHczYAMjbkcK-tbtv1CmJLFBC9p=@mail.gmail.com>
References: <AANLkTi=g7vCO04mqAPtbre02GnKZu0FUEq0-uPG1jR3A@mail.gmail.com>
	<AANLkTi=hc4J2Bf=dmT9aNc=Sb33neV6M3iL07V6XNVqy@mail.gmail.com>
	<AANLkTi=KJ9NacwqnUte81ghMioR+_j3c2KFSYdUzrtLc@mail.gmail.com>
	<AANLkTikm0X54k7-LcHczYAMjbkcK-tbtv1CmJLFBC9p=@mail.gmail.com>
Message-ID: <AANLkTinY_FYkZwPNfLinqm8=7d5qqH3aTfjHaYTGQW7f@mail.gmail.com>

 On Thu, Feb 17, 2011 at 2:55 PM, Galen Charlton <gmcharlt at gmail.com> wrote:

> Hi,
>
> On Thu, Feb 17, 2011 at 2:38 PM, Reed Wade <reedwade at gmail.com> wrote:
> > Galen, it can be used inline and I suspect would work how you're
> thinking. See:
> >  http://jqueryui.com/demos/datepicker/#inline
>
> Thanks for confirming.
>
> +1 to the switch.
>
>
Trying again.... ;-)

+1 to switch as well.

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

From paul.poulain at biblibre.com  Fri Feb 18 13:59:34 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Fri, 18 Feb 2011 13:59:34 +0100
Subject: [Koha-devel] Seeking opinions on Koha's calendar widget
In-Reply-To: <AANLkTi=g7vCO04mqAPtbre02GnKZu0FUEq0-uPG1jR3A@mail.gmail.com>
References: <AANLkTi=g7vCO04mqAPtbre02GnKZu0FUEq0-uPG1jR3A@mail.gmail.com>
Message-ID: <4D5E6D36.3090703@biblibre.com>

Le 17/02/2011 18:51, Owen Leonard a ?crit :
> The jQueryUI calendar widget can be tested here:
>
> http://jqueryui.com/demos/datepicker/
+1
;-)

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


From tomascohen at gmail.com  Fri Feb 18 19:26:30 2011
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Fri, 18 Feb 2011 15:26:30 -0300
Subject: [Koha-devel] Add authorities add/del/mod logging
Message-ID: <AANLkTin58YG4BQyF4djmkn2aDo8FHPJ96tCjHtsEFcFY@mail.gmail.com>

Hi,

I'm planning to add logging to the authorities management. In the
'action_logs' table we have, for biblios:

module : CATALOGUING
action   : ADD/DELETE/MODIFY for biblios, and other actions for issuing,
object   : a biblionumber or itemnumber
info       : string: 'biblio' or 'item' or previous 'marc' field (when
MODIFYing)

My first thought was that we could use 'CATALOGUING' too, and that
instead of 'biblio' in the info field we could use 'authority'.
Something like

module : CATALOGUING
action   : ADD/DELETE/MODIFY
object   : a authid
info       : string: 'authority' or previous 'marc' field (when MODIFYing)

But I realized that it is impossible to differentiate, from
tools/viewlog.pl point of view, if we're talking about a biblionumber
or an itemnumber (and now an authid) when the operation is MODIFY.
Check this from Items.pm:

logaction("CATALOGUING", "MODIFY", $itemnumber,
$new_item_marc->as_formatted) if
C4::Context->preference("CataloguingLog");

In the results in fact, they are all shown as biblios (bug?)! So,
adding 'authid' to the mix will make it worse.
Should I add AUTHCAT module? Should we split CATALOGUING module into
BIBLIOCAT and ITEMCAT? Also: should we avoid logging when calling
ModItem from Issues::AddIssue? It looks too much overhead as there is
a call to $new_item_marc->as_formatted.

Have a nice weekend!
To+

From kmkale at anantcorp.com  Sat Feb 19 04:27:27 2011
From: kmkale at anantcorp.com (Koustubha Kale)
Date: Sat, 19 Feb 2011 08:57:27 +0530
Subject: [Koha-devel] [Koha] KohaCon 2011 : The Votes Are In
In-Reply-To: <AANLkTikVKoXsPMP6giG9miTb1fu_F0eHogxp_xAhqZ4m@mail.gmail.com>
References: <AANLkTi=0RJqhc+9kzrSUJXebEbwXT9bcXC2tMMHDRT7R@mail.gmail.com>
	<20110218112701.0CB194F733@nail.towers.org.uk>
	<AANLkTikVKoXsPMP6giG9miTb1fu_F0eHogxp_xAhqZ4m@mail.gmail.com>
Message-ID: <AANLkTiksWoQrk-0Lnp_7jDoJZv6X09GAN_mDw7YCnSrC@mail.gmail.com>

Hi All,
I am just back from a Koha training trip in Konkan. And this is great
news to come back to. :)

Thanks to all who voted for VPM, Thane, India.
And also special thanks to Nicole for conducting the vote.

I will start preparations and discussions immediately as soon as I
reach office. Looking forward to participation, help and advise from
all the Koha community in making KohaCon11 a success..


Regards,
Koustubha Kale
Anant Corporation

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



On Fri, Feb 18, 2011 at 5:26 PM, Nicole Engard <nengard at gmail.com> wrote:
> On Fri, Feb 18, 2011 at 6:27 AM, MJ Ray <mjr at phonecoop.coop> wrote:
>> So... how can we win next time? ?In particular, should we bid with
>> Weston-super-Mare or Edinburgh and are there any other pointers or
>> tips that people would like to pass on, on-list or privately?
>
> MJ, I think it was pure numbers! ?With India off the table next year
> (based on talks on #koha) I think we're gonna see a European location
> next year :) I liked your location choice - all I wanted was for it to
> be in the spring instead of the fall (but that's just me).
>
> Nicole
> _______________________________________________
> Koha mailing list ?http://koha-community.org
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>

From jransom at library.org.nz  Mon Feb 21 03:53:29 2011
From: jransom at library.org.nz (Joann Ransom)
Date: Mon, 21 Feb 2011 15:53:29 +1300
Subject: [Koha-devel] Who are the various Koha vendors in the USA?
In-Reply-To: <AANLkTinqM1_aXgc6-UgbsNunGx+8O8OL2psrza1uDcUf@mail.gmail.com>
References: <AANLkTimv5Qso08KXJ=roiPi8OFXsEBn8pJGC8ZWtpUd2@mail.gmail.com>
	<AANLkTinqM1_aXgc6-UgbsNunGx+8O8OL2psrza1uDcUf@mail.gmail.com>
Message-ID: <AANLkTikcLbpQmPS1sijVyZXsYFCR4d3iQzMjHtZXZM_Q@mail.gmail.com>

ByWater have an excellent reputation in the States - check out Marshall
Breeding's Perception guide:
http://www.librarytechnology.org/perceptions2010.pl

I wouldn't go near PTFS if you are looking for open source Koha.

Cheers Jo.

2011/2/21 Buster <storypage at gmail.com>

> And which one do you use, if any?
>
>
> I know about LibLime and Bay Water. Anybody else?
>
> --JimMaroon
>
> --
>
> ==================================================
> "The man, who, by his own and his family's labour, can provide a
> sufficiency of food and raiment and a comfortable dwelling place, is not a
> poor man." --William Cobbett, *Cottage Economy*, 1826.
>
>
>
> _______________________________________________
> Koha mailing list  http://koha-community.org
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>
>


-- 
Joann Ransom RLIANZA
Head of Libraries,
Horowhenua Library Trust.

*Q: Why is this email three sentences or less?
A: http://three.sentenc.es*




-- 
Joann Ransom RLIANZA
Head of Libraries,
Horowhenua Library Trust.

*Q: Why is this email three sentences or less?
A: http://three.sentenc.es*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110221/661b1f12/attachment.htm>

From kmkale at anantcorp.com  Mon Feb 21 08:01:13 2011
From: kmkale at anantcorp.com (Koustubha Kale)
Date: Mon, 21 Feb 2011 12:31:13 +0530
Subject: [Koha-devel] KohaCon2011
Message-ID: <AANLkTi=ubmNMzO_AAVy5K59e-hjx9i_hUr61n87FX6_D@mail.gmail.com>

Hi All,
To get the ball rolling, I have put up a page in Koha wiki at
http://wiki.koha-community.org/wiki/KohaCon2011

I have also put up a supporting site at http://kohacon11.vpmthane.org/
Its just a stub yet but I will be working on it.

Looking for ideas, volunteers, suggestions, comments.....

Regards,
Koustubha Kale
Anant Corporation

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

From irmalibraries at gmail.com  Mon Feb 21 09:26:55 2011
From: irmalibraries at gmail.com (Irma Birchall)
Date: Mon, 21 Feb 2011 19:26:55 +1100
Subject: [Koha-devel] KohaCon2011
In-Reply-To: <AANLkTi=ubmNMzO_AAVy5K59e-hjx9i_hUr61n87FX6_D@mail.gmail.com>
References: <AANLkTi=ubmNMzO_AAVy5K59e-hjx9i_hUr61n87FX6_D@mail.gmail.com>
Message-ID: <4D6221CF.9050400@gmail.com>

Hi Koustubha,

Thank you for starting the ball rolling and creating the KohaCon2011 
wiki page.

Is this the correct address of the campus where the conference might be 
hosted?

Location: Vidya Prasarak Mandal Chendani Bunder Road, Thane (West) - 400601

http://wiki.koha-community.org/wiki/KohaCon2011#KohaCon_2011_:_VPM.2C_Thane.2C_India

Best wishes.
Irma
CALYX




On 21/02/11 18:01, Koustubha Kale wrote:
> Hi All,
> To get the ball rolling, I have put up a page in Koha wiki at
> http://wiki.koha-community.org/wiki/KohaCon2011
>
> I have also put up a supporting site at http://kohacon11.vpmthane.org/
> Its just a stub yet but I will be working on it.
>
> Looking for ideas, volunteers, suggestions, comments.....
>
> Regards,
> Koustubha Kale
> Anant Corporation
>
> Contact Details :
> Address  : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes
> Naka, Thane (w),
>                  Maharashtra, India, Pin : 400601.
> TeleFax  : +91-22-21720108, +91-22-21720109
> Mobile     : +919820715876
> Website  : http://www.anantcorp.com
> Blog : http://www.anantcorp.com/blog/?author=2
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/


From Cole.Hudson at hc.msu.edu  Mon Feb 21 14:05:58 2011
From: Cole.Hudson at hc.msu.edu (Cole Hudson)
Date: Mon, 21 Feb 2011 08:05:58 -0500
Subject: [Koha-devel] Editing the Comments feature on Koha
Message-ID: <89A35FEF98F9384BBB1360526A846BC7041D87B7@TEAM-EXCHANGE1.hc.msu.edu>

*Note: my apologies to all who have already seen this post on the koha
general list-serv*

 

Hi all,

 

I'm running Koha 3.02 on Ubuntu 10.10.  I'm trying to edit the comments
feature that displays with each record in the opac.  I'd like to edit it
where the name of the patron is not pulled from each patron record-so as
to make comments anonymous.  Could someone point me in the right
direction here on what code to edit/remove?  Thanks.

 

Cole Hudson

Library Assistant

MSU College of Osteopathic Medicine

Macomb University Center

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

From henridamien.laurent at gmail.com  Mon Feb 21 15:36:08 2011
From: henridamien.laurent at gmail.com (LAURENT Henri-Damien)
Date: Mon, 21 Feb 2011 15:36:08 +0100
Subject: [Koha-devel] Solr and Z3950 server some news.
In-Reply-To: <35132216e858a2e00a6b966fa9552380.squirrel@wmail.agogme.com>
References: <4D510CE4.70409@biblibre.com>
	<4ef2c1d826b8ef42ff870d0fba44be54.squirrel@wmail.agogme.com>
	<4D54EFE5.2070403@biblibre.com>
	<02ac1f4ee319671a732cc1440d28be21.squirrel@wmail.agogme.com>
	<4D550BB2.1090801@gmail.com>
	<35132216e858a2e00a6b966fa9552380.squirrel@wmail.agogme.com>
Message-ID: <4D627858.7060105@gmail.com>

Hi
Just some more interesting news.

Le 11/02/2011 20:01, Thomas Dukleth a ?crit :
> When briefly testing the BibLibre test configuration of SimpleServer
> Z39.50 server I have found same problem as BibLibre are reporting when
> using yaz-client.  I have also noted some other issues.
> 
> 1.  BAD MARC ERROR.
> 
> When setting format to UNIMARC in yaz-client, the following error message
> is returned along with the record when displaying a record with the show
> command.
> 
> "[]Record type: Unimarc
> 
> bad MARC. Dumping as it is:"
> 
> When setting format to XML in yaz-client, no error message is returned
> when displaying a  record with the show command.
> 
> "[]Record type: XML"
> 
> The issue seems to be consistent for all records in the result set.
> 
> YAZ is converting between ISO 2709 and MARCXML on the client side.
> 
> yaz-client does not report a "bad MARC" error when displaying UNIMARC
> MARCXML records returned from Zebra in ISO 2709 form.
> 
> Whatever the MARC error may be, it prevents YAZ from parsing the records
> properly in ISO 2709.  Consequently, unlike yaz-client, my very well
> tested PHP YAZ based Z39.50 client obtains the result set but cannot even
> attempt to display the records because it relies upon YAZ for parsing
> them.
This issue is still worked upon...
Work in progress.
I hope we can find a solution this week.
We are diving into the SimpleServer code + yaz source code to find a way
to get this right.


> 2.  INVARIANT RESULT SET.
> 
> In the configuration which I tested, any query would return exactly the
> same 1011 record result set whether or not there would be any legitimate
> matches.
This has been fixed.
This was owed to the fact that the RegExp::Grammars installed was too old.


> 
> 
> 3.  MISSING EXPLAIN RECORD.
> 
> Lack of an Explain record should not be fatal but might be helpful for
> obtaining more debugging information from YAZ.
I have added a call to a minimal zebra configuration file.
And should be fixed now.

> 
> 
> 4.  DEBUGGING.
> 
> I do not have time to try intensive tests myself.
> 
> First, fix the issue where the result set is an invariant 1011 records.

> 
> I suggest having yaz-client save the ISO 2709 records, then attempt to
> validate them with MARC::Lint keeping in mind that most errors would be
> from the MARC 21 checks in MARC::Lint.
> 
> I have not verified that MARCXML is working with SimpleServer using
> Solr/Lucene but I would be happy to test that if some SimpleServer target
> would be configured to return only MARCXML.
> 
> If all else fails, Index Data can help solve the problems for a very
> significant fee.

Hope that helps.
-- 
Henri-Damien LAURENT

From nengard at gmail.com  Mon Feb 21 22:47:25 2011
From: nengard at gmail.com (Nicole Engard)
Date: Mon, 21 Feb 2011 16:47:25 -0500
Subject: [Koha-devel] Call for Articles: February Newsletter
In-Reply-To: <AANLkTik4_pEkve76TX6guxZtCvwioyOb91JF1mddRTfa@mail.gmail.com>
References: <AANLkTik4_pEkve76TX6guxZtCvwioyOb91JF1mddRTfa@mail.gmail.com>
Message-ID: <AANLkTi=urLEwjqLhDp9=kHFu2FV=Yuosn=aV=MLH97Yq@mail.gmail.com>

I have gotten only one article so far - please send along your news -
no matter how small.

Nicole

On Mon, Feb 7, 2011 at 10:14 PM, Nicole Engard <nengard at gmail.com> wrote:
> Hi all,
>
> It's that time again - please get me your newsletter articles by the
> 23rd (your time zone) of February so that I can include them in the
> newsletter.
>
> Thanks a bunch,
> Nicole C. Engard
>

From chris.nighswonger at gmail.com  Tue Feb 22 04:24:16 2011
From: chris.nighswonger at gmail.com (Christopher Nighswonger)
Date: Mon, 21 Feb 2011 22:24:16 -0500
Subject: [Koha-devel] Koha 3.2.4 is now available
Message-ID: <AANLkTi=VeDTfG+pV77_bf1BtbiEQsVob5LywX=C=HX8T@mail.gmail.com>

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

The package can be retrieved from:

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

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

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

Release notes for 3.2.3 are below the fold.

Come and get it!

RELEASE NOTES FOR KOHA 3.2.4 - 22 February 2011
========================================================================

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

    http://koha-community.org/

Koha 3.2.4 can be downloaded from:

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

Installation instructions can be found at:

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

Koha 3.2.4 is a bugfix/maintenance release.

Highlights of 3.2.4
======================

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

2341    items marked 'On Order' (notforloan == -1) don't interact
correctly with opac-reserve.tmpl
4263    repeatable subfields in items
5376    Batch Edit and Delete need Superlibrarian Permissions
5683    link_bibs_to_authorities.pl can corrupt records
5477    Test cases requiring database access fail
5681    Autobarcode using C4::Barcode has issues with leading zeros
and large values
5731    If an item doesn't have a collection code set, moredetail.pl will error

This release also contains a variety of minor enhancements improving
Koha's interface and underlying scripts as well as updates to several
translations.

Bugs fixed in 3.2.4
======================

2742    Wrong language name in the preferences
3009    Change items.content field so it prints due date by default
3212    MARC21 leader plugins should force Leader/09 to 'a'
3319    Need a nicer error message when attempting to add a patron
with no libraries defined
4160    Currency Conversion dosn't handle rates other than 100
5115    Tags JavaScript includes many untranslatable strings
5140    In Chrome, drop-down menus disappear after using pop-up calendar
5230    MARC export by call number range results in a zero byte file
5661    Authority search return an "Error 500" when "Sort by" is set
to "No order"
5673    Incorrect Test of guarantorid
5689    System preference notifications are not translatable
5690    items.timestamp was not being updated when an item was edited
5691    If someone deletes all items, with independent branches on, it
deletes all
5699    Don't ignore subfield 3 when building a new record (UNIMARC specfic)
5700    Statuses not being set properly
5718    Moveitem has the wrong permissions
5735    Expanding/collapsing cloned fields in editor takes original field
5736    Fixing some zebra configuration errors in marc21/biblios/record.abs
5741    Extra comma causes JavaScript error in Internet Explorer
5745    overdues with fines not showing titles
5777    System preferences Tab content title and Save button partially
translatable
4306    Label manage batch listing should show item-level itemtype
5452    Overdue date color in borrower's today issues
5616    UTF-8 problem in Card View
5629    Adding anchor to holdings link in opac-detail.pl tabs
5665    Routing slip prints too wide for narrow printers
5702    Opac - Results : Highlight link need IF condition
5726    Fix a bug in the selection of biblios to merge
5727    Use of uninitialized value in concatenation (.) or string
5734    Fix column order in issue history
5751    Removing refetences to unused members quicksearch code/template
5759    When printing a borrowers information the secondary email
address is not printed
5769    notice tab disappearing on edit patron
5776    menu on funds wraps when only 1 fund
5649    Change wording on review.tmpl from white/blacklists to approved/rejected
5654    misc/installer_devel_notes not needed
5716    Whitespace correction for browse shelf link
4931    Stocktaking must be based on holdingbranch instead of homebranch
5506    Translation Process Simplification
5532    "Saved" message for sysprefs editor should show names of saved prefs
5733    Empty cart in intranet when session is closed
5760    Add the jquery table sorter to borrowers reading record

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

    Changes since 3.0:

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

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

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

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

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

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

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

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

The Git repository for the Koha manual can be found at

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

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

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

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

Partial translations are available for various other languages.

The Koha team welcomes additional translations; please see

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

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

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

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

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

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

The release team for Koha 3.2 is

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

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

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

D Ruth Bavousett
Jared Camins-Esakov
Colin Campbell
Fr?d?rick Capovilla
Jerome Charaoui
Galen Charlton
Chris Cormack
Fr?d?ric Demians
Magnus Enger
Katrin Fischer
Henri-Damien LAURENT
Owen Leonard
Chris Nighswonger
Liz Rea
Marcel de Rooy
Paul Poulain
Brice Sanchez
David Schuster
Robin Sheat
Reed Wade
Ian Walls


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

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

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

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

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

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

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

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

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

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

Naku te rourou, nau te rourou, ka ora ai te iwi.

From kmkale at anantcorp.com  Tue Feb 22 04:45:43 2011
From: kmkale at anantcorp.com (Koustubha Kale)
Date: Tue, 22 Feb 2011 09:15:43 +0530
Subject: [Koha-devel] KohaCon2011
In-Reply-To: <4D6221CF.9050400@gmail.com>
References: <AANLkTi=ubmNMzO_AAVy5K59e-hjx9i_hUr61n87FX6_D@mail.gmail.com>
	<4D6221CF.9050400@gmail.com>
Message-ID: <AANLkTikjKN+4Ko+mRGnrxWuUeHGWenFk6Gv_=wR8LMAV@mail.gmail.com>

Yes it is.

Here is the link to the campus on Google maps

http://www.google.co.in/mapmaker?gw=39&fid=0x3be7b927cd6912b9:0xcd4b44329d5ed6bb


Planning to add lots of info on the wiki asap..


Regards,
Koustubha Kale
Anant Corporation

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



On Mon, Feb 21, 2011 at 1:56 PM, Irma Birchall <irmalibraries at gmail.com> wrote:
> Hi Koustubha,
>
> Thank you for starting the ball rolling and creating the KohaCon2011 wiki
> page.
>
> Is this the correct address of the campus where the conference might be
> hosted?
>
> Location: Vidya Prasarak Mandal Chendani Bunder Road, Thane (West) - 400601
>
> http://wiki.koha-community.org/wiki/KohaCon2011#KohaCon_2011_:_VPM.2C_Thane.2C_India
>
> Best wishes.
> Irma
> CALYX
>
>
>
>
> On 21/02/11 18:01, Koustubha Kale wrote:
>>
>> Hi All,
>> To get the ball rolling, I have put up a page in Koha wiki at
>> http://wiki.koha-community.org/wiki/KohaCon2011
>>
>> I have also put up a supporting site at http://kohacon11.vpmthane.org/
>> Its just a stub yet but I will be working on it.
>>
>> Looking for ideas, volunteers, suggestions, comments.....
>>
>> Regards,
>> Koustubha Kale
>> Anant Corporation
>>
>> Contact Details :
>> Address ?: 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes
>> Naka, Thane (w),
>> ? ? ? ? ? ? ? ? Maharashtra, India, Pin : 400601.
>> TeleFax ?: +91-22-21720108, +91-22-21720109
>> Mobile ? ? : +919820715876
>> Website ?: http://www.anantcorp.com
>> Blog : http://www.anantcorp.com/blog/?author=2
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>
> _______________________________________________
> 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 cybermon at gmail.com  Tue Feb 22 09:54:03 2011
From: cybermon at gmail.com (Cybermon)
Date: Tue, 22 Feb 2011 16:54:03 +0800
Subject: [Koha-devel] koha cataloging
Message-ID: <AANLkTinbA7tGeMk2J-d0HhFbtabS=g9j8yhwbW9RCT=d@mail.gmail.com>

Dear All,

I would like to ask about few questions for koha configuration. I was
successfully installed the koha used following address.
http://wiki.koha-community.org/wiki/Koha_3.2_on_Debian_Squeeze. But my opac
address not working only show the apache the default web page /it works/,
 which configuration is missing for me.

I would like to add *084/other classification/* field for Koha cataloging,
what should i do ?

Best regards,
Gana
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110222/06e9d784/attachment.htm>

From mjr at phonecoop.coop  Tue Feb 22 10:24:08 2011
From: mjr at phonecoop.coop (MJ Ray)
Date: Tue, 22 Feb 2011 09:24:08 +0000 (GMT)
Subject: [Koha-devel] koha cataloging
In-Reply-To: <AANLkTinbA7tGeMk2J-d0HhFbtabS=g9j8yhwbW9RCT=d@mail.gmail.com>
Message-ID: <20110222092408.3EACAF7EEF@nail.towers.org.uk>

Cybermon wrote:
> I would like to ask about few questions for koha configuration. I was
> successfully installed the koha used following address.
> http://wiki.koha-community.org/wiki/Koha_3.2_on_Debian_Squeeze. But my opac
> address not working only show the apache the default web page /it works/,
>  which configuration is missing for me.
> 
> I would like to add *084/other classification/* field for Koha cataloging,
> what should i do ?

These are not development questions.  They would be better asked
in the general discussion area, not koha-devel.

Quick answers:

1. you probably have a default virtual host taking priority over your
koha virtual host. "a2dissite default" may be a quick fix, but reading
the /usr/share/doc/apache2-common files and http://httpd.apache.org/docs/
will explain why that happened.  It's a problem with apache httpd setup,
not with koha setup.

2. you edit the framework(s) to add that field if it's not present or
not as you want.

Hope that helps,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire for Koha work http://www.software.coop/products/koha

From paul.poulain at biblibre.com  Tue Feb 22 12:04:32 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Tue, 22 Feb 2011 12:04:32 +0100
Subject: [Koha-devel] bugzilla workflow, question when "pushed,
	pls test" rejected
Message-ID: <4D639840.4070507@biblibre.com>

Hello,

On http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3495, chris
has pushed a patch, it's now "patch pushed" "please test".
I tested and have found a problem (see comment 3)
Should I modify the patch status ? which value to set to have the RM
seing there's something more to do ?

What i know for sure is that it can't stay "patch pushed", as there's a
problem ;-)

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


From cnighswonger at foundations.edu  Tue Feb 22 12:46:53 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Tue, 22 Feb 2011 06:46:53 -0500
Subject: [Koha-devel] bugzilla workflow, question when "pushed,
	pls test" rejected
In-Reply-To: <4D639840.4070507@biblibre.com>
References: <4D639840.4070507@biblibre.com>
Message-ID: <AANLkTin_7c+C_x-k8SoYP7U-9zFfhX72apNN1SqX+rpB@mail.gmail.com>

 On Tue, Feb 22, 2011 at 6:04 AM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Hello,
>
> On http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3495, chris
> has pushed a patch, it's now "patch pushed" "please test".
> I tested and have found a problem (see comment 3)
> Should I modify the patch status ? which value to set to have the RM
> seing there's something more to do ?
>
> What i know for sure is that it can't stay "patch pushed", as there's a
> problem ;-)
>

Chris can correct me if I'm wrong....


Once the patch has been pushed to a QA branch it is "Pushed for QA."

If it fails QA it should be "Failed QA."

If it passes it should be "Needs sign off" or "Signed off."

Once pushed to master it is "Patch Pushed."

If at any time it fails a test the status should return to "Failed QA."

At least that's how I read it.

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

From paul.poulain at biblibre.com  Tue Feb 22 12:59:22 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Tue, 22 Feb 2011 12:59:22 +0100
Subject: [Koha-devel] bugzilla workflow, question when "pushed,
 pls test" rejected
In-Reply-To: <AANLkTin_7c+C_x-k8SoYP7U-9zFfhX72apNN1SqX+rpB@mail.gmail.com>
References: <4D639840.4070507@biblibre.com>
	<AANLkTin_7c+C_x-k8SoYP7U-9zFfhX72apNN1SqX+rpB@mail.gmail.com>
Message-ID: <4D63A51A.5070303@biblibre.com>

Le 22/02/2011 12:46, Chris Nighswonger a ?crit :
> Chris can correct me if I'm wrong....
>
> Once the patch has been pushed to a QA branch it is "Pushed for QA."
>
> If it fails QA it should be "Failed QA."
>
> If it passes it should be "Needs sign off" or "Signed off."
>
> Once pushed to master it is "Patch Pushed."
>
> If at any time it fails a test the status should return to "Failed QA."
That's how I read it too, but when "patch pushed", there's something in
master and something that is wrong. So it should not just be "failed QA"
because in this status a patch can be hidden in a middle of many other
"failed QA" that have no consequences in master.

the more I think of it the more I suspect it would be a good idea to
have a new status.

-- 
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 Feb 22 13:33:00 2011
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Tue, 22 Feb 2011 13:33:00 +0100
Subject: [Koha-devel] Editing the Comments feature on Koha
In-Reply-To: <89A35FEF98F9384BBB1360526A846BC7041D87B7@TEAM-EXCHANGE1.hc.msu.edu>
References: <89A35FEF98F9384BBB1360526A846BC7041D87B7@TEAM-EXCHANGE1.hc.msu.edu>
Message-ID: <AANLkTikQCB26zoeU6cGpCiDO8zveAF8-nVH6GeT4O_ja@mail.gmail.com>

Hie,

In file "opac-details.tmpl", line 692 :
            <h5>
                Comment by
                <!-- TMPL_VAR NAME="title" -->
                <!-- TMPL_VAR NAME="firstname" -->
                <!-- TMPL_VAR NAME="surname" -->
            </h5>

This part shows the name of the user who made the comment.
Just erase what you don't want to see.

Regards,

2011/2/21 Cole Hudson <Cole.Hudson at hc.msu.edu>

> *Note: my apologies to all who have already seen this post on the koha
> general list-serv*
>
>
>
> Hi all,
>
>
>
> I?m running Koha 3.02 on Ubuntu 10.10.  I?m trying to edit the comments
> feature that displays with each record in the opac.  I?d like to edit it
> where the name of the patron is not pulled from each patron record?so as to
> make comments anonymous.  Could someone point me in the right direction here
> on what code to edit/remove?  Thanks.
>
>
>
> Cole Hudson
>
> Library Assistant
>
> MSU College of Osteopathic Medicine
>
> Macomb University Center
>
> _______________________________________________
> 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/20110222/49718ca8/attachment.htm>

From cnighswonger at foundations.edu  Tue Feb 22 13:42:37 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Tue, 22 Feb 2011 07:42:37 -0500
Subject: [Koha-devel] bugzilla workflow, question when "pushed,
	pls test" rejected
In-Reply-To: <4D63A51A.5070303@biblibre.com>
References: <4D639840.4070507@biblibre.com>
	<AANLkTin_7c+C_x-k8SoYP7U-9zFfhX72apNN1SqX+rpB@mail.gmail.com>
	<4D63A51A.5070303@biblibre.com>
Message-ID: <AANLkTikMu6Z+SQg_7hBejDOAdN1JgS5G1HFrJQZngQdy@mail.gmail.com>

 On Tue, Feb 22, 2011 at 6:59 AM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> Le 22/02/2011 12:46, Chris Nighswonger a ?crit :
> > Chris can correct me if I'm wrong....
> >
> > Once the patch has been pushed to a QA branch it is "Pushed for QA."
> >
> > If it fails QA it should be "Failed QA."
> >
> > If it passes it should be "Needs sign off" or "Signed off."
> >
> > Once pushed to master it is "Patch Pushed."
> >
> > If at any time it fails a test the status should return to "Failed QA."
> That's how I read it too, but when "patch pushed", there's something in
> master and something that is wrong. So it should not just be "failed QA"
> because in this status a patch can be hidden in a middle of many other
> "failed QA" that have no consequences in master.
>
> the more I think of it the more I suspect it would be a good idea to
> have a new status.
>
>
I understand what you are thinking now.

I think if we just followed the use of the status and resolution fields (see
http://bugs.koha-community.org/bugzilla3/page.cgi?id=fields.html#status)
then in the case you suggest we would just re-open the bug.

I wonder if we are not creating solutions for a problem which is really due
to a lack of utilizing solutions which already exist?

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

From paul.poulain at biblibre.com  Tue Feb 22 13:58:31 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Tue, 22 Feb 2011 13:58:31 +0100
Subject: [Koha-devel] bugzilla workflow, question when "pushed,
 pls test" rejected
In-Reply-To: <AANLkTikMu6Z+SQg_7hBejDOAdN1JgS5G1HFrJQZngQdy@mail.gmail.com>
References: <4D639840.4070507@biblibre.com>
	<AANLkTin_7c+C_x-k8SoYP7U-9zFfhX72apNN1SqX+rpB@mail.gmail.com>
	<4D63A51A.5070303@biblibre.com>
	<AANLkTikMu6Z+SQg_7hBejDOAdN1JgS5G1HFrJQZngQdy@mail.gmail.com>
Message-ID: <4D63B2F7.8030300@biblibre.com>

Le 22/02/2011 13:42, Chris Nighswonger a ?crit :
> I understand what you are thinking now.
>
> I think if we just followed the use of the status and resolution
> fields (see
> http://bugs.koha-community.org/bugzilla3/page.cgi?id=fields.html#status)
> then in the case you suggest we would just re-open the bug.
>
> I wonder if we are not creating solutions for a problem which is
> really due to a lack of utilizing solutions which already exist?
I don't think so: the status (not patch status) is "assigned, so the bug
is not considered as "resolved".
chris is just waiting for feedback to confirm it can be closed (I'm
doing that on all bugs where biblibre.com is reporter or assigned or cc:
atm, already closed something like 20 !).
Sometimes the bug can't be closed because the applied solution has a
problem (other examples : 3550, 3816, 3924, 4044).
Staying "assigned" and "patch pushed" is incomplete: OK, a patch has
been pushed, but i've detected a problem on it !

let's chris waking up and we will see (he may have more important things
to do those days if he has family or friends on christchurch :\ )

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


From tomascohen at gmail.com  Tue Feb 22 14:22:40 2011
From: tomascohen at gmail.com (Tomas Cohen Arazi)
Date: Tue, 22 Feb 2011 10:22:40 -0300
Subject: [Koha-devel] Bug 5791 - Robust handling of deleted
	biblios/authorities
Message-ID: <AANLkTi=YebXORBJ59FwSvxfF9XgTHGFrd-7D1t7RpfNY@mail.gmail.com>

I've filled a bug for better non existent record handling for biblios
and authorities. I propose to use the same approach used for patrons.
I hope I can submit a patch within a few hours.

For authorities I plan to add to authorities/detail.pl a check like this:

if ( defined $authtypecode ) {
 record show stuff
} else {
 generate proper error message
}

To+

From Cole.Hudson at hc.msu.edu  Tue Feb 22 14:38:04 2011
From: Cole.Hudson at hc.msu.edu (Cole Hudson)
Date: Tue, 22 Feb 2011 08:38:04 -0500
Subject: [Koha-devel] Editing the Comments feature on Koha
In-Reply-To: <AANLkTikQCB26zoeU6cGpCiDO8zveAF8-nVH6GeT4O_ja@mail.gmail.com>
References: <89A35FEF98F9384BBB1360526A846BC7041D87B7@TEAM-EXCHANGE1.hc.msu.edu>
	<AANLkTikQCB26zoeU6cGpCiDO8zveAF8-nVH6GeT4O_ja@mail.gmail.com>
Message-ID: <89A35FEF98F9384BBB1360526A846BC7041D8A4D@TEAM-EXCHANGE1.hc.msu.edu>

Splendid!  Works like a charm!  Thanks so much.

 

Cole

From: Fridolyn SOMERS [mailto:fridolyn.somers at gmail.com] 
Sent: Tuesday, February 22, 2011 7:33 AM
To: Cole Hudson
Cc: koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] Editing the Comments feature on Koha

 

Hie,

In file "opac-details.tmpl", line 692 : 
            <h5>
                Comment by
                <!-- TMPL_VAR NAME="title" -->
                <!-- TMPL_VAR NAME="firstname" -->
                <!-- TMPL_VAR NAME="surname" -->
            </h5>

This part shows the name of the user who made the comment.
Just erase what you don't want to see.

Regards,

2011/2/21 Cole Hudson <Cole.Hudson at hc.msu.edu>

*Note: my apologies to all who have already seen this post on the koha
general list-serv*

 

Hi all,

 

I'm running Koha 3.02 on Ubuntu 10.10.  I'm trying to edit the comments
feature that displays with each record in the opac.  I'd like to edit it
where the name of the patron is not pulled from each patron record-so as
to make comments anonymous.  Could someone point me in the right
direction here on what code to edit/remove?  Thanks.

 

Cole Hudson

Library Assistant

MSU College of Osteopathic Medicine

Macomb University Center


_______________________________________________
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

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

From colin.campbell at ptfs-europe.com  Tue Feb 22 15:04:59 2011
From: colin.campbell at ptfs-europe.com (Colin Campbell)
Date: Tue, 22 Feb 2011 14:04:59 +0000
Subject: [Koha-devel] Bug 5791 - Robust handling of
	deleted	biblios/authorities
In-Reply-To: <AANLkTi=YebXORBJ59FwSvxfF9XgTHGFrd-7D1t7RpfNY@mail.gmail.com>
References: <AANLkTi=YebXORBJ59FwSvxfF9XgTHGFrd-7D1t7RpfNY@mail.gmail.com>
Message-ID: <4D63C28B.8080407@ptfs-europe.com>

On 22/02/11 13:22, Tomas Cohen Arazi wrote:
> I've filled a bug for better non existent record handling for biblios
> and authorities. I propose to use the same approach used for patrons.
> I hope I can submit a patch within a few hours.
> 
> For authorities I plan to add to authorities/detail.pl a check like this:
> 
> if ( defined $authtypecode ) {
>  record show stuff
> } else {
>  generate proper error message
> }

I'm assuming GetAuthority and GetBiblio are returning undef as the
returned $record so you should be able to test if ($record)

Catching these errors will be a major improvement, thanks

Colin

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

http://www.ptfs-europe.com

From semarie-koha at latrappe.fr  Tue Feb 22 17:38:31 2011
From: semarie-koha at latrappe.fr (=?iso-8859-1?Q?Fr=E8re_S=E9bastien?= Marie)
Date: Tue, 22 Feb 2011 17:38:31 +0100
Subject: [Koha-devel] Imported MARC notice and Authorities: :
	inconsistent database
In-Reply-To: <20110215105330.GB20709@latrappe.fr>
References: <alpine.DEB.2.00.1101291154510.12662@feipbzzhanhgr.ybpny.yngenccr.se>
	<20110215105330.GB20709@latrappe.fr>
Message-ID: <20110222163831.GH27171@latrappe.fr>

Hi,

I ask review for my (start of) solution, against inconsitent between authority (auth_header.auth_id) and koha_internal_code (like 700$9).

The restoration of the consistent should be in 2 stages:
 - stop inconsistent growing
 - relinks authorities

This is for the first stage: stop inconsistent growing... (as we continue to catalog using some external marc files)

Currently, 'cataloguing/addbiblio.pl' not check authorities if field like 700$9 exists (see BiblioAddAuthorities function).

If a subfield '3' or '9' exists in field 500, 600,..., 700... there is not search for authority and the function assume the koha_internal_number is right (I think this behaviour is wrong).

So, I want to strip this subfield: if no subfield, BiblioAddAuthorities will search for authority and create it if not found.

Here a piece of code (the most part is taken from 'BiblioAddAuthorities') :

sub BiblioCleanKohaInternalCode {
  my ( $record, $frameworkcode ) = @_;
  my $dbh=C4::Context->dbh;
  my $query=$dbh->prepare(qq|
SELECT authtypecode,tagfield
FROM marc_subfield_structure 
WHERE frameworkcode=? 
AND (authtypecode IS NOT NULL AND authtypecode<>\"\")|);
  $query->execute($frameworkcode ? $frameworkcode : '');
  while (my $data=$query->fetchrow_hashref){
    foreach my $field ($record->field($data->{tagfield})){
      #?clean code 3 and 9 (if exists)
      $field->delete_subfield(code => ['3', '9']);
    }
  }
}

and I call it just after 'MARCfindbreeding', in order to sanitize the record just getted.

It seems to function well: the page show record without xxx$9, and at the creation of the notice, authorities are search, found or created, and linked.

But what do you think: is it safe or not, to strip '3' and '9' code in these fields ?

Thanks.
-- 
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 kmkale at anantcorp.com  Wed Feb 23 04:43:09 2011
From: kmkale at anantcorp.com (Koustubha Kale)
Date: Wed, 23 Feb 2011 09:13:09 +0530
Subject: [Koha-devel] Trial install of "OPEN CONFERENCE SYSTEMS"
Message-ID: <AANLkTin+bsLP4h15t1x2zuDNYxmhxKrGKb5F62dzzMxF@mail.gmail.com>

Hi All,
I have set up a trial install of "OPEN CONFERENCE SYSTEMS" (
http://pkp.sfu.ca/ocs/) at http://kohacon11.vpmthane.org/ocs/

Please have a look and let me have your thoughts on its usefulness for
organizing Kohacon. I can provide "Conference Director" access on request..

Regards,
Koustubha Kale
Anant Corporation

Contact Details :
Address  : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka,
Thane (w),
                Maharashtra, India, Pin : 400601.
TeleFax  : +91-22-21720108, +91-22-21720109
Mobile     : +919820715876
Website  : http://www.anantcorp.com
Blog : http://www.anantcorp.com/blog/?author=2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110223/a742e247/attachment.htm>

From jcamins at cpbibliography.com  Wed Feb 23 20:56:46 2011
From: jcamins at cpbibliography.com (Jared Camins-Esakov)
Date: Wed, 23 Feb 2011 14:56:46 -0500
Subject: [Koha-devel] Subject tracings
Message-ID: <AANLkTim30J3c0ZH4sWLz+KOpmEyRm7wqOZXBJ4J=pu7p@mail.gmail.com>

Hello.

Can anyone think of any reason not to specify that subject tracings should
match only complete subfields? For example, at the moment, if you are
looking at a book about Religions (with a subject term "Religions") in the
catalog of a library that does not use Koha's authority control, when you
click on the subject tracing in the OPAC, you will be given a result set
that contains every single record that has the word "Religions" anywhere in
its subject. Including, for example, books with the subject "Christianity
and other religions."

If we make the query on the subject tracings su,complete-subfield: the only
false positives will be items where the subject heading being searched is
used for both a main entry and a subdivision, which still seems like a
significant improvement over the current behavior. Thoughts?

Regards,
Jared

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

From ian.walls at bywatersolutions.com  Thu Feb 24 04:29:05 2011
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Wed, 23 Feb 2011 22:29:05 -0500
Subject: [Koha-devel] Separating MARC Framework Structure from Display
Message-ID: <AANLkTind2N4dvTPjgXMsod5Vx+CNb7sO2-ACwoQymhm-@mail.gmail.com>

Colleagues and Friends,


I've been doing a training for a library in Maine, and working with their
cataloguers has got me thinking a lot about the MARC Frameworks.

Right now, our Frameworks are doing two jobs:  defining what MARC means, and
determining how that information will display in the editor and MARC views.
 It seems to me that we may benefit from separating these two functions more
thoroughly.  Doing so would allow us to have one or two framework structures
per MARC flavour, but as many displays as we like.  I'm thinking of the
further future of Koha where we support more than just MARC (like native DC,
MOD, METS or EAD data), and having the semantics and display separated is
more critical (so we can provide a common display layer to all those
formats)

To that end, I'd recommend some changes to how the display information is
handled in the GUI.  First off, having 'basic' constraints and 'advanced'
constraints (hidden by JQuery) should be eliminated in favour of a semantic
section and a display section.  Secondly, the 'hidden' value should no
longer be an integer (at least in the GUI), but a dropdown, or series of
dropdowns, laying out in plain text under what conditions you're hiding the
value.

Does this make sense to others, or am I writing too late into the evening?

Cheers,


-Ian

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

From fridolyn.somers at gmail.com  Thu Feb 24 08:30:48 2011
From: fridolyn.somers at gmail.com (Fridolyn SOMERS)
Date: Thu, 24 Feb 2011 08:30:48 +0100
Subject: [Koha-devel] Subject tracings
In-Reply-To: <AANLkTim30J3c0ZH4sWLz+KOpmEyRm7wqOZXBJ4J=pu7p@mail.gmail.com>
References: <AANLkTim30J3c0ZH4sWLz+KOpmEyRm7wqOZXBJ4J=pu7p@mail.gmail.com>
Message-ID: <AANLkTimR2Wp2wHkz-=co95nsRyT3c7S+vihaadcphhCV@mail.gmail.com>

Hie,

I agry.
And add that this should also be in relevance (when weighted query) : exact
match subjects must be above others.

Regards,

2011/2/23 Jared Camins-Esakov <jcamins at cpbibliography.com>

> Hello.
>
> Can anyone think of any reason not to specify that subject tracings should
> match only complete subfields? For example, at the moment, if you are
> looking at a book about Religions (with a subject term "Religions") in the
> catalog of a library that does not use Koha's authority control, when you
> click on the subject tracing in the OPAC, you will be given a result set
> that contains every single record that has the word "Religions" anywhere in
> its subject. Including, for example, books with the subject "Christianity
> and other religions."
>
> If we make the query on the subject tracings su,complete-subfield: the only
> false positives will be items where the subject heading being searched is
> used for both a main entry and a subdivision, which still seems like a
> significant improvement over the current behavior. Thoughts?
>
> Regards,
> Jared
>
> --
> Jared Camins-Esakov
> Freelance bibliographer, C & P Bibliography Services, LLC
> (phone) +1 (917) 727-3445
> (e-mail) jcamins at cpbibliography.com
> (web) http://www.cpbibliography.com/
>
>
> _______________________________________________
> 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/20110224/7be36b46/attachment.htm>

From henridamien.laurent at gmail.com  Thu Feb 24 11:18:05 2011
From: henridamien.laurent at gmail.com (LAURENT Henri-Damien)
Date: Thu, 24 Feb 2011 11:18:05 +0100
Subject: [Koha-devel] Subject tracings
In-Reply-To: <AANLkTim30J3c0ZH4sWLz+KOpmEyRm7wqOZXBJ4J=pu7p@mail.gmail.com>
References: <AANLkTim30J3c0ZH4sWLz+KOpmEyRm7wqOZXBJ4J=pu7p@mail.gmail.com>
Message-ID: <4D66305D.1070404@gmail.com>

Le 23/02/2011 20:56, Jared Camins-Esakov a ?crit :
> Hello.
> 
> Can anyone think of any reason not to specify that subject tracings
> should match only complete subfields?
Hi,
I agree too.
Note that completeness is not always enabled by default on the zebra
configuration.
With our default configuration, it would be available for :p indexes only.
Hope that helps.
-- 
Henri-Damien LAURENT


> For example, at the moment, if you
> are looking at a book about Religions (with a subject term "Religions")
> in the catalog of a library that does not use Koha's authority control,
> when you click on the subject tracing in the OPAC, you will be given a
> result set that contains every single record that has the word
> "Religions" anywhere in its subject. Including, for example, books with
> the subject "Christianity and other religions."
> 
> If we make the query on the subject tracings su,complete-subfield: the
> only false positives will be items where the subject heading being
> searched is used for both a main entry and a subdivision, which still
> seems like a significant improvement over the current behavior. Thoughts?
> 
> Regards,
> Jared
> 
> -- 
> Jared Camins-Esakov
> Freelance bibliographer, C & P Bibliography Services, LLC
> (phone) +1 (917) 727-3445
> (e-mail) jcamins at cpbibliography.com <mailto:jcamins at cpbibliography.com>
> (web) http://www.cpbibliography.com/
> 
> 
> 
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/


From nengard at gmail.com  Thu Feb 24 13:13:21 2011
From: nengard at gmail.com (Nicole Engard)
Date: Thu, 24 Feb 2011 07:13:21 -0500
Subject: [Koha-devel] Separating MARC Framework Structure from Display
In-Reply-To: <AANLkTind2N4dvTPjgXMsod5Vx+CNb7sO2-ACwoQymhm-@mail.gmail.com>
References: <AANLkTind2N4dvTPjgXMsod5Vx+CNb7sO2-ACwoQymhm-@mail.gmail.com>
Message-ID: <AANLkTikh52jL5zGEjxA-q7wnROJbPGunzAEn6L6xq31N@mail.gmail.com>

2011/2/23 Ian Walls <ian.walls at bywatersolutions.com>

>
> To that end, I'd recommend some changes to how the display information is
> handled in the GUI.  First off, having 'basic' constraints and 'advanced'
> constraints (hidden by JQuery) should be eliminated in favour of a semantic
> section and a display section.  Secondly, the 'hidden' value should no
> longer be an integer (at least in the GUI), but a dropdown, or series of
> dropdowns, laying out in plain text under what conditions you're hiding the
> value.
>

I've had this conversation with Ian many times and I usually throw in that
I'd go a step further and say that cataloging shouldn't be dependent on
Frameworks at all!  We should have the option to use a Framework if we want
one, but for us professional catalogers we want freedom to add and remove
fields as we see fit - while cataloging - not before we start cataloging.
I'd like to see a blank cataloging form that I can tab through and add
fields and subfields as needed.  If I'm understanding right, the first step
in this process would be to make the changes Ian is suggesting and then we
can move forward from there.

>
> Does this make sense to others, or am I writing too late into the evening?
>
>

Makes sense to me - but like I said I've heard it all before :)


Thanks
Nicole
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110224/9c8c3c2e/attachment.htm>

From nengard at gmail.com  Thu Feb 24 13:17:52 2011
From: nengard at gmail.com (Nicole Engard)
Date: Thu, 24 Feb 2011 07:17:52 -0500
Subject: [Koha-devel] Subject tracings
In-Reply-To: <AANLkTim30J3c0ZH4sWLz+KOpmEyRm7wqOZXBJ4J=pu7p@mail.gmail.com>
References: <AANLkTim30J3c0ZH4sWLz+KOpmEyRm7wqOZXBJ4J=pu7p@mail.gmail.com>
Message-ID: <AANLkTikwb3FMFnN4zuf0cgKTFhJkHjgP9DSZsTDt+kss@mail.gmail.com>

2011/2/23 Jared Camins-Esakov <jcamins at cpbibliography.com>

> Hello.
>
> Can anyone think of any reason not to specify that subject tracings should
> match only complete subfields? For example, at the moment, if you are
> looking at a book about Religions (with a subject term "Religions") in the
> catalog of a library that does not use Koha's authority control, when you
> click on the subject tracing in the OPAC, you will be given a result set
> that contains every single record that has the word "Religions" anywhere in
> its subject. Including, for example, books with the subject "Christianity
> and other religions."
>

I was doing a training a few months ago and the librarians there loved the
fact that it didn't do an exact match.  The reasoning made sense to me (but
then again I was never a stickler for the rules when I was cataloging).  If
you have a book with about the United States and a book that takes place in
the United States the subject term "United States" will appear in different
spots (with other possible identifiers). The way it searches now allows you
to find all of those subjects.  Other examples include keywords like
'Juvenile' or 'Fiction' (just to name a few).  I like that the search chains
the subjects together as keyword searches (on the subject) because then you
get more than if you were limited only to that exact subject.

Further, if your library isn't using Authorities then it makes perfect sense
that the search be flexible as it is now because there is no telling how two
people cataloged two books on the same topics.

>
> If we make the query on the subject tracings su,complete-subfield: the only
> false positives will be items where the subject heading being searched is
> used for both a main entry and a subdivision, which still seems like a
> significant improvement over the current behavior. Thoughts?
>

This might need to be an authorities system preference that asks outright if
the library uses authority control - and if so then you can make the search
only search the full authority - otherwise I'd say it should stay the way it
is.

Thanks
Nicole
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110224/9435070e/attachment.htm>

From ian.walls at bywatersolutions.com  Thu Feb 24 13:21:56 2011
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Thu, 24 Feb 2011 07:21:56 -0500
Subject: [Koha-devel] Subject tracings
In-Reply-To: <4D66305D.1070404@gmail.com>
References: <AANLkTim30J3c0ZH4sWLz+KOpmEyRm7wqOZXBJ4J=pu7p@mail.gmail.com>
	<4D66305D.1070404@gmail.com>
Message-ID: <AANLkTi=PGGG_DOuTyDA7b+ZBQEkohfo2rAPNJQh-TdMc@mail.gmail.com>

When doing an initial search, I'd recommend we stay with the current set up
(more results is better, as they can be narrowed with the filters), but if
you're clicking the subject tracing on a specific record (or on one of the
filters), yes, I think it should be forced to completeness.  You want
precisely _that thing_.  You're seeking, rather than searching.

We could also apply this to names and series entries in a similar fashion.

My understanding is that this completeness is on a subfield-level only; so
clicking the tracing for "Religion -- Europe" would generate the search
"su,complete-subfield:Religion AND su,complete-subfield:Europe", still
retrieving more records (like those with two headings, "Religion" and
"Christianity -- Europe -- 19th Century")

Is my understanding correct?


-Ian

On Thu, Feb 24, 2011 at 5:18 AM, LAURENT Henri-Damien <
henridamien.laurent at gmail.com> wrote:

> Le 23/02/2011 20:56, Jared Camins-Esakov a ?crit :
> > Hello.
> >
> > Can anyone think of any reason not to specify that subject tracings
> > should match only complete subfields?
> Hi,
> I agree too.
> Note that completeness is not always enabled by default on the zebra
> configuration.
> With our default configuration, it would be available for :p indexes only.
> Hope that helps.
> --
> Henri-Damien LAURENT
>
>
> > For example, at the moment, if you
> > are looking at a book about Religions (with a subject term "Religions")
> > in the catalog of a library that does not use Koha's authority control,
> > when you click on the subject tracing in the OPAC, you will be given a
> > result set that contains every single record that has the word
> > "Religions" anywhere in its subject. Including, for example, books with
> > the subject "Christianity and other religions."
> >
> > If we make the query on the subject tracings su,complete-subfield: the
> > only false positives will be items where the subject heading being
> > searched is used for both a main entry and a subdivision, which still
> > seems like a significant improvement over the current behavior. Thoughts?
> >
> > Regards,
> > Jared
> >
> > --
> > Jared Camins-Esakov
> > Freelance bibliographer, C & P Bibliography Services, LLC
> > (phone) +1 (917) 727-3445
> > (e-mail) jcamins at cpbibliography.com <mailto: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/
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



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

From paul.poulain at biblibre.com  Thu Feb 24 13:39:49 2011
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Thu, 24 Feb 2011 13:39:49 +0100
Subject: [Koha-devel] Subject tracings
In-Reply-To: <AANLkTi=PGGG_DOuTyDA7b+ZBQEkohfo2rAPNJQh-TdMc@mail.gmail.com>
References: <AANLkTim30J3c0ZH4sWLz+KOpmEyRm7wqOZXBJ4J=pu7p@mail.gmail.com>	<4D66305D.1070404@gmail.com>
	<AANLkTi=PGGG_DOuTyDA7b+ZBQEkohfo2rAPNJQh-TdMc@mail.gmail.com>
Message-ID: <4D665195.8010403@biblibre.com>

Le 24/02/2011 13:21, Ian Walls a ?crit :
> When doing an initial search, I'd recommend we stay with the current
> set up (more results is better, as they can be narrowed with the
> filters), but if you're clicking the subject tracing on a specific
> record (or on one of the filters), yes, I think it should be forced to
> completeness.  You want precisely _that thing_.  You're seeking,
> rather than searching.
>
> We could also apply this to names and series entries in a similar fashion.
We have made a development for Nimes public library that is related to
this too.

You can see the result here :
http://cat-bib.nimes.fr/cgi-bin/koha/opac-detail.pl?biblionumber=84738
click on an author or a subject. A popup is spawn, letting the user
specify better how he want to jump.

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


From nengard at gmail.com  Thu Feb 24 13:53:31 2011
From: nengard at gmail.com (Nicole Engard)
Date: Thu, 24 Feb 2011 07:53:31 -0500
Subject: [Koha-devel] Subject tracings
In-Reply-To: <4D665195.8010403@biblibre.com>
References: <AANLkTim30J3c0ZH4sWLz+KOpmEyRm7wqOZXBJ4J=pu7p@mail.gmail.com>
	<4D66305D.1070404@gmail.com>
	<AANLkTi=PGGG_DOuTyDA7b+ZBQEkohfo2rAPNJQh-TdMc@mail.gmail.com>
	<4D665195.8010403@biblibre.com>
Message-ID: <AANLkTi=4WnOm1DYDmCg4mmBtXkmEFNd5-bP0h7cD1wn=@mail.gmail.com>

On Thu, Feb 24, 2011 at 7:39 AM, Paul Poulain <paul.poulain at biblibre.com>wrote:

> We have made a development for Nimes public library that is related to
> this too.
>
> You can see the result here :
> http://cat-bib.nimes.fr/cgi-bin/koha/opac-detail.pl?biblionumber=84738
> click on an author or a subject. A popup is spawn, letting the user
> specify better how he want to jump.
>

While that is cool, I'd argue that it's too complicated for your average
library user.  If we went that way it should be a system preference so that
it's not the only way to do a subject search.


>
> --
> Paul POULAIN
> http://www.biblibre.com
> Expert en Logiciels Libres pour l'info-doc
> Tel : (33) 4 91 81 35 08
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110224/69e9190c/attachment-0001.htm>

From lculber at mdah.state.ms.us  Thu Feb 24 14:35:36 2011
From: lculber at mdah.state.ms.us (Linda Culberson)
Date: Thu, 24 Feb 2011 07:35:36 -0600
Subject: [Koha-devel] Koha Separating MARC Framework Structure from
	Display
In-Reply-To: <AANLkTikh52jL5zGEjxA-q7wnROJbPGunzAEn6L6xq31N@mail.gmail.com>
References: <AANLkTind2N4dvTPjgXMsod5Vx+CNb7sO2-ACwoQymhm-@mail.gmail.com>
	<AANLkTikh52jL5zGEjxA-q7wnROJbPGunzAEn6L6xq31N@mail.gmail.com>
Message-ID: <4D665EA8.2090203@mdah.state.ms.us>

I very much agree with Nicole on this one. One of my problems with the 
frameworks in our institutions is that while it is true that visual 
materials, books, serials, and manuscripts can use different frameworks, 
it would be very helpful to be able to add/remove fields and subfields 
as needed while cataloging.

On 2/24/2011 6:13 AM, Nicole Engard wrote:
>
> 2011/2/23 Ian Walls <ian.walls at bywatersolutions.com
> <mailto:ian.walls at bywatersolutions.com>>
>
>
>     To that end, I'd recommend some changes to how the display
>     information is handled in the GUI. ? First off, having 'basic'
>     constraints and 'advanced' constraints (hidden by JQuery) should be
>     eliminated in favour of a semantic section and a display section.
>     ? Secondly, the 'hidden' value should no longer be an integer (at
>     least in the GUI), but a dropdown, or series of dropdowns, laying
>     out in plain text under what conditions you're hiding the value.
>
>
> I've had this conversation with Ian many times and I usually throw in
> that I'd go a step further and say that cataloging shouldn't be
> dependent on Frameworks at all!?  We should have the option to use a
> Framework if we want one, but for us professional catalogers we want
> freedom to add and remove fields as we see fit - while cataloging - not
> before we start cataloging.?  I'd like to see a blank cataloging form
> that I can tab through and add fields and subfields as needed.?  If I'm
> understanding right, the first step in this process would be to make the
> changes Ian is suggesting and then we can move forward from there.
>
>
>     Does this make sense to others, or am I writing too late into the
>     evening? ?
>
>
> Makes sense to me - but like I said I've heard it all before :)
>
>
> Thanks
> Nicole
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/

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



From lculber at mdah.state.ms.us  Thu Feb 24 14:45:50 2011
From: lculber at mdah.state.ms.us (Linda Culberson)
Date: Thu, 24 Feb 2011 07:45:50 -0600
Subject: [Koha-devel] Subject tracings
In-Reply-To: <4D665195.8010403@biblibre.com>
References: <AANLkTim30J3c0ZH4sWLz+KOpmEyRm7wqOZXBJ4J=pu7p@mail.gmail.com>	<4D66305D.1070404@gmail.com>	<AANLkTi=PGGG_DOuTyDA7b+ZBQEkohfo2rAPNJQh-TdMc@mail.gmail.com>
	<4D665195.8010403@biblibre.com>
Message-ID: <4D66610E.2060003@mdah.state.ms.us>

I like this development by BibLibre very much.  We have a variety of 
patrons.  Some are very serious researchers who know exactly what they 
want and don't appreciate the vagueness of the fuzzy-type searches.  On 
the other hand, we have some people who are new to researching, aren't 
quite sure what they want, and they do want (or think they want) 
*everything* we have on "civil rights" or "Vicksburg"  even if such a 
search gives a mind-numbing number of results. I think the "drill down" 
filters would be very helpful.

On 2/24/2011 6:39 AM, Paul Poulain wrote:
> Le 24/02/2011 13:21, Ian Walls a ??crit :
>> When doing an initial search, I'd recommend we stay with the current
>> set up (more results is better, as they can be narrowed with the
>> filters), but if you're clicking the subject tracing on a specific
>> record (or on one of the filters), yes, I think it should be forced to
>> completeness.  You want precisely _that thing_.  You're seeking,
>> rather than searching.
>>
>> We could also apply this to names and series entries in a similar fashion.
> We have made a development for Nimes public library that is related to
> this too.
>
> You can see the result here :
> http://cat-bib.nimes.fr/cgi-bin/koha/opac-detail.pl?biblionumber=84738
> click on an author or a subject. A popup is spawn, letting the user
> specify better how he want to jump.
>

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



From bargioni at pusc.it  Thu Feb 24 14:59:11 2011
From: bargioni at pusc.it (Stefano Bargioni)
Date: Thu, 24 Feb 2011 14:59:11 +0100
Subject: [Koha-devel] Separating MARC Framework Structure from 	Display
In-Reply-To: <mailman.1853.1298552033.21663.koha-devel@lists.koha-community.org>
References: <mailman.1853.1298552033.21663.koha-devel@lists.koha-community.org>
Message-ID: <B0CF5F83-A26B-4323-8EA9-DF2E3EE5BE7B@pusc.it>

In my opinion, Koha has a very good UI for cataloguing.
However, this proposal is interesting because -if I'm not wrong- framework personalization could be up to the cataloguer level.
This will allow to rise productivity of cataloguers who know MARC rules very well.
Stefano

From ian.walls at bywatersolutions.com  Thu Feb 24 16:55:30 2011
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Thu, 24 Feb 2011 10:55:30 -0500
Subject: [Koha-devel] Separating MARC Framework Structure from Display
In-Reply-To: <B0CF5F83-A26B-4323-8EA9-DF2E3EE5BE7B@pusc.it>
References: <mailman.1853.1298552033.21663.koha-devel@lists.koha-community.org>
	<B0CF5F83-A26B-4323-8EA9-DF2E3EE5BE7B@pusc.it>
Message-ID: <AANLkTimj-XJ=O_j3KKbOcdzBBWCyRFkeQPzTiqWe9utX@mail.gmail.com>

Right.  This would let us keep the same underlying MARC structure for all
the records coming in, but put different interfaces on it for different
cataloguers.  The advanced, well-trained cataloguer could see the full MARC
specification, while a librarian or volunteer without cataloging training
could see a simplified screen for entering the kinds of items they're
responsible for.


-Ian

On Thu, Feb 24, 2011 at 8:59 AM, Stefano Bargioni <bargioni at pusc.it> wrote:

> In my opinion, Koha has a very good UI for cataloguing.
> However, this proposal is interesting because -if I'm not wrong- framework
> personalization could be up to the cataloguer level.
> This will allow to rise productivity of cataloguers who know MARC rules
> very well.
> Stefano
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



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

From henridamien.laurent at biblibre.com  Thu Feb 24 19:07:26 2011
From: henridamien.laurent at biblibre.com (LAURENT Henri-Damien)
Date: Thu, 24 Feb 2011 19:07:26 +0100
Subject: [Koha-devel] Script to remove authorities
Message-ID: <4D669E5E.6050803@biblibre.com>

Hi
you will find here a command line script which allows deduping
authorities based on the parameters passed.
You can test and tell me what you think of that.
I also fixed the merge script in C4::AuthoritiesMarc.pm
http://git.biblibre.com/?p=koha;a=blob;f=C4/AuthoritiesMarc.pm;h=af99fa632ee886a636a83feea6f737f2069bf448;hb=refs/heads/master
I think it is quite handy at the moment.
It requires though that your authorities index are declared with
completeness and p and you can declare on which index and which data you
want to deduplicate

$0 --match index/123sub##index2/123a####index2/001 AUTHTYPECODE1
AUTHTYPECODE2
Hope that helps.
-- 
Henri-Damien LAURENT

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dedduping_authorities.pl
Type: application/x-perl
Size: 8457 bytes
Desc: not available
URL: </pipermail/koha-devel/attachments/20110224/36fc76da/attachment.bin>

From cnighswonger at foundations.edu  Thu Feb 24 22:22:43 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Thu, 24 Feb 2011 16:22:43 -0500
Subject: [Koha-devel] Koha 3.2.5 is now available
Message-ID: <AANLkTim68LGOdAYfmY+9v2TeR-exRoSu8anbz+0q_kEA@mail.gmail.com>

Please note: This release is a security release. It is strongly recommended
that users apply this upgrade immediately to production systems. If you are
installing a new system, please use this version rather than earlier
versions.
 It is with pleasure that I announce the release of Koha 3.2.5.

The package can be retrieved from:

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

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

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

Release notes for 3.2.5 are below.

Come and get it!


RELEASE NOTES FOR KOHA 3.2.5 - 24 February 2011
========================================================================

Koha is the first free and open source software library automation package
(ILS). Development is sponsored by libraries of varying types and sizes,

volunteers, and support companies from around the world.
The website for the Koha project is

    http://koha-community.org/

Koha 3.2.5 can be downloaded from:


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

Installation instructions can be found at:

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

Highlights of 3.2.5
======================

NOTE: This release is a security release. It is strongly recommended
that users apply
this upgrade immediately to production systems. If you are installing
a new system, please

use this version rather than earlier versions.

Bugs fixed in 3.2.5
======================

1953    remove possible SQL injection attacks
2742    Wrong language name in the preferences
5745    overdues with fines not showing titles

5759    When printing a borrowers information the secondary email
address is not printed
5769    notice tab disappearing on edit patron

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

    Changes since 3.0:

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

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

The structure of the acquisitions tables have changed significantly
from 3.0.x.  In particular, the budget hierarchy is quite different.
During an upgrade, a new database table is created called fundmapping

that contains a record of how budgets were mapped.  It is strongly
recommended that users of Koha 3.0.x acquisitions carefully review
the results of the upgrade before resuming ordering in Koha 3.2.x.

Documentation

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

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

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

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

English: http://koha-community.org/documentation/3-2-manual/

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

The Git repository for the Koha manual can be found at

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

Translations

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

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

  * Chinese
  * Danish
  * English (New Zealand)

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

Partial translations are available for various other languages.

The Koha team welcomes additional translations; please see

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

for information about translating Koha, and join the koha-translate

list to volunteer:

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

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

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

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

The release team for Koha 3.2 is

Release Manager:        Galen Charlton <gmcharlt at gmail.com>

Documentation Manager:  Nicole Engard <nengard at gmail.com>
Translation Manager:    Chris Cormack <chris at bigallofwax.co.nz>

Release Maintainer (3.0.x):
                        Henri-Damien Laurent <henridamien.laurent at biblibre.com>
Release Maintainer (3.2.x):
                        Chris Nighswonger <cnighswonger at foundations.edu>

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

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

Owen Leonard
Chris Nighswonger
marcel at libdevelop.rijksmuseum.nl

Paul Poulain


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

The 3.2.x Release Maintainer especially thanks the 3.4 Release Team and all
who participated in QA for their diligent labors in testing and pushing well
over 330 patches since the 3.2.0 relese. Their continued work very much makes

possible the release of 3.2.5 on its announced schedule.

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

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

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

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

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

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

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

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

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

From robin at catalyst.net.nz  Fri Feb 25 00:19:23 2011
From: robin at catalyst.net.nz (Robin Sheat)
Date: Fri, 25 Feb 2011 12:19:23 +1300
Subject: [Koha-devel] [Koha] Koha 3.2.5 is now available
In-Reply-To: <AANLkTim68LGOdAYfmY+9v2TeR-exRoSu8anbz+0q_kEA@mail.gmail.com>
References: <AANLkTim68LGOdAYfmY+9v2TeR-exRoSu8anbz+0q_kEA@mail.gmail.com>
Message-ID: <1298589563.2664.47.camel@zarathud>

Chris Nighswonger schreef op do 24-02-2011 om 16:22 [-0500]:
> Please note: This release is a security release. It is strongly
> recommended
> that users apply this upgrade immediately to production systems. If
> you are
> installing a new system, please use this version rather than earlier
> versions.

The stable packages have been updated to this just now, I'm about to
make some new squeeze-dev ones too.

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

From ian.walls at bywatersolutions.com  Fri Feb 25 00:31:28 2011
From: ian.walls at bywatersolutions.com (Ian Walls)
Date: Thu, 24 Feb 2011 18:31:28 -0500
Subject: [Koha-devel] Script to remove authorities
In-Reply-To: <4D669E5E.6050803@biblibre.com>
References: <4D669E5E.6050803@biblibre.com>
Message-ID: <AANLkTi=CG772UjVyiyAF=HWNdwfhF1vD7y_3KgfrMLrT@mail.gmail.com>

Sounds great, looking forward to testing it out.  Will let you know what I
find.


-Ian

2011/2/24 LAURENT Henri-Damien <henridamien.laurent at biblibre.com>

> Hi
> you will find here a command line script which allows deduping
> authorities based on the parameters passed.
> You can test and tell me what you think of that.
> I also fixed the merge script in C4::AuthoritiesMarc.pm
>
> http://git.biblibre.com/?p=koha;a=blob;f=C4/AuthoritiesMarc.pm;h=af99fa632ee886a636a83feea6f737f2069bf448;hb=refs/heads/master
> I think it is quite handy at the moment.
> It requires though that your authorities index are declared with
> completeness and p and you can declare on which index and which data you
> want to deduplicate
>
> $0 --match index/123sub##index2/123a####index2/001 AUTHTYPECODE1
> AUTHTYPECODE2
> Hope that helps.
> --
> Henri-Damien LAURENT
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>



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

From magnus at enger.priv.no  Fri Feb 25 09:05:54 2011
From: magnus at enger.priv.no (Magnus Enger)
Date: Fri, 25 Feb 2011 09:05:54 +0100
Subject: [Koha-devel] [Koha] Koha 3.2.5 is now available
In-Reply-To: <AANLkTi=36s3LF=tmHe-rxzmUXU-Veqr5uNdoaWikf=zG@mail.gmail.com>
References: <AANLkTim68LGOdAYfmY+9v2TeR-exRoSu8anbz+0q_kEA@mail.gmail.com>
	<1298589563.2664.47.camel@zarathud>
	<AANLkTinfmgGWHtkh3XQOex_1Rdf6nEe+GPx-xk_H2EMk@mail.gmail.com>
	<AANLkTi=36s3LF=tmHe-rxzmUXU-Veqr5uNdoaWikf=zG@mail.gmail.com>
Message-ID: <AANLkTimwa=jnESDHE90ruTrdA1kHPz6jKpe6oJKw1B4e@mail.gmail.com>

On 25 February 2011 09:00,  <hansbkk at gmail.com> wrote:

>> Is it safe to just update from 3.2.3 with an existing database?
>>
>> If so, is that generally safe with point releases at that third level
>> (3.2.6 through 2.2.9 but perhaps not 3.3?)
>>
>> Does everything just automagically work while the system is in use, or
>> does Apache or something need to be restarted, or is there an
>> upgrade-data script that needs to be run?

> Sorry I didn't specifically state my questions are regarding updating
> automatically via the Debian package management system, not the
> traditional, more manual methods, whatever those might be. . .

That would be this, from INSTALL.debian
(http://git.koha-community.org/gitweb/?p=koha.git;a=blob_plain;f=INSTALL.debian;hb=HEAD):

UPGRADE
=======
If you are upgrading from a previous installation of Koha 3, you can
use the following:

 ./koha_perl_deps.pl -u -m # to identify new Perl dependencies
 perl Makefile.PL --prev-install-log /path/to/koha-install-log
 make
 make test
 sudo make upgrade

After you have done that you should immediately go to your Intranet
and if there are required changes to the database you will be prompted
to login and and the web installer will do the updates for you. The
OPAC will display a "this system is under maintenance" type message
until you have done that.

I imagine that last bit would work much the same way with the
packages, although I haven't had much time to play with them yet...

Best regards,
Magnus Enger
libriotech.no

From nengard at gmail.com  Fri Feb 25 13:12:27 2011
From: nengard at gmail.com (Nicole Engard)
Date: Fri, 25 Feb 2011 07:12:27 -0500
Subject: [Koha-devel] Official Koha Newsletter: Volume 2,
	Issue 2: February 2011
Message-ID: <AANLkTinLnk-=O9OjOTNy8xYnAyP9DFBUb8JM9789yyM4@mail.gmail.com>

Please read the newsletter online for live links:
http://koha-community.org/koha-newsletter-volume-2issue-2-february-2011/

Official Koha Newsletter (ISSN 2153-8328)
Volume 2, Issue 2: February 2011

Table of Contents

    * Koha Developments
          o Koha 3.2.5 Available
          o RFC Roundup: System Administration
    * Koha in Libraries
          o South Taranaki District Libraries move to Koha
          o Koha Article: OSS in Italy
          o Koha in Mongolia
          o Koha in the Maldives
    * Koha Events
          o KohaCon 2011 in India


Koha Developments

Koha 3.2.5 Available
by Chris Nighswonger

Please note: This release is a security release. It is strongly
recommended that users apply this upgrade immediately to production
systems. If you are installing a new system, please use this version
rather than earlier versions.

The package can be retrieved from:

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

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

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

Release notes for 3.2.5 can be found here.

RFC Roundup: System Administration
by MJ Ray

This month, I?m looking at some Requests For Comments pages about
Systems Administration improvement ideas. If you?ve any comments on
any of these, please visit the wiki and just edit the pages to add
your ideas or comment on the suggestions that are already there.
Alternatively, you could start a discussion on the email list or web
forum at http://koha-community.org/support/.

    * Enhance renewals parameters
          o This page says the suggestion is aimed at Koha 3.4, so
time is running out for it. It?s currently the really short idea that
?Renewable
            ? should be part of smart-rules.pl and take more
parameters into account: ability to renew X time for patron Category
Y, for item type Z in Branch A?. Could you tidy this idea up, link it
to a bug and get it ready for development? If so, please visit the
wiki and help Koha develop.
    * Managing permissions on acquisition module
          o This is a more complete request, suggesting we follow a
similar model for the acquisitions module as for the tools module,
with much more granular permissions. It suggests splitting acquisition
permissions into nine smaller permissions which would allow different
users to be authorised to do different parts of the process. If you?d
like to see the suggested split and maybe suggest groupings or others,
go to visit the wiki.
    * Improving statistics on acquisitions RFC
          o Well, the other side of monitoring acquisitions is to
collect statistics for reporting afterwards. This RFC was aimed at
Koha 3.2, so either it needs marking as completed, or it needs
updating for 3.4 or 3.6.
    * Support for Syndetics enhanced content RFC
          o I think this might already be in Koha 3.2 ? at least my
Koha site has a Syndetics section in the Enhanced Content system
preferences page. If you use Syndetics with Koha, could you update
this page to say that it is completed and working, please?
    * Translation Process: Installer and Javascript libraries improvements
          o This RFC needs some work to make it clearer what users
want from the developers when it comes to installing other languages,
and
            probably linking to an enhancement bug.
    * Guided reports serials RFC
          o A plan to expand the guided reports concept to the serials
table, sponsored by St Etienne University and developed by BibLibre,
expected for/deadline: 2011-05-01 ? I think that will make it just
miss Koha 3.4?s release, so there should still be time to comment on
the wiki.

Please Contribute!

Please, if you have any feedback or encouragement for any of the
above, follow the link and add comments, or start a discussion. It
really does make a difference, helping Koha to develop in the best way
possible, in collaboration between users and developers.


Koha Libraries

South Taranaki District Libraries move to Koha
by Susan McMillan

The South Taranaki District Council (STDC) Libraries are pleased to
announce that they are changing to Koha in March.

While initially skeptical that a ?free? system could provide for the
needs of a modern public library (in South Taranaki?s case made up of
seven branches), staff were pleasantly surprised with the features
that Koha offers straight out of the box.

After Council?s IT Manager, Pete Sayers and Customer Services
Librarian, Cath Sheard, attended Koha10 conference last year the IT
department decided to trial Koha. Soon Cath and I were getting emails
and excited phone calls from IT telling us how they had set up a
borrower, added a book (their cataloguing was abysmal!) and issued
items to themselves ? all with no training or library knowledge
what-so-ever.

Cath and I soon had some MARC records imported, set up lending rules,
Google book covers, carousels and personalised the OPAC. What we found
tricky was the change in terminology between our current management
system and that used in Koha.

We are looking forward to going live with Koha after Taranaki
Anniversary weekend on 14 March.

Koha Article: OSS in Italy
by Zeno Tajoli

Abstract: Koha is an open-source Integrated Library System (ILS)
developed in New Zealand and deployed for the first time in January of
2000 for Horowhenua Library Trust. Koha is a full-fledged software
with basic and advanced features. Koha has also a strong and wide
community of librarians and developers. In particular, it is suitable
to all institutions who want to automate their libraries using a
system that allows a complete control over data and over software
itself. CILEA worked to adapt Koha to Italian libraries and now it is
a part of the community.

    * The official link: http://dx.doi.org/10.1108/10650751111106555
    * The post-print link: http://eprints.rclis.org/handle/10760/15340

Koha in Mongolia
by J. Begzsuren

Central Public Library of Ulaanbaatar in Mongolia has been working to
implement Koha in our library since August, 2010. As of now we have
successfully tested the conversion of our Softlink Alice ?ansi?
database into a Koha ?unicode? database. Our partners are KOICA,
volunteer He Shin Young, librarian and Mongolian Libraries Consortium
Gantulga, IT specialist.

This is the first library in Mongolia to implement Koha to a public
library and the first known ansi database conversion. We are still
working on conversion but our system will be live soon at
http://koha.pl.ub.gov.mn.

Koha in the Maldives
by Aminath Riyaz

Koha is making waves in the Maldives library sector. A few personnel
from the Maldives library and information sector have been exposed to
Koha briefly during the last few years, at the short term training
programs hosted by the SAARC Documentation Center, New Delhi, India.
Koha made a loud enough impact in the Maldives with the formation of
DLNetSA (Digital Library Network of South Asia) in July 2010. This was
followed by a ?training of trainers? workshop on Koha held in Male?,
Maldives, organized by the Maldives Greenstone support Network and
facilitated by resource persons from HealthNet Nepal. A trial database
was hosted by HealthNet Nepal at http://115.187.27.13.

With online support of HealthNet Nepal, Maldives Library Association
(MLA) is introducing Koha to the libraries in the Maldives. As a first
step, the MLA will be setting up Koha in four libraries selected
strategically from different parts of the island nation. More
information about this pilot project is available at
http://infomalias.wordpress.com/2011/01/29/computerise-your-library.
The interest shown by the library sector is overwhelming. This is not
unexpected, as there are only a few libraries in the country with even
an online library catalogue. The only library known to be using an
integrated library system at present is the Maldives National
University Library.

The MLA is very enthusiastic about this endeavor and is very thankful
for the support from HealthNet Nepal, University of Waikato, and the
Maldives Greenstone support Network. This project is a huge step for
MLA given the small group of Library and Information Science
professionals in the country.


Koha Events

KohaCon 2011 in India
by Nicole C. Engard

The KohaCon 2011 Location Survey is closed. We had a total of 877
responses. If you voted for a location as your first choice it got 4
points, your second choice 3 points, and so on. Below is the break
down in points.

    * Thane, India [ End October - Beginning November ] 2640+150+62+33= 2885
    * Kathmandu, Nepal [ November / December 2011 ] 432+96+186+24= 738
    * Kolkata, India [ November / December 2011 ] 156+339+104+33= 632
    * Somerset or Bristol, UK [ September / October 2011 ] 160+141+72+108 = 481

A break down of results can be found here and raw results available
upon request.

Even if we ignore votes from those who didn?t fill in all the
information I?m pretty sure we have a winner.

In addition, I recommend that we soon move on to voting for the
location for 2012 so that we can get on top of things and conference
planners have more time to prepare.





Newsletter edited by Nicole C. Engard, Koha Documentation Manager.
Please send future story ideas to me.

From cnighswonger at foundations.edu  Fri Feb 25 20:31:38 2011
From: cnighswonger at foundations.edu (Chris Nighswonger)
Date: Fri, 25 Feb 2011 14:31:38 -0500
Subject: [Koha-devel] [Koha] Koha 3.2.5 is now available
In-Reply-To: <AANLkTimSW8C7ci46PHbmygtvNa61Z8AFxAPUS69fGGd0@mail.gmail.com>
References: <AANLkTim68LGOdAYfmY+9v2TeR-exRoSu8anbz+0q_kEA@mail.gmail.com>
	<1298589563.2664.47.camel@zarathud>
	<AANLkTinfmgGWHtkh3XQOex_1Rdf6nEe+GPx-xk_H2EMk@mail.gmail.com>
	<AANLkTi=36s3LF=tmHe-rxzmUXU-Veqr5uNdoaWikf=zG@mail.gmail.com>
	<AANLkTimwa=jnESDHE90ruTrdA1kHPz6jKpe6oJKw1B4e@mail.gmail.com>
	<AANLkTimSW8C7ci46PHbmygtvNa61Z8AFxAPUS69fGGd0@mail.gmail.com>
Message-ID: <AANLkTi=_J7iTVFwfCr0WjagD-ZrWQLOjZDDjepqOW=Fk@mail.gmail.com>

 On Fri, Feb 25, 2011 at 3:42 AM, <hansbkk at gmail.com> wrote:

> On Fri, Feb 25, 2011 at 3:05 PM, Magnus Enger <magnus at enger.priv.no>
> wrote:
> >>> Is it safe to just update from 3.2.3 with an existing database?
> >>>
> >>> If so, is that generally safe with point releases at that third level
> >>> (3.2.6 through 2.2.9 but perhaps not 3.3?)
> >>>
> >>> Does everything just automagically work while the system is in use, or
> >>> does Apache or something need to be restarted, or is there an
> >>> upgrade-data script that needs to be run?
> >
> >> Sorry I didn't specifically state my questions are regarding updating
> >> automatically via the Debian package management system, not the
> >> traditional, more manual methods, whatever those might be. . .
> >
> > That would be this, from INSTALL.debian
> > (
> http://git.koha-community.org/gitweb/?p=koha.git;a=blob_plain;f=INSTALL.debian;hb=HEAD
> ):
>
> Thanks much for replying Magnus. The link above returns "no such
> project" for me, perhaps a permissions issue?
>

Works fine from my neck of the woods.

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

From kohadevel at agogme.com  Sun Feb 27 12:37:45 2011
From: kohadevel at agogme.com (Thomas Dukleth)
Date: Sun, 27 Feb 2011 11:37:45 -0000 (UCT)
Subject: [Koha-devel] Script to remove authorities
In-Reply-To: <4D669E5E.6050803@biblibre.com>
References: <4D669E5E.6050803@biblibre.com>
Message-ID: <b1d73fbedfd3639e4b7ac506a54bba86.squirrel@wmail.agogme.com>

Reply inline:


On Thu, February 24, 2011 18:07, LAURENT Henri-Damien wrote:
> Hi
> you will find here a command line script which allows deduping
> authorities based on the parameters passed.
> You can test and tell me what you think of that.
> I also fixed the merge script in C4::AuthoritiesMarc.pm
> http://git.biblibre.com/?p=koha;a=blob;f=C4/AuthoritiesMarc.pm;h=af99fa632ee886a636a83feea6f737f2069bf448;hb=refs/heads/master

The link does not seem to point to a command line script.

> I think it is quite handy at the moment.
> It requires though that your authorities index are declared with
> completeness and p and you can declare on which index and which data you
> want to deduplicate
>
> $0 --match index/123sub##index2/123a####index2/001 AUTHTYPECODE1
> AUTHTYPECODE2
> Hope that helps.

[...]


Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY  10003
USA
http://www.agogme.com
+1 212-674-3783



From kohadevel at agogme.com  Mon Feb 28 06:40:40 2011
From: kohadevel at agogme.com (Thomas Dukleth)
Date: Mon, 28 Feb 2011 05:40:40 -0000 (UCT)
Subject: [Koha-devel] Script to remove authorities
In-Reply-To: <4D6AB815.6080502@biblibre.com>
References: <4D669E5E.6050803@biblibre.com>
	<b1d73fbedfd3639e4b7ac506a54bba86.squirrel@wmail.agogme.com>
	<4D6AB815.6080502@biblibre.com>
Message-ID: <1bc3af80ced1be5cc5bdecb62d7ee4b3.squirrel@wmail.agogme.com>

Sorry, I had not noticed that Henri-Damien Laurent had sent the the
authorities deduplication script as an attachment.

I have become unaccustomed to looking for attachments to email messages on
mailing lists.


Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY  10003
USA
http://www.agogme.com
+1 212-674-3783



From chris at bigballofwax.co.nz  Mon Feb 28 18:10:11 2011
From: chris at bigballofwax.co.nz (Chris Cormack)
Date: Tue, 1 Mar 2011 06:10:11 +1300
Subject: [Koha-devel] Jenkins (formerly known as hudson,
	until Oracle lost their minds) hosting
Message-ID: <AANLkTimBFw4EY13EhTW=Av1ntNb9WCVTswtSqCaJ3Uiq@mail.gmail.com>

Hi All

As you are probably all aware I have been running a hudson (now
jenkins) instance on my linode server. It has been invaluable for
catching errors and for helping to drive us towards better testing.

The problem I now have is that my linode instance is RAM starved with
both bugzilla and jenkins on it. So I am looking for volunteers to
offer a machine to host jenkins on. Ideally debian (running squeeze)
as the packages for jenkins work really well.

I would need a login so I could set up and configure jenkins, and get
it running all the tests again, but then id be happy to have sudo
access revoked and let someone else maintain it. Jenkins is a pile of
java, so it is RAM hungry.

Conversely I could leave it running on my linode, but others could
chip in to help afford the upgrade to the next level to get more ram
available.

Or any other suggestions?

Chris

PS the Jenkins story is an interesting one, and one worth reading
about, a lot of how not to interact with a free software community
lessons to be learnt there.