Time Nick Message 02:26 chris Afternoon 02:26 druthb hi, chris! :D 08:52 brendan_l @wunder 93109 08:52 munin brendan_l: The current temperature in K6LCM - Westside / Mesa, Santa Barbara, California is 5.5�C (12:51 AM PST on January 09, 2011). Conditions: Clear. Humidity: 95%. Dew Point: 5.0�C. Windchill: 6.0�C. Pressure: 29.96 in 1014.4 hPa (Steady). 08:53 druthb @wunder 20852 08:53 munin druthb: The current temperature in Woodley Gardens, Rockville, Maryland is -6.4�C (3:50 AM EST on January 09, 2011). Conditions: Clear. Humidity: 55%. Dew Point: -14.0�C. Windchill: -10.0�C. Pressure: 29.83 in 1010.0 hPa (Steady). 08:54 brendan_l hi druthb 08:55 druthb howdy. :D 09:43 * chris wanders by before sleep 09:44 * druthb waves to chris 09:46 brendan_l heya chris 12:18 cait hi #koha 12:40 fredericd hi cait! 12:40 cait hi fredericd :) 12:41 fredericd do you use overdue_notices.pl script? 12:43 cait not yet, but I have tested it a lot 12:43 cait our libraries all want to use fines and notices 12:43 fredericd with satisfaction? 12:43 cait I hope the first library wll start next eek 12:43 cait hm, it works 12:44 cait but some things don't work as I would like them to work 12:44 cait part of it is that we expect it to work differently 12:44 cait it does not respect the calendar - fines.pl does 12:44 cait that means that sometimes with holidays you will send out notices on holidays and before a fine as created on the account 12:45 cait I don't like that much 12:45 fredericd I can't make it properly handle claim cycle 12:45 cait claim cycle? 12:45 cait the interval? 12:45 fredericd in the code, you're correct, this script doesn't use calendar at all 12:46 cait yeah, I think it should - like fines.pl does 12:46 fredericd yes, interval as defined in Tool > Overdues triggers 12:46 cait or make it a choice, but it should be possible 12:46 cait ah, it's not really an interval 12:46 cait but the days between due date and notice 12:46 cait I got that working, but don't have my notes here. 12:46 cait the first value must be 1 or bigger 12:46 fredericd yes, that't what I call an interval 12:47 cait ah sorry 12:47 cait you are right 12:47 cait interval made me think about the value in the smart rules 12:47 fredericd There is another bug with claim cycle regarding the position in the cycle 12:47 cait can you explain? 12:48 fredericd Say that a borrower has two overdues: One has already been claimed, the other must be claimed for the first time 12:48 cait ah 12:48 cait no 12:49 cait it will not do that 12:49 fredericd the email sent will be for a first claim, grouping both items 12:49 cait I think it's only checking for the oldest due date 12:49 cait hm 12:49 cait but I would have expected it to be a second claim 12:49 fredericd me too but it isn't 12:50 fredericd this script is doing to many things 12:50 cait hm that's strange 12:50 cait yep 12:50 cait talked to chris about it 12:50 cait but needs a rewrite 12:50 fredericd I'm not sure it conceptually possible to group claim in a unique email 12:50 cait a little to big of a project for me 12:50 fredericd (for email claims of course) 12:51 cait what we ould like to see is different emails 12:51 cait group all 1st together sent 12:51 cait group all second together sent 12:51 fredericd imo a separate email should be sent for each overdue item 12:51 cait even if they are on the same date 12:51 cait perhaps not for each item - but for those that are on the same date 12:51 fredericd yes, you correct, grouping by number of overdue days 12:51 cait group them together by the same due date 12:52 cait I don't like much how koha works here 12:52 fredericd But then, you face another limitation of this script 12:52 fredericd it's no possible to format (a little bit) data extracted from items 12:53 cait hm there are 2 ways at the moment 12:53 fredericd in your notice, you juste have a iems.content placeholder 12:53 cait you can use <<items.content>> and define the fields tab separated as command line option 12:53 cait it's an option of the overdue_notices script 12:54 cait and you can use the <item></item> syntax and even display the fine amount and define the fields from items in there 12:54 fredericd Yes, but you can't have somethink like: Call Number: items.itemcallnumber 12:54 cait you can I think with the <items></items> syntax 12:54 fredericd intersting... 12:54 cait I tried that once, but don't have access to my data at the moment 12:55 cait it's in an email folder I can't access from home 12:55 fredericd ok 12:55 fredericd I don't see that in the code... 12:55 cait the code was from chris_n I think 12:56 fredericd I see it... 12:56 cait perhaps I can find the commit for you 12:56 fredericd thanks! 12:56 cait ah ok 12:56 cait np 12:56 cait if someone else uses that script... perhaps it will lead to some improvement ;) 12:57 cait I have to look at it this year, but my perl knowledge is still a bit limited... takes me a long time to figure things out 12:59 fredericd I rewrite it for doing just claims by emails 12:59 fredericd the existing was too confusing 12:59 fredericd and my customer is multi-branch libary with specific needs 13:00 cait so you plan to use an alternate script for them? 13:00 cait how will you handle those without email addresses? 13:00 fredericd yes 13:00 fredericd there is always an email address in this situation 13:01 fredericd and the need to be able to switch to SMS notifications 13:01 fredericd they need 13:01 cait I think that ould be something more people would like 13:01 cait an ability to choose on borrower level im notices go out as letter, mail or sms 13:02 cait at the moment it's one for all, depending on the existance of the email address only 13:03 fredericd And you may have to handle subtilities like who send the claim: library from which the issue has be done, borrower home branch, item branch... 13:13 cait yeah 13:13 cait I think homeorholdingbranch and such prefs are supposed to handle that 13:13 cait but not sure they really do 13:14 cait we have only one multibranch library - but they are not live yet 13:14 cait so until now it as not a problem 13:15 fredericd homeorholdingbranch is not used in overdue_notices.pl 13:17 cait hm. probably to be expected 13:17 cait this script needs a rewrite 13:17 cait and we need a proper spec probably before we do that 13:17 cait so that there is a consensus how it should work 13:18 fredericd yes 13:19 fredericd for example, for me, the possibily to modify claim cycle depending of item type is useless 13:20 fredericd sorry no item type but borrower category 13:31 cait hm 13:31 cait not fur us - sorry for the belated answer 13:31 cait it's common that you send different notice texts to teachers and students 13:31 cait often teachers get no fines, while students do 13:32 cait so the wording of the notices is different 13:32 cait but the current possibilites are not flexible enough 13:32 cait for example we have regular loans 28 days and short loans 13:33 cait for the 28day loans we want to send out weekly notices 13:33 cait for the short loans this is too long 13:33 cait a separate claiming process would be needed 13:33 cait or a possibility to define rules... for item types and borrower types and such... 13:33 cait not sure how that would work 13:34 cait fredericd: it needs a lot of thought - and fines.pl has some glitches too 13:35 fredericd what we would need is claim rules base on a combinaison of branch, 13:35 fredericd borrower category, item type and number of days of overdue. 13:36 fredericd now in Koha we don't have the item type parameter 13:38 cait fredericd: that sounds right to me 13:39 cait hi druthb :) 13:40 druthb hiya. :D 13:40 fredericd hi druthb 13:41 fredericd druthb: Do you have an opinion on overdue_notices.pl 13:41 fredericd it's a survey... cait kindly responded 13:42 cait :) 13:42 cait it's one of my biggest concerns with koha 13:43 druthb overdue_notices.pl is (IMO) better put together than advance notices, but it could probably still use a lot of love. 13:43 cait I appreciate every thought spend on this topic 13:44 druthb the trigger-mode is relatively nifty, and works pretty well for most US-ish libraries, but I understand from cait that German libraries don't do things quite the same way. 13:45 fredericd I also have French and international libraries who complain... 13:45 druthb It does contain many US-centric asssumptions about the process. If there was a way to internationalize it with a plugin or more-general things, that would be good. 13:46 cait I think the whole process is pretty much centered on one way to do it 13:46 cait there are options, but they don't work well 13:46 cait like fine intervals 13:46 druthb I do not think that more tight integration with fines.pl and long_overdue.pl is a good idea; I *like* that those are three separate things. long_overdue.pl needs to be dumped and start completely over. 13:47 fredericd generalisation means also complexification 13:48 druthb yes, unfortunately, it does. 13:48 fredericd thats' why charging fines must be separated from claiming 13:48 cait I think to keep them separated is ok - but have an option to use data from the other if needed. like keep a fine count somewhere to determine if it's a 1st 2nd or 3rd notice to be sent 13:48 druthb I'd keep as much of it as possible configurable in the staff client, too. having the notices forms and triggers there is very good. 13:49 fredericd druthb: I have an alternative claiming script which works pretty well, dealing with item type as a parameter 13:49 fredericd but there is no WUI 13:50 druthb I just had an idea on a more-generalized fines structure, that would let you do what USians do, *or* what I understand the German libraries do. It's a very young idea, and rough. But I'll make some notes on it, and see if I can make it grow. 13:51 cait perhaps we could work out a spec on the wiki? 13:52 fredericd It's not easy to share on such a thing design 13:52 fredericd IRC or mailing list are not good places 13:52 druthb What if you had a fines_rules table that let you define a *series* of events post-overdue, like this "wait six days, then charge $1.00. Then wait four more days, and charge another $2.00. Then charge $0.10 for every day after that, until maxfine, or the item is marked lost, or returned." 13:52 fredericd and wiki... 13:53 cait I think that should ork 13:53 cait the current grace period definition is bad 13:53 druthb Most US libraries would use a single step: "Charge 0.10 every day until maxfine, lost, or returned." 13:53 cait your table would work for us 13:54 fredericd we should avoid to implement it in MySQL table 13:54 druthb Then hook that rule to the itemtype/borrowercat/item branch combination,like the circ rules. 13:54 cait fredericd: I think the configuration must be stored in the database - separating from loan matrix seems quite ok here for me. It's already separated in pars. 13:54 cait druthb: that sounds great to me 13:55 cait would also allow for different rules for short and long term loans 13:55 druthb That table would only get called during fines.pl runs, or when being edited. 13:55 cait you would have to have some additional settings It hink 13:55 cait like use/ignore calendar 13:56 fredericd It must be stored in the DB of course, but not as a collection of rows 13:56 druthb yep. That would be a checkbox on the fine_rule: "do you charge fines on closed days?" 13:56 cait and how grace period is supposed to work - don't start fines process until grace period is over / charge fines for grace period after its over 13:56 fredericd we need a more complex data structure more tighted to the process 13:56 druthb I'm thinking store the events-sequence in XML in a single cell. Each fine rule would be one row. 13:57 cait where is the problem with having rows? 13:57 fredericd druthb: yes, or YAML, or so directly parsed into a data structure driving the process 13:57 druthb Storing the events as rows means keeping them in order could get painful; you'd need a nexttag-lasttag pair to traverse the list, as fields in the rows. 13:57 druthb that would work. 13:57 fredericd cait: take a look at overdue_notices.pl 13:58 cait fredericd: looking there gives me a headache - but not much understanding ;) 13:58 cait only asking to learn 13:58 fredericd most of the code is spent requesting table of claiming rules 13:59 fredericd it's a design nosense 13:59 fredericd sooner or later the code break 13:59 druthb In the implementation we're describing, you'd yank that table in once, at the first, keyed on the rule name, and not have a bunch of mess trying to chase down which rule to use. 14:00 cait ok 14:00 fredericd pure question of software engineering... 14:00 cait fredericd: it's interesting for me - I want to learn 14:00 druthb yah; you could do it either way, and the algorithm would be the same, but doing it in a single row makes the implementation a lot tidier. 14:01 fredericd the code slim down drasticaly and is much more maintenable 14:04 druthb If you built the structure right, you could easily set it up where you could even state this: "wait 10 days, and charge $1.00, and send a notice, then wait 14 days, and send a second notice, then wait 5 more days, and charge $2.00, then charge $0.10 every day thereafter, until marking lost on the 45th day, charging the borrower for the book." 14:05 druthb so with a proper way of describing those things, you *could* integrate the overdue-management into one script. 14:06 fredericd druthb: I like the idea! 14:06 fredericd if you could wrap up a XML file defining those rules, it would be great 14:06 fredericd a sample XML file 14:06 druthb I do too. The management interface will need a little thought, of course, so that it's not too painful. 14:07 fredericd I would be pleased to do the claiming/charging script 14:07 fredericd Someone else could code the user interface 14:08 druthb I have a vague idea of how I'd go about it, fredericd. Both scripts would revolve around what that rules table looks like, and how that XML is phrased. 14:09 cait I would be pleased to do a lot of testing 14:09 druthb :) We'd need that, for sure. :) 14:09 cait perhaps can do a bit of work on the interface... but the other things are probably a bit over my head 14:09 druthb collaboration++ 14:11 fredericd I can't agree more. You cait and druthb come with considerations I hadn't in mind 14:11 druthb My free time is rather limited right now, fredericd, but I should have time to put together some notes on the data structures as I envision them. Would what we describe work for the other international users that you've heard from? 14:12 jcamins_a Errr... clarify for me... why an XML file? 14:12 cait hi jcamins :) 14:13 jcamins_a Good morning. 14:13 druthb jcamins: You'd actually store it in YAML in the table, but XML is a person-friendlier way of describing that. 14:13 jcamins druthb: okay, that's what I was going to say should be done. 14:13 fredericd yes. We already have a solution since it was a requirement from them. But from that point, a generalisation seems very possible 14:14 druthb OK. For a next step, how about I create an RFC page on the wiki, describing the algorithm and data structures as I foresee it, and we can refine from there? 14:14 druthb Remember, all my expertise is US-ian, so I fully expect that I've missed something in this idea. 14:14 cait druthb++ 14:15 cait I could try to add how we suppose it to work 14:15 cait like a use case? 14:15 druthb cait++ 14:15 cait so us-ians could agree/disagree (probably disagree) and check if it would work for them too 14:15 druthb Use cases from other nations/ways-of-doing would be good, even if only to check to make sure that the scheme will work. 14:15 cait or just describe how it should work 14:15 fredericd druthb: An RFC would be great. We could collectively polish based on our specific requiremetns 14:16 druthb It may take me a few days to put something together; I am going out of town tomorrow early, and won't be back until Thursday late. Busy trip. 14:17 cait I will keep this log save and remind you ;) 14:18 druthb Thanks, cait. 14:18 druthb fredericd: Aren't you glad you asked your survey question? 14:19 fredericd yeah 14:19 cait me too :) 14:19 fredericd I think I have to open more often my IRC screen... 14:20 cait yep 14:20 fredericd I propose a new Koha position for cait: good ideas safeguard 14:20 cait so I could tell you that I really appreciate your work as translation manager :) 14:20 cait lol 14:20 fredericd cait: and your feedback on translation is very important 14:21 druthb You and I have not talked much in the past, fredericd--of course, no one seems to want to translate Koha into Texan English, so we wouldn't need to. ;-) 14:22 cait hi hdl :) 14:22 fredericd hi hdl 14:22 druthb hi, hdl. :) 14:23 hdl hi all 14:23 fredericd hdl: what about a survey on Koha overdues claiming and fines charging... 14:23 druthb hehehehe 14:23 hdl what is your purpose ? 14:24 fredericd cait and druthb have a lot of good ideas on how to improve the process 14:24 fredericd first: do you have to complain on how the process works in Koha now? 14:24 fredericd does overdues_process.pl works for you? 14:25 hdl overdue_notices.pl is working quite well now. 14:26 hdl Problem is that it is what it does not really integrated with letters. 14:26 hdl So that for instance it is not enqueing mails for the librarian. 14:26 fredericd don't you have sometime on the same email 2 items: one for a 1st claim and one for a 2nd? 14:27 fredericd don't you need to have claim cycle based on item type rather than borrower categories? 14:27 hdl I donot think so. But all our pathces have not been pushed. 14:28 hdl most of our libraries donot ask for such claim cycle 14:28 hdl They ask for a library based claiming cycle though 14:29 hdl i.e. per library, per patron categorie, per delay 14:29 cait hdl: I think it uses the message_queue 14:29 fredericd yes of course and it's already here 14:29 fredericd (library bases cycles) 14:29 hdl cait: not for html letters or csv 14:29 cait hdl: you are right - the letters need to be split up - sorry for the misunderstanding 14:30 cait hdl: having them all in one blob in the message_queue is a nightmare for reporting 14:31 hdl i am rather skeptikal on a survey... 14:31 hdl Since many libraries are not really following the wiki or any list. 14:31 fredericd it's a manner of speaking... 14:31 hdl and would require to translate the whole stuff and have librarians follow that. 14:32 fredericd and not for librarians but for vendors/implemntors 14:34 hdl It seems that the process at the moment is show me your code, and test, and then decide rather than Forecast and share design, decide, write tests and then have good code. 14:35 cait hm not entirely true I think 14:35 cait there are specs on the wiki like short loans from sekjal 14:35 cait so there is some movement to change that 14:35 hdl not entirely false either. 14:35 cait have not said that :) 14:35 cait just that there are some other examples too 14:36 cait and what we were talking about it gathering ideas from different people 14:36 cait and have a spec on the wiki 14:36 fredericd the difficulties is to find parties interested and having time so share on specific subjects 14:36 fredericd to share 14:38 hdl having specs with no implementors might lead to neverending process since things are so tight related at the moment 14:38 cait I think having a spec would be the first step 14:39 cait and start implementing it / raising funds if necessary after that 14:39 hdl maybe you could start with what koha **actually** does now.... And state what you want it to do. 14:45 cait I think that can be part of the idea gathering 15:02 cait @wunder Konstanz 15:02 munin cait: The current temperature in Taegerwilen, Taegerwilen, Germany is 6.6�C (4:00 PM CET on January 09, 2011). Conditions: Scattered Clouds. Humidity: 98%. Dew Point: 6.0�C. Windchill: 7.0�C. Pressure: 29.98 in 1015.1 hPa (Steady). 15:06 druthb @wunder 20852 15:06 munin druthb: The current temperature in Woodley Gardens, Rockville, Maryland is -4.4�C (10:05 AM EST on January 09, 2011). Conditions: Clear. Humidity: 50%. Dew Point: -13.0�C. Windchill: -8.0�C. Pressure: 30.01 in 1016.1 hPa (Rising). 15:06 druthb Harrrumph! 15:07 cait it's warm, but grey sky 15:07 cait I would prefer a chilly sunny winter day 15:20 cait ok, time to learn for my distance study 15:20 cait see you all later :) 15:21 druthb see ya! 15:51 magnus kia ora #koha 15:51 druthb hi, magnus! :D 15:51 magnus hiya druthb 15:56 munin New commit(s) kohagit: Bug 5480 Some usual UNIMARC cataloguing plugins doesn't work anymore <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=86df2d1efabe410be00748d1ba8ad63566392e3e> 16:00 hudsonbot Starting build 269 for job Koha_Master (previous build: SUCCESS) 16:02 cait hi magnus :) 16:03 magnus hi cait 16:23 hudsonbot Project Koha_Master build #269: SUCCESS in 23 min: http://hudson.koha-community.org/job/Koha_Master/269/ 16:23 hudsonbot Fr?d?ric Demians: Bug 5480 Some usual UNIMARC cataloguing plugins doesn't work anymore 16:24 hudsonbot Starting build 270 for job Koha_Master (previous build: SUCCESS) 16:26 munin New commit(s) kohagit: Fix for Bug 4984, Invalid XHTML in staff client search results <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=1b344bdbd1475efa0bb4f919521ed3ee0e86874b> / Additional fix for Bug 3550, Use GetRecordValue to get the subtitle <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=05c240953a7989af72c461bd9e2e37bac0fe2a66> 16:29 magnus woohoo 16:48 hudsonbot Project Koha_Master build #270: SUCCESS in 23 min: http://hudson.koha-community.org/job/Koha_Master/270/ 16:48 hudsonbot Owen Leonard: Additional fix for Bug 3550, Use GetRecordValue to get the subtitle 16:48 hudsonbot Starting build 271 for job Koha_Master (previous build: SUCCESS) 17:11 hudsonbot Project Koha_Master build #271: SUCCESS in 23 min: http://hudson.koha-community.org/job/Koha_Master/271/ 17:11 hudsonbot Owen Leonard: Fix for Bug 4984, Invalid XHTML in staff client search results 18:36 chris Morning 18:39 cait hi chris 18:42 * cait waves to magnus 18:43 * magnus waves back t ocait and the rest of #koha 18:43 magnus s/t ocait/to cait/ 18:45 cait @wunder Konstanz 18:45 munin cait: The current temperature in Taegerwilen, Taegerwilen, Germany is 7.0�C (7:45 PM CET on January 09, 2011). Conditions: Mostly Cloudy. Humidity: 92%. Dew Point: 6.0�C. Windchill: 7.0�C. Pressure: 30.03 in 1016.8 hPa (Steady). 18:45 magnus hot! 18:45 magnus @wunder bodo, norway 18:45 munin magnus: The current temperature in Bodo, Norway is -1.0�C (7:20 PM CET on January 09, 2011). Conditions: Mostly Cloudy. Humidity: 60%. Dew Point: -8.0�C. Windchill: -9.0�C. Pressure: 29.18 in 988 hPa (Steady). 18:46 cait yeah, strange winter 18:57 chris_n @later tell sekjal work on html label output is very much a wip and so an utter mess atm albeit a basically working mess :-) 18:57 munin chris_n: The operation succeeded. 19:05 chris morning 19:07 * cait waves to chris 19:09 chris hiya cait 19:10 druthb hi, chris. :) 19:10 chris hiya druthb 19:12 magnus ata marie, chris 19:12 chris heya magnus 19:19 chris_n heya chris 19:19 chris hey chris_n have a good break? 19:19 chris_n yup... just too short :) 19:22 magnus hi jwagner 19:22 * druthb waves to jwagner, and offers her a cookie. 19:27 * jwagner gobbles cookie :-) 19:27 jwagner hi folks 19:29 cait hi jwagner 19:30 druthb !hudson botsnack cookie 19:30 hudsonbot druthb: thanks a lot! om nom nom. how did you know that cookie is my favorite food? 19:33 cait cookiesẞ 19:33 cait ? 19:33 * druthb offers cait a cookie 19:33 chris first day of the open source academy today 19:34 magnus cool! 19:34 cait aw 19:34 * cait takes the cookie 19:34 cait what are they going to do? 19:35 chris first week is all lessons 19:36 chris today is a welcome, and they get a laptop to install ubuntu on .. then in the afternoon, talks about freedom 19:36 chris tomorrow is how the web works, then in the afternoon, one fo the sysadmins is teaching 'my first server' 19:36 chris then html/css/js .. and databases, then php, git, perl, graphics 19:36 chris and thats end of the week 19:37 chris next week they work on projects, i have about 8 working on unit testing for koha 19:37 chris and a class trip to weta to see where open source stuff is being used 19:37 cait I wish I could spend my week like that! 19:38 cait sounds like a lot of fun :) 19:39 magnus it sure does! 19:40 jwagner I'd sure like the Weta visit :-) 20:07 munin New commit(s) kohagit: Bug 5589: Remove duplicated Exports in Suggestions.pm <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=d1172b98d9a2b8dde3c700b0d116816b4d45fa26> 20:15 hudsonbot Starting build 272 for job Koha_Master (previous build: SUCCESS) 20:27 munin New commit(s) kohagit: Merge remote branch 'kc/new/bug_5240' into kcmaster <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=a75a9264e19fe658f475c8a8ee40e0b1ca53dbd2> / Merge remote branch 'kc/new/bug_5186' into kcmaster <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=c0441ebbfb547507cda86c8c05575d88761045e1> / Merge remote branch 'kc/new/bug_4838' into kcmaster <http://git.koha-community.org/gitweb/?p=koha.git;a=co 20:38 hudsonbot Project Koha_Master build #272: SUCCESS in 23 min: http://hudson.koha-community.org/job/Koha_Master/272/ 20:38 hudsonbot Colin Campbell: Bug 5589: Remove duplicated Exports in Suggestions.pm 20:39 hudsonbot Starting build 273 for job Koha_Master (previous build: SUCCESS) 20:40 chris wb druthb 20:41 druthb thanks! 20:56 * cait waves to druthb 20:58 cait need duct tape? 21:02 hudsonbot Project Koha_Master build #273: SUCCESS in 23 min: http://hudson.koha-community.org/job/Koha_Master/273/ 21:02 hudsonbot * Owen Leonard: Fix for Bug 5240 - next link hidden on edit subfields 21:02 hudsonbot * Robin Sheat: Bug 5186 - allow tax rates to be set to zero (master) 21:02 hudsonbot * Fr?d?ric Demians: Bug 4838 Allow to choose which authority heading to copy into biblio record 21:02 hudsonbot * Owen Leonard: Fix for Bug 5560 - pagination option for lists 21:42 cait good night all 21:49 jwagner See you tomorrow.... 22:17 Brooke kia ora 22:17 druthb hi, Brooke! :) 22:17 Brooke :) 22:32 chris http://computerworld.co.nz/news.nsf/news/schools-in-for-open-source-advocates 22:33 * Brooke waves at ronald 22:43 robin I kinda want to hack the computerworld servers and make their app extention '.nsfw' 22:46 Brooke naughty. 23:15 * Brooke waves at chilts