[01:40:39] (PS1) AndyRussG: Fix banner name filter and put it in URLs [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/151568 (https://bugzilla.wikimedia.org/39212) [04:19:06] (PS1) Ejegg: WIP email bounce tracking [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/151573 [04:19:08] (PS1) Ejegg: WIP Track TY emails in CiviMail [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/151574 [16:43:44] (PS2) Ejegg: Get innerHTML correctly in DI node assertions [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/150897 [16:43:46] (PS1) Ejegg: WIP: Test cases for Belgium [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/151673 [16:54:22] (PS2) Ejegg: WIP: Test cases for Belgium [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/151673 [17:44:01] atgo: not to shrug that off, but I think jessicarobell's question is more for ccogdill [17:44:25] sorry, which question? [17:44:26] oh ok! [17:44:41] ccogdill: email thread: "Thank-you we screwed up paragraph" [17:45:39] ccogdill: jessicarobell: the status on my end is that I've collected the people affected and have code ready for review which will repair the missing records. [17:45:55] ccogdill: Are there any questions I can answer about what the paragraph should say? [17:47:58] hey awight - yes we’re waiting on one answer re who is receiving the modified ty email [17:48:23] is it going to all donors, including those who are receiving them on time, or only to the people who didn’t receive them before [17:48:43] ccogdill: Only people who were affected by the glitch, and never received a thank-you for their recurring payment. [17:48:48] okay [17:48:52] that’s all we needed to know! [17:48:55] The contribution details will match the missing record. [17:48:59] k, great! [17:49:04] so are we pausing other TYs while those go out? [17:50:02] ccogdill: no, the special paragraph will be enabled according to a tag on the contribution. [17:50:13] perfect [17:50:22] okay I’ll update the email thread so Jessica knows [17:50:25] thanks awight! [17:50:39] ccogdill: fwiw, we can do that sort of conditional template for anything you need. [17:50:47] that is good to know [17:51:43] (PS1) Awight: option to withhold the thank-you letter [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/151686 [18:02:25] (CR) Awight: [C: 2] "Thanks, that's definitely an improvement!" (1 comment) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/151568 (https://bugzilla.wikimedia.org/39212) (owner: AndyRussG) [18:02:35] (Merged) jenkins-bot: Fix banner name filter and put it in URLs [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/151568 (https://bugzilla.wikimedia.org/39212) (owner: AndyRussG) [18:07:13] Jeff_Green: I'm available today if you need, for banner impressions migration, or dashboard authentication chat. [18:07:28] Jeff_Green: did you see the minutes of our meeting with csteipp? [18:07:32] ok great, let's link up in an hour or so [18:07:43] yeah [18:07:44] Jeff_Green: I have a 12-1 meeting, but afterwards sure [18:07:47] looked rather grim [18:07:49] ok [18:07:50] hehe [18:08:01] dedicated server! [18:08:13] urp yes that was sad [18:08:19] everything else I'm okay with [18:08:33] we could also take the apparmor or jail shortcut, if we care [18:08:35] did chroot or similar come up? [18:08:37] no [18:08:39] we do care imo [18:08:45] yyyeah [18:08:48] apparmor maybe. dunno. [18:09:58] Jeff_Green: mebbe 30 minute vidchat at 1? [18:10:38] sure [18:22:37] ejegg|away: just read your letter to silverpop, nice one! [18:58:30] awight: good nooning [18:59:23] thanks, awight! Got some code for adding mailings while creating ty templates, then adding queue records during send. Still very much WIP, but up on gerrit if you want to comment on the general direction / organization [18:59:50] awight: I don't have any hangout link / calendar invitation on my wmf account amusso@wikimedia.org [19:04:21] ah wrongemail used [19:09:43] (CR) AndyRussG: "Thanks!" (1 comment) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/151568 (https://bugzilla.wikimedia.org/39212) (owner: AndyRussG) [19:32:07] (PS2) Ejegg: WIP Track TY emails in CiviMail [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/151574 [19:32:09] (PS2) Ejegg: WIP email bounce tracking [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/151573 [19:46:34] awight: https://wiki.jenkins-ci.org/display/JENKINS/Building+a+software+project#Buildingasoftwareproject-JenkinsSetEnvironmentVariables [20:00:42] awight: +2 :-] [20:06:35] (PS3) Ejegg: WIP Track TY emails in CiviMail [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/151574 [20:06:37] (PS3) Ejegg: WIP email bounce tracking [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/151573 [20:08:06] hey ejegg how was scrum of scrums last week? never got your thoughts [20:08:39] atgo: it was nice to hear from all the other departments [20:09:26] I should get all of fr-tech's input on stuff to bring up ahead of time next one [20:10:12] yeah that would be cool [20:10:16] This time I just dropped a link to the etherpad into this channel while the meeting was on, with a 'did I miss anything?' [20:11:00] nobody's blocked by us so far as SoS participants go [20:13:26] yeah that is not unexpected [20:13:54] :) [20:14:03] you planning on going back this week? [20:16:44] atgo: wasn't it cancelled? Or was that a different meeting? [20:17:06] oh maybe [20:17:19] but I'd be glad to if it's still on [20:17:22] but i'm glad it's seeming useful! [20:25:20] and ejegg awight what's the status on our cookie change? [20:25:29] still waiting? [20:25:53] Oh, the log filter is up, but I still have no prod cluster access. [20:26:24] ejegg: I don't think you need that? I was imagining Jeff_Green would be able to route that filter to a frack box. [20:26:33] Jeff_Green, can you help me get at some log filter output? I hear you sometimes replicate those to the fr cluster [20:27:02] right, what awight said! :) [20:27:02] ejegg: ok [20:27:06] is this the thing from last week? [20:27:11] one sec, finding the path [20:27:14] yeah [20:27:34] i think puppet must have been broken for that box because I did this in the puppet repo [20:28:06] the box that was doing the UDP filtering? [20:28:53] yeah [20:29:23] oh i see, it's routed right to fr with a puppet template variable. [20:30:26] there's a log rotation script that's suppose to drop it on the netapp [20:30:33] i tweaked by hand for now [20:30:54] thanks! [21:24:18] (PS1) Awight: annotate generated templates with source information [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/151775 [21:33:19] hi awight [21:33:34] eileen: hi! [21:33:52] how goes ? [21:34:40] eileen: going well, development on our CRM tools is really picking up now that totten's work is making it worthwhile to write tests [21:35:00] it's been real murky w/o those tests [21:35:12] thanks again for making that connection for us! [21:35:56] nice - and I'm excited that I submitted a PR that failed the tests - before merge :-) [21:36:06] lol I missed that [21:36:13] really, on civi-core? That's even more cool [21:36:18] yep [21:36:35] I'm probably more excited by that angle, cos civi development should be less painful soon [21:36:37] it was a backport of a couple of api & I hit a bug on the 'syntax conformanct test' [21:36:43] ... once you know it was you who broke the test [21:36:49] ah heh I do that often [21:37:07] (if anything is going to fail the syntax conformance test will - but about 40% of the time they are real bugs -) [21:37:59] the travis thing on github is pretty big too - eg Omnipay gateway uses it to check for breaking comits [21:38:03] (2 ms) [21:38:17] ms as in milliseconds? [21:38:36] Yeah I like Travis, or at least the test config format is great, and the service works well [21:38:46] Don't approve of the closed-sourceness, of course. [21:39:59] (2 ms as in commits not comits) [21:40:19] hehe, I actually saw a comet last night... [21:40:45] really? [21:40:53] err sorry, a meteor [21:41:12] really looked like it was beneath the clouds though, which afaik is unlikely [21:41:45] whoa, I just opened yr WMF Roadmap doc, there's... a lot there now. [21:43:19] awight - yep - still have to wrangle some of the ideas in [21:43:30] but there was a lot of info there [21:46:24] eileen: do let us know if you have more questions, or recommendations, or want to grapple with the Civi integration issue yet [21:47:16] awight - yes - I think I understand somewhat what you are doing now [21:47:40] but, would like to get further into what thoughts you have already about how CiviCRM integration might look [21:48:06] Sure! [21:48:20] Civi and or general open sourcing [21:48:33] So, there's this, https://trello.com/b/HEeLk0ZJ/fundraising-open-source-roadmap [21:49:16] I still like the idea that we should push all the processor API stuff in DonationInterface down a level, beneath OmniPay perhaps. [21:49:23] yep - so some of those things - e.g data normalisationyou already have [21:49:45] Most important is the idea that the processor classes will become a library [21:49:52] ok - so donation interface consists of a form builder & a post form processing doesn't it? [21:49:53] completely decoupled from mediawiki assumptions [21:50:01] yes [21:50:07] & also a logger of some sort [21:50:19] & then the queue processor [21:50:29] (do you see those 2 as separate components) [21:50:53] yes, what do you think about the queue stuff? [21:51:06] I was imagining it would be a decent component to open-source, but there's actually very little there. [21:51:15] Most of the magic is in the normalization... [21:51:41] I haven't looked too closely at the queue side - but yes agree you have normalisation & a queing mechanism [21:51:54] We've been playing with the idea of moving normalization into its own component, which would basically be a framework that runs mostly declarative specifications [21:52:13] OK - so if I look at where Omnipay might fit [21:52:23] here's a difficult to grok summary of the transformations lib: https://wikitech.wikimedia.org/wiki/Fundraising/tech/Transformer [21:52:25] Omnipay does normalisation & form post processing [21:52:36] if DOES deal with IPNs as it turns out [21:53:03] okay that's a big deal [21:53:04] & also with recurring tokenised payments (eg. like Worldpay) [21:53:10] very nice [21:53:34] what it doesn't do is help much with the form building side of things [21:54:03] yes... [21:54:28] decoupling forms from processor code looks like it can happen in either order [21:54:37] also, the other possible issue is that it has a number of fields it supports & normalises & to add more you need to get that OKd through the maintainer (strength and weakness) [21:54:40] err, 1) decouple, 2) make universal, or vice-versa [21:55:19] :-) [21:55:57] I really hope the forms can become one big universal thing, with special blocks that are controlled by boolean template params [21:56:10] do you have any experience with that in the real world? [21:56:23] Yes, so I have been doing some work on Cybersource for someone [21:56:24] I'm worried that it might become just as baneful to maintain as what we have now [21:56:27] oh? [21:56:43] & that one works using a 'transparent redirect' [21:56:55] which is the term for when you submit some fields to your site [21:57:07] & then present a 'signed' form that POSTs to their site [21:57:24] (I think you are acheiving the same thing with World Pay with js) [21:57:25] yep, we have three variants on that [21:58:08] For CiviCRM it is a new flow & I've just gone with the php forms [21:58:30] but basically in CiviCRM there is a 'billing block' that collects the address data [21:59:39] yep. I guess the first step in investigating whether we can have a universal form is to collect all the required fields from our different methods... [21:59:41] then on the postProcess the std CiviCRM fields are put onto normalised omnipay fields [21:59:53] great. [22:00:28] If you look at CiviCRM they always gather the same fields & then map them [22:00:38] I think you vary your fields a lot more [22:00:55] (although presumably with the same names unless you are POSTing direct) [22:01:09] I do imagine the differences can always be broken down and controlled with yes/no logic [22:01:19] yeah the names are always the same [22:01:33] so for CiviCRM it looks like https://github.com/eileenmcnaughton/nz.co.fuzion.omnipaymultiprocessor/blob/master/CRM/Core/Payment/OmnipayMultiProcessor.php#L113 [22:01:54] + the extra fields https://github.com/eileenmcnaughton/nz.co.fuzion.omnipaymultiprocessor/blob/master/CRM/Core/Payment/OmnipayMultiProcessor.php#L164 [22:02:09] & then Omnipay handles the next layer of normalisation [22:03:01] very nice. is that class the entire integration, or did you write a ui template as well? [22:03:51] well - I wrote an 'in-between' class (so functions I thought should be on the core-payment class that weren't went in there) [22:04:19] & then for Cybersource I had to do a whole lot of argy-bargy to remove the credit card fields from the billing block & present a new form for them [22:04:45] I also had to write the Omnipay gateway for that one - so it was quite a bit [22:05:01] ahh hrm, that's exactly the sort of form thing I'm vaguely worried about. [22:05:10] which part [22:05:13] (CR) Ejegg: [C: 2] assert more interesting things about recurring contributions [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/149536 (owner: Awight) [22:05:19] the billing block [22:05:22] that we would end up with custom hacks per-gateway [22:05:26] yeah [22:05:32] well - I didn't quite go that far [22:05:41] in that I introduced a new 'type' [22:05:53] which was basically credit card - no fields [22:06:11] but, I was thinking that a yml might be the way to do it [22:06:44] ie. ship with each processor a yml that describes required credit card fields & required billing fields [22:06:45] what would the yaml contain? [22:06:47] ah [22:07:13] (CR) Ejegg: [C: 2] skip some tests under hhvm [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/149537 (owner: Awight) [22:07:15] Well, that's definitely a valid approach. We can catalog the fields on our end and get back about this. [22:07:34] But I have the hunch that very coarse parameters would be the nicest. [22:07:58] For example, the form will require different fields depending on *country* [22:08:20] (CR) Ejegg: [C: 2] recurring donations must have the same contact [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/149538 (owner: Awight) [22:08:59] so the interface might be something like, $processor->alterTemplateParams(&$params, $language, $country, $payment_method) [22:09:07] hey awight ... if you get a break today, i think it would be helpful for me to learn how to pull some data from civi. maybe when adam wh. shows up :) [22:09:18] atgo: no problem [22:09:28] data goes into civi - it doesn't come out [22:09:36] hehehe by design [22:09:42] that's a "feature" [22:09:45] hotel civifornia [22:09:57] aaah motel CA [22:10:03] they stole that song btw! [22:10:15] nothing else they did can even touch that song [22:10:27] I bet I could look that up on wikipedia [22:10:50] I'm trying :p [22:10:55] :-) [22:11:23] eileen: and the altered params would be like 'needAddressDetails' => true [22:11:43] gets twitchy with bank transfers though... :( [22:11:48] ok - so just thinking - about the idea of how you might do metadata (& I'll discuss with Tim too) - one thing I had in mind was whether implementers would need to be able to over-ride it [22:11:49] those have a million different fields. [22:12:04] eileen: yes, that is key IMO [22:12:05] ie. you have a weighting [22:12:14] hook sort of thing sounds good [22:12:28] although... Civi doesn't weight the hooks, does it? [22:12:38] well - the hook would work in civi land [22:12:51] as each processor could have a weight & you could alter it [22:13:08] not that Civi would easily care about the weighting [22:13:27] so, that's a bit of an aside I guess [22:13:27] hi, can anyone explain to me some details about my CN tasks :) :) ? [22:13:46] eileen: Ah maybe I'm confused now--are you talking about how we select an appropriate processor? [22:13:54] AndyRussG: yes I'd be happy to [22:14:03] awight: cool thanks! :) [22:14:12] for example https://wikimedia.mingle.thoughtworks.com/projects/online_fundraiser/cards/957 [22:14:19] yep - I think I am - & I'm not sure if it's relevant actually [22:14:32] Just wondering which message field... [22:15:18] eileen: well, definitely is. My only thought about that is, we would have generic payment methods, and processors could register whether they support that capability / per country. [22:15:39] fyi, we often have to turn off a specific method x country combination [22:15:55] AndyRussG: wow yeah that is an empty card [22:16:11] AndyRussG: ok updating now... [22:16:23] awight - OK - so I guess the thing is the metadata is relevant for 2 processes [22:16:28] components [22:16:37] 1) gateway selector [22:16:44] 2) form builder [22:17:03] eileen: I think the form builder uses entirely different metadata [22:17:49] as in there is not really any cross over [22:18:04] Probably is the case. [22:18:30] Hmm, fwiw they both need to be overridable by the site config though [22:18:38] yeah [22:19:08] but I guess I need to think about whether that is a feature of the library or the library's integration [22:19:37] ie. CiviCRM holds the relevant credentials field names in it's payment processor table [22:19:52] so mapping those to omnipay ones is part of the integration not the library [22:20:25] ah, you bring up a really good point, that Civi might have to be aware of the gateway selection [22:20:30] that seems like a lot of work... [22:20:47] and WMF would be the only user... [22:21:19] yes - but you aren't really thinking about using CiviCRM for your forms anyway [22:21:30] right [22:21:56] so, I guess we might be saying that the gateway selector is bottom of the heap priority wise [22:23:06] Maybe we should start to spell out what we would be adding to Civi, and what we change about DonationInterface [22:23:16] :-) [22:23:25] so, the most obvious win would be refunds [22:23:43] actually refunds & token payments [22:24:40] on the Civi side, yes [22:24:50] for DI, we just need that beast to be maintainable [22:25:31] then a sadly neglected priority is that we're writing payment processor stuff that 3rd-parties can use [22:25:54] can you give me some examples of the maintenance pain? [22:26:21] the most challenging gateway seems like global collect [22:27:06] eileen: Adding new processors is a multimonth thing, and is spread across four codebases... [22:27:41] We have to copy and paste a similar form from existing gateways, and if we make any improvements, other gateways do not benefit [22:28:36] the DI code has some really crazy mini-framework stuff going on, so you have to grok far too many operational details before you can safely write a new gateway [22:28:46] so, I understand DI as having 3 components - gateway chooser, form builder, & post form processor - is that right? [22:28:57] We're using a fork of DI to do token-recurring... still have not unforked [22:29:05] eileen: that is one way to look at it, yes [22:29:15] the component boundaries are hopelessly blurred, though [22:29:23] ejegg: feel free to chime in, your wounds are fresher... [22:29:28] heh [22:29:32] so, if CiviCRM could handle token recurring would you use that? [22:29:38] eileen: absolutely [22:29:49] ie. there is a fairly clear path to add that as a scheduled job in CiviCRM [22:30:01] so, it would query the civicrm_contribution_recur table [22:30:03] maintaining that piece has been a real nightmare, when it breaks we usually have a huge cleanup and donor relations job [22:30:18] & then run requests based on that [22:30:41] yes, we do that much [22:30:50] weirdly half-integrated with Civi... [22:31:07] this is the code in https://github.com/wikimedia/wikimedia-fundraising-crm/tree/master/sites/all/modules/recurring_globalcollect [22:31:09] ok - so, moving that to CiviCRM would be a win [22:31:44] yep, and implementing refunds would be a big relief for donor services AFAICT [22:32:34] does a batch run as a series of individual requests? [22:33:59] so, for global collect you actually store tokens? I thought worldpay was going to be the first where you did recurring that way [22:36:22] we don't have tokens for GC. [22:36:40] yes a batch is a fixed number of donations that we charge [22:37:24] but, you are triggering the recurring payments - rather then them being like Paypal where they run according to a scheduled you have described to them? [22:38:45] eileen: for GC, we do trigger the recurring payments [22:39:06] I'm just now learning how we do that [22:39:23] ok - so you store something that acts as a token to allow you to trigger them - so the flow is similar to the ones which are officially tokens? [22:39:44] i guess we must [22:42:44] awight|errand: can you talk me through this a little bit https://upload.wikimedia.org/wikipedia/commons/3/39/WMF_Fundraising_crm_classes.svg [22:44:26] eileen: that... was a bit crazy. I was trying to put together my thoughts about the ideal interface... [22:45:01] The original thing that put me over the edge is that we're passing around several types of ID to refer to donations and subscriptions. [22:45:29] trxn_id is not really cutting it, so we had to turn that into a natural key, including the name of the gateway and stuff... [22:45:53] it gets even worse with GlobalCollect, cos in their world, the subscription id == the txn id of all payments [22:45:55] not cutting it because? [22:46:10] because the numbers can collide between gateways [22:46:15] as in all payments have the same txn id [22:46:22] yeah [22:46:38] ah yes - I had wondered if that could happen - which would be OK if the key was a combo key wouldn't it [22:46:42] so we jam this extra piece of information on... and it quickly becomes unqueryable [22:48:09] right - so in general if the key included a trxn_id and a payment_processor_id field you'd be OK - but what's 'worse' with GC? [22:48:54] GC uses the same ID for the initial and the repeats, right? [22:49:02] wow [22:49:02] we just change the order type [22:49:30] as in it looks like trxnid-1, trxnid-2 when you store it? [22:49:55] awight, we append a sequence number, right? [22:50:51] sorry, I was just looking at this. should be clearer in my mind... [22:51:33] yep it's -1 -2 etc. It's not fun to query. [22:52:08] so, I guess CiviCRM would ideally have a unique 3 key combo [22:52:19] processor_id + trxn_id + sequence_id [22:52:45] (normally sequence_id would be NULL but for the odd processor that won't play ball....) [22:52:59] wellll, I suspect it will get even weirder than that. [22:53:00] yeah, the trxn_id is basically our recurring token. they just internally remember when or how many times we're allowed to use it [22:53:14] I think the processor class might have to be involved in querying [22:53:39] for example, BPay in Australia doesn't have -1 -2, we are supposed to use the timestamp to identify each payment :( [22:53:52] ah.... [22:54:04] Melbourne or Perth timestamp? [22:54:08] exactly :) [22:54:26] I have no idea how we would query anything in their database... maybe we can't. [22:54:27] so, what would you be doing when you are retrieving that information? [22:54:52] (thinking of BPay example) [22:55:08] eileen: probably nothing in this case, we wouldn't need to query the processor. [22:55:28] But very abstractly, it would be stuff like "get the donor's contact info", or "did this payment settle" [22:55:44] The part we definitely do care about however is that we have a sane way of addressing payments within Civi. [22:56:26] right & at the moment you have to clumsy-up (technical term) the trxn id because it has to be unique within that field [22:59:29] yep [22:59:40] so that is just some background to why I had a UML freak-out... [23:00:09] I also want nice stuff that lets us go $subscription->cancel(), for example [23:01:03] DonationStatus is a thing I wanted to do where we keep track of the processor's raw status and test transaction behavior against a small FSM to validate that only expected things are happening. [23:03:09] actually - it is currently possible with some processors to cancel recurrings from CiviCRM I think [23:04:29] so, at the moment cancelling subscriptions has 2 processes? [23:04:50] 1 for ones like paypal where they hold the recurring schedule [23:04:56] well, it can be done on the processor's console, then the odds of that propagating back into Civi are 50/50 :D [23:05:14] & another one for ones like GC & worldpay where it's triggered from your end? [23:05:49] I honestly don't know how we cancel GC subscriptions. [23:06:02] the hotel gc [23:06:26] haha yes but don't worry we will eventually damage your subscription record to the point that we stop charging you [23:06:32] :-) [23:07:07] so, I also notice things like getSettledTotal - I know paypal returns net amount & fee amount [23:07:18] do others / do you otherwise calculate that? [23:07:39] mostly it's transparent to us, and the finance dept has aggregate numbers. [23:07:58] the SettledTotal thing is because we can settle in different currencies... [23:08:32] apparently it's often more cost-effective to have several accounts in different currencies, and settle into one or the other... [23:09:09] ok - it's a bit hard to see how that would apply to other CiviCRM users [23:11:02] I see there is already logic to segment reports along currency groups [23:11:12] that's true [23:11:17] We want that too, but we have original currency groups, and settled currency groups. [23:11:22] ah ok [23:11:28] the settled groups are the same as what civi already supports [23:12:01] you might read it that civi supports original rather than settled [23:12:20] interesting... [23:12:30] well, we reverse the values then [23:12:52] for now, we only deal with USD [23:12:56] I guess in the parlance of CiviAccounts there would probably be a currency conversion transaction [23:13:36] that's also transparent to us [23:13:48] We get a summary bill for ForEx fees [23:15:08] yeah - but potentialy you would want CiviCRM to hold more information about settlement (although I'm not reading that as high priority for you) [23:15:50] I also note time for settled vs received in there [23:19:26] awight - what I might do now is just improve that doc some more & then try to grab totten to discuss (maybe on my Thurs / your Wed) on civicrm IRC to get his input - [23:28:28] eileen: ok that sounds good! [23:32:32] cool - I'll email him to try to lock him in & cc you. I'm in 2 minds about actively inviting a couple of other people - e.g Joe M / Chris B at that point [23:33:46] eileen: I'm happy doing this either way--we can come up with an ideal solution then try to sell it to the rest of the civi community, or we can collaborate from the outset. [23:35:17] yeah - well - I definitely would like to pick Tim's brain - I'm torn as to whether getting more minds in at this point would generate more ideas or create diversion [23:35:45] it seemed very productive last time, at the end of the code sprint. [23:37:22] yeah Tim is great at getting to the essence of things [23:37:48] It's been a pleasure working with him on the CI project! [23:38:06] yep [23:38:20] btw we haven't really talked much about the auditing side [23:38:34] I assume it's pretty much a case of get data from processors that support it [23:38:38] normalise it [23:39:08] check status against civicrm transaction status [23:39:11] yeah nothing tricky there [23:39:15] sometimes there is an API call [23:39:18] update CiviCRM as appropriate / spit out reports [23:39:31] (which processors support it?) [23:39:43] Actually, the most interesting thing there is the updating Civi part--currently we are only using auditing to fill in missing records [23:39:59] I'd like to do what you say, though: update and compare with existing information [23:40:13] and also, record that we have audited the transaction. [23:40:13] ok - & the key part there is the issues with the transaction_id is a problem? [23:40:29] ah yes - you don't do that but would like to? [23:40:54] nah, we have workarounds for trxn_id. it's just that we haven't yet decided how to do the updating. [23:41:04] That's what the "PipelineInteraction" class is about in my UML [23:43:25] o [23:43:34] hehe [23:43:38] UML does that [23:43:46] oops. i've got to hit the road to avoid muni madness with the pooch. ciao! i'll be wfh tomorrow [23:43:58] ok, I'll set the alarm when I leave at 5 :p [23:44:58] ok - do you hit ones that need updating? or only missing ones? [23:45:04] awight please make a card for btc import :) [23:45:07] only missing ones at the moment [23:45:12] atgo: argh, busted [23:45:16] :P [23:45:33] atgo-home: but... there is so much other unplanned work that is not encarded... [23:48:17] encard it :) [23:48:42] * awight sullenly punches holes in index cards [23:54:48] (CR) Awight: "Sane as it could be! Some comments inline..." (9 comments) [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/151574 (owner: Ejegg)