[00:13:45] ejegg|away: yeah about now [00:14:10] (CR) Eileen: [C: 2] Allow 'donation' under tx type for Bitpay import [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/445035 (https://phabricator.wikimedia.org/T198669) (owner: Ejegg) [00:19:47] (Merged) jenkins-bot: Allow 'donation' under tx type for Bitpay import [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/445035 (https://phabricator.wikimedia.org/T198669) (owner: Ejegg) [04:04:18] Fundraising Sprint Junebugs prefer July, Fundraising Sprint Karma chameleons hide amongst us, Fundraising-Backlog, MediaWiki-extensions-CentralNotice: CentralNotice - CSP overreach - https://phabricator.wikimedia.org/T193332 (AndyRussG) Hi! There is a [[ https://stackoverflow.com/questions/273236... [04:19:45] (CR) Eileen: "recheck" [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/444769 (owner: Eileen) [04:26:46] (CR) jerkins-bot: [V: -1] [WIP] CiviCRM 5.4 [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/444769 (owner: Eileen) [04:41:29] Fundraising Sprint Junebugs prefer July, Fundraising Sprint Karma chameleons hide amongst us, Fundraising-Backlog, MediaWiki-extensions-CentralNotice: CentralNotice - CSP overreach - https://phabricator.wikimedia.org/T193332 (Bawolff) We may be adjusting the core csp header Its kind of rediculou... [13:17:20] jgleesn: [13:17:28] Happy birthday ya scouse bastard [13:17:45] it's the other Jack!!! [13:17:48] ha :) [13:20:22] Fundraising-Backlog, MediaWiki-extensions-DonationInterface, Continuous-Integration-Config: Fundraising should fall back to non master - https://phabricator.wikimedia.org/T199130 (hashar) [13:21:42] ffs [13:21:50] I'd be impressed if the other Jack knew what 'scouse' was [13:22:04] the dish or the dialect [13:23:13] jgleeson: the dish doesn't count. It's just a rebranded hotpot [13:23:22] lol [13:24:11] Maybe re-badged is the more appropriate verb for the area [13:26:31] technically it's a stew [13:28:00] imported from Scandinavia [13:28:31] https://en.wikipedia.org/wiki/Scouse_(food) [13:28:49] comes from the word "lobscouse"... what [13:54:03] Fundraising-Backlog, MediaWiki-extensions-DonationInterface, Continuous-Integration-Config: Fundraising should fall back to non master - https://phabricator.wikimedia.org/T199130 (hashar) And eventually I figured out that the issue is when sending a patch to mediawiki/core branch `fundraising/REL1_27... [14:11:58] Fundraising-Backlog: Investigate why Ingenico donation did not recur on 6/14 - https://phabricator.wikimedia.org/T199331 (MBeat33) [14:14:14] Fundraising-Backlog, MediaWiki-extensions-DonationInterface, Continuous-Integration-Config, Patch-For-Review, Release-Engineering-Team (Kanban): Fundraising should fall back to non master - https://phabricator.wikimedia.org/T199130 (hashar) a:hashar [14:56:17] (PS4) Mepps: WIP Refactor of ConfirmCreditCard [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/444311 (https://phabricator.wikimedia.org/T194517) [14:56:19] (PS4) Mepps: WIP: Handle no status code for Ingenico api [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/440465 (https://phabricator.wikimedia.org/T194517) [14:58:04] (CR) jerkins-bot: [V: -1] WIP: Handle no status code for Ingenico api [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/440465 (https://phabricator.wikimedia.org/T194517) (owner: Mepps) [15:08:47] yikes, lots of failmail [15:11:04] the message is correct, new endpoint IP [15:18:19] (CR) Hashar: "It is not needed right now, but will whenever I switch to a Quibble job. Quibble relies on MediaWiki to detect and inject wfLoadExtension" [core] (fundraising/REL1_27) - https://gerrit.wikimedia.org/r/419526 (https://phabricator.wikimedia.org/T189567) (owner: Hashar) [15:18:44] (CR) Hashar: "recheck" [core] (fundraising/REL1_27) - https://gerrit.wikimedia.org/r/419526 (https://phabricator.wikimedia.org/T189567) (owner: Hashar) [15:19:07] (CR) Hashar: "recheck" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/324066 (owner: Hashar) [15:19:14] (CR) jerkins-bot: [V: -1] Let install.php detect and inject extensions [core] (fundraising/REL1_27) - https://gerrit.wikimedia.org/r/419526 (https://phabricator.wikimedia.org/T189567) (owner: Hashar) [15:19:27] (Abandoned) Reedy: Let install.php detect and inject extensions [core] (fundraising/REL1_27) - https://gerrit.wikimedia.org/r/419526 (https://phabricator.wikimedia.org/T189567) (owner: Hashar) [15:22:32] (CR) Hashar: "Magic :]" [core] (fundraising/REL1_27) - https://gerrit.wikimedia.org/r/419526 (https://phabricator.wikimedia.org/T189567) (owner: Hashar) [15:23:01] (PS1) Hashar: Jenkins job validation (DO NOT SUBMIT) [core] (fundraising/REL1_27) - https://gerrit.wikimedia.org/r/445186 [15:29:09] (PS1) Reedy: Revert "Hack out some failing tests on fundraising/REL1_27" [core] (fundraising/REL1_27) - https://gerrit.wikimedia.org/r/445189 [15:31:42] (CR) jerkins-bot: [V: -1] Revert "Hack out some failing tests on fundraising/REL1_27" [core] (fundraising/REL1_27) - https://gerrit.wikimedia.org/r/445189 (owner: Reedy) [15:31:50] pfft [15:32:17] ejegg: ^ lol [15:32:25] 15:31:37 There was 1 error: [15:32:25] 15:31:37 [15:32:25] 15:31:37 1) IngenicoFormLoadTest::testIngenicoFormLoad_FR [15:32:25] 15:31:37 DOMDocument::loadHTML(): error parsing attribute name in Entity, line: 308 [15:32:30] So none of the ones you disabled... xD [15:33:32] (Abandoned) Hashar: Jenkins job validation (DO NOT SUBMIT) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/324066 (owner: Hashar) [15:34:03] (Abandoned) Hashar: Jenkins job validation (DO NOT SUBMIT) [core] (fundraising/REL1_27) - https://gerrit.wikimedia.org/r/445186 (owner: Hashar) [15:37:33] cwd ejegg, do we have a fix for the cause of all this failmail? [15:38:52] mepps yeah, a firewall update [15:38:59] i think cwd is on it [15:39:14] well i can't update the firewall actually [15:39:33] it's a netops duty [15:39:37] we might need a short term fix [15:39:54] ops is dealing with other fires atm [15:41:09] fr-tech: can we hack out the failmail in the mean time? [15:41:23] or i'm open to other suggestions [15:49:18] fundraising-tech-ops, Operations, netops: New PFW policy for Amazon - https://phabricator.wikimedia.org/T199341 (cwdent) [15:51:42] cwd yeah, sorry, let me get that in the smaahpig settings [15:52:37] ejegg: cool, i might be able to get the new fw policy up, asking around [15:53:26] ejegg, anything we can be doing to help? [15:53:28] we broke email with this one [16:00:41] jgleeson I'm about to push a change to smashpig settings [16:01:06] cool! [16:01:50] ejegg can you document later how you did this? maybe a good tech talk [16:02:07] sure, it's just in the settings repo on frpm [16:02:15] under SmashPig/local-config [16:02:28] ejegg: you disabled the mail? [16:02:30] disabling the failmail logstream [16:02:49] !log disabled failmail logstream for SmashPig [16:02:50] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [16:02:55] cwd just did now [16:03:01] thanks :) [16:03:07] i'll let you know when i get the fw config worked out [16:03:34] Reedy: oh man, that's a really flaky almost-browser-test [16:03:57] would be nice to move that and its siblings to actual browser tests [16:04:51] jgleeson and mepps so I just disabled failmail for all gateways cause I didn't think I could do it for just the amazon gateway [16:05:32] The way we're merging the defaults + the gateway overrides, I'm not sure that we can REMOVE something in an override [16:06:25] if you look in SmashPig/local-config/provider-defaults [16:06:37] which box ejegg ? [16:06:48] jgleeson it's in the settings repo on frpm [16:07:25] thanks [16:07:54] on a side note, fr-tech I just added this https://etherpad.wikimedia.org/p/fr-tech-talk-ideas [16:08:03] feel free to edit/add/improve [16:10:26] ejegg, do you mean we can't remove an existing constructor argument [16:10:30] look at file now [16:10:32] looking* [16:11:12] anyway... I think in order to disable the failmail for just Amazon, we could redefine all the parts of the failmail constructor under log-streams/failmail [16:11:21] in amazon/main.yaml [16:12:40] make it a ConsoleLogStream or something [16:13:35] crap I got disconnected [16:13:41] sorry :( [16:15:18] I didn't catch anything after I posted ejegg but it looks like you might be discussing swapping out the failmail class in the config [16:15:29] as in [16:15:31] failmail: [16:15:31] class: SmashPig\Core\Logging\LogStreams\FailmailLogStream [16:15:42] yeah, just tried that and pushed it out [16:15:44] Looks like it's been an exciting morning [16:16:29] Fundraising-Backlog, MediaWiki-extensions-ContributionTracking: [ContributionTracking] default DB settings differs when using extension registration - https://phabricator.wikimedia.org/T195814 (greg) Adding #fundraising-backlog per https://www.mediawiki.org/wiki/Developers/Maintainers :) [16:17:33] ejegg, what if you don't merge it in the amazon config [16:17:50] and just add a new block without any merge characters [16:17:59] will it overwrite it? [16:18:09] jgleeson: it's not a yaml-level <<< merge [16:18:23] it's PHP reading the files and merging the arrays recursively [16:18:29] ah [16:20:06] cwd so how did this break email when holiday thank-you mails don't overwhelm the system? [16:20:58] ah, incoming, not outgoing, right? [16:21:19] yeah [16:21:52] cwd I think that last thing I did actually fixed it, can you tell? [16:22:23] nothing in thulium postfix logs about fr-tech since 16:17 [16:25:29] ejegg: The latest timestamps hitting my inbox are from 15:58, so... we probably will get more emails. [16:25:58] fundraising-tech-ops, Operations, netops: New PFW policy for Amazon - https://phabricator.wikimedia.org/T199341 (cwdent) @ayounsi the last one I posted was incomplete, I found the problem and 1531326142 should fix it [16:32:27] Fundraising-Backlog, FR-Smashpig: Look at standard config library for SmashPig - https://phabricator.wikimedia.org/T199346 (Ejegg) [16:32:44] waiting for the end of the failamail wave like: http://gifimage.net/wp-content/uploads/2017/10/hold-gif-6.gif [16:33:05] lol [16:33:53] heh [16:33:56] we just got a different failmail [16:34:03] another villan! [16:34:12] lock file [16:37:26] fr-tech if any wants to give their brain a failmail-break and think about something else briefly, here a question I'm pondering for the new Kafka Python scripts: should we use anything even semi-fancy for db access, like say the pretty straightforward sqlachelmy https://en.wikipedia.org/wiki/SQLAlchemy, or just stick to straight sql? [16:38:02] It's pretty sure that these scripts will never like, get bigger and gain features [16:38:21] They need to work and be easy to understand and maintainable [16:38:35] But they're certainly not the basis for anything bigger [16:38:59] Given that I'm leaning towards using straight sql [16:39:18] I guess performance is also an issue... Even the best orm/DB abstraction layer is going to have some overhead [16:39:55] My instinct is for sticking with straight SQL [16:39:59] AndyRussG i would lean toward straight sql too if we just need it to work [16:40:32] Mmmm... also, even though SQLAlchemy does have Debian packages, making it potentially installable on the cluster, it'd still be another piece of work for ops [16:40:34] introducing additional dependencies can cause issues down the road [16:41:17] mepps XenoRyet okok! Yeah I think you're right :) [16:41:30] thx!!! :) [16:41:36] No worries [16:41:43] pls lmk if u have further suggestions on this btw :) [16:42:33] +1 to straight sql [16:42:48] Yea, I'll look into SQLAlchemy some more, but without a really compelling resaon to go that way I think keeping it simpler is better. [16:43:24] jgleeson: :) thx! [16:44:21] XenoRyet: yeah, I mean, basically the reason to go to some ORM would be if that makes the code cleaner, but I think the advantages are mainly when you're building an app that will eventually get to a level of complexity this will never reach [16:45:01] Yep, I can definitely see where it would get useful, but it does seem like it's not the tool for this job. [16:45:48] If this were destined to one day be part of a framework that would have multiple clients, APIs, front-ends that would query and write the data in different ways, then okok, but this is just straight out-and-out load up some tables and never to be seen again [16:47:00] AndyRussG, on an unrelated note, I got the python bannerimpressions app running [16:47:13] i just needed to feed it an unzipped gz file [16:47:37] jgleeson: cool!!! :) [16:47:59] ah you mean, zipped, no? [16:48:11] ah shoot, yes! zipped [16:48:13] gzipped [16:48:14] heh I see, file = gzip.open(filename, 'rb') [16:48:15] :) [16:48:55] on a very tangential note, is "sheveled" the opposite of "disheveled"? [16:49:08] makes sense to me [16:49:30] 8p it was just one of my pre-coffee delirium dilemmas [16:49:32] oh no [16:49:39] Well, unfortunately you're never going to be gusted, gruntled or sheveled. Disgusted, disgruntled and disheveled are what you might call “lonely negatives.” [16:50:00] oh hmmm! [16:50:13] I guess just tidy [16:50:42] heheh [16:50:50] sad there's no enwiki entry for that! [16:51:05] I guess it's diswikied [16:51:06] doesn't have the same eloquence I admit :) [16:51:10] lol [16:51:40] So are words with no negative companion lonely affirmatives? [16:51:54] Seems unfair that only the negatives are considered lonely [16:53:11] Well, I just fell down that etymological hole. Apparently goes back to the latin word for hair. [16:53:28] which word XenoRyet ? [16:53:34] Oh interesting [16:53:36] disheveled [16:53:40] sorry for the distraction [16:53:57] fr-tech btw do we have a standard practice for how scripts that run under process to control should emit debugging and error messages? [16:53:58] Na, it was fun. I dig that stuff [16:54:23] :) [16:56:01] It apparently starts with capillus, Latin for hair, then to chevel in old French for hair, then the dis- came in and it was descheveler for 'to dissarange the hair', then we get to the modern forms. [16:56:30] Though there was a minute there where it was more literal and just meant bald. [16:56:50] hehe wow [16:57:46] I guess yeah it does sound like the French word for hair, cheveux [16:59:02] wrt grammar, here's my fav: http://www.oxfordscholarship.com/view/10.1093/acprof:oso/9780195331967.001.0001/acprof-9780195331967 [16:59:48] Huh, sounds interesting. [17:01:13] yeah it is! I don't condone reading unofficial PDFs of that book that may or may not be downloadable from somewhere [17:01:46] Yes... I would never do something like that... [17:02:42] I would. [17:02:42] hnrrrrggggh [17:02:51] :D [17:03:23] I really need to start reading again [17:03:49] I set an hour aside a day to read, but I'm currently filling the time with non-reading things [17:03:51] AndyRussG: process-control will pick up anything from stderr and stdout [17:05:35] speaking of process-control, who wants to watch me make a new job for the smashpig recurring? [17:06:20] will do a screenshare for that in queenmary shortly [17:06:34] Yea, I'd watch that. [17:06:43] sure! I'm dropping off soon but would be good to catch some [17:06:51] cool! [17:06:57] fr-tech ^^^ [17:07:18] Give me like 5 minutes then I'll be ready to join [17:07:25] fundraising-tech-ops, Operations, netops: New PFW policy for Amazon - https://phabricator.wikimedia.org/T199341 (ayounsi) Pushed. [17:07:38] ejegg: and where does it put what it gets from stderr and stdout? [17:07:40] ejegg would love to but i have performance review + check in with k4 then meetings alll the rest of the day [17:07:55] ok mepps [17:08:05] if you want a recap another day just ask [17:08:14] and what can/do we do with the stuff it puts there, wherever there is? [17:08:38] AndyRussG: it goes into log files on civi1001 in /var/log/process-control [17:08:46] which get bzipped and archived on frlog1001 [17:14:22] Fundraising Sprint Junebugs prefer July, Fundraising Sprint Karma chameleons hide amongst us, Fundraising-Backlog, MediaWiki-extensions-CentralNotice: CentralNotice - CSP overreach - https://phabricator.wikimedia.org/T193332 (AndyRussG) >>! In T193332#4414663, @Bawolff wrote: > So the core stuff... [17:15:39] ejegg: so basically saved for posterity and can be grepped in case there was a problem, but otherwise never consulted, right? [17:16:16] So, basically I'll just output error messages to stderr, no? [17:16:37] And I guess, for a debug mode, extra debug info there, too? [17:16:38] Fundraising Sprint Junebugs prefer July, Fundraising Sprint Karma chameleons hide amongst us, Fundraising-Backlog, MediaWiki-extensions-CentralNotice: CentralNotice - CSP overreach - https://phabricator.wikimedia.org/T193332 (Bawolff) > OK thanks...!!! Do you know if, as it is, it allows gad... [17:19:18] (PS5) Mepps: WIP Refactor of ConfirmCreditCard [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/444311 (https://phabricator.wikimedia.org/T194517) [17:20:03] (PS6) Mepps: WIP Refactor of ConfirmCreditCard [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/444311 (https://phabricator.wikimedia.org/T194517) [17:20:05] (PS5) Mepps: WIP: Handle no status code for Ingenico api [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/440465 (https://phabricator.wikimedia.org/T194517) [17:22:28] (CR) jerkins-bot: [V: -1] WIP Refactor of ConfirmCreditCard [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/444311 (https://phabricator.wikimedia.org/T194517) (owner: Mepps) [17:23:17] Also, fr-tech thinking of adding some basic info about number of entries processed or ignored somewhere into the DB schema. So instead logging like this https://github.com/wikimedia/wikimedia-fundraising-tools-DjangoBannerStats/blob/master/fundraiser/analytics/management/commands/LoadLPImpressions.py#L171-L175 we could have that overview of how each file went in the db [17:23:51] Also, ideas for a name for the scripts would be welcome :) [17:30:59] fr_event_logging_processor? [17:31:37] fr_event_logging_consumer? [17:31:42] data_loader? [17:37:07] have a good rest of your day fr-tech! [17:38:05] oh heck I'm missing scrum of scrums [17:38:12] any last-minute news fr-tech? [17:38:17] Na, none here. [17:39:05] ejegg: might mention the emails [17:42:42] ejegg: all good, thx :) [17:43:29] ejegg: or, I guess might be worth mentioning very briefly thanks to the MCR folks for fixing the issue? [17:44:02] doesn't entail any action items at this point realy [17:48:31] cwd yep, apologized for that disruption [17:48:56] AndyRussG: k, sent a thank you [17:50:52] ejegg: thx4thx :) [17:52:17] fr-tech if your github account doesn't have 2fa yet, please turn it on [17:52:36] let me check that. [17:52:38] (especially if you want to stay part of the 'wikimedia' org group on github) [17:53:19] ejegg: thanks [17:53:34] i am writing the incident report but want to make sure i actually understand what happened [17:54:06] ejegg: at this point i think the problem is at amazon, none of the IPs in those emails answer to https [17:54:15] does that make sense? [17:54:18] ??? [17:54:45] i was flailing assuming it was the firewall [17:54:50] from where? [17:54:58] from anywhere [17:55:05] my laptop [17:55:06] well weird [17:55:20] can you check? [17:55:38] sure, one sec [17:55:39] Ok, github 2FA turned on [17:56:12] our listener can request https to anywhere, and has a dmz interface that can get https from anywhere [17:56:19] so only payments should actually care if the IP changes [17:58:16] what's the curl option to bypass dns? [17:58:39] ah, --resolve [18:41:20] (PS1) Ejegg: Set recurring smashpig job params in spec function [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/445232 [19:07:46] Okok also turned on 2fa [19:08:12] for github [19:08:39] fr-tech I think I have to skip tech-talk today, since now is the only window I have to feed my kids, given the rescheduled sprink planning [19:08:52] eileen and i are in a meeting during that time anyways [19:09:02] yeah, let's take it off the calendar [19:09:13] ah okok :) thx! [21:00:00] fundraising-tech-ops: Staging access for Saurabh - https://phabricator.wikimedia.org/T199373 (Eileenmcnaughton) [21:08:41] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, FR-WMF-Audit: GlobalCollect recurring donation refunds marked against wrong installment - https://phabricator.wikimedia.org/T199376 (Ejegg) [21:09:08] Fundraising Sprint Elevators were never intended to go down, Fundraising Sprint Matt Damon to head up Space Force, Fundraising-Backlog, Fr-Ingenico-integration_2017-18, and 2 others: Ingenico Connect: Support 3d Secure transactions - https://phabricator.wikimedia.org/T176512 (Ejegg) Open>R... [21:09:21] Fundraising Sprint Matt Damon to head up Space Force, Fundraising-Backlog, Fr-Ingenico-integration_2017-18: New Ingenico iframe is slightly cut off at top - https://phabricator.wikimedia.org/T194513 (Ejegg) Open>Resolved p:Triage>Low a:Ejegg [21:24:32] Fundraising-Backlog: Investigate why Ingenico donation did not recur on 6/14 - https://phabricator.wikimedia.org/T199331 (mepps) Hmm so the question is why was this cancelled. I'm seeing a few of these from that date range but haven't found a common cause. [21:26:49] Fundraising Sprint Karma chameleons hide amongst us, Fundraising Sprint Lactose is unusually tolerant, Fundraising Sprint Matt Damon to head up Space Force, Fundraising Sprint N 2018, and 2 others: Civi: enable Force Merge Selected Duplicates for new DS-Adm... - https://phabricator.wikimedia.org/T193674 [21:26:51] Fundraising Sprint N 2018, Fundraising-Backlog: Update Wikimedia CH landing page redirects - https://phabricator.wikimedia.org/T196403 (DStrine) [21:26:54] Fundraising Sprint N 2018, Fundraising-Backlog: Deploy new thank you email translations - https://phabricator.wikimedia.org/T198870 (DStrine) [21:48:32] Fundraising-Backlog, fundraising-tech-ops: Try Amazon proxy IP for cert retrieval - https://phabricator.wikimedia.org/T199382 (cwdent) [22:19:49] !log activated SmashPig recurring donation job [22:19:51] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [22:23:08] Fundraising Sprint HTTP originally stood for Happy Turtle Transfer Protocol, Fundraising Sprint Ivory and eggshell white are the same color, Fundraising Sprint Junebugs prefer July, Fundraising Sprint Karma chameleons hide amongst us, and 6 others: Write s... - https://phabricator.wikimedia.org/T170973 [22:45:25] XenoRyet|food: when you get back, want to get a jump start on the opt-in checkbox? [22:45:43] I started making a thing, but I should do this more collaboratively [23:15:34] hmm just thinking when to delete a whole activity & when to delink. I think the options are to determine by activity type (which feels clunky) or to check if there is more than one target & then delete. I’m just not sure if we need to check assigned as well - guess assigned would be source if not the contact in question [23:15:57] what's the value in a de-linked activity? [23:16:05] ah, multiple targets [23:16:11] yeah [23:18:33] I feel like one extension I looked at said ‘if there are more than 2 distinct contact ids then delink rather than delete' [23:18:37] which might make sense [23:18:53] XenoRyet: I dove into the opt-in checkbox stuff, but I'd rather do this collaboratively - want to screenshare to get started on that? [23:19:10] eileen: yeah, then if all linked contacts get deleted, the activity itself goes away [23:19:32] I'm actually kind of into the fraud headspace at the moment. Tomorrow maybe? Could get Jack and Maggie in on it as well. [23:19:35] ejegg: right - but one of the contacts is likely to be a staff member [23:19:44] so probably if there are only 2 then it should go [23:20:02] eileen: oh right, hmm [23:21:09] lemme just clarify the types of links for myself [23:21:13] ok XenoRyet [23:22:19] Guess I should update phab with that. [23:23:34] eileen ok, so 'contact deleted by merge' activities have 2 non-staff links, but those are both really the same person [23:23:49] yeah - but I’m not deleting that activity type [23:23:54] got it [23:24:04] not deleting these [23:24:07] 'Payment', [23:24:08] 'Refund', [23:24:09] 'Cancel Recurring Contribution', [23:24:11] 'Update Recurring Contribution Billing Details', [23:24:12] 'Update Recurring Contribution', [23:24:14] 'Grant Application Due', [23:24:15] 'Grant Decision', [23:24:17] 'Report Due', [23:24:18] 'Grant Reminder', [23:24:20] 'Contact Merged', [23:24:21] 'Failed Payment', [23:24:23] 'Contact Deleted by Merge', [23:24:24] 'unsubscribe', [23:24:25] 'contact_type_changed', [23:24:26] 'forget_me' [23:24:33] ok [23:25:31] so we have a list of things NOT to delete... [23:25:39] 'Contribution' gets deleted? [23:26:30] ejegg: not to delete [23:26:51] (contribution is contribution activity - yeah we could ‘not delete’ that too [23:27:29] I guess grant stuff is a bit moot - I mean if a granting agency REALLY asked us to delete them... [23:27:35] The 2+ distinct seems like a viable rule [23:27:44] ejegg: OK - will do it [23:27:57] we could filter out IDs where the user has a login [23:28:07] and make it 1+ [23:28:33] uf_match or something? [23:29:52] ejegg: yeah that makes sense too [23:30:10] unless that's overcomplicated or non-performant [23:31:28] ejegg: no - it’s probably simpler [23:32:05] but I can’t see how to do it in one api call - the check for the number of contacts - so will need to do a second call or query I think [23:32:15] unless I want to construct one complex query [23:32:37] then again - this is a low traffic action so focus is prob not on performance unless it’s a bad query [23:33:00] well, maybe just put the filter idea in a comment and start with the 2+ rule? [23:34:50] ejegg: [23:34:58] it’s the 2+ that requires a second query [23:35:07] ohhh [23:35:10] ie one query to get a list of activities [23:35:17] & one to find out how many with each one [23:35:41] heh, api golf? [23:35:56] like you said, this is pretty low traffic [23:36:06] :-) [23:52:56] Fundraising Sprint Naming Sprints Is Not Important, Fundraising-Backlog: Investigate why Ingenico donation did not recur on 6/14 - https://phabricator.wikimedia.org/T199331 (Ejegg) Ut-oh, there may be a bunch more of these! I'm seeing a new type of error in the logs for the DO_PAYMENT requests we use in... [23:56:29] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Recurring-Donations: Add metrics for recurring charge job to Grafana - https://phabricator.wikimedia.org/T199390 (Ejegg)