[03:24:57] Fundraising Sprint The Pogues, Fundraising-Backlog, MediaWiki-extensions-CentralNotice: Spike: Determine how to load CentralNotice RL modules and when to execute campaign and banner selection logic - https://phabricator.wikimedia.org/T106577#1483870 (AndyRussG) Another note from the meeting: while we... [04:00:10] (PS33) AndyRussG: WIP - Don't merge but please review - Refactor client-side API and RL modules for banner display [extensions/CentralNotice] (campaign_mixins) - https://gerrit.wikimedia.org/r/221759 (https://phabricator.wikimedia.org/T100686) [11:29:09] Fundraising Sprint The Pogues, Fundraising-Backlog, MediaWiki-extensions-CentralNotice: Spike: Determine how to load CentralNotice RL modules and when to execute campaign and banner selection logic - https://phabricator.wikimedia.org/T106577#1484585 (Pcoombe) Do we have any idea how much this is likel... [13:06:09] fundraising-tech-ops, Traffic, operations, Patch-For-Review: Decide what to do with *.donate.wikimedia.org subdomain + TLS - https://phabricator.wikimedia.org/T102827#1484671 (BBlack) [13:06:22] fundraising-tech-ops, Traffic, operations, Patch-For-Review: Decide what to do with *.donate.wikimedia.org subdomain + TLS - https://phabricator.wikimedia.org/T102827#1374642 (BBlack) [14:04:55] Fundraising Sprint The Pogues, Fundraising-Backlog, MediaWiki-extensions-CentralNotice: Spike: Determine how to load CentralNotice RL modules and when to execute campaign and banner selection logic - https://phabricator.wikimedia.org/T106577#1484768 (AndyRussG) >>! In T106577#1484585, @Pcoombe wrote:... [14:37:44] (PS34) AndyRussG: WIP - Don't merge but please review - Refactor client-side API and RL modules for banner display [extensions/CentralNotice] (campaign_mixins) - https://gerrit.wikimedia.org/r/221759 (https://phabricator.wikimedia.org/T100686) [14:47:56] (CR) AndyRussG: "Indeed I was quite mistaken about page display being blocked on CentralNotice top-queue RL module loading and initial execution. Many, man" [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/213990 (https://phabricator.wikimedia.org/T100372) (owner: Jdlrobson) [14:51:10] https://en.wikipedia.org/wiki/Category:Simon_%26_Garfunkel_members [15:22:27] morning AndyRussG [15:22:42] cwdent: Hey! How's it going? [15:22:53] Wikimedia-Fundraising-CiviCRM, Continuous-Integration-Infrastructure: CI for Civi: provision and run tests under Jenkins/Zuul - https://phabricator.wikimedia.org/T86103#961478 (hashar) Seems this is just waiting for {T91911}. [15:22:57] pretty good, how you doin? [15:23:17] Eh not bad [15:23:38] I bought a new desk chair at a garage sale but I like my old one better :( [15:24:04] heh, no herman miller? [15:24:11] Who's he? [15:24:24] Working away here on the CN refactor/performance stuff, a little later I have to tell FR folks that banner history is still not there... [15:24:33] maker of perversely expensive office furniture [15:25:03] yeah i am digging around https://phabricator.wikimedia.org/T104774 [15:25:08] Heh... Well this one was pretty cheap... [15:25:29] cool! LMK anytime u have any questions :) [15:25:33] so far i'm here https://phabricator.wikimedia.org/T106856 [15:26:15] i was wondering if there's a staging server for CN/Translate...i'm trying to get an idea of what correctly modeled message group data looks like [15:26:39] Interesting....! Yeh I saw that [15:26:46] Maybe the beta cluster would be of some use? [15:26:56] http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page [15:26:59] awight said it looks like a bug, not just screwy config [15:27:03] ah perfect [15:27:22] It's a whole mini copy of the cluster, that automagically syncs to master [15:27:48] In addition we have test.wikipedia.org and test2.wikipedia.org, and maybe some more here and there... [15:27:55] sounds like just what i'm looking for! [15:29:20] On production production, you can also target banners for https://aa.wikibooks.org/, which is live but inactive. But that should be a last resort if you can't test something elsewhere [15:31:14] I see your Simon and Garfunkle members category, and raise you a list of lists of lists: https://en.wikipedia.org/wiki/List_of_lists_of_lists [15:31:42] hehe [15:32:53] AndyRussG, cwdent: I'm a big fan of https://en.wikipedia.org/wiki/List_of_lists_which_do_not_include_themselves [15:34:33] the-wub: nice! [15:35:27] Yeah that stuff is the best [16:20:28] AndyRussG: got access to the beta cluster, but i am not seeing the translate_* tables on any of the wikis...not sure if this is your area of expertise [16:23:30] cwdent: hmmm... interesting, not sure, then... No, I haven't worked extensively with the translationstuff [16:24:23] cwdent: Translate is installed on beta cluster version of meta: http://meta.wikimedia.beta.wmflabs.org/wiki/Special:Version [16:25:11] nice, thanks! [16:25:52] np! [16:35:05] awight: you said you have some experience with the translation extension? this messageindex table is kinda blowing my mind. do you know if there's a doc describing any the technical layout? [16:38:05] hey all, what's up with the paypal spam from yesterday? [16:38:11] hi friends!!!! [16:38:24] * dstrine waves [16:38:42] wb atgo [16:38:49] Fundraising-Backlog: Dedupe data in Silverpop file - https://phabricator.wikimedia.org/T107045#1485282 (CCogdill_WMF) NEW [16:39:01] Fundraising-Backlog: Dedupe data in Silverpop file - https://phabricator.wikimedia.org/T107045#1485289 (CCogdill_WMF) p:Triage>Low [16:40:16] hey K4-713 - heads up that i rescheduled our 1:1 to tomorrow morning [16:41:37] atgo: Acknowledged. And, thanks. [16:46:31] Fundraising-Backlog: Dedupe data in Silverpop file - https://phabricator.wikimedia.org/T107045#1485307 (MBeat33) If/when we come across another instance of this, would it be helpful if we didn’t merge it until tech has had a chance to look at it? [16:55:11] Fundraising Tech Backlog: More and easier testing for DonationInterface - https://phabricator.wikimedia.org/T86247#1485342 (awight) [16:55:13] Fundraising Tech Backlog, MediaWiki-extensions-DonationInterface: In the event that credentials for a gateway are not supplied, that gateway should go in to local development mode. - https://phabricator.wikimedia.org/T99954#1485343 (awight) [16:55:51] Fundraising Sprint Kraftwerk, Fundraising Tech Backlog, MediaWiki-extensions-DonationInterface, Epic: Hackathon idea: Make the DonationInterface extension as friendly as possible - https://phabricator.wikimedia.org/T89188#1485346 (awight) [16:58:34] Fundraising Tech Backlog: More and easier testing for DonationInterface - https://phabricator.wikimedia.org/T86247#1485355 (awight) I just learned about something important: the [[ https://github.com/realestate-com-au/pact | PACT ]] framework, a Ruby proxy which records API conversations in a way that's easy... [17:15:27] (CR) Awight: "/me whimpers to self about the growing complexity of this patch" [extensions/CentralNotice] (campaign_mixins) - https://gerrit.wikimedia.org/r/221759 (https://phabricator.wikimedia.org/T100686) (owner: AndyRussG) [17:20:00] awight_: i get a similar but different error about message groups here: http://meta.wikimedia.beta.wmflabs.org/w/index.php?title=Special:Translate&group=Centralnotice-tgroup-welcome&filter= [17:24:35] awight: don't worry, it doesn't bite! [17:25:03] Or, it only feeds on online encyclopediae [17:26:03] * AndyRussG knows it's complex, but thinks it's the only waaaaay [17:26:24] cwdent: I'm baffled [17:27:05] definitely spidering out into a lot of code i'm not familiar with [17:27:36] cwdent: you might hop on mediawiki-i18n and ask if there were breaking changes to Extension:Translate in this area. [17:28:05] in mw core updates? [17:28:14] umm, in the extension [17:28:22] kk, will do [17:29:00] IMO that CN/bannermessagegroup class was held together with floss and toothpicks, and I wouldn't be surprised if there were a slight change in how we're supposed to be creating groups [17:29:27] On the other hand, it seems to partly work in production--have you tried copying all the translate workflow configuration from mediawiki-config/wmf-config into your localsettings? [17:29:56] ah, just what i found on the install tutorial [17:30:27] there's a bunch of stuff in wmf-config... [17:30:37] including the effing FundraisingTranslateWorkflow extension (kill me) [17:32:48] forgive my dunceness, where is that mediawiki-config? [17:36:40] cwdent: https://gerrit.wikimedia.org/r/#/admin/projects/operations/mediawiki-config [17:48:54] (PS3) Awight: WIP Orphan slayer reads from frack Redis [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/226947 (https://phabricator.wikimedia.org/T99017) [17:48:56] (Abandoned) Awight: WIP Implement high-availability queue pool [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/226948 (https://phabricator.wikimedia.org/T104499) (owner: Awight) [18:07:17] also K4-713 i'm going to need to move our 1:1 every 4 weeks because of a recurring conflict :P [18:07:52] ugh [18:07:56] yeah. ot [18:08:00] it's an every 4 weeks meeting [18:08:01] ... [18:08:07] That's... odd. [18:08:27] mhm [18:08:30] Were they going for monthly? [18:08:34] ish [18:09:20] Happily, I can never remember where my regular meetings are anyway. [18:09:46] When is only *slightly* more solid in my head. [18:19:58] (PS1) Ejegg: Generate new order IDs for each NewInvoice call [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/227256 (https://phabricator.wikimedia.org/T106039) [18:22:08] I've got some reviewables if anyone has time to look at DonationInterface patches: https://gerrit.wikimedia.org/r/226239 https://gerrit.wikimedia.org/r/226917 https://gerrit.wikimedia.org/r/226920 https://gerrit.wikimedia.org/r/224546 https://gerrit.wikimedia.org/r/227256 [18:22:34] K4-713: introducing a 'sequence' session key so as not to abuse numAttempt [18:23:07] ejegg: Heh, cool. [18:23:12] I figure we can also use that for Worldpay if we ever switch back to the system that needs different IDs for each API call [18:23:24] I could swear we already had something like this somewhere, but... [18:23:28] ...I could be making that up. [18:24:37] I have an ancient patch in review that solved the Worldpay thing by different means [18:33:47] (PS2) Ejegg: Generate new order IDs for each NewInvoice call [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/227256 (https://phabricator.wikimedia.org/T106039) [18:39:35] (PS2) Ejegg: Move deleteMessage out of legacy antimessage function [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/226960 (owner: Awight) [18:40:06] (CR) Ejegg: [C: 2] "Looks good!" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/226960 (owner: Awight) [18:40:29] (Merged) jenkins-bot: Move deleteMessage out of legacy antimessage function [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/226960 (owner: Awight) [18:54:42] ejegg: Thanks, I was having a terrible time finding that composer call... We need to merge back to the upstream! [19:00:18] awight: Add our wmff configuration to the upstream buildkit? [19:01:47] Fundraising-Backlog: Set up import for Major Gifts events payment/invitation tool - https://phabricator.wikimedia.org/T101191#1485789 (CaitVirtue) @awight No, I don't want to ask for those two fields, so i believe they will be blank. Caitlin Virtue Director of Development Wikimedia Foundation (415) 839-68... [19:09:00] dstrine: https://www.mediawiki.org/wiki/Extension:CentralNotice/Notes/Campaign-associated_mixins_and_banner_history [19:33:27] Fundraising Sprint ODB, Fundraising Sprint The Pogues, Fundraising-Backlog, MediaWiki-extensions-CentralNotice: Banner history mixins and data - https://phabricator.wikimedia.org/T90918#1485948 (awight) [19:38:59] Fundraising Sprint ODB, Fundraising Sprint The Pogues, Fundraising-Backlog, MediaWiki-extensions-CentralNotice: Banner history mixins and data - https://phabricator.wikimedia.org/T90918#1485979 (awight) [20:18:04] Fundraising Sprint The Pogues, Patch-For-Review: Bug: JCB logo not always appearing in first position in Japan - https://phabricator.wikimedia.org/T106705#1486098 (awight) [20:32:38] (CR) Awight: WIP - Don't merge but please review - Refactor client-side API and RL modules for banner display (5 comments) [extensions/CentralNotice] (campaign_mixins) - https://gerrit.wikimedia.org/r/221759 (https://phabricator.wikimedia.org/T100686) (owner: AndyRussG) [20:42:27] cwdent: you can run QUnit tests directly on-wiki in ur browser like so: https://test2.wikipedia.org/wiki/Special:JavaScriptTest/qunit?module=ext.centralNotice.bannerController.lib [20:43:02] You can also run them from the command line [20:43:16] LMK if you'd like to do that and I can help... [20:45:36] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Edits to LYBUNT report - https://phabricator.wikimedia.org/T88819#1486168 (atgo) [20:46:54] nice, thanks AndyRussG [20:46:58] just reading the qunit docs [20:47:02] cwdent: yw! [20:47:59] AndyRussG: is that special page a mw extension? [20:48:59] Hi all! These are the DonationInterface patches I've got in review: https://gerrit.wikimedia.org/r/226239 https://gerrit.wikimedia.org/r/226917 https://gerrit.wikimedia.org/r/226920 https://gerrit.wikimedia.org/r/224546 https://gerrit.wikimedia.org/r/227256 [20:50:00] cwdent: no, rather there's a global config variable to set in your LocalSettings.php [20:50:18] cwdent: $wgEnableJavaScriptTest = true; [20:53:15] oh nice [20:56:27] AndyRussG: i see passing centralnotice tests...have the failing ones been removed from here but not the jenkins build? [20:57:14] and is the nature of those failing ones that they are impossible or not worth it to fix? [20:59:08] cwdent: qunit, none are failing anywhere [20:59:27] oooh, browser tests [20:59:32] yeah [20:59:36] are those the cucumber ones? [20:59:41] yeah [20:59:55] gotcha! so what about fixing those? [21:00:05] cwdent: between the master branch and the tip of the feature branch, we have mostly they same tests. IIRC I may have removed one or two that didn't make sense anymore [21:00:56] cwdent: the browser tests I think are lower priority. The cucumber tests in and of themselves should be fine. What's broken is (probably) several bits of the complicated pipeline for testing them on real VMs using SauceLabs [21:01:19] For now top prority is new qunit tests that check small parcels of functionality of the new code [21:03:26] gotcha, yeah pesky browser tests [21:03:48] i'll see if i can narrow down areas of this patch that could use coverage [21:04:27] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Civi Prospect Field - Saving Error - https://phabricator.wikimedia.org/T107087#1486277 (astillwell) NEW [21:06:20] i'm going to mosey over to the shop, back in a few [21:28:15] Fundraising Sprint The Pogues, Fundraising-Backlog, MediaWiki-extensions-CentralNotice: Spike: Determine how to load CentralNotice RL modules and when to execute campaign and banner selection logic - https://phabricator.wikimedia.org/T106577#1486331 (AndyRussG) Proposal: - Keep GeoIP top-loaded. - Onl... [21:43:56] hey awight [21:44:16] is it possible to edit the name of a contact in civi [21:44:17] ? [21:44:22] say, in the case of a misspell [21:44:36] it's being weird. [21:45:01] Huh, it /should/ be possible! [21:45:21] hm [21:45:31] we're having a problem with a specific record [21:45:41] where you hit "edit" and then it just spins forever [21:45:48] odd [21:45:53] yeah [21:45:54] cid=37908 [21:48:42] (CR) AndyRussG: WIP - Don't merge but please review - Refactor client-side API and RL modules for banner display (2 comments) [extensions/CentralNotice] (campaign_mixins) - https://gerrit.wikimedia.org/r/221759 (https://phabricator.wikimedia.org/T100686) (owner: AndyRussG) [21:48:50] "Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience." [21:49:19] ejegg|food, atgo: mine is stalled waiting for jquery-ui-F5F6F1.png [21:49:35] hm. [21:49:48] cwdent: but.. . what about the middle user's experience... All but forgotten in this day and age [21:49:49] anna says she's been able to do this for other records though [21:49:57] AndyRussG: ;) [21:50:11] you mean the elves in my computer? [21:51:12] we have quite the healthy timeout value in civi [21:53:02] actually my browser tab died [21:53:53] but yeah atgo the edit page for other contacts seems to come up [21:57:18] cwdent, atgo: has something to do with the contact being associated with an organization, I think [21:59:30] ahhh [21:59:58] ejegg|food: is that file an icon for an organization or something? [22:00:19] funny thing is i see it on disk right next to the other icon it gets successfully [22:00:30] cwdent: mine was blocking on a request to the AJAX api [22:00:46] My leaky internet is partially fixed. [22:00:46] tring to call CRM_Contact_Page_AJAX::getContactList() [22:01:01] oh huh [22:01:08] Might go up and down a few more times today, but the guy said he'd leave me hooked up for now. [22:01:16] XenoRyet: so. weird. [22:01:21] mine sure looks like it's waiting on that png [22:01:53] Apparently I had too many unused splitters on the line, and additionally the cable between me and the street is corroded. [22:02:19] Guess it was causing noise problems in the network. [22:02:54] aah, RF leaking in, not out [22:02:57] makes more sense [22:03:21] Yea. I mean, it's probably leaking out too, but nobody would care about that. [22:19:44] atgo: oh hey. yeah, if you can't edit a contact's name, that's a monster bug. [22:31:46] aargh: stupid select [22:31:50] SELECT v.name as name ,v.value as value, v.grouping as grouping [22:31:50] FROM civicrm_option_value v, [22:31:50] civicrm_option_group g [22:31:50] WHERE v.option_group_id = g.id [22:31:51] AND g.name = 'contact_autocomplete_options' [22:31:53] AND g.is_active = 1 AND v.is_active = 1 ORDER BY v.weight [22:31:56] 601 Init DB wmfcivi [22:31:58] 601 Query /* https://civicrm.wikimedia.org/user/1 */ SELECT employer_id [22:32:01] FROM civicrm_contact [22:32:04] [22:32:06] WHERE ( civicrm_contact.id = 209 ) [22:32:09] 601 Init DB wmfcivi [22:32:11] 601 Query /* https://civicrm.wikimedia.org/user/1 */ SELECT DISTINCT(id), data, sort_name, email [22:32:14] FROM [22:32:17] ( [22:32:19] ( [22:32:22] SELECT [22:32:24] civicrm_contact.id, [22:32:27] CONCAT_WS( ' :: ', sort_name, email ) AS data, [22:32:29] sort_name, [22:32:32] email [22:32:34] FROM civicrm_contact [22:32:37] LEFT JOIN civicrm_email [22:32:39] ON ( civicrm_email.contact_id = civicrm_contact.id AND civicrm_email.is_primary = 1 ) [22:32:42] WHERE [22:32:43] (CR) Awight: "I really like the legacy support! A few questions inline, but no blockers jumped out at me." (15 comments) [extensions/CentralNotice] (campaign_mixins) - https://gerrit.wikimedia.org/r/221759 (https://phabricator.wikimedia.org/T100686) (owner: AndyRussG) [22:32:45] civicrm_contact.sort_name LIKE 'w%' [22:32:47] AND civicrm_contact.is_deleted = 0 [22:32:50] ) UNION ( [22:32:52] SELECT [22:32:55] civicrm_contact.id, [22:32:57] CONCAT_WS( ' :: ', sort_name, email ) AS data, [22:33:00] sort_name, [22:33:02] email [22:33:05] FROM civicrm_email [22:33:07] JOIN civicrm_contact [22:33:10] ON civicrm_email.contact_id = civicrm_contact.id [22:33:12] WHERE [22:33:15] civicrm_email.email LIKE 'w%' [22:33:17] AND civicrm_contact.is_deleted = 0 [22:33:20] AND civicrm_email.is_primary = 1 [22:33:22] ) [22:33:25] ) AS t [22:33:27] LIMIT 0, 10 [22:33:30] ack, sorry for the flood [22:33:32] not even what I wanted to paste... [22:33:35] anyway, here's the dumb part: WHERE cc.contact_type = "Organization" AND cc.id = 2423 AND cc.sort_name LIKE '%%' [22:33:47] D: [22:34:04] so the query just spins off into space? [22:34:17] ejegg: you're in the quicksearch bar query? [22:34:54] awight: this one happens (blockingly) on loading the edit page for a contact who has an employer set [22:34:56] atgo: here's a surprisingly useful sandbox site, to help determine if it's just us who are broken: http://d44.demo.civicrm.org/ [22:35:40] awight: it returns fine on my machine, but I suspect the sort_name LIKE '%%' is wreaking havoc in production [22:35:40] ejegg: well, it's definitely the quicksearch query [22:35:55] paste me an URL? [22:36:33] ejegg: you currently have a 'w' in the quicksearch field... [22:37:02] I guess that wasn't the main problem case though [22:37:03] sorry, that floodpaste wasn't even the query I meant to show [22:37:13] hehe that's how it always works [22:37:28] take a look at this OH GOD PRIVATE DATA [22:37:44] freaking paste buffer roulette [22:38:34] awight: here's my local uglyurl [22:38:44] http://localhost/civi/index.php?q=civicrm/ajax/rest&className=CRM_Contact_Page_AJAX&fnName=getContactList&json=1&context=contact&org=1&id=2423&employee_id=259 [22:39:33] which... doesn't return the right org info! [22:39:37] * awight sniffles. I've been defribillating my local instance, no pulse yet [22:39:46] u got one for production? [22:39:50] yah, one sec [22:42:04] wtf firebug? y u no let me copy ajax call location from net tab? [22:42:21] no not the ajaxy one, the page you're looking at [22:42:44] oh, https://civicrm.wikimedia.org/civicrm/contact/add?reset=1&action=update&cid=37908 [22:43:16] what a POS [22:43:41] that sync ajax call tho [22:44:19] We're overriding the quicksearch thing via hook, so we might be interpreting something wrong [22:44:24] The problem code inserting the LIKE '%%' is commented with "CRM-7157, hack: get current employer details when employee_id is present." [22:45:51] we really have to upgrade to 4.4 [22:45:59] um. Well that's dreadful [22:47:41] aargh, that code's still there in 4.4 [22:48:13] so probably it's just slow for most users, but our db is huge? [22:48:17] users of civi i mean [22:48:40] that'd be my guess [22:49:06] tried on staging? [22:49:50] not yet, but I could [22:49:57] i'll give it a shot [22:50:02] already on there [22:50:15] sorry, I had to fill a bowl of mixed employee chow to console myself [22:51:14] Looks like even !config->includeWildCardInName won't help us [22:51:17] well wait [22:51:32] since you're specifying cc.id [22:51:39] oh crap, nope, that's not the bad query [22:51:40] i don't think the %% should matter [22:51:52] params['name'] must not be defined [22:52:28] for some reason it follows that up with a totally open quicksearch query [22:52:34] that might be our fault [22:52:38] lemme find that hook [22:52:42] oh. thx [22:52:47] it's in wmf_civicrm AFAIR [22:52:50] thanks! [22:52:53] er IIR [22:53:02] leaky internets... [22:55:48] ok, I see the issue [22:58:16] (PS1) Ejegg: Don't override quicksearch for empty $name [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/227368 [22:58:58] awight: ^^ makes it fill in the right employer details on my machine [23:00:20] (CR) Awight: [C: 2] "An improvement--whether it might solve the current problem I can't say." [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/227368 (owner: Ejegg) [23:00:46] Is it possible that the API call is being send to the wrong URL? [23:01:01] nope, the URL is good [23:01:29] (Merged) jenkins-bot: Don't override quicksearch for empty $name [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/227368 (owner: Ejegg) [23:01:50] It's just we weren't accounting for the hack that uses quicksearch to get a specific org's data by passing in org ID but no name [23:02:17] gonna check it on on staging... [23:02:50] doesn't it still seem weird that it hangs vs getting an empty response? [23:02:52] Wouldn't that just take the is_numeric conditional branch? [23:03:15] The hang isn't surprising, cos it's waiting up to... 15 minutes for MySQL to fall over and die [23:03:30] awight: it's not passing in the org id on $name, it's in another place [23:03:54] so the query is actually hanging? [23:04:05] ook thx [23:04:57] oh, that one is not narrowing down by id [23:04:57] I think so - it's trying to select where email like '%' unioned with another select where sort_name like '%' [23:05:23] yeah, gnarly query [23:05:58] i need visual block select in browser [23:06:12] ok, so it definitely still hangs right now in staging. gonna cherry-pick that commit [23:08:35] woohoo, working! [23:08:46] nice ejegg [23:08:57] thanks! [23:10:31] cwdent: how would you feel about me deploying utm_ passthrough, and 'corrects engage contribution type' ? [23:10:51] hrm, those should be out already [23:11:16] That was an amazing fix. [23:12:00] oh, lemme pull deploy branch... [23:12:11] We still support ie8 as per this page, right? https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix [23:13:25] ejegg: i did that deploy when no one else was around so lemme know if i screwed something up [23:13:29] (PS1) Ejegg: Merge branch 'master' into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/227370 [23:13:53] cwdent: no, I was just comparing master to my outdated local deployment checkout [23:14:21] * ejegg crosses fingers, hopes 'better success check' doesn't break recurring again [23:14:45] (CR) Ejegg: [C: 2] Merge branch 'master' into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/227370 (owner: Ejegg) [23:17:47] !log updated crm from 83cacfa1e0852ffaf47d2f02e7d843cf6f3bcda4 to db417a28a247a3fdf3e3023a700d6266e04f3e9d [23:17:52] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log, Master [23:33:33] (PS3) Awight: Generate new order IDs for each NewInvoice call [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/227256 (https://phabricator.wikimedia.org/T106039) (owner: Ejegg) [23:39:04] (PS35) AndyRussG: WIP - Don't merge but please review - Refactor client-side API and RL modules for banner display [extensions/CentralNotice] (campaign_mixins) - https://gerrit.wikimedia.org/r/221759 (https://phabricator.wikimedia.org/T100686) [23:40:19] hey sorry... disappeared for a while into meetings. thanks for taking care of that! [23:41:21] (CR) AndyRussG: WIP - Don't merge but please review - Refactor client-side API and RL modules for banner display (13 comments) [extensions/CentralNotice] (campaign_mixins) - https://gerrit.wikimedia.org/r/221759 (https://phabricator.wikimedia.org/T100686) (owner: AndyRussG) [23:42:32] (CR) AndyRussG: "Updated in line with Stage 1 described here:" [extensions/CentralNotice] (campaign_mixins) - https://gerrit.wikimedia.org/r/221759 (https://phabricator.wikimedia.org/T100686) (owner: AndyRussG) [23:43:50] (CR) Awight: [C: 2] "Bold! Not worrying too much about Worldpay, cos we'll have to smoke test that when we take it out of deep freeze, anyway." [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/227256 (https://phabricator.wikimedia.org/T106039) (owner: Ejegg) [23:44:19] (Merged) jenkins-bot: Generate new order IDs for each NewInvoice call [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/227256 (https://phabricator.wikimedia.org/T106039) (owner: Ejegg) [23:46:20] Fundraising Sprint The Pogues, Fundraising-Backlog, Unplanned-Sprint-Work: Footer images on payments missing - https://phabricator.wikimedia.org/T106728#1486924 (Ejegg) weird, resources/assets/poweredby_mediawiki_88x31.png definitely exists in the repo and on the deploy server, but https://payments.wi... [23:47:20] awight: thanks! I'll need to manually rebase the 'parse error messages' one around that [23:48:03] (CR) Awight: Parse more of AstroPay's error descriptions (1 comment) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/224546 (https://phabricator.wikimedia.org/T106053) (owner: Ejegg) [23:48:23] Strangely looks like it might merge... attempting... [23:48:29] (CR) Awight: [C: 2] Parse more of AstroPay's error descriptions [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/224546 (https://phabricator.wikimedia.org/T106053) (owner: Ejegg) [23:48:53] ah, now the dependencies box expands... anyway [23:49:05] (PS2) Awight: Use old error forms for AstroPay fail page [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/226917 (https://phabricator.wikimedia.org/T106053) (owner: Ejegg) [23:49:26] (CR) Awight: [C: 2] "Nice workaround!" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/226917 (https://phabricator.wikimedia.org/T106053) (owner: Ejegg) [23:49:31] (PS2) Awight: Check error['context'] to place error messages [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/226920 (https://phabricator.wikimedia.org/T106053) (owner: Ejegg) [23:49:45] (Merged) jenkins-bot: Use old error forms for AstroPay fail page [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/226917 (https://phabricator.wikimedia.org/T106053) (owner: Ejegg) [23:49:59] (CR) Awight: [C: 2] Check error['context'] to place error messages [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/226920 (https://phabricator.wikimedia.org/T106053) (owner: Ejegg) [23:50:05] (PS6) Awight: Parse more of AstroPay's error descriptions [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/224546 (https://phabricator.wikimedia.org/T106053) (owner: Ejegg) [23:50:23] automatic rebase worked [23:50:24] (Merged) jenkins-bot: Check error['context'] to place error messages [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/226920 (https://phabricator.wikimedia.org/T106053) (owner: Ejegg) [23:50:27] nice! [23:59:44] awight: thanks for all the CR! Looks like 'parse descriptions' and the country-specific fiscal numbers (https://gerrit.wikimedia.org/r/#/c/226239/ ) are in limbo between +2 and merge