[00:06:37] (PS12) Eileen: Update contribution recur statuses. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/572764 (https://phabricator.wikimedia.org/T244326) [00:06:38] (PS11) Eileen: Get rid of old review tags. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/573055 (https://phabricator.wikimedia.org/T245577) [00:06:40] (PS1) Eileen: Remove defunct contribution recur statuses. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574611 [00:06:57] statuses removal here https://gerrit.wikimedia.org/r/#/c/wikimedia/fundraising/crm/+/574611/ [00:09:20] (PS9) Eileen: Add basic thank-you extension [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/566413 (https://phabricator.wikimedia.org/T227903) [00:09:21] (PS2) Eileen: Merge sendannualttyemail with wmf_thankyou [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574601 (https://phabricator.wikimedia.org/T245580) [00:10:20] (CR) jerkins-bot: [V: -1] Add basic thank-you extension [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/566413 (https://phabricator.wikimedia.org/T227903) (owner: Eileen) [00:10:35] (CR) Eileen: "Note I checked select contribution_status_id, count(*) FROM civicrm_contribution_recur GROUP BY contribution_status_id;" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574611 (owner: Eileen) [00:11:03] (CR) Eileen: "recheck" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/566413 (https://phabricator.wikimedia.org/T227903) (owner: Eileen) [00:18:50] ejegg: MBeat I just tested sending myself an annual thank you from staging - it worked but it seemed really weird not having a signoff at the end - I'm wondering if that is on purpose or an oversight [00:19:21] The suggested template was pretty darn sparse [00:19:40] yeah - not having a from just felt really wrong [00:19:46] +1 [00:20:01] 'Katherine’ should sign it for sure [00:20:07] should I stick it in a phab? [00:20:21] I have passed that feedback on to email team [00:20:37] but if you’re feeling Phabby that would be great' [00:21:07] Wikimedia-Fundraising-Banners: Low contrast on Paypal (USD) logo when selected (blue logo on blue button background) - https://phabricator.wikimedia.org/T246051 (jbolorinos-ctr) [00:21:25] MBeat: had you already passed it on? [00:21:33] Wikimedia-Fundraising-Banners: Low contrast on Paypal (USD) logo when selected (blue logo on blue button background) - https://phabricator.wikimedia.org/T246051 (jbolorinos-ctr) p:Triage→Medium Changing priority to P3 since this does not affect all banners in Bundle campaign, however it does affect t... [00:22:38] in a feedback doc, so maybe it doesn’t need a new Phab. I think that annual summary email will be getting some wider touchups from existing Phab tasks, eileen [00:22:58] ok - I'll leave it there then [00:26:06] (PS10) Eileen: Add basic thank-you extension [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/566413 (https://phabricator.wikimedia.org/T227903) [00:26:08] (PS3) Eileen: Merge sendannualttyemail with wmf_thankyou [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574601 (https://phabricator.wikimedia.org/T245580) [00:27:27] (CR) Ejegg: [C: -1] "Looks functionally correct. Just requesting a couple of updates to log messages and a var name for clarity" (4 comments) [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/572764 (https://phabricator.wikimedia.org/T244326) (owner: Eileen) [00:31:35] (PS13) Eileen: Update contribution recur statuses. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/572764 (https://phabricator.wikimedia.org/T244326) [00:31:44] (CR) Eileen: "I think I got them all" (6 comments) [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/572764 (https://phabricator.wikimedia.org/T244326) (owner: Eileen) [00:34:03] (CR) Ejegg: [C: +2] "Looks good to me! Let's turn the charge jobs off and try it out." [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/572764 (https://phabricator.wikimedia.org/T244326) (owner: Eileen) [00:35:14] eileen: right now would be a good time to try that patch out, as there are probably a bunch of recurring donations of both types still due to run today [00:35:33] (it's 12:35 AM UTC, so we've only run one batch for each of the implementations) [00:36:35] ejegg: cool - just merging to deployment [00:36:56] I guess we can stop jobs now [00:37:08] ok, I'm on frpm so I can do that [00:38:52] !log disabled recurring donation charge jobs for CiviCRM update [00:38:56] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [00:40:31] (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/574613 [00:40:41] (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/574613 (owner: Eileen) [00:43:48] ejegg: it's merged - if you are still on there do you want o deploy [00:43:56] (PS12) Eileen: Get rid of old review tags. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/573055 (https://phabricator.wikimedia.org/T245577) [00:43:56] (PS2) Eileen: Remove defunct contribution recur statuses. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574611 [00:43:56] sure thing [00:46:21] !log updated Fundraising CiviCRM from 87b13fd3b5 to b9d1acdb6d [00:46:24] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [00:46:25] oh boy.... [00:46:37] so let's see if those jobs are actually still running [00:47:20] nope, only the TY mail sender running now [00:47:43] so I guess I'll try a --slow-start and we can examine the outcome [00:47:55] I'll go for the old integration (globalcollect) first [00:49:42] ooohhh [00:49:45] it's happening [00:49:53] OK, looks like 1 got through fine [00:49:57] let's review the log [00:50:55] ct_id 56880123 [00:53:46] contribution_recur_id is 297728 [00:54:51] hmm, modified date is set in PST [00:55:02] but I don't think that's the fault of this patch [00:56:33] (PS11) Eileen: Add basic thank-you extension [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/566413 (https://phabricator.wikimedia.org/T227903) [00:56:39] cid is 6433496 [00:56:51] db record looks good to me [00:56:54] Let's see the UI [00:59:17] sure, looks good there too [00:59:47] although the pager and the sort are not working together like i'd expect on the modal for viewing all the contributions associated with a subscription [01:01:18] hmm I guess that's a core bug - or missing feature [01:02:48] (CR) jerkins-bot: [V: -1] Add basic thank-you extension [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/566413 (https://phabricator.wikimedia.org/T227903) (owner: Eileen) [01:07:26] (PS12) Eileen: Add basic thank-you extension [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/566413 (https://phabricator.wikimedia.org/T227903) [01:11:08] (PS13) Eileen: Add basic thank-you extension [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/566413 (https://phabricator.wikimedia.org/T227903) [01:15:38] (PS14) Eileen: Add basic thank-you extension [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/566413 (https://phabricator.wikimedia.org/T227903) [01:17:07] OK, let's try one with the SmashPig recurring [01:18:46] well, the first one wasn't authorized, let's see how it looks [01:20:52] cid 27591420 [01:22:06] ok, looks like it's got the new 'Failing' status [01:22:08] trying another [01:23:37] that sounds like a good thing... [01:24:04] also not authorized, and seems to have hit the max failure count [01:24:12] now showing up as 'Cancelled' [01:24:20] heh, these are good test cases [01:24:26] :-) [01:25:18] hmm, each new one I try is 'not authorized' [01:25:32] could it be that all the good cards were already charged in the first run? [01:26:19] do we retry them that quickly? [01:26:42] We should wait a day [01:33:06] so let's see, there were 762 successes and 36 failures in the first run [01:33:12] looking at some of those failures now [01:34:51] so I get a total of 392 'due today' SELECT * FROM civicrm_contribution_recur WHERE next_sched_contribution_date BETWEEN '2020-02-24' AND '2020-02-25' [01:35:13] ejegg: leap year this month - I wonder what will break [01:39:09] oh shoot, why is failure_retry_date null? [01:39:28] (PS15) Eileen: Add basic thank-you extension [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/566413 (https://phabricator.wikimedia.org/T227903) [01:39:30] (PS1) Eileen: temp debug [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574623 [01:42:28] oh heck, we seem to be using the next_sched_contribution_date. Why aren't we using the failure_retry_date then? [01:43:10] I mean, we're just pushing the next_sched_contribution_date forward instead of setting a failure_retry_date [01:43:13] hmm hmm [01:43:27] yeah .... [01:44:41] (PS2) Eileen: temp debug [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574623 [01:56:17] eileen: oh shoot, there's no 'Processing' status in our database! [01:56:27] it's using 'Template' for some reason [01:56:35] Oh, I guess because it's the last numerically? [01:57:29] did we miss something in the upgrade? [01:57:33] it's there - see other channel [02:06:00] (PS1) Eileen: Fix references to recur status [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574626 (https://phabricator.wikimedia.org/T244326) [02:09:03] (PS2) Eileen: Fix references to recur status [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574626 (https://phabricator.wikimedia.org/T244326) [02:10:19] OK- template has the same id as processing [02:19:16] yeah, that was what confused me [02:22:35] (CR) Ejegg: "Nice catch! Could you please also fix the instances of civicrm_api_contribution_status in this patch too? It looks like ALL of those actua" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574626 (https://phabricator.wikimedia.org/T244326) (owner: Eileen) [02:35:55] (PS3) Eileen: Fix references to recur status [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574626 (https://phabricator.wikimedia.org/T244326) [02:36:13] (CR) Eileen: "Done - there was one place that DID refer to contribution status." [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574626 (https://phabricator.wikimedia.org/T244326) (owner: Eileen) [02:36:54] ejegg: I realise that we actually are changing status on upgrade script - but I still prefer to keep handling the legacy ones [02:44:57] (CR) Ejegg: [C: +2] Fix references to recur status [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574626 (https://phabricator.wikimedia.org/T244326) (owner: Eileen) [02:45:45] (PS1) Eileen: Fix weird failure [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574635 (https://phabricator.wikimedia.org/T227903) [02:45:55] (Abandoned) Eileen: temp debug [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574623 (owner: Eileen) [02:49:38] ejegg: so I'm not clear - did you identify a problem with the new patches - or are we checking & tidying [02:50:14] I think with that fixup we're good as far as statuses go [02:50:54] I'm still puzzled by why I decided to push the next_sched_contribution_date back instead of setting the failure_retry_date in the smashpig extn [02:51:16] I'mma just deploy that fixup and try another few single shot charges [02:51:51] (Merged) jenkins-bot: Fix references to recur status [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574626 (https://phabricator.wikimedia.org/T244326) (owner: Eileen) [02:52:58] (PS1) Ejegg: Merge branch 'master' into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/574637 [02:53:03] (CR) Ejegg: [C: +2] Merge branch 'master' into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/574637 (owner: Ejegg) [02:53:38] ok - I just broke my brain on why my thankyous didn't work from staging - oddly this fixes https://gerrit.wikimedia.org/r/#/c/wikimedia/fundraising/crm/+/574635/ [02:54:09] hang on that's not right [02:56:48] eesh, that is weird. I'mma just try to get those recurring charges back running for tonight and look at that tomorrow [02:56:55] (PS2) Eileen: Fix weird failure [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574635 (https://phabricator.wikimedia.org/T227903) [02:57:19] yeah - it's super weird -just refixed & will test again [02:59:34] !log updated Fundraising CiviCRM from b9d1acdb6d to 88c72e39ca [02:59:38] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [03:02:16] ugh, still don't understand why only failing ones are left to charge now [03:02:42] are we doing one batch of good ones then a batch of retries? [03:03:37] no, we're just grabbing the whole bunch, limited by batch size [03:04:39] does it naturally sort by status for some reason? [03:06:07] not that I can see - what id is it picking up? [03:06:45] I'm just wondering why on earth every single time I try the new recurring job it's an auth failure [03:06:56] and it seems like all the good ones were processed on the first go round [03:07:44] the SmashPigRecurringProcessor just grabs anything in the date range with any of the valid statuses when it picks up stuff to charge [03:08:06] so I'm not sure why it would have done all the good ones first [03:08:15] so I'm seeinng something weird - recur id 73783 (lowest number in select * FROM civicrm_contribution_recur WHERE next_sched_contribution_date BETWEEN '2020-02-24' AND '2020-02-25' [03:08:20] has an end_date [03:08:33] ruh roh [03:09:14] wait, that would be for yesterday's processing [03:09:40] sure, if anything is left with a NEXT date of yesterday, that would be something that was on its last retry yesterday [03:10:01] isn't it 24th over there still? [03:10:05] check with 02-25 to 02-26th [03:10:19] yah, but we're doing these on UTC time [03:10:29] well, all except the last_modified_date column it seems [03:11:12] hmm id 8426 - should have no next date [03:12:30] I think we need to update SET next_sched_contribution_date = NULL WHERE end_date IS NOT NULL [03:14:25] sure, that would be nice [03:15:03] I don't know how it has been set on those - but we could run a one off update for now [03:15:51] are we consistently nulling it out when we set a final failure? [03:16:05] no - looks like we are not [03:20:34] shoot, I'd really like to understand what's up with the failure retries before i just turn the job back on [03:20:44] but it's late here [03:21:00] I think I'm going to leave it off for the night and look a bit more in the morning [03:21:09] I was about to say that [03:27:02] Fundraising Sprint Byzantine Empire Strikes Back, Fundraising Sprint CAPS LOCK CULTS, Fundraising Sprint Dampness, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Stop hacking out civi checks - https://phabricator.wikimedia.org/T244324 (Eileenmcnaughton) [03:28:24] (PS4) Eileen: Merge sendannualttyemail with wmf_thankyou [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574601 (https://phabricator.wikimedia.org/T245580) [03:30:51] well, I'll turn the old job back on. it's acting normally [03:33:11] OOPS, no, it's not [03:33:15] SQL error [03:35:48] eileen looks like it's this: contribution_status_id = IN (4 , 15) [03:35:50] = IN [03:36:00] bugger [03:36:02] ok, leaving that off too [03:37:02] k, I gotta get to bed. See you tomorrow! [03:40:07] (PS1) Eileen: Remove extraneous = [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574639 [03:40:22] (CR) Eileen: "ejegg" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574639 (owner: Eileen) [06:12:15] PROBLEM - check_puppetrun on frdb1001 is CRITICAL: CRITICAL: Puppet has 1 failures. Last run 6 minutes ago with 1 failures. Failed resources (up to 3 shown): Package[mariadb-client] [06:17:17] RECOVERY - check_puppetrun on frdb1001 is OK: OK: Puppet is currently enabled, last run 55 seconds ago with 0 failures [08:33:11] (PS1) AlexPinchuk: Cloning Campaign [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/574667 [10:54:36] (PS2) ItSpiderman: Cloning Campaign [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/574667 (owner: AlexPinchuk) [10:54:56] (CR) jerkins-bot: [V: -1] Cloning Campaign [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/574667 (owner: AlexPinchuk) [10:56:58] (PS3) ItSpiderman: Cloning Campaign [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/574667 (owner: AlexPinchuk) [10:57:03] (PS2) ItSpiderman: Schema changes related to BannerTemplates [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/573520 [10:57:10] (PS18) ItSpiderman: Banner templates [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/572672 [10:57:12] (CR) jerkins-bot: [V: -1] Cloning Campaign [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/574667 (owner: AlexPinchuk) [13:35:17] Wikimedia-Fundraising-Banners: Low contrast on Paypal (USD) logo when selected (blue logo on blue button background) - https://phabricator.wikimedia.org/T246051 (Pcoombe) Open→Resolved a:Pcoombe Fixed with this change, so the paypal-usd logo is treated the same as paypal and amazon logos: https:/... [14:28:08] (CR) Mepps: [C: +2] "Nice catch!" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574639 (owner: Eileen) [14:28:58] (CR) Jgleeson: Add PaymentProviderResponse to help normalize reponses across providers. (1 comment) [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/567137 (https://phabricator.wikimedia.org/T243340) (owner: Jgleeson) [14:34:49] (Merged) jenkins-bot: Remove extraneous = [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574639 (owner: Eileen) [14:49:21] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: contact merge not working for MG - https://phabricator.wikimedia.org/T241276 (mepps) @DKaufman @dstrine @ejegg do we know if this got resolved? [15:29:30] fr-tech ok, lemme just sort out those recur jobs [15:29:44] eileen seems to have fixed the typo [15:32:12] (CR) Ejegg: [C: -1] "Sounds good! CrmLink is definitely a funny place for it - the CRM is not the place we care about those statuses!" [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/567137 (https://phabricator.wikimedia.org/T243340) (owner: Jgleeson) [15:32:44] (PS1) Ejegg: Merge branch 'master' into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/574777 [15:32:58] (CR) Ejegg: [C: +2] Merge branch 'master' into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/574777 (owner: Ejegg) [15:57:07] hi mepps! [15:57:13] hi ejegg! [15:58:22] !log updated Fundraising CiviCRM from 88c72e39ca to bec2d6ad9f [15:58:26] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [15:58:43] ok, so that's the fix for the old job deployed. [15:58:53] trying a --slow-start on it [15:59:39] working [15:59:42] will restart the job [16:00:55] !log restarted legacy Ingenico recurring donation charge job [16:00:58] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [16:01:37] mepps so now to try to understand why the new Ingenico recurring charge job should only have expired cards left to as due for today [16:02:11] ejegg it looks like it ran by itself before you turned it off [16:02:15] hah! And it proves me wrong. There went a good one [16:02:50] cstone the recurring_smashpig_charge job? [16:03:06] it definitely did run at the start of the day UTC once before we were ready to deploy [16:03:10] yeah it has a log for 0021 with a bunch of successes [16:03:40] yeah, then all the batch-of-one runs after we deployed were card declines [16:03:43] usually all of the successes are in the first run when i was failure hunting [16:03:56] interesting, huh? [16:04:00] So why would that be? [16:04:19] If we look at the code to fetch the batch, we're not putting an order by clause into the API call [16:04:30] but I guess maybe there's some implicit ordering under the hood [16:05:01] anyway, that last --slow-start run I just did seems to have come back with a successful charge [16:05:18] so lemme just look at it in the db and I'll feel happy to turn the job back on and get back to the Adyen work [16:07:25] oh huh, it's still using 'Completed' as the contribution_recur status [16:07:50] I expected 'In Progress' [16:10:02] ok, trying to debug that bit locally [16:17:23] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: contact merge not working for MG - https://phabricator.wikimedia.org/T241276 (Ejegg) yeah, @DKaufman sent me a message on google chat later saying it worked. [16:17:37] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: contact merge not working for MG - https://phabricator.wikimedia.org/T241276 (Ejegg) Open→Resolved [16:23:19] Fundraising-Backlog: Incorrect currency conversion amounts on Paypal payment form (USD only countries) - https://phabricator.wikimedia.org/T244946 (jbolorinos-ctr) Hey @Ejegg can someone update those before March 3rd which is when the big bundle campaign starts? Since we'll be using exchange rates most fre... [16:25:34] Fundraising-Backlog, fundraising-tech-ops, Analytics: Install superset on front end server for analytics - https://phabricator.wikimedia.org/T245755 (EYener) It would be good to touch base, @Milimetric - I'll find time on your calendar for later next week. Please feel free to add others to the meeti... [16:28:48] Fundraising Sprint Autocorrect Astrology Ascendant, Fundraising Sprint Byzantine Empire Strikes Back, Fundraising Sprint CAPS LOCK CULTS, Fundraising Sprint Dampness, and 2 others: Server for previewing/usability testing new CentralNotice features - https://phabricator.wikimedia.org/T241070 (Ejegg... [16:33:34] Fundraising-Backlog, fundraising-tech-ops: Upgrade fundraising grafana to v6.6 - https://phabricator.wikimedia.org/T246119 (Dwisehaupt) [16:56:18] Fundraising Sprint Autocorrect Astrology Ascendant, Fundraising Sprint Byzantine Empire Strikes Back, Fundraising Sprint CAPS LOCK CULTS, Fundraising Sprint Dampness, and 2 others: Server for previewing/usability testing new CentralNotice features - https://phabricator.wikimedia.org/T241070 (mepps... [16:58:47] huh, locally i do get the right statuses for the new job [17:08:18] and it's working for the new 'Failing' status [17:10:13] OK, I'm gonna consider this working [17:10:16] restarting the thing [17:10:37] !log restarted new Ingenico recurring donation charge job [17:10:41] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [17:10:50] and now back to looking at the adyen patches! [17:23:27] (CR) AndyRussG: "> Patch Set 14:" [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/567141 (https://phabricator.wikimedia.org/T244536) (owner: Jgleeson) [17:32:31] (CR) Ejegg: [C: -1] "This looks really good. Can we just rename a couple of things?" (6 comments) [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/567141 (https://phabricator.wikimedia.org/T244536) (owner: Jgleeson) [17:33:12] AndyRussG: I think the iDEAL payment provider may not have both create and approve [17:33:50] ejegg: ah hmmm okok... which does it have? [17:34:42] ejegg: jgleeson|baksoon: how does the calling code know which it can and can't call on a given provider? [17:35:17] Also, what is the reason for having interfaces for the provider? Wasn't the effort around standardization to standardize responses? [17:38:44] If we've got interfaces, I guess the calling code can at least use 'instanceof IApprovePayement' to know if it has to make another API call after the createPayment call [17:38:59] just thinking ahead to making the same code handle recurring iDEAL [17:59:11] Are all the implementing classes that we want to attach an interface to called PaymentProvider within the respective directories/namespaces? I see files for Ingenico and Adyen only... also, where does iDEAL code live? [18:00:16] also, pls remind me, wasn't iDEAL a set of Dutch payment methods, not a payment provider? [18:00:28] ejegg: jgleeson|baksoon ^ [18:07:19] AndyRussG: it's a set of Dutch payment methods indeed [18:08:37] But to separate out the code a bit, we have at least one iDEAL specific method for Ingenico in BankPaymentProvider [18:09:35] ejegg: okok so where is that one in SmashPig? [18:09:45] we didn't finish building it out, but that should eventually implement its own createPayment method (and therefore implement ICreatePayment) [18:10:05] AndyRussG: it's in PaymentProviders\Ingenico [18:10:49] it uses the same base API and auth logic as the HostedCheckoutProvider, so they both inherit from Ingenico\PaymentProvider [18:12:19] so far we have only used the SmashPig Ingenico class for card payments, so there's still some flexibility in how those classes could be arranged [18:13:06] ejegg: ok, so in summary, payment provider classes have subclasses within a single provider namespace... [18:13:33] fundraising-tech-ops, Operations, ops-codfw: codfw:fundraising single-cpu misc servers - https://phabricator.wikimedia.org/T244950 (Papaul) [18:13:52] the provider namespaces though (Adyen, Ingenico, Paypal) do correspond precisely to the providers themselves (i.e. the legal entities) ? [18:23:25] Fundraising-Backlog, MediaWiki-extensions-CentralNotice, MinervaNeue (Tracking), Performance-Team (Radar), Readers-Web-Backlog (Kanbanana-2019-20-Q3): Safari crashes on some click handling events for banners that move the centralNotice element outside o... - https://phabricator.wikimedia.org/T242895 [18:25:19] Fundraising-Backlog: Solution for 3DS2.0 name field issue which caused Wikimedia to shut off 3Ds on payment page - https://phabricator.wikimedia.org/T236332 (EMartin) Open→Resolved a:EMartin [18:25:54] (PS16) Ejegg: Add basic thank-you extension [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/566413 (https://phabricator.wikimedia.org/T227903) (owner: Eileen) [18:28:17] (CR) Ejegg: [C: +2] "Nice hotrod shell you've built around our lawnmower engine!" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/566413 (https://phabricator.wikimedia.org/T227903) (owner: Eileen) [18:29:19] (CR) AndyRussG: Update Adyen to break out into separate PaymentProvider and Api classes. Also map responses sent back from Api to the new PaymentProviderRes (1 comment) [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/567141 (https://phabricator.wikimedia.org/T244536) (owner: Jgleeson) [18:31:06] (CR) AndyRussG: Update Adyen to break out into separate PaymentProvider and Api classes. Also map responses sent back from Api to the new PaymentProviderRes (1 comment) [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/567141 (https://phabricator.wikimedia.org/T244536) (owner: Jgleeson) [18:34:54] (Merged) jenkins-bot: Add basic thank-you extension [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/566413 (https://phabricator.wikimedia.org/T227903) (owner: Eileen) [18:35:14] (CR) Ejegg: "Very odd - I don't see the issue locally, and we're using the same find() || fetch() pattern for the email and mailing records. Should we " [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574635 (https://phabricator.wikimedia.org/T227903) (owner: Eileen) [18:36:33] AndyRussG: yes, sorry, the provider namespaces correspond to the providers [18:37:26] ejegg|food: okok thanks... provecho... :) [18:37:35] So we've got a PaymentProviderFactory::getProviderForMethod object that should get the right subclass for a given payment method [18:38:12] hmmm ok [18:39:05] So like a wee bit of DI [19:00:18] fr-tech any more specifics on https://phabricator.wikimedia.org/T242278 ? Where is the code that needs to be standardized, for example? [19:04:36] hmm [19:05:18] if I remember rightly this is a small change (updating an ingenico-specific id to be the new generic id name) [19:05:24] s/this/that/ [19:05:34] but yeah the context isn't clear [19:05:57] AndyRussG: the code that needs standardising is the stuff I'm looking at [19:06:08] specifically the responses sent back from adyen and ingenico [19:07:16] lemme get some code to explain [19:09:22] AndyRussG: currently for calls to the ingenico PaymentProvider::createPayment() call we send back what ingenico return us verbatim, https://github.com/wikimedia/wikimedia-fundraising-SmashPig/blob/74dac310d586b789d2c60dd563cd25a08a6a9356/PaymentProviders/Ingenico/PaymentProvider.php#L77 [19:09:35] Wikimedia-Fundraising-Banners: Error messages not appearing on Mobile Large form in Hebrew - https://phabricator.wikimedia.org/T242396 (jbolorinos-ctr) p:Triage→Medium Updating to Medium priority because this will affect one country in the upcoming Big Bundle campaign [19:10:47] and for adyen we send back just the pspReference https://github.com/wikimedia/wikimedia-fundraising-SmashPig/blob/a7f5ada467f978cc1dcc67ca6a0f335d1ccbf83b/PaymentProviders/Adyen/AdyenPaymentsAPI.php#L82 [19:12:20] the area of code in your ticket, the civi smashpig extension, is currently only working with ingenico and as a result works with the ingenico response sent back from smashpig. That code then pulls the ingenico transaction id from the result. [19:12:45] lemme just find where that civi extenion speaks to smashpig (ingenico) [19:16:00] so here within the civi smashpig extension after it calls createPayment() it looks for an id to use knowing the specific location of the id within the ingenico api result (sent back via smashpig). It's coupled to the ingenico response as a result so makes it tricky to swap out the backend to adyen for example for other recurring payments. [19:16:02] https://github.com/wikimedia/wikimedia-fundraising-crm/blob/9aa4f641a47c42baa421aecc95c473330072033d/sites/default/civicrm/extensions/org.wikimedia.smashpig/CRM/Core/Payment/SmashPig.php#L182 [19:17:30] so the work I'm doing is trying to align the responses across provider into a single Response object which smashpig will send back regardless of the provider. Your code can then just call $createPaymentResponse->getTrxnId() without caring what the backend payment provider is [19:24:50] fr-tech, sticking with the spanish guitar theme... today's album recommendation is Jesse Cook - Free Fall [19:27:12] Fundraising Sprint CAPS LOCK CULTS, Fundraising Sprint Dampness, Fundraising-Backlog, FR-Adyen, Recurring-Donations: Update civi SmashPig extension to be able to charge Adyen recurring - https://phabricator.wikimedia.org/T242278 (jgleeson) Pasted from IRC: ` 19:00 fr-tech any mo... [19:27:14] AndyRussG: I've added the above overview to the phab task to make life easier working from the ticket. [19:39:31] Fundraising Sprint Autocorrect Astrology Ascendant, Fundraising Sprint Byzantine Empire Strikes Back, Fundraising Sprint CAPS LOCK CULTS, Fundraising Sprint Dampness, and 2 others: Server for previewing/usability testing new CentralNotice features - https://phabricator.wikimedia.org/T241070 (Ejegg... [19:49:13] hmmmmz [19:49:33] anyone know how to add a new commit between two existing commits? [19:49:36] fr-tech^ [19:49:45] jgleeson yeah! [19:49:48] !!! [19:50:06] * jgleeson waits in suspense [19:50:26] so if it's a small fix and doesn't affect the later of the 2 existing [19:50:37] ah it might [19:50:38] I would just make the commit and then use rebase -i master [19:50:51] oooo yeah reorder there [19:50:55] ok, if it might, then I'd create a new branch starting from the first of the existing ones [19:51:06] add the new patch [19:51:16] and then try cherry picking the later of the 2 existing over [19:51:18] rebase is awesome, and deadly. [19:51:41] yeah, it's functionaly equivalent to the other way of doing things [19:52:00] I just realised I could also probably add the new patch, reorder the the commits and just resolve the conflicts [19:52:07] but messing with the branch that has the solid existing version might feel a little scarier [19:52:10] yeah, totally [19:52:12] I wish I'd asked before I done the work [19:53:02] I'm making the updates to the FinalStatus thingy and it feels like it warrants it's own commit [19:53:16] wedged right in between the two existing [19:53:26] (PS3) Ejegg: Fix weird failure [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574635 (https://phabricator.wikimedia.org/T227903) (owner: Eileen) [19:55:13] (CR) Ejegg: [C: +2] "Well for whatever reason, it looks like this works! Heck of a sleuthing job to figure that out." [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574635 (https://phabricator.wikimedia.org/T227903) (owner: Eileen) [19:57:37] (CR) Eileen: "ejegg to be honest this class scares me & I have doubts about touching more than I have to -" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574635 (https://phabricator.wikimedia.org/T227903) (owner: Eileen) [19:58:15] ejegg: where did you get to with those recurrings? [19:59:57] I turned 'em back on [20:00:26] did you figure out the issue you were seeing? [20:00:43] Though the one successful --slow-start I was able to do with the new job ended up with a ContributionRecur status of 'Completed' [20:00:49] rather than 'In Progress' [20:00:54] which is confusing [20:02:13] jgleeson: thanks!!! (sorry, was in a meeting) [20:02:23] np! [20:02:24] I'll check it out now... :) [20:02:31] (Merged) jenkins-bot: Fix weird failure [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574635 (https://phabricator.wikimedia.org/T227903) (owner: Eileen) [20:02:42] hmm - ok - well I'll try to see what is happening with that - [20:13:24] eileen that one was for cid 6288555 [20:14:11] ejegg: cool - I'll look - I've just pushed into process control a new job to delete deleted contacts [20:14:21] nice [20:14:31] i'll take a quick peep [20:15:21] every 2 minutes, huh? [20:15:35] OK, let's see how it handles on the autobahn [20:16:58] I think it won't be a prob since our issue is contact level contention - if we do hit problems then it will be on the acl_contact_cache table I think [20:17:04] but let's see [20:17:13] lol autobahn [20:17:23] ok - pushing it out now.... [20:17:24] * jgleeson tips hat [20:18:15] !log process-control config revision is e17d104c73 [20:18:19] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [20:23:08] (PS13) Ejegg: Get rid of old review tags. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/573055 (https://phabricator.wikimedia.org/T245577) (owner: Eileen) [20:23:39] Fundraising Sprint CAPS LOCK CULTS, Fundraising Sprint Dampness, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, and 2 others: Delete contacts deleted more than x months / years ago - https://phabricator.wikimedia.org/T245087 (Eileenmcnaughton) OK - I just started it - here are before stats... [20:23:43] (CR) Ejegg: [C: +2] "Seems to work. We'll want to make sure to run this 'updb' under screen or tmux. Also probably best to run at a very low traffic time." [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/573055 (https://phabricator.wikimedia.org/T245577) (owner: Eileen) [20:23:56] (PS3) Ejegg: Remove defunct contribution recur statuses. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574611 (owner: Eileen) [20:24:07] (CR) Ejegg: [C: +2] Remove defunct contribution recur statuses. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574611 (owner: Eileen) [20:28:51] eileen I'm looking at the extended reports update - where do I find the 'Benevity report' again? [20:29:14] oops, meeting time [20:29:53] (Merged) jenkins-bot: Get rid of old review tags. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/573055 (https://phabricator.wikimedia.org/T245577) (owner: Eileen) [20:30:30] (Merged) jenkins-bot: Remove defunct contribution recur statuses. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574611 (owner: Eileen) [20:31:05] (PS5) Eileen: Merge sendannualttyemail with wmf_thankyou [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574601 (https://phabricator.wikimedia.org/T245580) [20:32:38] !log process-control config revision is e17d104c73 slow down delete deleted contacts [20:32:42] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [20:42:02] !log process-control config revision is c0ef31e2fd [20:42:05] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [20:47:52] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, FR-WMF-Audit: Tag contributions to indicate that they've been confirmed by audit or IPN files. - https://phabricator.wikimedia.org/T246158 (Ejegg) [20:48:36] Fundraising Sprint CAPS LOCK CULTS, Fundraising Sprint Dampness, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, and 2 others: Decide what to do about the increasing civi crm db size - https://phabricator.wikimedia.org/T243870 (DStrine) Open→Resolved [20:48:38] Fundraising-Backlog, fundraising-tech-ops, Epic: Epic: civi crm db approaching data partition capacity - https://phabricator.wikimedia.org/T241083 (DStrine) [20:52:13] Fundraising Sprint CAPS LOCK CULTS, Fundraising Sprint Dampness, Fundraising-Backlog, FR-Adyen, Recurring-Donations: Update civi SmashPig extension to be able to charge Adyen recurring - https://phabricator.wikimedia.org/T242278 (AndyRussG) a:AndyRussG [20:53:13] Fundraising-Backlog, MediaWiki-extensions-CentralNotice: investigate: Find alternative to Special:HideBanners cookies to mitigate the loss of 3rd-party cookie support - https://phabricator.wikimedia.org/T244699 (DStrine) [20:58:48] (CR) Eileen: [C: +2] "ejegg this seems to work fine - but note that trying it on staging and I think you are going to need to 'ease up' to the default number of" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574033 (https://phabricator.wikimedia.org/T245844) (owner: Ejegg) [21:05:13] (Merged) jenkins-bot: Add drush command to trim queue2civicrm_log [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/574033 (https://phabricator.wikimedia.org/T245844) (owner: Ejegg) [21:11:43] Fundraising-Backlog, Analytics, MediaWiki-extensions-CentralNotice, Patch-For-Review: Refining is failing to refine centranoticeimpression events - https://phabricator.wikimedia.org/T244771 (Nuria) @ottomata: can we alter table to latest schema and re-refine the last 90 days of data? [21:12:33] ejegg: check civicrm/admin/report/template/list?reset=1 - search for Extended Report - Contributions Detail with extra fields & all those extended reports with 'existing reports' next to them... [21:12:52] thanks! [21:13:11] Fundraising-Backlog, Analytics, WMDE-Analytics-Engineering, WMDE-FUN-Team, WMDE-Fundraising-Tech: Find a better way for WMDE to get impression counts for their banners - https://phabricator.wikimedia.org/T243092 (Nuria) >Do I understand correctly, that event.centralnoticeimpression does not c... [21:15:28] Fundraising-Backlog, Analytics, WMDE-Analytics-Engineering, WMDE-FUN-Team, WMDE-Fundraising-Tech: Find a better way for WMDE to get impression counts for their banners - https://phabricator.wikimedia.org/T243092 (Nuria) Now, I think if you rely on that data source strongly you need to communi... [21:17:47] (PS1) Mepps: Make subscription id optional in paypal refund script [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/574864 [21:18:13] Fundraising-Backlog, Analytics, MediaWiki-extensions-CentralNotice, Patch-For-Review: Refining is failing to refine centranoticeimpression events - https://phabricator.wikimedia.org/T244771 (Nuria) Selecting from table now I get: ` hive (event)> select * from CentralNoticeImpression where year=2... [21:18:58] (PS2) Mepps: Make subscription id optional in paypal refund script [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/574864 [21:20:44] (PS3) Mepps: Make subscription id optional in paypal refund script [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/574864 [21:21:21] ejegg jgleeson ^^ for making subscription id optional [21:22:00] thanks mepps, will take a look in a sec! [21:22:39] (CR) jerkins-bot: [V: -1] Make subscription id optional in paypal refund script [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/574864 (owner: Mepps) [21:24:01] (PS4) Mepps: Make subscription id optional in paypal refund script [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/574864 [21:25:44] (CR) jerkins-bot: [V: -1] Make subscription id optional in paypal refund script [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/574864 (owner: Mepps) [21:26:57] (PS5) Mepps: Make subscription id optional in paypal refund script [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/574864 [21:29:13] (CR) jerkins-bot: [V: -1] Make subscription id optional in paypal refund script [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/574864 (owner: Mepps) [21:29:32] (PS2) Ejegg: Update extended reports [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/571658 (https://phabricator.wikimedia.org/T244194) (owner: Eileen) [21:29:46] Fundraising Sprint Autocorrect Astrology Ascendant, Fundraising Sprint Byzantine Empire Strikes Back, Fundraising Sprint CAPS LOCK CULTS, Fundraising Sprint Dampness, and 2 others: Server for previewing/usability testing new CentralNotice features - https://phabricator.wikimedia.org/T241070 (mepps... [21:30:52] (PS6) Mepps: Make subscription id optional in paypal refund script [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/574864 [21:33:50] (CR) Ejegg: [C: +2] "looks good! The existing reports all seem to be working." [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/571658 (https://phabricator.wikimedia.org/T244194) (owner: Eileen) [21:36:22] (CR) Ejegg: "cool! Let's go a little bit further and not require padding with ", 0"" (2 comments) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/574864 (owner: Mepps) [21:38:09] AndyRussG: shoot, we should have thought of this earlier, but do you think we should ask hallo welt to rebase their banner template patch over the geotargeting patch? [21:39:01] mepps: oh hey, did the geotargeting stuff get pulled out of sprint? [21:39:11] I'm worried about that going stale and being hard to rebase again [21:39:18] ejegg i'm not sure it actually got put in--i wasn't there for sprint planning [21:39:26] ah, neither was I [21:39:44] I really feel like we need to merge that before the banner templates [21:40:49] (Merged) jenkins-bot: Update extended reports [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/571658 (https://phabricator.wikimedia.org/T244194) (owner: Eileen) [21:43:50] (PS7) Mepps: Make subscription id optional in paypal refund script [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/574864 [21:44:22] ejegg i put time on my calendar to look at these CN tasks on thursday, want to plan to chat with me then? [21:44:27] thursday morning that is [21:44:41] if i don't schedule it, it doesn't happen... [21:45:36] (CR) jerkins-bot: [V: -1] Make subscription id optional in paypal refund script [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/574864 (owner: Mepps) [21:48:55] (PS8) Mepps: Make subscription id optional in paypal refund script [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/574864 [21:53:18] ejegg: mepps: how much overlap is there with banner template vs. geotargeting code? [21:54:02] hey ejegg, what is the length requirement for paypal express subscription ids [21:54:33] good question AndyRussG i would guess the editing UI would be impacted by both.. [21:55:58] is it the plan-id here ejegg: https://developer.paypal.com/docs/subscriptions/integrate/ [21:56:06] (CR) Ejegg: [C: -1] "Looking better - just needs a couple fixes" (3 comments) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/574864 (owner: Mepps) [21:58:04] AndyRussG: oh hey, I was able to cherry pick the banner template over the other one without any merge conflicts! [21:58:18] so... maybe not such a big issue [21:58:28] I figured at least qqq.json and en.json [21:58:41] (PS9) Mepps: Make subscription id optional in paypal refund script [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/574864 [21:58:54] ejegg never mind about my earlie rquestion [21:59:07] i misunderstood a comment--my brain is a little broken right now [21:59:10] so with that, i'm headed out [22:01:07] (PS12) Jgleeson: Add PaymentProviderResponse to help normalize reponses across providers. [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/567137 (https://phabricator.wikimedia.org/T243340) [22:01:14] (PS15) Jgleeson: Break up Adyen into separate PaymentProvider and Api classes. [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/567141 (https://phabricator.wikimedia.org/T244536) [22:01:16] (PS1) Jgleeson: Move FinalStatus to Core [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/574874 (https://phabricator.wikimedia.org/T244536) [22:01:22] (CR) Ejegg: "Just one tweak to avoid potential undefinedness" (1 comment) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/574864 (owner: Mepps) [22:01:29] (CR) jerkins-bot: [V: -1] Break up Adyen into separate PaymentProvider and Api classes. [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/567141 (https://phabricator.wikimedia.org/T244536) (owner: Jgleeson) [22:03:05] hmmm looks like I missed one! [22:04:18] ooooo looks like I hit git review before completing the rebase [22:04:46] d'oh! [22:04:49] although that still wouldn't have fixed those tests failing [22:22:22] PROBLEM - check_puppetrun on frdb1002 is CRITICAL: CRITICAL: Puppet has 1 failures. Last run 3 minutes ago with 1 failures. Failed resources (up to 3 shown): Package[mariadb-backup-10.1] [22:25:18] PROBLEM - check_puppetrun on frdev1001 is CRITICAL: CRITICAL: Puppet has 1 failures. Last run 9 minutes ago with 1 failures. Failed resources (up to 3 shown): Package[mariadb-backup-10.1] [22:27:22] PROBLEM - check_puppetrun on frdb1002 is CRITICAL: CRITICAL: Puppet has 1 failures. Last run 3 minutes ago with 1 failures. Failed resources (up to 3 shown): Package[mariadb-backup-10.1] [22:28:04] what is up with puppet? [22:29:22] jgleeson: FYI - https://gerrit.wikimedia.org/r/#/c/wikimedia/fundraising/crm/+/574601/ [22:30:18] PROBLEM - check_puppetrun on frdev1001 is CRITICAL: CRITICAL: Puppet has 1 failures. Last run 14 minutes ago with 1 failures. Failed resources (up to 3 shown): Package[mariadb-backup-10.1] [22:30:33] ejegg: oh hey great to hear! :) thanks for trying that! [22:32:12] PROBLEM - check_mysql on frdb1003 is CRITICAL: Slave IO: Connecting Slave SQL: Yes Seconds Behind Master: (null) [22:32:22] RECOVERY - check_puppetrun on frdb1002 is OK: OK: Puppet is currently enabled, last run 59 seconds ago with 0 failures [22:34:28] fr-tech any idea why I have these two untracked files in my civicrm repo on Vagrant? sites/default/civicrm-install.php sites/default/drupal-install.sh [22:35:18] RECOVERY - check_puppetrun on frdev1001 is OK: OK: Puppet is currently enabled, last run 1 minute ago with 0 failures [22:35:27] hmm, are they maybe created from templates by the setup script? [22:35:57] hmmm no idea [22:36:08] I guess I could just let them be... [22:37:12] PROBLEM - check_mysql on frdb1003 is CRITICAL: Slave IO: Connecting Slave SQL: Yes Seconds Behind Master: (null) [22:42:12] PROBLEM - check_mysql on frdb1003 is CRITICAL: Slave IO: Connecting Slave SQL: Yes Seconds Behind Master: (null) [22:42:13] jgleeson: want to finish that rebase and push the result up? [22:42:21] was kinda waiting for that before diving into the test bits [22:46:03] Fundraising-Backlog, MediaWiki-extensions-CentralNotice, Epic: [Epic] Banner history improvements - https://phabricator.wikimedia.org/T192564 (Nuria) [22:47:12] PROBLEM - check_mysql on frdb1003 is CRITICAL: Slave IO: Connecting Slave SQL: Yes Seconds Behind Master: (null) [22:52:12] PROBLEM - check_mysql on frdb1003 is CRITICAL: Slave IO: Connecting Slave SQL: Yes Seconds Behind Master: (null) [22:57:12] PROBLEM - check_mysql on frdb1003 is CRITICAL: Slave IO: Connecting Slave SQL: Yes Seconds Behind Master: (null) [23:00:27] ACKNOWLEDGEMENT - check_mysql on frdb1003 is CRITICAL: Slave IO: Connecting Slave SQL: Yes Seconds Behind Master: (null) Dwisehaupt looking into ssl connection issues. [23:07:12] RECOVERY - check_mysql on frdb1003 is OK: Uptime: 41 Threads: 2 Questions: 118880 Slow queries: 0 Opens: 198 Flush tables: 1 Open tables: 192 Queries per second avg: 2899.512 Slave IO: Yes Slave SQL: Yes Seconds Behind Master: 0 [23:13:59] ejegg: sorry I planned to push it up sooner but I had to tuck oscar in lol [23:14:55] just gonna double check I've replied to everything and made the updates discussed [23:16:24] oh great! [23:16:33] we're just looking at your code in tech talk [23:16:35] jgleeson: hey I know it's late, but if you want to join tech-talk [23:16:39] no worries if not eh! [23:16:47] to discuss what AndyRussG will need to do up in the CRM extension [23:17:08] sure I can listen in and type but won't be able to talk unfortunately [23:32:26] Fundraising-Backlog, Fr-CiviCRM-dedupe-FY2017/18: Civi deduper permission levels for DS - https://phabricator.wikimedia.org/T245843 (MBeat33) [23:37:02] (PS13) Jgleeson: Add PaymentProviderResponse to help normalize reponses across providers. [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/567137 (https://phabricator.wikimedia.org/T243340) [23:37:04] (PS16) Jgleeson: Break up Adyen into separate PaymentProvider and Api classes. [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/567141 (https://phabricator.wikimedia.org/T244536) [23:38:10] (CR) Jgleeson: Add PaymentProviderResponse to help normalize reponses across providers. (1 comment) [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/567137 (https://phabricator.wikimedia.org/T243340) (owner: Jgleeson) [23:40:25] (CR) Jgleeson: Break up Adyen into separate PaymentProvider and Api classes. (4 comments) [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/567141 (https://phabricator.wikimedia.org/T244536) (owner: Jgleeson) [23:42:42] (PS5) Art-Baltai: Replace usage of deprecated Page in favor of WikiPage/Article [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/573604 (https://phabricator.wikimedia.org/T239975) [23:45:00] (PS14) Jgleeson: Add PaymentProviderResponse to help normalize repsonses across providers. [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/567137 (https://phabricator.wikimedia.org/T243340) [23:45:02] (PS17) Jgleeson: Break up Adyen into separate PaymentProvider and Api classes. [wikimedia/fundraising/SmashPig] - https://gerrit.wikimedia.org/r/567141 (https://phabricator.wikimedia.org/T244536)