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