[00:37:05] Fundraising Sprint A series of unfortunate event handlers, Fundraising Sprint Bert and Ernie's Excellent Adventure, Fundraising Sprint Casino Royale With Cheese, Fundraising-Backlog, and 3 others: Reduce recurring TY emails - https://phabricator.wikimedia.org/T213209 (CCogdill_WMF) Hey there! Jus... [01:53:28] Fundraising Sprint A series of unfortunate event handlers, Fundraising Sprint Bert and Ernie's Excellent Adventure, Fundraising Sprint Casino Royale With Cheese, Fundraising-Backlog, and 3 others: Reduce recurring TY emails - https://phabricator.wikimedia.org/T213209 (Ejegg) Looks like the Italia... [01:58:14] Fundraising Sprint A series of unfortunate event handlers, Fundraising Sprint Bert and Ernie's Excellent Adventure, Fundraising Sprint Casino Royale With Cheese, Fundraising-Backlog, and 3 others: Reduce recurring TY emails - https://phabricator.wikimedia.org/T213209 (CCogdill_WMF) I think it’s o... [02:01:21] Fundraising Sprint Casino Royale With Cheese, Fundraising-Backlog, Patch-For-Review: Tag removal triggers unrestricted dedupe query - https://phabricator.wikimedia.org/T216057 (Ejegg) @NNichols, @Eileenmcnaughton found a fix for this, and it's now deployed. You should now be able to delete tags witho... [04:15:23] Fundraising Sprint Casino Royale With Cheese, Fundraising-Backlog, Patch-For-Review: Tag removal triggers unrestricted dedupe query - https://phabricator.wikimedia.org/T216057 (Eileenmcnaughton) Upstream PR https://github.com/civicrm/civicrm-core/pull/13606 ( I did a refactor first which is already m... [13:57:09] mornin Jeff_Green [13:57:20] hey ejegg, how's it going? [13:57:25] pretty good! [13:57:53] any luck with the mystery logs? [13:58:14] Jeff_Green: so, it seems like it's an issue with sessions! [13:58:32] We don't get the log lines I was expecting because each page load starts a new session [13:59:04] I see the second page load (POSTing back the donor details) sending a payments_session cookie [13:59:21] and the server just sends another Set-Cookie header with a different payments_session value [13:59:34] ah, interesting, so was the whole issue just the IP whitelist and the logging was a red herring? [13:59:57] I /think/ so [14:00:04] cool [14:00:24] Also, since I was looking for log lines by ct_id, I wasn't finding the ones from the previous page load, since that's stored in session too [14:00:47] makes sense [14:00:47] But I'm not sure how to proceed with debugging the session [14:01:02] Can we do something to convince ourselves apache is seeing the cookies? [14:01:11] thinking... [14:01:43] So this problem only seems to occur on 2003, not 1004 [14:02:13] ok [14:02:35] I believe nginx can log cookies of you specify the name of the cookie to log [14:02:58] apache can do it too [14:03:04] that would be useful [14:03:43] lemme experiment with it a bit and see what it looks like [14:04:03] cool, thanks [14:33:23] ejegg: ok I think it's working [14:33:41] i'll set you up with an account on payments1003, they're ending up in access logs [14:33:46] err 2003 I mean [14:44:17] thanks! [14:44:23] gotta run for now, back soon-ish [18:12:52] (CR) Ejegg: [C: -1] "Looks like this should work! Inline comments suggest a way to maybe do it more efficiently, and there's a bit of whitespace cleanup needed" (4 comments) [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/490666 (https://phabricator.wikimedia.org/T213209) (owner: Cstone) [19:17:03] https://theconversation.com/no-wikipedia-didnt-get-actress-olivia-colmans-birthdate-wrong-111848 I watched that movie last night. what a bizarre story! [20:06:34] (PS2) 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) [22:21:23] XenoRyet|ish: did you get an account on 2003 too? are those cookies getting through to apache? [22:29:46] Fundraising-Backlog: Silverpop import processed twice - https://phabricator.wikimedia.org/T162197 (CCogdill_WMF) Open→Invalid Out of date, closing! [22:35:33] No, I don't have an account on 2003 yet. Honestly Marek's been a handful today and I'm not getting much of anything done. [22:35:42] Fundraising-Backlog: Re-add fields to Silverpop export - https://phabricator.wikimedia.org/T170972 (CCogdill_WMF) p:Normal→High Hi, I'm changing this task to High priority because the topic of increased email segmentation has been brought up numerous times by Lisa and other managers as a way for us t... [22:35:58] (PS6) Jgleeson: WIP: civi wmffraud fredge report [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/482672 (https://phabricator.wikimedia.org/T199268) [22:38:58] (PS7) Jgleeson: WIP: civi wmffraud fredge report [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/482672 (https://phabricator.wikimedia.org/T199268) [22:39:07] have a great weekend fr-tech ! [22:39:59] Fundraising-Backlog, FR-Email: Make Silverpop export leaner - https://phabricator.wikimedia.org/T173538 (CCogdill_WMF) [22:40:36] Gotta run out for a bit, be back in a while [22:40:59] Fundraising-Backlog, FR-Email: Make Silverpop export leaner - https://phabricator.wikimedia.org/T173538 (CCogdill_WMF) Hey there, sorry I'm just coming back to this task now! I just modified the task description to make the nouns clearer--I think you all thought I was talking about the opposite end of th... [22:42:13] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Epic, FR-Email: Reflect all undeliverables via Silverpop in CiviCRM - https://phabricator.wikimedia.org/T161761 (CCogdill_WMF) Just making sure--is there anything else you need on this task? [22:44:48] Fundraising-Backlog: Record opt-in on payment attempts - https://phabricator.wikimedia.org/T216293 (CCogdill_WMF) [22:45:34] Fundraising-Backlog: Record opt-in on payment attempts - https://phabricator.wikimedia.org/T216293 (CCogdill_WMF) p:Triage→High [22:46:00] Fundraising-Backlog: Record opt-in on payment attempts - https://phabricator.wikimedia.org/T216293 (CCogdill_WMF) Adding a few potentially interested parties: @Pcoombe @spatton @MBeat33 [23:02:48] Fundraising-Backlog: Re-add fields to Silverpop export - https://phabricator.wikimedia.org/T170972 (DStrine) [23:02:50] Fundraising-Backlog: Add field data back into Silverpop export - https://phabricator.wikimedia.org/T105254 (DStrine) [23:04:28] Fundraising-Backlog: Re-add fields to Silverpop export - https://phabricator.wikimedia.org/T170972 (DStrine) I closed T105254 and moved this back to Sprint+1. We'll look at it first thing next week. [23:10:39] Fundraising-Backlog: Re-add fields to Silverpop export - https://phabricator.wikimedia.org/T170972 (CCogdill_WMF) Awesome, thanks! [23:31:09] cstone: do you feel like adding a unit test for that recurring no_thank_you patch? [23:31:40] sure where would it go? [23:32:00] let's see, probably in the wmf_civicrm tests? [23:33:09] That wmf_civicrm/tests/phpunit/RecurringTest.php file looks like a good place [23:33:57] so, the 'createTestContact' function you can see used in testGetGatewaySubscription [23:34:15] is handy, because it'll make sure that contact is cleaned up in the tearDown [23:34:32] ok cool [23:35:16] awesome! [23:35:42] I'm testing locally and it looks good [23:36:08] but since the chat on the ticket suggests there are some text changes we need to deploy before we can put this change on prod [23:36:17] we might as well get the unit test coverage in there [23:38:47] yeah is that text they are talking about hard coded somewhere then? [23:40:48] The thank you letter has a canonical wiki page, where the volunteer translators can use the translatewiki infrastructure to give us versions in different languages: [23:41:11] https://meta.wikimedia.org/wiki/Fundraising/Translation/Thank_you_email [23:41:48] then when fr-not-tech tells us there are updates, we use a weird drush script [23:42:15] ok and i found a folder of templates in the thank_you module, they end up in there? [23:42:32] https://github.com/wikimedia/wikimedia-fundraising-crm/blob/master/sites/all/modules/thank_you/make_thank_you.drush.inc [23:42:44] yep yep, that's what the drush script does [23:43:05] ok that makes sense [23:43:08] really kinda gnarly - uses regexes to translate from wikitext to a twig template [23:43:41] but it's what we have till we make some kind of connector from crm / drupal content to translatewiki [23:44:06] then I think there are a couple messages in the donatewiki (and maybe paymentswiki) interfaces [23:44:53] the paymentswiki ones, and some of the ones used on donatewiki, are in json files inside this folder in DonationInterface: [23:45:07] https://github.com/wikimedia/mediawiki-extensions-DonationInterface/tree/master/gateway_common/i18n/interface [23:45:47] so when we need to change them, we just change en.json (unless we're feeling particularly fluent in a foreign langauge we need right away) [23:45:51] and check that in [23:46:21] there are bots that watch for i18n message changes and flag those messages as needing translation at https://translatewiki.net/ [23:46:31] Then the awesome volunteers get to work [23:46:56] yeah this is cool all the translations [23:47:04] and the i18n-bot commits their updates back to our repo on a regular basis [23:47:50] there's one special json file in each dir: qqq.json [23:48:30] instead of the messages in language qqq, each message key's value is a description of how that message is used, to give the translators some context [23:48:56] so every time we add or remove a message in en.json, we need to do the same in qqq.json to keep it up to date [23:49:01] ah nice [23:49:41] yeah! [23:49:42] I was trying to translate at a previous job and could really have used a qqq.json [23:51:29] the cool thing is that it might not be too hard technically to make the connector from drupal/civi to translatewiki. They support a bunch of different ways of translating things, not just json and wikis. [23:51:41] The trickiest part there would be access control, I guess