[00:02:22] awight apparently this is their normal template except they added in country and phone, which we need [00:02:54] so sara sent them what we typically use in january or so, and then they were all "Sweet, this is the same as what we do but we don't have country and phone" [00:03:23] atgo: that's... very unlikely. It's missing all kinds of stuff such as transaction ID, exactly matches our existing templates, and I can clearly see one field they added, which has crazy contents. [00:03:32] sigh [00:03:33] ok [00:03:50] for example, the template has "Restrictions" and "Direct Mail Appeal" [00:03:54] well yeah [00:03:57] that is defintiely ours. [00:04:21] I feel like the template we have is someone's notes from trying to line up their auditing file with our existing stuff. [00:04:27] I asked in email, but no answers yet. [00:04:34] I think I flooded the conversation :-/ [00:04:44] yeah... [00:05:06] so. ok. do you have a punchlist of questions/areas of confusion anywhere? [00:05:22] :( sure, I can summarize my emails [00:06:24] atgo: actually. It doesn't even make sense to do that, cos there are questions totally contingent on other questions. need conversation. [00:06:45] ahh ok [00:07:02] aargh, /me creates nested questions document, https://wikitech.wikimedia.org/wiki/Fundraising/tech/Coinbase [00:07:14] it will be like a choose yr own adventure [00:08:18] YAYYY [00:10:22] atgo: Good news! All the GC errors I was getting for SEPA have changed. [00:10:37] ha changed.. that's... interesting [00:10:51] awight think it might be better to move the CB meeting tomorrow until wednesday? [00:10:53] Now, instead of indicating a bad IBAN, they indicate that the payment product wasn't enabled on our staging account. [00:10:59] YAY [00:11:05] I LOVE EVERYTHING. [00:11:05] atgo: I'm quite happy to just read the minutes [00:11:11] yeah but you have the most questions... [00:11:23] K4-713 PROGRESS [00:11:26] atgo: oh, soon enuf you will have those questions :D [00:11:33] alright :P [00:11:40] K4-713: is it too late to amend git history to delete the feature? [00:11:55] Which one? And no. [00:12:04] It's never too late to destroy. [00:12:19] atgo: it would be awesome to get a first draft of answers, at least, then I can continue to threadflood on Wednesday. [00:12:49] ok. let's try to consolidate to 1 thread if we can :) [00:14:42] * K4-713 still can't believe current staging account issue [00:15:09] I mean, we... how can it... when they... [00:15:15] * K4-713 sputters [00:15:53] Also, I want to know why I can get information like "invalid IBAN" back from a thing I'm not even enabled to use. [00:16:22] K4-713: they're scared that you're getting close to the answers [00:16:37] follow the documentation! [00:16:43] ...or don't. It's usually wrong. [00:19:57] K4-713 on the standup you mentioned that you saw a shop link in some TY email somewhere... is that a real thing? [00:20:01] or did i make it up in my memory [00:20:18] It was, but it was more like a dream I had about an email that initially got sent a month ago. [00:20:28] atgo: okay i have dumped my questions to the wiki page above [00:20:40] atgo: please lemme know if I should clarify anything [00:21:25] ok. i'll try to look at it today [00:21:32] K4-713 alright :) [00:21:47] K4-713 so.. we're good on that one? [00:21:54] Anybody know what today's day of the year is? Like, between 1 and 365? [00:21:58] atgo: Yes. [00:22:06] K4-713: omg [00:22:26] Huh. [00:22:27] http://www.epochconverter.com/epoch/daynumbers.php [00:22:28] K4-713: http://www.epochconverter.com/epoch/daynumbers.php [00:22:29] ha [00:22:30] HAHA [00:22:43] 1 2 3 4 5 6 7 8 9 10 [00:22:43] jin [00:22:43] ...x [00:22:47] damn. [00:22:54] async jinx [00:23:07] Do I still get to talk on IRC, or is somebody going to punch me? [00:23:20] >_> [00:23:21] virtual punch. not so bad. [00:23:21] <_< [00:23:50] Well, this sucks too. [00:24:04] atgo: Apparently they never restarted sending us WX samples either. [00:24:22] Did everybody at GC perish in a tragic fireworks accident over the weekend? [00:24:44] K4-713 i thought we were kind of paused on the WX for a bit? [00:24:46] I was able to determine that we are, in fact, still getting production WR1 files. [00:25:08] atgo: We are. But seeing as how I was paused to do SEPA, and our sandbox account isn't enabled for it yet... [00:25:23] yeah but i thought this was from their end [00:25:25] ...I thought maybe I could keep that balloon in the air while I was waiting for somebody to toggle something. [00:25:26] that we were on hold [00:25:29] yeah... [00:25:32] they... i don't know. [00:25:36] They told me on the last call, that they had started it up again. [00:25:43] I believed them. [00:25:59] K4-713: aAAUGH [00:26:13] You know what? I think I give up for today. [00:26:33] K4-713 oh... i must've spaced on that [00:26:34] K4-713: that is completely reasonable [00:26:39] +2 [00:26:44] if that's a thing [00:27:02] I should send them another email first, though. [00:27:17] "Why must you turn my office into a house of lies?" [00:27:21] ha! [00:28:24] ...oh wait. "We made some tweaks, would you mind retrying in 15-20 minutes (after our meta update has run)?" [00:33:43] ?!? [00:33:46] Now I get "NOT ALLOWED FOR BOARDING METHOD 4" [00:34:02] ...um. [00:39:23] you're in the wrong boarding group K4-713 [00:39:26] look at your boarding pass. [00:39:43] I thought I paid for extra legroom! ...in my xml. [00:39:57] Worth every penny. [00:41:39] atgo: Ehrm. Have we, by any chance, asked them if any other clients are going through this right now? [00:41:50] i haven't. [00:41:55] but i assume they are [00:42:00] ... [00:42:03] wait yeah, they've said they have other clients going through it [00:42:07] You know, I'd have thought that, too... [00:42:10] remember when we were like "we want to do WX" [00:42:20] they were like "no but.. everyone else is doing SEPA" [00:42:24] I remember they said we *should* all do SEPA DD. [00:42:28] and we were like "that's backwards" [00:42:58] I don't remember them saying that they had convinced anyone, or that they had made progress or anything. [00:43:42] Also: Boarding _method_? [00:43:46] Usually I go in the door. [00:44:07] I fully accept that I may have been doing it wrong. [00:44:28] yeah i don't either [00:45:02] I guess there's that one you see in action movies sometimes where you cling tenaciously to the landing gear. [00:45:15] ...but seriously, I'm out for today. [00:45:44] Brain can't brain further. [00:55:58] (CR) Ejegg: [C: 2] "Yep, checkAll is definitely the one that exists" [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/142168 (owner: Awight) [00:56:00] (CR) jenkins-bot: [V: -1] typo causing whitescreen [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/142168 (owner: Awight) [08:20:11] (CR) Siebrand: "Happened a while ago..." [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/23614 (owner: Siebrand) [16:47:15] Good morning K4, pizzzacat, atgomez [16:47:36] good morning ejegg [16:57:01] Good morning, ejegg! [16:57:15] ...I really should set this thing up to highlight/alert on just "K4". [16:57:40] * K4-713 stares at pigdin settings for a while [16:57:46] oh whoops, I assumed you had that based on your quick responses to it earlier... [16:57:49] Er. Also Pidgin. [16:57:57] Guess you're just really on top of IRC [16:58:03] Nah, I was just being creepy. :D [17:03:18] ejegg: Is there anything that I could review for you this morning? I actually have some relatively free time to do, you know... work. [17:03:37] want to take a look at the GC CVV stuff? [17:03:41] Yep! [17:03:47] thanks! [17:26:24] ejegg: Dang, this orphan vs not-orphan cc confirmation code always turns my brain inside out. [17:26:47] hrm? [17:27:10] The whole transactionConfirm_CreditCard function, really. [17:27:19] I have to go cross-eyed and look at it sideways. [17:27:44] ...usually indicates a problem, which is, you know, my fault. [17:27:45] might be easier to deal with orphans and non-orphans in different places, i guess [17:28:03] You're probably right. [17:28:09] But, that's... later. [17:28:23] I'd like to get more orphan-related unit tests in there before we try that refactor. [17:28:36] so if there is anything on the QS, we're dealing with a live person coming back from GC, right? [17:28:42] Aye. [17:29:47] i split the addme array into one for qs and one for xml, so we can compare [17:30:02] When we get the time to rip the thing out, there is this relatively new member variable that tells us if the parent object was instantiated in batch mode. That might help with the part where I go cross-eyed. [17:30:20] ooh, that does sound useful [17:30:55] ...and it would help for when we actually get enough relative slack time to actually abstract this business out into a non-mw dependent library. [17:31:19] Did we manage to talk to you about the long-term roadmap? [17:31:29] yeah, sounds very cool [17:31:38] It's only long-term because our time isn't really ours. [17:31:41] like, being able to share this with other nonprofits [17:32:07] If we did have our own time, we'd drop everything and work on just doing that for a while. [17:32:36] hmm, gc adapter line 1139 [17:32:43] Every once in a while, though, there is some well-known target of opportunity that we can take down in the normal course of our work, that will make the final decoupling a liiiiittle easier... [17:32:59] i'll keep an eye out for those [17:33:07] So, you know, it's good to talk about where we're trying to go. Then we can sneak up on it. :) [17:33:32] Ah, my checkout is all over the place with the SEPA stuff.... hang on. [17:33:55] just the online diff might be enough [17:35:07] i'm wondering if we want to repeat the antifraudhooks even for non-orphans [17:36:07] my thought was this: for non-orphans, we already ran antifraud hooks on the cvv result from the QS [17:36:14] yep [17:36:25] and now if the XML has anything different, we're setting the problem flag [17:36:36] * K4-713 nods [17:36:58] since cvv is an insta-fail hook, there's no need to re-run [17:38:06] on the other hand, if it had a lower weight, we might get a different fraud total by re-running after the rest of the XML info is added [17:38:25] ...er, wait, we already run those hooks on the XML stuff someplace [17:38:44] I think any change is sufficient reason to give the whole thing the boot, even if it's lower according to GC. [17:39:12] Another silly idea I had: There should be a class of bad behavior, that gets your IP address blocked for a while. [17:39:16] We can do that with memcache. [17:39:29] (already use it to work out the IP veolcity filters) [17:39:50] like screwing with QS fraud parameters [17:39:56] Exactly. [17:40:09] If we catch you doing that, you're done. I think that's reasonable. [17:40:13] yeah [17:40:30] ...but, the timing on that is going to have to be... sort of like the velocity filters. [17:40:55] oh? [17:40:56] Public libraries and large offices complicate these things. [17:41:06] ah, yeah [17:41:21] So, we catch it happening, and the IP address gets blocked for some amount of time. [17:41:34] if you're any kinda competent, you'll be doing this from somebody else's IPs [17:41:40] Yep. [17:41:59] So, usually we have a local setting that defines the TTL for that piece of data. [17:42:16] We can adjust that up or down depending on what we're being hit with today. [17:42:21] hmm, where exactly are we running those hooks on the XML stuff for non-orphans? [17:42:46] GET_STATUS pre...checkthingy? [17:43:06] * K4-713 frowns [17:43:33] pre_process_get_orderstatus(). [17:44:05] Im loverO:-)O:-)O:-) [17:44:11] but isn't that only before we have the XML stuff? [17:44:56] It is, yes. So, we'd have to fail the transaction specially. You could add a post_process_get_orderstatus [17:45:20] In the parent object, there's some voodoo that just calls these functions if they exist. [17:46:00] 'pre_process_' and 'post_process_' . lcase($this->transaction) [17:46:06] ...or something. [17:46:24] hmm [17:46:32] It's before and after the curl. [17:47:52] so right now, for live GC transactions, we never run our antifraud hooks on what we get back from GET_ORDERSTATUS... [17:48:06] ejegg: Nope. Don't have to. [17:48:15] We already have all we need to do all our stuff + maxmind. [17:48:42] The only thing we'd detect after GET_ORDERSTATUS that we don't already know, is the mismatch. [17:49:03] ...and we also pay for Maxmind queries. [17:49:30] Pretty much just assume that every time we talk to anything that isn't us, it costs us. [17:49:47] yeah [17:50:38] ah, right, they'll give us a NOK and an error code for anything else that would trip our detectors anyway [17:50:57] yep. Actually, if they give us an error, the transaction is already dead anyway. [17:51:16] OK, seems good to me. [17:51:20] ...I will *never* know why they can't pass that along in the querystring, or a post. [17:51:28] Grumble grumble. [17:51:36] ...but I guess this is safer anyway. [17:51:45] yeah [17:56:01] (CR) Katie Horn: [C: 2] GC: Check XML for CVV result, use blanks if missing (1 comment) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/143764 (owner: Ejegg) [17:56:18] thanks! [17:56:43] ejegg: Aw, dependencies. [17:56:54] K4-713 yeah, depends on the gatewway globals cache change [17:57:03] So, I'm actually sort of curious as to why you changed the way that works. [17:57:19] So I could write unit tests without screwing up the globals for all the other tests [17:57:43] Hum. I could swear I already sorted that out, but if it wasn't working, then I guess not. [17:57:49] on my first pass, suddenly some of the fraud filter tests started bombing out [17:58:03] I couldn't see any other way to reset a function-local static var [17:58:43] Yeah, there... wouldn't be. Okay, I get it now. Makes sense. [17:59:10] (does make me wonder how I was not having this problem with other tests, but I probably got weird) [18:00:42] K4-713: how familiar are you with CentralNotice innards? [18:01:03] ejegg: Well, let me put it this way... [18:01:05] * K4-713 hidea [18:01:09] heh [18:01:10] *hides [18:01:17] what do you need to know? [18:01:49] are there usually banners to fill all the slots? [18:02:07] Oh, that I do know. Yes, even if some are blank. [18:02:19] I know that sounds like "no". [18:02:25] But it isn't. [18:02:26] I just have one configured right now, with traffic limit set to 20% [18:02:54] if you have just one banner set active with a limit set; it shouldn't use all the slots [18:02:55] ...locally? [18:03:01] So 80% of slots are just empty, and I usually get the insertBanner(false /* due to exception */ ) [18:03:14] that sounds correct [18:03:20] the exception being that there is no banner [18:03:23] ok, just checking that's normal [18:03:34] *nods* with a limit set [18:03:48] if you had another banner in there with a limit of 80% or no limit all slots would be filled [18:04:25] * K4-713 looks sad, loses 50 points for gryffindor [18:04:50] ejegg: what are you up to in CN? [18:04:58] Do we need to give you something more interesting to do? [18:05:05] Because we have some thoughts there. [18:05:25] taking a look at the cookie change since Adam got busy with the hot new payment method [18:05:32] aaaaaaaaaaaaaaaaaaha. [18:05:37] Carry on, then. [18:07:13] ejegg, reading that card; I'm not sure adam fully understood the intent [18:07:20] we need to expire all old hide cookies [18:07:36] oh, we're getting rid of those? [18:07:46] *nods* megan wants to start with a fresh plate [18:08:08] Do we want to convert the old hide till expire cookies to new-style date cookies? [18:08:38] there's no method provided in JS to know when a cookie will expire [18:08:39] so... no [18:08:43] I think we want to just stop using the old ones. [18:09:12] that's not to say we have to stop using the old cookie name; but we cannot honor the hide request if it's just "hide: true" [18:09:15] ahh, so we're good with people seeing new banners when we push this, no matter when they last donated? [18:09:21] exactly [18:09:28] That's exactly the idea, yes. [18:09:49] Hopefully, with this change, though, that will *never happen again*. [18:09:53] and we'll use some new value in the cookie for the short-term 'X' button hiding [18:09:58] er. [18:10:00] mwalker quick WP question - on that auth for the authorization and sale route, donors see a small authorization charge in addition to the actual charge, right? [18:10:08] ejegg: I don't think that's supposed to change. [18:10:09] atgomez, currently, yes [18:10:19] cool. and the the other way would not have that, right? mwalker [18:10:25] ejegg: In fact, touching that would be Bad. [18:10:36] ejegg, the mechanism should be the same for both -- call up to Special:HideBanners and it will set a cookie with an expiration time value [18:10:38] K4-713: currently the 'X' button sets the same cookie to hide [18:10:53] ...the same... cookie? [18:11:02] yeah, but with a shorter expiration date [18:11:05] atgomez, correct; we would authorize for the full amount and then use that authorization to charge [18:11:11] thanks mwalker ~ [18:11:12] ! [18:11:17] Oh dear. [18:11:42] K4-713, that's how its always worked... and it's also how we enable cross wiki banner hiding [18:11:55] you click the X; it makes a bunch of cross domain calls to SPecial:HideBanners [18:12:02] and it sets the cookie [18:12:23] internally to CN it doesn't matter why we're hiding the banner; it just knows we want to [18:12:34] mwalker: there's something in bannerController that just adds the cookie in js [18:12:44] window.hideBanner [18:13:05] oh right, then it hits all the URLs [18:14:14] mwalker: I knew that bit. I just thought the Thank You For Donating cookie wasn't overlapping with that. [18:14:39] I admit that I may be thinking of the code from two years ago, or making things up. [18:14:46] *nods* it's the same thing; we just set different expiry times [18:14:52] Flip. [18:15:55] hmm, i thought we wanted to store an approximate donation date so we could change our minds about re-pestering interval at any time and have it be retroactive [18:16:09] Yep. [18:16:21] we still can; so long as the expiry date of the cookie is further out in the future than the short expiry interval [18:16:34] inside that interval we would not be able to tell if they donated or closed the banner [18:16:49] That seems like a problem. [18:16:54] why? [18:16:57] Perhaps I need more coffee. [18:17:11] So, somebody donates, they get (roughly) today. [18:17:18] Somebody clicks the X, they get... what date? [18:17:33] Because it sounds like we're going to close banners for a year or something. [18:17:54] ah; in the original thought process; they donate they get today + 300 days; if they click the X they get today + 14 [18:18:00] Yes. [18:18:06] And that shouldn't change substantially. [18:18:18] but doesn't that 300 days lock us in? [18:18:27] Yeah, that's the problem. We were. [18:18:45] When the cookie just lives for as long as you want the banners to hide, it's easy. [18:18:51] They want to turn it all on its head. [18:19:13] if the cookie has the value of the date when it's supposed to expire; we can use the mixin mechanism to override the hide cookie [18:19:22] because mixins run before the banner is displayed [18:19:30] and can alter the show/hide decision [18:19:37] ahh, the mixins! [18:19:37] Uhm. [18:19:40] I have a wacky idea. [18:19:54] What if the hide cookie gets today and expires the way it always did? [18:20:01] +2 weeks. [18:20:05] Then today goes away. [18:20:34] that seems like it would work [18:20:39] Then the hiding logic is the same for both cases. [18:21:59] It's just that the actual post-donation cookie has a much longer lifespan. [18:22:20] And we can still make show/hide decisions about localities in the mixin. [18:22:38] it doesn't particularly matter if the cookie holds the date the hide was issued or the date the hide will expire -- but I find it conceptually easier to deal with if the value of the cookie is the date it's supposed to expire [18:22:53] Sadly, that's what they're trying to get away from with this. [18:22:53] given that we cannot inspect a cookie to find its expiration date [18:23:24] so the change is this: new cookies get 'hideDate' with the exp date as the value (adding fuzz for the donations) rather than just 'hide' [18:23:38] Hmm. [18:23:53] in js, we check for 'hideDate' value so we ignore old cookies [18:24:09] I really think we need the date the cookie was created. [18:24:15] ...and so do they. [18:24:41] Otherwise, nine months out, when they want to change when some locality expires, we have to do an additional operation in the math. [18:24:57] it's the same operation; just with a different sign... [18:24:58] ...it depends on the settings of the past. [18:25:00] but! [18:25:02] it's a cookie [18:25:05] put both in [18:25:15] and that solves the problem of determining if it's a X or a donation [18:25:22] because you can then see the date rante [18:25:24] *range [18:26:00] we have a fine history of putting json objects in cookies [18:26:18] I suppose whatever we can do to not hate ourselves when this happens again, is probably a good idea. [18:26:27] we're getting the intended lifetime from mw.config, right? [18:26:47] ejegg, yep; there are two variables that are exported through ResourceLoader into mw.config [18:26:56] I would prefer, though, if only one piece of code had anything to say about when we expire things. [18:27:18] yeah, i was hoping to use that to make it simpler [18:27:43] we only store the approx donate date [18:28:05] then check if we've passed that plus lifetime from mw.config [18:28:12] I'd... prefer to get that setting as close to being on-wiki as we can, for the post-donate version. [18:28:30] so; keep in mind ejegg that the Special:HideBanners response is cached heavily (I think production has the value at 24H currently) [18:28:43] and we really dont want to change that [18:29:07] we've brought the cluster down twice by having the cache expiry too low for that page [18:29:32] mwalker: meaning everyone will get the same 'approximate' donation date? [18:29:37] yes [18:30:01] K4-713 - are you looking at the fraud stuff at the moment? [18:30:08] ffffffffff [18:30:09] no [18:30:11] Okay. [18:30:14] ...yes now. [18:30:31] But we have 30 minutes. [18:30:39] do you remember if we changed the filters for NL a few months back? [18:30:52] i don't have any tracking in mingle/email... i think it may have been a chat sort of thing [18:30:59] but i vaguely remember us adjustin them a while back [18:31:07] do we log those changes anywhere? [18:31:51] atgomez: We definitely did. And we don't log specifics, no. Usually I try to be as clear as possible in email if it was something of common concern. [18:32:08] atgomez: What specifically are you looking for? [18:32:33] ok.. if we did it htat's cool [18:32:42] Keep in mind also, that records of exactly how we are adjusting our antifraud filters should *never ever ever* be public. [18:32:46] pats looked at the numbrs a while back and we just wanted to confirm that we'd actually, you know, addressed it :P [18:32:49] ahh yeah that's true [18:32:57] hm. [18:32:59] This is why it won't show up in any public places. [18:33:09] ...so please don't put it there. :) [18:33:09] something to consider.. it would be good to have *something* that we can reference [18:33:10] yeah word. [18:33:15] Collab. [18:33:20] yup [18:33:35] We should talk about when and how we update. [18:33:42] ...that could get annoying. [18:33:53] yeah totally [18:34:03] Also, if I put everything in there, nobody but tech would be able to read the thing. [18:34:19] So, let's talk about intended audience, too. [18:34:50] word [18:34:52] I'm pretty interested in not-tech being able to find this information without pinging me. :) [18:36:26] mwalker: HideBanners could use a 'fuzz' int parameter that js generates between -7 and +7. Would render 14x as many fresh responses in each 24 hr period, but after that they're all cached [18:37:14] that's OK from a operations perspective; but Legal didn't seem to care about fuzzing [18:37:17] so I wouldn't both [18:37:21] *wouldn't bother [18:37:39] ok [18:50:32] !log updated fraud filters on payments cluster [18:50:38] Logged the message, Master [18:58:41] Hmm. I may have been a little overzealous with the referrer blocking, there... [19:47:45] !log updated payments fraud filters again [19:47:50] Logged the message, Master [20:55:42] what's the wifi secret here? [20:55:47] i forget [21:56:11] * K4-713 yawns [21:56:26] atgo-away: Am I forgetting to do anything? [21:56:41] well.. the https shop thing :P [21:57:12] Can I please forget that until SEPA is done? [21:57:42] ...unless I hit more account-related blockers I can't do anything about, anyway. [21:57:47] yeah we can postpone. i'll let caitlin know [21:58:14] Timing. [21:58:22] K4-713: So, we're not worrying about the exact way we'll override right now - we just want to get dates into those cookies? [21:58:32] Ah, no... we need it to work. [21:59:09] But... we're not currently using mixins, are we? [21:59:51] No, but Matt was saying he thought those would be the override mechanism [22:00:02] I mean, we definitely want to be using mixins. But this is kind of a hot item. [22:00:27] So, any way we can uncomplicate the path to the deliverable while not sabotaging ourselves is probably the way we want to go. [22:00:40] I think they wanted this last week. [22:00:57] Hence my hesitation to roll some other new mechanism in there. [22:01:23] it's more important to do it right than to rush it [22:01:33] Good to know. [22:01:48] generally, let's try to think that way as much as we can [22:02:00] I was going to change the value from 'hide' to two timestamps separated by a '|' [22:02:07] i've been clear with prod that the emergencies that have come in have taken precedence. [22:02:08] first being created, second being expiry [22:02:08]