← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 00:57 | druthb joined #koha | |
| 00:59 | druthb left #koha | |
| 01:03 | ronald joined #koha | |
| 01:29 | ronald left #koha | |
| 02:08 | druthb joined #koha | |
| 02:26 | chris | Afternoon |
| 02:26 | druthb | hi, chris! :D |
| 04:09 | Nate joined #koha | |
| 04:28 | Nate left #koha | |
| 04:50 | saorge left #koha | |
| 04:51 | saorge joined #koha | |
| 06:13 | davi left #koha | |
| 06:15 | druthb left #koha | |
| 06:15 | davi joined #koha | |
| 07:13 | druthb joined #koha | |
| 07:22 | ibot left #koha | |
| 07:22 | hudsonbot left #koha | |
| 07:23 | hudsonbot joined #koha | |
| 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 |
| 10:31 | druthb left #koha | |
| 12:07 | wasabi joined #koha | |
| 12:18 | cait joined #koha | |
| 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 | 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 | hm, it works | |
| 12:44 | but some things don't work as I would like them to work | |
| 12:44 | part of it is that we expect it to work differently | |
| 12:44 | it does not respect the calendar - fines.pl does | |
| 12:44 | that means that sometimes with holidays you will send out notices on holidays and before a fine as created on the account | |
| 12:45 | 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 | 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 | ah, it's not really an interval | |
| 12:46 | but the days between due date and notice | |
| 12:46 | I got that working, but don't have my notes here. | |
| 12:46 | 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 | you are right | |
| 12:47 | 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 | no | |
| 12:49 | 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 | hm | |
| 12:49 | but I would have expected it to be a second claim | |
| 12:49 | fredericd | me too but it isn't |
| 12:50 | this script is doing to many things | |
| 12:50 | cait | hm that's strange |
| 12:50 | yep | |
| 12:50 | talked to chris about it | |
| 12:50 | 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 | group all 1st together sent | |
| 12:51 | 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 | 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 | I don't like much how koha works here | |
| 12:52 | fredericd | But then, you face another limitation of this script |
| 12:52 | 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 | it's an option of the overdue_notices script | |
| 12:54 | 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 | it's in an email folder I can't access from home | |
| 12:55 | fredericd | ok |
| 12:55 | 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 | np | |
| 12:56 | if someone else uses that script... perhaps it will lead to some improvement ;) | |
| 12:57 | 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 | the existing was too confusing | |
| 12:59 | 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 | how will you handle those without email addresses? | |
| 13:00 | fredericd | yes |
| 13:00 | there is always an email address in this situation | |
| 13:01 | and the need to be able to switch to SMS notifications | |
| 13:01 | they need | |
| 13:01 | cait | I think that ould be something more people would like |
| 13:01 | an ability to choose on borrower level im notices go out as letter, mail or sms | |
| 13:02 | 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 | I think homeorholdingbranch and such prefs are supposed to handle that | |
| 13:13 | but not sure they really do | |
| 13:14 | we have only one multibranch library - but they are not live yet | |
| 13:14 | 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 | this script needs a rewrite | |
| 13:17 | and we need a proper spec probably before we do that | |
| 13:17 | so that there is a consensus how it should work | |
| 13:18 | fredericd | yes |
| 13:19 | for example, for me, the possibily to modify claim cycle depending of item type is useless | |
| 13:20 | sorry no item type but borrower category | |
| 13:31 | cait | hm |
| 13:31 | not fur us - sorry for the belated answer | |
| 13:31 | it's common that you send different notice texts to teachers and students | |
| 13:31 | often teachers get no fines, while students do | |
| 13:32 | so the wording of the notices is different | |
| 13:32 | but the current possibilites are not flexible enough | |
| 13:32 | for example we have regular loans 28 days and short loans | |
| 13:33 | for the 28day loans we want to send out weekly notices | |
| 13:33 | for the short loans this is too long | |
| 13:33 | a separate claiming process would be needed | |
| 13:33 | or a possibility to define rules... for item types and borrower types and such... | |
| 13:33 | not sure how that would work | |
| 13:34 | 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 | borrower category, item type and number of days of overdue. | |
| 13:36 | now in Koha we don't have the item type parameter | |
| 13:38 | cait | fredericd: that sounds right to me |
| 13:39 | druthb joined #koha | |
| 13:39 | cait | hi druthb :) |
| 13:40 | druthb | hiya. :D |
| 13:40 | fredericd | hi druthb |
| 13:41 | druthb: Do you have an opinion on overdue_notices.pl | |
| 13:41 | it's a survey... cait kindly responded | |
| 13:42 | cait | :) |
| 13:42 | 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 | there are options, but they don't work well | |
| 13:46 | 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 | 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 | 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 | 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 | druthb: that sounds great to me | |
| 13:55 | 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 | 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 | 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 | only asking to learn | |
| 13:58 | fredericd | most of the code is spent requesting table of claiming rules |
| 13:59 | it's a design nosense | |
| 13:59 | 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 | 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 | if you could wrap up a XML file defining those rules, it would be great | |
| 14:06 | 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 | 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 | jcamins_a is now known as jcamins | |
| 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 | 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 | I could try to add how we suppose it to work | |
| 14:15 | 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 | 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 | 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 | hdl joined #koha | |
| 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 | first: do you have to complain on how the process works in Koha now? | |
| 14:24 | does overdues_process.pl works for you? | |
| 14:25 | hdl | overdue_notices.pl is working quite well now. |
| 14:26 | Problem is that it is what it does not really integrated with letters. | |
| 14:26 | 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 | 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 | most of our libraries donot ask for such claim cycle | |
| 14:28 | They ask for a library based claiming cycle though | |
| 14:29 | 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 | (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 | 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 | 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 | there are specs on the wiki like short loans from sekjal | |
| 14:35 | so there is some movement to change that | |
| 14:35 | hdl | not entirely false either. |
| 14:35 | cait | have not said that :) |
| 14:35 | just that there are some other examples too | |
| 14:36 | and what we were talking about it gathering ideas from different people | |
| 14:36 | 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 | 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 | 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 | @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 | I would prefer a chilly sunny winter day | |
| 15:20 | ok, time to learn for my distance study | |
| 15:20 | see you all later :) | |
| 15:21 | druthb | see ya! |
| 15:44 | magnus joined #koha | |
| 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/[…]1ba8ad63566392e3e> |
| 16:00 | hudsonbot | Starting build 269 for job Koha_Master (previous build: SUCCESS) |
| 16:02 | cait | hi magnus :) |
| 16:03 | magnus | hi cait |
| 16:07 | hdl left #koha | |
| 16:23 | hudsonbot | Project Koha_Master build #269: SUCCESS in 23 min: http://hudson.koha-community.o[…]/Koha_Master/269/ |
| 16:23 | Fr?d?ric Demians: Bug 5480 Some usual UNIMARC cataloguing plugins doesn't work anymore | |
| 16:24 | 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/[…]9521ed3ee0e86874b> / Additional fix for Bug 3550, Use GetRecordValue to get the subtitle <http://git.koha-community.org/[…]d9e2e37bac0fe2a66> |
| 16:29 | magnus | woohoo |
| 16:48 | hudsonbot | Project Koha_Master build #270: SUCCESS in 23 min: http://hudson.koha-community.o[…]/Koha_Master/270/ |
| 16:48 | Owen Leonard: Additional fix for Bug 3550, Use GetRecordValue to get the subtitle | |
| 16:48 | Starting build 271 for job Koha_Master (previous build: SUCCESS) | |
| 17:11 | Project Koha_Master build #271: SUCCESS in 23 min: http://hudson.koha-community.o[…]/Koha_Master/271/ | |
| 17:11 | Owen Leonard: Fix for Bug 4984, Invalid XHTML in staff client search results | |
| 17:34 | magnus left #koha | |
| 18:17 | druthb left #koha | |
| 18:36 | chris | Morning |
| 18:37 | magnus joined #koha | |
| 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 | @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:53 | druthb joined #koha | |
| 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:03 | davi left #koha | |
| 19:03 | davi joined #koha | |
| 19:05 | chris | morning |
| 19:07 | * cait | waves to chris |
| 19:08 | davi left #koha | |
| 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:19 | jwagner joined #koha | |
| 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 | ? | |
| 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 | today is a welcome, and they get a laptop to install ubuntu on .. then in the afternoon, talks about freedom | |
| 19:36 | tomorrow is how the web works, then in the afternoon, one fo the sysadmins is teaching 'my first server' | |
| 19:36 | then html/css/js .. and databases, then php, git, perl, graphics | |
| 19:36 | and thats end of the week | |
| 19:37 | next week they work on projects, i have about 8 working on unit testing for koha | |
| 19:37 | 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 | sounds like a lot of fun :) | |
| 19:39 | magnus | it sure does! |
| 19:40 | jwagner | I'd sure like the Weta visit :-) |
| 20:05 | druthb left #koha | |
| 20:07 | munin | New commit(s) kohagit: Bug 5589: Remove duplicated Exports in Suggestions.pm <http://git.koha-community.org/[…]0d116816b4d45fa26> |
| 20:15 | hudsonbot | Starting build 272 for job Koha_Master (previous build: SUCCESS) |
| 20:18 | davi joined #koha | |
| 20:27 | munin | New commit(s) kohagit: Merge remote branch 'kc/new/bug_5240' into kcmaster <http://git.koha-community.org/[…]8ee40e0b1ca53dbd2> / Merge remote branch 'kc/new/bug_5186' into kcmaster <http://git.koha-community.org/[…]c05575d88761045e1> / Merge remote branch 'kc/new/bug_4838' into kcmaster <http://git.koha-community.org/[…]/?p=koha.git;a=co |
| 20:38 | hudsonbot | Project Koha_Master build #272: SUCCESS in 23 min: http://hudson.koha-community.o[…]/Koha_Master/272/ |
| 20:38 | Colin Campbell: Bug 5589: Remove duplicated Exports in Suggestions.pm | |
| 20:39 | Starting build 273 for job Koha_Master (previous build: SUCCESS) | |
| 20:40 | druthb joined #koha | |
| 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.o[…]/Koha_Master/273/ |
| 21:02 | * Owen Leonard: Fix for Bug 5240 - next link hidden on edit subfields | |
| 21:02 | * Robin Sheat: Bug 5186 - allow tax rates to be set to zero (master) | |
| 21:02 | * Fr?d?ric Demians: Bug 4838 Allow to choose which authority heading to copy into biblio record | |
| 21:02 | * Owen Leonard: Fix for Bug 5560 - pagination option for lists | |
| 21:16 | darling joined #koha | |
| 21:40 | magnus left #koha | |
| 21:42 | cait | good night all |
| 21:42 | cait left #koha | |
| 21:49 | jwagner | See you tomorrow.... |
| 21:50 | jwagner left #koha | |
| 22:17 | Brooke joined #koha | |
| 22:17 | Brooke | kia ora |
| 22:17 | druthb | hi, Brooke! :) |
| 22:17 | Brooke | :) |
| 22:32 | chris | http://computerworld.co.nz/new[…]-source-advocates |
| 22:32 | ronald joined #koha | |
| 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. |
| 22:57 | chilts left #koha | |
| 23:15 | chilts joined #koha | |
| 23:15 | * Brooke | waves at chilts |
| 23:19 | Brooke left #koha | |
| 23:20 | druthb left #koha |
← Previous day | Today | Next day → | Search | Index