[00:44:13] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: New Citibank import - https://phabricator.wikimedia.org/T217390 (LeanneS) [03:30:20] (CR) Krinkle: [C: +1] "This will save bytes on all page views on all wikis by removing a key from the "startup" payload. Once landed, could this be backported?" [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/485877 (owner: Ejegg) [06:37:34] PROBLEM - check_puppetrun on payments1004 is CRITICAL: CRITICAL: Puppet has 3 failures. Last run 5 minutes ago with 3 failures. Failed resources (up to 3 shown): Package[php7.0-cli],Package[php7.0-cgi],Package[php7.0] [06:42:26] PROBLEM - check_puppetrun on payments1004 is CRITICAL: CRITICAL: Puppet has 3 failures. Last run 10 minutes ago with 3 failures. Failed resources (up to 3 shown): Package[php7.0-cli],Package[php7.0-cgi],Package[php7.0] [06:47:28] RECOVERY - check_puppetrun on payments1004 is OK: OK: Puppet is currently enabled, last run 39 seconds ago with 0 failures [06:52:32] PROBLEM - check_puppetrun on payments2003 is CRITICAL: CRITICAL: Puppet has 2 failures. Last run 6 minutes ago with 2 failures. Failed resources (up to 3 shown): Package[php7.0-cgi],Package[php7.0] [06:57:38] PROBLEM - check_puppetrun on payments2003 is CRITICAL: CRITICAL: Puppet has 2 failures. Last run 11 minutes ago with 2 failures. Failed resources (up to 3 shown): Package[php7.0-cgi],Package[php7.0] [07:02:32] RECOVERY - check_puppetrun on payments2003 is OK: OK: Puppet is currently enabled, last run 48 seconds ago with 0 failures [15:27:11] (PS5) AndyRussG: Create CampaignChange hook [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/493459 (https://phabricator.wikimedia.org/T208511) [15:35:46] hi fr-tech! [15:36:02] ejegg hello and buen día [15:36:22] ¿qué Pachuca por Toluca? [15:37:01] ¿qué transa? [15:38:02] ¡Hasta la victoria... duele! [15:38:36] fundraising-tech-ops: cronspam: file size changed while zipping - https://phabricator.wikimedia.org/T217413 (cwdent) [15:42:57] jeje [15:43:36] AndyRussG: I'm trying to test the FundraisingTranslateWorkflow fix, but I'm not sure exactly how to trigger that code [15:43:52] ejegg: which patch is that? [15:43:52] Do you know where one should go to promote translations from one state to another? [15:43:59] yes [15:44:13] https://gerrit.wikimedia.org/r/486345 [15:45:54] Odd it's not working locally right now [15:46:08] should be: Special:Translate?group=Centralnotice-tgroup-TranslateTest4&task=view [15:46:23] replace TranslateTest4 with the name of the banner with the message [15:46:31] and then click on a language other than the interface language [15:46:59] But this isn't for banners, right? [15:47:41] Right, it's for specific patterns of page names [15:47:58] I don't know what group the ty e-mail messages are in [15:48:09] Maybe poke about on Special:Translate? [15:48:15] https://meta.wikimedia.org/w/index.php?title=Fundraising/Translation/Thank_you_email_20171019&action=edit [15:48:34] yeah, been poking about, with some breakpoints in the spots where the new hook is called [15:48:39] but so far nothing's hitting it [15:48:47] Hmmm [15:49:08] so I've got a page locally with a stuff section in it [15:49:12] Normally, first yout translate a message [15:49:16] to a language other than English [15:49:19] and a tag above [15:49:29] then it gains the draft state [15:49:35] yeah, I have some banner messages translated into spanish [15:49:41] but they seem to be in proofreading [15:49:45] and from there, if you have the correct rights, you should be able to promote it to "published" [15:49:49] so I'm trying to set up a page to translate [15:50:06] but all I get is a header that says 'This page contains changes which are not marked for translation' [15:50:50] Hmmm [15:51:16] Does it work on the beta cluster? [15:51:23] https://meta.wikimedia.beta.wmflabs.org/wiki/Special:Translate [15:51:57] You know about the drop-down kinda below the headers that sets the status of the translation, right? [15:53:19] yep yep [15:53:31] that's what I assume this change affects [15:53:51] but I'm surprised to see the breakpoints not being hit on that page [15:53:55] Hmmm K I'll take a peek a bit later today? [15:54:03] cool [15:54:07] thanks! [15:54:16] sorry I don't have much insight [15:54:30] thank u for working on it! [15:54:55] yay tech-debt reduction [16:14:22] (PS4) Ejegg: Rename and improve method for processes after campaign change [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/493457 (https://phabricator.wikimedia.org/T208511) (owner: AndyRussG) [16:15:04] (CR) Ejegg: [C: +2] "Looks good! Slight reduction in db calls, removal of unused return val, set up for doing more stuff in the future." [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/493457 (https://phabricator.wikimedia.org/T208511) (owner: AndyRussG) [16:16:44] ejegg: ^ thanks! [16:16:50] :) [16:17:13] ejegg: I'm gonna mark the follow-on patch to that as WIP [16:17:43] For emitting the event to the eventbus (which will handle the new hook created) I think I'll omit all the fields we don't actually need just now [16:18:46] but yeah let's not merge that one until I've got the events emitting and consuming fully [16:18:53] ok, cool [16:18:55] just in case there are tweaks [16:19:03] I was wondering a couple things on that following patch [16:19:21] btw the first patch on that ticket is totally ready for review, though... it's the new CN API for current campaigns [16:19:33] mmmm? [16:19:35] 1) did you want to make it possible to change the log entry before writing it? If so, maybe move the $log = [... block below the hook [16:20:15] 2) Is there some standard for documenting the creation of a new hook? I see there's a section in extension.json to register the hooks we use, but nothing about hooks we create [16:20:42] (PS6) AndyRussG: Create CampaignChange hook [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/493459 (https://phabricator.wikimedia.org/T208511) [16:20:49] (Merged) jenkins-bot: Rename and improve method for processes after campaign change [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/493457 (https://phabricator.wikimedia.org/T208511) (owner: AndyRussG) [16:21:06] ok, looking at the API for current campaigns [16:21:15] will paste those questions on the WIP patch [16:21:57] ejegg: ah ok cool [16:22:23] (CR) Ejegg: "Looks good so far. 2 questions:" [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/493459 (https://phabricator.wikimedia.org/T208511) (owner: AndyRussG) [16:22:24] yea there isn't much documentation, other than https://www.mediawiki.org/wiki/Extension_hook_registry [16:23:23] oh wow, it's literally just a page on mw.o ? [16:23:43] ejegg: yep, as far as I can tell [16:24:03] I grepped about in other extensions that implement hooks [16:24:05] * ejegg shrugs [16:24:15] and found that all they do is call the hook handlers with the name of their hook [16:24:35] I think the hook itself is also to be documented somewhere thereabouts [16:24:42] though I think we could also add it to the readme [16:24:54] ah yeah, also a good spot [16:25:36] ejegg: ah now I understand your first question. No, the hook handler shouldn't be able to change the log entry [16:25:50] Really it's just so it can be handled by the eventbus extension [16:25:52] ok, got it, just a notification [16:26:18] yeah [16:26:26] the bootiful doc fo this is here: https://wikitech.wikimedia.org/wiki/EventBus [16:26:58] the only point for now is just to be able to know for sure which banners are live [16:27:28] mmmmm twice-weekly espresso [16:28:31] (CR) jenkins-bot: Rename and improve method for processes after campaign change [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/493457 (https://phabricator.wikimedia.org/T208511) (owner: AndyRussG) [16:32:01] AndyRussG: looks like the only V-1 issue on https://gerrit.wikimedia.org/r/492353 is a missing newline at end of file [16:33:27] ah ooops [16:33:30] K lemme fix that [16:33:56] we should just take an entire year and clean up aaaaaaaaaaaaall the tech debt [16:34:38] make all the code pretty [16:35:53] (quick, change all the quarterly goals, before anyone notices) [16:37:33] hehe, definitely! [16:38:34] manifesto of the anarchist pretty code rebellion [16:45:05] aka "the pretty-codies" [16:46:30] (PS3) AndyRussG: Add API for active campaigns and banners [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/492353 (https://phabricator.wikimedia.org/T208511) [16:47:58] ^ that otta fix it [16:48:11] (the CI failure, not all the code debt) [16:49:11] (CR) jerkins-bot: [V: -1] Add API for active campaigns and banners [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/492353 (https://phabricator.wikimedia.org/T208511) (owner: AndyRussG) [16:50:21] Hmmm nope https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-hhvm-docker/37380/console [16:50:54] didn't fix either one [16:53:08] AndyRussG: any reason you didn't want to use the existing Campaign::getCampaigns function? Looks like that can filter by currently active too [16:53:17] wanted to make it more lightweight? [16:55:10] ejegg: aaaaaaaaaaaargh no I just missed it [16:55:45] ejegg: however, looking at it, it doesn't give out banners, right? [16:56:10] basically I followed the pattern for the ChoiceData query [16:56:13] ah, looks like nope [16:56:34] back in a bit [16:59:25] ejegg in truth the actual query done in the API would be better placed in the Campaign class [16:59:48] I should at least rework that, or maybe add banners to the getCampaigns function [17:12:02] actually on second thought let's just leave it as is for now [19:16:44] ejegg interestingly Campaign::getCampaigns() has no callers [19:17:52] I guess now I feel a bit less bad about not having seen or remembered it. I should have looked though, for sure [19:18:24] proposal: I'll take the private getActiveCampaigns() out of the API class and make it a static method of Campaigns [19:18:39] and mark with a TODO to merge the two methods one day [19:18:40] make sense? [19:36:58] AndyRussG|ish: yeah, definitely, sounds good [19:52:47] Fundraising-Backlog, Code-Stewardship-Reviews, MediaWiki-extensions-CentralNotice, QuickSurveys, and 5 others: Consolidate QuickSurveys into CentralNotice - https://phabricator.wikimedia.org/T217374 (Niedzielski) [19:53:01] Fundraising-Backlog, Code-Stewardship-Reviews, MediaWiki-extensions-CentralNotice, QuickSurveys, and 5 others: Consolidate QuickSurveys into CentralNotice - https://phabricator.wikimedia.org/T217374 (Niedzielski) @jdlrobson, thanks for surfacing this. I think it's generally best to use the first... [19:56:22] oh darn, more omnimail unsubscribe failmail [19:57:18] ooh, target_contact_id is not a valid integer [19:57:20] weird [20:14:21] huh, not seeing anything off in the db [20:41:24] (PS1) Ejegg: Filter out non-integer contact_id rows [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/493759 [20:41:29] aha, there it is [20:41:46] fr-tech anyone around to review that ^^^ ? [20:45:22] !log turned off fundraising omnimail process unsubscribes job [20:45:24] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [20:45:56] (CR) jerkins-bot: [V: -1] Filter out non-integer contact_id rows [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/493759 (owner: Ejegg) [20:48:49] (CR) Ejegg: [C: -1] "The order of operations looks good now, we just need different variable names for that inner loop." (1 comment) [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/493324 (owner: Eileen) [20:53:57] Fundraising Sprint Da Vinci Coder, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Some users not able to use quick search - https://phabricator.wikimedia.org/T216553 (Eileenmcnaughton) Open→Resolved [20:56:33] (PS2) Ejegg: Filter out non-numeric contact_id rows [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/493759 [22:25:49] (PS3) Cstone: Add in check to set no_thank_you field for recurring payments after the first recurring payment. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/490666 (https://phabricator.wikimedia.org/T213209)