[14:26:39] Fundraising-Backlog: donatewiki access for Trilogy - https://phabricator.wikimedia.org/T110038#1567464 (Pcoombe) NEW [15:09:19] (CR) Ejegg: [C: 1] "I like it! Update comment on line 44?" [extensions/CentralNotice] (campaign_mixins) - https://gerrit.wikimedia.org/r/233065 (owner: AndyRussG) [17:34:26] happy Monday everyone: https://www.youtube.com/watch?v=Q0z4bajiq8s [17:35:34] Nice [18:05:22] AndyRussG: CN question--if I specify ?country=BR in a Wikipedia URL, shouldn't that override my GeoIP cookie? [18:05:35] awight: yeppers! [18:05:59] awight: wfm! https://en.wikipedia.org/wiki/Main_Page?uselang=es&country=AR [18:06:16] Remember there might be other reasons you're not getting a campaign [18:06:21] hrm. I'm trying https://en.wikipedia.org/wiki/Main_Page?country=BR and don't see https://meta.wikimedia.org/w/index.php?title=Special:CentralNotice&subaction=noticeDetail¬ice=C1516_enBR_dsk_hi_FR [18:06:22] or banner [18:07:37] awight: maybe ur logged in? [18:07:54] naw [18:08:21] awight: I'm getting it fine when logged out [18:08:31] At least on Chromium [18:08:47] ok, must be cookie foolishness, I'll plug away at it [18:09:15] awight: u can check mw.centralNotice.choiceData and see what allocations are there [18:11:44] looks like, reset=1 doesn't clear my seen counts [18:12:33] awight: eh that'd be the in-banner JS hookey sauce [18:12:46] just tried it logged out on Iceweasel, works fin [18:12:52] I think reset=1 is implemented by core CN [18:12:52] Maybe just delete ur hide cookie? [18:14:09] awight: don't see it via grep -ri reset [18:14:39] sorry--it's indeed in banner js hokiness [18:14:56] hokey hookiness? [18:17:00] ejegg: yes, hokey hooks! [18:17:11] do the hokey hooky [18:17:15] that's what it's all about! [18:18:54] awight: ejegg: don't forget the remaining minipatches on the CN feature branch, mostly CR follow-ups, that I think probably should go before any patch to merge feture to master :) [18:19:09] (and many thx in advance) [18:19:51] yep, just +1ed the fuzz increase with a comment on a comment! [18:20:56] ^ about that timestamp fuzzing. Why did you choose to fuzz rather than round? [18:21:00] me reads CR [18:21:56] I have a lunch meeting that will likely run late. I will probably miss standup [18:22:21] however, Anne wanted to do some estimation [18:22:35] AndyRussG: My uninformed thoughts about the fuzzing is that it's unnecessary complexity, possibly fragile, and not clear when we're interpreting the statistics [18:23:51] Is this something ewulzcyn suggested? [18:24:17] awight: nope it's my own frankenidea [18:24:25] afik [18:24:42] what's the rationale? [18:25:08] awight: just what's commented in the code. This shouldn't be ever linked to info about what people are reading or writing, cos we don't want to know that [18:25:17] I mean, I understand the privacy concern, but why fuzz? [18:25:35] 'cause a precise timestampe could be linked to precise timestamps in the web log [18:25:39] web server logs [18:25:53] Yes, that part makes sense [18:26:07] But the fuzzing seems like it will make interpreting results really twitchy. [18:26:34] Like, timestamps will often precede the beginning of a campaign [18:26:50] So rounding... to the nearest minute? or the nearest timestamp ending in two zeros? [18:26:58] hehe. donno [18:27:43] I'm fine with this going out as is, but I'd like to hear what Ellery prefers [18:28:04] I think statswise it's just a known degree of uncertainty... yes, you're right, though, we should check it with our end suer [18:28:05] user [18:28:18] * awight takes out legal insurance [18:28:39] heh [18:29:17] (PS2) Awight: BannerHistoryLogger: anticipate RL resources for sendLog() [extensions/CentralNotice] (campaign_mixins) - https://gerrit.wikimedia.org/r/233057 (owner: AndyRussG) [18:29:50] cwdent: morning! sorry I also meant to include you above when I pinged people about small patches remaining on the CN feature branch :) Also, I'm CRing your tests, just have a meeting starting in a sec so I'll finish that up a little while after that [18:30:08] thanks AndyRussG! [18:30:27] couldn't rounding timestamps have the same problem? things get rounded outside the campaign duration [18:30:41] (CR) Awight: [C: 2] BannerHistoryLogger: anticipate RL resources for sendLog() (1 comment) [extensions/CentralNotice] (campaign_mixins) - https://gerrit.wikimedia.org/r/233057 (owner: AndyRussG) [18:30:51] yeah totally [18:31:04] also, we're relying on the client-side clocks [18:31:22] so +/- 10 years [18:31:45] yeah...we rely on a lot of client side stuff, but i think it's the most honest way to collect stats [18:31:46] (Merged) jenkins-bot: BannerHistoryLogger: anticipate RL resources for sendLog() [extensions/CentralNotice] (campaign_mixins) - https://gerrit.wikimedia.org/r/233057 (owner: AndyRussG) [18:31:48] (CR) Awight: [C: 2] Merge branch 'master' into campaign_mixins [extensions/CentralNotice] (campaign_mixins) - https://gerrit.wikimedia.org/r/233059 (owner: AndyRussG) [18:32:06] you can't show people what you're doing without letting them potentially mess with it [18:32:14] (PS2) Awight: BannerHistoryLogger: comment about temp measure for minification [extensions/CentralNotice] (campaign_mixins) - https://gerrit.wikimedia.org/r/233067 (owner: AndyRussG) [18:32:46] (CR) Awight: [C: 2] BannerHistoryLogger: comment about temp measure for minification [extensions/CentralNotice] (campaign_mixins) - https://gerrit.wikimedia.org/r/233067 (owner: AndyRussG) [18:32:53] (Merged) jenkins-bot: Merge branch 'master' into campaign_mixins [extensions/CentralNotice] (campaign_mixins) - https://gerrit.wikimedia.org/r/233059 (owner: AndyRussG) [18:33:13] (PS2) Awight: BannerHistoryLogger: Increase random shift of timestamps [extensions/CentralNotice] (campaign_mixins) - https://gerrit.wikimedia.org/r/233065 (owner: AndyRussG) [18:33:18] (PS3) Awight: BannerHistoryLogger: Increase random shift of timestamps [extensions/CentralNotice] (campaign_mixins) - https://gerrit.wikimedia.org/r/233065 (owner: AndyRussG) [18:33:41] (Merged) jenkins-bot: BannerHistoryLogger: comment about temp measure for minification [extensions/CentralNotice] (campaign_mixins) - https://gerrit.wikimedia.org/r/233067 (owner: AndyRussG) [18:34:14] (CR) Awight: BannerHistoryLogger: Increase random shift of timestamps (1 comment) [extensions/CentralNotice] (campaign_mixins) - https://gerrit.wikimedia.org/r/233065 (owner: AndyRussG) [18:40:49] Fundraising-Backlog: Parse Amazon last name data differently (or: review the way we receive Amazon name data) - https://phabricator.wikimedia.org/T86720#1568642 (MBeat33) Could we modify the Civi import so that //if there is only a single initial// after the first name (or a single initial plus a period), it... [18:53:28] Fundraising Tech Backlog, Fundraising-Backlog: CiviCRM interface for repairing damaged recurring contributions - https://phabricator.wikimedia.org/T110095#1568737 (awight) NEW a:awight [18:55:41] Fundraising Tech Backlog, Fundraising-Backlog: CiviCRM interface for repairing damaged recurring contributions - https://phabricator.wikimedia.org/T110095#1568761 (awight) [19:01:34] (CR) Ejegg: "Suggestion for eliminating extra RT at the cost of optimizing for our particular production setup." (1 comment) [extensions/CentralNotice] (campaign_mixins) - https://gerrit.wikimedia.org/r/233057 (owner: AndyRussG) [19:07:41] MBeat: When you get the chance, I'm wondering how we're doing on GC status 600s... I deployed a change on Friday which hopefully stops us from accumulating new 600s, they should be resolved within an hour. [19:09:42] awight: GC600 raw #s: friday 528 (includes India); saturday 60; sunday 59 [19:09:54] ouch. [19:10:07] Those are all still in status 600? [19:10:18] Can you paste me one or two order IDs from Sat? [19:11:14] actually friday India was much better than the previous test, only half as much. Sat IDs include 694977779 3780768311 126572991 [19:11:57] brb [19:18:54] bassoon! [19:51:04] Fundraising Tech Backlog, Fundraising-Backlog: CiviCRM interface for repairing damaged recurring contributions - https://phabricator.wikimedia.org/T110095#1568978 (MBeat33) Thanks @awight - would this Civi button apply just to damaged reccurrings at status 600, or to any status 600 we needed to settle? [19:53:29] Fundraising Tech Backlog, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: CiviCRM interface for repairing damaged recurring contributions - https://phabricator.wikimedia.org/T110095#1568991 (atgo) What's the marked difference between doing this in Civi vs. in the GC console? [20:07:08] awight|fud: dstrine coming to standup? [20:30:19] awight|fud, ejegg you guys both wanna talk in 1/2 hour? [20:32:32] cwdent: shore [20:32:52] cwdent: can you paste me the xml output? [20:33:09] sure, one sec [20:40:53] Fundraising Tech Backlog, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: CiviCRM interface for repairing damaged recurring contributions - https://phabricator.wikimedia.org/T110095#1569098 (awight) @MBeat33: It would be difficult to have it apply to non-recurring status 600s, because those aren'... [20:52:54] Fundraising Tech Backlog, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: CiviCRM interface for repairing damaged recurring contributions - https://phabricator.wikimedia.org/T110095#1569116 (MBeat33) @awight, from DS's end there's no need to build it so that it applies to non-recurring 600s, I wa... [21:02:14] Fundraising Tech Backlog, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: CiviCRM interface for repairing damaged recurring contributions - https://phabricator.wikimedia.org/T110095#1569137 (awight) I don't think there's a way to do this from the Civi web ui--recurring contributions aren't very w... [21:38:55] cwdent: Hi! I'm finding some new flaky bugginess in the mixin tests... I hope it won't be too terribly frustrating for u that I suggest some additional changes there... ? [21:39:18] AndyRussG: please do! [21:39:19] rrrg... a few more things that I should have thought to take into account.... [21:39:28] cwdent: K! thanks and apologies!!! [21:41:09] no problem! i had a few problems i couldn't explain and definitely want to get to the bottom of it [21:41:47] cwdent: K will do! arrrg also gotta drive a bit again, back soon! [21:54:24] Fundraising-Backlog: [epic] Accept credit cards in France via Enhanced Silent Order Post - https://phabricator.wikimedia.org/T110111#1569235 (atgo) NEW [21:54:33] Fundraising-Backlog: [epic] Accept credit cards in France via Enhanced Silent Order Post - https://phabricator.wikimedia.org/T110111#1569242 (atgo) [21:54:58] Fundraising-Backlog: [epic] Internal testing with French credit cards - https://phabricator.wikimedia.org/T110112#1569244 (atgo) NEW [21:55:30] Fundraising-Backlog: [epic] 1 hour test in France - https://phabricator.wikimedia.org/T110113#1569250 (atgo) NEW [21:55:42] Fundraising-Backlog: [epic] campaign ready in France - https://phabricator.wikimedia.org/T110114#1569256 (atgo) NEW [21:56:40] cwdent: awight ejegg XenoRyet dstrine - here's a parent task for the ESOP work (yes, abbreving) https://phabricator.wikimedia.org/T110111 [21:56:57] i'm modifying the task that's in-sprint to include a request to break out an approach into these milestones. [21:57:00] thank you! [21:57:04] thanks atgo! [21:57:22] nice, thanks! [21:57:36] sweet task number, huh? [21:57:36] i just fired off an email to them, made modest progress [21:58:19] ...59 [21:59:25] errr [21:59:31] 55 :P [22:00:14] (CR) Krinkle: "This code adds both 'editcount' and 'pastyearseditcount'. While the latter is indeed no longer used, 'editcount' still is." [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/225669 (owner: Ori.livneh) [22:02:43] also cwdent fwiw, they plan to give us someone more senior to support :) [22:03:28] (CR) Krinkle: [C: 1] Remove dead code for targetting users based on UserDailyContribs data [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/225669 (owner: Ori.livneh) [22:04:06] atgo: nice! wmf clout does have some advantages [22:04:17] ha yeah... [22:04:27] and they sort of hosed us on this PCI thing [22:04:31] by not knowing anything [22:04:36] Hey, you earned it, by asking difficult questions like how do we freaking test [22:05:21] at sparkfun it was like "hrm i'm sorry our customer volume chart has you plotted in the no-one-cares-or-will-ever-care matrix" [22:05:35] have some stickers [22:12:12] :P [22:12:18] ooh maybe we could just give stickers! [22:36:27] this is what we're talking about with worldpay, cwdent :) [22:39:25] the email? [22:40:56] i wonder how many separate layers of dns caching there are between me and a website [22:41:32] cwdent: the email... totally. I did a little stomp snort and circle pace when I saw that. [22:41:48] "try the other number, which you already said doesn't work either" [22:42:01] OK SURE, let's do a two-hour call on the weekend, then [22:42:58] hehe well to be fair i don't think i actually mentioned that i tried that number [22:43:05] but i probably should have [22:44:36] https://www.youtube.com/watch?v=shwjITmIXWA [22:44:41] first 15 seconds, priceless. [22:48:07] thanks! [22:48:28] amazing [22:49:56] dns cache makin me rage [22:50:11] mebbe it's your router? [22:51:12] could be... [22:51:21] consumer grade POS [22:51:27] i had to come home earlier and kick it [22:51:53] going to a semipresentation, maybe back in a few mebbe not. [23:18:27] (PS2) Ejegg: WIP authorize and capture Amazon payment [extensions/DonationInterface] (amazon) - https://gerrit.wikimedia.org/r/231801 (https://phabricator.wikimedia.org/T108119) [23:18:59] (CR) jenkins-bot: [V: -1] WIP authorize and capture Amazon payment [extensions/DonationInterface] (amazon) - https://gerrit.wikimedia.org/r/231801 (https://phabricator.wikimedia.org/T108119) (owner: Ejegg) [23:22:05] ah dang, still no composer install in CI [23:26:22] (PS3) Ejegg: WIP authorize and capture Amazon payment [extensions/DonationInterface] (amazon) - https://gerrit.wikimedia.org/r/231801 (https://phabricator.wikimedia.org/T108119) [23:36:57] arg what was that global to force across-the-board non-minificationf for RL? [23:44:33] AndyRussG: is it debug=true? [23:44:57] cwdent: there's a config variable, so that grunt qunit will non-minify, too... [23:45:21] aah, i'm not sure in that case [23:46:38] Fundraising-Backlog, Astropay Integration, MediaWiki-extensions-DonationInterface: AstroPay 'deposit' error actually indicates a CPF problem - https://phabricator.wikimedia.org/T109918#1569653 (Ejegg) Apparently this is similar to 'user unauthorized due to cadastral situation'. We should treat it li... [23:47:47] cwdent: just trying to figure out an error I'm only getting in grunt qunit [23:48:09] cwdent: ah here it is: https://www.mediawiki.org/wiki/Manual:$wgResourceLoaderDebug [23:48:25] Heh that's so cryptic! [23:49:28] hahahah and with that set as true, the tests pass! [23:49:56] ohgod [23:50:00] brutal [23:52:57] cwdent: it actually looks similar to the problem we had before, of not being able to access a var from the enclosing context, hmmm [23:58:48] hmm maybe not...