July 2002 - Koha-devel - lists.koha-community.org

[Bug 61] New: bug in installer.pl ($httpduser variable used before initialized)
by bugzilla-daemon＠wilbur.katipo.co.nz 04 Jul '02

04 Jul '02

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=61 Summary: bug in installer.pl ($httpduser variable used before initialized) Product: Koha Version: 1.2.0 Platform: PC Status: NEW Severity: normal Priority: P2 Component: Installation AssignedTo: tonnesen(a)cmsd.bc.ca ReportedBy: tonnesen(a)cmsd.bc.ca QAContact: koha-devel(a)lists.sourceforge.net installer.pl tries to set httpduser=$httpduser in /etc/koha.conf before the variable has been set. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 60] invoice
by bugzilla-daemon＠wilbur.katipo.co.nz 04 Jul '02

04 Jul '02

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=60 tonnesen(a)cmsd.bc.ca changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED OS/Version| |All ------- Additional Comments From tonnesen(a)cmsd.bc.ca 2002-07-05 03:53 ------- I added this field into updatedatabase in rel-1-2, along with one other field (nocalc). I then ran into some other bugs and decided to leave full acquisitions well enough alone. I think it has some significant problems that need to be fixed, and that's why I set simple acquisitions as the default in the installer. I'll add the invoicedisc and nocalc fields in trunk updatedatabase. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 60] New: invoice
by bugzilla-daemon＠wilbur.katipo.co.nz 04 Jul '02

04 Jul '02

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=60 Summary: invoice Product: Koha Version: 1.2.0 Platform: PC Status: NEW Severity: major Priority: P2 Component: Acquisitions AssignedTo: chris(a)katipo.co.nz ReportedBy: paul.poulain(a)free.fr QAContact: koha-devel(a)lists.sourceforge.net My 1st bugzilla reporting ;-) The modif of a supplier doesn't work : in acquisition.pm, line 599, the update refers to a invoicedisc column that does not exist in supplier table (at least in database.mysql) the same appears in main branch, so i'll be interested by the solution (remove of the invoicedisc reference probably) That was my 1st bugzilla ;-) ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

about package scope...
by paul POULAIN 04 Jul '02

04 Jul '02

I've just spend almost 1 hour to understand a bug... He's due to the redundance of _itemcount_ sub : it exists in Search.pm AND in Catalogue.pm (aka Acquisition.pm for MARC). In newbasket2.pl, in 1.2 branch it uses the Search.pm one, and that's what wanted. In newbasket2.pl, in main branch, it uses the Catalogue.pm one, and THAT'S not the right one... It can be fixed by C4::Search::itemcount innstead of itemcount. My question is : * why does it use Search in 1.2 and Catalogue in main ? you must know that the use at the beginning of the script is the same, so it's not a declaration order problem. * is it good to have the same function name in 2 packages ? I know the answer : no ! can someone propose a new name for one of those itemcounts ? (katipo/chris maybe ?) Next mail in a few minuts for sure ;-) (as kiwis are sleeping and USA are in holiday, i can send as many mails as i want, without being disturbed by an answer ;-))) ) -- Paul

2 1

merging 1.2 and main branches...
by paul POULAIN 04 Jul '02

04 Jul '02

IT'S DONE !!!! Except for a few scripts, which needs to be rewritten in the future, or don't need to be merged, everything is done... It was trully a NIGHTMARE ;-) (and i'm not sure i made no mistakes ;-\\\\ ) I remind everybody the rules : * rel-1-2 is done only for BUGFIXES. If you make a bugfix, check it in the main trunk too please. * If you plan to implement a new feature, do it in the MAIN trunk. If we decide to provide the functionnality in a 1.2.x release, we will merge from the trunk to rel-1-2. PLEEAAASSSEEEE Use those rules. The 1st who don't will be nominated as merging-programmer for the next big merge !!!! Thanks for your attention. Let's go to MARC stuff now for me ;-) -- Paul

1 0

RE: Hello
by Nicholas Rosasco 03 Jul '02

03 Jul '02

Koha is designed to support multiple branches (for example, the original implementation was for a library with 3 different sites). So your union catalog problem is covered, I think. Koha is normally run on a dedicated server (most of us use what is in practice a high performance PC) connected to the internet and the catalog information is delivered via the web (in other words, whatever your schools use for book check out will need a network connection, as will whatever is used to view the catalog). Forgive me for the bullet points... What kind of technology do you currently have? [Koha is normally configured and run on a Unix/Linux machine, but the catalog and circulation system can be used with anything with a web browser.] What kind of support (staff? contractor?) do you have? [Koha is intended to be pretty easy to handle, but installation at the moment is a little complicated at the moment.] What kind of budget do you have for this project? [Koha is free, I'm free, but Murphy's law :)] Are there are sort of standards (cataloging, circulation) you must abide by [you may need to check with your librarians on that]? What sort of record exporting does your catalog support? [If we're lucky, you may be able to feed all the book records directly from one to the other...] > -----Original Message----- > From: Karen Littlefield [mailto:klittle@mid-del.k12.ok.us] > Sent: Monday, July 01, 2002 9:01 AM > To: nsr(a)etome.net > Subject: Re: Hello > > > ** Reply Requested When Convenient ** > > > > Reply requested when convenient > > So Nick where do we begin? What do you need to know from me? I > am just trying to find a way to economically join our separate > catalogs together to be viewed as one. Can the Koha Library > Project help us? > > > Karen Littlefield > klittle(a)mid-del.k12.ok.us > Mid Del Schools > Midwest City, OK 73110 > 405-737-4461 x294 >

2 2

RE: RE: RE: RE: Hello
by Nicholas Rosasco 03 Jul '02

03 Jul '02

Great :). Sorry about the unnecessary info then-- I wasn't sure what you were asking in re reliability etc. Was afraid you were concerned abt net congestion causing flakiness. Thank you for considering Koha. I hope I didn't ramble on for too long. Nick Rosasco > -----Original Message----- > From: Karen Littlefield [mailto:klittle@mid-del.k12.ok.us] > Sent: Wednesday, July 03, 2002 2:29 PM > To: nsr(a)etome.net > Subject: Re: RE: RE: RE: Hello > > > ** Reply Requested When Convenient ** > > > > Reply requested when convenient > > We are on T1 lines using cable access to the Web. We don't use > phone lines or modems for any of our access. IT would seem to me > that this would make this an excellent solution. Thanks for your > time. I will be sharing this with the decision makers here in > our district. > > Karen Littlefield > klittle(a)mid-del.k12.ok.us > Mid Del Schools > Midwest City, OK 73110 > 405-737-4461 x294 >

