[05:56:43] (03CR) 10AndyRussG: [C: 03+2] "looks great, thanks for this!!!! :)" [wikimedia/fundraising/SmashPig] - 10https://gerrit.wikimedia.org/r/894131 (https://phabricator.wikimedia.org/T324299) (owner: 10Wfan) [05:57:25] (03Merged) 10jenkins-bot: Add unit test for upi recurring [wikimedia/fundraising/SmashPig] - 10https://gerrit.wikimedia.org/r/894131 (https://phabricator.wikimedia.org/T324299) (owner: 10Wfan) [07:07:01] (03CR) 10CI reject: [V: 04-1] Localisation updates from https://translatewiki.net. [extensions/DonationInterface] (REL1_35) - 10https://gerrit.wikimedia.org/r/897500 (owner: 10L10n-bot) [09:43:50] 10Fundraising-Backlog, 10MediaWiki-extensions-CentralNotice: CentralNotice banners being shown too many times - https://phabricator.wikimedia.org/T331671 (10Ciell) p:05Triageβ†’03High The number of complaints are growing throughout different projects, so bumping this up to high priority and also pinging @Pco... [09:54:44] 10Fundraising-Backlog: Add UPI donations queue consumer - https://phabricator.wikimedia.org/T331851 (10jgleeson) [09:54:55] 10Fundraising Sprint Everything I Merge I Merge For You, 10Fundraising-Backlog, 10FR-dlocal: Add UPI donations queue consumer - https://phabricator.wikimedia.org/T331851 (10jgleeson) [09:57:36] 10Fundraising Sprint Everything I Merge I Merge For You, 10Fundraising-Backlog, 10FR-Smashpig, 10FR-dlocal, 10Patch-For-Review: Handle recurring IPNs for Dlocal - https://phabricator.wikimedia.org/T330724 (10jgleeson) This is in pending deployment, but the queue consumer patch using this ticket's ID is s... [09:58:21] (03PS6) 10Jgleeson: UPI donations queue consumer [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/895897 (https://phabricator.wikimedia.org/T331851) (owner: 10Ejegg) [09:58:53] 10Fundraising Sprint Everything I Merge I Merge For You, 10Fundraising-Backlog, 10FR-dlocal, 10Patch-For-Review: Add UPI donations queue consumer - https://phabricator.wikimedia.org/T331851 (10jgleeson) a:03Ejegg [10:12:23] (03CR) 10CI reject: [V: 04-1] UPI donations queue consumer [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/895897 (https://phabricator.wikimedia.org/T331851) (owner: 10Ejegg) [11:32:07] 10Fundraising Sprint Everything I Merge I Merge For You, 10Fundraising-Backlog, 10FR-dlocal: Create UML diagrams for dLocal India Recurring - https://phabricator.wikimedia.org/T331555 (10jgleeson) a:03jgleeson [11:34:06] 10Fundraising Sprint Everything I Merge I Merge For You, 10Fundraising-Backlog, 10FR-dlocal: Create UML diagrams for dLocal India Recurring - https://phabricator.wikimedia.org/T331555 (10jgleeson) Pulling this into sprint as we could do with the UPI recurring sequence diagram now to help explain the complica... [12:08:06] (03CR) 10Jgleeson: [C: 04-1] "Question about the 'next_sched_contribution_date' updates across this queue consumer and the recurring charge extension. There's an overla" [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/895897 (https://phabricator.wikimedia.org/T331851) (owner: 10Ejegg) [14:38:40] (03PS1) 10AndyRussG: Move PlaceholderFiscalNumber to gateway_common [extensions/DonationInterface] - 10https://gerrit.wikimedia.org/r/897901 (https://phabricator.wikimedia.org/T324297) [14:39:53] (03CR) 10Jgleeson: [C: 04-1] "More thoughts which contradict earlier thoughts :(" [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/895897 (https://phabricator.wikimedia.org/T331851) (owner: 10Ejegg) [14:47:10] fr-tech, we've got a lot of patches floating around which are in-review or merged that make up our dlocal India recurring solution. When reviewing the queue consumer code today it made me realise I'm still unsure about the best place to manage our scheduling so I figure it might make sense to put it on a diagram using the earlier dlocal diagrams as a template, [14:47:12] https://gitlab.wikimedia.org/repos/fundraising-tech/fr-tech-diagrams/-/commit/11bd07e6c26fc191506ced529423b045433e4882, and then we can all agree on the expected flow. I don't think we're far away but at things sit there's a slight overlap between the smashpig code an the civi code that needs ironing out and I feel like a shared picture could help us with that. Maybe we should jump on a quick [14:47:14] short team call to go through it when folks are around [14:47:16] back soon [14:57:35] 10Fundraising Sprint Everything I Merge I Merge For You, 10Fundraising-Backlog, 10Wikimedia-Fundraising-CiviCRM: Add fiscal_number to Civi Smashpig extension parameter mapping for Dlocal - https://phabricator.wikimedia.org/T331288 (10Ejegg) Moving this back to 'doing' because we have a new place to store it:... [15:04:10] sounds good to me jgleeson - it would certainly simplify things if we could avoid the extra contribution_recur_status value and do less processing in the new queue consumer [15:22:40] (03PS1) 10Ejegg: Move fiscal_number to legal_identifer [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/897911 (https://phabricator.wikimedia.org/T331288) [15:35:35] (03CR) 10CI reject: [V: 04-1] Move fiscal_number to legal_identifer [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/897911 (https://phabricator.wikimedia.org/T331288) (owner: 10Ejegg) [15:47:25] (03PS2) 10Ejegg: Move fiscal_number to legal_identifer [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/897911 (https://phabricator.wikimedia.org/T331288) [15:57:20] hmm, there are a LOT of old CentralNotice tickets in phab. I bet we can close at least 5 [15:57:51] or we could let them continue to ferment [15:57:54] T108849 is pretty much done as far as I can tell [15:57:55] T108849: Move CentralNotice stuff out of cookies - https://phabricator.wikimedia.org/T108849 [15:58:17] ejegg: we still use cookies for banner close tracking [15:58:24] ahh ok [15:59:16] in all seriousness if it's OK I'd like to ignore that backlog today and tomorrow, except for anything that is actually urgent to reply on [16:01:53] (03CR) 10CI reject: [V: 04-1] Move fiscal_number to legal_identifer [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/897911 (https://phabricator.wikimedia.org/T331288) (owner: 10Ejegg) [16:03:23] 10Fundraising-Backlog, 10MediaWiki-extensions-CentralNotice: CentralNotice admin UI should display warnings on potential banner overload - https://phabricator.wikimedia.org/T331890 (10Ejegg) [16:03:48] awesome ejegg. I'm gonna quickly finish the prep for some bolognese and then I'll push up a starting pointing and we can talk through it if that works [16:03:59] yep yep AndyRussG, i'm switching back to dlocal after writing that one ticket [16:17:04] (03PS3) 10Ejegg: Move fiscal_number to legal_identifer [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/897911 (https://phabricator.wikimedia.org/T331288) [16:27:43] starting point* [16:32:23] (03CR) 10CI reject: [V: 04-1] Move fiscal_number to legal_identifer [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/897911 (https://phabricator.wikimedia.org/T331288) (owner: 10Ejegg) [16:33:48] fr-tech if anyone fancies helping out with review I'd really like to get feedback on this dlocal patch https://gerrit.wikimedia.org/r/c/wikimedia/fundraising/crm/+/895862 [16:41:21] fr-tech is anyone having issues with the dlocal sandbox API? [16:41:23] local::10161:10161.1 | cURL transaction to https://sandbox.dlocal.com/payments failed 3 times! Please see previous warning-level logs for details [16:41:50] jgleeson: so my feedback would depend on the flow we end up with - I'd like to hear from the rest of fr-tech whether they think we can do this the simpler way (no extra status, only shift date on the initial setup) [16:42:13] it seems fine to me at first glance [16:43:47] I guess I wasn't proposing we do away entirely with the new status in https://phabricator.wikimedia.org/T324301#8683229 but more suggesting we use it temporarily until we decide how to add custom statuses [16:46:31] jgleeson: ah ok, so 'In Progress' is the default status for things that are to be picked up by the processor [16:46:36] I think there's a lot of power in manipulating the next_sched_contribution_date, but I need to look at the code more [16:46:59] Also hello fr-tech having a late start today [16:47:09] and as long as we keep using that, we need to push next_sched_contribution_date as soon as we prenotify, so we don't pick it up again on the next run [16:47:15] hi cstone! [16:48:25] so another benefit to treating next_sched_contribution_date as the prenotification date (and not the expected date of the actual contribution) is that it will probably be less variable cause it's all under our control [16:48:38] I don't know if the prenotification -> charge time is always fixed [16:48:54] What if we don't update the next sched on successful upi is there still an easy way to pick them up for prenotify? Like update it when we get the go ahead from the prenotify [16:49:47] cstone so jgleeson [16:49:51] 's current patch [16:50:05] updates the date as soon as we send the prenotification [16:50:13] which is totally fine in the happy case [16:50:21] Yeah [16:50:41] and the only weirdness there is that we have to set the retry_date to something early than that (but still later than now) when there's a failure [16:51:09] seems like that might be preferable to maintaining the extra status [16:52:16] if that value list is locked in the UI, maybe it's because changing it causes some other unexpected consequences [16:52:47] So then I'd be able to simplify the new queue consumer to just handle initial setup for now [16:53:09] and then add on failure notifications after the IPN listener can handle them [16:54:05] (aside: grr, those smashpig test failures are super opaque! I think it's all because of bad params being passed to the mock but those aren't what show up in the test output because of exception handling) [16:54:52] Hey fr-tech. Is UPI recurring looking likely to be ready by tomorrow? [16:54:55] ejegg|brb: I fixed some of the failures with the headers removal but the last one was contact_id I think [16:55:10] *internal test ready, that is. [16:56:01] XenoRyet: it's close but we've got a few last minute details to figure out [16:56:32] relating to the India recurring solution [16:56:32] They could start a recurring though right? It's the second charge logic that's the complicated part [16:57:05] Also sorry if I'm responding to past messages something is up with my internet [16:57:22] cstone: tangential but I'm also getting rejections from the dlocal sandbox. I just replied to your email [16:58:51] Cool, thanks for the info. [17:01:10] cstone I think we need to get the fiscal_number into the right field at least [17:02:10] let me focus on that patch for now [17:03:30] jgleeson the only thing I think we need to add to your patch right now is the failure handling if that first prenotification returns a failure immediately - shouldn't that mark the recur as failed on the second try rather than waiting for 3 failures? [17:05:10] ejegg: I don't think there's a hard limit with the prenotification attempts. I think the hard limit of 2 is with the payment https://docs.dlocal.com/docs/india-recurring-payments#retry-payment-flow [17:06:28] so if the prenotification fails for some reason, I think we'd be ok to retry it 3 times [17:06:55] although that might break out scheduling if we don't do that immediately [17:07:10] jgleeson: as the subscription still been block, the recharge api works, still able to test with old wallet token [17:07:22] jgleeson: ok, let's think about this - if we get a failure IPN and mark the failure_count as 1 and set a retry_date [17:07:44] So they never fixed the issue from Friday? [17:07:49] then we pick it up for the retry and the prenotification fails once, do we mark that failed immediately? [17:07:52] yep [17:07:53] I didn't have an tokens saved [17:07:58] cstone: aad328f2-61e8-4a89-a015-feef4d52ff2c here you go [17:08:34] * ejegg reads email to see what the issue from Friday was [17:08:51] Every test payment was being rejected [17:09:13] oh boo [17:09:31] yep, just saw jgleeson's follow-up [17:11:45] ejegg: my thinking is that if the prenotification call fails 3 times as i think it will be allowed to here https://github.com/wikimedia/wikimedia-fundraising-crm/blob/master/drupal/sites/default/civicrm/extensions/org.wikimedia.smashpig/CRM/Core/Payment/SmashPigRecurringProcessor.php#L511 [17:12:24] we either close the recurring charge down as we're gonna break our scheduling rules if we try to requeue it [17:12:37] or we come up with a fancy way to retry it on the same day [17:13:27] hypothetically this could happen when dlocal has comms issues with UPI [17:13:42] jgleeson: so that's a weird loop - the only errors it will actually retry in realtime are 'DUPLICATE_MERCHANT_ID' [17:13:56] anything else will return false from $this->handleException [17:14:04] and it'll just increment the failure cound [17:14:04] oh right [17:14:06] *count [17:14:53] so would we still get an IPN for a failed payment? Or just the realtime failure status? [17:15:04] I feel like we're only going to learn some of these answers in production [17:15:23] definitely should deploy this with maximum logging [17:15:30] wfan: thanks. I was trying to walk through the end-to-end flow so I could double check it against a diagram [17:15:34] Yeah I really wanted to try and get some ipns as soon as possible [17:16:02] ejegg: I need a picture ha [17:16:10] this is pretty complicated stuff [17:16:13] yeah, the ipn part is been blocked since we get reject directly πŸ˜… [17:16:28] it's close [17:16:36] and we can pull it apart on a call [17:16:42] gimme 30 mins [17:16:42] jgleeson: yep. I'm just trying to puzzle out whether we need to handle the retry=1 limit in the SmashPig ext, or if it's OK to just handle it in response to IPNs [17:17:43] cstone: I have some IPN requests you could use with postman [17:17:47] if you have that setup [17:18:28] Are you getting responses from them? I just wanted to see the whole flow work [17:18:28] (03PS7) 10Ejegg: Remove watchdog, legacy function calls in normalize message [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/895870 (https://phabricator.wikimedia.org/T288585) (owner: 10Eileen) [17:18:52] ah no. I meant in case you wanted to simulate one coming in locally [17:19:40] (03CR) 10Ejegg: [C: 03+1] "Looks pretty good! I had to flip back and forth a bit to understand the new Cash default in the ChecksFile, but I think that's OK. Could m" [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/895870 (https://phabricator.wikimedia.org/T288585) (owner: 10Eileen) [17:20:01] 10Fundraising-Backlog: Enabling Paypal in local currency (CNY) for China - https://phabricator.wikimedia.org/T96062 (10XenoRyet) 05Openβ†’03Declined [17:20:04] 10Wikimedia-Fundraising-Campaigns: Fundraise in China & Hong Kong - https://phabricator.wikimedia.org/T94286 (10XenoRyet) [17:26:12] PROBLEM - check_mysql on frdb1006 is CRITICAL: Slave IO: Yes Slave SQL: No Seconds Behind Master: (null) https://icinga.wikimedia.org/cgi-bin/icinga/extinfo.cgi?type=2&host=frdb1006&service=check_mysql [17:31:12] PROBLEM - check_mysql on frdb1006 is CRITICAL: Slave IO: Yes Slave SQL: No Seconds Behind Master: (null) https://icinga.wikimedia.org/cgi-bin/icinga/extinfo.cgi?type=2&host=frdb1006&service=check_mysql [17:35:51] (03PS4) 10Ejegg: Move fiscal_number to legal_identifer [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/897911 (https://phabricator.wikimedia.org/T331288) [17:36:05] ok, that's finally passing locally ^^^ [17:36:12] PROBLEM - check_mysql on frdb1006 is CRITICAL: Slave IO: Yes Slave SQL: No Seconds Behind Master: (null) https://icinga.wikimedia.org/cgi-bin/icinga/extinfo.cgi?type=2&host=frdb1006&service=check_mysql [17:36:17] let's rebase the queue consumer over that [17:37:48] hmm, I could have it check for the fiscal_number there [17:41:12] PROBLEM - check_mysql on frdb1006 is CRITICAL: Slave IO: Yes Slave SQL: No Seconds Behind Master: (null) https://icinga.wikimedia.org/cgi-bin/icinga/extinfo.cgi?type=2&host=frdb1006&service=check_mysql [17:42:07] 10Fundraising-Backlog, 10FR-Email: EPIC: Exploring other ESPs even if it’s just to get new workflow/feature ideas - https://phabricator.wikimedia.org/T301906 (10XenoRyet) 05Openβ†’03Declined [17:46:12] 10Fundraising-Backlog, 10FR-Amazon, 10fr-donorservices: Amazon unresponsive donation form Dec 2020 - https://phabricator.wikimedia.org/T269907 (10XenoRyet) 05Openβ†’03Resolved [17:46:12] PROBLEM - check_mysql on frdb1006 is CRITICAL: Slave IO: Yes Slave SQL: No Seconds Behind Master: (null) https://icinga.wikimedia.org/cgi-bin/icinga/extinfo.cgi?type=2&host=frdb1006&service=check_mysql [17:46:45] 10Fundraising-Backlog, 10FR-Amazon, 10fr-donorservices: Amazon unresponsive donation form Dec 2020 - https://phabricator.wikimedia.org/T269907 (10XenoRyet) Closing due to age [17:51:12] PROBLEM - check_mysql on frdb1006 is CRITICAL: Slave IO: Yes Slave SQL: No Seconds Behind Master: (null) https://icinga.wikimedia.org/cgi-bin/icinga/extinfo.cgi?type=2&host=frdb1006&service=check_mysql [17:56:12] RECOVERY - check_mysql on frdb1006 is OK: Uptime: 1702411 Threads: 5 Questions: 56563789 Slow queries: 32 Opens: 2717 Open tables: 1771 Queries per second avg: 33.225 Slave IO: Yes Slave SQL: Yes Seconds Behind Master: 0 https://icinga.wikimedia.org/cgi-bin/icinga/extinfo.cgi?type=2&host=frdb1006&service=check_mysql [18:08:52] 10Fundraising-Backlog, 10MediaWiki-extensions-CentralNotice: CentralNotice banners being shown too many times - https://phabricator.wikimedia.org/T331671 (10AndyRussG) Thanks so much everyone for your input and effort on this, and many apologies for the delay. I did a bit of digging, and it looks like there m... [18:29:08] (03PS7) 10Ejegg: UPI donations queue consumer [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/895897 (https://phabricator.wikimedia.org/T330724) [18:29:30] so ^^^ is just rebased around the fiscal_number -> legal_identifier change [18:30:20] I will put up another PS simplifying the behavior for handling installments [18:32:55] ejegg: https://phabricator.wikimedia.org/F36909648 [18:33:09] just finishing the on-going charge flow [18:33:13] it's rough [18:36:27] jgleeson: thanks so much for that ^ !!!!! [18:36:35] hugely appreciated [18:37:03] thanks AndyRussG! :) [18:38:30] jgleeson: I also have a drive-by comment, if I may, and hopefully saying it wouldn't take away from the appreciation I wish to express... I'd really like to see the "payments" swim lane separated into "user browser" and "payments server" [18:38:41] since those are separate systems [18:39:05] i.e., separate computers, different locations, connected via network, etc [18:41:48] sure lemme get the other one done and we can talk through 'em [18:42:01] I just pushed up the text definitions for them here https://gitlab.wikimedia.org/repos/fundraising-tech/fr-tech-diagrams/-/commit/cbcf41906932c8a50ba25b8a5931d41575239b7b [18:45:09] (03CR) 10CI reject: [V: 04-1] UPI donations queue consumer [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/895897 (https://phabricator.wikimedia.org/T330724) (owner: 10Ejegg) [18:54:22] cool thx jgleeson [19:19:06] (03CR) 10Damilare Adedoyin: [C: 03+2] "Thanks for working on this. Tested and works great." [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/897911 (https://phabricator.wikimedia.org/T331288) (owner: 10Ejegg) [19:25:29] fr-tech does upi switch its payment type for 2+ reucurrings like ideal does? [19:26:23] I don't know what you mean by switch cstone [19:26:51] like the first ideal payment is one type then the 2+ are a different type [19:27:05] (03PS1) 10AndyRussG: Fix test for opted out banner types [extensions/CentralNotice] - 10https://gerrit.wikimedia.org/r/897969 (https://phabricator.wikimedia.org/T331671) [19:28:06] (03CR) 10AndyRussG: "Note: Due to issues with my local setup, I haven't yet tested this locally." [extensions/CentralNotice] - 10https://gerrit.wikimedia.org/r/897969 (https://phabricator.wikimedia.org/T331671) (owner: 10AndyRussG) [19:30:42] fr-tech be 1 min [19:33:51] (03Merged) 10jenkins-bot: Move fiscal_number to legal_identifer [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/897911 (https://phabricator.wikimedia.org/T331288) (owner: 10Ejegg) [19:40:54] (03PS8) 10Eileen: Remove watchdog, legacy function calls in normalize message [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/895870 (https://phabricator.wikimedia.org/T288585) [19:41:19] (03CR) 10Eileen: "Thanks ejegg - well spotted (fixed)" [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/895870 (https://phabricator.wikimedia.org/T288585) (owner: 10Eileen) [19:44:45] 10Fundraising-Backlog, 10Wikimedia-Fundraising-CiviCRM: Update WMF_donor fields - https://phabricator.wikimedia.org/T331919 (10Eileenmcnaughton) [19:48:50] 10Fundraising Tech - Chaos Crew, 10Fundraising-Backlog, 10MediaWiki-extensions-CentralNotice, 10Patch-For-Review: CentralNotice banners being shown too many times - https://phabricator.wikimedia.org/T331671 (10AKanji-WMF) [19:55:54] 10Fundraising Tech - Chaos Crew, 10Fundraising-Backlog, 10Recurring-Donations, 10fr-donorservices: Ingenico recurrings stopped at status 600 March 5th - https://phabricator.wikimedia.org/T331490 (10AKanji-WMF) [20:01:57] 10Fundraising-Backlog: Implement Adyen Auto-Rescue feature to improve donor recurring conversion - https://phabricator.wikimedia.org/T331920 (10EMartin) [20:05:00] (03CR) 10XenoRyet: [C: 03+2] Fix test for opted out banner types [extensions/CentralNotice] - 10https://gerrit.wikimedia.org/r/897969 (https://phabricator.wikimedia.org/T331671) (owner: 10AndyRussG) [20:05:11] thanks XenoRyet!! :) [20:13:10] (03Merged) 10jenkins-bot: Fix test for opted out banner types [extensions/CentralNotice] - 10https://gerrit.wikimedia.org/r/897969 (https://phabricator.wikimedia.org/T331671) (owner: 10AndyRussG) [20:15:07] 10Fundraising-Backlog, 10MediaWiki-extensions-CentralNotice: CentralNotice admin UI should display warnings on potential banner overload - https://phabricator.wikimedia.org/T331890 (10spatton) +1, as a CentralNotice admin this makes sense and would be a useful administrative interface element. When creating a... [20:16:54] (03PS1) 10Eileen: Remove a couple more watchdogs [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/897975 (https://phabricator.wikimedia.org/T288585) [20:16:56] (03PS1) 10Eileen: Remove watchdogs from templating [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/897976 (https://phabricator.wikimedia.org/T288585) [20:16:58] (03PS1) 10Eileen: Remove some more watchdogs [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/897977 (https://phabricator.wikimedia.org/T288585) [20:17:00] (03PS1) 10Eileen: Remove more watchdogs [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/897978 (https://phabricator.wikimedia.org/T288585) [20:19:45] (03PS1) 10Eileen: Remove more watchdogs [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/897979 (https://phabricator.wikimedia.org/T288585) [20:20:04] (03CR) 10Ejegg: [C: 03+2] Remove watchdog, legacy function calls in normalize message [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/895870 (https://phabricator.wikimedia.org/T288585) (owner: 10Eileen) [20:29:07] (03PS1) 10Wfan: Add cz to wgDonationInterfaceMonthlyConvertCountries [wikimedia/fundraising/dev] - 10https://gerrit.wikimedia.org/r/897982 (https://phabricator.wikimedia.org/T331665) [20:35:00] (03Merged) 10jenkins-bot: Remove watchdog, legacy function calls in normalize message [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/895870 (https://phabricator.wikimedia.org/T288585) (owner: 10Eileen) [20:35:02] (03PS1) 10Eileen: Remove watchdogs, wmf_audit [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/897983 (https://phabricator.wikimedia.org/T288585) [20:35:04] (03PS1) 10Eileen: Remove watchdogs, wmf_than_you [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/897984 (https://phabricator.wikimedia.org/T288585) [20:35:06] (03PS1) 10Eileen: Code reformat to Civi stds [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/897985 (https://phabricator.wikimedia.org/T288585) [20:35:08] (03PS1) 10Eileen: Remove watchdog from BannerHistoryQueueConsumer [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/897986 (https://phabricator.wikimedia.org/T288585) [20:35:10] (03PS1) 10Eileen: Remove watchdog from PaymentsInitQueueConsumer [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/897987 (https://phabricator.wikimedia.org/T288585) [20:40:46] if anyone is seeing all those patches - I'm doing one file at a time - which means a lot of small commits - but also means that it's easy to dip in & out & they can be rebased out of the chain [20:45:04] (03PS1) 10Eileen: Remove watchdog from drush script + reformat [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/897990 (https://phabricator.wikimedia.org/T288585) [20:45:06] (03PS1) 10Eileen: Remove some watchdogs from drush scripts [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/897991 (https://phabricator.wikimedia.org/T288585) [20:51:00] (03PS1) 10AndyRussG: Fix fix test for opted out banner types [extensions/CentralNotice] - 10https://gerrit.wikimedia.org/r/897992 (https://phabricator.wikimedia.org/T331671) [20:51:59] XenoRyet: ^ there's the fix for the fix for CN :) thx in advance! [20:53:52] (03CR) 10XenoRyet: [C: 03+2] Fix fix test for opted out banner types [extensions/CentralNotice] - 10https://gerrit.wikimedia.org/r/897992 (https://phabricator.wikimedia.org/T331671) (owner: 10AndyRussG) [20:54:00] XenoRyet: thx! :) [20:54:10] No worries [20:54:22] (03PS1) 10Eileen: Remove watchdogs from wmf_ct_qc.module [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/897995 (https://phabricator.wikimedia.org/T288585) [20:56:25] (03Merged) 10jenkins-bot: Fix fix test for opted out banner types [extensions/CentralNotice] - 10https://gerrit.wikimedia.org/r/897992 (https://phabricator.wikimedia.org/T331671) (owner: 10AndyRussG) [20:58:20] ejegg: I think the dlocal job config is ok to deploy. [21:00:30] thanks wfan [21:01:22] (03PS1) 10Eileen: Remove watchdog from matching_gifts drush [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/897996 (https://phabricator.wikimedia.org/T288585) [21:01:33] !og enabled jobs-dlocal queue runner [21:01:38] !log enabled jobs-dlocal queue runner [21:01:41] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [21:03:36] hold on could we remote -d [21:07:57] ejegg: I just tested from civi1001, seems like we should either remove -d or add the --max-messages back. [21:08:45] just remove the -d would be fine~ [21:08:57] https://www.irccloud.com/pastebin/uhGfUlxr/ [21:09:27] (03PS4) 10Wfan: Add monthly convert amounts for CZ [extensions/DonationInterface] - 10https://gerrit.wikimedia.org/r/896388 (https://phabricator.wikimedia.org/T331665) [21:12:14] ejegg: typo add display_errors=1 after -d or remove -d not the --max-messages [21:17:51] ohh ok [21:18:00] I think I will remove -d [21:18:49] oh i see you just did it. THanks wfan! [21:19:59] np, and sorry I was not noticed that before, do you want me to deploy the update or you will? [21:20:08] could you please? [21:20:11] sure [21:21:56] !log remove -d for jobs-dlocal queue runner [21:21:59] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [21:22:34] gonna relocate, back in half an hour-ish [21:33:35] (03PS1) 10Eileen: Reformat code (only) [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/898000 (https://phabricator.wikimedia.org/T288585) [21:33:37] (03PS1) 10Eileen: Remove watchdog from Oanda retriever [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/898001 (https://phabricator.wikimedia.org/T288585) [21:33:39] (03PS1) 10Eileen: Remove watchdog from large donation module [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/898002 (https://phabricator.wikimedia.org/T288585) [21:33:41] (03PS1) 10Eileen: Apply CiviCRM formatting standard to offline2civicrm.common.inc [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/898003 (https://phabricator.wikimedia.org/T288585) [21:33:43] (03PS1) 10Eileen: Swap out watchdog from offline2civicrm [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/898004 (https://phabricator.wikimedia.org/T288585) [21:33:45] (03PS1) 10Eileen: Remove watchdog from checks file [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/898005 (https://phabricator.wikimedia.org/T288585) [21:33:47] (03PS1) 10Eileen: Remove watchdog from orphan_slayer [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/898026 (https://phabricator.wikimedia.org/T288585) [21:34:50] (03PS3) 10Eileen: Cleanup to remove call to wmf_civicrm_get_civi_id [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/895871 (https://phabricator.wikimedia.org/T288585) [21:35:16] (03PS3) 10Eileen: Fully remove wmf_get_civi_id [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/895873 (https://phabricator.wikimedia.org/T288585) [21:59:12] 10Fundraising Sprint Everything I Merge I Merge For You, 10Fundraising-Backlog, 10Wikimedia-Fundraising-CiviCRM: Missing primary address fields in Search Kit - https://phabricator.wikimedia.org/T330700 (10Eileenmcnaughton) I'm moving this to `done` cos I think we discussed it further & it is resolved. Howeve... [21:59:55] 10Fundraising Sprint Drop It Like It's Fraud, 10Fundraising Sprint Everything I Merge I Merge For You, 10Fundraising-Backlog, 10Wikimedia-Fundraising-CiviCRM, and 2 others: Swap all our process logging to Civi::log('wmf') from watchdog() - https://phabricator.wikimedia.org/T288585 (10Eileenmcnaughton) a:0... [22:01:38] man - these watchdog fixes are minor but there are just so many of them [22:25:48] (03PS1) 10Eileen: Apply civicrm code formatting, no other change [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/898030 (https://phabricator.wikimedia.org/T288585) [22:25:52] (03PS1) 10Eileen: Remove watchdog from refund_queue_consume drush [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/898031 [22:25:54] (03PS1) 10Eileen: Remove watchdog from AntiFraudConsumer [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/898032 (https://phabricator.wikimedia.org/T288585) [22:25:56] (03PS1) 10Eileen: Apply CiviCRM code formatting (no other change) [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/898033 (https://phabricator.wikimedia.org/T288585) [22:25:58] (03PS1) 10Eileen: Remove watchdog from banner_history_queue_consume [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/898034 (https://phabricator.wikimedia.org/T288585) [22:26:00] (03PS1) 10Eileen: Remove watchdog from wmf_optin [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/898035 (https://phabricator.wikimedia.org/T288585) [22:26:02] (03PS1) 10Eileen: Remove watchdog from unsubscribe [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/898036 (https://phabricator.wikimedia.org/T288585) [22:27:02] 10Fundraising Sprint Everything I Merge I Merge For You, 10Fundraising-Backlog, 10FR-dlocal: Create UML diagrams for dLocal India Recurring - https://phabricator.wikimedia.org/T331555 (10jgleeson) New subscription data flow: {F36910251, size=full} [22:27:49] 10Fundraising Sprint Everything I Merge I Merge For You, 10Fundraising-Backlog, 10FR-dlocal: Create UML diagrams for dLocal India Recurring - https://phabricator.wikimedia.org/T331555 (10jgleeson) Ongoing recurring charge flow: {F36910253, size=full} [22:29:06] 10Fundraising Sprint Everything I Merge I Merge For You, 10Fundraising-Backlog, 10FR-dlocal: Create UML diagrams for dLocal India Recurring - https://phabricator.wikimedia.org/T331555 (10jgleeson) gitlab patch with associated text definitions is [[ https://gitlab.wikimedia.org/repos/fundraising-tech/fr-tech-... [22:30:58] fr-tech, I've finished the sequence diagrams for dlocal india recurring new subscriptions and ongoing charges. I think now we can discuss whether the flow depicted is what we what and if so what else do we need to get us there. The diagrams are here https://phabricator.wikimedia.org/T331555 [22:32:12] we'll likely make changes and add missing details so they are a WIP for now but the sooner we can lock in the flow and finish off the last bits of coding the better! thanks in advance [22:45:53] thanks jgleeson [22:52:09] (03CR) 10Ejegg: [C: 03+2] "Looks good for the happy case, nice thorough tests" [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/895862 (https://phabricator.wikimedia.org/T324301) (owner: 10Ejegg) [22:52:22] (03PS8) 10Ejegg: Smashpig Extension: UPI Recurring [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/895862 (https://phabricator.wikimedia.org/T324301) [22:52:30] (03CR) 10Ejegg: [C: 03+2] Smashpig Extension: UPI Recurring [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/895862 (https://phabricator.wikimedia.org/T324301) (owner: 10Ejegg) [22:55:39] ejegg: I'm just gonna push up a small update to that patch [22:55:59] just to allow the prenotification call to retry [22:56:24] ty for the review [23:06:33] (03Merged) 10jenkins-bot: Smashpig Extension: UPI Recurring [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/895862 (https://phabricator.wikimedia.org/T324301) (owner: 10Ejegg) [23:12:26] ejegg: I think the legal_identifier patch may have uncovered a bug [23:12:54] I'm seeing a bunch of unexpected params being sent to createPayment now [23:14:00] the mapped output from this method is what's being sent to createPayment($params) https://github.com/wikimedia/wikimedia-fundraising-crm/blob/e95087154112a14e381342744f0c8b5304f906f6/drupal/sites/default/civicrm/extensions/org.wikimedia.smashpig/CRM/Core/Payment/SmashPigRecurringProcessor.php#L460 [23:20:11] (03PS1) 10Wfan: Add amount limitation for dlocal certain payment method [wikimedia/fundraising/dev] - 10https://gerrit.wikimedia.org/r/898041 (https://phabricator.wikimedia.org/T324299) [23:20:14] ah no ejegg. I can now see they are mapped again here to seemingly correct params https://github.com/wikimedia/wikimedia-fundraising-crm/blob/e95087154112a14e381342744f0c8b5304f906f6/drupal/sites/default/civicrm/extensions/org.wikimedia.smashpig/CRM/Core/Payment/SmashPig.php#L74 [23:32:02] (03PS2) 10Wfan: Add recurring amount validation to DI for india bt recurring [extensions/DonationInterface] - 10https://gerrit.wikimedia.org/r/895731 (https://phabricator.wikimedia.org/T324299) [23:33:37] (03CR) 10CI reject: [V: 04-1] Add recurring amount validation to DI for india bt recurring [extensions/DonationInterface] - 10https://gerrit.wikimedia.org/r/895731 (https://phabricator.wikimedia.org/T324299) (owner: 10Wfan) [23:36:00] (03PS3) 10Wfan: Add recurring amount validation to DI level for dlocal IN bt recurring [extensions/DonationInterface] - 10https://gerrit.wikimedia.org/r/895731 (https://phabricator.wikimedia.org/T324299) [23:38:17] 10Fundraising Sprint Drop It Like It's Fraud, 10Fundraising Sprint Everything I Merge I Merge For You, 10Fundraising-Backlog, 10Wikimedia-Fundraising-CiviCRM, and 3 others: Ensure DLocal recurring card payments can be charged via Civi SmashPig recurring charge job - https://phabricator.wikimedia.org/T324298... [23:38:51] (03PS1) 10Jgleeson: Fix test for Smashpig Extension: UPI Recurring [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/898043 (https://phabricator.wikimedia.org/T324301) [23:46:05] (03CR) 10CI reject: [V: 04-1] Add recurring amount validation to DI level for dlocal IN bt recurring [extensions/DonationInterface] - 10https://gerrit.wikimedia.org/r/895731 (https://phabricator.wikimedia.org/T324299) (owner: 10Wfan) [23:52:23] (03PS1) 10Jgleeson: WIP: Smashpig Extension: UPI Recurring retry [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/898086 [23:52:35] (03PS4) 10Wfan: Add recurring amount validation to DI level for dlocal IN bt recurring [extensions/DonationInterface] - 10https://gerrit.wikimedia.org/r/895731 (https://phabricator.wikimedia.org/T324299) [23:54:29] (03PS2) 10Jgleeson: Fix test for Smashpig Extension: UPI Recurring [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/898043 (https://phabricator.wikimedia.org/T324301) [23:54:36] (03PS2) 10Jgleeson: WIP: Smashpig Extension: UPI Recurring retry [wikimedia/fundraising/crm] - 10https://gerrit.wikimedia.org/r/898086