[00:57:15] Fundraising-Backlog, MediaWiki-extensions-CentralNotice, Availability (MediaWiki-MultiDC), Beta-Cluster-reproducible, and 2 others: CentralNotice must not query master on GET request (page views) - https://phabricator.wikimedia.org/T216287 (aaron) This looks like it should use DB_REPLICA. [03:04:37] (PS4) Ejegg: Adjust Benevity import to reflect changed csv from Benevity [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/489952 (https://phabricator.wikimedia.org/T215196) (owner: Eileen) [03:07:15] (CR) Ejegg: [C: +2] "Looks great! Sorry for the delay - thinking about connecting to the VPN to download the example files always makes me drag my heels." [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/489952 (https://phabricator.wikimedia.org/T215196) (owner: Eileen) [03:07:26] thanks ejegg [03:10:47] sure thing! Just taking a peek at that drupal upgrade too [03:11:34] ejegg: yeah not much in it actually [03:11:50] there IS a pending drupal security update but it seems it’s d8 + some d7 modules [03:11:59] & I think we are unaffected but it’s not out yet [03:12:08] phar fix, host header, registry rebuild skip, huh? [03:12:15] this one looks pretty safe [03:12:29] (Merged) jenkins-bot: Adjust Benevity import to reflect changed csv from Benevity [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/489952 (https://phabricator.wikimedia.org/T215196) (owner: Eileen) [03:12:30] yeah - one of those was a regression fix which is why I thought we should grab it [03:12:54] who knows it could be the cause of Caitlin’s problem - doubtful though [03:13:01] ah, it's for the outgoing http requests [03:13:28] hmm, seems like it would only apply for retrying outgoing http requests where the original ended up in a redirect to a different host [03:13:37] can't picture that affecting quicksearch [03:13:43] but we might as well pick it up [03:13:47] (CR) Ejegg: [C: +2] Re-apply WMF patches [wikimedia/fundraising/crm/drupal] - https://gerrit.wikimedia.org/r/491573 (owner: Eileen) [03:13:54] (CR) Ejegg: [C: +2] drupal update to 7.64 [wikimedia/fundraising/crm/drupal] - https://gerrit.wikimedia.org/r/491572 (owner: Eileen) [03:14:37] ok, signing off. have a good one! [03:15:14] (CR) jerkins-bot: [V: -1] drupal update to 7.64 [wikimedia/fundraising/crm/drupal] - https://gerrit.wikimedia.org/r/491572 (owner: Eileen) [03:15:16] (CR) jerkins-bot: [V: -1] Re-apply WMF patches [wikimedia/fundraising/crm/drupal] - https://gerrit.wikimedia.org/r/491573 (owner: Eileen) [03:16:02] (CR) Ejegg: [V: +2 C: +2] drupal update to 7.64 [wikimedia/fundraising/crm/drupal] - https://gerrit.wikimedia.org/r/491572 (owner: Eileen) [03:21:17] (Merged) jenkins-bot: Re-apply WMF patches [wikimedia/fundraising/crm/drupal] - https://gerrit.wikimedia.org/r/491573 (owner: Eileen) [17:03:26] Fundraising-Backlog, fundraising-tech-ops: Redis queues should use a key prefix - https://phabricator.wikimedia.org/T216633 (Ejegg) [17:04:20] fr-tech, cwd & Jeff_Green what do you think of adding a prefix to all the queue keys in Redis? [17:05:03] cstone was screensharing from her local machine which had mediawiki configured to use redis as the session store, and it was a bit tough to see all the queue keys [17:05:27] ejegg: no objection here [17:05:33] cool [17:07:01] so we could either do it at a time when payments-wiki is down and the queues are drained [17:07:55] or deploy the new settings (/etc/smashpig/main.yaml) to payment-wiki first, run all the consumers on civi to empty the queues, then deploy the file to civi1001 [17:08:42] what about supporting both queue names at once in the consumer? [17:08:51] and disabling the old ones once they are empty [17:09:20] cwd ehhh, i guess that's possible [17:10:09] so we'd also have to split out read and write config, which seems repetitive [17:10:32] right now producer and consumer use the same config for any given queue [17:10:53] I'd prefer just staggering the rollout of the yaml file if possible [17:11:12] shouldn't take more than 10 minutes to empty all the queues [17:12:25] cwd and Jeff_Green so also, I think everything's looking good for the payments-wiki upgrade. [17:13:08] would any time tomorrow work for you guys? [17:13:44] probably need a fresh checklist [17:13:51] that upgrade is going to take a couple of hours [17:14:01] yep yep [17:14:09] there needs to be total downtime in campaigns for at least a day I think [17:14:32] ok, let's ask for a day [17:14:39] also it needs to be coordinated with Michael's team with a protocol for identifying and fixing issues [17:15:03] I'm concerned about oddball browser behavior re. the new headers [17:15:06] cool [17:17:48] ejegg: I'm going to switch the codfw cluster back to 'frdev' ok? [17:20:51] Fundraising-Backlog: Record opt-in on payment attempts - https://phabricator.wikimedia.org/T216293 (CCogdill_WMF) We're trying to figure out how high of a priority this should be. Maybe less people are being left on the table than I thought. Is it easy to figure out these stats? - the % of people who ente... [17:31:58] fr-tech this cafe's wifi isn't working amd i just ordered lunch :( [17:32:01] will send an email soon as I wcan [17:46:23] ejegg|food: no worries... ¡buen provecho! [17:46:39] (we did see your message in time, all good) [18:14:29] Fundraising Sprint A series of unfortunate event handlers, Fundraising Sprint Bert and Ernie's Excellent Adventure, Fundraising Sprint Casino Royale With Cheese, Fundraising Sprint Da Vinci Coder, and 4 others: Reduce recurring TY emails - https://phabricator.wikimedia.org/T213209 (Ejegg) One que... [18:21:45] Fundraising Sprint A series of unfortunate event handlers, Fundraising Sprint Bert and Ernie's Excellent Adventure, Fundraising Sprint Casino Royale With Cheese, Fundraising Sprint Da Vinci Coder, and 4 others: Reduce recurring TY emails - https://phabricator.wikimedia.org/T213209 (CCogdill_WMF)... [19:18:27] Jeff_Green, cwd, sounds like fr-online will need to discuss a bit to figure out a full day of downtime. I'm going to send an email to kick that off [19:18:41] ejegg: ok [19:45:35] fr-tech, is manual population of the fredge tables the best way to add some sample data there to show up in fraud reports? Or is there a more convenient way hidden somewhere :P [19:45:56] jgleeson: let's see [19:46:06] I think there's some test data checked in to the dash repo [19:47:05] jgleeson: https://github.com/wikimedia/wikimedia-fundraising-dash/blob/master/README.md#test-data [19:47:43] oh darn [19:47:57] > TODO: add payments-fraud rows to match... [19:48:16] ah [19:48:30] this looks very close to what I need though [19:48:40] I might be able to fill in the blanks for now [19:48:41] thanks! [19:49:19] That mockaroo site did a pretty good job creating fake data for the rest of the tables [19:49:41] probably wouldn't be too hard to create a schema there to generate the matching payments_fraud data [19:50:02] do you also need the per-filter scores from payments_fraud_breakdown? [19:50:11] yeah [19:50:28] hmm, ok [19:50:44] well, we don't really need a lot of diversity in those tables [19:51:02] if I can get my head around how we handle foreign keys in the fraud filter rows I think that might work [19:51:05] we could probably populate them with a couple of selects from the other tables [19:51:18] via mockaroo* [19:51:21] using some kinda silly modulo math to get scores based on the ids [19:51:48] jgleeson: there's an fk from payments_fraud to contribution_tracking [19:52:01] then an fk from payments_fraud_breakdown to payments_fraud [19:52:26] I think I understand how we link up the others, just the fraud filters have two I think [19:52:35] just need to make sure they line up [19:53:42] man I wish I found that earlier... [19:53:46] like 10 years ago earlier [19:53:49] hmm, let's see... payments_fraud_breakdown just has its pk 'id' and fk 'payments_fraud_id' [19:54:09] heh, you mean mockaroo? [19:54:12] yup [19:54:18] yeah, pretty handy [19:54:55] then the filter_name score, which maybe should be an fk but is just a varchar [19:55:23] so (payments_fraud_id, filter_name) should be a unique key [19:56:08] and the sum of all payments_fraud_breakdown.risk_score grouped by payments_fraud_id should equal the payments_fraud.risk_score with that same id [19:56:56] ah so that's how we get that number [19:57:39] OK, so I guess you could do one pass via mockaroo or something to populate payment_fraud with contribution_tracking_id, gateway, order_id, user_ip, payment_method, server, and date [19:58:11] then you could do a few selects from payments_fraud to populate payments_fraud_breakdown [19:58:29] one select per filter_name, and some module silliness to generate risk_score [19:59:34] then some kind of update with group by (might need a temp table?) to get the risk_scores summed up from the breakdown table into the payments_fraud table [19:59:51] and set the validation_action based on the different risk_score levels [20:11:43] Fundraising-Backlog, MediaWiki-extensions-CentralNotice, MinervaNeue, Accessibility, and 2 others: Banner/CentralNotice should be child of `header` and not above it - https://phabricator.wikimedia.org/T205360 (Jdlrobson) @alexhollender letting you know this got merged. Is there anyway we can tes... [20:12:06] Fundraising-Backlog, MediaWiki-extensions-CentralNotice, MinervaNeue, Accessibility, and 2 others: Banner/CentralNotice should be child of `header` and not above it - https://phabricator.wikimedia.org/T205360 (Jdlrobson) a:alexhollender [20:34:38] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Investigate speeding common searches with combined indexes - https://phabricator.wikimedia.org/T216655 (Eileenmcnaughton) [20:34:40] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Investigate speeding common searches with combined indexes - https://phabricator.wikimedia.org/T216655 (MBeat33) typical DS search: Contribution Source Like usd% ...AND... Contribution Date - greater than or equal to "January 1st, 2019 12:00 AM" AND le... [20:36:23] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Investigate speeding common searches with combined indexes - https://phabricator.wikimedia.org/T216655 (Eileenmcnaughton) [20:47:52] (Abandoned) Eileen: Show risk score by default [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/491648 (owner: Eileen) [20:52:32] (PS1) Eileen: Drupal submodule update - update core to 7.64 [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/491854 [20:53:32] (CR) Eileen: [C: +2] Drupal submodule update - update core to 7.64 [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/491854 (owner: Eileen) [20:55:52] This is a fairly easy review - https://gerrit.wikimedia.org/r/#/c/wikimedia/fundraising/crm/civicrm/+/491383/ - it just rips stuff out :-) All the hard part was in the upstream version that added tests & cleaned up & convinced people to let me rip it out [20:58:27] (Merged) jenkins-bot: Drupal submodule update - update core to 7.64 [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/491854 (owner: Eileen) [21:04:34] (Abandoned) Eileen: Add risk score to filter [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/491646 (owner: Eileen) [21:04:45] (Abandoned) Eileen: Alternative, add field [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/491647 (owner: Eileen) [21:29:47] Fundraising Sprint Da Vinci Coder, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Some users not able to use quick search - https://phabricator.wikimedia.org/T216553 (Eileenmcnaughton) a:Eileenmcnaughton I just hung out with @CaitVirtue & disabling the KAM extension resolved it Wouldn't you... [21:46:42] (PS1) Eileen: Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/crm into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/491858 [21:46:57] I about to deploy benevity & drupal update [21:47:06] (CR) Eileen: [C: +2] Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/crm into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/491858 (owner: Eileen) [21:47:43] (Merged) jenkins-bot: Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/crm into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/491858 (owner: Eileen) [21:48:30] !log civicrm revision changed from 165fbf5894 to 1b5d974569, config revision is ccefa3716b [21:48:32] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [21:52:57] Fundraising Sprint Casino Royale With Cheese, Fundraising Sprint Da Vinci Coder, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Patch-For-Review: Changes to Benevity import - https://phabricator.wikimedia.org/T215196 (Eileenmcnaughton) @LeanneS I just deployed this although I think we wa... [22:08:28] Fundraising Sprint Da Vinci Coder, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Some users not able to use quick search - https://phabricator.wikimedia.org/T216553 (Eileenmcnaughton) Alright issue for lack of visibility on what you are searching for https://github.com/aydun/uk.squiffle.kam/iss... [22:19:17] Fundraising Sprint Da Vinci Coder, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Some users not able to use quick search - https://phabricator.wikimedia.org/T216553 (Eileenmcnaughton) font feedback https://github.com/aydun/uk.squiffle.kam/issues/51 [22:24:56] catch you tomorrow fr-tech o/ [22:49:46] Fundraising-Backlog, FR-Email: Make Silverpop export leaner - https://phabricator.wikimedia.org/T173538 (DStrine) New DoD: Let's just try to only export those updated in the last 48 hours. The email team would like to see how this affects their workflow. We will create new tasks after this for other ideas. [22:50:19] Fundraising Sprint Casino Royale With Cheese, Fundraising Sprint Da Vinci Coder, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Patch-For-Review: Changes to Benevity import - https://phabricator.wikimedia.org/T215196 (LeanneS) Thanks @Eileenmcnaughton. I just did a test of ~20 rows. The... [22:58:57] Fundraising Sprint Da Vinci Coder, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Epic, FR-Email: Reflect all undeliverables via Silverpop in CiviCRM - https://phabricator.wikimedia.org/T161761 (Eileenmcnaughton) a:Eileenmcnaughton [23:03:24] hi fr-tech [23:03:31] hello [23:03:34] hi [23:03:41] group hi [23:04:38] I like group hi [23:56:09] Fundraising-Backlog, fundraising-tech-ops: Redis queues should use a key prefix - https://phabricator.wikimedia.org/T216633 (Ejegg) Alternate deploy strategy: update /etc/smashpig/main.yaml on payments first, wait till queues are empty before updating the same config file on civi1001.