[00:00:52] so, we definitely had our best hour to date. [00:01:09] close to the best day ever, and that's only showing banners for 10 hours of it [00:01:21] do we know when emails go out? Once things settle a bit I'd like some more deduping to happen - but I would want it to miss key email times [00:01:48] eileen1: that's not in our systems - you'd have to ask ccogdill [00:02:22] ok - I'll ping her - maybe not today but in the next couple [00:02:56] cool [00:03:41] hmm, sun's down and it's all dark here at the river's edge. Think I'll take off for a while, but I'll be listening for IRC pings. [00:04:02] so long! [00:05:21] wow, just got another donation spike. email is killin it! [00:07:42] enjoy the downtime! [00:12:47] AndyRussG: have you seen this? https://phabricator.wikimedia.org/T151962 [00:13:43] is this something wrong with the banner/campaign or something deeper? [00:14:16] Almost certain that it's a CSS issue with the banner [00:16:17] I cannot repro on regular chrome, firefox and safari [00:16:27] I'll add that to the task [00:16:42] dstrine: fyi https://office.wikimedia.org/wiki/Browser_testing_and_design_tools [00:18:59] Fundraising-Backlog, MediaWiki-extensions-CentralNotice, Regression: Banner "B1617_112919_en6C_dsk_p1_lg_bdr_prp" makes login, signup and search inaccesible - https://phabricator.wikimedia.org/T151962#2833511 (DStrine) I cannot reproduce on regular chrome, firefox or safari. [00:24:08] Fundraising-Backlog, MediaWiki-extensions-CentralNotice, Regression: Banner "B1617_112919_en6C_dsk_p1_lg_bdr_prp" makes login, signup and search inaccesible - https://phabricator.wikimedia.org/T151962#2833718 (DStrine) p:High>Normal [02:15:46] (PS1) Krinkle: Remove use of deprecated "json" module [extensions/CentralNotice] (wmf_deploy) - https://gerrit.wikimedia.org/r/324375 [03:12:58] (PS5) Ejegg: WIP rename 'zip' to 'postal_code' [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/320267 [03:16:38] (CR) jenkins-bot: [V: -1] WIP rename 'zip' to 'postal_code' [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/320267 (owner: Ejegg) [03:24:29] (PS6) Ejegg: WIP rename 'zip' to 'postal_code' [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/320267 [03:25:01] dstrine: looking! [03:26:10] (CR) jenkins-bot: [V: -1] WIP rename 'zip' to 'postal_code' [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/320267 (owner: Ejegg) [04:37:03] Fundraising-Backlog: Thank-you page should report current waiting time until you can expect a receipt - https://phabricator.wikimedia.org/T151981#2834095 (awight) [04:38:14] Fundraising-Analysis, Fundraising-Backlog: Create new git repository for fundraising stats tools - https://phabricator.wikimedia.org/T151982#2834107 (awight) [04:39:28] Fundraising-Analysis, Fundraising-Backlog: Make Github wmf-fr repository public - https://phabricator.wikimedia.org/T151983#2834119 (awight) [05:29:47] (CR) Krinkle: "This fixes "This page is using the deprecated ResourceLoader module "json"." currently emitting on every page in prod." [extensions/CentralNotice] (wmf_deploy) - https://gerrit.wikimedia.org/r/324375 (owner: Krinkle) [05:30:08] AndyRussG: ejegg|away: ^ Let me know if this is okay to SWAT tomorrow. [05:34:23] (CR) Jforrester: [C: 1] Remove use of deprecated "json" module [extensions/CentralNotice] (wmf_deploy) - https://gerrit.wikimedia.org/r/324375 (owner: Krinkle) [06:07:38] Fundraising-Analysis, Fundraising-Backlog: Create new git repository for fundraising stats tools - https://phabricator.wikimedia.org/T151982#2834183 (JakeTheDeveloper) a:JakeTheDeveloper I got this. [11:29:11] Damn. [11:29:17] It sucks that this site might get shut down. [11:29:23] Hopefully we reach needed donations. [11:29:25] I can't afford so. [11:38:06] Fundraising-Backlog, MediaWiki-extensions-CentralNotice, Regression: Banner "B1617_112919_en6C_dsk_p1_lg_bdr_prp" makes login, signup and search inaccesible - https://phabricator.wikimedia.org/T151962#2834601 (Pcoombe) Open>Resolved a:Pcoombe Thanks for the detailed report! I've fixed thi... [14:33:17] Fundraising-Analysis, Fundraising-Backlog: Create new git repository for fundraising stats tools - https://phabricator.wikimedia.org/T151982#2835008 (JakeTheDeveloper) I am very busy because my boss wants me to help someone with their project. I will review this project 1 time per hour. This will take a... [15:26:52] (CR) Ejegg: "recheck" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/320267 (owner: Ejegg) [16:22:16] (PS1) Ejegg: Less complicated SQL for $/sec [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/324478 [16:26:55] (CR) Ejegg: "recheck" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/320267 (owner: Ejegg) [16:31:14] fr-tech this one is mostly to ease development on ne mariadb: https://gerrit.wikimedia.org/r/324478 [16:31:29] *new [16:32:09] ejegg: u already on the lookout for January at the end of the tunnel? :) [16:32:49] heh, just developing on a machine with way newer software than the box that hosts dash [16:37:19] (PS7) Ejegg: Rename 'zip' to 'postal_code' [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/320267 [17:30:41] (CR) Raimond Spekking: [C: 1] "i18n review" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/320267 (owner: Ejegg) [17:39:19] AndyRussG: we are in the morning FR meeting and fr-online and the-wub want to double check that they are limiting banners correctly [17:39:38] s/are/will be/ [17:39:46] awight|domestic: and the-wub can we discuss here? [17:40:09] dstrine: just joined... K! I also would like to check how cps are checking impressions, BTW [17:40:39] dstrine: can we do over email? megan will want to be involved [17:40:47] if we finish updates early, maybe people can stay on the call? [17:41:45] (I was surprised at a comment in one e-mail about impressions, just want to check the procedure being used there...) [17:53:41] AndyRussG: please see my email. also, while I was writing that email I didn't catch seddon's questions. Can you make a task for that conversation? [17:54:34] dstrine: yep! [17:55:12] Sorry I was late...!!! Was just focusing on something and lost track of time 8| [17:56:58] heh that's a good smiley [17:59:42] cwd: ;þ [18:00:02] fr-tech: In case of atomic attack, all work rules will be temporarily suspended. [18:00:02] -- discuss. [18:00:04] thorny! [18:03:49] particle-ar [18:04:09] (CR) Cdentinger: [C: 2] Less complicated SQL for $/sec [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/324478 (owner: Ejegg) [18:05:14] (Merged) jenkins-bot: Less complicated SQL for $/sec [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/324478 (owner: Ejegg) [18:07:37] thanks! [18:07:44] (CR) Cdentinger: [C: 1] "This is a good clean-up and simplification but I think too much surface area to merge during BE." [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/320267 (owner: Ejegg) [18:10:31] Fundraising-Backlog: Fail mail on 'city is too long' - https://phabricator.wikimedia.org/T152022#2835693 (cwdent) [18:13:04] Fundraising-Backlog: Fail mail on 'city is too long' - https://phabricator.wikimedia.org/T152022#2835693 (Ejegg) Yep, at least truncate before sending to the queue. Guess add maxlength to the input fields too. [18:26:38] ejegg: does the dash daily totals count all donations from our form at any giving level? Like... someone gave $1,000 would it be in these totals? [18:27:06] dstrine: there's a configurable major gifts cutoff [18:27:17] dstrine: We usually use 5k. [18:28:22] ok cool I thought there was a limit. I just saw the settings in my dash. Thanks! [18:29:39] any scrum of scrums asks fr-tech? [18:29:53] None here [18:30:47] nope! [18:32:23] oh, awight, want me to ask about the whitespace oddness coming out of the parser? [18:32:47] dstrine: We were just discussing that in fr-tech-talk. I think we should double-check how stakeholders want to use the Big English graph. [18:32:54] ejegg: eh sure, lemme get you the URL [18:33:10] ejegg: https://meta.wikimedia.org/w/api.php?page=Fundraising/Translation/Thank_you_email_20161128&oldid=16108775&action=parse [18:34:30] Thanks! [19:00:04] doing dishes for a few minutes... [19:02:35] Fundraising-Backlog: Thank You page to Facebook error - https://phabricator.wikimedia.org/T152026#2835881 (MBeat33) [19:11:23] awight|domestic: sorry I missed your comment. what do you mean? [19:16:14] Fundraising Dash, Fundraising-Backlog: Top days / top hours widget - https://phabricator.wikimedia.org/T152028#2835935 (Ejegg) [19:34:54] dstrine: Just that, I'm not clear about which donations should be included in BE and which should be broken out. Maybe other people are more confident about that? Are we agreed on showing all bulk email and banner donations lumped together, minus anything coming from a MG mailing or an online donation of $5k+? [19:35:48] Fundraising Dash, Fundraising-Backlog: Top days / top hours widget - https://phabricator.wikimedia.org/T152028#2836016 (XenoRyet) a:XenoRyet [19:37:14] I'm checking on the donation cutoff. please hold [19:37:20] the-wub: Do you have a readme for the /srv/br tools? [19:37:50] and not sure you saw this in backscroll, but we should have a proper git repo for your newer stats tools by the end of the week. [19:38:31] the-wub: for dropping notes about what the various scripts do, https://etherpad.wikimedia.org/p/fundraising_stats [19:39:49] worthy endeavor! [19:40:20] :) just trying to keep my hands off of the mains [19:40:41] Also, I want to pull stats the same way production crew is doing so [19:41:55] Fundraising Dash, Fundraising-Backlog: Dash: change the "Totals Earned " widget cutoff to default to $999 - https://phabricator.wikimedia.org/T152031#2836043 (DStrine) [19:42:22] awight: ^^ [19:42:32] let's default to $999 [19:42:36] dstrine: beautiful, thx [19:44:10] the-wub: Nice inline usage docs, btw! [19:45:39] Fundraising Dash, Fundraising-Backlog: Dash: change the "Totals Earned " widget cutoff to default to $999 - https://phabricator.wikimedia.org/T152031#2836043 (Ejegg) Changing the default is easy. Changing everyone's saved settings is a little annoying because widget settings are JSON blobs. Folks can do... [19:51:51] Fundraising Dash, Fundraising-Backlog: Dash: change the "Totals Earned " widget cutoff to default to $999 - https://phabricator.wikimedia.org/T152031#2836100 (DStrine) Let's just change the default. [19:54:00] awight: you are missing some awesome pizza [19:56:22] d'oh! I'll have to content myself with boiled rye flakes [19:58:34] is that like oatmeal? [19:59:21] yah a little heartier [19:59:33] ... if that's possible [20:00:12] My hot cereal theme album: https://mischiefbrew.bandcamp.com/album/boiling-breakfast-early [20:06:50] awight: thanks for the stats help. I'm pretty swamped at the moment, but will try and write up some quick descriptions soon [20:08:50] the-wub: No worries--your inline help covers like 50% of my questions [20:09:09] I'll get back to you once we have a git repo and we can figure out a way to ease that into your workflow [20:09:22] sorry... that it's been a year since the last time we tried to do this [20:10:02] Fundraising-Backlog, Wikimedia-Fundraising: Thank You page to Facebook error - https://phabricator.wikimedia.org/T152026#2836193 (Pcoombe) [20:11:41] Fundraising Sprint Waiting for Godot, Fundraising-Backlog, MediaWiki-extensions-DonationInterface, Unplanned-Sprint-Work: Determine impact of mobile CSS changes - https://phabricator.wikimedia.org/T151815#2828861 (awight) **Desktop** | banner | donations / clicks | | B1617_1121_en6C_dsk_p1_lg_txt... [20:11:56] !log enabled CiviMail record creation at 100% for thank you letters [20:12:07] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [20:17:26] Fundraising-Backlog, MediaWiki-extensions-CentralNotice: Spike: CentralNotice: Evaluate supressing banners for logged-out users who previously logged in - https://phabricator.wikimedia.org/T152038#2836218 (AndyRussG) [20:17:39] dstrine: ^ as per talk this morning [20:18:17] thanks! [20:18:50] Fundraising-Backlog, MediaWiki-extensions-CentralNotice: Spike: CentralNotice: Evaluate supressing banners for logged-out users who previously logged in - https://phabricator.wikimedia.org/T152038#2836218 (Ejegg) Never mind my suggestion about using the enwikiUserName cookie - it's http-only [20:24:22] !log re-enabled CiviMail bounce fetching job [20:24:36] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [20:31:06] I'm gonna do that long city one [20:32:17] hmm so we have a bunch of fields where we throw an error if they are too long [20:32:21] (PS1) Ejegg: Add 'maxlength' attributes to personal info fields [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/324550 (https://phabricator.wikimedia.org/T152022) [20:32:28] kid pickuptime [20:36:49] Fundraising Sprint Asbestos Removal 2016, Fundraising Sprint Bloodletting 2016, Fundraising Sprint Testing on Production, Fundraising Sprint Unbreaking Now, and 10 others: [Epic] Do not show donation form error message: "No processors available". Fi... - https://phabricator.wikimedia.org/T117872#2836290 [20:40:21] (PS1) Eileen: Do not hard-fail on overlong city. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/324555 (https://phabricator.wikimedia.org/T152022) [20:40:48] ejegg: what are your thoughts on also being more forgiving in the import code? Just wondering if overlong city could come from anywhere else [20:41:22] wow https://browsix.org/ [20:42:24] eileen1: definitely a good idea! [20:42:44] I think we have a tag 'Address truncated' or something that we apply in one import path [20:42:47] let me see [20:43:27] It's also reasonable to reject the message and Donor Services can sort out the issue then reinject into the queue [20:44:27] (CR) Eileen: [C: 1] "This looks logical - although I don't have a set up to test it. I checked all the assigned field lengths matched the import code and the l" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/324550 (https://phabricator.wikimedia.org/T152022) (owner: Ejegg) [20:44:46] ejegg: I pushed a patch to do that [20:45:11] awesome, looks good! [20:57:05] Fundraising-Backlog, MediaWiki-extensions-DonationInterface, Unplanned-Sprint-Work: Ingenico: stop calling SET_PAYMENT when GET_ORDERSTATUS returns 25 - https://phabricator.wikimedia.org/T151788#2836349 (DStrine) [21:02:36] Fundraising-Backlog, Wikimedia-Fundraising: Thank You page to Facebook error - https://phabricator.wikimedia.org/T152026#2836374 (DStrine) a:Pcoombe [21:02:48] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Fix Civi bug where creating a smart group with total giving >= 1000 saves a = 1000 - https://phabricator.wikimedia.org/T152044#2836375 (Eileenmcnaughton) [21:03:31] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Fix Civi bug where creating a smart group with total giving >= 1000 saves as = 1000 - https://phabricator.wikimedia.org/T152044#2836388 (Eileenmcnaughton) [21:03:40] Fundraising Sprint Waiting for Godot, Fundraising-Backlog, Patch-For-Review, Unplanned-Sprint-Work: Fail mail on 'city is too long' - https://phabricator.wikimedia.org/T152022#2836389 (DStrine) [21:04:14] Fundraising Dash, Fundraising Sprint Waiting for Godot, Fundraising-Backlog: Top days / top hours widget - https://phabricator.wikimedia.org/T152028#2836391 (XenoRyet) [21:07:18] MBeat: heads-up that the queue is a little backed up and TY emails are 15 minutes out [21:07:34] ty awight, that’s not too bad [21:10:18] MBeat: you have that widget enabled in the dash, aye? [21:10:35] checking [21:23:03] oh hey did riot.im just turn off [21:24:08] awight: are you in the office today? (I shoudl remember that from the meeting 2 mins ago & don't) [21:25:45] eileen1: I was trying to get another patch in on that ticket to restore the previous year graphs [21:26:20] ah right [21:27:05] just thinking - perhaps rather than scheduling dedupe around emails I should add a check on queue length to the job & if it is longer than 500 skip the dedupe run? [21:28:34] (CR) Ejegg: [C: 2] "Thanks! And we should all take inspiration from your unit testing diligence." [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/324555 (https://phabricator.wikimedia.org/T152022) (owner: Eileen) [21:30:02] eileen1: unfortunately I don't thing we've got a programmatic way to check queue length right now [21:30:22] (CR) Eileen: "I am a bit evangelical about it...." [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/324555 (https://phabricator.wikimedia.org/T152022) (owner: Eileen) [21:30:24] i guess maybe number of donations created in the last 5 minutes? [21:32:15] ejegg: sounds like an easier query - it would mean it would not be quite as responsive [21:32:18] but probably OK [21:32:25] (Merged) jenkins-bot: Do not hard-fail on overlong city. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/324555 (https://phabricator.wikimedia.org/T152022) (owner: Eileen) [21:32:47] FWIW the dedupe seems to mostly cause problems when there are multiple jobs trying o dedupe the same contacts [21:33:04] oh, that makes sense [21:35:56] @dstrine - I might add a job to make the dedupe jobs self-throttling to the sprint. Then we can up the dedupe jobs again - which DS etc will find helpful I think [21:36:45] eileen1: ok [21:39:43] ejegg: I think that's a real easy redis query though [21:41:20] https://redis.io/commands/llen [21:44:08] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Search for email only works if primary email address - https://phabricator.wikimedia.org/T152048#2836522 (LeanneS) [21:52:30] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Search for email only works if primary email address - https://phabricator.wikimedia.org/T152048#2836549 (Eileenmcnaughton) That's a change that has been attempted & reverted in CiviCRM before - so it's probably not going to be something we want to sque... [21:59:55] yep got the widget awight, super helpful [22:09:59] OK awesome [22:11:17] eileen1: I'm not in the office, but we have that hangout if u want to achieve bilocation [22:13:10] awight|distract: I'm just trying to figure out what needs to be done re the engage ticket by ccogdill [22:13:45] eileen1: ah cool lemme take a peek [22:14:11] eileen1: Have you dug around in offline_civicrm yet? [22:14:42] Not my finest work, I was trying to gradually adapt legacy code to be easier to work with [22:15:29] So the import templates are Excel files, https://github.com/wikimedia/wikimedia-fundraising-crm/tree/master/sites/all/modules/offline2civicrm/templates [22:17:13] awight: yeah - I'm looking there - it's not the code confusing me - it's defining the problem [22:17:37] it sounds like 'in unknown circumstances trxn_id is not populated' [22:17:37] cool, I'm struggling too [22:17:49] I believe there are two things there. [22:17:56] and 'it's something to do with matching gifts.. maybe' [22:18:00] (1) Lots of fields could be added to the templates [22:18:17] but (2) missing trxn_ids do seem to be related to the matching gifts entries [22:18:44] I haven't gone deep enough to understand how those are being created and if there's even an issue we could fix. [22:19:01] It's possible that Engage is hand-keying these and there's just no mechanism to populate trxn_id in that case. [22:19:19] Could also be that these are the soft credit portion of contributions that already do have a trxn_id [22:21:39] If the offline2civicrm gets as far as mungeMessage [22:21:39] I don't think the trxn_id can be empty [22:21:43] Ah actually to revisit (1), I don't think we create a contribution_tracking record for manually entered contributions. We might consiter doing that. [22:21:51] * ejegg remembers he was going to look into soft credits and got distracted [22:21:52] eileen1: ok that sounds reasonable [22:22:53] That function is called by parseRow [22:23:45] which is not overridden (except by SquareFile which then calls the parent) [22:23:48] eileen1: Wait, I'm not seeing anything in the code that sets trxn_id directly, isn't that done on the wmf_civicrm_contribution_import side? [22:24:34] yeah we synthesize a gateway_txn_id that should be somewhat unique yet idempotent in case the file is imported twice. [22:24:49] but trxn_id is set by the wmf_civicrm functions [22:25:24] If I import locally I get ENGAGE 4025E8C0EE4C2187E8239F056316181F in the trxn_id field [22:25:27] btw anything imported by offline2civicrm will have wmf_contribution_extra.source_* values set. [22:25:32] perfect [22:28:55] hmm - I just don't see how something using the engage import can by pass that setting of the trxn_id [22:31:16] aw man they're back [22:32:22] what's back? [22:32:46] our i[m]posters [22:33:33] pod people! [22:33:46] hehe [22:33:58] eileen1: ahh- okay so I *Think* that engage has multiple ways of entering things. [22:34:24] For the checks, they create a spreadsheet based on our import template, and MG QAs the data before running the import ourselves. [22:34:42] But for major gifts, they need to match existing contacts in the database, so they enter those manually via the Civi UI. [22:35:27] eileen1: That should be corroborated by Leanne or Rosie [22:35:53] u should be able to tell though, using the log tables, source_* etc. [22:36:11] awight: so here is an example I think [22:36:12] civicrm/contact/view/contribution?reset=1&id=17472457&cid=72&action=view&context=contribution&selectedChild=contribute [22:36:40] That is entered by an engage person - is it hand-entered? [22:39:13] Fundraising-Analysis, Fundraising-Backlog: Create new git repository for fundraising stats tools - https://phabricator.wikimedia.org/T151982#2836660 (awight) Hi @JakeTheDeveloper Thank you for the enthusiasm! This might be a difficult task to take on however, cos it requires some advanced WMF Gerrit pe... [22:40:34] eileen1: source_* is empty, so it's definitely not being created directly by the offline2civicrm import. Financial Type "engage" strongly suggests they entered it manually, since that's forced by the contribution save form hooks for anyone with the engage user role. [22:41:04] Nice example too, cos it's an EFT and not a matching gift. [22:41:09] awight: I've spot checked a few & they seem manual [22:41:35] There is data in the soft credit custom table, but I'm afraid I don't know what it means. [22:41:52] & entered by someone with the role • Engage Direct Mail [22:42:23] Fundraising-Backlog, Wikimedia-Fundraising: Thank You page to Facebook error - https://phabricator.wikimedia.org/T152026#2836680 (Pcoombe) I've been trying the debugger at https://developers.facebook.com/tools/debug/sharing/. Facebook's scraper evidently doesn't have a defined location, so the country is... [22:42:30] sounds like we can be certain it was manually entered via the Civi UI [22:42:30] but here's the thing - the issue reported is blank trxn_id [22:42:44] that's not enforced [22:43:04] and the thing about no utm_medium is not relevant [22:43:21] Probably best not to. I guess we could * analyze where null trxn_id is coming from and if they're all accounted for by manual entry [22:43:47] and * have a conversation about whether null trxn_id hurts any specific analytics and what could be better if so [22:43:52] just see if they're all missing ct rows? [22:44:07] um. yeah and if financial type = engage [22:44:17] something like that. [22:44:26] but they wouldn't have ct rows if manually entered?? [22:44:30] utm_medium is interesting but yeah let's call it a second issue [22:44:52] eileen1: right. I believe. [22:44:53] so - SHOULD they have trxn_id? [22:45:10] it's a bank deposit in front of me [22:45:11] that's more a question for the other stakeholders, I think. We don't need it for anything on our side. [22:45:43] I'm also seeing Direct Mail Appeal empty - I thought that was enforced [22:47:15] awight: looks like you're spot on - 77k entries missing trxn_id are also missing ct rows. only 7 contributions without trxn_id have ct rows [22:47:37] nope - there is not a rule on source [22:47:48] sorry direct mail [22:47:52] that is not enforced [22:50:07] OK - so in summary the entries are offline manually entered engage donations [22:50:19] They don't have a utm_medium as they did not come from the web [22:50:51] they don't have trxn_id because engage has not entered them, and it is not clear if one is really appropriate as they are often EFTS [22:51:05] yes. [22:51:11] & we are not quite clear what the problem is we are trying to solve [22:51:28] We can offer that stuff, it would be cheap for us, but yeah it depends on whether it's necessary to simplify their reporting. [22:51:41] Or if they just stumbled across some unexpected data and wanted to alert us. [22:53:07] (CR) Ejegg: "One js question, and an appeal for help with the setup." (2 comments) [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/323321 (https://phabricator.wikimedia.org/T147571) (owner: Eileen) [22:56:58] awight: ejegg: https://gerrit.wikimedia.org/r/#/c/324375/ [22:57:07] Similar patches have already gone out to other extension in last week's train. [22:57:17] CentralNotice is the last one (because it doesn't follow the train) [22:57:23] Fundraising Sprint Value Subtracting, Fundraising Sprint Waiting for Godot, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, FR-2016-17-Q2-Bugs: Engage import failing to import certain significant fields - https://phabricator.wikimedia.org/T146295#2836716 (Eileenmcnaughton) Hi @CCogdill_WM... [22:57:26] Is it going to cause errors to wait till January? [22:57:36] Krinkle: ^^^ [22:57:50] AndyRussG|bassoo: ^ [22:57:53] ejegg: It would avoid a lot of log spam in every page view console.warn(). opening dev tools with deprecation warnings is confusing and unusual for production. [22:57:57] OK - I've updated the ticket. I'm not sure whether it's going to be something cc cares about this week [22:58:26] Thanks for taking the initiative on that! [22:58:38] The "json" module is empty and a no-op. It does nothing in current production. [22:59:06] well, that patch looks totally safe [22:59:20] I can roll it out on a canary app server for you to try using https://wikitech.wikimedia.org/wiki/X-Wikimedia-Debug [22:59:23] I always want AndyRussG's input on CN deploys though [22:59:55] (CR) Eileen: Add extension with screen to do data entry on unsubscribing emails. (1 comment) [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/323321 (https://phabricator.wikimedia.org/T147571) (owner: Eileen) [22:59:59] (if you don't have the Chrome or Firefox extension installed already, I'd recommend it :) [23:01:55] (CR) Eileen: "Thanks for tackling this ejegg - I know it's a bit longer than the normal patch!" (1 comment) [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/323321 (https://phabricator.wikimedia.org/T147571) (owner: Eileen) [23:04:23] Krinkle: cool! If you don't mind pushing it to a canary server I'd be glad to take a look [23:06:24] (CR) Eileen: [C: 1] "This looks solid to me - although I'm not sure how to test it. One thing I noticed - it assumes only one of the conditions (null data, out" [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/324343 (https://phabricator.wikimedia.org/T151954) (owner: Ejegg) [23:10:06] (PS2) Ejegg: Less noisy queue consumer logging [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/324343 (https://phabricator.wikimedia.org/T151954) [23:11:50] ejegg: OK. done. Please verify in prod regular that you see the deprecation warning in the browser console. then try again using mwdebug1001. [23:12:13] will do [23:12:41] ejegg: that patch reads as being correct - but just wondering what I need to do to test it [23:13:08] ejegg: The deprecation warning isn't in group2 yet, it's in group0 or group1 so check on commons, or meta wiki or another non-wikipedia. [23:13:18] ah, gotcha [23:13:30] I used https://meta.wikimedia.org/?banner=B1617_112919_en6C_dsk_p1_lg_bdr_prp [23:13:33] yeah, I was only seeing a couple warnings for jquery.ui things [23:13:59] yep, there's the json warning [23:15:27] the jqui warnings are because wikibase is using jqui in one place. [23:15:32] That's another one to fix this week :) [23:16:06] hmm, got the ff extension turned on with mwdebug1001 selected, but I'm still getting parsed by mw1267 [23:17:35] trying chrome [23:24:16] Krinkle: ejegg awight hi! backscrollbrowsing... [23:24:34] ejegg: Be sure to refresh without cache to avoid 304 Not Modified [23:25:11] though it shouldn't matter as the main code is in load.php responses (startup and such), which wil bypass cache either way in that mode [23:27:43] huh, definitely getting fresh pages (following links from random), I see the debug header, but it doesn't match the 'parsed' comment [23:31:29] We should document somewhere that a queue backlog of 5k corresponds roughly to a 20 minute delay in thank-you letters. That must be a linear relationship--score! [23:31:44] so 10k is about a 40-second delay [23:32:15] err. minute. [23:32:26] ejegg: there was a change in which backend is used for that, I think there was an announcement that the extension will say the wrong thing still for a little while [23:33:03] yeah, I think I'm using the current ones - mwdebug1001 and mwdebug1002 [23:33:13] awight: wgHostname and parsedby may be different if hitting parser cache [23:33:20] parsing of wikitext vs wrapping skin around [23:33:25] oh hah, I bet those are just aliases to 1065 and 1067 [23:33:35] mwdebug1001 is the one where I have the changes staged [23:33:37] oh, or parser cache [23:33:49] mwdebug1001 used to be mw1017 (decom) mwdebug1002 used to be mw1099 (decom) [23:34:04] they are now their own server, not an alias [23:34:10] got it [23:34:14] but you see the bannerworking and no json warning? [23:34:35] yeah, that part is working as expected with the header switch! [23:35:44] https://lists.wikimedia.org/pipermail/wikitech-l/2016-November/087080.html [23:36:23] AndyRussG: yep, the mwdebug hosts are in the browser extensions now and I was using them [23:37:49] Krinkle: thanks for working on this!!! What was the old json module for then? [23:37:51] gotta run for a bit! [23:39:16] AndyRussG: The old json module registered a polyfill (json2.js) for JSON.parse and JSON.stringify for older browsers - and it only loaded this file if a test for !!window.JSON returned false (using the RL skipFunction feature). We ran a test last month and verified this test returned true for more than 99.9% of browsers. It has since then been added to the [23:39:17] feature test / browser blacklist in startup.js, so the module was redundant. [23:40:18] cool! [23:40:21] only affected browsers were Chrome 1.0 (2008) and [23:40:33] Safari 4.0 (2007) [23:40:36] https://phabricator.wikimedia.org/T141344#2784065 [23:40:39] https://github.com/wikimedia/mediawiki/commit/fd5c3b5817167ef59342aaca17ac6bfe44e5a719 [23:40:40] Well [23:40:53] Those were good years, but we should look to the future. [23:41:06] We already don't support IE8, and IE9 has it. [23:41:26] (for Grade A Js that is) [23:41:30] yep [23:41:30] (we support all the above for Grade C) [23:41:45] K [23:42:01] It'll go out in 20min with SWAT unless there's an issue :) [23:42:10] AndyRussG: I'm totally unconcerned about the patch [23:42:21] ejegg: yeah! thanks, I agree [23:42:24] Krinkle: ^ :) [23:42:33] Thanks [23:42:42] Krinkle: likewise!!!!!! :) [23:43:13] Sorry to have been the console-spamming stragglers....