[00:26:57] eileen: are we expecting it to be rtl in the preview? [00:27:11] cstone: I think we are expecting it to be a complete mess [00:27:16] haha [00:27:22] but in my IDE it was rtl but not in gerrit [00:27:27] oh no [00:27:28] haha [00:27:30] ok [00:27:39] but - honestly I think it's that bad that the words didn't copy in order [00:27:57] ok i see the ide vs gerrit [00:35:44] nuu the email test is using my personal email [00:37:05] not that it makes sense the he ty email is backwards in gerrit but correct when its actually sent [00:38:56] nothing about it makes sense [00:47:10] hey my garmin watch can handle hebrew but not japanese hah [00:47:24] 10Fundraising-Backlog, 10Wikimedia-Fundraising-CiviCRM, 10fundraising Sprint NULL calorie food cart, 10fundraising sprint onion pit, and 2 others: Recurring donors segmentation criteria Civi/Acoustic - https://phabricator.wikimedia.org/T283798 (10Eileenmcnaughton) @KHaggard I guess what I meant by 'last_re... [00:47:49] oh they merged me [00:47:50] oh no [00:47:51] haha [00:48:45] eileen: if they merged my personal civi account with the work one is there an easy undo [00:48:52] cstone: there is [00:48:56] or should be [00:48:59] or i guess [00:49:05] you should be able to find the change on your activity tab [00:49:09] & revert it [00:53:23] oh shoot eileen it's not just the casing - that preg_grep is looking for the name without the _123 id suffix [00:53:36] i guess will they just merge me again though haha [00:53:42] so i'm still getting errors even with the lcase name [00:54:49] or i guess its fine to stay merged, just do you see any issues with my civi login being my person email account name? [00:55:03] er be tied to my personal email account [00:56:31] eileen you haven't seen errors in production running the custom field update drush script? [00:56:54] ejegg: I haven't run it yet - I thought the lcast name would fix it [00:57:33] to be honest normally Rosie adds the fields & we only add locally [00:59:14] So the issue is that here in the logging schema sync: https://github.com/civicrm/civicrm-core/blob/5aa3eb6665501264c4603844712a9587abfc9ce7/CRM/Logging/Schema.php#L520 [00:59:31] they try to get the definition of the column by grepping through the 'create table' [00:59:44] and what they're grepping for is $customField->name [01:00:16] but that name doesn't have the _123 id tagged onto the end of it [01:00:19] and the column does [01:00:23] so the grep fails [01:00:44] ejegg: ok - let's just define column name for now [01:01:03] cool, i like predictable column names better anyway [01:01:47] just not sure the CustomField.php will pass the right value even then: https://github.com/civicrm/civicrm-core/blob/master/CRM/Core/BAO/CustomField.php#L157 [01:01:50] (03PS3) 10Eileen: Use lcase name [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/710124 [01:01:59] let's try it [01:02:16] it might not - but they will be the same so we will be OK :-) [01:02:25] heh, right [01:02:33] I'll dig more - but not on this phab [01:02:38] cool cool [01:02:44] if I can help it [01:09:46] (03CR) 10Ejegg: [C: 03+2] "Looks good, works locally!" [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/710124 (owner: 10Eileen) [01:10:31] 10Fundraising-Backlog, 10Wikimedia-Fundraising-CiviCRM, 10fundraising sprint onion pit: Send Receipts not working from civi - https://phabricator.wikimedia.org/T288149 (10Eileenmcnaughton) @nnichols can you confirm what you are doing - you should see a few actions to the right of each contribution on the lis... [01:10:39] eileen: would it be restore from trash or something on the activity itself [01:10:51] cstone: in the change log tab [01:11:05] not activity like I said before.... [01:11:24] 10Fundraising-Backlog, 10Wikimedia-Fundraising-CiviCRM, 10fundraising sprint onion pit: Send Receipts not working from civi - https://phabricator.wikimedia.org/T288149 (10Eileenmcnaughton) a:03Eileenmcnaughton [01:13:05] in the view details? [01:13:33] ooooh i see [01:13:34] okay [01:14:06] it will revert all 1091 changes listed? [01:15:01] ahhh, the erroneous code is only used for bulk saves [01:15:10] ok, I'mma make a core PR [01:17:54] bah its later than i thought, Im gona go to try and get some sleep see everyone tomorow [01:18:25] cstone: thats a lotta changes - mostly activity contact records I guess [01:18:53] eileen: yeah it had all my test donations [01:20:32] (03CR) 10jerkins-bot: [V: 04-1] Use lcase name [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/710124 (owner: 10Eileen) [01:21:06] oh boo [01:21:41] how did that mess up ImportMessageTest::testDuplicateHandling ??? [01:21:45] and nothing else [01:28:53] it passed locally [01:29:04] (03CR) 10Eileen: "recheck" [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/710124 (owner: 10Eileen) [01:33:30] eileen: upstream PR - https://github.com/civicrm/civicrm-core/pull/21019 [01:34:07] thanks ejegg - that looks right [01:34:13] with that merged, I can run the update-custom-fields successfully even without the latest patch [01:34:24] and it doesn't touch the UI codepath [01:39:18] cool [01:45:53] thanks for the CR cstone ! [01:52:21] 10Fundraising-Backlog, 10Wikimedia-Fundraising-CiviCRM, 10fundraising Sprint NULL calorie food cart, 10fundraising sprint onion pit, 10Patch-For-Review: Wmf-donor - new year fields - https://phabricator.wikimedia.org/T280595 (10Ejegg) Feels like year total and y-o-y change fields should go back a maximum... [01:53:34] ejegg: the same PR passed - we can pick up your patch once merged upstream - or earlier if we need to [01:53:43] yay! [01:54:21] I think my issues getting my creaky old local db in sync will actually be easier to solve with it too [01:57:32] ejegg: the next rc is gonna be cut today or tomorrow so we can roll that out with your patch in it [01:57:48] sounds good [01:57:56] (03PS1) 10Eileen: Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/crm into deployment [wikimedia/fundraising/crm] (deployment) - 10https://gerrit.wikimedia.org/r/710132 [01:58:16] (03CR) 10Eileen: [C: 03+2] Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/crm into deployment [wikimedia/fundraising/crm] (deployment) - 10https://gerrit.wikimedia.org/r/710132 (owner: 10Eileen) [02:07:39] (03Abandoned) 10Eileen: Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/crm into deployment [wikimedia/fundraising/crm] (deployment) - 10https://gerrit.wikimedia.org/r/710122 (owner: 10Eileen) [02:46:54] !log civicrm revision changed from d6baf291f4 to e52f569991, config revision is 360c8a1f08 [02:47:02] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [02:49:20] dang I ran the ucf update & its trying to add wmf_donor year field [02:50:56] oh dang, let's just bump that min_rollup_year up to 2011 [02:51:33] i think that gets us under 64, right? [02:57:10] ejegg|away: ug - did you see my email [02:57:22] looking [02:57:37] also - if fr-online broad enough? [02:57:59] yeah fr-online should be broad enough [02:58:16] hmm, wonder how the queues are doing [02:58:42] it's a bit worst of both worlds - I killed the drush command but the table alter is still running - so I'll have to figure out how to do the create without re-altering the table [02:59:51] ejegg|away: are you turning off queues or shall I? [03:00:33] let's see, maybe just donations [03:01:15] i'll do it [03:01:33] so I think it could take up to 40 minutes! [03:01:53] ok, i'll disable them all [03:01:53] I could ping Dallas to kill but probably it will run through by then [03:02:12] it'll fail on the wmf_donor table, right? [03:02:22] b/c of the >64 indexes ? [03:03:20] !log disabled fundraising scheduled jobs (process-control) [03:03:24] ejegg: no - because it's running off the 'old' max date [03:03:25] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [03:03:35] ah OK [03:03:51] it's putting fields we already have on dev onto live - and they are the highest priority ones [03:04:11] but not all the extra requested ones - + I was gonna add to the end of next year [03:04:18] or actually mid 2023 [03:04:40] re the indexes - do you think we should just drop the indexes from the older fields (& keep the fields) [03:05:26] i guess we could - as long as the queries that are run to update superset won't then become untenable [03:06:00] yeah so that IS the thing [03:06:24] eyener has asked for 'all funds' - ie endowment + foundation [03:06:41] but, for superset exports the 2 can be added together [03:06:50] but, I think eyener wants to do more in search kit [03:06:58] ah dang [03:08:30] but probably they won't filter on the older fields much,.... [03:16:53] ejegg: good news & bad news - good is I that the benefactor fields have created ok, bad is that the contact summary page won't load right now, good is that no-one has replied to the email or slack pings so maybe they aren't on? [03:18:16] so is there still a process running? or did it all finish and leave things in a broken state? [03:18:27] it's still running [03:19:16] I think it will be 'all good' once the query finished [03:22:38] ejegg: well once it finishes we can reload the triggers & add to silverpop & populate. I've unintentionally separated the urgent bit from the extra requests on the wmf_donor fields [03:22:53] ok [03:25:44] dang - I think the query belatedly killed - but that doesn't work because we need those fields there now [03:25:50] I'm re-running it [03:25:53] argh [03:25:57] ok, cool [03:25:58] I think it's better to push through now [03:26:06] yeah, definitely [03:26:16] let's leave this in as consistent a state as possible [03:26:23] esp since there has been no repsonse to my email / slack update [03:31:22] 10Fundraising-Backlog, 10Wikimedia-Fundraising-CiviCRM, 10fundraising sprint onion pit: Fredge report only lets you export <200 rows - https://phabricator.wikimedia.org/T287994 (10Eileenmcnaughton) @RKumar_WMF so I just uploaded that list of csv & I got a report with 298 rows. When I choose export as csv I g... [03:49:56] the alter statement is gaslighting me - it keeps incrementing % done up to nearly 100% & then drops back to 0% [03:59:50] ejegg: it looks like we are all good now [04:01:33] yep, looks good [04:02:01] i'll turn queues back on [04:02:54] cool [04:03:42] !log re-enabled fundraising scheduled jobs (process-control) [04:03:49] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [04:04:11] thanks for getting that sorted eileen! I'mma head to bed now [04:08:25] 10Fundraising-Backlog, 10Wikimedia-Fundraising-CiviCRM, 10fundraising sprint onion pit: Fredge report only lets you export <200 rows - https://phabricator.wikimedia.org/T287994 (10RKumar_WMF) @Eileenmcnaughton - It seems we can do more than 200 rows but I am not sure of the upper limit. I have updated the sh... [04:12:12] 10Fundraising-Backlog, 10Wikimedia-Fundraising-CiviCRM: Silverpop fail mail - https://phabricator.wikimedia.org/T288187 (10Eileenmcnaughton) [04:13:06] (03PS1) 10Eileen: Trigger update [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/710135 (https://phabricator.wikimedia.org/T280595) [04:21:34] PROBLEM - check_mysql on frdb2002 is CRITICAL: SLOW_SLAVE CRITICAL: Slave IO: Yes Slave SQL: Yes Seconds Behind Master: 1363 [04:22:30] PROBLEM - check_mysql on frdb2001 is CRITICAL: SLOW_SLAVE CRITICAL: Slave IO: Yes Slave SQL: Yes Seconds Behind Master: 1421 [04:22:34] PROBLEM - check_mysql on frdb1002 is CRITICAL: SLOW_SLAVE CRITICAL: Slave IO: Yes Slave SQL: Yes Seconds Behind Master: 1426 [04:23:08] 10Fundraising-Backlog, 10Wikimedia-Fundraising-CiviCRM, 10fundraising sprint onion pit: Fredge report only lets you export <200 rows - https://phabricator.wikimedia.org/T287994 (10Eileenmcnaughton) ok - so the error is the same as for search kit - ie we are using the url to pass information & it just gets to... [04:25:34] PROBLEM - check_mysql on frdev1001 is CRITICAL: SLOW_SLAVE CRITICAL: Slave IO: Yes Slave SQL: Yes Seconds Behind Master: 1604 [04:26:34] PROBLEM - check_mysql on frdb2002 is CRITICAL: SLOW_SLAVE CRITICAL: Slave IO: Yes Slave SQL: Yes Seconds Behind Master: 1663 [04:27:30] PROBLEM - check_mysql on frdb2001 is CRITICAL: SLOW_SLAVE CRITICAL: Slave IO: Yes Slave SQL: Yes Seconds Behind Master: 1721 [04:27:34] PROBLEM - check_mysql on frdb1002 is CRITICAL: SLOW_SLAVE CRITICAL: Slave IO: Yes Slave SQL: Yes Seconds Behind Master: 1726 [04:30:34] PROBLEM - check_mysql on frdev1001 is CRITICAL: SLOW_SLAVE CRITICAL: Slave IO: Yes Slave SQL: Yes Seconds Behind Master: 1904 [04:31:34] PROBLEM - check_mysql on frdb2002 is CRITICAL: SLOW_SLAVE CRITICAL: Slave IO: Yes Slave SQL: Yes Seconds Behind Master: 1964 [04:31:39] ACKNOWLEDGEMENT - check_mysql on frdb1002 is CRITICAL: SLOW_SLAVE CRITICAL: Slave IO: Yes Slave SQL: Yes Seconds Behind Master: 1726 Dwisehaupt wmf_donor alter causing replication lag [04:31:39] ACKNOWLEDGEMENT - check_mysql on frdb2001 is CRITICAL: SLOW_SLAVE CRITICAL: Slave IO: Yes Slave SQL: Yes Seconds Behind Master: 1721 Dwisehaupt wmf_donor alter causing replication lag [04:31:39] ACKNOWLEDGEMENT - check_mysql on frdb2002 is CRITICAL: SLOW_SLAVE CRITICAL: Slave IO: Yes Slave SQL: Yes Seconds Behind Master: 1964 Dwisehaupt wmf_donor alter causing replication lag [04:31:39] ACKNOWLEDGEMENT - check_mysql on frdev1001 is CRITICAL: SLOW_SLAVE CRITICAL: Slave IO: Yes Slave SQL: Yes Seconds Behind Master: 1904 Dwisehaupt wmf_donor alter causing replication lag [04:36:34] RECOVERY - check_mysql on frdb2002 is OK: Uptime: 3580394 Threads: 11 Questions: 130640914 Slow queries: 1682 Opens: 1587 Flush tables: 1 Open tables: 1251 Queries per second avg: 36.487 Slave IO: Yes Slave SQL: Yes Seconds Behind Master: 0 [04:37:30] RECOVERY - check_mysql on frdb2001 is OK: Uptime: 3579719 Threads: 11 Questions: 130640055 Slow queries: 1652 Opens: 1614 Flush tables: 1 Open tables: 1262 Queries per second avg: 36.494 Slave IO: Yes Slave SQL: Yes Seconds Behind Master: 0 [04:47:34] RECOVERY - check_mysql on frdb1002 is OK: Uptime: 3152280 Threads: 12 Questions: 128300089 Slow queries: 1543 Opens: 886960717 Flush tables: 1 Open tables: 200 Queries per second avg: 40.700 Slave IO: Yes Slave SQL: Yes Seconds Behind Master: 0 [04:55:34] RECOVERY - check_mysql on frdev1001 is OK: Uptime: 2992582 Threads: 17 Questions: 128080098 Slow queries: 2443844 Opens: 933690150 Flush tables: 1 Open tables: 200 Queries per second avg: 42.799 Slave IO: Yes Slave SQL: Yes Seconds Behind Master: 0 [06:04:04] (03PS1) 10Eileen: Follow up settings fixes on custom update fields [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/710137 (https://phabricator.wikimedia.org/T281268) [08:05:40] (03PS2) 10Thiemo Kreuz (WMDE): Update small code pieces to use more modern PHP 7 syntax [extensions/CentralNotice] - 10https://gerrit.wikimedia.org/r/683617 [11:32:57] hi fr-tech! [12:57:13] 10Fundraising-Backlog, 10Wikimedia-Fundraising-CiviCRM, 10fundraising sprint onion pit, 10fundraising-tech-ops: Request for fr-tech-ops to Update civi staging databases back in sync with production - https://phabricator.wikimedia.org/T287632 (10Jgreen) a:03Jgreen Update: Aug 4 12:30:58 frdev1001 select... [14:12:53] hi fr-tech! [14:13:10] damilare: want to release a new version of the SmashPig library? [14:14:14] Not sure I understand ejegg, but sounds exciting [14:14:30] it's fun, for sure! [14:14:41] so you'll need an account over at https://packagist.org [14:14:56] want to create one there, then let me know the username? [14:21:17] hi ejegg [14:26:30] I've created the accouunt ejegg, the username is damilare [14:28:24] ok great, let me add you as an owner of our two libraries [14:29:11] ok, you're added [14:29:14] hi fr-tech [14:29:22] hi jgleeson and cstone [14:30:17] damilare: OK, so packagist.org is the central repository for composer, but it basically just has metadata, not the packages themselves [14:30:51] Ok [14:30:55] so the listing for SmashPig https://packagist.org/packages/wikimedia/smash-pig just has the requirements, the latest version, and the URL for the actual code repo [14:31:01] hi jgleeson and cstone [14:31:01] hi cstone ! [14:31:19] hi again damilare :) [14:31:35] if you visit that URL now, you should see a few action buttons under the package description - Abandon, Update, and Edit [14:32:10] hi fr-tech jgleeson ejegg damilare cstone :) [14:32:15] when you tell packagist to Update a package, it just fetches the tags from the source repository [14:32:18] hi AndyRussG ! [14:32:21] :) [14:32:31] hi AndyRussG [14:32:35] :) :) [14:32:50] so it fetches the tags from the source repository and compares anything that looks like a version tag to the latest version in knows about [14:33:53] the latest version listed is 0.7.0 [14:34:07] ok [14:34:30] and we want to release a minor update, so we can call it 0.7.1 [14:34:52] have you ever used tags in git before? [14:35:13] hey AndyRussG ! [14:35:18] yh to find specific package version [14:35:42] yep yep, that's exactly our use case [14:36:23] so to add a new tag, cd to your Smashpig checkout and make sure you've got the latest on the master branch [14:36:52] then git tag v0.7.1 [14:36:58] then [14:37:26] git push origin v0.7.1 [14:37:44] oh, that last might need to be [14:37:59] git push gerrit v0.7.1 [14:38:08] depending on your remote name [14:38:58] brb [14:40:42] ok, I've pushed the tag [14:45:41] ok, the next thing to do is just to hit that 'Update' button on the packagist page for SmashPig [14:45:50] https://packagist.org/packages/wikimedia/smash-pig [14:46:49] done [14:47:00] great, it's published! [14:47:19] so now we want to update the version deployed to payments-wiki [14:47:30] 10Fundraising-Backlog, 10fundraising-tech-ops: SSL cert for my PC so I can access Superset - https://phabricator.wikimedia.org/T288246 (10spatton) [14:47:43] ok [14:47:55] over in your mediawiki core checkout, make sure you have the latest version of the fundraising/REL1_35 branch [14:48:20] and then cd into vendor and make sure that submodule is ALSO on the latest version of fundraising/REL1_35 [14:48:50] if vendor has a bunch of untracked files, it's easiest to just rm -rf vendor && git submodule update --init vendor [14:48:56] to restore it to the clean state [14:50:45] one moment ejegg, where can I find the mediawiki core checkout, is it dev/src/smashpig/Core [14:51:01] a sorry, let me back up here [14:51:22] so we have just published a new version of the composer library of SmashPig [14:51:38] we have two other projects which depend on that composer library [14:51:45] crm and payments-wiki [14:52:04] ok [14:52:36] right now we want to update the version of the SmashPig library which is deployed to payments-wiki [14:53:28] and payments-wiki is deployed by checking out a particular branch of mediawiki - fundraising/REL1_35 [14:54:04] so in dev/src/payments/ [14:54:17] make sure you have the latest commits on fundraising/REL1_35 [14:56:10] we're going to use composer to update the package [14:56:39] so most projects which use composer or npm will check the lock file into the source repo [14:57:09] i.e. composer.lock or package-lock.json [14:57:52] yea [14:58:07] while the dependency list file may say that any version of foolib between 7 and 8 will work, the lock file will specify that foolib 7.2.13 is the exact version in use now [14:58:22] anyway, we do check in our composer.lock file [14:58:38] but we ALSO do something a lot of projects don't, which is to check in the whole vendor directory [14:58:51] we do that because our deploy process is very locked down [14:59:03] and we can't run composer at the time of deploy [14:59:47] Ok [14:59:51] our deploy host is only allowed to fetch software from the gerrit repository, not all the random places where our other dependencies come from [15:00:07] so instead, we run composer install --no-dev on our local machines [15:00:30] then check in the resulting vendor directory to a submodule of the mediawiki/core repo [15:01:10] there's a similar process for main cluster deploys, so we just use our own branch in the same repo they use: mediawiki/core/vendor [15:01:28] and we use the same branch name as we use for core: fundraising/REL1_35 [15:02:28] So, in order to update those packages, we want to make sure both the core checkout (in dev/src/payments) and the vendor checkout (in dev/src/payments/vendor) are up to date with the latest fundraising/REL1_35 [15:02:43] and don't have a lot of untracked files (like dev-dependencies) [15:03:25] Ok [15:03:56] Understood, pulling from origin now on core checkout [15:05:42] yep, git pull always takes a little while in that repo because there's so much activity on the other branches [15:09:48] Ok the pull is complete [15:10:21] ok, so i imagine if you cd into vendor and type git status you will see a lot of untracked files [15:10:22] And the vendor checkout is up to date with the latest fundraising/REL1_35 [15:10:29] oh ok, great [15:11:04] so up in the /payments directory, we want to use composer to update only the wikimedia/smash-pig package, without installing development dependencies [15:11:09] the command for that is [15:11:24] composer update --no-dev wikimedia/smash-pig [15:14:11] then we need to commit the change in vendor first [15:14:32] https://www.mediawiki.org/wiki/Fundraising_tech/Deployment#Deployment_process [15:15:10] ok [15:15:18] because we want the core checkout to include both the composer.lock change and the vendor submodule update [15:15:32] so we need to create that commit in the vendor submodule first [15:20:09] 10Fundraising-Backlog, 10Wikimedia-Fundraising-CiviCRM, 10fundraising Sprint NULL calorie food cart, 10fundraising sprint onion pit, and 2 others: Recurring donors segmentation criteria Civi/Acoustic - https://phabricator.wikimedia.org/T283798 (10MSuijkerbuijk_WMF) Thanks @Eileenmcnaughton -- these changes... [15:39:56] looks like I don't have access to the vendor repo on gerrit [15:49:12] 10Fundraising-Backlog, 10Wikimedia-Fundraising-CiviCRM, 10fundraising Sprint NULL calorie food cart, 10fundraising sprint onion pit, and 2 others: Recurring donors segmentation criteria Civi/Acoustic - https://phabricator.wikimedia.org/T283798 (10KHaggard) I like your list of "required changes" @Eileenmcna... [15:59:03] ok damilare, let me see if I can get you access to that repo [16:00:03] ohh it's mediawiki/vendor not mediawiki/core/vendor [16:02:09] let's see, it looks like you are in the fundraising group just fine: https://gerrit.wikimedia.org/r/admin/groups/2d819982ec99908ce0c986891033e1728dc38fab,members [16:02:39] and that fundraising has access to mediawiki fundraising branches: https://gerrit.wikimedia.org/r/admin/repos/mediawiki,access [16:29:47] 10Fundraising Sprint Mandatory corn dogs, 10Fundraising-Backlog, 10Wikimedia-Fundraising-CiviCRM, 10fundraising Sprint NULL calorie food cart, and 2 others: Modification to Fredge Report - https://phabricator.wikimedia.org/T285321 (10EMartin) Hi Rakhi, can you get Eileen a file to work with? ---------- Fo... [16:50:49] 10Fundraising-Backlog, 10fundraising-tech-ops, 10SRE, 10Traffic, and 2 others: SSL cert for links.email.wikimedia.org - https://phabricator.wikimedia.org/T188561 (10DStrine) @JBennett @BBlack @Dwisehaupt @Jgreen I'm hearing that the email service provider (now branded acoustic) is getting higher ratings. W... [17:02:38] 10Fundraising-Backlog, 10fundraising-tech-ops: SSL cert for my PC so I can access Superset - https://phabricator.wikimedia.org/T288246 (10DStrine) @spatton We haven't really done this before. I've emailed the fr-privacy group to weigh in. I would like to see what they think before moving forward. [17:16:01] (03PS1) 10Damilare Adedoyin: Update smashpig [core] (fundraising/REL1_35) - 10https://gerrit.wikimedia.org/r/710308 [17:19:09] (03CR) 10jerkins-bot: [V: 04-1] Update smashpig [core] (fundraising/REL1_35) - 10https://gerrit.wikimedia.org/r/710308 (owner: 10Damilare Adedoyin) [17:27:38] (03PS1) 10Damilare Adedoyin: update smashpig on core [core] (fundraising/REL1_35) - 10https://gerrit.wikimedia.org/r/710314 [17:28:48] (03CR) 10Ejegg: [C: 03+2] update smashpig on core [core] (fundraising/REL1_35) - 10https://gerrit.wikimedia.org/r/710314 (owner: 10Damilare Adedoyin) [17:30:22] (03Abandoned) 10Damilare Adedoyin: Update smashpig [core] (fundraising/REL1_35) - 10https://gerrit.wikimedia.org/r/710308 (owner: 10Damilare Adedoyin) [17:42:08] (03Merged) 10jenkins-bot: update smashpig on core [core] (fundraising/REL1_35) - 10https://gerrit.wikimedia.org/r/710314 (owner: 10Damilare Adedoyin) [18:09:14] 10Fundraising-Backlog, 10fundraising-tech-ops: SSL cert for my PC so I can access Superset - https://phabricator.wikimedia.org/T288246 (10spatton) Thanks @DStrine! I didn't realize this was unusual. What is unusual, if I may clarify; getting 2 SSL certificates at all, or having one on my non-WMF machine? [18:18:48] 10Fundraising-Backlog, 10fundraising-tech-ops: SSL cert for my PC so I can access Superset - https://phabricator.wikimedia.org/T288246 (10DStrine) The non-wmf computer part. I'm not sure how to navigate this. the only policies we can find are a bit fuzzy on this: https://office.wikimedia.org/wiki/Security/Poli... [18:20:31] 10Fundraising-Backlog: Genreal layout and organization of topics and subtopics - https://phabricator.wikimedia.org/T288279 (10AndyRussG) [18:23:10] 10Fundraising-Backlog: Genreal layout and organization of topics and subtopics - https://phabricator.wikimedia.org/T288279 (10AndyRussG) As a starting point, [[ https://www.mediawiki.org/wiki/Fundraising_tech/notes/Draft:Documentation_overhaul#Brainstorming:_topics_to_include | here ]] is a place to brainstorm i... [18:24:20] 10Fundraising-Backlog: Documentation: Genreal layout and organization of topics and subtopics - https://phabricator.wikimedia.org/T288279 (10AndyRussG) [18:24:44] 10Fundraising-Backlog, 10fundraising-tech-ops, 10FR-Adyen, 10Patch-For-Review: endpoint monitoring for adyen endpoints - https://phabricator.wikimedia.org/T287411 (10Jgreen) 05Open→03Resolved a:03Jgreen I configured monitoring of the /paymentMethods endpoint per @ Ejegg's suggestion, for now only the... [18:24:46] 10Fundraising-Backlog, 10FR-Adyen, 10Epic: Epic: Adyen reintegration, Drop In Web - https://phabricator.wikimedia.org/T277120 (10Jgreen) [18:24:53] 10Fundraising-Backlog: Documentation: General layout and organization of topics and subtopics - https://phabricator.wikimedia.org/T288279 (10AndyRussG) [18:25:29] 10Fundraising-Backlog: Documentation: General organization of topics and subtopics - https://phabricator.wikimedia.org/T288279 (10AndyRussG) [18:27:30] PROBLEM - check_log_messages on frav1002 is CRITICAL: CRITICAL: minFraud_endpoint_critical 7 [=1] [18:29:09] 0_0 [18:32:24] HMMM [18:32:27] hmmm [18:32:30] PROBLEM - check_log_messages on frav1002 is CRITICAL: CRITICAL: minFraud_endpoint_critical 7 [=1] [18:32:42] sorry (unintentional caps lock) [18:33:14] huh, why is frav looking at minfraud connectivity? [18:33:30] we do the minfraud pings from payments and civicrm [18:37:30] PROBLEM - check_log_messages on frav1002 is CRITICAL: CRITICAL: minFraud_endpoint_critical 7 [=1] [18:37:34] and payments is still getting through fine [18:38:26] Jeff_Green / dwisehaupt any reason there's a minfraud connectivity check running on frav (not payments or civi, where we actually ping minfraud) ? [18:39:08] it doesn't run on frav1002, that's just where we aggregate to alert once for clusterwise [18:39:13] oh i see [18:39:33] hmm, so the payments server seems to be making minfraud queries just fine [18:39:35] fyi I just deployed a bunch of changes to the endpoint checker [18:39:48] yeah, it's just a monitoring issue, not real [18:39:53] or at least I see some good ones at :33 for example, after these alerts started [18:39:56] ok [18:40:15] i'll happily ingore it [18:41:09] I ~think~ what's happening is minfraud is redirecting to port 80 there for some reason (the old result was a 301), and when I changed the endpoint_checker it switched from ignoring the redirect to attempting to follow it, looking into it now [18:42:01] 10Fundraising-Backlog: Documentation: General organization of topics and subtopics - https://phabricator.wikimedia.org/T288279 (10AndyRussG) [18:42:30] PROBLEM - check_log_messages on frav1002 is CRITICAL: CRITICAL: Astropay-DLocal_endpoint_critical 1 [=1],minFraud_endpoint_critical 7 [=1] [18:47:30] PROBLEM - check_log_messages on frav1002 is CRITICAL: CRITICAL: minFraud_endpoint_critical 7 [=1] [18:48:02] i'll ack the alerts so they don't clog up the channel. [18:50:05] ACKNOWLEDGEMENT - check_log_messages on frav1002 is CRITICAL: CRITICAL: minFraud_endpoint_critical 7 [=1] Dwisehaupt known issue with endpoint checker changes. being worked. [18:50:15] ACKNOWLEDGEMENT - check_log_messages on frav1002 is CRITICAL: CRITICAL: minFraud_endpoint_critical 7 [=1] Jeff_Green known, just a monitoring issue, fixing... [19:01:23] fr-tech I'm at the point no where we probably need to email Adyen again. I exhausted things to try on the first test account so set up the second Applepay test account and I'm still getting the same problem. When trying to pay with Applepay I get a popup saying "this website doesn't support the card you've added to Wallet" but I've tried about 10 different test cards including one that [19:01:26] previously worked so it feels like something is up [19:01:30] now* [19:02:29] I'll start an email now and send it over before I hop off. [19:02:59] if folks wanna email me over their public keys, I'll also add some accounts to the test server for when others wanna try out transactions. [19:04:40] also, there is some mention in the Applepay docs about logging out of icloud to use the test accounts. However this is contradicted by the fact that you must log in to icloud to add an a payment method to your Apple Pay wallet [19:05:11] lots of fun [19:27:30] RECOVERY - check_log_messages on frav1002 is OK: OK [19:32:26] 10Fundraising-Backlog, 10Wikimedia-Fundraising-CiviCRM, 10fundraising Sprint NULL calorie food cart, 10fundraising sprint onion pit, 10Patch-For-Review: Wmf-donor - new year fields - https://phabricator.wikimedia.org/T280595 (10DStrine) A bunch of us talked in the analytics meeting today. These totals ar... [19:39:51] 10Fundraising-Backlog, 10fundraising-tech-ops: SSL cert for my PC so I can access Superset - https://phabricator.wikimedia.org/T288246 (10DStrine) 05Open→03Declined [19:40:21] 10Fundraising-Backlog, 10fundraising-tech-ops: SSL cert for my PC so I can access Superset - https://phabricator.wikimedia.org/T288246 (10DStrine) This is apparently a windows machine. We have no way of handling a certificate for this OS [19:51:58] (03PS1) 10Ejegg: Remove Adyen test adapter [extensions/DonationInterface] - 10https://gerrit.wikimedia.org/r/710345 [19:52:39] (03PS1) 10Ejegg: Merge branch 'master' into deployment [extensions/DonationInterface] (deployment) - 10https://gerrit.wikimedia.org/r/710346 [19:59:35] ha. I left remote debugging on and someone just visited the test server which caused PHPStorm to pop up on my screen. hopefully it was adyen folks [20:15:16] probably a bot scanning for things to exploit. [20:15:33] since that is the way of the world with exposed ports. [20:22:57] (03CR) 10Ejegg: [C: 03+2] Merge branch 'master' into deployment [extensions/DonationInterface] (deployment) - 10https://gerrit.wikimedia.org/r/710346 (owner: 10Ejegg) [20:24:22] (03Merged) 10jenkins-bot: Merge branch 'master' into deployment [extensions/DonationInterface] (deployment) - 10https://gerrit.wikimedia.org/r/710346 (owner: 10Ejegg) [20:33:43] (03PS1) 10Ejegg: Update DonationInterface submodule [core] (fundraising/REL1_35) - 10https://gerrit.wikimedia.org/r/710355 [20:44:15] 10Fundraising-Backlog, 10Wikimedia-Fundraising-CiviCRM, 10fundraising Sprint NULL calorie food cart, 10fundraising sprint onion pit, and 2 others: Recurring donors segmentation criteria Civi/Acoustic - https://phabricator.wikimedia.org/T283798 (10Eileenmcnaughton) @KHaggard - renaming should be fine - we d... [20:49:56] (03CR) 10Ejegg: [C: 03+2] Update DonationInterface submodule [core] (fundraising/REL1_35) - 10https://gerrit.wikimedia.org/r/710355 (owner: 10Ejegg) [20:59:29] (03Merged) 10jenkins-bot: Update DonationInterface submodule [core] (fundraising/REL1_35) - 10https://gerrit.wikimedia.org/r/710355 (owner: 10Ejegg) [21:03:48] !log updated payments-wiki from 72fe99abb1 to a70aaa7944 [21:03:56] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [21:23:48] 10Fundraising-Backlog, 10fundraising Sprint NULL calorie food cart, 10fundraising sprint onion pit, 10FR-Japan, and 2 others: set Japanese monthly convert variant 11 to default - https://phabricator.wikimedia.org/T287262 (10Ejegg) This is now set to the default (for all countries where MC is on by default)... [21:56:25] (03PS1) 10Damilare Adedoyin: dded tax disambiguation clause to Payments Wiki in France [extensions/DonationInterface] - 10https://gerrit.wikimedia.org/r/710364 (https://phabricator.wikimedia.org/T286880) [21:59:05] (03CR) 10jerkins-bot: [V: 04-1] dded tax disambiguation clause to Payments Wiki in France [extensions/DonationInterface] - 10https://gerrit.wikimedia.org/r/710364 (https://phabricator.wikimedia.org/T286880) (owner: 10Damilare Adedoyin) [22:44:36] 10fundraising-tech-ops: Test and choose a benchmark to use for applying a machine standard - https://phabricator.wikimedia.org/T246841 (10Dwisehaupt) 05Open→03Resolved a:03Dwisehaupt All hosts are monitored with CIS benchmark. We are working through what changes we wish to apply to ensure hosts match the e... [22:44:38] 10Fundraising-Backlog, 10fundraising-tech-ops: Run authenticated scans of hosts checking against a known standard / benchmark - https://phabricator.wikimedia.org/T246839 (10Dwisehaupt) [23:01:21] dstrine: [23:01:30] sorry meant to say more than your name [23:02:31] I'm not sure if it was clear - but we can add more wmf_donor fields by removing older ones - or potentially just removing the indexes (so they could be displayed but not used as search criteria ) [23:03:56] eileen: hi!!! btw I'm currently digging into CR for that and am available if you'd like to talk over it [23:04:26] I think I see in all 6 patches awaiting review [23:04:52] oh sure - wanna hangout? [23:05:18] https://meet.google.com/kze-ezvu-xgg?authuser=0 [23:13:27] AndyRussG: ^ [23:13:38] I've just got that open so pop in whenever [23:15:51] eileen: one sec :) [23:16:51] eileen: we talked about that briefly in the analytics call and offered that up as an option. it's really down to what data the analytics and fundraising folks really need day to day. [23:17:03] cool [23:17:24] I haven't calculated how many we are over by [23:17:28] we may also look at condensing or distilling the data they need and putting it in a different table that more specifically fits their needs. [23:17:49] something where it wouldn't affect civi functionality if possible. [23:17:57] yeah - so stuff that is for superset or silverpop shouldn't need indexing [23:18:04] it's stuff to access from the UI that should [23:18:50] yeah. al lot comes down to not knowning what they actually use and need. :) [23:19:05] (had anyone notices how well the words silverpop & superset go together - I think acoustic's next name change should be to 'silverpop') [23:19:27] dwisehaupt: if we can get those triggers merged - can you run them [23:22:45] superpop or silverset [23:22:52] yeah. i can run the triggers.