IRC log for #koha, 2006-12-08

All times shown according to UTC.

Time S Nick Message
11:04 kados paul: when receiving an item, there is an Accounting Details section
11:04 kados paul: it asks how many items were received
11:04 kados paul: this is confusing to me ...
11:05 kados paul: suppose I order 4 items, and I recieve a parcel with 3 of them
11:05 kados paul: when i add an item, do I fill in 3 in accounting details?
11:06 paul you mean 4 items of a single title ?
11:06 kados yes
11:06 paul no, you just say 3 items in acocunting detail.
11:06 paul don't you have a field to enter this ?
11:06 kados yes, I do, but only one item is available to edit
11:07 kados so if I enter a barcode for instance
11:07 kados is that barcode added to every item (out of 3)?
11:07 kados (I have confirmed the problem exists for me in rel_2_2 npl templates ... a shame ... I'll test with default now)
11:08 paul mmm...
11:08 paul you want to put barcodes on items just when you recieve them, right ?
11:08 kados yes
11:08 paul !
11:09 paul none of our customers do that, so it may not work on default as well. but iirc, you are supposed to enter 3 barcodes, separated by a space.
11:09 kados !!!
11:09 kados this is undocumented 'feature'?
11:10 paul it's something coming from koha 1.x, so you should ask chris for this one ;-)
11:10 kados hehe
11:10 kados we should integrate acquisitions and serials with and
11:11 paul for serials, hdl did it already if I understand what you mean.
11:11 paul I must add that SAN-OP will sponsor a 100% new acquisition module in 2007, with so many new features that I can't list them ;-)
11:11 hdl not for addbiblio.
11:12 kados paul: great news!@
11:12 paul the idea being to have a complete suite to analyse & decide what to buy to have the most useful catalogue for a public library
11:12 kados will it use ESI?
11:12 kados electronic ordering, etc.?
11:13 paul acquisitions will be divided by "poles" (=subjects), with buyers being responsible of a specific budget for each pole, having monthly reports tools...
11:14 paul ESI => not decided, but we plan at least to have a strong API to be able to add it when needed.
11:21 paul kados : bulkmarcimport says : {_conn} undefined: has this Connection been destroy()ed? at /usr/lib/perl5/site_perl/5.8.8/i386-linux/ line 344.
11:23 hdl was this bulkmarcimport modified according to the latest ?
11:23 paul ???
11:24 cm hey kados--the passwords are reset, so i'll be around whenever you're ready.
11:25 paul hi cm
11:25 kados paul: that bug has always existed
11:25 cm hi paul.  :)
11:25 kados paul: even in dev_week
11:25 kados paul: it's the connection problem I told you about yesterday
11:25 paul is it related to the zebra problem or something else ?
11:25 paul ok
11:26 kados could be a zoom bug, or else koha bug related to how the connection is forged, or else zebra bug for closing the connection without being told to
11:26 kados cm: ok ...
11:27 cm kados: should I update to the you just committed?
11:29 kados cm: won't hurt, but shouldn't affect anything
11:29 kados cm: I'm in
11:29 cm ok, will do.
11:29 cm cool.
11:39 paul the 1st zebraop works, the 2nd fails.
11:39 paul between them, the context->Zconn is dropped, I still don't know why.
11:39 paul but of course, the next zebraop will reach an empty connexion & fail.
11:40 paul (+ with mod_perl, the problem would have happen in Koha itself, as the zconn is persistant)
11:45 kados cm: found where the problem is happening
11:45 kados cm: the getissues call isn't returning data
11:47 cm hmm.
11:47 cm in my bugtracker I'm using to track our project, I found that I marked it as working on Nov 15.
11:47 cm so, something must have happened between now and then to break it again.
11:48 tumer paul:around??
11:48 cm i'm looking at the cvs digest to see what has changed between now and then.
11:48 paul yep
11:48 tumer see my mail on zebraop
11:49 kados cm: I'm not sure it's in CVS
11:50 kados cm: because I've got a few CVS installs that don't exhibit this behavior
11:50 paul tumer: thanks. kados, any opinion on tumer mail ?
11:51 kados paul: yep, my opinion is that it's a great solution
11:52 kados paul: if you have time to port it to rel_3_0 please do
11:52 cm it's probably something we did then.
11:53 cm do you know where the getissues call is?
11:53 paul (except it can be run once every 10mn or once every hour if needed)
11:53 paul (so it's more "real time update" than your solution)
11:53 tumer paul: with update_items script cannot delete a record from ZEBRA!!!
11:53 kados cm: give me a sec, I'm still troubleshooting
11:53 kados paul: it's much more efficient
11:53 paul tumer: 1 point
11:54 cm ok.
11:54 paul ok, i'll investigate the question & see what I can do
11:54 kados paul: update_items can't handle simple times
11:54 kados paul: like 1 minute, or 10 minutes
11:55 cm i found it in  
11:55 kados cm: yea, it's called in and the routine is in
11:56 kados cm: so we could throw some warns in there to figure out why it's not finding issues properly
11:56 cm ok.
11:58 paul kados, pls : open, go to line 3486 and tell me what you see :-D
11:58 paul (line 3483 sorry)
11:58 kados hehe
11:59 paul bulkmarcimport works ;-)
11:59 kados it does?
11:59 kados how?
12:00 paul at least, it don't die. I don't have checked things are indexed correctly, but I hear my HD working
12:00 kados paul: what did you do?
12:00 paul -d -f aniso_file
12:00 paul and I just commented the line 3483
12:00 kados is it a zebraop line?
12:00 paul that should never have been here, as it destroys the persistant connection
12:01 paul     $Zconnbiblio[0]->destroy();
12:01 kados !!
12:01 paul the last line of zebraop
12:01 paul in fact :
12:01 paul    $Zconnbiblio[0] = C4::Context->Zconn( $server, 0, 1 );
12:02 kados paul++
12:02 kados :-)
12:02 kados cm: here's the query:
12:02 kados SELECT items.*,issues.timestamp      AS timestamp, issues.date_due       AS date_due, items.barcode         AS barcode, biblio.title          AS title,         AS author, biblioitems.dewey     AS dewey, itemtypes.description AS itemtype, biblioitems.subclass  AS subclass, biblioitems.ccode  AS ccode, biblioitems.isbn  AS isbn, biblioitems.classification AS classification FROM issues,items,biblioitems,biblio, itemtypes WHERE issues.borrowernumber
12:04 kados cm: and that returns nothing in mysql when I run it
12:04 kados cm: SELECT items.*,issues.timestamp      AS timestamp, issues.date_due       AS date_due, items.barcode         AS barcode, biblio.title          AS title,         AS author, biblioitems.dewey     AS dewey, itemtypes.description AS itemtype, biblioitems.subclass  AS subclass, biblioitems.ccode  AS ccode, biblioitems.isbn  AS isbn, biblioitems.classification AS classification FROM issues,items,biblioitems,biblio, itemtypes WHERE issues.borrowernum
12:05 cm i'm wondering if it's because I don't have any ccodes in there yet.
12:05 kados Empty set
12:05 kados nope, ccodes aren't required
12:05 kados ahh, wait a sec
12:05 kados you may be right
12:05 cm let me add one to test it.
12:06 kados what we could do is something like:
12:06 cm most of our records (if not all) are missing deweys too.
12:06 kados update biblioitems set ccode = itemtype;
12:06 kados which would make all the ccodes identical to the itemtypes
12:06 cm yeah, i'll do that.
12:06 kados k
12:06 cm i tried it the other day, but got ccodes & itemtypes reversed,
12:07 cm so I obliterated all our itemtypes--oops!
12:07 kados yea, and frankly, the ccodes is a bit of a hack
12:07 kados a bit of coding I'm definitely not proud of
12:07 cm then i reuploaded the database & got sidetracked by something else.
12:07 cm yeah, you kind of threw us for a loop with that.
12:08 kados well, it would be simple enough to make a syspref to turn them on or off
12:08 cm that would be good.
12:08 kados ok, I'll put it on the list
12:10 cm uh oh, you got it reversed too.  I just obliterated the itemtypes again.  :P
12:10 kados er?
12:10 cm well, i have a database backup from last night, at least.
12:10 kados update biblioitems set ccode=itemtype; should have updated only ccode
12:11 cm i'm looking at biblioitems in phpmyadmin, and they're both empty.
12:12 cm hmm...maybe itemtype was empty before?  i should've looked before I did it.
12:12 kados did you do it fromp phpmyadmin? or the mysql console?
12:12 cm console.
12:13 kados try restoring the db and check for values in biblioitems.itemtype
12:13 cm ok.  it'll take me a few minutes to get it started.
12:13 kados I still can't figure out what i was thinking committing that ccode query
12:15 kados actually ...
12:15 kados ccode can be empty in that query
12:16 kados the query is dependent on itemtype not being empty
12:16 kados so I'm guessing that's where the problem has been the whole time
12:16 kados we'll see soon I suppose :-)
12:17 cm huh...itemtype is indeed empty.
12:17 cm well, crap.
12:18 cm i must have managed to blitz them again and didn't realize it or got sidetracked.
12:18 cm too much going on!
12:19 cm I guess I'll have to run bulkmarcimport again to get them back, unless they happen to be in one of my backups.
12:19 cm that's a possibility.
12:25 cm i'm reloading the database from an old backup.
12:25 cm i like tumer's quit message.  :)
12:26 cm mc
12:26 cm oops
12:29 cm shoot, they're still null.  i'm going to have to use bulkmarcimport.
12:46 kados koha will will work much better with itemtypes ;-)
12:49 cm yes, indeed.  :)
12:52 cm i think i remapped my fields incorrectly, and so they didn't get inserted by bulkmarcimport.
12:52 cm i'm reloading the data now.
12:52 cm sorry for wasting your time!
14:10 slef hi
14:10 dewey bonjour, slef
14:10 slef hdl, kados: içi? here?
14:10 slef dewey, es-tu bot?
14:10 dewey slef: wish i knew
14:11 paul (hdl seems not to be here since 30mn)
14:11 slef paul: I don't have any dangling discussion with you yet ;-)
14:11 slef paul: ça va?
14:11 paul lol
14:11 paul yep.
15:35 cm hey kados--it works perfectly now that I have itemtypes.  
15:35 cm thanks.  :)
15:38 kados itemtypes++ ;-)
15:41 cm yep.  :)
20:30 rch hey
20:30 rch can anyone out there give a quick rundown on reserveconstraints?

| Channels | #koha index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary