IRC log for #koha, 2006-12-08

← Previous day | Today | Next day → | Search | Index

All times shown according to UTC.

Time Nick Message
11:04 kados paul: when receiving an item, there is an Accounting Details section
11:04 paul: it asks how many items were received
11:04 paul: this is confusing to me ...
11:05 paul: suppose I order 4 items, and I recieve a parcel with 3 of them
11:05 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 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 so if I enter a barcode for instance
11:07 is that barcode added to every item (out of 3)?
11:07 (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 you want to put barcodes on items just when you recieve them, right ?
11:08 kados yes
11:08 paul !
11:09 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 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 we should integrate acquisitions and serials with additem.pl and addbiblio.pl
11:11 paul for serials, hdl did it already if I understand what you mean.
11:11 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 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 ESI => not decided, but we plan at least to have a strong API to be able to add it when needed.
11:21 kados : bulkmarcimport says : {_conn} undefined: has this Connection been destroy()ed? at /usr/lib/perl5/site_perl/5.8.8/i386-linux/ZOOM.pm line 344.
11:23 hdl was this bulkmarcimport modified according to the latest Context.pm ?
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 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 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 cm: ok ...
11:27 cm kados: should I update to the Circ2.pm you just committed?
11:29 kados cm: won't hurt, but shouldn't affect anything
11:29 cm: I'm in
11:29 cm ok, will do.
11:29 cool.
11:39 paul the 1st zebraop works, the 2nd fails.
11:39 between them, the context->Zconn is dropped, I still don't know why.
11:39 but of course, the next zebraop will reach an empty connexion & fail.
11:40 (+ 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 cm: the getissues call isn't returning data
11:47 cm hmm.
11:47 in my bugtracker I'm using to track our project, I found that I marked it as working on Nov 15.
11:47 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 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 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 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 (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 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 paul: like 1 minute, or 10 minutes
11:55 cm i found it in circ2.pm.  
11:55 kados cm: yea, it's called in circulation.pl and the routine is in Circ2.pm
11:56 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 Biblio.pm, go to line 3486 and tell me what you see :-D
11:58 (line 3483 sorry)
11:58 kados hehe
11:59 paul bulkmarcimport works ;-)
11:59 kados it does?
11:59 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 bulkmarcimport.pl -d -f aniso_file
12:00 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     $Zconnbiblio[0]->destroy();
12:01 kados !!
12:01 paul the last line of zebraop
12:01 in fact :
12:01    $Zconnbiblio[0] = C4::Context->Zconn( $server, 0, 1 );
12:02 kados paul++
12:02 :-)
12:02 cm: here's the query:
12:02 SELECT items.*,issues.timestamp      AS timestamp, issues.date_due       AS date_due, items.barcode         AS barcode, biblio.title          AS title, biblio.author         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 cm: and that returns nothing in mysql when I run it
12:04 cm: SELECT items.*,issues.timestamp      AS timestamp, issues.date_due       AS date_due, items.barcode         AS barcode, biblio.title          AS title, biblio.author         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 nope, ccodes aren't required
12:05 ahh, wait a sec
12:05 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 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 so I obliterated all our itemtypes--oops!
12:07 kados yea, and frankly, the ccodes is a bit of a hack
12:07 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 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 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 actually ...
12:15 ccode can be empty in that query
12:16 the query is dependent on itemtype not being empty
12:16 so I'm guessing that's where the problem has been the whole time
12:16 we'll see soon I suppose :-)
12:17 cm huh...itemtype is indeed empty.
12:17 well, crap.
12:18 i must have managed to blitz them again and didn't realize it or got sidetracked.
12:18 too much going on!
12:19 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 that's a possibility.
12:25 i'm reloading the database from an old backup.
12:25 i like tumer's quit message.  :)
12:26 mc
12:26 oops
12:29 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 i think i remapped my fields incorrectly, and so they didn't get inserted by bulkmarcimport.
12:52 i'm reloading the data now.
12:52 sorry for wasting your time!
14:10 slef hi
14:10 dewey bonjour, slef
14:10 slef hdl, kados: içi? here?
14:10 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 paul: ça va?
14:11 paul lol
14:11 yep.
15:35 cm hey kados--it works perfectly now that I have itemtypes.  
15:35 thanks.  :)
15:38 kados itemtypes++ ;-)
15:41 cm yep.  :)
20:30 rch hey
20:30 can anyone out there give a quick rundown on reserveconstraints?

← Previous day | Today | Next day → | Search | Index

koha1