[01:05:13] (CR) Awight: "Thanks for explaining the stuff! I still have a mini-beef with the existing code, but this patch only improves the situation. Will merge" (2 comments) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/254343 (https://phabricator.wikimedia.org/T119120) (owner: Ejegg) [10:49:39] Fundraising Sprint X-Ray Spex, Fundraising-Backlog, Unplanned-Sprint-Work, Patch-For-Review: Silverpop import not importing entire database? - https://phabricator.wikimedia.org/T119105#1824694 (CCogdill_WMF) Per @Ejegg's email, I checked the Silverpop import report from 11/22 and we're back to impo... [10:49:59] Fundraising Sprint X-Ray Spex, Fundraising-Backlog, Unplanned-Sprint-Work, Patch-For-Review: Silverpop import not importing entire database? - https://phabricator.wikimedia.org/T119105#1824695 (CCogdill_WMF) Open>Resolved [10:54:22] Fundraising Sprint William Shatner, Fundraising Sprint X-Ray Spex, Fundraising-Backlog, Patch-For-Review: Dedupe data in Silverpop file - https://phabricator.wikimedia.org/T107045#1824698 (CCogdill_WMF) The latest fix seems to have done wonders (I say with cautious optimism). Not only did it fix th... [13:41:05] fundraising-tech-ops, operations, Patch-For-Review: remove fundraising banner log related cruft from production puppet - https://phabricator.wikimedia.org/T118325#1824953 (ArielGlenn) p:Triage>Low [14:50:24] (PS1) AndyRussG: Merge branch 'master' into wmf_deploy [extensions/CentralNotice] (wmf_deploy) - https://gerrit.wikimedia.org/r/254861 [14:53:10] (CR) AndyRussG: [C: 2] Merge branch 'master' into wmf_deploy [extensions/CentralNotice] (wmf_deploy) - https://gerrit.wikimedia.org/r/254861 (owner: AndyRussG) [14:54:24] (Merged) jenkins-bot: Merge branch 'master' into wmf_deploy [extensions/CentralNotice] (wmf_deploy) - https://gerrit.wikimedia.org/r/254861 (owner: AndyRussG) [15:38:50] (PS1) Cdentinger: minor adyen iframe css changes [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/254874 [15:43:22] (CR) Cdentinger: [C: 2] "That's a fun one!" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/254633 (https://phabricator.wikimedia.org/T118349) (owner: Ejegg) [15:44:22] (Merged) jenkins-bot: Return from function after redirect [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/254633 (https://phabricator.wikimedia.org/T118349) (owner: Ejegg) [15:44:34] thanks cwd ! [15:44:45] Wikimedia-Fundraising: Don't show fundraising banners outside of main namespace - https://phabricator.wikimedia.org/T119400#1825302 (Pcoombe) NEW a:Pcoombe [15:45:30] np! [15:45:55] Fundraising-Backlog, Wikimedia-Fundraising, MediaWiki-extensions-CentralNotice: Fundraising banners showing when opened in-app on iOS to users who are logged in through Safari - https://phabricator.wikimedia.org/T119116#1825314 (Pcoombe) >>! In T119116#1823491, @Wittylama wrote: > > So... at the ver... [15:46:53] ejegg: do you want anything done with that first PS? this one seems to supersede it... [15:48:57] cwd: Ah, no, I'll drop that [15:49:21] cool [15:50:20] Wikimedia-Fundraising, WMF-Design, Wikimedia-General-or-Unknown, Easy, Mobile: [[wmf:Benefactors]] not displaying well on Mobile - https://phabricator.wikimedia.org/T87805#1825324 (Pcoombe) Open>Resolved Closing this, if there's specific things you still want improving feel free to re-open... [15:55:02] (Abandoned) Ejegg: Revert logic change from logging enhancement [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/254181 (https://phabricator.wikimedia.org/T118349) (owner: Ejegg) [16:34:44] Wikimedia-Fundraising: Don't show fundraising banners outside of main namespace - https://phabricator.wikimedia.org/T119400#1825431 (Wittylama) This has the critical advantage of not pissing off the community because the overwhelming majority of readers of the site never leave namespace zero a.k.a. article s... [17:15:23] (PS2) Ejegg: make iframe behave more like worldpay [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/254437 (owner: Cdentinger) [17:16:30] (CR) Ejegg: [C: 2] "Looks good, nice to move the frame opening to the ajax success." [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/254437 (owner: Cdentinger) [17:17:20] (Merged) jenkins-bot: make iframe behave more like worldpay [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/254437 (owner: Cdentinger) [17:18:48] ty ejegg! [17:28:59] ejegg: cwd: hi! how's everything? I just got a call from my daughter's school that she's sick and I should go pick her up, and a CN deploy is about to go out [17:28:59] Hi AndyRussG [17:28:59] Anyone like to cover for me during about 15 minutes, in case anything goes wonky while I'm out? [17:28:59] hi! [17:28:59] Is it just the [Ff]undraising cookie patch? [17:29:28] i will be here [17:29:35] I'll be here too [17:29:35] will help however i can [17:29:41] ejegg: yep! [17:29:46] Hope your daughter feels better soon! [17:29:48] ejegg: cwd: thx!!! [17:33:01] ejegg: cwd: K back in 10 or so! thanks!!! [17:44:03] ejegg: do you know how to test this change? [17:44:31] Hmm, we need to get a fundraising banner without forcing it [17:44:48] let me check campaigns [17:48:55] huh, I know we had a google calendar or doc for campaigns, but I can't find it [17:58:55] (PS2) Ejegg: commit screen.css [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/254441 (owner: Cdentinger) [18:02:09] (CR) Ejegg: [C: 2] "Dig those retro carriage returns!" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/254441 (owner: Cdentinger) [18:04:13] cwd: ejegg: thanks so much for covering for me!!!! confirmed that FR campaigns use cookies as required for banner diet [18:04:18] (Merged) jenkins-bot: commit screen.css [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/254441 (owner: Cdentinger) [18:04:33] AndyRussG: i did nothing but you're welcome :) [18:04:34] good stuff! [18:05:25] :) [18:26:51] cwd: ejegg: I don't see any active non-FR that I can get to check that they use KV storage, but I can confirm that non-FR campaigns still get mw.centralNotice.data.campaignCategoryUsesLegacy set to false, which should trigger KV storage, while FR campaigns are now getting it set to true, which triggers the cookie [18:27:40] AndyRussG: hard to see how that patch could have made anything go the other way [18:28:53] ejegg: yeah... funny, one question that has come up now, incidentally, is how many users have cookies disabled [18:29:51] Would we want to sample that to event logging? [18:30:05] I think it'd be the only way! [18:30:50] The (smallish) issue is that now on the impression diet people with cookies disabled default to seeing a banner, but FR thinks it'd be better to default to hiding in that acse [18:30:51] case [18:31:12] right. [18:31:22] +1, that seems like the best. Always fail open! [18:31:44] Hmmm open to avoiding criticism for excess banners! [18:31:48] Dunno if such a change is freeze-allowed [18:31:49] err fail closed. gah [18:31:54] Would be quite easy, in any case [18:31:57] definitely allowed [18:32:06] Ah K cool [18:32:24] Feel free to argue with yourself about whether it's appropriate, though ;) [18:33:35] awight: cwd merged https://gerrit.wikimedia.org/r/254633 this morning, which I hope/believe makes DI deployable again [18:34:03] was there anything more to do in the currency patch? [18:34:17] now: much cherry-picking [18:34:35] uhh. DI was deployable after I reverted the buggy patch, I thought [18:34:47] I feel like I missed a lot over the weekend ;) [18:34:56] but i think we can remerge everything now? [18:34:57] awight: oh, I think you only reverted in deployment [18:35:11] Yeah, I was going to revert the revert and merge in the following things [18:35:26] I see [18:35:50] ejegg: do you want your latest patch to be on top? [18:36:09] i guess it shouldn't matter but might have to resolve some conflicts [18:36:10] yeah, it would have to go after the revert-revert [18:36:11] Well, a fancier option would be to add a parameter to randomly show or hide a % of the time for those users [18:36:11] Heh and that would even give us a sample of users with cookies disabled (because we'd set a new hide reason) [18:36:11] (that would show up in logs) [18:36:58] Oh, has there been a cherry-picked deploy since the failed one? [18:37:50] AndyRussG: We can look into that later, but in general I think that if someone doesn't have cookies / js / etc, we should just not mess with them [18:38:25] ejegg: Revert "Merge branch 'master' into deployment" is the deployment head [18:38:29] sorry. I'm just catching up [18:39:16] ok, cool. So I'll do a revert of that top one (in deployment) to get us back to the failed deploy, then merge in master to get all the commits since [18:40:12] uhh [18:40:18] Anyone want to OK the currency code fix? https://gerrit.wikimedia.org/r/254343 [18:40:21] that sounds really card [18:40:22] hard [18:40:29] can you just do the merge without reverting the revert? [18:40:38] I mean--whatever's easiest for you [18:40:41] awight: will that work? [18:40:41] awight, AndyRussG: i think that's a good policy, if someone turns cookies off it's probably because they want to be left alone [18:40:54] The merge won't work out of the box regardless of reverting the revert, AFAIK [18:40:58] I thought it wouldn't re-merge the reverted patches [18:41:03] Git is hopelessly confused by a reverted merge [18:41:13] ejegg: it will if you cherry pick [18:41:17] It has marked all the commits in that branch as "do not want" [18:41:18] but it won't re-merge [18:41:23] yep, what cwd said [18:41:29] ah, I see [18:41:32] if you cherry pick it technically becomes a different commit [18:41:36] changes sha [18:41:41] Although, I think it would if you put all those commits onto a new branch so they got new SHA's [18:41:44] because what came before it is part of the sha [18:41:55] OK, I'll see which way is easier [18:42:15] revert the merge revert would also eff with our heads :) [18:42:34] in principle, that should redo the merge, but none of us would believe it [18:43:22] otoh, it avoids having to regenerate change ids [18:45:27] (PS1) Awight: Revert "Revert "Merge branch 'master' into deployment"" [extensions/DonationInterface] (deployment) - https://gerrit.wikimedia.org/r/254900 [18:45:41] nvm me--that worked perfectly, it's identical to a2420393e9c376de26965b11ee8ffe7c1d3186e8 [18:45:50] nice! [18:48:48] wicked [18:51:31] hey awight AndyRussG do you know how to force a banner? the "preview on wiki" feature doesn't seem to be working [18:52:00] gah. Please send a preview link that's not working [18:52:05] It could have to do with banner hiding code. [18:52:07] atgomez: ^ [18:53:23] atgomez: preview on wiki should work, though other measures are needed to make mixins run.... yeah links plz :) [18:53:30] https://meta.wikimedia.org/w/index.php?title=CIS-A2K/Community_support&banner=B1516_1120_enWW_dsk_lw_sm_txt_volndon&uselang=en&force=1 [18:53:44] works for me--so it's the hiding code [18:53:50] Try clearing cookies for metawiki [18:54:07] (or use private mode) [18:54:14] And for a good time: https://meta.wikimedia.org/w/index.php?title=CIS-A2K/Community_support&banner=B1516_1120_enWW_dsk_lw_sm_txt_volndon&uselang=en&force=1&country=HK [18:55:32] Hahaha [18:55:46] nice [18:56:53] oh, now I get it - HKD! [18:58:53] credit to the-wub for that one [19:02:17] running an errand, back in a bit [19:12:31] Fundraising-Backlog, fundraising-tech-ops: Replicate silverpop export (barium) on lutetium - https://phabricator.wikimedia.org/T103740#1826173 (Jgreen) Ok thanks everyone. I don't see an issue with putting lutetium back into replication for the silverpop database. I don't have any brilliant way to do it... [19:29:51] hey awight, I have a quick sql question about the PP data [19:30:52] your note about making sure to use the is_primary field made me think - is that actually what we want? PP will need the email associated with the contribution, but couldn’t the is_primary field show us a different email associated with the contact record, if DS has merged any? [19:31:48] aaahm [19:31:50] dear god [19:31:56] yeah this email this is really a fiasco [19:32:08] Can you fwd me the note where they said "gateway txn id won't work"? [19:32:16] Cos I have a very hard time with that... [19:32:24] I may not have it… PPena was leading that conversation [19:32:27] I'm hoping there is a chink in their language [19:32:28] but I know, it’s ridiculous [19:32:32] PPena: ^ if you would? [19:33:35] awight I will [19:33:42] thx! [19:33:43] Fundraising-Backlog, fundraising-tech-ops: Replicate silverpop export (barium) on lutetium - https://phabricator.wikimedia.org/T103740#1826213 (awight) @Jgreen Works for me! I guess, sooner is better. [19:34:05] thanks awight, I’ll wait for word from you. I have the query ready but yeah, wasn’t sure how to make sure I got the email they needed [19:34:09] ejegg|afk: You want me to merge the re-revert? [19:34:38] ccogdill: Like you pointed out, I don't think there's any way to di it, if the records haved been merged. [19:34:50] fyi, I'm planning on adding exactly this feature when I do the dedupe work [19:35:02] I was afraid of that. Wasn’t sure if the original email lived in a table I didn’t know about [19:35:03] We'll have a record of which *original* contact ID each contribution came from [19:35:07] ooh! So it will. Awesome [19:35:31] The motivation there is actually to provide the ability to fully undo a merge if we have to [19:35:50] MBeat: ;) thanks for giving a name to my failures [19:36:02] np! [19:40:47] awight: sure, please do merge! [19:43:46] Then maybe I'll just cherry-pick my fix on top of that and deploy to make sure globalcollect works. If that's chill I'll do another deploy later with the stuff we've done since. [19:45:44] ccogdill: It seems that Civi doesn't have the records to say that another contact has been merged into one. Which is too bad. I was thinking that you could just exclude emails from deduped records, and clean up by hand or something. Nope [19:46:01] yeah :/ [19:46:06] (CR) Awight: [C: 2] Revert "Revert "Merge branch 'master' into deployment"" [extensions/DonationInterface] (deployment) - https://gerrit.wikimedia.org/r/254900 (owner: Awight) [19:46:34] well… should we just send what we have to PP and cross our fingers? It was only two banners so it’s not an incredible number of donations [19:47:19] totes [19:47:31] okay [19:47:33] We can say maybe 25% of the records are wrong ;) [19:47:33] thanks [19:47:35] lol [19:47:36] haha [19:47:40] I’m hoping less [19:47:57] so would you leave out the is_primary param? [19:47:58] That's our estimate for how much of the DB are dupes [19:48:22] um... no, keep that on. Otherwise, you'll get a record for each email on each contact [19:48:30] ah okay [19:48:32] will do [19:48:47] By keeping that where clause, the risk we're taking is PP not finding the contribution for an email we send them [19:49:02] Maybe they can send that list back to us, if it's not asking too much. [19:49:09] yeah [19:49:12] Going forward, we need to give them that "BN" param [19:49:17] sigh [19:49:24] (Merged) jenkins-bot: Revert "Revert "Merge branch 'master' into deployment"" [extensions/DonationInterface] (deployment) - https://gerrit.wikimedia.org/r/254900 (owner: Awight) [19:50:34] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Civi should record merge activities on both old and new contacts - https://phabricator.wikimedia.org/T119426#1826269 (awight) NEW [19:52:19] PPena: ccogdill: it's worth sending them another email saying, "WTF you mean, you can't use your own IDs" if you wish [19:52:56] awight lol. Give them a break, they just got 'divorced'... it's hard! [19:53:11] Fundraising Sprint X-Ray Spex, Fundraising-Backlog, MediaWiki-extensions-CentralNotice, Unplanned-Sprint-Work, Patch-For-Review: Fix and handle effects of mistake that made FR banners use KV store for impression diet - https://phabricator.wikimedia.org/T119348#1826286 (DStrine) [19:53:12] :D [19:53:41] It gets better [19:54:34] Fundraising-Backlog, MediaWiki-extensions-DonationInterface, FR-Paypal: Send PayPal stuff in the "BN" param... sometimes - https://phabricator.wikimedia.org/T119429#1826315 (awight) [19:55:48] Fundraising Sprint X-Ray Spex, Fundraising-Backlog, fundraising-tech-ops: Format Monolog messages to be easier to grep, bucket them - https://phabricator.wikimedia.org/T115746#1826318 (awight) Okay, assigning back to myself--This is probably because no fatal errors have happened. I'll have to deploy... [19:55:52] Fundraising Sprint X-Ray Spex, Fundraising-Backlog, fundraising-tech-ops: Format Monolog messages to be easier to grep, bucket them - https://phabricator.wikimedia.org/T115746#1826319 (awight) a:Jgreen>awight [20:06:54] Fundraising Sprint X-Ray Spex, Fundraising-Backlog, MediaWiki-extensions-CentralNotice, Unplanned-Sprint-Work, Patch-For-Review: Fix and handle effects of mistake that made FR banners use KV store for impression diet - https://phabricator.wikimedia.org/T119348#1826338 (AndyRussG) Open>Reso... [20:21:19] ejegg: cwd|afk: this is fixed now, right? [20:21:20] https://phabricator.wikimedia.org/T118349 [20:21:40] AndyRussG: I think so! [20:21:46] cool! [20:22:00] cwd|afk just merged one of the two possibilities for preventing that bad fallthrough [20:22:20] Yeah I was thinking about adding a return statement there, but I wanted to actually be able to smoke test, which I didn't achieve [20:22:40] ejegg: can I re-assign it to you, since you did the actual work? I'll also put it in pending deploy then... [20:23:08] sure, thanks! [20:23:31] ejegg: likewise! [20:23:52] Fundraising Sprint X-Ray Spex, Fundraising-Backlog, MediaWiki-extensions-DonationInterface, Unplanned-Sprint-Work, and 3 others: Determine what was breaking GlobalCollect in paymentswiki 3730cff20 - https://phabricator.wikimedia.org/T118349#1826375 (AndyRussG) a:AndyRussG>Ejegg [20:25:29] Aaarg... unless there's another suggestion on what I should do, I'm going to try to actually get that test donation to work, rather than leaving things in a semiconfigured useless state... [20:25:37] ejegg: ^ [20:25:47] that sounds worthwhile! [20:26:49] I still get "There has been an error processing your request. No processors are available." js alert box... Was gonna just JS debug... [20:26:53] (PS1) Ejegg: Return from function after redirect [extensions/DonationInterface] (deployment) - https://gerrit.wikimedia.org/r/254920 (https://phabricator.wikimedia.org/T118349) [20:27:18] AndyRussG: I was getting that too, with an internal-1002 error code [20:27:35] we send that code when we can't communicate with the processor API [20:27:59] So either our URL is bad, or the VPN isn't enough, or something... [20:28:23] On a background request? Hmm I don't see that at anywhere [20:28:34] server-to-server call [20:28:46] Where can I see that? [20:28:56] The syslog? [20:29:14] maybe? let me check the logging there [20:29:26] I usually just step thru w/ a php debugger [20:30:06] Ah yeah I should do that... Haven't re-set that up with vagrant yet [20:30:49] Nov 23 20:27:46 mediawiki-vagrant globalcollect_gateway: 28:5110189830 processResponse Error 102010 : There has been an error processing your request. No processors are available. [20:31:22] Maybe I have the test URL wrong? [20:31:29] Oh, huh, maybe that's not the same problem? [20:31:47] lemme see, there's a guide to their error codes on the share [20:32:44] $wgGlobalCollectGatewayURL = 'https://ps.gcsip.nl/wdl/wdl'; [20:32:44] $wgGlobalCollectGatewayMerchantID = '6570'; [20:32:44] $wgGlobalCollectGatewayAccountInfo['whatever'] = array( 'MerchantID' => '6570' ); [20:40:03] AndyRussG|cello: gah! [20:40:08] wrong number! [20:40:16] Ah K that's it! [20:44:12] awight: I want to talk with you briefly about the refunds ticket [20:44:33] sure! [20:44:39] irc or hangouts? [20:44:48] either or [20:45:45] my concern is that we are making a permanent decision [20:46:19] mmm [20:46:24] ie. if we start doing UI refunds + creating a refund transaction now then the financial-transaction data will be corrupted [20:46:25] Sounds good :p [20:46:48] because there will be 2 * refund rows created [20:47:25] so, if we go that way (duplicate previous method) we are precluding making use of low-level financial data [20:47:47] but we have the simplicity of contribution data still accessible [20:48:06] I think we eventually have to migrate existing data either way. [20:48:14] I don't know about "permanent" here [20:48:41] well, when the upgrade happened the financial items were filled in for existing data [20:48:55] yes [20:49:03] and any transactions we have entered since them have them added [20:49:24] but, if we start setting transactions to refunded then it will create financial rows to reflect that [20:49:58] if we ALSO create negative value transactions from now onward it will create transactions that duplicate what the other ones did [20:50:30] ie. at the financial transaction level we will have 2 * $-1 row [20:50:45] my expectation is that is NOT the case for the existing [20:51:09] one thing I could do is figure out a way to expose the per contribution financial transactions to the UI [20:51:33] which would make it clearer & might a) help us make a better decisiion & b) be useful anyway [20:52:07] I think it makes sense to ignore old-style refunds as we make a decision about how this should work going forward. We'll just migrate existing records to exactly match the new style. [20:52:24] ... and update the few reports that rely on our ad-hoc refund thing [20:52:44] I think maybe we should hangout - 'cos I'm not sure what migrate existing records means [20:52:54] +1 that we need to expose line items [20:52:54] k [20:54:08] just a sec--my phone is answering, that's bad. [20:54:14] ok [21:14:03] Fundraising-Backlog, FR-Adyen: Configure new Adyen account - https://phabricator.wikimedia.org/T119442#1826535 (Ejegg) NEW a:Ejegg [21:14:23] Fundraising Sprint X-Ray Spex, Fundraising-Backlog, FR-Adyen: Configure new Adyen account - https://phabricator.wikimedia.org/T119442#1826543 (Ejegg) [21:17:26] Fundraising Sprint William Shatner, Fundraising Sprint X-Ray Spex, Fundraising-Backlog: Really slow when you search for Eileen's mum from quicksearch email + enter - https://phabricator.wikimedia.org/T118215#1826561 (Eileenmcnaughton) [21:17:39] Fundraising Sprint X-Ray Spex, Fundraising Tech Backlog, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Patch-For-Review: Donation over $1000 throws error on comma in amount field (editing or creating) - https://phabricator.wikimedia.org/T118216#1826562 (Eileenmcnaughton) [21:28:43] Fundraising Sprint William Shatner, Fundraising Sprint X-Ray Spex, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Unplanned-Sprint-Work: Slow query on deduping 2 contacts - https://phabricator.wikimedia.org/T116886#1826588 (DStrine) [21:28:43] Fundraising Sprint William Shatner, Fundraising Sprint X-Ray Spex, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Unplanned-Sprint-Work: Slow query on deduping 2 contacts - https://phabricator.wikimedia.org/T116886#1760905 (DStrine) [21:45:58] hey sorry we got dropped from the call [21:46:01] please hold [21:46:29] fighting 2-factor auth ... It's real fun over here [21:50:12] Wikimedia-Fundraising-CiviCRM: Look at porting patch to mitigate CiviCRM deadlocks - https://phabricator.wikimedia.org/T119447#1826652 (Eileenmcnaughton) NEW [21:51:04] can anyone hear us on the call? [21:51:16] You guys are quiet but I can hear. [21:51:22] i can hear you [21:52:19] ejegg: can you hear us on the call? [21:52:34] LOLOLLOLOLOL [21:52:35] no! [21:52:38] :( [21:52:40] just eileen1 [21:52:49] only the important one [22:00:58] fundraising-tech-ops: Need a dev_fredge database on the staging server - https://phabricator.wikimedia.org/T116879#1826686 (Jgreen) p:Triage>Normal [22:01:54] fundraising-tech-ops: Need a dev_fredge database on the staging server - https://phabricator.wikimedia.org/T116879#1826689 (Jgreen) Open>Resolved This is done. Normal users have 'all' access, plus I created dev_fredgeread and dev_fredgewrite users also with 'all' access. Ping me for passwords for those... [22:15:57] Fundraising Sprint William Shatner, Fundraising Sprint X-Ray Spex, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Patch-For-Review: Civi quick search by email doesn't work - remove label to alleviate confusion. - https://phabricator.wikimedia.org/T118036#1826730 (Eileenmcnaughton) Open>... [22:22:17] Fundraising-Backlog, fundraising-tech-ops: Don't send us all the cron spam - https://phabricator.wikimedia.org/T119452#1826750 (awight) NEW [22:43:31] Fundraising-Backlog, fundraising-tech-ops: Don't send us all the cron spam - https://phabricator.wikimedia.org/T119452#1826810 (cwdent) maybe something like this? http://habilis.net/cronic/ [22:45:39] Fundraising Sprint X-Ray Spex, Fundraising Tech Backlog, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Patch-For-Review: Donation over $1000 throws error on comma in amount field (editing or creating) - https://phabricator.wikimedia.org/T118216#1826819 (LeanneS) @Eileenmcnaughton Yes, it... [22:47:13] Fundraising Sprint X-Ray Spex, Fundraising Tech Backlog, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Patch-For-Review: Donation over $1000 throws error on comma in amount field (editing or creating) - https://phabricator.wikimedia.org/T118216#1826822 (Eileenmcnaughton) Open>Resolve... [22:52:53] !log disable paymentswiki in config [22:52:57] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log, Master [22:54:37] awight saw your message - payments are messed up? [22:55:05] atgomez: It's all disabled at the moment. [22:55:19] I smell smoke coming from Jeff_Green's tardus [22:55:37] I turned off campaigns and put paymentswiki into maintenance mode... [22:56:07] He's aware of whatever is happening, and seems to be fixing rapidly. [22:56:15] ok. ccogdill sent an email back on the thread - we sent out 300k emails this morning [22:56:25] faaa [22:56:30] That's bad. [22:56:42] is it card processing only? [22:57:16] yeah this is peak time for that email [22:57:46] could we just funnel people who arrive on donate through paypal only? [22:58:33] or are the effect wider ranging? [22:58:42] hey. still piecing it together but it looks like network flap to the eqiad datacenter. [22:59:01] Seddon: I think we drop a message in the queue before we send them to paypal, so it would still error out [23:00:23] or... maybe we don't? [23:00:59] Seddon: It's theoretically possible to go straight to PayPal, but the banners aren't written that way. They redirect through paymentswiki. [23:01:45] awight_: correct but all of the email links would go to donate first would they not? [23:01:54] awight: correct but all of the email links would go to donate first would they not? [23:02:07] right. k we are screwed on that, then [23:02:32] amazing timing...what about that dfw datacenter? [23:03:53] bugger. yeah the setup isn't how I remember it [23:04:35] !log shutting down Jenkins [23:04:40] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log, Master [23:06:36] eileen1: While we're in this lifeboat and the playing cards are soaked--wanna continue that refunds conversation? [23:06:54] awight: :-) [23:07:47] awight: ok - so I kinda feel like if I can figure out how to make the hidden records more visible it will allow us to see if they are nice & consistent post-upgrade & how they look in different scenarios [23:08:02] you probably saw I got agreement that we could take longer to get it right [23:08:06] That makes me more inclined to use them ;) [23:08:10] ah, I missed that [23:08:48] What about the mechanics of making a refund the "new" way? [23:08:48] yeah - "don’t rush anything on our acount!" - seems a bit of a carte blanche :-) [23:09:03] so the new way is basically change the status to refunded [23:09:15] OK and that will create the financial line items? [23:09:18] & rely on getting the data out of the financial records [23:09:20] yeah - [23:09:29] the question is what reports it will affect [23:09:30] What if it's done accidentally, and he unrefunds? [23:09:39] yeah should try that [23:09:54] also, currently partial -refunds not looking available [23:09:55] Does it work if we set the contribution_status from code? [23:09:59] right [23:10:00] k [23:10:16] I guess we could do a query to see how often that happens [23:10:37] re setting from code - my guess is that is also something that needs looking at [23:11:25] but at least that is api based so we can ensure changes are nice & permanent :-) [23:11:29] (tests) [23:11:59] do you know which reports are used? how the aggregate data is accessed? [23:15:06] The only affected report that I know of is the custom "Gateway Reconciliation" report. [23:15:24] What will civicrm_contribution.total_amount look like, though? 0? [23:16:08] We do lots of direct queries on total_amount, but I'm pretty sure it's fine if this column is either zeroed for refunds, or if two records with + and - exist [23:16:27] awight: I can look more at that report I wonder if the ad hoc reports by ccogdill or the lybunts would be affected - [23:16:33] Gateway Reconciliation is the exception only because we group by <>0 [23:17:09] I think the key thing is to exclude contribution_status = Refund where you are looking for paid amounts [23:17:18] eileen1: I can (new) refund some of my contributions on staging to see what the db looks like [23:17:22] but, the partial-refund / over-refund is still an issue [23:17:36] OK - or else wait until I've had a go at the UI stuff [23:17:51] I'm not convinced we need to exclude status=refunded [23:18:13] -- unless total_amount will be + with no - record to offset it [23:18:23] which I believe IS the new way [23:19:03] there are negative financial transaction lines tho [23:22:42] Jeff_Green: sorry to pile on more pressure, but pls give us an update when you can [23:28:27] !log reenabling fundraising-jenkins jobs [23:28:31] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log, Master [23:29:11] !log reenabling paymentswiki [23:29:15] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log, Master [23:30:12] the-wub, do we have any existing templates on donate wiki that will all redirecting people direct to paypal and bypassing payments? [23:30:21] allow* [23:30:21] !log campaigns reenabled [23:30:25] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log, Master [23:30:27] Seddon: I think we're good now... [23:30:40] Seddon: nope, nothing like that [23:31:19] the-wub, although not needed now its something probably worth looking into for fall back of absolute last resort [23:31:32] awight update emailed [23:31:33] Seddon: I think we need to go thru Payments so we get all the logs and stuff in our DB [23:31:36] especially for email campaigns [23:31:55] eek, looks like I missed some fun... [23:31:55] Jeff_Green: Thanks! [23:32:14] the-wub, just a bit :P [23:32:55] Seddon: please make Phabricator task, sounds like a prudent discussion to have... [23:33:54] awight, will do [23:34:33] Although we're very attached to this thinking box [23:34:55] awight, thinking box? [23:35:38] Seddon: https://www.youtube.com/watch?v=5srwCNx2Ti0 [23:37:21] awight: definitely not getting the cultural reference there :P [23:37:57] hehe. um I was trying to dress up a cliche. Yes, please do think outside our greasy cardboard box, we've been living alone in here for far too long... [23:40:57] awight: I'm going to look at that dedupe query issue this afternoon & look more at refunds tomorrow I think [23:41:17] ok! [23:41:23] awight: Well its bringing back a very old way of doing things actually :P its how Wikimedia UK used to do their donations and possibly even the foundation in the depths of time. Its not ideal because you'd have to do alot of work to retain the tracking information. But it's the workflow of least dependence. Far from ideal but when all has gone to shit its better than having nothing [23:42:11] yeah we have more than one SPOF actually. We're hoping to fix two of them early next year, but it would be really nice to have some totally independent workflows [23:43:53] eileen1: ouch--it seems to take forever to refund using contribution_type [23:44:35] awight: yeah MBeat mentioned that - I was going to dig into that too [23:45:11] ok [23:45:54] (PS2) Ejegg: minor adyen iframe css changes [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/254874 (owner: Cdentinger) [23:46:11] the reason I'm worried about the other one is the think I copied in bold into the comments https://issues.civicrm.org/jira/browse/CRM-17454 [23:46:19] (CR) Ejegg: [C: 2] "Looks like a match for the rest of the form" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/254874 (owner: Cdentinger) [23:46:28] yes! I completely agree, sorry to distract from that [23:46:48] I also want to write a blog onto CiviCRM.org talking about performance [23:47:01] explaining what things to watch out for etc [23:47:03] ;-) thanks for giving the dead canaries a voice [23:47:03] (Merged) jenkins-bot: minor adyen iframe css changes [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/254874 (owner: Cdentinger) [23:47:38] ejegg: So, I was stalling on failing tests, want me to force merge? [23:52:18] awight: oh, right! [23:52:24] lemme peek at those tests [23:52:58] (PS1) Eileen: CRM-17464 remove deadlock inducing query [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/255048 (https://phabricator.wikimedia.org/T119447) [23:53:19] (PS4) Ejegg: Replace rubbish data in currency code [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/254343 (https://phabricator.wikimedia.org/T119120) [23:54:15] awight: that gerrit just above *might* stop those deadlock failmails [23:54:21] (CR) jenkins-bot: [V: -1] Replace rubbish data in currency code [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/254343 (https://phabricator.wikimedia.org/T119120) (owner: Ejegg) [23:54:44] (it's already in 4.7) [23:54:50] grumble... wtftf is breaking there? [23:57:10] (PS2) Awight: CRM-17464 remove deadlock inducing query [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/255048 (https://phabricator.wikimedia.org/T119447) (owner: Eileen) [23:58:14] (CR) Awight: [C: 2] "Looks safe! Hooray for backporting!" [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/255048 (https://phabricator.wikimedia.org/T119447) (owner: Eileen)