← 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