[00:07:02] ejegg: are you IRCing on a plane???? [00:07:08] wooooo [00:07:28] crazy, huh? [00:08:12] i'm surprised that irc is going through fine when ssh isn't [00:09:29] You can configure ssh to go through port 443 (https) [00:09:44] But you have to firs somehow get to your vps to set that up... [00:09:49] yeah, I wish I'd though of that before I got on the plane! [00:10:10] also, i do run https sites off that port [00:10:19] Ah hmm [00:10:34] AndyRussG, could you review https://gerrit.wikimedia.org/r/#/c/333679/ when you have a chance. I don't know enough about CentralNotice so it would take me some digging. [00:10:39] thanks to certbot [00:10:51] AndyRussG, goal is to target MediaWiki.org as a separate entity. (I'm also not sure what 'wikimedia' currently does). [00:12:08] ahh, that's why srishakatux was trying to use sitenotice to show something there [00:13:10] I guess [00:13:20] matt_flaschen: hi! Infact I was just digging at that right now [00:14:11] It seems that that's the way to go... CN is indeed enabled on mediawiki.org, and it does get some campaigns [00:15:24] AndyRussG, what's the way to go? [00:15:26] ejegg: maybe multiple subdomains could avoid collisions? [00:15:28] Do you mean 'wikimedia'? [00:15:48] What does that mean exactly, MediaWiki.org, MW.org + other stuff? [00:16:10] matt_flaschen: I mean, so far it looks like the patch takes the correct approach [00:16:30] Though we should also try to move that setup out of a CN default and into mediawiki-config [00:16:45] AndyRussG, how does it get campaigns already before this patch? Is there a broader group that includes MW.org? [00:17:02] Must be, but that's weird [00:17:35] Go to mediawiki.org, open a console, and type mw.centralnotice.choiceData [00:18:53] It's undefined for me logged out. [00:19:31] Ah sorry mw.centralNotice.choiceData [00:19:35] (missing a capital) [00:19:43] matt_flaschen: ^ [00:20:22] Ah I think I see how it works, one sec [00:20:34] Maybe those are all-wiki banners. [00:20:41] I don't know how "every wiki" is configured. [00:21:21] This should also be documented somewhere. [00:22:51] AndyRussG, weird things to think about: 1. The DB name of Wikispecies (also a single-wiki "family") is specieswiki, but it's in that list as 'wikispecies'. 2. The DB name of MediaWiki.org is 'mediawikiwiki'. It's in there as 'mediawiki' which is maybe? right. [00:23:14] In the proposed patch as mediawiki I mean. [00:24:32] matt_flaschen: totally agreed it should be documented... and cleaned up... preferably in reverse order, I guess [00:28:17] matt_flaschen: https://github.com/wikimedia/operations-mediawiki-config/blob/1bc8f4a2d44172f2132a30f07b9beb1b7ff8ae86/wmf-config/InitialiseSettings.php#L4505-L4523 [00:29:47] So all the ones with the 'wikimedia' value will be targeted by a campaign for the "wikimedia" project [00:29:52] Indeed it's a catch-all [00:31:02] It should be easy to update to target only mediawiki.org [00:40:33] laptop battery's running low up here at 32,000 feet, going to sign off for now! [00:41:46] "laptop battery's running low up here at 32,000 feet" [00:41:56] "Exit, pursued by a bear." [00:42:02] Terrifying [00:44:13] haha [00:44:18] starring samuel l jackson [00:46:13] AndyRussG, great, let me know if you'd like me to review anything related to that. [00:46:32] matt_flaschen: so for targeting mw.org it'd be this change or something similar, plus a config change [00:46:52] Though it'd probably be almost as easy to move this config from a CN default into mediawiki-config where I think it should live [00:47:10] I imagine this is a campaign that should go out nowish? [00:48:53] AndyRussG, yep. I don't know what your normal policy is on SWAT, I might want to do it a little early. [00:49:25] It's for the CoC one. [00:49:41] (There will be a few messages, one is ready to run when this is ready, or there will be others after that). [00:52:01] matt_flaschen: K... For SWAT probably we should just do the minimal thing, so update the config in MW and then minimal config needed in config [00:58:33] Fundraising Sprint Baudelaire Bowdlerizer, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Unplanned-Sprint-Work: Resolve dedupe conflicts on latitude and longitude - https://phabricator.wikimedia.org/T155677#2950785 (Ejegg) Bringing this into sprint, since it seems to be blocking de-dupe for... [00:59:37] matt_flaschen: gotta be away from the keyboard a bit, but I'll work on this more later....! [00:59:54] Thanks, I appreciate it. [01:00:32] Fundraising Sprint Baudelaire Bowdlerizer, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Unplanned-Sprint-Work: Resolve dedupe conflicts on latitude and longitude - https://phabricator.wikimedia.org/T155677#2950785 (Ejegg) a:Ejegg [01:39:54] matt_flaschen: I'd suggest we first test the change on the beta cluster... So we'd first make a config change that only modifies the labs config [01:41:16] AndyRussG, MW.org doesn't exist on Beta Cluster, unfortunately. [01:43:40] ooohh [01:46:18] Hmmmm [01:46:34] I assume that doesn't mean we need different settings between labs and prod [01:49:37] Mmm also checking how the CN db tables will handle this... [02:13:11] * matt_flaschen nods [02:13:28] You can check which wikis are available on Labs at all-labs.dblist [05:06:43] Fundraising-Backlog, MediaWiki-extensions-CentralNotice: CentralNotice: Move WMF-specific project list to mediawiki-config, from global var default - https://phabricator.wikimedia.org/T156221#2967924 (AndyRussG) [05:07:08] (CR) AndyRussG: [C: 2] Add mediawiki to list of wikis [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/333679 (https://phabricator.wikimedia.org/T155997) (owner: DatGuy) [05:09:31] (Merged) jenkins-bot: Add mediawiki to list of wikis [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/333679 (https://phabricator.wikimedia.org/T155997) (owner: DatGuy) [05:10:48] (CR) AndyRussG: "Thanks!!! This is, apparently, the right place to make this change, for now. In fact, the list of projects available to target should be m" [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/333679 (https://phabricator.wikimedia.org/T155997) (owner: DatGuy) [05:16:51] (CR) AndyRussG: "This needs a related configuration change: I09ac490cf. The two should be deployed together." [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/333679 (https://phabricator.wikimedia.org/T155997) (owner: DatGuy) [15:24:07] fundraising-tech-ops: replace indium (eqiad fundraising logger) with new hardware running jessie - https://phabricator.wikimedia.org/T145116#2969035 (Jgreen) [16:13:38] fundraising-tech-ops: rename fdb2001 to frdb2001 - https://phabricator.wikimedia.org/T156274#2969196 (Jgreen) [16:24:53] fundraising-tech-ops: reimage frdb2001 with debian/jessie - https://phabricator.wikimedia.org/T156275#2969258 (Jgreen) [17:22:51] welcome back XenoRyet! how was the vacation? [17:28:52] Pretty good, lots of time spent with family [17:29:13] Marek got to see all his cousins too, which was nice. [17:38:36] fundraising-tech-ops, Operations, ops-eqiad: decommission the old pay-lvs1001/pay-lvs1002 boxes - https://phabricator.wikimedia.org/T156284#2969512 (Jgreen) [17:47:31] fundraising-tech-ops: replace boron (fundraising build server) with new hardware running jessie - https://phabricator.wikimedia.org/T145117#2969578 (Jgreen) pfw port 11/0/10 should be relabled from beryllium to frav1001, and confirm that it's in the frack-administration vlan [17:49:11] (PS1) Ejegg: Round off all the geo_codes to 4 digits [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/334158 (https://phabricator.wikimedia.org/T155677) [17:51:12] fr-tech I think that will really help fr-not-tech ^^^ [17:51:31] Basically no US addresses from December are de-dupe-able right now [17:52:03] because the geocoding is assigning new addresses lat and long with 4 digits of precision [17:52:19] while the existing ones got tagged with unnecessarily high precision [17:52:47] anyway, there's a potential code fix, but this is quick and safe and good for our needs [17:54:35] XenoRyet: are you in the middle of something, or do you have some time for code review? [17:55:10] Just catching up on emails from the vacation. I can set that aside for some CR though. [17:55:21] Let me take a look. [17:55:52] thanks! I can talk through the background if you want to hop on the -talk channel [17:56:47] Na, patch notes seem clear enough. I think I understand what happened. [17:57:20] cool. I'm going to file a bug over at the Civi issue tracker suggesting the code change [17:57:30] cool [18:00:32] fr-tech: All newspaper editorial writers ever do is come down from [18:00:32] the hills after the battle is over and shoot the wounded. [18:00:32] -- discuss. [18:08:22] Here's that bug: https://issues.civicrm.org/jira/browse/CRM-19932 [18:09:01] I'm leaning towards ignoring the geo_code fields on de-dupe, since they're supposed to be automatically calculated [18:09:32] I would lean that way as well. [18:09:42] fr-tech anyone have updates for scrum of scrums? [18:10:02] None here. [18:15:33] (CR) XenoRyet: [C: 2] Round off all the geo_codes to 4 digits [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/334158 (https://phabricator.wikimedia.org/T155677) (owner: Ejegg) [18:19:20] (Merged) jenkins-bot: Round off all the geo_codes to 4 digits [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/334158 (https://phabricator.wikimedia.org/T155677) (owner: Ejegg) [18:21:44] thank XenoRyet [18:26:36] fundraising-tech-ops: decommission beryllium.frack.eqiad.wmnet - https://phabricator.wikimedia.org/T147934#2969754 (Cmjohnson) p:Normal>Low [20:11:54] !log renabled dedupe job, disabled major gifts (one should be enough). Will investigate next error [20:11:57] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [20:16:48] eileen: I'm going to deploy this quick fix for dedupe merges blocked on geo_code mismatches: https://gerrit.wikimedia.org/r/334158 [20:17:07] I think we're not de-duping anything since the geo_code column type fix [20:17:28] oh! [20:18:39] ejegg: do you know how long the update command is likely to take - ie is it quick enough there won't be a replication lag. I see you have batched it [20:18:43] I filed something for core too, since the conflicts aren't displayed: https://issues.civicrm.org/jira/browse/CRM-19932 [20:19:12] eileen: not sure, but I'm hoping it will be OK since there are no joins [20:19:48] Jeff_Green: heads up, I'd like to deploy another civi db update [20:20:10] ejegg what kind of update? [20:20:24] it'll update all the address rows, but it's batched by 1,000,000 and doesn't involve any joins [20:20:27] https://gerrit.wikimedia.org/r/#/c/334158/1/sites/all/modules/wmf_civicrm/wmf_civicrm.install [20:20:48] batched by 1M sounds like replag [20:21:05] ah, what size do you suggest? [20:21:21] Oh, also, this is only affecting US addresses, I can limit this further [20:21:56] I think the fact it's indexed by primary key is OK - but it could take some minutes & monitoring emails might go out [20:22:03] (again) [20:22:09] ejegg I'm not entirely sure, try it on the dev instance first? [20:22:43] eileen: ohh wait, I see you did something similar in 7330 [20:23:04] were you seeing new ones coming in with 6 digits of precision? [20:23:09] let me check again [20:32:01] :-) [20:32:07] but the new ones with 3 digits before only have three digits after [20:32:44] so... maybe go ahead with a code change to ignore conflicts on the geo_code fields? [20:34:25] yeah - that seems fair - [20:34:35] why have they changed? [20:35:23] Fundraising Sprint Baudelaire Bowdlerizer, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Slow log in - looks like it's drupal cron - https://phabricator.wikimedia.org/T155084#2970280 (Eileenmcnaughton) [20:35:24] There was that type mismatch that gave things extraneous digits [20:35:51] then we rounded them off [20:35:54] Fundraising Sprint Baudelaire Bowdlerizer, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Slow log in - looks like it's drupal cron - https://phabricator.wikimedia.org/T155084#2932973 (Eileenmcnaughton) I pulled this in since I'm working on jenkins jobs now it's a good time to turn on cron again [20:36:10] but it looks like we didn't round them off as far as the source data [20:36:10] ok - but why only 3 after? Our rounding is doing that? [20:36:46] That may be in the source data, let me see [20:38:27] yep, the source data is 6 significant figures, so longitudes past 100 each way only get 3 decimal digits [20:39:15] ok - so we got it wrong last time [20:39:22] yeah, guess so [20:39:42] we should probably just get the right number this time - that rounding is wierd! [20:42:39] OK, I'll make the batches smaller and do different rounding for geo_code_2 [20:43:05] no harm batching them by 100,000 [20:53:26] ejegg: meeting? [20:55:25] ah shoot, sorry! [20:57:05] (PS1) Ejegg: Geocode updates: 6 sig figs, smaller batches [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/334187 (https://phabricator.wikimedia.org/T155677) [20:57:35] Fundraising Sprint Baudelaire Bowdlerizer, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Slow log in - looks like it's drupal cron - https://phabricator.wikimedia.org/T155084#2970340 (Eileenmcnaughton) I've just added a cron in jenkins. The setting may not be necessary with the cron on - I just... [21:06:18] Fundraising Sprint Baudelaire Bowdlerizer: CiviCRM dedupe jobs fail noisly if there is nothing to dedupe - https://phabricator.wikimedia.org/T156306#2970405 (Eileenmcnaughton) [21:14:03] internet issue - I think son-related [21:14:20] k, I'll run that new update on staging. Worked locally: https://gerrit.wikimedia.org/r/334187 [21:16:13] ejegg: that looks good - I'll pull it locally too to test it [21:18:16] thanks eileen [21:23:57] (PS1) Eileen: Early return when there are no contacts to dedupe [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/334198 [21:25:06] ^^ that will reduce dedupe noisyness [21:27:03] (CR) Ejegg: [C: 2] Early return when there are no contacts to dedupe [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/334198 (owner: Eileen) [21:30:43] (CR) Eileen: "Still reviewing - made a quick comment re the comment block" (1 comment) [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/334187 (https://phabricator.wikimedia.org/T155677) (owner: Ejegg) [21:30:45] (Merged) jenkins-bot: Early return when there are no contacts to dedupe [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/334198 (owner: Eileen) [21:32:18] ejegg: this is kinda annoying - there are actually 2 digit + 4 latitudes too [21:32:55] could we just change that table to be a DOUBLE like the other one & it should stay the same? [21:33:06] (PS2) Ejegg: Geocode updates: 6 sig figs, smaller batches [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/334187 (https://phabricator.wikimedia.org/T155677) [21:33:40] (CR) Ejegg: "PS2: rebased & added bug number in comment block" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/334187 (https://phabricator.wikimedia.org/T155677) (owner: Ejegg) [21:35:02] eileen: agreed that the data types should match [21:35:19] hmm - the actual table has 6 digits after the point - ie 40.922326 [21:35:35] eileen: wait, the wmf_zip_geo table does? [21:35:41] yes [21:35:52] but I think it messes with them on display [21:35:55] d'oh, I wonder what I was doing wrong locally [21:36:44] try this [21:36:45] select cast(`latitude` as decimal(8, 6)) FROm wmf_zip_geo [21:37:41] wow, that's nasty [21:38:42] err, it keeps adding digits if you ask it for more [21:39:15] yeah - we put it in using 6 but.... [21:39:18] eg decimal(12,10) gives 43.0058937073 [21:39:38] I think my head would prefer it if we converted those fields to decimals [21:39:48] yep, me too [21:40:04] I think if the wmf_zip_geo table is predictable to us then the address table can stay as it is [21:40:20] what about dropping the table & re-creating & populating it as a decimal table [21:40:44] (because I don't know i trust converting it) [21:41:09] huh, yeah, I guess that's the best way [21:41:36] also - it would mean we can update the 7310 update & then just run it again [21:41:44] yah [21:41:53] which, kind of feels like we aren't leaving a mistake for people to copy & paste later [21:41:58] (not that we would….) [21:42:17] :-) [21:42:31] oh yeah, there are those 6 digits in the source data [21:42:59] thanks! Will fix up that other update and revert the rounding [21:45:09] (PS1) Ejegg: Revert "Round off all the geo_codes to 4 digits" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/334200 [21:48:16] (CR) Eileen: [C: 2] "Approving this - not yet deployed & a different approach has been selected - death to FLOATS" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/334200 (owner: Ejegg) [21:52:22] (Merged) jenkins-bot: Revert "Round off all the geo_codes to 4 digits" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/334200 (owner: Ejegg) [21:58:29] (PS1) Ejegg: Better fix for lat/long woes [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/334204 (https://phabricator.wikimedia.org/T155677) [22:00:50] ok eileen, ^^ looks better [22:01:14] testing locally [22:03:14] (CR) jerkins-bot: [V: -1] Better fix for lat/long woes [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/334204 (https://phabricator.wikimedia.org/T155677) (owner: Ejegg) [22:05:34] d'oh, tests using munged data. [22:07:03] (PS2) Ejegg: Better fix for lat/long woes [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/334204 (https://phabricator.wikimedia.org/T155677) [22:08:18] k, that's better [22:08:46] ejegg: opening that long geocode update has frozen my computer - rebooting! [22:09:05] ah jeez, right, I always need to edit that one in vi [22:09:53] yeah... I shoulda left that in a CSV and built the insert dynamically [22:18:30] XenoRyet: got a better fix ready for that geocode thing: https://gerrit.wikimedia.org/r/334204 [22:18:46] turns out those numbers were all bogus because they were stored as floats [22:19:02] putting them in as decimals will avoid the bogosity [22:19:31] Cool, looking. [22:24:00] (CR) XenoRyet: [C: 2] Better fix for lat/long woes [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/334204 (https://phabricator.wikimedia.org/T155677) (owner: Ejegg) [22:25:23] (Abandoned) Ejegg: Geocode updates: 6 sig figs, smaller batches [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/334187 (https://phabricator.wikimedia.org/T155677) (owner: Ejegg) [22:25:54] plenty more stuff ripe for CR here: https://gerrit.wikimedia.org/r/#/q/owner:eeggleston%2540wikimedia.org+status:open [22:26:06] happy to explain any background [22:27:36] (Merged) jenkins-bot: Better fix for lat/long woes [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/334204 (https://phabricator.wikimedia.org/T155677) (owner: Ejegg) [22:30:19] (PS1) Ejegg: Merge branch 'master' into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/334212 [22:30:48] (CR) Eileen: "Looks solid to me & I tested locally & my test contact went from having a rounded version of the latitude to the full 6 digits in our upda" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/334204 (https://phabricator.wikimedia.org/T155677) (owner: Ejegg) [22:30:50] (CR) Ejegg: [C: 2] Merge branch 'master' into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/334212 (owner: Ejegg) [22:31:22] (PS2) Ejegg: Update libraries (no more Stomp!) [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/333827 [22:31:33] (Merged) jenkins-bot: Merge branch 'master' into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/334212 (owner: Ejegg) [22:33:19] ejegg: re this one - I'm confused seeing a .lock file update with no .json file update https://gerrit.wikimedia.org/r/#/c/333827/ [22:33:43] !log updated civicrm from af8d7359c6f860411281a97226d2fc859c1b7867 to cd058a02dc532980f20a1bcea30c07d57d4d1fcf [22:33:48] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [22:34:05] eileen: it's just version of the existing dependencies, so no .json file update was needed [22:34:24] the stomp lib was only being pulled in as a smashpig dependency, and that's now gone [22:34:28] ah like you re-ran it & that is what came out [22:35:16] yep, that's all that changed with composer update [22:35:29] !log paused civicrm dedupe and donation import jobs [22:35:34] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [22:36:08] k, running that geocoding fix [22:36:13] ejegg: so there are various minor version updates - eg minfraud goes up a point version - I take it we are normally pretty relaxed about those going out? [22:36:50] yeah, I took a look at those for the underlying DonationInterface update [22:37:19] this one brings all our composer-using projects in line as far as library versions [22:39:06] (CR) Eileen: [C: 2] "I had a quick chat to ejegg on IRC & he confirmed that this we just a re-run of composer (ie no json changes) to pick up upstream changes," [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/333827 (owner: Ejegg) [22:40:34] thanks! [22:40:50] Just to be safe, I did want to deploy that change on its own [22:41:23] so I just put up the few things that were in the backlog [22:43:24] (Merged) jenkins-bot: Update libraries (no more Stomp!) [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/333827 (owner: Ejegg) [22:46:03] (PS2) Ejegg: Remove Stomp, update other libraries [wikimedia/fundraising/crm/vendor] - https://gerrit.wikimedia.org/r/333829 [22:50:01] (CR) jerkins-bot: [V: -1] Remove Stomp, update other libraries [wikimedia/fundraising/crm/vendor] - https://gerrit.wikimedia.org/r/333829 (owner: Ejegg) [22:52:52] (CR) Ejegg: [V: 2 C: 2] Remove Stomp, update other libraries [wikimedia/fundraising/crm/vendor] - https://gerrit.wikimedia.org/r/333829 (owner: Ejegg) [22:54:55] phooey, did drush updb die between contact ID 16700000 and 16800000 ? [22:55:43] ugh, on free wireless, I should have nohup'd [22:56:44] huh, process is still listed [23:12:27] (PS1) Ejegg: Merge branch 'master' into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/334219 [23:16:20] ejegg: should kick off again fine [23:16:30] will re-run from start but.... [23:16:30] yep, re-running [23:16:53] still chugging along this time [23:17:29] (CR) Ejegg: [C: 2] Merge branch 'master' into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/334219 (owner: Ejegg) [23:17:36] (Merged) jenkins-bot: Merge branch 'master' into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/334219 (owner: Ejegg) [23:19:17] ok, seems to be done [23:19:22] turning the jobs back on [23:21:07] !log restarted civicrm donation queue consumer and dedupe jobs [23:21:11] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [23:30:30] Fundraising-Backlog: Review fr-tech data retention guidelines - https://phabricator.wikimedia.org/T156317#2970802 (Ejegg) [23:31:07] Fundraising-Backlog: Review fr-tech data retention guidelines - https://phabricator.wikimedia.org/T156317#2970815 (Ejegg) p:Triage>High [23:36:08] ok, let's try deploying those library updates [23:37:37] !log updated civicrm from cd058a02dc532980f20a1bcea30c07d57d4d1fcf to 6b6f5d68e20f268e1502b14c366cea78ff22dc96 [23:37:41] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [23:44:27] Fundraising Sprint Baudelaire Bowdlerizer, Fundraising Sprint Dirt Farming, Fundraising Sprint Elevator Maintenance 2016, Fundraising-Backlog, and 3 others: Store and update list of currenly working IDEAL banks - https://phabricator.wikimedia.org/T128692#2970851 (Ejegg) Working on a way to do thi... [23:48:00] (CR) Eileen: [C: 2] "per my comment I think the code was a bit more confusing that it needed to be -(not specific to this patch) but I agree that the contribut" (1 comment) [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/331823 (https://phabricator.wikimedia.org/T147873) (owner: Ejegg) [23:50:11] If someone can face reviewing this at some stage … https://gerrit.wikimedia.org/r/#/dashboard/self [23:51:03] it seems a bit confusing to read but the key part is that it creates a function to check & fix missing primary addresses - ie. where there are multiple emails for a contact but none are marked primary [23:51:19] (CR) Ejegg: Fix missing ct_id recovery (1 comment) [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/331823 (https://phabricator.wikimedia.org/T147873) (owner: Ejegg) [23:51:30] I want to delete out the blank emails from the DB - but doing that will leave some more non-primaries in the DB [23:51:49] (Merged) jenkins-bot: Fix missing ct_id recovery [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/331823 (https://phabricator.wikimedia.org/T147873) (owner: Ejegg) [23:51:58] (PS2) Ejegg: Add limit to sourceUrl on dedupefind results [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/298396 [23:54:25] (Abandoned) Ejegg: Add limit to sourceUrl on dedupefind results [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/298396 (owner: Ejegg) [23:55:22] eileen: ah yeah, the dataChecks extension? [23:56:09] yep - I know it's a bit of a drag to review because it's quite big [23:56:21] but, I was hoping it would be a good structure to add more to [23:56:34] heh, still getting into the groove of real civi extensions, too [23:56:40] :-) [23:57:10] one thing I'm wondering about is whether to use next upgrade window to add an index to civicrm_activity.activity_datetime field [23:57:35] I could run it after the main update so that it wouldn't drag it down too much [23:57:36] eileen: what queries will that help with? [23:58:01] yeah well any searches for activities created in a date range [23:58:28] do people do a lot of those? [23:59:06] not a lot - but if you wanted to find contacts merged in a period [23:59:29] k [23:59:38] I have no objection to the index [23:59:42] it's basically unusable now - you can see my tests here [23:59:43] https://issues.civicrm.org/jira/browse/CRM-19821