Time |
S |
Nick |
Message |
12:37 |
|
slef |
hi all |
12:41 |
|
acmoore |
good morning |
13:00 |
|
gmcharlt |
greetings |
13:01 |
|
hdl |
hi |
13:04 |
|
masonj |
hi guys |
13:07 |
|
hdl |
gmcharlt: how are you ? |
13:07 |
|
gmcharlt |
good, and you? |
13:08 |
|
hdl |
tired by my trip to Yerevan. |
13:08 |
|
hdl |
But it was a good experience. |
13:08 |
|
hdl |
And it was great to meet Dan Scott again. |
13:08 |
|
hdl |
Is rch around ? |
13:08 |
|
ryan |
hi hdl |
13:09 |
|
hdl |
hi ryan |
13:09 |
|
hdl |
I have seen you had worked on the serials part. |
13:10 |
|
ryan |
yes, i have |
13:10 |
|
hdl |
And you seemed to display serialseq on items page when it was linked to a subscription. |
13:10 |
|
ryan |
I was going to send off a reply to your email |
13:10 |
|
ryan |
yes, a less-than-ideal solution |
13:11 |
|
hdl |
Have you worked on serials recently ? |
13:11 |
|
ryan |
i was looking to do a date sort for serials |
13:11 |
|
ryan |
no, not recently. |
13:12 |
|
ryan |
hdl: will your work allow for 2/month serials planning ? |
13:12 |
|
hdl |
ryan: sure, to display serialseq on items page when it was linked to a subscription was less than ideal, but provided ppl with information on one place |
13:13 |
|
hdl |
And that was a good step. |
13:14 |
|
hdl |
ryan: well, my goal is to even allow 3/week and 3/month and eventually n/day|week|month |
13:14 |
|
ryan |
nice. |
13:14 |
|
hdl |
This is why a frequency table is required. |
13:15 |
|
ryan |
yep. i think that's a good approach. |
13:17 |
|
ryan |
hdl: I just got a question from one of our data people about sorting items. |
13:17 |
|
ryan |
we want to have items sort by date desc when it's a serial |
13:17 |
|
ryan |
currently you can test against biblio.serial |
13:17 |
|
ryan |
but then that does the table join on serials module |
13:18 |
|
ryan |
he's loading in items , but not filling serials table. |
13:19 |
|
ryan |
I'd like to have a way to specify that it's a serial publication, but it's not controlled by serials module |
13:19 |
|
ryan |
so it can sort nicely |
13:20 |
|
ryan |
currently the serial flag is set either by biblio.serial or if there's a series title, i think. |
13:21 |
|
hdl |
MMM... |
13:22 |
|
ryan |
i guess it's not a big deal to do the table join even if there's no subscription |
13:22 |
|
hdl |
We were asked by one of our customer not to display items in biblio when it is a serial. |
13:22 |
|
ryan |
yes, there are many ways to manage. |
13:22 |
|
hdl |
Then users have to go to serial collection to see the "items". |
13:23 |
|
ryan |
that makes sense when there are many copies. |
13:23 |
|
hdl |
And of course it is displayed in order. |
13:23 |
|
hdl |
We could add there informations about items (location, and availability) |
13:25 |
|
ryan |
it gets messy with the duplicated information. |
13:25 |
|
ryan |
it makes sense to only list it once. |
16:05 |
|
slef |
Hi - is there anyone who understands matching rules online? |
16:10 |
|
gmcharlt |
slef: for bib import? yes |
16:11 |
|
slef |
Does length in the matching rule configuration do anything? |
16:11 |
|
slef |
I've read C4::Matcher and it looks like no |
16:11 |
|
slef |
but there's a FIXME but no corresponding bug |
16:13 |
|
gmcharlt |
slef: yes, it does do something (see _get_match_keys) but only for fixed fields |
16:14 |
|
gmcharlt |
intent was to have length apply only to fixed field positions |
16:14 |
|
slef |
ah, it's linked to normalization rule? |
16:15 |
|
slef |
In short, is Length: 0 and Normalization rule: ISBN a problem? |
16:15 |
|
gmcharlt |
effectively - for fixed field, use offset and length to extract only the component of interest |
16:15 |
|
gmcharlt |
slef: should not be a problem |
16:15 |
|
slef |
gmcharlt: is zero-length some sort of magic value? |
16:16 |
|
gmcharlt |
slef: for a matchpoint on a subfield, offset and length are currently ignored |
16:16 |
|
gmcharlt |
only apply for tags < 010 |
16:16 |
|
slef |
ok, so this is a UI bug? |
16:17 |
|
gmcharlt |
could be construed as such - only display the offset and length fields if the entered tag is < 010 |
16:17 |
|
slef |
ok, will report |
16:19 |
|
slef |
kohabug 2243 |
16:19 |
|
slef |
(for the logs) |
16:19 |
|
slef |
Thanks for your help with that. |
16:20 |
|
gmcharlt |
you're welcome |
16:24 |
|
atz |
gmcharlt: how does "incremental" barcode calculation know how many digits to apply? |
16:25 |
|
atz |
i.e. 00001 vs. 00000000000001 |
16:25 |
|
atz |
since the field is varchar(20) |
16:27 |
|
gmcharlt |
atz: what's the context? autoBarcode? |
16:27 |
|
atz |
yeah, it's one of the autoBarcode functions |
16:27 |
|
atz |
perhaps the rule is in mysql default? |
16:28 |
|
atz |
i.e., it lets mysql try to autoincrement |
16:28 |
|
atz |
? |
16:28 |
|
slef |
see cataloguing/value_builder/barcode.pl:108 |
16:28 |
|
slef |
it's not mysql |
16:29 |
|
atz |
yeah, i've seen that |
16:29 |
|
slef |
so it's the length of the barcode field in the html |
16:29 |
|
atz |
it doesn't answer my question though |
16:29 |
|
gmcharlt |
doesn't look like it's doing zero-padding |
16:30 |
|
slef |
how doesn't it? |
16:30 |
|
atz |
slef: rather, it shows it doesn't control the zero-pads there |
16:32 |
|
atz |
pretty cheesy though that we don't have any way of knowing the next barcode without executing a value_builder that returns javascript :\ |
16:33 |
|
slef |
easiest way would be for "next" to be a special value in the cataloguing form that the database fills out at INSERT time |
16:33 |
|
slef |
IMO |
16:34 |
|
slef |
but I hate javascript, you know. |
16:34 |
|
atz |
i hate this js in particular. |
16:34 |
|
gmcharlt |
. |
16:36 |
|
slef |
atz: is it definitely zero-padded in the database? |
16:36 |
|
atz |
it might just be the dataset I have |
16:37 |
|
atz |
i haven't tested catalogue *input* that much |
16:38 |
|
gmcharlt |
atz: I think it's your dataset |
16:38 |
|
gmcharlt |
fresh DB, new item with barcode 456 |
16:38 |
|
gmcharlt |
turned on autoBarcode = incremental |
16:38 |
|
gmcharlt |
next barcode assigned was 457 |
16:38 |
|
atz |
ok, cool by me |
16:39 |
|
atz |
gmcharlt: now add 000458 |
16:39 |
|
atz |
and the next one is? probably "459" |
16:39 |
|
gmcharlt |
correct |
16:40 |
|
slef |
mmm, we're stripping lead zeros |
16:40 |
|
gmcharlt |
as I would expect from the way the code is written |
16:40 |
|
atz |
yeah, it's just a ++ |
16:41 |
|
slef |
only library I've spotted from my datasets that uses consistent-length barcodes so far is one that uses the ISBN because it has max 1 copy of each |
16:41 |
|
slef |
(no, they don't have a trained librarian...) |
16:42 |
|
slef |
not ISBN... EAN or UPC... I've forgotten which it is on the cover |
16:42 |
|
gmcharlt |
slef: so none use 14-digit codabar barcodes? (not sure if codabar was ever widely adopted in the UK, of course) |
16:42 |
|
atz |
need to do: $x=len($val); $newval = sprintf("%$x.$xd",$val+1); |
16:42 |
|
slef |
gmcharlt: if they do, they might have special shortcodes for non-circulating items |
16:42 |
|
slef |
(which would stop them circulating, after all) |
16:43 |
|
gmcharlt |
slef: at least until somebody adds item-lookup-by-title at the circ screen, as somebody was suggesting on koha |
16:44 |
|
slef |
gmcharlt: I'll let them deal with that when it comes! |
19:02 |
|
slef |
Isn't it always the way? Patch emailed anyway. |
19:10 |
|
gmcharlt |
self: diagnostics don't hurt |
23:37 |
|
chris |
interesting |
23:37 |
|
chris |
> Sometimes I use Explorer, sometimes I use firefox, but my access to Koha is |
23:37 |
|
chris |
> direct, not through a web browser. |
23:37 |
|
chris |
wonder how they are managing that :) |
23:56 |
|
gmcharlt |
ethernet jack at the base of the skull? |
00:05 |
|
chris |
heh |
08:23 |
|
mc |
hello world |