1 0

RE: RE: RE: Hello
by Nicholas Rosasco 03 Jul '02

03 Jul '02

You are _very_ on track. I'm a little confused... do you mean Koha was created to work easily over phone lines. Our feedback indicates that the telnet based circulation system is better for phonelines (versus the web circ. system) as far as response time goes. Modems for linking patron stations catalog searching works fine. If you can't afford any downtime, you could follow the route taken by one of our Sites. MySQL has support for replicating servers -- makes it pretty easy to set up a hotswappable server. It would require a second machine to replicate to... we can point you to info on how to accomplish that. Network and dial-in reliability issues are really rather beyond my scope :) past that point. Anything else I can answer? Nick > -----Original Message----- > From: Karen Littlefield [mailto:klittle@mid-del.k12.ok.us] > Sent: Wednesday, July 03, 2002 12:14 PM > To: nsr(a)etome.net > Subject: Re: RE: RE: Hello > > > ** Reply Requested When Convenient ** > > > > Reply requested when convenient > > SOOOO I get from your last communication that we would be > choosing to export all data from our existing system to the Koha > system and would be running it with the entire database residing > on a district server across our WAN. Installation would be Unix > in format and our only obligation would be to provide the server > and management of the database. Am I on track? I know we have > some issues related to MARC but we have been working on that > issue for a couple of years and the cleanup is happening. Our > tech support coordinator is UNIX wise and I'm sure could handle > the loading process. I guess my next question is the quality of > service across the WAN. Having the library down is NOT good. > > Karen Littlefield > klittle(a)mid-del.k12.ok.us > Mid Del Schools > Midwest City, OK 73110 > 405-737-4461 x294 >

1 0

Re: [Koha] Some question: postgres, italian, ...
by Alan Millar 03 Jul '02

03 Jul '02

This conversation came up on the main Koha list: > From: Marco Gaiarin <gaio(a)sv.lnf.it> > > Having said that, im sure some mysqlisms have crept into the code over > > the last 2-3 years. So im sure a little bit of code cleanup will be > > needed as well. > > As i suppose, i've found a bunch of this. e.g., in > > --- ./cgi-bin/admin/currency.pl~ Mon Jul 1 16:59:55 2002 > +++ ./cgi-bin/admin/currency.pl Mon Jul 1 17:09:37 2002 > @@ -31,7 +31,7 @@ > $searchstring=~ s/\'/\\\'/g; > my @data=split(' ',$searchstring); > my $count=@data; > - my $query="Select currency,rate from currency where (currency like \"$data[0]%\") order by currency"; > + my $query="Select currency,rate from currency where (currency like '$data[0]%') order by currency"; > my $sth=$dbh->prepare($query); > $sth->execute; > my @results; > > Postgres use " for strict escape (inside "", % is a normal character), > and ' for normal character enclosing (so inside '' % is a wildcard > matching char as supposed). > Clearly all file have to be changed, and need to be verified there's no > ' character in strings, really common in italian. In my opinion, this is another very good reason to use the DBI bound parameters and stop using $dbh->quote. This should really by done as: my $query="Select currency,rate from currency where (currency like ?) order by currency"; my $sth=$dbh->prepare($query); $sth->execute($data[0] . '%'); or similar. Then we don't have to worry about Italian using apostrophes, etc. - Alan ---- Alan Millar --==> am12(a)bolis.com <==--

1 0

[Bug 57] koha.upgrade doesn't add koha.version
by bugzilla-daemon＠wilbur.katipo.co.nz 03 Jul '02

03 Jul '02

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=57 tonnesen(a)cmsd.bc.ca changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From tonnesen(a)cmsd.bc.ca 2002-07-04 05:01 ------- Fixed koha.upgrade so that it updates koha.conf, adding the kohaversion, intranetdir, and opacdir lines if they are missing. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0