[00:23:16] awight: AndyRussG: What are your working times usually, SF? [00:23:52] I overlap about half with SF working days (the first half). [00:26:21] Krinkle: They're usually on SF times, more or less. [00:27:05] Though, awight is usually completely missing on Tuesdays. [00:27:38] AndyRussG can tilt a little more Eastern Time, as that's where he actually is. [00:44:12] Krinkle: yep, any morning except Tuesday works for me. But I think we might have a solution that doesn't involve any fancy footwork WRT ResourceLoader. [00:44:42] We're just setting a default which causes the banner choice data RL module to work without emitting warnings. [00:59:48] Wikimedia-Fundraising, MediaWiki-extensions-CentralNotice, Epic, Patch-For-Review, and 2 others: Special:RecordImpression should die in a fire - https://phabricator.wikimedia.org/T45250#1124045 (faidon) [01:01:58] awight: Yeah, I assume it shoudl jut return an empty list on a fresh wik [01:02:06] But something is preventing it from doing that? [01:02:40] Hi Krinkle and awight [01:02:58] Krinkle: yeah I'm on EST but really I shuffle it all around a lot (maybe too much) [01:03:58] (one sec, just putting kids to bed) [01:07:18] done! :) [01:07:27] That was fast. [01:07:33] They were almost ready [01:07:33] Do your children have an off-switch? [01:07:43] Because that would be really neat. [01:08:02] Sort of, though sometimes it doesn't quite work on the first try [01:08:27] About 70% of the time, they go to sleep quietly after we turn out their bedroom light [01:09:08] Maybe 20% of the time they decide to make noise, giggle, entice the cat to play with them under the door, get up and ask for water, etc. etc. [01:09:20] And maybe 10% of the time there's some degree of drama 8p [01:09:35] Sounds like you've got decent odds, there. [01:09:37] Mmm take that back, maybe 5%, used to be more tho [01:09:57] Yeah! The minutes preceeding lights out are often the craziest tho [01:10:23] Since they're tired, which means more wild 'n' crazy antics [01:10:50] This evening was relatively decent :) [01:11:09] Even tho it's later than it should be! Really they should be in bed by 8:30 pm [01:14:35] Krinkle: yes, it should return an empty list. My mistake was taking as a default path the API call from the "subscribing" wiki to the "infrastructure" wiki, which somehow borked during the Jenkins job. By taking the direct cross-wiki DB call as the default fallback, awight avoided the whole problem :D [01:18:55] Code avoision. [01:19:21] :) [01:19:26] K4-713: lol :) [01:19:42] Aww, I just saw email re. snacks. [01:19:47] hmm now the cat is trying to entince the kids to come out to play ha [01:20:01] There was an email about snacks? [01:20:10] wtf. [01:20:37] ...oh, wait: Was it the cupcakes? I split one with atgo. Awesome. [01:22:13] Krinkle: I guess on my part it was a little bit just not seeing the forest for the trees. Being completely idealistic, RL should let PHP-based RL modules be mocked in these circumstances. But if this default, i.e. fetching banner choices by a DB call on the same wiki, works--and really it's the most sensible no-config default--then I think we're good to proceed :) [01:23:12] now the cat isn't allowed out of the study, heheheheh [01:23:43] * K4-713 facepalms like crazy [01:23:51] awight: Guess what. [01:24:08] Those sections in the PCI gap assessment? [01:24:16] Come from the official form. [01:26:11] And there are much nicer human-friendly names for the major section numbers. [01:26:18] At the very end of the doc. [01:30:26] Krinkle: am I making sense ^ ? [01:31:53] AndyRussG: Yup [01:32:14] cool :) [01:32:55] AndyRussG: Modules should work on a fresh wiki without configuration or user input. Returning an empty data set seems logical there. Any modules client-side should mock pre-existing input and any extra requests it makes. [01:33:20] The module being there already on the page isn't related to the test, but just related to the test host page itself being a regular wiki and the wiki, having the extension installed can potentially show banners. [01:33:27] So that's just overlap to be ignored. [01:33:53] For the same reason we also ignore most of mw.config and/or $wg in unit tests. Instead tests provide their own values and the tests should run fine on any set' up wiki regardless of configuration values. [01:33:56] As those are ignored. [01:34:21] Yeah [01:35:53] It gives the same end result as if there were a special testing set up that removed the dependency or replaced it with a mock [01:38:27] WRT the second thing you mentioned, ignoring $wg's in unit tests: the fact that CN's PHP tests were not doing that was also a problem, unrelated except that it was blocking this solution, until awight made a patch that fixed it [01:39:48] In any case I'm happy to have had the chance to delve deeper in to the RL code, since it looks like we have more twisting of RL into unforseen shapes coming up :) [01:40:18] * awight tries not to look like a potential balloon animal [01:44:50] (unrelated to upcoming twistiness: I'm trying to think if it makes sense that RL would ever need to adjust module dependencies during tests for better isolation, including for JS modules. I guess in all or maybe nearly all circumstances there'll be a way to not need it...) [01:45:58] Donno... hopefully, most modules will be safe to load? [01:46:29] I was sort of surprised at how the testmodules hook works, though. [01:47:50] We do a little dance in DonationInterface to avoid loading unit tests... this seems related. Maybe when testing knobs are turned off, we should go out of our way to not run any of the testing hooks in mw-core [01:47:54] ? [01:49:25] awight: you mean PHPUnit stuff? [01:49:42] well, both [01:50:06] Eh, that was half-baked. I guess that's how it already works. [01:53:54] mmm you could call it lightly toasted instead... sounds reasonable [01:57:36] which hooks? [02:01:21] Err, I suppose the two hooks I'm talking about work a bit differently, and it might be nice to make the RL one work like the UnitTestsList hook. [02:01:34] The PHP one is only run when we're building the list of tests to run. [02:02:00] Maybe QUnit should call back to the wiki with some parameter set, "isQunitTest=1", and that triggers the RL test hook to fire. [02:02:45] Save a few cycle for every RL startup request, plus we allow for tricky testiness like what we tried to accomplish with changing dependencies during a test. [02:08:33] awight: the draft patch I did for core was headed out along those lines, more or less [02:08:53] though it was a bit more involved and not about that specific hook [02:16:50] I should read that! [02:17:24] hmmm might want to take a few shots of dramamine first tho [02:18:20] recall the banner history plan also involves mucking with RL dependencies dynamically BTW! ;D [02:18:50] ooh really, no I didn't know that [02:19:45] hahahaha no lo dudes [02:21:17] CNBannerChoiceDataResourceLoaderModule will dynamically add the needed mixin RL modules as dependencies in its override of getDependencies() [02:24:14] So that is not cached? [02:24:45] And, I guess we're adding dependencies every random N requests, to include the banner history support? [02:25:44] * awight cannot find synopsis [02:27:12] awight: looking... hmm where did we put it? [02:28:02] awight: https://phabricator.wikimedia.org/T90913 [02:29:10] When I looked into the varnish setup for that my (very possibly wrong) conclusion was that it wasn't any more or less cached than anything else ResourceLoader [02:30:08] CNBannerChoiceDataResourceLoaderModule varies when banner choices for a given combination of language and project vary. We'll need only the same variance and caching time for the changing dependencies [02:31:21] awight: also BTW, working on this alternative to the collab page (which also has some new stuff btw): https://www.mediawiki.org/wiki/Extension:CentralNotice/Notes/Campaign-associated_mixins_and_banner_hisotry [02:43:57] AndyRussG: whew, thanks. Now I think I understand the connection between the campaign mixins and banner history: but I'm surprised that you're planning to implement banner history on a per-campaign basis. Maybe I still don't understand? [02:44:49] awight: not planning to implement that on a per-campaign basis :) [02:44:53] ah [02:45:02] * awight squints [02:45:10] The logic will go in campaign-associated mixins, which may or may not be associated with any given campaign [02:45:27] wat [02:45:28] But the actual history will be stored on a per- *category* basis [02:45:37] That still seems like an odd decision. [02:45:48] Well, it could also be universal, I guess [02:45:55] accessible to all campaigns [02:45:59] Don't we care if a reader sees ten unrelated banners before our FR banner? [02:46:07] tre [02:46:08] true [02:46:26] yeah the per-category stuff was a bit prior to scoping out a lot of the detailed requirements [02:46:40] I think some of the logic may need t be so [02:46:51] What exactly would the mixin be? [02:47:01] Javascript, mainly [02:47:02] :) [02:47:18] Logic for recording and calling home about banner impressions? [02:47:22] or just the calling home? [02:47:28] or... something else... [02:47:42] Well, it could be componentialized, so there could be more or less [02:48:06] What is an example of a page load which wouldn't include the history module? [02:48:06] Re: categories, for example, we may want to count how many FR banner views the user has got before starting to hide 'em all, across FR campaigns [02:48:16] that makes sense [02:48:20] :) [02:48:27] But not have that affect community campaign hide/showing [02:48:33] k [02:48:56] page load w/ out the history module: user not targeted by any campaign [02:49:11] ok [02:49:12] or user targeted only be Wikie Loves Monuments or something [02:49:16] whoa [02:49:19] why? [02:49:31] well, OK I guess we could give 'em history [02:49:39] But if we know they really don't want it... [02:49:51] I mean, the banner history module is not what replaces impression counts [02:50:00] Everyone gets impression counts for free via Special:BannerLoader [02:50:17] The history module is a much bigger chunk of data [02:50:54] BTW check out the most recent addition to the data requirements Ellery added to the collab page, there is actually some new stuff to be re-discussed w/ Ellery [02:51:01] Keeping history across categories seems very much a part of https://collab.wikimedia.org/wiki/Fundraising/banner_history_cookie # banner fatigue [02:51:55] awight: yeah that makes sense [02:52:19] Well we could have global banner counts and FR banner counts, and have a nice algorithm that takes 'em both or one or the other into account as needed [02:52:30] This also looks funny: Client Side Data Collection -> "pageview where CN is active" -> campaign name. I think that's an optional field, now? [02:52:40] Mixins will be like the Excel functions of CentralNotice [02:52:48] 8p [02:53:15] I think "where CN is active" really means, "when a user is targeted by a campaign" [02:53:29] AndyRussG: but counts don't tell the whole story... IMO we'll want history as well. [02:53:48] yeah [02:53:48] Ah [02:53:51] true [02:54:04] hmm does sound like it's gonna get hairy! [02:55:49] Apologies for the long tangent, I should really wait a few weeks before purging things from my last-generation memory [02:56:54] Still, I think it makes a difference that we include banner history as a ubiquitous RL module, rather than trying to mixinize... [02:58:20] (CR) AndyRussG: "Nice!! Another possible reason for squashing this with the next commit might be that it'd be silly to write the doc for the global config " (3 comments) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/181238 (https://phabricator.wikimedia.org/T92000) (owner: Awight) [02:59:18] np! Hmmm so you're saying, you think it should be ubiquitous? [03:00:10] There are also more issues, since ubiquitious client-side page view history would be interesting for other teams and projects too, and architecturally in that case CN would not be the place for it [03:00:52] Well, at least as ubiquitous as other CN stuff which runs whenever we show a banner. [03:01:32] or err, more accurately whenever there are campaigns targeting the project and language, like u were saying. [03:02:17] I see what you mean that this could reuse the campaign mixin getDependencies trick. [03:05:43] awight: hmm well let's decide based on what would really be used when... making it all ubiquitous could simplify stuff... I'm not opposed but still would also like to keep the non-ubiquity option on the table for some or all of it [03:07:41] (PS3) Awight: Clean up database switching [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/197003 (https://phabricator.wikimedia.org/T92000) [03:07:46] (Abandoned) Awight: Clean up database switching [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/197003 (https://phabricator.wikimedia.org/T92000) (owner: Awight) [03:08:10] (Restored) Awight: Clean up database switching [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/197003 (https://phabricator.wikimedia.org/T92000) (owner: Awight) [03:08:24] (Abandoned) Awight: Default to single-database configuration [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/196985 (https://phabricator.wikimedia.org/T91763) (owner: Awight) [03:09:54] (Abandoned) Awight: Clean up database switching [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/197003 (https://phabricator.wikimedia.org/T92000) (owner: Awight) [03:10:15] (PS9) Awight: Clean up database switching [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/181238 (https://phabricator.wikimedia.org/T92000) [03:10:16] hehehe [03:10:27] which cup is the coin under? [03:11:00] (CR) Awight: Clean up database switching (1 comment) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/181238 (https://phabricator.wikimedia.org/T92000) (owner: Awight) [03:11:40] whoa! [03:11:54] it's not a coin, it's a hamster! [03:11:55] "git-tor" [03:13:19] http://www.rettet-raffi.de/en/ [03:14:13] juggling flaming patches :) [03:14:56] (PS10) Awight: Clean up database switching [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/181238 (https://phabricator.wikimedia.org/T92000) [03:15:37] (CR) Awight: Clean up database switching (2 comments) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/181238 (https://phabricator.wikimedia.org/T92000) (owner: Awight) [03:16:27] cool! [03:17:02] Time to wind chime, I'll look at the bonfires and cup tricks 'morrow :) [03:17:06] cya! [03:17:11] Whaa, that film is real :) You really get to do cool stuff with kid excuse [03:17:16] bye! [03:17:19] & thanks! [03:17:42] "Raffi was hard work for the film team as he turned out to be a real Diva, and caused them sleepless nights. Due to this reason he had 14 understudies, each of whom could do something different to one another." [03:18:28] (PS1) Ejegg: Update c3 and d3 [wikimedia/fundraising/dash/src/bower_modules] - https://gerrit.wikimedia.org/r/197270 [03:19:16] (PS1) Ejegg: Update c3 and d3 to latest supported versions [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/197271 [03:26:49] ejegg: waitaminute. Let's just skip query #23?? [03:27:47] Whew. Russia does have 10 hours of timezone, however! [03:30:06] awight: skip timezone?? [03:30:16] Hm [03:31:23] query #24 fetches timezone by country as a fallback... [03:32:00] even US, I imagine they attach some importance to sending at 9am vs noon or the like [03:32:37] I'll ask ccogdill if she cares, for starters. [03:32:41] Wikimedia-Fundraising, Fundraising Tech Backlog, Fundraising-Backlog, Fundraising Sprint Flaming Lips, Patch-For-Review: BUG: Silverpop export is still broken - https://phabricator.wikimedia.org/T92537#1124138 (awight) @CCogdill_WMF: How much do you rely on the donor time zone information in th... [03:32:50] I think the time of day does matter. [03:32:59] But don't the emails go out in long batches anyway?... [03:33:33] i dunno - silverpop may have some massive burst infrastructure [03:39:28] we could try doing it to the real output table and see if the tempiness is somehow the problem [04:15:42] (PS1) Ejegg: Set tzoffset on persistent output table [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/197273 (https://phabricator.wikimedia.org/T92537) [04:21:44] (PS1) Awight: Break query #23 into pieces [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/197274 (https://phabricator.wikimedia.org/T92537) [04:21:54] ejegg: rats, I didn't realize we were both in there. [04:22:35] hah [04:22:43] may the best patch win! [04:23:05] I'll rebase mine to second... [04:24:43] uhh nvm. let's just go with your approach... [04:26:11] aww, but procedural sql is so fun! [04:26:24] I'd like to put this whole affair behind me :p [04:26:58] tru dat [04:28:07] (CR) Awight: [C: 2] "Seems fine, except now I worry that a hanging query will lock the real silverpop_export table... That will get our attention tho, which i" (1 comment) [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/197273 (https://phabricator.wikimedia.org/T92537) (owner: Ejegg) [04:28:09] (Merged) jenkins-bot: Set tzoffset on persistent output table [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/197273 (https://phabricator.wikimedia.org/T92537) (owner: Ejegg) [04:28:58] woot [04:29:14] imma deploy that, unless you want to wait [04:29:50] (PS2) Awight: Break has-been query #23 into pieces [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/197274 (https://phabricator.wikimedia.org/T92537) [04:29:52] hehe [04:30:07] gasoline in the nest? [04:30:09] nice [04:30:38] oops, left some merge gunk in there [04:30:57] (PS3) Awight: Break has-been query #23 into pieces [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/197274 (https://phabricator.wikimedia.org/T92537) [04:31:09] gack [04:32:04] Did I mention, "untested" [04:32:19] (PS4) Awight: Break has-been query #23 into pieces [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/197274 (https://phabricator.wikimedia.org/T92537) [04:32:44] that looks like the ticket! [04:36:01] ohh, except we've hardcoded the ';' delimiter in the python code [04:36:27] 's how we break up the queries [04:37:27] (CR) Ejegg: [C: -1] "python's breaking up queries on ';', so delimiter replacement is gonna be a pain here." [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/197274 (https://phabricator.wikimedia.org/T92537) (owner: Awight) [04:38:10] omg [04:38:15] :P [04:41:23] Well, I'm fine w/ you deploying just one fix, of course. We can wait to see if the rash comes back... [04:42:38] ok, i'll give it a shot [04:44:21] (PS1) Ejegg: Merge branch 'master' into deploy [wikimedia/fundraising/tools] (deploy) - https://gerrit.wikimedia.org/r/197275 [04:44:35] (CR) Ejegg: [C: 2] Merge branch 'master' into deploy [wikimedia/fundraising/tools] (deploy) - https://gerrit.wikimedia.org/r/197275 (owner: Ejegg) [04:46:41] !log updated tools from 84442d51a841af4265ff103827cda83d5dd9dc54 to 9fd0a885e84074f215082aad689649a0684660f9 [04:46:48] Logged the message, Master [04:49:46] That's so evil. I'm sort of glad I wasn't able to change the delimiter again, from within the stored procedure. [04:50:12] I'll wait for the 4am run to test it. not going to stay up another 2hr [04:50:52] yeah, we've limited ourselves to SQL as it's meant to be used :) [04:50:56] that sounds better from a repeatability perspective, anyway [04:51:20] :p the python interpreter really bothers me... as cool as it is. [04:54:23] It makes me worry whether this SQL condom has failed already :p [04:54:40] hah [04:54:56] (Abandoned) Awight: Break has-been query #23 into pieces [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/197274 (https://phabricator.wikimedia.org/T92537) (owner: Awight) [04:55:54] ok, i'm over and out [05:09:39] Wikimedia-Fundraising, Fundraising Tech Backlog, Fundraising-Backlog, Fundraising Sprint Flaming Lips, Patch-For-Review: BUG: Silverpop export is still broken - https://phabricator.wikimedia.org/T92537#1124210 (CCogdill_WMF) @awight we don't even import the field into Silverpop - so we don't re... [05:12:32] (PS1) Awight: Drop all timezone stuff [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/197276 (https://phabricator.wikimedia.org/T92537) [05:13:29] Wikimedia-Fundraising, Fundraising Tech Backlog, Fundraising-Backlog, Fundraising Sprint Flaming Lips, Patch-For-Review: BUG: Silverpop export is still broken - https://phabricator.wikimedia.org/T92537#1124212 (awight) @CCogdill_WMF: Okay great, that should help a lot. [05:16:16] Wikimedia-Fundraising, Fundraising Tech Backlog, Fundraising-Backlog, Fundraising Sprint Flaming Lips, Patch-For-Review: BUG: Silverpop export is still broken - https://phabricator.wikimedia.org/T92537#1124214 (CCogdill_WMF) @awight awesome! Would it make sense for me to look into other extrane... [05:34:16] Wikimedia-Fundraising, Fundraising Tech Backlog, Fundraising-Backlog, Fundraising Sprint Flaming Lips, Patch-For-Review: BUG: Silverpop export is still broken - https://phabricator.wikimedia.org/T92537#1124228 (awight) @CCogdill_WMF: yeah, great idea! I'm pretty sure that the timezone was the... [08:46:02] Wikimedia-Fundraising, Fundraising Tech Backlog, Fundraising-Backlog, Fundraising Sprint Flaming Lips, Patch-For-Review: BUG: Silverpop export is still broken - https://phabricator.wikimedia.org/T92537#1124376 (CCogdill_WMF) @awight I think we can remove the contribution_id field as well. Conta... [14:17:14] hi the_wub! [14:17:41] we’re about to run a short ES test - couldn’t wait to test some of the focus group feedback despite the weird fraud stuff [14:18:10] Michael is going to check the fraud #’s in 30 minutes and if we’re rejecting > 20%, he will ping you to take banners down [14:18:13] does that work for you? [14:18:25] oops… the-wub :D [14:18:59] hey, sure that's fine with me ccogdill [14:19:05] awesome, thank you! [14:19:26] we’ll be OOO for an hour or so, so the help is much appreciated :) [14:27:01] Wikimedia-Fundraising, Fundraising Tech Backlog, Fundraising-Backlog, Fundraising Sprint Flaming Lips, Patch-For-Review: BUG: Silverpop export is still broken - https://phabricator.wikimedia.org/T92537#1125253 (CCogdill_WMF) Hi @awight - I talked with Trilogy and we've agreed we can remove A LO... [15:43:35] hey ejegg [15:44:07] hi atgo [16:09:14] hey atgo - we need to take the ES banners down, but I don’t think I can in CN [16:09:19] and Megan and Jessica are in a meeting [16:09:24] hmm ok [16:09:27] let me dig [16:09:28] you have access, right? [16:09:36] fraud is higher than Michael initially said [16:09:38] 21% right now [16:11:11] ccogdill: is that this one? C15_caES_dsk_FR [16:11:16] yep! [16:11:20] that’s the only one we need atgo [16:11:24] because it already says it's not enabled? [16:11:29] hmm [16:11:31] and it's not green... so... [16:11:33] maybe Megan did it... [16:11:37] ohh now! [16:11:39] *no! [16:11:41] that’s catalan [16:11:48] C15_esES_dsk_FR [16:11:49] is the one [16:12:02] yeah it says it was supposed to go down a while ago because of the schedule [16:12:13] oh ok [16:12:14] 1 sec [16:13:09] ok should be down. it takes up to 15 min to spin down ccogdill [16:13:17] cool, thanks atgo [16:13:35] ccogdill: we should get michael in this cannel, too [16:13:40] channel* [16:14:07] yep I’m going to ask him :) [17:20:25] (PS1) Ssmith: WIP add remove button to widgets [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/197360 [17:34:39] (CR) Ssmith: [C: 2] Update c3 and d3 to latest supported versions [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/197271 (owner: Ejegg) [17:35:11] (Merged) jenkins-bot: Update c3 and d3 to latest supported versions [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/197271 (owner: Ejegg) [19:03:22] atgo: agreed we should consolidate and re-organize the CN docs! [19:03:37] :) [19:06:05] Thanks for adding the key for the diagram... I was thinking about sending an e-mail about on the fr-tech banner history thread with this link, and also suggesting that the "Motivation" and "High Level Propsal" sections be copied to the empty sections on the Mediawiki page... [19:06:29] and also asking the questions that came up in the check-in yesterday... [19:06:35] Does that make sense? [19:06:37] atgo: ^ [19:07:43] Also, BTW Peter sent an e-mail with an overview of on-wiki JS, which could eventually be adapted to go there, I think [19:08:19] yes [19:08:22] all of that makes sense [19:12:29] atgo: cool! :) [19:12:36] thanks AndyRussG! [19:12:53] np, likewise [19:12:55] did i say i was going to make a meeting for us to circle up wtih megan and ellery? [19:13:18] Ah not sure, but in any case that sounds like a good idea, yeah [19:15:57] ok. want me to set something up or do you want to? [19:18:06] Wikimedia-Fundraising-CiviCRM, Fundraising Tech Backlog, Fundraising-Backlog: Create a general Civi import function to reduce time for hand keying donations in Civi - https://phabricator.wikimedia.org/T88836#1126119 (atgo) Hey @rlewis - I've just added this as a goal to our quarterly plan for Q4. Her... [19:19:00] atgo: mmm whatever's easiest! Do you want me to book the meeting since you did last time? I think you have the more complex schedule, tho, so maybe it's easier for you to know when's a good time... [19:19:10] sure :) [19:19:12] my calendar is up to date [19:21:35] (PS3) Ssmith: Fraud gauge widget refactor [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/196614 [19:22:37] (CR) jenkins-bot: [V: -1] Fraud gauge widget refactor [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/196614 (owner: Ssmith) [20:01:34] (PS4) Ssmith: Fraud gauge widget refactor [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/196614 [20:16:48] (CR) Ejegg: [C: 2] "Bam!" [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/197276 (https://phabricator.wikimedia.org/T92537) (owner: Awight) [20:30:51] (PS2) Ejegg: Delete more unused fields [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/197406 (https://phabricator.wikimedia.org/T92537) [20:33:03] ejegg: Any new insights into the fraud spike? [20:33:46] ...in the last 30 minutes since standup. :/ [20:35:27] no, nothing yet [20:35:42] okay [20:36:02] I'm going to pick this up from the beginning, then. I think there's a weird assumption in there somewhere. [20:36:25] k [20:36:30] * K4-713 picks up assumption-smashing hammer [20:38:02] thor? [20:38:11] ...'ya got me. [20:38:26] I should be more careful. [20:42:27] Okay, I can already tell you that there are multiple things going on, and none of them seem to be related to what we ran away with this morning. :) [20:42:46] oh? [20:42:50] Yep! [20:42:58] I will have to send more details over email. [20:55:15] Wikimedia-Fundraising-CiviCRM, Fundraising Tech Backlog, Fundraising-Backlog: Create a general Civi import function to reduce time for hand keying donations in Civi - https://phabricator.wikimedia.org/T88836#1126527 (RLewis) @atgo thanks. Just to add more context to the Donor Advised Fund import, th... [22:17:13] And once again: The damage report machine's been damaged. :) [22:26:42] hey quick question K4-713 ejegg - for recurring, is it on the same day of the month (so if i set up a subscription today always on the 17th)? [22:26:50] except for days 29+? [22:26:51] Yep! [22:26:59] Ah, it's actually cooler than that. [22:27:11] oooh! [22:28:30] It always recurs on the start day. But, for any day, if that day of the month is missing (February: What a jerk, amirite?), it goes to the... er. Last day of the month. I think. [22:29:03] But, then, if the next month has that original start date, it goes back to what it used to be. [22:29:41] Also, by "cooler" I mean "unbelievably more infuriating". [22:33:16] oooh fancy [22:33:36] That function is, like, 10x longer than anybody thinks it has any right to be. [22:34:09] Including me, and I wrote it to begin with. [22:34:16] :P [22:34:22] Stupid human months. [22:34:33] Financial Arghbargle. [22:34:36] yeah i think other recurring situations i've been around have basically pushed everyoen who signs up from the 29-31 onto the 28 [22:35:02] We could have done that, but noooOOOOOOoooOooOo. [22:35:06] hahaha [22:35:09] let's make things harder! :P [22:44:10] atgo: omg, I'm so good at that. [22:44:19] Complication is GO. [22:47:51] Oooh... can I kill off that spike? [22:47:56] atgo: ^^ [22:48:00] hi! [22:48:10] what do we need to do to un-break this? [22:48:18] ejegg is working on it. [22:48:21] sweet [22:48:30] But, we know what's wrong. [22:48:30] yeah if you want to make a subtask from the spike that covers that, perfect [22:48:33] woooo! [22:48:44] atgo: Hum. Is that how you want to arrange things? [22:48:57] it'll just show as "blocked by" the spike [22:49:05] what are you thinking? [22:49:28] Nothing, actualy. [22:49:33] There is nothing going on in here. [22:49:44] haha [22:49:50] * K4-713 enjoys a gentle breeze [22:49:57] yeah i think either adapt the spike to include the solution, and keep the task open in dev [22:50:02] or make a subtask that describes the fix [22:50:07] Okay. [22:50:15] I was just... excited about maybe getting to move a card. [22:50:19] yay! either way :) [22:50:24] ccogdill: how are you awake?! [22:50:40] i guess it's not that late... [22:50:53] I’m working my way towards bed atgo :D [22:50:57] :) [22:51:07] the sleep schedule is very strange these days [22:52:43] word. [23:00:17] AndyRussG: I just read your "Wobbly dinosaur potato" email. [23:00:47] This is a much better name than I had imagined. [23:01:11] K4-713: ahhh glad you like it! [23:02:02] Still, I feel that I should endorse going after a(n) euphonious backronym... [23:03:07] But I guess this isn't an astronomy project. [23:03:11] Those guys are the worst. [23:03:18] heh yeah at that time my random value generating was overactive, I'll still try to find one! [23:06:50] For instance, if we wanted to call it "BAD CATITUDE", it would stand for: BAnner Data / CAmpaign TrackIng Tool, User Data Enabled [23:06:54] Just an example. [23:06:57] Please don't use that. [23:07:09] nice! [23:07:24] No it's not. [23:07:28] :p [23:09:47] Well, nice as in "baaaaaaaaaaaad" nice maybe? [23:10:01] Oh! French verb conjugation, weee! [23:10:08] hehe [23:10:52] I think I could make any of those work as long as there is at least one B, and one C. [23:11:02] A "U" would be nice. [23:11:08] Maybe an "H". [23:16:21] OK u got it :) [23:21:51] ... [23:26:08] (PS1) Ejegg: Don't fraud-fail on STATUSID 25 [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/197440 [23:26:33] K4-713: I may be solving the wrong problem there [23:27:06] just realized that for status 25 we probably shouldn't even be running the hooks [23:31:27] ejegg: Ha. [23:31:39] right? [23:32:08] Even more funny: I don't know if we ever had this one entirely right. [23:32:30] especially with that 'only run the hooks on the first try' block [23:32:43] But, yes: 20, 25... anything that isn't 600, really... won't go anywhere. [23:33:25] so yeah, let's not run them hooks if the status maps to 'pending' [23:33:58] I think there was a card for this in our voluminous backlog that we abandoned in Mingle. [23:34:13] aww, probably [23:36:25] Did you look in the orphan adapter for, ah... things that would override the functions that call the hooks in the first place? [23:36:38] nope [23:36:41] will do! [23:37:51] ok, that doesn't seem to be happening [23:38:29] it's just that cheesy querystring test that decides whether confirm_CreditCard treats it like an orphan or not [23:40:08] You can probably... [23:40:10] ...wait 1. [23:40:41] Yeah, totally. [23:40:54] protected function pre_process_get_orderstatus in the gc adapter is what calls the hooks. [23:41:26] So... in the child class, just add a blank and make a post_process for get_orderstatus, I think. [23:41:54] This is, like... one of those things that actually still works the way I intended. [23:42:01] I mean: probably. [23:42:06] oh, there's also a bit in confirm_creditcard where we explicitly check after and run the hooks if its an orphan [23:42:13] orly [23:42:22] Well, never mind that last statement, then. [23:42:35] I think you still want to gut the first function, though. [23:42:47] That will prevent the pre-check that won't do anything anywa.y [23:43:31] strictly in the orphan adapter, though. [23:43:35] yep [23:43:48] cool [23:45:08] huh, i think i need to keep that empty string to null fix still [23:46:04] so when a live user returns, we get a 25 and addData, and then we retry, we don't fraud fail on the second preprocess [23:46:27] uhm. [23:46:36] rephrasing: so that when we get a 25 on a live user return [23:46:46] Except that's broken right now. :) [23:47:00] Are you fixing that too? [23:47:18] ah, not in this patch! [23:47:30] (CR) Ejegg: [C: -1] "Shouldn't be running the hooks after statusid 25 anyway" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/197440 (owner: Ejegg) [23:47:49] Also: dang it, we used to not re-run antifraud filters if we already ran the hooks, and literally nothing changed in the data set. [23:48:01] Shouldn't have lost that. [23:48:17] aw, bummer. We had some kind of 'dirty' flag? [23:48:33] Well, a hash that we calculated and checked. [23:48:52] There may still be evidence of that in the minfraud filter. [23:49:05] ...brb [23:50:50] totally still exists in minfraud [23:52:35] still exists, ooh, but setHash may no longer be propigating the value to where getData_Unstaged_Escaped() will return it [23:54:46] We shouldn't need it all the way up there. [23:54:50] ...right? [23:55:12] It was always up to the filter classes to recalculate or not. [23:56:04] minfraud is just looking for it there is all [23:59:11] hum [23:59:49] This is starting to resemble a loose thread on a sweater. [23:59:57] very much so