← Previous day | Today | Search | Index
All times shown according to UTC.
| Time | 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 | But it was a good experience. | |
| 13:08 | And it was great to meet Dan Scott again. | |
| 13:08 | Is rch around ? | |
| 13:08 | ryan | hi hdl |
| 13:09 | hdl | hi ryan |
| 13:09 | 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 | 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 | no, not recently. | |
| 13:12 | 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 | And that was a good step. | |
| 13:14 | 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 | hdl: I just got a question from one of our data people about sorting items. | |
| 13:17 | we want to have items sort by date desc when it's a serial | |
| 13:17 | currently you can test against biblio.serial | |
| 13:17 | but then that does the table join on serials module | |
| 13:18 | he's loading in items , but not filling serials table. | |
| 13:19 | 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 | so it can sort nicely | |
| 13:20 | 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 | We could add there informations about items (location, and availability) | |
| 13:25 | ryan | it gets messy with the duplicated information. |
| 13:25 | 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 | I've read C4::Matcher and it looks like no | |
| 16:11 | 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 | intent was to have length apply only to fixed field positions | |
| 16:14 | slef | ah, it's linked to normalization rule? |
| 16:15 | 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 | 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 | 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 | kohabug 2243 | |
| 16:19 | (for the logs) | |
| 16:19 | 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 | i.e. 00001 vs. 00000000000001 | |
| 16:25 | 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 | perhaps the rule is in mysql default? | |
| 16:28 | i.e., it lets mysql try to autoincrement | |
| 16:28 | ? | |
| 16:28 | slef | see cataloguing/value_builder/barcode.pl:108 |
| 16:28 | 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 | 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 | IMO | |
| 16:34 | 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 | i haven't tested catalogue *input* that much | |
| 16:38 | gmcharlt | atz: I think it's your dataset |
| 16:38 | fresh DB, new item with barcode 456 | |
| 16:38 | turned on autoBarcode = incremental | |
| 16:38 | next barcode assigned was 457 | |
| 16:38 | atz | ok, cool by me |
| 16:39 | gmcharlt: now add 000458 | |
| 16:39 | 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 | (no, they don't have a trained librarian...) | |
| 16:42 | 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 | (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 | Isn't it always the way? Patch emailed anyway. | |
| 19:10 | gmcharlt | self: diagnostics don't hurt |
| 23:37 | chris | interesting |
| 23:37 | > Sometimes I use Explorer, sometimes I use firefox, but my access to Koha is | |
| 23:37 | > direct, not through a web browser. | |
| 23:37 | 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 |
← Previous day | Today | Search | Index