All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 13:58 | paul | kados around ? |
| 06:56 | et hop, une nouvelle version de Koha publiée... | |
| 06:56 | 2.2.8 | |
| 07:07 | kados | paul++ |
| 07:07 | paul: were modifs made to 2.2.8 that aren't in rel_2_2? | |
| 07:07 | paul | hi kados |
| 07:07 | no, unless i'm silly | |
| 07:07 | kados | paul: congratulations on the new member of the family :-) |
| 07:08 | paul | thanks. |
| 07:08 | kados | paul: is Mathew (spelling?) home now? |
| 07:08 | paul | Matthieu in french? |
| 07:08 | kados | thx |
| 07:08 | paul | and yes, he's at home : they were back 3 days after the birth |
| 07:08 | kados | great |
| 07:08 | so all the kids have been cooing over him I'm sure :-) | |
| 07:08 | paul | not so great : a little bit too early according to sandrine... |
| 07:09 | kados | ahh |
| 07:09 | paul | the nice things is that's it holiday for childrens last week and this one |
| 07:09 | so we have everybody home. | |
| 07:09 | kados | very nice |
| 07:09 | paul | fortunatly, sandrine mother is here for those 2 weeks. |
| 07:10 | that's why I can work ;-) | |
| 07:10 | kados | hehe |
| 07:10 | paul | do you (LL) have something to commit on rel_3_0 ? |
| 07:11 | did you see my question on koha-devel, about the move to HEAD ? | |
| 07:11 | kados | yes, I did |
| 07:11 | and it's a great idea | |
| 07:11 | paul | (/me posted a lot of things on koha-devel yesterday...) |
| 07:11 | kados | we have some testing results |
| 07:11 | but nothing is ready to commit yet besides what we already committed | |
| 07:11 | so feel free to move it | |
| 07:12 | paul | OK, i'll do it tomorrow I think |
| 07:12 | kados | paul++ |
| 07:12 | paul | something to look at :http://o9.bureau.paulpoulain.com/ui/main.xul |
| 07:12 | OpenCataloger v0.2 ;-) | |
| 07:12 | kados | wow, nice |
| 07:12 | wow, very nice :-) | |
| 07:13 | paul | (encoding problem + save does not work. otherwise, it should work at least enough to be considered as beta stage) |
| 07:13 | about 3.0 : are you happy with the tests you did ? | |
| 07:13 | (the result of the tests ;-) ) | |
| 07:13 | kados | hehe |
| 07:13 | some things we are very happy about | |
| 07:14 | others may need some tweaks | |
| 07:14 | paul | only "tweaks" ? it's a very good news... |
| 07:14 | kados | there are two major problems with rel_3_0 for our customers |
| 07:14 | 1. NZ customers want de-duplicated records like Koha 1.0 | |
| 07:15 | paul | de-duplicated ? |
| 07:15 | kados | 2. US customers need item-level circulation rules |
| 07:15 | meaning biblio, biblioitem, item | |
| 07:15 | (point 1) | |
| 07:15 | paul | ah, ok. this is a very very large problem i'm afraid. |
| 07:15 | and, to say the truth, I don't know how to achieve this... | |
| 07:15 | kados | I think point #1 will have to wait for the metarecord |
| 07:15 | paul | point 2 will be from far easier... |
| 07:16 | kados: ++ | |
| 07:16 | kados | so hopefully it's an add-on for 3.2 or something |
| 07:16 | but point #2 is critical for US customers | |
| 07:16 | paul | do you know how to solve it ? |
| 07:16 | kados | and it's the first thing chris will be working on April 1 |
| 07:16 | :-) | |
| 07:16 | paul | (i have ideas) |
| 07:17 | kados | we have a poor solution for dev_week |
| 07:17 | I would prefer a better implementation for 3.0 | |
| 07:17 | paul | - issuing rules can be defined for itemtypes + freely (for each borrower category) |
| 07:18 | - default issuing rules for an item is the actual itemtype depending rule | |
| 07:18 | - a new field (items.specificissuingrule) can be attached to any item | |
| 07:18 | thus, libraries that don't need item level issuing rules have nothing to do | |
| 07:18 | and libraries that want just have to activate the "specificissuingrule" field in MARC editor. | |
| 07:18 | kados | hmmm |
| 07:19 | that doesn't quite capture the expectation in the US i think | |
| 07:19 | paul | (the last question being where do we store the specificissuingrule in MARC...) |
| 07:19 | what does they expect ? | |
| 07:19 | kados | I think in the US they expect to have 'circulationcode' at the item level |
| 07:19 | so you have a biblio: | |
| 07:19 | Harry Potter | |
| 07:20 | with itemtype at the record level that says 'material type', maybe 'content' and 'audience' | |
| 07:20 | then, at the item level you have a circulation code that says 'rules for circ' | |
| 07:20 | this is how 99% of US ILSes work | |
| 07:21 | and it's been a big problem for NPL since they switched to Koha | |
| 07:21 | paul | yes, that's what i propose (or I missed something...) |
| 07:21 | kados | esp since they want to have 1 biblio that has circulating and reference records attached |
| 07:22 | but I think we need a new matrix | |
| 07:22 | besides itemtype one | |
| 07:22 | paul | yep, that's what I meaned for : issuing rules can be defined for itemtypes + freely (for each borrower category) |
| 07:22 | kados | what do you mean by 'freely' |
| 07:23 | paul | I think having a biblio-level issuing rule is still interesting for simplicity. |
| 07:23 | kados | sure |
| 07:23 | paul | having a itemlevel issuing rule is interesting for completness |
| 07:23 | thus, having both is interesting... | |
| 07:23 | kados | right |
| 07:24 | paul | if an issuing rule is defined for a given itemtype => it applies by default for every item |
| 07:24 | kados | so will they both use itemtypes table? or will we create a new table for circcodes? |
| 07:24 | paul | we will create a new table. that CAN contain itemtype codes |
| 07:26 | kados | it can contain itemtype codes? |
| 07:26 | why not contain only its own codes? | |
| 07:27 | I think the typical expectation is that itemtypes are for searching and ccodes are for circ (noone will want to search by ccode) | |
| 07:27 | paul | To keep the possibility to have itemtype level issuing rules |
| 07:28 | (on phone) | |
| 07:30 | kados | paul: http://kados.org/stuff/ccodes_itemtypes.sql |
| 07:30 | paul: is that what you mean to have? | |
| 07:44 | paul | kados : back. |
| 07:45 | what i'm thinking could be : | |
| 07:45 | issuingrules table : | |
| 07:45 | - issuingcode char(10) | |
| 07:45 | - borrowercategory char(10) | |
| 07:45 | - days int | |
| 07:45 | - quantity int | |
| 07:45 | in the issuingprocess : | |
| 07:45 | chris | i think we need lower than days paul |
| 07:46 | paul | hi chris. ok for hours if you prefer ;-) |
| 07:46 | in items table a new row : issuingrule | |
| 07:46 | chris | yeah i think lots of academic libraries do hourly periods |
| 07:46 | paul | during issuing process : |
| 07:46 | kados | yep, good point chris |
| 07:47 | paul | - is there an items.issuingrule ? |
| 07:47 | yes => OK, get it | |
| 07:47 | no => is there a issuincode = itemtype of this item ? | |
| 07:47 | yes => use is | |
| 07:47 | s/is/it/ | |
| 07:47 | no => we have a problem, impossible to know what to do | |
| 07:47 | does that sound more clear ? | |
| 07:48 | that would change strictly nothing for actual behaviour | |
| 07:48 | and add an item level behaviour | |
| 07:49 | kados | so both biblioitems.itemtype and items.issuingrule would use itemtypes table? |
| 07:49 | for values I mean | |
| 07:49 | ? | |
| 07:50 | paul | no, items.issuingrules would use only issuingrules.issuingcode |
| 07:51 | the issuingrules.issuingcode field contains any value (itemtype or not. actually it's only itemtype) | |
| 07:51 | if the issuincode = itemtype => it's an itemtype level rule | |
| 07:51 | otherwise => it's an item level rule | |
| 07:52 | chris | well its nearly midnight here, and ill need to wake up again in a few hours to feed kahurangi, so i might head to bed |
| 07:53 | ill read the log in the morning | |
| 07:53 | paul | the item level rule having priority to itemlevel |
| 07:53 | chris | cya's |
| 07:53 | paul | the item level rule having priority to itemtype |
| 07:53 | cya's | |
| 07:53 | kados | chris: night |
| 07:53 | paul | good night |
| 07:53 | kados | paul: I will give it some thought |
| 07:53 | paul: perhaps we can discuss it again soon | |
| 07:53 | paul | ok |
| 07:54 | good night too | |
| 07:54 | kados | g'night |