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