IRC log for #koha, 2007-03-24

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

All times shown according to UTC.

Time Nick Message
12:00 lea hey
12:01 i'm getting 3 copies of every book i import via bulkmarcimport. Any ideas?
12:06 hdl lea : did you launch bulkmarcimport more than once ?
12:06 lea : Is there a loop you misuse ?
12:08 lea hdl: I'm using the -d flag
12:08 that should delete target DB no?
12:09 the output data is ok
12:09 *import data is ok. I visually checked it
12:10 i've seen this before. What happens is you get the barcode on one item, the location on another and nopthing on the 3rd
12:10 toins kados around ?
12:34 lea here is an example record that is generating 3 items: http://www.pastebin.ca/406676
12:35 *using bulkmarcimport
12:42 ah, a clue! I've added home and holding branch and the item count has gone up to 5! So this leads me to believe that koha creates an item per 952 tag!
13:03 nice one
13:03 gotta go
13:18 cm rch, are you in?
13:25 rch hi cm
13:37 any luck with the itemnotes problem?
13:47 cm hey rch.  that's what I was going to ask you.  ;)
14:05 rch what's the status?
14:05 dewey hmmm... the status is updating
14:10 kyle Can anyone tell me how I get the currently set branch code for the currently logged in librarian circ.
14:12 currently renewals do not put the branchcode in the statistics table, and I would like to add it.
14:13 Otherwise our reports don't count renewals.
14:16 cm rch, i haven't been able to figure itemnotes out.
14:16 kados kyle: it's in the cookie
14:16 rch kyle: there should be a brnch cookie set.
14:16 kyle is there anyway I can grab it directly in Circ2::renewbook
14:16 cm i have items.itemnotes mapped to the nonpublic note field (952x) but if I add a note in the item editor,
14:16 rch $query->cookie->{'branch'}
14:17 i think.
14:17 cm the data's not saved in items.itemnote.
14:17 kados yea, where $query is the CGI object
14:17 cm just in the marc record.
14:17 kyle $query is not a local var in renewbook.
14:17 I think.
14:17 rch somethimes it's $input
14:17 kados kyle: well whatever the CGI object is called
14:17 cm so the templates can't find it, because marc stuff isn't in the loop the template is using.
14:19 rch cm: right, but all the items table  is
14:19 so it must be a template problem passing back to the script in the item edit
14:19 cm yeah, but if i have it mapped, it should be saving whatever I add to 952x to itemnote, right?
14:20 yeah, that's my understanding.
14:21 i think i'll switch to the npl template to make sure it's not a bug in our template.
14:21 kyle, did you catch that?  i'm going to switch templates for a few minutes.
14:21 rch cm: if you look at the html, you should see the mapping in additem.pl
14:22 kyle cm: ok
14:22 cm ok, rch, i'll look at the source before switching.
14:22 rch ie: <input name="field_value" size="50" maxlength="255">  <input name="tag">[959]  <input name="subfield">[w]  <input name="mandatory">[0]
14:22 (i have my items in 959's)
14:23 and public note mapped to 959$w
14:24 cm this is what I see:
14:24 <th><label>x - <span id="error14">Nonpublic note</span></label></th>
14:24 <td><input type="text" name="field_value" value="" size=50 maxlength=255>
14:24 <input type="hidden" name="tag" value="952">
14:24 <input type="hidden" name="subfield" value="x">
14:24 <input type="hidden" name="mandatory" value="0"></td>
14:26 rch hmm.
14:27 and your other items fields are being saved in items table?
14:27 cm yeah, AFAIK.
14:27 just not the note.
14:37 ok, I tested it with npl's template.  it didn't save to itemnote either.
14:38 rch cm: can you give details on the mapping from the framework you're using?
14:38 kados it'd be worth running the MARC check too
14:38 cm like what?
14:38 i'll run marcheck.
14:39 marccheck says it's ok.
14:40 i can confirm it's saving the note to biblioitems.marc.
14:40 kyle when I try: print STDERR "renewscript: branch: " . $input->cookie->{'branch'} . "\n"; from renewscript.pl I get nothing.
14:40 even though earlier I see: my $input = new CGI;
14:42 rch ah, sorry... cookie is a method, not a hashref.
14:42 cookie('branch') should do it.
14:44 kyle like this: $input->cookie('branch') ?
14:44 rch yep
14:53 cm: did you check your framework?
14:53 make sure you don't have some weird p[lugin defined?
14:55 kyle for some reason, when I pass $branch from renewscript to circ2::renewbook, it disapears. Any ideas?
14:55 cm yeah, i think it's okay.  Here's a pdf of my mapping in 952:
14:56 http://circ.ccfls.org/952mapping.pdf
14:58 rch kyle: there's some code in circ2 that takes the branch from the borrowers table.
14:58 I did a little cleaning on that yesterday, but haven't had time to finish...
14:59 primarily the too_many sub.
14:59 it requires a bunch of new sql queries to check if you've hit maxissueqty at each branch.
15:03 so in renewbook:
15:03    my $loanlength = getLoanLength($borrower->{'categorycode'},$iteminf​ormation->{'itemtype'},$borrower->{'branchcode'});
15:21 cm: still there?
15:21 dewey i heard there was no spoon
15:25 cm rch, yeah, i'm still here.
15:27 so itemnotes works for everybody but me?  :(
15:29 rch cm: check C4::Biblio.pm
15:30 sub _koha_modify_item  around line 2090
15:30 cm ok.
15:31 okay, i'm there.
15:31 rch check the bind variables
15:32 do you see an $item->{'itemnotes'} ?
15:32 or an $item->{'notes'} ?
15:36 cm i see 'notes' on line 2107.  haven't found 'itemnotes'.
15:38 rch cm:     my @bind = (
15:38        $item->{'barcode'},         $item->{'notes'},
15:38        $item->{'itemcallnumber'},  $item->{'notforloan'},
15:38        $item->{'location'},        $item->{multivolumepart},
15:38        $item->{multivolume},       $item->{stack},
15:39 ??
15:44 cm here's mine:
15:44    my @bind = (
15:44        $item->{'barcode'},                     $item->{'notes'},
15:44        $item->{'itemcallnumber'},      $item->{'notforloan'},
15:44        $item->{'location'},            $item->{multivolumepart},
15:44                $item->{multivolume},           $item->{stack},
15:44                $item->{wthdrawn},$item->{holdingbra​nch},$item->{homebranch},$cutterextr​a,$item->{onloan},$item->{binding}
15:45 looks the same.
15:46 are you running dev_week too?
15:47 rch yes, one stock and one fairly heavily customized.
15:47 interestingly, i have $item->{itemnotes} on one, and {notes} on the other... looking into that now
15:49 cm yeah, interesting.
15:49 rch (and they both work)
15:49 :?
15:50 cm yikes!
15:51 is {notes} equal to a field called items.notes, then?
15:51 if so, i don't have it.
15:58 rch:  i changed it to {itemnotes} and it worked!
15:58 rch++
15:58 rch great!
15:58 cm yes, thanks!
15:59 rch cm: note it's there twice, again after  an if statment.
15:59 cm okay, thanks.
16:00 rch guess i didnt commit that...
16:00 cm yeah, peeked at the cvs browser and didn't see it.
16:00 good eye, i would never have found that.
16:11 hey, rch, while you're here, we also realized something about how the due date is calulated with holidays.
16:12 it looks like always offsets the due date by the holidays regardless of whether the due date falls on the holiday or after it.
16:12 it should only prevent the due date from falling on a holiday, but not add days to the due date if it doesn't.
16:15 slef hello everyone
16:16 cm hi slef
18:29 slef rach: hello
05:30 js hi #koha
06:13 chris hi js
06:13 js :)
06:52 paul hello kados.
06:53 kados hi paul
06:53 paul: I attempted to install opencataloger yesterday
06:53 paul i'll have time to work on head in the next 2 weeks
06:53 kados paul: I ran into some problems
06:53 paul i'm waiting impatiently for some directions ;-)
06:53 kados paul: (great news!)
06:53 hehe
06:54 how often does toins work on opencataloger?
06:54 paul what do you mean by "how often" ?
06:55 kados does he work on it every week?
06:55 paul atm, he works for me only on monday.
06:55 kados I am wondering because in an email to me he said it was nearly finished
06:55 paul and the last 3 mondays, he worked on it at least a little bit.
06:55 kados ahh, ok
06:55 paul: do you have a customer who will use it immediately?
06:56 paul IPT probably. but I have to work on it, to enable iso8859-1 encoding
06:56 (as she will work on it with french 2.2)
06:56 kados (right)
06:56 paul (so in latin1, not unicode)
06:56 + change some scripts to use 2.2 API and not 3.0 one
06:57 kados right
06:57 and not zebra?
06:57 (it seems it is supposed to use zebra now)
06:57 paul right.
06:57 kados (though I cannot get it working)
06:58 paul although for zebra/not zebra use, I may solve the problem with the NPL 2.2 z3950server
06:58 (at least for reading catalogue)
06:58 kados (right)
06:58 (keep in mind that is a very ugly script :-)
06:58 paul (for saving, I use Koha API anyway, so nothing to change, except the API)
06:58 kados (it was the first perl I ever wrote)
06:58 paul (maybe we could stop adding () on all our phrases...)
06:59 ()
06:59 kados hehe
06:59 I was just thinking the same thing :-)
06:59 paul hdl just found expiry date not properly calculated bug on 2.2.8
06:59 kados or else we need to start adding (( )) to every phrase :-)
06:59 for borrowers?
06:59 paul it's a Date::Manip use instead of Date::Calc...
06:59 yep.
07:00 kados NPL noticed that some borrowers don't have a correct data assigned and it causes circ to crash
07:00 this is in dev_week which is based on 2.2
07:00 so I'm not surprised
07:00 did hdl find a fix?
07:01 paul in fact, there is one in rel_2_2, that is not in 2.2.8 (specific branch)
07:01 hdl I committed a fix on rel_2_2 som time ago.
07:01 kados hdl++
07:26 hdl: have you used opencataloger?
07:34 hmmm, maybe it just saves to zebra?
07:35 ahh, I see savetokoha.pl now
07:37 but it doesn't seem to work, I 'save' it and it says 'OK' but when I searh for the record again it is unchanged
07:41 and the record doesn't leave the finished reservoir
07:55 kyle hey kados
09:16 paul kados: saveToKoha.pl is the last script to test in fact. I'm not that surprised that it don't work atm
09:27 kados paul: it does work!
09:28 paul great !
09:28 toins told me it seemed to work, but I couldn't test yet
09:28 kados yep, it's very interesting
09:28 owen Hi everyone
09:29 kados one thing it doesn't currently allow is editing existing records
09:29 owen: hi
09:29 dewey bonjour, kados
09:32 paul hi owen
09:32 what do you mean ? you can retrieve a record, save it, but not modify it ?
09:33 kados I can find a record in koha
09:33 edit it and save it
09:33 and now there are two records in koha :-)
09:39 paul hehe... it's a new feature ;-)
09:39 "library enlargement patch"
09:40 kados hehe
10:04 kyle I was just thinking... I've been fixing a some bugs in dev_week, does anyone pull the bugfixes into rel 2.x ? It seems like a good idea.
10:04 paul kyle: I've seen them, they are still "to read" status on my mailbox
10:04 owen From time to time, kyle. I know I've seen such traffic on the koha-cvs list
10:05 paul and they will stay here until i've taken care of them
10:05 (which may need some time...)
10:05 kyle I don't mean my bugfixes specifically, but bugfixes in dev_week in general
10:07 it's good to know that there are people keeping an eye for those things ; )
10:07 ls
10:23 kados kyle: cvs update -r dev_week filename will merge the changes
10:23 kyle: if you're working on a rel_2_2 branch
10:23 kyle I always work on dev_week
10:23 as that is what we are rolling out on.
10:23 ls
10:24 kados yea
10:24 so if you want to backport stuff
10:24 check out a copy of rel_2_2
10:24 and then do cvs update -r dev_week filename
10:24 or else paul will do it ;-)
10:24 kyle sounds good. thanks for the info.
10:25 paul mmm... I won't do that without triple checking... will put in some bugs for sure...
10:25 kados yea, make sure you also test :-)
10:25 paul: sorry :-)
10:26 kyle Has anyone checked out that problem with the issuing rules being selected by the borrower's homebranch instead of the branch cookie ?
10:27 kados IIRC Ryan's looking into it still
10:27 kyle excellent.
10:27 kados paul: did you hear about that one?
10:28 paul kados: could you explain ?
10:28 (because iiuc, it's not a bug according to me)
10:29 kados kyle could explain it better
10:29 kyle ok.
10:30 Basically, when an item is circulated in koha, the rules governing that circulation are the rules for that patrons homebranch, regardless or which library branch the patron is at.
10:30 In our system, each library has different rules, and that way of function would really screw everything up.
10:31 kados kyle: are you sure it's not the rules for the item's homebranch?
10:31 kyle: or is that what you're saying
10:31 paul kados is right : it's supposed to be item homebranch issuing rules, not borrower branch.
10:31 kyle If a library only allows 4 dvd's, and the borrower's homebranch allows 6, the borrower should only be able to check out 4 at *that* library.
10:31 paul s/homebranch/holdingbranch/ iirc
10:32 wow... very complex for users to remember i'm afraid...
10:32 kyle I don't see why it should be the item's homebranch either. To me the only may that makes sense is to have the issuing rules chosen based on which branch you are at. That is, by the branch set in the intranet cookie.
10:33 kados kyle: I can tell you from experience that every library has a 'only way that makes sense' :-)
10:33 paul in your example, say lib A allow 4 and lib B allow 6
10:33 kyle If you do it by item's homebranch, then as soon as you introduce a rotating collection things get even stranger : )
10:33 paul what happends if patron already has 5 DVD from B and tries to issue one at A ?
10:33 (what is supposed to happend I mean)
10:34 kyle I understand what you mean. I will ammend my statment: 'for *us*, that is the only way that makes sense'
10:34 us as in the CCFLS
10:35 If library A has a max out of 3 DVDs and library B has a max out of 6 DVDs, a borrower should be able to go to A and get 3 DVDs, then drive over to B and get another 6 DVDs. At least, that's how it should work for us at the CCFLS.
10:38 I'll be back, we have to move 20 monitors to another building.
11:03 hdl Becaus then, user exceeds the maxissuecount in any library.
11:03 Say I am registered at library A
11:04 Library A allows 3 DVDs, B 4, C 3 and D 1.
11:04 I borrow 3 DVDS at A, 4 at B, 3 at C.
11:05 And returns to D... 10 DVDs at once :D Jackpot for D !!
11:18 kyle owen: our libraries don't really share materials. However, we do have rotating collections. So we have a group of say 30 audiobooks, and they stay at a library for a period of months, and then are passed on to the next library.
11:19 owen But you can't return an item from one library to another one?
11:19 kyle it doesn't happen often, but a patron *can* return a book to a different library, then it is mailed to the item's home library
11:20 it's a rare occurance.
11:21 owen So kyle, for your librarians, do they want to be able to see what a person has checked out from each branch? Or do they only care about what's checked out from their branch.
11:22 kyle I think it doesn't hurt to allow a librarian to see what the borrower has checked out at each library. I believe that is how it works now, yes?
11:23 owen Yeah, that's how Koha works. I was just curious what they're used to.
11:24 kyle Our current ILS is a separate install for each library, it runs on DOS. Koha is going to be a *huge* change for them.
11:24 owen But I'm not sure how Koha would handle your example with limits at each branch
11:24 (since we don't do anything like that)
11:25 kyle I believe it was rch who said it would actually be a very simple fix. I imagine it just involves replacing the branchcode argument for grabbing the issuing rules with the branchcode from the cookie.
11:26 he asked about the very same thing, and said that limits for each library was the easy answer.
11:26 that is, that limits for each library fits naturally with the current system and requires no extra coding, if I understood correctly.
11:28 owen That's good. Often libraries ask us, can Koha do this? And we say, We don't know, we don't do that! :)

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

koha1