IRC log for #koha, 2007-03-09

Today | Search | Index

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

Today | Search | Index

koha1