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