Time |
S |
Nick |
Message |
12:00 |
|
lea |
hey |
12:01 |
|
lea |
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 |
|
hdl |
lea : Is there a loop you misuse ? |
12:08 |
|
lea |
hdl: I'm using the -d flag |
12:08 |
|
lea |
that should delete target DB no? |
12:09 |
|
lea |
the output data is ok |
12:09 |
|
lea |
*import data is ok. I visually checked it |
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:10 |
|
toins |
kados around ? |
12:34 |
|
lea |
here is an example record that is generating 3 items: http://www.pastebin.ca/406676 |
12:35 |
|
lea |
*using bulkmarcimport |
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! |
13:03 |
|
lea |
nice one |
13:03 |
|
lea |
gotta go |
13:18 |
|
cm |
rch, are you in? |
13:25 |
|
rch |
hi cm |
13:37 |
|
rch |
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 |
|
kyle |
currently renewals do not put the branchcode in the statistics table, and I would like to add it. |
14:13 |
|
kyle |
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 |
|
rch |
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 |
|
kyle |
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 |
|
rch |
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 |
|
cm |
yeah, that's my understanding. |
14:21 |
|
cm |
i think i'll switch to the npl template to make sure it's not a bug in our template. |
14:21 |
|
cm |
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 |
|
rch |
(i have my items in 959's) |
14:23 |
|
rch |
and public note mapped to 959$w |
14:24 |
|
cm |
this is what I see: |
14:24 |
|
cm |
<th><label>x - <span id="error14">Nonpublic note</span></label></th> |
14:24 |
|
cm |
<td><input type="text" name="field_value" value="" size=50 maxlength=255> |
14:24 |
|
cm |
<input type="hidden" name="tag" value="952"> |
14:24 |
|
cm |
<input type="hidden" name="subfield" value="x"> |
14:24 |
|
cm |
<input type="hidden" name="mandatory" value="0"></td> |
14:26 |
|
rch |
hmm. |
14:27 |
|
rch |
and your other items fields are being saved in items table? |
14:27 |
|
cm |
yeah, AFAIK. |
14:27 |
|
cm |
just not the note. |
14:37 |
|
cm |
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 |
|
cm |
i'll run marcheck. |
14:39 |
|
cm |
marccheck says it's ok. |
14:40 |
|
cm |
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 |
|
kyle |
even though earlier I see: my $input = new CGI; |
14:42 |
|
rch |
ah, sorry... cookie is a method, not a hashref. |
14:42 |
|
rch |
cookie('branch') should do it. |
14:44 |
|
kyle |
like this: $input->cookie('branch') ? |
14:44 |
|
rch |
yep |
14:53 |
|
rch |
cm: did you check your framework? |
14:53 |
|
rch |
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 |
|
cm |
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 |
|
rch |
I did a little cleaning on that yesterday, but haven't had time to finish... |
14:59 |
|
rch |
primarily the too_many sub. |
14:59 |
|
rch |
it requires a bunch of new sql queries to check if you've hit maxissueqty at each branch. |
15:03 |
|
rch |
so in renewbook: |
15:03 |
|
rch |
my $loanlength = getLoanLength($borrower->{'categorycode'},$iteminformation->{'itemtype'},$borrower->{'branchcode'}); |
15:21 |
|
rch |
cm: still there? |
15:21 |
|
dewey |
i heard there was no spoon |
15:25 |
|
cm |
rch, yeah, i'm still here. |
15:27 |
|
cm |
so itemnotes works for everybody but me? :( |
15:29 |
|
rch |
cm: check C4::Biblio.pm |
15:30 |
|
rch |
sub _koha_modify_item around line 2090 |
15:30 |
|
cm |
ok. |
15:31 |
|
cm |
okay, i'm there. |
15:31 |
|
rch |
check the bind variables |
15:32 |
|
rch |
do you see an $item->{'itemnotes'} ? |
15:32 |
|
rch |
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 |
|
rch |
$item->{'barcode'}, $item->{'notes'}, |
15:38 |
|
rch |
$item->{'itemcallnumber'}, $item->{'notforloan'}, |
15:38 |
|
rch |
$item->{'location'}, $item->{multivolumepart}, |
15:38 |
|
rch |
$item->{multivolume}, $item->{stack}, |
15:39 |
|
rch |
?? |
15:44 |
|
cm |
here's mine: |
15:44 |
|
cm |
my @bind = ( |
15:44 |
|
cm |
$item->{'barcode'}, $item->{'notes'}, |
15:44 |
|
cm |
$item->{'itemcallnumber'}, $item->{'notforloan'}, |
15:44 |
|
cm |
$item->{'location'}, $item->{multivolumepart}, |
15:44 |
|
cm |
$item->{multivolume}, $item->{stack}, |
15:44 |
|
cm |
$item->{wthdrawn},$item->{holdingbranch},$item->{homebranch},$cutterextra,$item->{onloan},$item->{binding} |
15:45 |
|
cm |
looks the same. |
15:46 |
|
cm |
are you running dev_week too? |
15:47 |
|
rch |
yes, one stock and one fairly heavily customized. |
15:47 |
|
rch |
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 |
|
rch |
:? |
15:50 |
|
cm |
yikes! |
15:51 |
|
cm |
is {notes} equal to a field called items.notes, then? |
15:51 |
|
cm |
if so, i don't have it. |
15:58 |
|
cm |
rch: i changed it to {itemnotes} and it worked! |
15:58 |
|
cm |
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 |
|
cm |
good eye, i would never have found that. |
16:11 |
|
cm |
hey, rch, while you're here, we also realized something about how the due date is calulated with holidays. |
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: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: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 |
|
kados |
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 |
|
kados |
hehe |
06:54 |
|
kados |
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 |
|
kados |
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 |
|
paul |
(as she will work on it with french 2.2) |
06:56 |
|
kados |
(right) |
06:56 |
|
paul |
(so in latin1, not unicode) |
06:56 |
|
paul |
+ change some scripts to use 2.2 API and not 3.0 one |
06:57 |
|
kados |
right |
06:57 |
|
kados |
and not zebra? |
06:57 |
|
kados |
(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 |
|
paul |
(at least for reading catalogue) |
06:58 |
|
kados |
(right) |
06:58 |
|
kados |
(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 |
|
paul |
() |
06:59 |
|
kados |
hehe |
06:59 |
|
kados |
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 |
|
kados |
for borrowers? |
06:59 |
|
paul |
it's a Date::Manip use instead of Date::Calc... |
06:59 |
|
paul |
yep. |
07:00 |
|
kados |
NPL noticed that some borrowers don't have a correct data assigned and it causes circ to crash |
07:00 |
|
kados |
this is in dev_week which is based on 2.2 |
07:00 |
|
kados |
so I'm not surprised |
07:00 |
|
kados |
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 |
|
kados |
hdl: have you used opencataloger? |
07:34 |
|
kados |
hmmm, maybe it just saves to zebra? |
07:35 |
|
kados |
ahh, I see savetokoha.pl now |
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:41 |
|
kados |
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 |
|
paul |
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 |
|
kados |
owen: hi |
09:29 |
|
dewey |
bonjour, kados |
09:32 |
|
paul |
hi owen |
09:32 |
|
paul |
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 |
|
kados |
edit it and save it |
09:33 |
|
kados |
and now there are two records in koha :-) |
09:39 |
|
paul |
hehe... it's a new feature ;-) |
09:39 |
|
paul |
"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 |
|
paul |
(which may need some time...) |
10:05 |
|
kyle |
I don't mean my bugfixes specifically, but bugfixes in dev_week in general |
10:07 |
|
kyle |
it's good to know that there are people keeping an eye for those things ; ) |
10:07 |
|
kyle |
ls |
10:23 |
|
kados |
kyle: cvs update -r dev_week filename will merge the changes |
10:23 |
|
kados |
kyle: if you're working on a rel_2_2 branch |
10:23 |
|
kyle |
I always work on dev_week |
10:23 |
|
kyle |
as that is what we are rolling out on. |
10:23 |
|
kyle |
ls |
10:24 |
|
kados |
yea |
10:24 |
|
kados |
so if you want to backport stuff |
10:24 |
|
kados |
check out a copy of rel_2_2 |
10:24 |
|
kados |
and then do cvs update -r dev_week filename |
10:24 |
|
kados |
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 |
|
kados |
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 |
|
paul |
(because iiuc, it's not a bug according to me) |
10:29 |
|
kados |
kyle could explain it better |
10:29 |
|
kyle |
ok. |
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:30 |
|
kyle |
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 |
|
kados |
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 |
|
paul |
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 |
|
paul |
(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 |
|
kyle |
us as in the CCFLS |
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:38 |
|
kyle |
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 |
|
hdl |
Say I am registered at library A |
11:04 |
|
hdl |
Library A allows 3 DVDs, B 4, C 3 and D 1. |
11:04 |
|
hdl |
I borrow 3 DVDS at A, 4 at B, 3 at C. |
11:05 |
|
hdl |
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 |
|
kyle |
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 |
|
owen |
(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 |
|
kyle |
he asked about the very same thing, and said that limits for each library was the easy answer. |
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: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! :) |