18:22:02 <slef> #startmeeting 18:22:02 <huginn> Meeting started Thu Sep 15 18:22:02 2011 UTC. The chair is slef. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:22:02 <huginn> Useful Commands: #action #agreed #help #info #idea #link #topic. 18:22:04 <cait> last time we created the document 18:22:06 <cait> altogether 18:22:10 <slef> #chair cait Brooke 18:22:10 <huginn> Current chairs: Brooke cait slef 18:22:28 <cait> not sure we can make that work agai nfor us 18:22:39 <slef> ok, is that what's on the wiki? 18:22:41 <cait> probably need more of a chat this time - but we could still use the tool 18:22:47 <sekjal> #info last meeting's document found at: http://typewith.me/3gYf6ozqf4 18:22:53 <slef> #topic Introductions 18:23:05 <slef> please introduce yourself with #info if you want to be recorded 18:23:17 <sekjal> #info Ian Walls, ByWater Solutions, Koha 3.6 QA Manager 18:23:37 <libsysguy> #info Elliott Davis, University of Texas at Tyler, Developer 18:23:43 <cait> hm 18:23:43 <slef> #info MJ Ray, software.coop, delaying dinner because this stuff's important, you know? 18:23:57 <cait> #info Katrin Fischer 18:24:21 <slef> ok, late entrants can intro themselves later 18:24:34 <slef> #topic What we want to cover this meeting 18:24:50 <slef> so sekjal has pasted a link to something 18:25:04 <slef> it's not loading for me... I'm just going to kick browser permissions to try to see it... 18:25:12 <libsysguy> right the link to the collaboration document 18:25:23 <Brooke> #link http://typewith.me/3gYf6ozqf4 18:25:49 <cait> I thought it was on the wiki too, but can't find it right now 18:25:55 <libsysguy> it was there 18:25:56 <Brooke> the wiki was revolting 18:26:02 <libsysguy> but the other day I checked and it was gone 18:26:06 <Brooke> it kept handling things like i was editing a template 18:26:11 <Brooke> so chris moved stuff 18:26:19 <slef> #link http://wiki.koha-community.org/wiki/Notifications_RFC 18:26:25 <Brooke> but really, someone should fix the forkin wiki 18:26:27 <slef> is what I saw 18:26:41 <cait> that's the document that was started from the mailing list thread 18:26:48 <cait> the typewithme is from our first meeting 18:27:04 <slef> Brooke: I think I'm compelled to say about all mediawiki problems: I told you so. ;-) 18:27:14 <Brooke> http://wiki.koha-community.org/wiki/Messaging_rewrite_RFC 18:27:16 <libsysguy> so in this meeting we are supposed to start planning the steps right? 18:27:35 <slef> that seems like a good idea 18:27:47 <sekjal> I'm looking at data structure first 18:28:04 <libsysguy> did you say you had that on a whiteboard sekjal? 18:28:18 <sekjal> I'm drawing it on the one on my wall behind my desk 18:28:31 <libsysguy> haha you need one of those smartboards 18:28:31 <cait> hm 18:28:34 <sekjal> yes 18:28:35 <cait> make us a phoot? 18:28:38 <cait> photo... 18:28:41 <slef> http://imgur.com/ or similar? 18:28:52 <libsysguy> because I am having trouble seeing the one on your desk 18:29:09 <cait> I know what you mean,might need new glasses 18:29:10 <cait> ;) 18:29:12 <libsysguy> or we could huddle in G+ and watch sekjal on his webcam 18:29:12 <sekjal> I could turn on my webcam, but... then you'd see the rest of my horrible office 18:29:23 <slef> #link http://wiki.koha-community.org/wiki/Messaging_rewrite_RFC 18:29:23 * cait chants webcam webcam.. 18:29:39 * libsysguy joins cait's chat....webcam webcam... 18:30:18 <slef> [off] http://media.rightmove.co.uk/77k/76325/19937445/76325_APW0418_IMG_06_0000_max_620x414.JPG 18:30:28 <slef> there I've showed you mine, now you show me yours 18:30:49 <slef> magnus_away: we can seeeeee you 18:31:37 <slef> So which came first? The Notifications RFC, then the Messaging_rewrite_RFC? 18:31:42 <libsysguy> yes 18:31:45 <cait> correct 18:31:58 <cait> i think the second should have most points from the first 18:32:06 * Brooke nods. 18:32:27 <Brooke> I was gonna link them, and initially both were on the same page, but like I said, stuff got moved. 18:33:18 <sekjal> okay, so we've got some key pieces of the puzzle to link together 18:33:40 <slef> #topic Planning the steps to implement this 18:34:29 <sekjal> we've got the various kinds of messages we want to send (overdue, due, hold placed, claim, etc etc) 18:34:53 <sekjal> and we want to be able to have different templates for those messages depending on several factors 18:35:05 <sekjal> {itemtype, branchcode,patroncategory} 18:35:39 <sekjal> messages can also be delivered in several ways: print, email, SMS, RSS, etc 18:35:54 <sekjal> each deliver method can support 1 or more message formats 18:36:18 <cait> to make it more complicated we might want to fall back from one to the other 18:36:26 <Brooke> cait++ 18:36:28 <sekjal> the formats so far are HTML, plaintext, RSS/XML, and short-message 18:36:29 <cait> no mobile numbe > send email > no email > create print 18:36:48 <Brooke> rank by patron preference, perhaps? 18:37:29 <sekjal> we could save ourselves some complexity, and fuse message format with delivery method 18:37:45 <cait> hm 18:37:47 <sekjal> since RSS is always RSS/XML 18:37:51 <sekjal> SMS is always shortmessage 18:37:53 <cait> what about email? should be plan or html 18:38:01 <sekjal> ^^ 18:38:27 <sekjal> same with print 18:38:34 <sekjal> though I'd lean more on HTML for print 18:38:40 <cait> def 18:38:49 <Brooke> hmmm 18:38:53 <Brooke> it'd have to print nicely 18:38:53 <cait> but email makes sense in plain and html (although I always prefere plain) 18:39:07 <cait> print should have options to add corporate design 18:39:11 <cait> logos, footer, header 18:39:14 * Brooke nods. 18:39:15 <cait> so html is a good way to go for that 18:39:19 <sekjal> do we think this is something people would want to decide on globally? 18:39:23 <Brooke> no 18:39:24 <sekjal> like, system preference level? 18:39:29 <Brooke> I think this is a pizza topping 18:39:34 <cait> decide about? 18:39:35 <sekjal> all emails are plain, or all emails are HTML, per install? 18:39:40 <cait> hm 18:39:41 <Brooke> no 18:39:43 <Brooke> not even that 18:39:47 <Brooke> for my overdue notices 18:39:50 <Brooke> I'd want plain 18:39:57 <Brooke> for my flash fundraising stuff, might want html. 18:40:01 <cait> Brooke: really not so sure about that 18:40:06 <Brooke> although 18:40:09 <cait> couldn't we make it an option in the notice templates? 18:40:10 <Brooke> if we default to plain 18:40:14 <Brooke> I can always be sneaky 18:40:17 <Brooke> and just link stuff. 18:40:20 <slef> I think that's fine for an option, but it's plain at the mo, isn't it? 18:40:28 <cait> like give it a subject, give it an email address to be sent from and check html or not? 18:40:50 <libsysguy> from a design perspective whats the difference between html and plain 18:41:01 <Brooke> for a test, we've to ensure that the email address in reply to is the right one in parameters. 18:41:22 <sekjal> libsysguy: WYSIWYG editor 18:41:33 <slef> Would someone go through http://wiki.koha-community.org/wiki/Messaging_rewrite_RFC and bold which ones already exist? I'm happy to take a first crack, but I'll probably miss some. 18:42:01 <cait> slef: I had marked soem of them with a * 18:42:06 <libsysguy> why not enable the wysiwyg editor by default...if its plain text just render it as such? 18:42:16 <libsysguy> maybe im just being naive about it 18:42:23 <Brooke> the new ones are * on the initial document 18:42:27 <cait> libsysguy: you can't do bold and such tihngs in plain, might get confusing 18:42:35 <slef> libsysguy: people screw up and use only colour or styling to indicate things. 18:42:41 <cait> yep 18:42:46 <cait> hi Oak 18:42:55 <cait> but why not have a flag on the notice to indicate? 18:42:58 <cait> the format? 18:43:00 <slef> libsysguy: which they shouldn't, because that's bad for accessibility too (red-green colour-blind for example) 18:43:01 <Oak> hello cait 18:43:09 <Oak> hello #koha 18:43:13 <libsysguy> gotcha 18:43:15 <slef> cait / Brooke: so are * the new ones or the current ones? 18:43:22 <cait> see my note below ;) 18:43:23 <Brooke> line 50 says new 18:43:32 <sekjal> if we're including a flag or an option, we're losing any benefits of merging format and delivery method 18:43:36 <sekjal> unless 18:43:37 <cait> new 18:43:45 <sekjal> we have two email delivery methods: plain, and HTML 18:43:52 <Oak> loud hello to Brooke 18:43:53 <slef> hi Oak. Welcome to the meeting. #info if you want to be noted in the minutes. 18:43:58 * Brooke hugs Oak. 18:43:59 <Oak> oops 18:44:07 <Oak> it's a meeting. will shut up now 18:44:19 <cait> sekjal: hm, is this so bad? 18:44:19 <slef> it's a chaos 18:44:26 <cait> having html and plain mail? 18:44:57 <slef> Brooke: ok, I see that line now. That wasn't clear to me on first reading. 18:45:09 <sekjal> so, when in the notices editor creating a new notice: 18:45:37 <sekjal> you'd have the options for format: "email-plain, email-HTML, print (HTML), SMS, RSS" 18:45:57 <sekjal> choice of format would inform the editor on any restrictions/tools to include 18:46:48 <Brooke> *nod* and theoretically call the printer on the carpet. 18:47:24 <slef> So am I right in thinking the later sections don't have *s? 18:47:38 <slef> OK with everyone if I take a run through those? 18:47:57 <cait> slef: correct 18:48:01 <Brooke> please do, and double check the wiki I know I edited some out accidentally. 18:48:06 <cait> we didn't get far tidying it up 18:48:15 <cait> I will mark them now for oyu 18:48:53 <sekjal> okay: so message templates would have major characteristics: itemtype, branchcode, patron category, format 18:49:11 <sekjal> oh, and type 18:49:20 <libsysguy> yes ^^ 18:49:51 <cait> hm 18:49:54 <cait> i was thinking 18:49:58 <cait> have the rules apart 18:50:01 <cait> from the templates 18:50:06 * Brooke nods. 18:50:09 <cait> so you can reuse a template 18:50:16 <cait> for different combinatons 18:50:31 <sekjal> good point 18:50:39 <cait> like have one overdue to sent to all borrowers, but different overdues for professors and students 18:51:04 <libsysguy> so like the circ rules 18:51:06 <cait> keep template characteristics specific to the text 18:51:22 <cait> libsysguy: similar, yes, but perhaps with a nicer gui :) 18:51:30 <sekjal> so just format and type 18:51:32 <sekjal> makes sense 18:51:44 <Brooke> nicer guis++ 18:51:47 <sekjal> use rules elsewhere 18:51:58 <libsysguy> aww I wanted all text everyhing :'( 18:52:01 <cait> sekjal: perhaps even a code for the hardcoded things? like module now 18:52:07 <cait> oh 18:52:13 <libsysguy> jk 18:52:37 <cait> if we put how something is triggered into the rules 18:52:46 <cait> how do we indicate which placeholders can be used in a template? 18:52:55 <sekjal> that would be a function of "type" 18:53:05 <slef> OK, I've tried to update http://wiki.koha-community.org/wiki/Messaging_rewrite_RFC#Meeting_Document_from_8_September_2011 and put *s on new types and formats. Did I get it right? 18:53:09 <sekjal> all Overdues would have access to the same variables 18:53:38 <cait> slef: we could use the typewithme and put that on the wiki later? 18:54:11 <Brooke> it's on the thinger 18:54:19 <cait> slef: sms is possible already 18:54:34 <slef> cait: oh yeah. I thought I deleted that 18:54:36 <slef> cait: :( typewithme eats my battery. 18:54:40 <cait> ok 18:54:43 <slef> cait: you remove or shall I? 18:54:48 <cait> can you? 18:54:53 <slef> removing 18:55:12 <cait> thx 18:55:17 <slef> done 18:55:25 <cait> ok 18:55:27 <cait> so type format 18:55:29 <sekjal> so, right now, when creating a new message, you specific what Module it's in 18:55:38 <cait> where format also indicates the delivery type 18:55:46 <cait> hm 18:55:53 <sekjal> and that gives you access to various tables 18:55:59 <sekjal> what about 18:56:01 <sekjal> instead 18:56:31 <sekjal> you specify an SQL query to per message type to get you the variables you want? 18:57:07 <sekjal> and that SQL lived in a Report 18:57:14 * Brooke pukes. 18:57:41 <Brooke> that's okay for advanced users 18:57:54 <Brooke> but is incredibly hostile for other types, if I'm grokin' ye 18:57:59 <slef> sekjal: how would the SQL query work? Wouldn't that need its own placeholders, which would vary by which module it's in, or at least which type of object it's working on? 18:58:26 <sekjal> Brooke: we'd include default reports that include all the tokens we include now 18:58:33 <cait> some kind of primary key , yes 18:58:48 <Brooke> default features++ 18:58:59 <cait> sekjal: I kind of like the idea to make it more flexible 18:59:02 <cait> for example fines 18:59:11 <cait> i could make it sum things 18:59:16 <sekjal> slef: the template would be called with whatever key parameters make sense in it's context 18:59:23 <cait> using sql functions,not dpeenidng on the system to do it the way I want it too 18:59:24 <cait> to 18:59:51 <cait> but it would need a way to make clear which pk is to be used... 18:59:57 <slef> I think this is another enhancement for later? 19:00:08 <cait> pehaps a phase 2 thing yes... 19:00:13 <cait> but still something I would really love to see 19:00:16 <Brooke> a lot of this is enhancement and phased 19:00:31 <Brooke> I think it's important to honour what we want while we move on the stuff y'all need NAO 19:00:41 <slef> sekjal: do you think this would still work if we move to DBIx or whatever it's called? 19:00:42 <cait> ok 19:00:50 <cait> so we have a desired structure for templates now 19:00:51 <sekjal> slef: I don't know 19:00:56 <cait> that will kill a lot of the tables in there right now 19:01:13 <cait> because koha has already very complicated structures in place for delivery types and messaging 19:01:16 <slef> oh yeah, it's worth mentioning... just I've 1001 questions on it which probably don't need asking just now 19:01:43 <slef> So what are the phases? Is that written anywhere yet? 19:01:45 <cait> no 19:01:52 <cait> not yet 19:01:56 <cait> I think talking about structures is first 19:02:08 <cait> and then making small sets to be developed as patches? 19:02:31 <cait> and be aware of what we want it to do late to not make it hard to enhance 19:02:45 * Brooke nods. 19:03:12 <slef> sure 19:03:18 <sekjal> I doubt we'll come out of this meeting with a complete roadmap, but a few steps closer is acceptable to me 19:03:36 <sekjal> is it acceptable to say 19:03:37 <sekjal> that 19:03:40 * cait nods 19:03:51 <slef> We've also a structure for how we get what to put into the templates. So any other structures we need? 19:03:58 <sekjal> each message type should pull in a specific set of usable variables? 19:05:01 <cait> yes 19:05:05 <cait> and consistent this time plz 19:05:09 <cait> from the beginning 19:05:16 <sekjal> phrase another way: does it make sense to have message type and 'module' as separate things? 19:05:29 <cait> hm 19:05:32 <cait> perhaps not 19:05:40 <cait> as long as message type is not unique 19:05:46 <slef> Why not? 19:05:55 <cait> why not unique? 19:06:03 <slef> why no sense? 19:06:06 <cait> oh 19:06:14 <cait> perhaps not necessary 19:06:17 <sekjal> can an overdue notice be anything but a Circulation module notice? 19:06:20 <cait> but might make it easier to organize 19:06:55 <cait> or prone to false inputs 19:06:57 <slef> sekjal: it could be an email scheduled, or a screen notice triggered on checkout and checkin, couldn't it? 19:07:23 <sekjal> slef: I mean, in the Notices editor, there is a dropdown to select Module 19:07:39 <sekjal> and that's what determines what tokens/variables/database fields you can put into the template 19:07:44 <cait> but type would already indicate the module 19:07:58 <cait> and choose the fields 19:08:26 <slef> I thought type was delivery type? 19:08:39 <Brooke> do we want a preview box someplace so we can see what all will be pulled? 19:08:45 <slef> let's keep the jargon straight please people! ;-) 19:08:49 <sekjal> sorry, slef 19:08:58 <sekjal> message templates 19:09:18 <sekjal> have message types (overdue, checkin, predue, holds place, etc) 19:09:26 * slef has gin now (it's 8pm here), so may be more easily confused than usual. 19:09:33 <cait> Brooke: you can't preview without giving it a borrower or something - I think it's not really necessary 19:09:44 <sekjal> and formats (email-plain, email-HTML, print, SMS, etc) 19:10:01 <slef> sekjal: those seem to be called messages in the new RFC. 19:10:27 <sekjal> yeah, that's how we originally labeled them last meeting 19:11:07 <sekjal> message type informs the available database fields for the message template 19:11:22 <sekjal> every overdue notice will have access to the same fields 19:11:35 <slef> please stop using type or I'll get confused again... so the question is: can the same message appear in multiple modules? 19:11:53 <sekjal> I'm proposing getting rid of modules 19:12:20 <cait> slef: for the messages we have spoken about - I think no 19:12:34 <slef> By the looks of the design, I think it makes sense to relegate them to headings in the messages list. 19:12:34 <cait> so voting to go for the simpler version now 19:12:36 <cait> no modules 19:12:45 * slef just checks the current source 19:13:00 <cait> sekjal: the table will also need subject and perhaps description 19:13:06 <sekjal> cait: yes 19:13:10 <cait> and a pk 19:13:12 <cait> of course 19:13:22 <cait> or? 19:13:27 <sekjal> those are free text and 3NF design bits, respectively 19:13:31 <sekjal> very necessary 19:13:39 <cait> ok 19:13:47 <cait> so we have that mapped out now 19:14:03 <cait> now, we will have things where triggers are hardcoded 19:14:04 <cait> like for holds 19:14:19 <cait> but we need other things with more options 19:14:21 <cait> like overdues 19:14:25 <cait> or predues 19:14:32 <sekjal> right, we've got two kinds of message triggers 19:14:40 <cait> can we get that into 1 additional table? or do we need another structure? 19:14:45 <sekjal> event-based (checkin, checkout, hold placed, hold confirmed, etc) 19:14:52 <sekjal> and scheduled 19:15:06 <cait> overdues - event or scheduled? 19:15:17 <cait> the event is book gets overdue - but it's more a time based thing probably 19:15:18 <Brooke> both 19:15:22 <Brooke> which is tricky 19:15:24 <sekjal> scheduled at this point 19:15:27 <cait> ok 19:15:36 <Brooke> should be pre overdue triggers notice 19:15:42 <Brooke> actual overdue triggers a notice 19:15:50 <Brooke> end of month accounting might nag yet again. 19:16:05 <sekjal> the trigger is "our cronjob ran to see what's overdue, and here're the messages" 19:16:07 <Brooke> then > collection over X $ 19:16:11 <slef> could scheduled be just events (queuerun,hourly,dayhour,nighthour,...)? 19:16:41 <sekjal> slef: yes 19:17:05 <sekjal> we'd just need some thing to cause those events (cron, daemon, etc) 19:17:08 <libsysguy> sorry guys for going silent 19:17:14 <libsysguy> i had to take care of something 19:17:53 <sekjal> this is much like the fines discussion earlier today, actually 19:17:55 <sekjal> much like it 19:18:05 <libsysguy> uh oh 19:18:05 <slef> I think book dueness events are just strange events, triggered by another event (a search triggered by the queuerun or daily event which looks for books going that much due) 19:18:11 <libsysguy> looks like i came back just in time 19:18:33 <slef> sekjal: heh. A fine is a type of message. 19:18:34 * slef runs 19:18:46 <sekjal> slef: well.... yeah 19:18:50 <sekjal> in a way 19:19:07 <cait> ok 19:19:12 <cait> only wanted to get that sorted in :) 19:19:21 <cait> I think this is good so far 19:19:38 <cait> sekjal: do you have a structure in mind for the triggers? 19:19:48 <cait> the scheduled triggers (I should clarify this) 19:20:22 <sekjal> well, scheduled or event based should probably both call the same subroutine to populate the message template with real data 19:20:34 <sekjal> that means a) choosing the right template, based on our rules 19:20:52 <sekjal> b) passing the appropriate primary keys for the contextually-correct objects 19:21:02 <Brooke> is there summat clever y'all can do to prevent someone from being sent a message too often within a certain timeframe? Like an array that checks v chron or summat? 19:21:18 <sekjal> c) adding the completed notice to the message_queue 19:21:28 <slef> event_id int, event varchar(16), function text, template_id int references templates.template_id 19:21:56 <slef> I'm sure that's a security disaster waiting to happen. 19:23:12 <slef> at very least, function would need whitelisting 19:23:13 <sekjal> right now, steps a), b) and possibly c) are done each time a message event happens 19:23:13 <rangi> morning 19:23:28 <Brooke> morena 19:23:36 <cait> morning rangi 19:23:53 <Brooke> Kei te pehea koe? 19:24:02 <sekjal> how could we pass the right keys to an arbitrary notice.... hmmmm...... 19:24:18 <slef> rangi: where's my microUSB cable hiding? 19:24:38 <rangi> in the couch? 19:24:40 <cait> check under the bad? 19:24:42 <cait> bed 19:24:43 <cait> ... sorry 19:25:01 <cait> sekjal: I am not sure I can follow all that 19:25:01 <libsysguy> slef refridgerator 19:25:03 <cait> let me reread 19:25:41 <cait> hm 19:25:46 <cait> sounds ok to me so far 19:25:53 <cait> not sure about slefs security concerns though 19:26:20 <slef> I found a different one in the cupboard. All is well 19:26:57 <slef> sekjal: by having the event say what function fuels it. See above. Maybe add a column for report_id if you want to use the reports table? 19:27:46 <sekjal> slef: ah, I'm seeing it, now 19:27:48 <sekjal> took a second 19:28:02 <slef> sekjal: yeah, clarity is not my strong point right now. 19:28:15 <cait> ah 19:29:09 <slef> Brooke: if the outgoing messages are being logged in koha, a sending action could check the log to make sure it isn't sending too often. 19:29:27 <Brooke> excellent :) 19:29:37 * Brooke can't help but picture teh angry Patrons. 19:29:49 * slef can and is laughing. Is that wrong? 19:29:57 <sekjal> well, choosing which message template to retrieve doesn't involve passing keys 19:30:15 <sekjal> need itemtype/patroncategory/branchcode (maybe) 19:30:22 <cait> hmm 19:30:26 <sekjal> and message type, of course 19:30:37 <sekjal> and message format, taken from patron preferences 19:30:38 <cait> but that also would make a lot of repeated entries 19:30:46 <cait> when setting up things i mean 19:30:56 <slef> sekjal: I'm seeing function as an arbitrary something like C4::Notification::SendOverdueToPatron 19:31:27 <slef> rangi: c'mon, are you horrified yet? 19:31:37 <cait> he is hiding 19:31:55 <cait> but perhaps that's ok 19:32:13 <cait> I think we have to rethink the way message preferences work 19:32:19 <cait> for patrons 19:32:19 * rangi is happy this is SEP 19:32:25 <cait> SEP? 19:32:25 <wahanui> SEP is probably similar daylight to March. 19:32:36 <rangi> someone elses problem 19:32:41 <Brooke> wahanui forget SEP 19:32:41 <wahanui> Brooke: I forgot sep 19:32:42 <cait> are we that bad? 19:33:16 <rangi> Hehe nope but its not 3.6 so im low on caring :) 19:33:19 <slef> rangi: what's the right way to extend core actions? My brian isn't working just now. 19:33:24 <slef> Or brain even. 19:34:18 <cait> what we are talking abou tnow will kill existing structures 19:34:20 * sekjal just needs to be exorbitantly wealthy, so he can fly everyone interested in working on this to the same location, and provide whiteboards, snacks/beer and comfy sofas 19:34:35 <libsysguy> ^^ 19:34:39 <cait> the messaging tables are quite a bit complicated, but could be extended I guess 19:34:45 <rangi> id start again 19:34:50 <Brooke> sekjal++ 19:34:59 <rangi> in the Koha:: namespace 19:35:11 <sekjal> oh, and remember: 19:35:17 <rangi> then cutover when done 19:35:34 <sekjal> whatever database structure changes we wind up making, we have to be able to port over everyone's existing notices into the new structures 19:35:38 <sekjal> seamlessly 19:35:55 <libsysguy> oh yes...i keep forgetting that 19:36:07 <sekjal> no regressions allowed 19:36:10 <libsysguy> and there frequency structure 19:36:58 <rangi> yep port and equally important clean up what is now deprecated 19:37:16 <slef> sekjal: can you fix my health too please? 19:37:34 <slef> ok, sorry folks, I resign the chair 19:37:48 <slef> not that I've been doing much for the last few minutes ;) 19:38:05 <cait> bye slef 19:38:11 <cait> perhaps we need to close the meeting soon 19:38:12 <libsysguy> bye slef...thanks 19:38:18 <cait> can someone put down our structures? 19:38:18 <Brooke> he's not leaving, he's passing the gavel, yes? 19:38:25 <cait> to have something to start with next time? 19:38:34 <cait> and perhaps meet again in one week or 2? 19:38:35 <slef> I'm not sure when I'm leaving but it will be soon and sudden 19:38:45 <cait> I am not feeling too well myself tonight - might be getting a cold 19:39:46 <libsysguy> Well i basically missed the meeting so I have no objections to whatever 19:40:06 <sekjal> #idea instead of functions in the database table, why not functions directly in the event itself? 19:40:21 <slef> because then how do you replace events? 19:41:19 <sekjal> when an item is checked in, the CHECKIN event occurs, and SendCheckinNotice($itemnumber) is called 19:41:22 <slef> #idea something like eventid int, event varchar(16), function text, template_id int references templates.templateid, report_id references reports.reportid 19:42:02 <slef> yeah but what SendCheckinNotice? C4::SendCheckinNotice or LocalLibrary::SendCheckinNotice? 19:42:15 <slef> sorry, C4::Circulation::SendCheckinNotice 19:42:27 <sekjal> slef: right, sorry, Koha::Notices::SendCheckinNotice 19:42:29 <cait> the one defined in our table weith borrowercategory library and itemtype? 19:43:35 <slef> sekjal: so what would I do to get LocalLibrary::Notices::SendCheckinNotice run instead? 19:43:50 <sekjal> slef: why would you want to? 19:44:26 <slef> sekjal: because Koha::Notices::SendCheckinNotice doesn't check the message log before deciding whether to send a notice. 19:44:32 <slef> (for example) 19:45:11 <sekjal> then write a patch to fix it so it does... (optionally controlled by a syspref) 19:45:21 <sekjal> sorry, I think my head is getting all fuzzy 19:45:34 <sekjal> having a hard time grasping ideas 19:45:38 <slef> patching core is no fun... we have a chance to avoid it here :) 19:46:06 <rangi> oh noes 19:46:08 <sekjal> I think I see 19:46:11 <sekjal> plugin support 19:46:14 <rangi> slef is pitching drupal 19:46:22 * rangi runs screaming 19:46:24 <slef> rangi: I'm hoping to do better. 19:46:44 <oleonard> slef would never pitch something written in PHP 19:46:45 <slef> rangi: replace function calls, not just have function calls that defer to other function calls 19:46:49 <rangi> couldn't do worse :) 19:46:58 <slef> oh I could 19:47:02 <slef> and probably have 19:47:08 <slef> father forgive me 19:47:22 <Brooke> you are forgiven, my son. 19:47:24 <slef> oleonard: danger money, yeah! 19:47:43 * cait can't follow 19:48:01 <sekjal> I'm all for making Koha pluggable, but I think that's outside the scope of this particular project 19:48:21 <rangi> im pretty sure the catalyst drupal team (all 10 of them) just sit around swearing about plugins 19:48:42 <slef> the co-op does too. We almost have no drupal sites left now. 19:48:55 <slef> ttyl - remember to endmeeting, someone 19:49:04 <sekjal> bye, slef 19:49:07 * libsysguy libsysguys site is based on drupal :'( 19:49:22 <cait> oh 19:49:26 <cait> he is using that smiley again 19:49:30 * cait glares 19:49:44 <libsysguy> i mean :-D 19:49:44 <cait> ok 19:50:04 <cait> so perhaps we should end meeting and start with trigger talk/modules next time? 19:50:10 <sekjal> cait: agreed 19:50:14 <sekjal> I'm fried 19:50:23 <rangi> catalyst has a lot, im just glad I dont have to maintain them 19:50:35 <Brooke> #endmeeting