[04:07:30] (CR) Cdentinger: Add text filters (1 comment) [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/200097 (owner: Ejegg) [06:03:51] Fundraising Tech Backlog: Build prototypes for mobile fundraising donation asks - https://phabricator.wikimedia.org/T99004#1324848 (Qgil) [06:13:39] Fundraising Sprint Kraftwerk, Fundraising Sprint Lou Reed, Analytics-Cluster, operations: Verify kafkatee use for fundraising logs on erbium - https://phabricator.wikimedia.org/T97676#1324871 (AndyRussG) Hi! I've checked this by comparing, from erbium: `/a/log/fundraising/logs/buffer/2015/bannerImp... [10:40:36] Fundraising-Backlog: Logging if a donation amount was chosen from one of the fixed amounts - https://phabricator.wikimedia.org/T92462#1325251 (Pcoombe) It would be reasonably easy to add this to the data submitted from the banner, but there isn't really a place to store it in contribution_tracking. [13:37:56] Fundraising Sprint Kraftwerk, Fundraising Sprint Lou Reed, Analytics-Cluster, operations: Verify kafkatee use for fundraising logs on erbium - https://phabricator.wikimedia.org/T97676#1325639 (Ottomata) > My only concern so far is a difference in the number of entries for that 15-minute period: the... [13:46:12] Fundraising Sprint Lou Reed, Wikimedia-Fundraising-CiviCRM: Recent Engage Import - Contribution Type = Cash and not Enage - https://phabricator.wikimedia.org/T100853#1325675 (atgo) p:Triage>High [14:10:43] Fundraising-Backlog: Logging if a donation amount was chosen from one of the fixed amounts - https://phabricator.wikimedia.org/T92462#1325790 (atgo) Cool. Let's look at this later, then, after the banner history stuff is sorted out. Thanks! [14:15:51] Fundraising-Backlog: Stop retrying certain types of GC recurring failures - https://phabricator.wikimedia.org/T100536#1325805 (atgo) [14:26:13] (CR) Gilles: "It is worth checking what the impact is for users that are in a campaign, considering that this adds an extra round-trip in the head." [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/213990 (https://phabricator.wikimedia.org/T100372) (owner: Jdlrobson) [15:39:55] (CR) Cdentinger: [C: 2 V: 1] "works as expected" [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/199968 (owner: Ejegg) [16:07:20] morning ejegg [16:07:25] hi cwdent [16:08:23] i finally tracked that bug down, comment here: https://gerrit.wikimedia.org/r/#/c/200097/3/src/components/filters/text-filter/text-filter.js [16:10:07] oh wow, that's odd behavior [16:11:14] yeah, i still haven't found the bottom but passing null there works so i figure it's not worth spending more time on [16:11:33] with that change i think all 3 of these filter related branches should merge [16:11:52] i was going to make the change myself but i am a little confused about the workflow [16:12:00] really, calling with null works? [16:12:15] yep, anything i tried besides empty string works as expected [16:12:40] ok, i'll take a look in a little bit. [16:12:40] i verified that it just doesn't call the subscribed function on empty string [16:13:07] the previous value isn't the empty string, correct? [16:13:37] yep [16:13:45] weird [16:14:00] setting, changing work fine [16:14:15] deleting works fine except for the one edge case [16:14:33] where you delete it as the only action [16:14:57] so i figure it must be something with ko's subscribe [16:25:33] cwdent: i'm not sure if i'm seeing the same thing [16:26:28] if I tab out after backspacing, the 'save chart' button turns red and I can save with no filter qs [16:27:55] if I don't tab out, the 'chart saved' button stays green, and pressing it the first time doesn't do anything [16:28:32] well, anything except fire the change event and turn the button back to red / pressable [16:28:43] hmmm [16:28:55] you mean if you scroll down and click it without tabbing out? [16:28:59] that should fire a change event too... [16:29:00] right [16:29:24] yeah, it fires the change event, which turns the button red [16:29:29] i didn't have that problem [16:29:37] and the UI showed me it saved [16:29:42] but since the button started green, it doesn't send the 'put' request [16:29:43] but if you refresh the page? [16:29:51] oh, let me see [16:32:08] ooh, something is definitely amiss there [16:32:12] let me see [16:33:02] ejegg: if you throw a console.log in setChoices() you can see that it doesn't get fired [16:33:17] in the error case [16:33:17] oh, huh. [16:33:23] i'm just seeing the configuration returned looks odd [16:33:47] it's got a queryString with one filter but userChoises with a different filter [16:33:51] i was looking at what got saved in the db and did notice some weirdness [16:33:56] yeah totally [16:34:15] but it didn't appear to cause bad behavior [16:36:29] dang, this is going to take some digging [16:37:02] i mean...i spent about 8 hours on it :-\ [16:37:22] do you think they are the same issue? [16:37:28] unfortunately, i think i need to focus on the astropay DonationInterface stuff for a little bit longer [16:37:32] i figured on the configuration being a red herring [16:37:50] i dunno, maybe two different issues [16:37:53] yeah i'm definitely not trying to distract you from that [16:38:09] we can just pass a null in there and everything seems to work [16:38:18] huh, ok [16:38:32] and i'll just keep going with the other stuff and see if this comes up somewhere [16:38:42] if that's cool with you [16:38:46] sure [16:39:02] i was going to make the change but i'm not sure how to push stuff back from the detached head state [16:39:40] oh, if you want it to have a topic you can just checkout -b whatever from detached head [16:40:14] ok, so i should just push a different change to gerrit? [16:40:31] but let me make that change - it feels nicer to keep the distinction between writer and reviewer clear [16:40:40] i noticed these 3 "depend" on each other but are all branches of master [16:40:49] these 3 change sets [16:41:12] i'm coming from using github forever so i have a ton of habits to break [16:41:57] for instance several people editing the same change set [16:42:19] oh, i guess i rebased from detached head onto master and never made a new branch name [16:44:08] oh, right, they have a 'topic' but not a whole different branch [16:44:54] we mostly merge stuff right into master, except long projects like the centralNotice stuff AndyRussG is working on now [16:45:13] and the 'topic' just reflects the branch name on the dev's local machine [16:46:17] * AndyRussG waves :) [16:46:39] hi AndyRussG|mob [16:46:46] cool, well if you wanna make that change i'll +2 all these and continue on the a/b board [16:47:10] what is the next step to merge them after +2? [16:47:20] ejegg: hey :) [16:47:25] just +2 and click the 'publish and submit' button [16:47:30] then gerrit should merge it [16:47:36] groovy [16:47:39] morning AndyRussG [16:47:49] cwdent: morning! :) [16:49:47] (PS4) Ejegg: Add text filters [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/200097 [17:04:22] atgo: skipping the fr standup, got my head down in some stuff [17:04:28] cool sounds good :) [17:04:31] it's totally optional [17:04:44] cool, ty [17:05:27] hey ejegg - i'm wondering... will there be data about which card types are clicked/completed from Astropay? through anything on our side? [17:05:49] maybe we can get it from their side, too... not sure. [17:05:52] atgo: yeah, we should totally get the card type [17:05:58] awesome [17:06:11] we will probably have to educate about how to get that data at some point :D [17:06:40] I think it'll come up in the same spot we get card type for any other gateway [17:06:43] lemme see [17:07:42] great [17:20:32] (CR) Cdentinger: [C: 2] Create shared filtering component, use in x-by-y [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/199266 (owner: Ejegg) [17:20:46] (CR) Cdentinger: [C: 2] Add text filters [wikimedia/fundraising/dash] - https://gerrit.wikimedia.org/r/200097 (owner: Ejegg) [17:31:09] AndyRussG: chat CN admin email? :) [17:31:25] atgo: yup one second! :) [17:31:29] cool [17:49:49] * K4-713 yawns [17:50:38] atgo, AndyRussG: Hey y'all. CN question: How's the roadmap coming? [17:50:46] Or, do we just have a roadmap for making a roadmap? [17:50:52] more the second thing... [17:50:57] can we wait to chat in a few mins? [17:51:04] I can't chat until noon. [17:51:06] K4-713: hi! just in a meeting about the CN admin list e-mail [17:51:12] This is just a dream you're having. [17:51:15] (w/ atgo) [17:51:16] haha [17:51:22] i'm in your dreams?! [17:51:25] ... [17:51:37] * K4-713 coughs [17:51:42] K4-713: we can chat about it tomorrow? [17:51:45] K4-713: we do have a short-term roadmap [17:51:46] Usually you're telling me I forgot to do things. [17:51:51] i'm going to be offline in some short amount of time [17:52:03] There's really nothing to chat about on my end. [17:52:07] I just had that one question. [17:52:15] K4-713: go ahead :) [17:52:18] I'm all done here. :) [17:52:23] Ah just that question ;P [18:14:18] Fundraising Sprint Kraftwerk, Fundraising Sprint Lou Reed, Fundraising Tech Backlog, Analytics-Cluster, operations: Verify kafkatee use for fundraising logs on erbium - https://phabricator.wikimedia.org/T97676#1326616 (atgo) [18:20:44] (CR) Awight: More logic for mustache forms (2 comments) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/212728 (https://phabricator.wikimedia.org/T97056) (owner: Ejegg) [18:33:26] (PS12) Ejegg: More logic for mustache forms [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/212728 (https://phabricator.wikimedia.org/T97056) [18:34:03] awight: Now adding fiscal_number in an Astropay-specific override ^^ [18:35:24] K4-713: https://gerrit.wikimedia.org/r/#/c/213990/ [18:36:06] Fundraising Sprint Lou Reed: Remove unused JavaScript from GlobalCollect gateway - https://phabricator.wikimedia.org/T101014#1326679 (XenoRyet) NEW a:XenoRyet [18:37:35] Fundraising Sprint Lou Reed: Remove unused JavaScript from GlobalCollect gateway - https://phabricator.wikimedia.org/T101014#1326679 (XenoRyet) [18:42:48] ejegg: rad. I'm happy to merge that patch, lmk if you're still churning [18:43:36] nope, not churning on that any more [18:43:43] thanks! [18:44:32] (PS13) Awight: More logic for mustache forms [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/212728 (https://phabricator.wikimedia.org/T97056) (owner: Ejegg) [18:45:59] ejegg: Just occurred to me--maybe there should be a third, top level to cascading payment method specs, which is defined per gateway. [18:46:07] ooh, yeah [18:47:01] been playing with that a bit and finding some other cases we'll need to support [18:48:00] for instance, sofort supports EUR in one set of countries but only GBP in GB [18:48:47] blighty! [18:49:01] (PS1) Ejegg: WIP convert form settings for PaymentMethodFilter [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/215085 [18:49:17] here's one possibility ^^ [18:49:56] hrm, interesting hack, countries XX => true [18:50:03] use a numeric array an any level to indicate different sets of supported conditions [18:50:07] awight: ooh, right [18:50:23] so blacklisting would be XX => false... but how would you specify, 'all except' ? [18:50:51] I did that to allow combining the method and submethod overrides with a simple array_replace_recursive, but you're right, there are a lot of other cases we need to support [18:51:44] So yeah, maybe countries and currencies just come out of the define_payment_methods entirely and live in settings [18:51:54] with the formSettings syntax [18:52:08] This might work... then the gateway top-level spec would list all countries they have integrated in [18:52:56] or if there's no countries array on any level, we just move down to the next sublevel [18:54:29] adapters might not even need getCurrencies [18:54:31] Not sure what you mean--that we should assume that an empty countries list means, "all"? [18:54:34] That would work [18:54:42] well, maybe not [18:54:59] yeah, that was my thought [18:55:03] cos then a method that has a specific whitelist would be silently defaulting to all. [18:55:13] hrm [18:55:15] ok [18:55:45] just seems annoying to have to list the whole set up top when each submethod has its own whitelist [18:56:00] I think array_merge_recursive might do the right thing if we use K4-713's +/- syntax [18:56:11] oh yeah? [18:56:17] cool [18:56:29] it's such a stupid library function... lemme double-check [18:56:57] ... [18:57:23] You're merging formsettings [18:57:24] ? [18:57:51] K4-713: formsettings won't mean much when we're all using one unified form [18:57:53] yeah, so if we cascaded gateway+method+submethod countries lists, we would get a whitelist and blacklist of everything listed at each level [18:58:00] ejegg: Uhh... [18:58:06] so we're making it more like gateway payment method settings [18:58:11] K4-713: currently, we're thinking the GatewayFormChooser continues life as "GatewayChooser" [18:58:17] So, sometimes this talk of unified forms freaks me out. This is one of those times. :p [18:58:29] hehe [18:58:37] You... can't torpedo named form A/B testing. [18:58:57] Yeah, the ffname would be like a style override [18:59:02] https://github.com/sparkfun/SparkLib/blob/master/lib/SparkRecord.php#L12 [18:59:02] okay [18:59:10] we laughed about those array_ builtins a lot [18:59:10] so we'd maybe have a whitelist of those still [18:59:16] the-wub currently does something like appeal= to hack in CSS [18:59:41] cwdent: lol thanks [18:59:53] The other thing that freaks me out, is: Will there still be a place to see what happens for what combination of things, for all the combinations, in one place? And more to the point, change/override things we want to change/override really fast? [19:00:26] K4-713: we were thinking the list of currencies and countries for each payment method/ submethod / gateway still lives in settings [19:00:44] That doesn't tell me much about what the final form looks like, though. [19:00:52] K4-713: you food btw? [19:00:57] Are you here? [19:01:00] yep [19:01:02] okay then. [19:01:49] ejegg: I'm trying to grasp how white and black lists at each level interact... We'll have to decide something like "Order deny, allow" [19:02:22] heh. I was thinking the most specific level always overrode the less specific [19:16:24] Fundraising-Backlog: Pass name/email data from Silverpop to LP2 fields through URL - https://phabricator.wikimedia.org/T101019#1326851 (CCogdill_WMF) NEW [19:20:19] (PS1) Ejegg: Move