[05:45:02] Fundraising-Backlog: Deploy 2015 Lila thank you email + typo fix for br-pt - https://phabricator.wikimedia.org/T110232#1636217 (jrobell) @atgo and tech team, Just re-confirming that all translations are finished, published on Meta and ready to be deployed. Here is the list of languages: # ca # zh... [10:27:23] TCB-Team-Fundraising-Sprint-2015-09-10, TCB-Team: [WMDE-Fundraising] Add validation api to the fundraising app - https://phabricator.wikimedia.org/T112063#1636629 (WMDE-leszek) a:WMDE-leszek [11:21:48] fundraising-tech-ops, Traffic, operations, IPv6, Patch-For-Review: Enable IPv6 on donate.wikimedia.org - https://phabricator.wikimedia.org/T73267#1636783 (Pcoombe) @jrobell AFAIK this change won't affect banners. The main sites already use IPv6, this change is only for donatewiki. Related: it s... [11:23:31] TCB-Team-Fundraising-Sprint-2015-09-10, TCB-Team: [WMDE-Fundraising] estimate effort: membership payment processing via ppl and cc and money transfer - https://phabricator.wikimedia.org/T112094#1636786 (kai.nissen) a:kai.nissen [12:17:24] fundraising-tech-ops, Traffic, operations, IPv6, Patch-For-Review: Enable IPv6 on donate.wikimedia.org - https://phabricator.wikimedia.org/T73267#1636967 (BBlack) We haven't had the time to devote to it yet, it's just a matter of scheduling and priorities. [13:31:04] Fundraising Tech Backlog, fundraising-tech-ops: Set up fr-tech permissions for Eileen - https://phabricator.wikimedia.org/T109765#1637205 (Jgreen) p:High>Normal [13:33:19] fundraising-tech-ops, Traffic, operations, IPv6, Patch-For-Review: Enable IPv6 on donate.wikimedia.org - https://phabricator.wikimedia.org/T73267#1637211 (Jgreen) a:Jgreen>BBlack [13:34:31] fundraising-tech-ops, operations: reformulate kafkatee package to work with Trusty - https://phabricator.wikimedia.org/T110591#1637217 (Jgreen) p:Normal>High [13:37:54] fundraising-tech-ops, Traffic, operations, IPv6, Patch-For-Review: Enable IPv6 on donate.wikimedia.org - https://phabricator.wikimedia.org/T73267#1637231 (jrobell) Thank you @Pcoombe, as this doesn't seem to affect banner campaigns, the planned Luxembourg and Belgium campaign just went up at 1.3... [13:38:39] fundraising-tech-ops, operations: package udp-filter for Trusty, for use on fundraising banner_logger - https://phabricator.wikimedia.org/T110592#1637236 (Jgreen) [13:38:41] fundraising-tech-ops: build librdkafka for Trusty - https://phabricator.wikimedia.org/T112139#1637234 (Jgreen) Open>Resolved built [13:39:22] fundraising-tech-ops, operations: package udp-filter for Trusty, for use on fundraising banner_logger - https://phabricator.wikimedia.org/T110592#1581705 (Jgreen) [13:39:24] fundraising-tech-ops, operations: build libanon package for trusty - https://phabricator.wikimedia.org/T110739#1637238 (Jgreen) Open>Resolved builds now [13:47:01] fundraising-tech-ops: build libcidr package for Trusty - https://phabricator.wikimedia.org/T110740#1637248 (Jgreen) Open>Resolved [13:47:02] fundraising-tech-ops, operations: package udp-filter for Trusty, for use on fundraising banner_logger - https://phabricator.wikimedia.org/T110592#1637249 (Jgreen) [13:52:07] fundraising-tech-ops, operations: package udp-filter for Trusty, for use on fundraising banner_logger - https://phabricator.wikimedia.org/T110592#1637263 (Jgreen) Open>Resolved compiles/builds fine now [14:07:23] Fundraising-Backlog: Record if a donation amount was chosen from one of the fixed amounts - https://phabricator.wikimedia.org/T92462#1637304 (Pcoombe) @awight That has the amount the donor picked, but not whether it was one of the fixed amounts (as opposed to using the 'Other' input box). I'm not 100% sure w... [14:15:55] Fundraising-Backlog: donatewiki access for Trilogy - https://phabricator.wikimedia.org/T110038#1637332 (Pcoombe) @awight We currently upload banner images to donatewiki. On Commons images can be overwritten by any random user, which is risky when they're being widely used in banners. If giving donatewiki ac... [15:00:11] Fundraising-Backlog: IDEAL drop on traffic (and not working for a few banks) - https://phabricator.wikimedia.org/T112533#1637454 (Ppena) NEW [15:06:16] Fundraising-Backlog: IDEAL drop on traffic (and not working for a few banks) - https://phabricator.wikimedia.org/T112533#1637505 (Pcoombe) A big drop in traffic is expected: we stopped running banners in NL on 1 Sep because of Wiki Loves Monuments. We should look into the bank issues though. [16:38:59] (CR) Cdentinger: worldpay ESOP (2 comments) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/234691 (owner: Cdentinger) [16:42:34] Fundraising-Backlog: IDEAL drop on traffic (and not working for a few banks) - https://phabricator.wikimedia.org/T112533#1637951 (atgo) @pcoombe is that a you thing or an fr-tech thing? [16:42:46] Fundraising-Backlog, Wikimedia-Fundraising: IDEAL drop on traffic (and not working for a few banks) - https://phabricator.wikimedia.org/T112533#1637955 (atgo) [16:43:14] Fundraising-Backlog, Wikimedia-Fundraising: IDEAL not working for a few banks - https://phabricator.wikimedia.org/T112533#1637959 (atgo) [16:43:28] Fundraising-Backlog, Wikimedia-Fundraising: IDEAL not working for a few banks - https://phabricator.wikimedia.org/T112533#1637454 (atgo) Updated task to reflect actual issue [16:49:55] hi awight, a few comments on the ESOP patch for your perusal [16:51:33] ok! [16:53:57] Fundraising-Backlog: Deploy 2015 Lila thank you email + typo fix for br-pt - https://phabricator.wikimedia.org/T110232#1638012 (atgo) Thanks @jrobell! We'll get it into the next sprint. [16:57:33] (PS4) Ejegg: optional address fields for mustache [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/234579 (owner: Cdentinger) [17:00:10] (CR) Ejegg: [C: 2] "Jenkins plz merge!" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/234579 (owner: Cdentinger) [17:00:34] (Merged) jenkins-bot: optional address fields for mustache [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/234579 (owner: Cdentinger) [17:00:52] (CR) Awight: worldpay ESOP (5 comments) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/234691 (owner: Cdentinger) [17:01:22] I didn't have much to say... Lmk if you want to bounce more ideas off someone. [17:01:49] (PS4) Awight: de-centralize mustache js [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/234584 (owner: Cdentinger) [17:03:26] thanks awight! [17:03:41] will push another PS soon getting rid of ternaries etc, just didn't want to pave over the comments [17:04:27] also made good shed progress this weekend: http://i.imgur.com/cLzMNA7.jpg [17:04:31] (CR) Ejegg: [C: 2] "Go-go-gadget gate-and-submit!" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/234584 (owner: Cdentinger) [17:05:05] (Merged) jenkins-bot: de-centralize mustache js [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/234584 (owner: Cdentinger) [17:19:32] ejegg: it looks like the iframe liberator is supposed to be generalized, but do you know if it will need to be built in for mustache? [17:19:51] fundraising-tech-ops, operations: reformulate kafkatee package to work with Trusty - https://phabricator.wikimedia.org/T110591#1638171 (Jgreen) >>! In T110591#1610291, @Ottomata wrote: > Done https://gerrit.wikimedia.org/r/#/c/236066/ > > http://apt.wikimedia.org/wikimedia/pool/main/k/kafkatee/ Minor bu... [17:19:59] cwdent: haven't looked at that stuff in a while! [17:20:20] i was just checking out GatewayPage and it seems like it should Just Work [17:20:26] nice! [17:20:58] should being the operative word [17:21:22] in handleResultRequest...i made a basic thanks page but it doesn't pop out of the iframe [17:21:58] no js errors or anything so i'm guessing it's just mustache tpl needs to include something? [17:21:59] ah, dang... let me take a look in a few [17:22:23] oh i can try to figure it out, just making sure it wasn't something known [17:25:46] Fundraising-Backlog, Wikimedia-Fundraising: IDEAL not working for a few banks - https://phabricator.wikimedia.org/T112533#1638199 (Pcoombe) It's an fr-tech thing. [17:29:23] * AndyRussG waves [17:29:50] Hey cwdent awight|stairs ... any wise thoughts on where to start with https://phabricator.wikimedia.org/T112022 ? [17:30:20] (CR) Ejegg: "chiming in with opinion, info, snark" (4 comments) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/234691 (owner: Cdentinger) [17:30:23] I was gonna make a test campaign on the beta cluster [17:30:30] ejegg: ^ [17:31:08] (a second ago when I looked, I thought I didn't see u online, sorry /me checks eyeglasses) [17:31:21] beta sounds good, I think [17:32:09] cool thx! Any ideas as to the actual technique? Do we want like a throbber or "processing..." message in case the EL call takes a while? [17:45:40] ejegg|mtg: are you able to hear us? [17:47:19] all good now dstrine, sorry for tech difficulties [17:47:37] it's cool .. I was just trying to find you [18:05:02] running some errands, back in a bit [18:07:57] Fundraising-Backlog: Deploy 2015 Lila thank you email + typo fix for br-pt - https://phabricator.wikimedia.org/T110232#1638378 (atgo) [18:22:01] (PS1) Legoktm: Add es5-shim dependency to ext.centralNotice.display [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/238205 [18:22:47] AndyRussG: ^ people are seeing exceptions in older browsers [18:23:48] legoktm: huh! thanks... That's something I should have heard of, I guess? [18:24:43] legoktm: any specifics on the errors? [18:24:55] AndyRussG: https://phabricator.wikimedia.org/T112552#1638401 [18:25:52] we support es3 browsers, so if you use es5 features, you need a dependency upon the shim [18:26:07] according to the table, it should also throw an exception in IE8 [18:27:02] legoktm: ahhhrg K let's get a fix out ASAP [18:28:13] someone might also want to audit the other modules, I only glanced at that one because of the bug report [18:28:33] I think it's the only instance of the use of that specific feature, at least [18:28:58] legoktm: how big is es5-shim? since this is code that we want to run as early as possible, we could aslo just do something a bit different instead of defineProperty [18:29:13] * AndyRussG checks bytecount [18:30:01] AndyRussG: it only loads on browsers that are not es5 compliant [18:30:20] there's RL magic to make it not load on modern browsers [18:30:33] Hmm! [18:34:39] legoktm: K! Smoke testing ur patch now... I'll ask to have it on today's SWAT [18:35:35] awesome, thanks :) [18:37:31] legoktm: same! ;) [18:40:10] (PS13) Ejegg: Handle results of Amazon API calls [extensions/DonationInterface] (amazon) - https://gerrit.wikimedia.org/r/233993 (https://phabricator.wikimedia.org/T108123) [18:42:26] Fundraising-Backlog: Deploy 2015 Lila thank you email + typo fix for br-pt - https://phabricator.wikimedia.org/T110232#1638550 (jrobell) Thank you @atgo. (cc @Pcoombe) I want to clarify that we want the editing link to go to the sign up page: [https://en.wikipedia.org/w/index.php?title=Special:UserLogin&ret... [18:45:01] legoktm: looks like es5-shim doesn't really cover defineProperty: https://github.com/es-shims/es5-shim https://kangax.github.io/compat-table/es5/#Object.defineProperty [18:45:42] hrm [18:45:46] its in the sham? [18:46:08] might be better to avoid using it entirely then [18:46:09] sham shim? [18:49:41] legoktm: ejegg: yeah it says "May fail" https://github.com/es-shims/es5-shim#may-fail [18:49:47] :| [18:49:56] well I have no idea then [18:50:32] It's not an absolute necessity... We can avoid it, or maybe check if it's available? looking... [19:17:26] (PS6) Ejegg: PayWithAmazon IPN listener [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/237313 (https://phabricator.wikimedia.org/T109649) [19:42:15] ejegg: my local copy of this gerrit branch doesn't seem to know that those two WIP commits were merged [19:42:31] do you have a good process for this? [19:43:21] cwdent: yeah, I switch back to master, pull, then rebase -i my local branch onto local master [19:43:41] dropping any duplicates [19:43:41] great, thanks [19:43:44] yeah [19:44:32] cwdent: slowly catching up on backscroll--you shouldn't make a TY page. You'll want a ResultSwitcher, which will do the iframe liberation and will redirect to the TY [19:44:45] It relies on some session variables existing, fwiw... [19:44:52] awight: ok i did start down that path [19:44:56] looking at the GC one [19:45:21] how do you call the result switcher instead of the page? [19:45:24] AndyRussG: I think the place to start on T112022 is just to get the extra URL parameter to pass through to paymentswiki. [19:45:43] cwdent: it's a normal Special page [19:46:17] grep for GlobalCollectGatewayResult [19:46:18] awight: WP currently uses the presence of the OTT param on the url to decide whether it's coming back. Should we be changing that here? [19:46:32] awight: yeah! working on that for a test banner on beta clust. Just got distracted by an incoming ie8 bicho [19:46:35] aah hmm [19:46:39] ejegg: yeah that was a bad idea, cos inconsistent with the other gateways [19:46:44] k [19:46:47] I think I made a similar mistake in Amazon [19:46:57] awight: my main wonder was what the best technique for page-away-from-navigation when sendBeacon isn't avail [19:47:03] aah [19:47:12] wait [19:47:24] yeah, Amazon's still a freak [19:47:25] those are two different things, right? [19:47:56] I mean, eventLogging has a fallback, and we use EL, but we need to delay navigating away when the fallback is used [19:47:58] AndyRussG: are you trying to do the banner ID thing in the background? I was imagining we would add that to the redirect URL [19:48:06] AndyRussG: you're talking about onunload for the donation click? [19:48:23] ejegg: yep [19:48:51] awight: we need to make sure the fallingback version of the event log gets through [19:49:08] ah just remembering now, there's a phab task w/ an example of a shim someone else's using! [19:50:03] AndyRussG: That's a different task though? [19:50:11] Isit? [19:50:49] we should definitely cap the delay at something conservative [19:51:11] don't want to make 'em wait to donate! [19:51:19] ejegg: mmm conservative from which point of view? ahh OK yes [19:51:26] AndyRussG: I ask cos I don't see how eventlogging or sendbeacon is related to https://phabricator.wikimedia.org/T112022 [19:51:40] ...other than, you need the banner history data to make it back to our server [19:52:03] awight: well, yes, that's it, exactly [19:52:23] we have to log specifically when they click on donate [19:52:54] love that the commit msg text box in gerrit doesn't add line breaks [19:52:54] awight: we don't know we have to sample them at 100% until they click [19:52:59] we have some fug history in DI now [19:53:21] arrrg I have my brain in this silly ie8 bug, should be done in a few [19:53:31] Got it, thx. I'll make a note of this in the task [19:54:13] Fundraising Sprint Snoop (Dogg|Lion), Fundraising-Backlog: Associate banner history ID with contribution ID - https://phabricator.wikimedia.org/T112022#1638858 (awight) Note that we have to send the banner history data back whenever a donation is made, i.e. anyone who donates is suddenly sampled at 100%. [19:55:33] awight: thx! [19:55:40] what is fug? [19:55:52] frightfully ugly [19:55:54] food und garden? [19:56:00] ejegg: good tip on the update/rebase, that was totally painless [19:56:18] woot! I <3 rebase -i [19:57:03] now i'm going to push all the interim master stuff up to the gerrit branch...should i do that or just create a new change? [19:57:53] cwdent: aren't your changes merging to master? [19:58:37] well, those two did, i think the review branch is just missing the stuff that happened to master while those two were in review [19:59:05] so it gives me that "you're about to push a bunch of changes" [19:59:09] but i think that's ok? [19:59:35] ah darn, I don't think it should be doing that [19:59:53] it would be easy to just make a new change [20:00:14] did the rebase save the exact same commits that merged to master? [20:00:43] so, 2be9476681edf43caed683bf86bb23b260dae097 for decentralize mustache? [20:01:22] yep! i think my local branch is all good [20:01:27] just the remote change is confused [20:01:44] huh. I think git review should know which ones are in origin / master now that you've fetched it all [20:02:04] yeah it seems like it should [20:03:12] what does git log origin/master..HEAD say? [20:03:17] oop, standup [20:06:52] Fundraising Sprint Snoop (Dogg|Lion), Fundraising-Backlog, MediaWiki-extensions-CentralNotice, Unplanned-Sprint-Work: Version banner history log - https://phabricator.wikimedia.org/T112015#1638904 (DStrine) a:Ejegg [20:09:41] ejegg: atgo: cwdent: XenoRyet: awight: https://phabricator.wikimedia.org/T112552#1638401L [20:22:12] (PS2) Ejegg: Add version to banner history log entries in KV store [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/236069 [20:23:03] https://www.youtube.com/watch?v=yaHOvWMPeJA [20:23:07] ejegg^ [20:23:18] thanks! [20:30:29] ejegg: K4's on vacation [20:30:33] oh right, K4|vaca! [20:30:51] yep [20:31:01] (I also normally have mine today, too...) [20:31:03] with long As [20:32:20] AndyRussG: you're saying you have the same error as in https://phabricator.wikimedia.org/T112552#1638401 ? [20:32:27] so review branches do not actually track remote branches? [20:32:59] cwdent: nope. you can push a sandbox/cwdent/* branch if you'd like, though. [20:33:01] so AndyRussG should this one be int he seprint? [20:33:14] cwdent: i'll start an email to get some french cards for testing :) [20:33:39] atgo: sounds good! [20:34:13] awight: i can't imagine what gerrit is using to group patch sets that is "better" than branches [20:34:48] bastards. More free software calculated to destroy the FLOSS movement [20:37:33] cwdent: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/DonationInterface,branches [20:38:58] will let you create a new persistent gerrit branch [20:39:17] then you update your .gitreview to send changes along that one [20:39:57] ejegg: can you then just push to that branch? [20:40:30] in DI no, it's the same merge rules [20:40:32] cwdent: Is this a long-lived feature thing, or just your work? [20:40:42] just my work [20:40:49] then u should use a sandbox branch [20:40:59] oh yeah, i wouldn't advise it for right now [20:41:06] https://www.mediawiki.org/wiki/Gerrit/personal_sandbox [20:41:06] just saying if you needed to, that's how [20:41:19] right on [20:41:57] ah so maybe this is why remote doesn't understand my rebased local branch [20:42:01] because there is not remote branch? [20:42:05] *no [20:42:56] awight: no, I don0t have the error. It's reported in ie8. Just this one: Exception in module-execute in module ext.centralNotice.display: [20:42:56] TypeError: Object.defineProperty is not a function TypeError: Object.defineProperty is not a function message=Object.defineProperty is not a function [20:43:08] nah, git review knows it's pushing refs for review to master, so it compares with that [20:43:19] atgo: it's as u wish, it could be a 1-pointer. We do need to deal w/ it [20:43:22] did you try git log origin/master..HEAD ? [20:43:50] yeah, it looks right, just that one commit different [20:43:51] awight: ejegg: I'm just smoke testing the patch I have to make sure it doesn't break stuffs [20:43:53] the esop one [20:44:41] cwdent: ugh, if you can see that in the log I'm suprised git review is still complaining. [20:45:07] git review is just warning about submitting your own patches, right? [20:45:30] no it's everything that's happened to master since these went into review [20:45:34] the mustache ones [20:45:55] i think anyway [20:45:58] goes back to b4391a7 [20:45:59] so all the translation updates and everything? [20:46:25] yep [20:46:40] git status on master says you're even with orgin/master? [20:46:52] yep! [20:47:03] cwdent: try git fetch --all [20:47:05] and rebase -i on your work branch should just show your esop patch [20:47:14] this is about your local "gerrit" branch being behind [20:47:35] awight: he started by checking out master and pulling [20:47:37] or sorry--your local copy of the gerrit remote [20:47:48] yeah but pulling only fetches the origin remote [20:48:06] (PS12) Cdentinger: worldpay ESOP [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/234691 [20:48:12] ah ha [20:48:20] oh, I never use a 'gerrit' remote [20:48:23] the easy way to check is to just fetch --all, and see if there's any activity when downloading the gerrit remote [20:48:33] ejegg: really? It's set up by git review -s [20:48:40] what is the difference between the gerrit remote and origin?? [20:48:41] how do you avoid it? [20:48:49] cwdent: try "git remote -v" [20:48:49] huh, guess I got rid of it? [20:49:17] idgi [20:49:27] e.g. I have origin = https://gerrit.wikimedia.org/r/p/mediawiki/extensions/DonationInterface.git and gerrit = ssh://awight@gerrit.wikimedia.org:29418/mediawiki/extensions/DonationInterface.git [20:49:27] why have two? [20:49:28] All I have is origin (points to gerrit) and a remote on my VPS to sync dev work [20:49:53] I don't see how git review works for you, then. do you just push to the remote manually? [20:50:16] nope, just 'git review' [20:50:22] somehow it figures it out! [20:50:23] O_o [20:50:38] gerrit ssh://cwdent@gerrit.wikimedia.org:29418/mediawiki/extensions/DonationInterface.git (fetch) [20:50:40] gerrit ssh://cwdent@gerrit.wikimedia.org:29418/mediawiki/extensions/DonationInterface.git (push) [20:50:42] * ejegg rummages around in ~/.gitconfig [20:50:42] origin ssh://cwdent@gerrit.wikimedia.org:29418/mediawiki/extensions/DonationInterface (fetch) [20:50:44] origin ssh://cwdent@gerrit.wikimedia.org:29418/mediawiki/extensions/DonationInterface (push) [20:51:27] morning [20:51:30] That looks fine [20:51:33] eileen_: hi! [20:53:26] Is a Yubikey a bit of hardware? If so I don’t have it... [20:54:03] You should email Jeff_Green to check on that. It's one of these, https://www.yubico.com/products/yubikey-hardware/ [20:54:11] Needed for 2-factor auth on our servers. [20:54:39] hi eileen, ya OIT should have sent you a yubikey [20:54:48] ah right, OIT thanks [20:54:54] eileen_: techsupport@wikimedia.org [20:55:01] awight: aren't those the same thing? [20:55:07] Jeff_Green: I can recheck the laptop packaging again but I didn’t see anything in there [20:55:18] gerrit and origin in this case? [20:55:22] totally, but I'm sure git maintains them as two separate copies [20:55:30] heh [20:55:35] so what is origin for? [20:55:44] eileen_: if you ping techsupport@ they can either track the package or tell you it was included somewhere [20:57:19] Jeff_Green: ok thanks [20:57:35] & I need that before I can access the CiviCRM instance I think? [20:58:07] http://arstechnica.com/science/2015/09/wikigate-raises-questions-about-wikipedias-commitment-to-open-access/ [20:58:08] so, i don't have defaultremote=origin in any kind of config, but git-review still uses it. maybe the default changed? the man page doesn't say anything about the default value [21:00:18] Fundraising Sprint Snoop (Dogg|Lion): Fix error for non-ECMA5 browsers in ext.centralNotice.display - https://phabricator.wikimedia.org/T112590#1639178 (AndyRussG) NEW a:AndyRussG [21:01:29] Fundraising Sprint Snoop (Dogg|Lion), MediaWiki-extensions-CentralNotice, Unplanned-Sprint-Work: Fix error for non-ECMA5 browsers in ext.centralNotice.display - https://phabricator.wikimedia.org/T112590#1639194 (AndyRussG) [21:01:31] atgo: https://phabricator.wikimedia.org/T112590 [21:01:39] (not sure if I did that right) [21:01:46] what's that? [21:01:48] the bug? [21:01:54] Fundraising-Backlog: Recent iframe errors from up-to-date browsers - https://phabricator.wikimedia.org/T112181#1639197 (MBeat33) [21:01:54] looks great, thank you for tracking :) [21:03:12] eileen_: Did someone get back to you on a private channel? [21:03:32] re yubikey? [21:04:25] u need a cloak btw, https://meta.wikimedia.org/wiki/IRC/Cloaks [21:04:42] That's what we rely on to not give out private info to doppelgangers :) [21:06:16] atgo: it's a new task that I created. Thanks! Yeah, I saw that that the task where the issue was reported (in a commnet) is a lot broader [21:13:55] https://www.mediawiki.org/wiki/Gerrit/Advanced_usage#git_review_complains_about_multiple_commits [21:13:58] TIL git review -u [21:17:54] (PS1) AndyRussG: Fallback for browsers that don't support Object.defineProperty [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/238326 (https://phabricator.wikimedia.org/T112590) [21:19:32] (CR) jenkins-bot: [V: -1] Fallback for browsers that don't support Object.defineProperty [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/238326 (https://phabricator.wikimedia.org/T112590) (owner: AndyRussG) [21:20:22] aaaarg [21:30:47] cwdent: Minor thing, please link patches to the Phabricator tasks e.g. https://phabricator.wikimedia.org/T110423 [21:31:21] The easiest way is to add "Bug: T110423" in the commit msg [21:32:52] cwdent: Was PS12 just a rebase, or are there code changes? [21:33:08] awight: i just got rid of those ternaries [21:33:21] sorry i need to start making new patchsets for this [21:33:42] whatever's easiest. the only rule is to not mix rebasing with code changes... [21:33:55] oops! [21:33:58] will remember [21:34:05] there was ONLY ONE rule [21:34:05] :p [21:34:06] Fundraising-Backlog: Recent iframe errors from up-to-date browsers - https://phabricator.wikimedia.org/T112181#1639305 (Ejegg) In the second screenshot, the lack of styling makes it look like some necessary parts of the page didn't load. Just reloading might help there. Nothing looks obvious from the first... [21:34:17] * awight wonders if I skipped lunch [21:34:18] * cwdent dejected [21:36:38] awight: sorry i'm still a little confused about the special page workflow [21:37:07] do i need basically globalcollectresultswitcher&popout_if_iframe? [21:37:08] (CR) Awight: worldpay ESOP (2 comments) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/234691 (owner: Cdentinger) [21:38:29] cwdent: yeah, maybe push globalcollect_gateway/globalcollect_resultswitcher.body.php popout_if_iframe into the base class? [21:38:56] yeah i was thinking of that [21:39:04] there is already iframe code in there [21:39:05] (CR) Awight: [C: -1] "I'm only blocking on the IsHosted=1 thing, it will definitely break the non-iframe flow." [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/234691 (owner: Cdentinger) [21:39:06] gatewaypage [21:39:30] it's horrible. But at least if all our messes are in one place, we can have a burn day some time soon [21:39:44] yeah [21:40:00] btw i'm pretty sure there are other things in here that will break the non-iframe flow [21:40:21] one thing i know if is the old form gets both stylesheets and looks like crap [21:40:23] I know, we need tests that catch regressions [21:40:57] Can you file a bug about repairing the wmf-hosted WP flow, and note anything you discover there? [21:41:18] yeah definitely [21:41:27] (CR) Awight: [C: 2] "Okay, we've decided to break the old flow for now, but note to self to fix it." [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/234691 (owner: Cdentinger) [21:41:34] thanks! [21:41:46] i feel like there are limitations to how much we can currently have two workflows in one adapter [21:42:09] I think we should improve the platform until that's easier to do [21:42:13] a few things i haven't been able to find a way to make divergent cases for [21:42:17] yeah [21:42:41] (Merged) jenkins-bot: worldpay ESOP [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/234691 (owner: Cdentinger) [21:42:53] oh man [21:42:55] is it really time? [21:43:16] well we don't deploy master on DI do we? [21:43:59] You wannt deploy? Be my guest [21:44:22] it's the "deployment" branch, then you bump the submodule pointer on mediawiki-core fundraising/REL1_25 [21:44:36] cool [21:45:19] dude from WP wants me to fire a live req. i guess this just means swapping the creds and removing the test flag? [21:45:28] Yeah that should do it [21:45:43] There might be whitelisting issues, but going through the full VPN tunnel should do the trick. [21:46:18] cool, well i'm waiting on some french cards anyway so i'll try to get this resultswitcher wired up in the mean time [21:51:46] (CR) Ejegg: [C: -1] "Looking good! Please add Trilogy to the dropdown in wmf_reports/CRM/Report/Form/Contribute/GatewayReconciliation.php. Could also add Tr" (4 comments) [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/237864 (https://phabricator.wikimedia.org/T101191) (owner: XenoRyet) [21:53:49] AndyRussG: I edited down the commit message on that log thing [21:54:22] ejegg: woohoo! Thanks sorry to be such a censorous nitpick [21:54:36] (CR) Awight: "Wow, you caught almost all the frayed ends!" (2 comments) [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/237864 (https://phabricator.wikimedia.org/T101191) (owner: XenoRyet) [21:55:04] AndyRussG: you mean consciencous steward of the code history? [21:56:58] ejegg: heheh dictatorial party hack from a government-sponsored unthink tank? [21:57:20] O_O [22:00:07] heh [22:01:17] ejegg: So... what do you think about SmashPig as a framework? [22:01:37] (PS2) AndyRussG: Fallback for browsers that don't support Object.defineProperty [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/238326 (https://phabricator.wikimedia.org/T112590) [22:01:59] awight: needs some questioning of assumptions [22:02:02] yeah... [22:02:15] I think it's resulting in really garish spaghetti code [22:02:52] Sounds tasty! >_> [22:02:53] It's optimized for the SOAP case, which farms much of the responsbility for parsing messages out to an external library [22:03:17] hehe hopefully soap makes it too bitter for the neighborhood animals to eat and get sick [22:04:35] even with the PwA SDK doing a similar role, the enforced order of 'build a list of these, then do these specific steps' doesn't quite fit [22:04:47] Yeah. I think we need to tear down and rebuild [22:04:58] The rolled-in mini framework libraries kill me, too [22:05:18] There's lots of nice existing stuff we can lean on to do logging and configuration. [22:05:19] you mean symfony? [22:05:29] oh, right, the config stuff is... interesting [22:05:33] hehe [22:05:37] @wat [22:05:50] what % of the api responsibilities does smashping hold vs DI? [22:06:07] So far, SmashPig is only used for IPN processing [22:06:09] https://duckduckgo.com/?q=%22garish+spaghetti%22&t=ffsb [22:06:43] AndyRussG: I think those two flavors have been shown to have overlapping territory [22:07:05] Heh right! [22:07:09] and some audit file parsing! [22:07:35] is IPN analogous to the other processors? [22:07:44] I don't want to move more things into SP until we clean up the mess.... [22:07:48] or is it a whole other thing? [22:12:21] cwdent: IPN is instant payment notifications [22:13:07] ooh, ddg turned up "intuit payment network" [22:13:11] i thought it was a processor [22:13:15] a way for the processors to tell us when something async has completed [22:13:22] gotcha [22:13:22] Sorry. We sorely need a glossary [22:14:28] Smashpig listens on a particular url for each gateway, and transforms notification POSTs from the processors into messages for the CRM queue consumer [22:15:26] (PS3) AndyRussG: Fallback for browsers that don't support Object.defineProperty [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/238326 (https://phabricator.wikimedia.org/T112590) [22:17:24] what's the deal with vendor/composer/autoload_classmap.php vs. stuff defined in DI as $wg* ? [22:17:50] i'm making this result page...i see some subclasses get loaded in vendor...but not astropay which also has a custom one [22:18:20] cwdent: Good question. We added let composer build the classmap for running DonationInterface under Drupal [22:18:21] cwdent: the stuff in classmap is what we explicitly include in our composer.json [22:19:28] (CR) AndyRussG: "Thanks much!! I fear this may not work... See also I2fdfda11..." [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/238205 (owner: Legoktm) [22:19:39] ooh ok [22:20:36] (Abandoned) Legoktm: Add es5-shim dependency to ext.centralNotice.display [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/238205 (owner: Legoktm) [22:21:43] (CR) Awight: "Some questions before I merge..." (9 comments) [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/237313 (https://phabricator.wikimedia.org/T109649) (owner: Ejegg) [22:23:41] Fundraising Sprint Rowlf the Dog, Fundraising Sprint Snoop (Dogg|Lion), Fundraising-Backlog, Recurring-Donations, Patch-For-Review: GC error causing donors to create multiple recurring donations - https://phabricator.wikimedia.org/T110367#1639471 (awight) Pinging on this--turns out we can't clo... [22:29:05] (CR) AndyRussG: [C: 2] "Woohoo!! Thanks much :)" [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/236069 (owner: Ejegg) [22:33:03] (Merged) jenkins-bot: Add version to banner history log entries in KV store [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/236069 (owner: Ejegg) [22:33:35] Fundraising-Backlog: Recent iframe errors from up-to-date browsers - https://phabricator.wikimedia.org/T112181#1639513 (MBeat33) Thank you @ejegg, I've asked the donors to take these steps and we'll see what they come back with. [22:36:58] awight, ejegg i think i see the problem [22:37:05] correct me if i'm wrong [22:37:19] Which problem? [22:37:37] it looks like since they return with the token in the URL that isProcessImmediate fires and doesn't go down the path that would liberate from the iframe [22:38:25] sorry, just trying to get it to pop out of the iframe [22:38:51] oh, huh. that should be working the same as before, i thought [22:39:08] I guess the fix is to override isProcessImmediate to have better judgement? [22:39:46] awight: yeah i think so? i can put some logic in the adapter that checks isESOP [22:42:06] awight: except...don't we want it to immediately process? [22:43:19] That... sounds right :) [22:43:22] lemme see... [22:47:24] cwdent: What class are u looking at? There's no resultswitcher page in the master branch [22:47:42] awight: yeah i just made it locally [22:47:58] but i basically copied the business part of GC resultswitcher [22:48:25] but the resultswitcher doesn't get built on the last request because isProcessImmediate [22:48:35] if i'm understanding this [22:49:26] We should be fine processing the request, doing API calls if necessary, and then popping out of the iframe [22:50:05] Might need to shuffle the logic as it appears in GC--although that would be surprising, I think GC has the same workflow after we return from the iframe. We need to do final fraud checks, settle the payment, then pop out of the iframe. [22:50:27] looks like isProcessImmedate isn't used in the GC resultswitcher [22:52:53] awight: when i turn of immediate process i get: Refused to display '' in a frame because it set 'X-Frame-Options' to 'DENY'. [22:52:54] (CR) Ejegg: "Some answers inline. So, kill the factories and just use a switch to check status?" (5 comments) [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/237313 (https://phabricator.wikimedia.org/T109649) (owner: Ejegg) [22:53:00] *off [22:53:33] i can see that mw does set that [22:53:50] but i would think that would happen for GC? [22:54:10] cwdent: there may be a call to 'allowClickjacking' [22:54:59] ah right, WP didn't need that before [22:55:32] so you only need that on the resultswitcher [22:58:02] ejegg: i'm confused about how body and resultswitcher both extend gatewaypage [22:58:22] are they two separate layers of routing? which comes first? [22:58:41] the entry point of any special page is the execute method [22:59:52] which is defined in GatewayPage [23:00:36] that checks to see if we're in maintenance mode, then hands off to abstract handleRequest [23:00:47] which the subclasses define [23:01:26] _body usually calls handleDonationRequest() from that fn [23:01:45] and _resultswitcher usually calls handleResultRequest() [23:02:51] Up in DonationInterface.php where we tell the wiki what special pages we're adding, we just give urls to the subclasses [23:03:31] ohwait [23:03:40] so those are two different special pages? [23:04:01] yeah, so you can make the return url point to the resultswitcher [23:04:08] OH [23:04:13] now i see, thank you! [23:04:22] * cwdent still fuzzy on specialpages [23:04:32] heh, all this wiki cruft [23:04:52] i thought result switcher was like a router that would take you to body [23:05:12] ah, nothing that sophisticated [23:05:19] just to the fail page or the thank you page [23:05:51] well that helps anyway because body reimplements isProcessImmediate [23:05:54] I'm not a fan of the separate result page... [23:06:05] I have to ask K4 for the tenth time why we do it that way... [23:06:35] awight: wait, didn't you just say we should add the result switcher for WP? [23:06:51] Yeah, just for consistency [23:06:57] I'm not happy about it ;) [23:07:37] heh, ok. It seems slightly valuable to have the different URL indicate that the user has just come back from a processor, no? [23:07:48] it's funny how when learning a code base the big picture comes last [23:07:52] unlike most endeavors [23:07:58] ejegg: lolling about you shoving GC against the ropes [23:08:17] heh, gotta quote 'em chapter and verse [23:08:42] didn't mean to sound pissed off though - i'm honestly just curious [23:09:24] i /did/ take merchanteservices@ off the cc for that reply [23:09:35] :) [23:09:44] I don't think there's any need to be polite [23:09:51] It's a factual thing [23:10:46] hey guys - it's getting rainy and i brought the scooter in today, so i'm going to pack up and finish things from home today [23:11:01] be back online in like 30 [23:11:02] don't inhale too much smoke! [23:11:54] the great thing about email is there's still plausible deniability [23:12:03] that one musta got lost! [23:12:05] prove me wrong [23:12:28] hmm, think I'll hop on my two-wheeler and head home too. Back in a bit, y'all [23:13:55] iframe popout works [23:13:57] awesome [23:14:33] WohoowWWWooo [23:15:21] :) [23:15:55] awight: so just instantiating the adapter with the right stuff in the url is enough to do the final processing and queueing? [23:16:13] I don't think so [23:16:42] where you looking? [23:16:44] i don't see any other calls to speak of in the GC result [23:17:27] returns after popout [23:17:59] pretty obscure, but this is the line, $result = $this->adapter->do_transaction( 'Confirm_CreditCard' ); [23:19:01] ah ha, it looks like that one bails before that line if iframe [23:19:08] so the flow must be a little different? [23:19:36] where does it bail? [23:19:55] line 64? [23:19:58] yeah [23:20:53] I think that causes the same page to be reloaded, w/o iframe [23:21:46] * awight struggles to understand [23:21:51] oh totally [23:22:05] hrm [23:22:55] yeah, it reloads the page. top.location = self.document.location + '&liberated=1'; [23:23:13] what if i just redirected to the thanks page instead of popping out of the iframe? [23:23:28] returning to the original url does all the processing [23:23:37] then you would deliver a tiny thank-you, perhaps [23:23:50] dang it [23:24:29] * cwdent goes to find the iframe RFC [23:25:04] cwdent: my suggestion is to solve this problem for all adapters... after we get WP working... [23:25:24] heh yeah [23:25:38] it seems like a lot of duplication to make the result page do the same processing [23:25:49] and potential for divergence [23:26:50] could the result page call handledonationrequest? [23:27:04] Can you reuse handleResultRequest? [23:27:08] in the base class? [23:27:35] I would avoid using anything from GC, we just never finished porting it to the newer base class tools cos it's fragile and scary. [23:28:43] what's the different between donationrequest and resultrequest? [23:28:47] sorry for all the questions [23:29:07] Fundraising-Backlog, MediaWiki-extensions-DonationInterface, Technical-Debt: Finish porting GlobalCollect result switcher page to use handleResultRequest - https://phabricator.wikimedia.org/T112602#1639861 (awight) NEW [23:29:25] donationrequest seemed to handle all the finalizing when redirecting back to the same page from WP [23:29:31] They're just controller entry points. donationrequest sets up a donation form, and resultrequest handles responses [23:29:39] yeah, that's a historical accident [23:30:03] feel free to leave the resultswitcher page out if you can get away with that [23:31:12] Ooh I see what you're saying, the base class handleDonationRequest does do everything we needed [23:31:57] But it's lacking all the session stuff, which is unfortunately in there for a reason [23:31:57] except provide an opportunity to pop out of the frame? [23:32:12] that too [23:33:13] yeah on third reading, session things are only for the iframe [23:35:39] If you can find a way to safely encapsulate that and consolidate the handle* functions, that would be amazing. Meanwhile, does handleResultRequest work out of the box for WP? [23:36:18] Looks like all it would need is a way for subclasses to hook in and do additional finalization steps [23:36:28] That would make it reusable for GC as well. [23:36:51] awight: does that need to get explicitly called in the result page? [23:37:39] Yeah, we need to do that some time after the donor fills out the hosted form, and before we send them to the TY page [23:38:23] Call to a member function setCommunicationStatus() on null in /srv/DonationInterface/worldpay_gateway/worldpay.adapter.php on line 874 [23:38:25] grumble [23:39:33] silly. $this->transaction_response = new PaymentTransactionResponse(); [23:39:56] ah ok, in the result page? [23:40:39] * cwdent just tries it [23:40:52] Can't stand the semiglobal way we're doing that stuff at the moment. It's all in transition cos we've been rewriting. [23:41:20] do_transaction_internal should have created that object [23:41:43] how are you calling processResponse w/o doing an API call? [23:42:25] i guess handleresultrequest does it? [23:42:55] gateway_common/gateway.adapter.php line 1172 should be the only caller [23:43:05] and the object is initialized just above that [23:43:45] hmm [23:44:44] yeah that sure looks like the only call [23:44:53] go go gadget xdebug [23:45:02] I wasn't gonna say it :p [23:45:31] tfw you try to type gt to switch browser tabs [23:46:10] awight: gatewaypage@420 (chuckle) [23:46:36] This is clearly no accident [23:47:03] There are an awful number of TODOs above that line... [23:47:28] damn [23:48:35] astropay is the only active gateway using handleResultRequest [23:48:45] and look at AstroPayGateway::processResponse [23:48:51] :( [23:50:23] (CR) Awight: [C: 2] Handle results of Amazon API calls (4 comments) [extensions/DonationInterface] (amazon) - https://gerrit.wikimedia.org/r/233993 (https://phabricator.wikimedia.org/T108123) (owner: Ejegg) [23:50:32] (PS3) Awight: Don't submit an Amazon payment with invalid amount [extensions/DonationInterface] (amazon) - https://gerrit.wikimedia.org/r/237748 (https://phabricator.wikimedia.org/T108123) (owner: Ejegg) [23:50:56] (Merged) jenkins-bot: Handle results of Amazon API calls [extensions/DonationInterface] (amazon) - https://gerrit.wikimedia.org/r/233993 (https://phabricator.wikimedia.org/T108123) (owner: Ejegg) [23:51:03] (CR) Awight: [C: 2] Don't submit an Amazon payment with invalid amount [extensions/DonationInterface] (amazon) - https://gerrit.wikimedia.org/r/237748 (https://phabricator.wikimedia.org/T108123) (owner: Ejegg) [23:51:25] (Merged) jenkins-bot: Don't submit an Amazon payment with invalid amount [extensions/DonationInterface] (amazon) - https://gerrit.wikimedia.org/r/237748 (https://phabricator.wikimedia.org/T108123) (owner: Ejegg) [23:57:06] awight|brb: well the first bit is encouraging... [23:59:19] Let's... add that clause to the base class processResponse [23:59:53] well that was miserable.