[01:01:54] (PS3) Cdentinger: WIP worldpay ESOP [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/234691 [01:02:25] (CR) jenkins-bot: [V: -1] WIP worldpay ESOP [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/234691 (owner: Cdentinger) [01:18:21] (CR) Cdentinger: WIP worldpay ESOP (1 comment) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/234691 (owner: Cdentinger) [02:23:19] (CR) Eileen: Annotate CiviCRM patches (1 comment) [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/235359 (https://phabricator.wikimedia.org/T99836) (owner: Eileen) [05:07:28] (PS1) Ori.livneh: Migrate to a terser cookie name and format [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 [05:08:31] (CR) jenkins-bot: [V: -1] Migrate to a terser cookie name and format [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 (owner: Ori.livneh) [05:10:27] (PS2) Ori.livneh: Migrate to a terser cookie name and format [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 (https://phabricator.wikimedia.org/T110353) [05:11:39] (CR) jenkins-bot: [V: -1] Migrate to a terser cookie name and format [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 (https://phabricator.wikimedia.org/T110353) (owner: Ori.livneh) [05:15:47] (PS3) Ori.livneh: Migrate to a terser cookie name and format [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 (https://phabricator.wikimedia.org/T110353) [05:16:25] (PS4) Ori.livneh: Migrate to a terser cookie name and format [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 (https://phabricator.wikimedia.org/T110353) [05:17:23] (CR) jenkins-bot: [V: -1] Migrate to a terser cookie name and format [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 (https://phabricator.wikimedia.org/T110353) (owner: Ori.livneh) [05:50:18] (CR) Eileen: "I've updated the Patches & readme with them. I will push those through too - although the coversation is a bit confusing when I do that :-" [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/235359 (https://phabricator.wikimedia.org/T99836) (owner: Eileen) [05:55:10] (PS3) Eileen: Annotate CiviCRM patches [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/235359 (https://phabricator.wikimedia.org/T99836) [09:09:28] TCB-Team-Fundraising-Sprint-2015-08-26, TCB-Team-Fundraising-Sprint-2015-09-02, TCB-Team: [WMDE-Fundraising] Remove unused templates from content staging wiki - https://phabricator.wikimedia.org/T110322#1605695 (WMDE-leszek) Looks rather fine. Below some remarks If I am not mistaken, these are still u... [09:39:43] TCB-Team-Fundraising-Sprint-2015-09-02, TCB-Team: [WMDE-Fundraising] Fix restoring archived template files in CMS wiki - https://phabricator.wikimedia.org/T111507#1605869 (kai.nissen) NEW a:kai.nissen [09:42:38] TCB-Team-Fundraising-Sprint-2015-08-26, TCB-Team-Fundraising-Sprint-2015-09-02, TCB-Team: [WMDE-Fundraising] Remove unused templates from content staging wiki - https://phabricator.wikimedia.org/T110322#1605908 (kai.nissen) Leszek is right, I found that out as well and while trying to restore L10h16, I... [09:48:16] TCB-Team-Fundraising-Sprint-2015-09-02, TCB-Team: [WMDE-Fundraising] Fix restoring archived template files in CMS wiki - https://phabricator.wikimedia.org/T111507#1605916 (kai.nissen) [13:20:17] TCB-Team-Fundraising-Sprint-2015-09-02, TCB-Team: [WMDE-Fundraising] Document current status of mobile tracking - https://phabricator.wikimedia.org/T111167#1606320 (WMDE-leszek) a:WMDE-leszek [14:54:15] Hi the-wub! How's it going? [14:54:39] I just added this to meta, hope to announce shortly on centralnotice-admins: https://meta.wikimedia.org/wiki/Help:CentralNotice/Changes_following_refactoring_%282015-09%29 [14:56:50] thanks AndyRussG, will take a look in a few minutes [14:58:21] the-wub: fantastic, thanks much!! :) [15:04:27] AndyRussG: Hi. [15:05:43] Glaisher: hi! [15:06:05] How's it going? [15:06:23] AndyRussG: Do you have time to look at a few CN patches? [15:06:50] nice work on the CN updates btw [15:07:53] Glaisher: thanks! it's been a long haul.... 8p I saw 4 patchest that you submitted, thanks so much for working on that [15:08:11] Haven't yet gotten to looking at them in detail, but initially they seem great [15:08:55] they are simple except one [15:09:20] I think I could get to them next week? Right now my priority is making some documentation on how the new client-side code is working [15:09:48] Alright. Thanks! :-) [15:11:19] Also, folks from the Performance team have been asking for changes to the new Banner History Logger system, which was deployed but not activated anywhere yet... If I get a chance to look at your patches sooner, I definitely will, and please don't let this delay dissuade you from submitting more ;) [15:11:53] BTW did you see the link to new Meta documetatnion above ^ ? If you have comments, it'd be fantastic to hear them :) [15:12:03] Sure, I understand. [15:12:11] I was just looking at that page! :P [15:12:18] Ah cool! [15:13:50] hey AndyRussG, the email and meta page look good to me [15:16:32] the-wub_: great, many thanks [15:49:36] (CR) AndyRussG: [C: -1] "Wow, that'll be a huge improvement, thanks so much!!" (2 comments) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 (https://phabricator.wikimedia.org/T110353) (owner: Ori.livneh) [16:06:54] (PS4) Cdentinger: WIP worldpay ESOP [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/234691 [16:07:36] (CR) jenkins-bot: [V: -1] WIP worldpay ESOP [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/234691 (owner: Cdentinger) [16:43:14] (CR) Cdentinger: [C: 2] "Does what it says" [extensions/DonationInterface] (amazon) - https://gerrit.wikimedia.org/r/235182 (owner: Ejegg) [16:43:42] (Merged) jenkins-bot: Quit validating that order_id is numeric [extensions/DonationInterface] (amazon) - https://gerrit.wikimedia.org/r/235182 (owner: Ejegg) [16:48:50] (CR) Cdentinger: [C: 2] "Cool idea!" [extensions/DonationInterface] (amazon) - https://gerrit.wikimedia.org/r/235293 (https://phabricator.wikimedia.org/T108123) (owner: Ejegg) [17:08:19] thanks for the CR cwdent! [17:09:16] I'm thinking more seriously about the comment at the bottom af tha adapter in that big final commit [17:09:50] you bet! [17:09:56] maybe go back and make Amazon act more like the other adapters [17:10:42] ejegg: is that 233993? [17:11:21] * awight alerts [17:12:09] hiya awight [17:12:19] mornin' [17:12:36] hi awight [17:13:20] cwdent: yeah, that one [17:14:02] awight: I think you had the right idea to use varMap and assocated trappings with Amazon [17:14:40] I just took a peek, it still seems tricky. Maybe there's something we can do to improve the encapsulation around api calls and error handling, that would benefit other adapters as well? [17:14:51] What do you think of adding a communication type sdk (maybe rename communication type to request format, and call it type array?) [17:15:24] We already discovered that the error map stuff is being stretched thin when we aren't simply making a payment. [17:15:26] Then either override curl_transaction or add a new base function [17:15:42] to use the sdk instead of curl [17:16:08] yeah, yr comment makes sense, but it doesn't seem quite right, I'm not sure other SDKs will play nice when we try to split the "staging" step from actually sending the request [17:16:35] Remind me what their SDK gives us, anyway? [17:16:55] Just signatures and curling? [17:16:58] Oh, the staging would still happen in do_transaction - it would call makeRequestArray [17:17:10] awight: mostly parsing their atrocious return format [17:17:13] hehehe [17:17:39] and makeRequestArray would call getTransactionSpecific value just like makeNameValueWhatever [17:18:04] I mean... That's a nice direction to go in for all the processors. GC XML stuff is unpleasantly coupled to how we describe and handle transactions. [17:20:31] There are things I'm afraid I'm skipping by avoiding do_transaction etc. for instance, there's a saveContributionTrackingData in do_transaction_internal that I maybe should add somewhere [17:20:41] yup [17:21:03] OTOH, do_transaction* is a mess, and the _internal thing was a hack from the beginning. [17:21:18] We could also break down those functions and make the side effects more clear [17:21:31] hrm [17:21:50] I was trying to make them less side-effecty with that paymentTransactionResponse deal [17:22:04] though they still finalize status sometimes [17:23:04] (CR) Cdentinger: [C: 2] "tests pass" [extensions/DonationInterface] (amazon) - https://gerrit.wikimedia.org/r/235369 (https://phabricator.wikimedia.org/T108123) (owner: Ejegg) [17:23:30] (Merged) jenkins-bot: Move Amazon test responses into their own files [extensions/DonationInterface] (amazon) - https://gerrit.wikimedia.org/r/235369 (https://phabricator.wikimedia.org/T108123) (owner: Ejegg) [17:23:32] (Merged) jenkins-bot: Allow callables in GatewayAdapter::$error_map [extensions/DonationInterface] (amazon) - https://gerrit.wikimedia.org/r/235293 (https://phabricator.wikimedia.org/T108123) (owner: Ejegg) [17:23:36] i am out this afternoon btw, driving to santa fe [17:23:39] filed pto [17:24:09] oh nice, i hear it's really pretty there [17:24:54] We should break out: buildRetryData, runPreProcessHooks, runPostProcessHooks [17:25:01] yeah it's awesome, my parents live there [17:25:08] d'argh, pretty much nothing in do_transaction_internal belongs there [17:26:14] things are looking pretty good with WP, but i have a feeling we're going to have to cram cdata tags into the xml [17:26:31] which looks like kind of a bitch because there are a few layers of indirection [17:26:44] oh damn, i thought they were offering to add those [17:26:48] in order to get them in there unescaped [17:27:05] ejegg: yep but their input also chokes on an encoded & :P [17:27:23] aw jeez [17:27:28] screw that [17:27:49] we alrady have to do some encoding dance 'cause they can't speak unicode [17:27:51] it was funny, our url builder was building a url with 2 ?s instead of ? then & [17:28:01] for a url query [17:28:01] awkward [17:28:20] so i fixed it and then the api fell over [17:28:29] LOL [17:28:34] did you hit the jackpot? [17:28:49] 100 tokens [17:30:18] ejegg: Does it make any sense to go lower-level for now, and use their SDK just to parse the response? [17:31:07] Hmm, let me see how much of a pain that would be [17:31:21] speaking of that i rolled a crappy url builder here but am i duplicating? https://gerrit.wikimedia.org/r/#/c/234691/4/worldpay_gateway/worldpay.adapter.php [17:31:30] I hate that we're using a member variable to pass the transaction response [17:31:49] cwdent: yeah, php has that [17:32:22] http://php.net/manual/en/function.http-build-query.php I think [17:32:37] awight: we're doing that a lot less this year! [17:32:48] yes, huge little steps! [17:33:04] awight: that http stuff isn't in core so i wasn't sure [17:33:15] oh? looking [17:33:39] weird, yeah only one reference in work/mediawiki-core/includes/libs/MultiHttpClient.php [17:33:42] erm [17:33:58] probably has historical reasons due to back compatibility [17:35:18] there's also wfAssembleUrl [17:35:27] gross, nvm [17:35:49] i love how random php is [17:36:00] parse_str means parse url query [17:36:06] into an array [17:36:18] it's evil [17:36:23] and it takes an array as the 2nd argument that it works on [17:36:27] wat [17:36:45] Probably worthwhile to ask about http_build_query in #wikimedia-dev [17:38:13] I think it's fine to use, though. If it's at all helpful. [17:38:59] cwdent: charming gotcha: https://gerrit.wikimedia.org/r/#/c/106624/ [17:40:37] ah ha [17:40:39] annoying [17:40:55] awight: I don't think it's worth going low-level on the request. There are a few special cases that will be annoying, and the beginning of the response parsing is wrapped up in the same private function that invokes the post. [17:41:44] k [17:41:46] http://docs.hhvm.com/manual/en/ref.http.php [17:41:53] looks like everything is built in to hhvm [17:42:03] but this would be on payments which is zend? [17:42:36] yeah, for this season at least [17:43:03] also... http_build_str and http_build_url "NOT SUPPORTED IN HHVM" [17:43:14] do you see build query? [17:46:55] ejegg: What do you think about do_transaction_internal? I'm still leaning towards cutting that apart as being the lowest friction way to decouple us from curl [17:47:07] oh haha, why are they in the docs then? [17:47:50] ... like you said, building the request and parsing the response could be less hardcoded. [17:48:32] so, buildRequestData then doRequest? [17:48:57] cwdent: seriously. That exact issue has been killing me. Also, I wish I could make the compiler barf on unsupported functions, rather than waiting for possible runtime errors. [17:49:06] ejegg: cool! [17:49:17] And the response functions could all use a tune-up [17:49:45] awight: yeah, ok, shrinking that down could be a good step [17:50:18] awight: no kidding [17:51:26] I'll work from master with this stuff to keep abreast of other changes as they merge [17:51:46] session_pushRapidHTMLForm <- *blinks* [17:51:54] blech [17:52:05] i have no idea just what that does [17:53:44] oh, supposedly takes care of ffname when the request has none [17:54:04] We need to keep that functionality [17:54:20] ohhhh, that's why it was just amazon logspamming on return way back when [17:54:39] coz it never pushed ffnames, special snowflake that it was [17:54:55] It should be transparent, though. Every time you load a good form, that fact should be recorded somewhere accessible. [17:55:05] yeah [17:55:45] and it does that... at the end of RapidHTML::set_html_file_path (??) [17:55:56] I simply don't understand this, $this->transaction_response->setRedirect( $this->url ); [17:56:04] which amazon wasn't reaching [17:56:08] How can we say that before doRequest? [17:56:21] yeah, the way Amazon is written should be fine, for all processors. [17:56:21] where are you seeing that? [17:56:46] oh, huh [17:57:42] Aah, it's short-circuiting the entire transaction and saying, yes it was successful and they said, go to this URL [17:57:44] maybe stuff happened in preProcess? [17:58:21] derp. This is when an API is executed by the donor's browser, so yeah there's no CURL [17:58:32] pretty freaking opaque how that url var was supposed to be set though [17:58:35] nice edge case [17:58:44] Could use a comment [18:01:41] oh hey, speaking of http_build_query, paypal.adapter is using it to build the redirect url [18:02:32] ah ha, that's just what i was messing with [18:02:34] but WP [18:03:04] i'm not sure if it's the redirect url or the postback url [18:06:26] I forgot to write comments there. see PaypalAdapter.getCommunicationType() [18:06:33] all these apis are redirects [18:09:22] * AndyRussG waves [18:09:43] wow, we really query and update contribution tracking tables every time through do_transaction_internal, and when generating order id, and when we create a new DonationData, AND whenever we call addData on DaonationData??? [18:09:57] hi AndyRussG ! [18:10:06] :) [18:10:27] Hi! Any more comments on the centralnotice-admins doc? I could send the announcement w/ out much ado [18:11:24] so, i'm getting my contribution tracking saved for free when I call addRequestData with donor name and email... [18:12:24] seems like a lot of strain to put on our SPOF [18:12:33] ejegg: I'd like to split contribution tracking into two things, * An global sequence * A history of events attached to this id [18:13:15] including every time the associated data changes? [18:13:23] It's not tremendous strain, and load is pretty much proportional to # of donors [18:13:45] A few dozen per second [18:14:01] yeah, just seems like we must be reading and writing the same table at least 3-4 times in each request [18:14:05] But let's use php-queue-Redis for that, too. [18:14:37] AndyRussG: hi! Lemme read that thread [18:14:46] thanks! [18:15:06] Sorry to interrupt what seems like an important discussion that I'm not able to contribute to 8p [18:16:37] That reads real well. Documentation is brilliant, too! [18:16:49] Maybe link to an example campaign where we use the new features. [18:19:21] You could say "CentralNotice 2.6" in the release notes [18:20:07] Thanks! good points :) [18:21:33] Hmmm though actually its a config we don't really want to encourage... [18:21:40] it's [18:21:44] It's very usable. I'm really excited now about the banner diet mixin, too. [18:22:07] Yeah! Really glad u like it [18:22:22] Just gotta tease out the details of functionality [18:22:33] And add some hooks in there for making the UI nicer [18:22:47] If you'd like, I can take a stab at the mixin, I'd curious to see what the interface looks like from an implementor's POV [18:23:11] awight: Sure, that'd be amazing :) [18:23:16] alright! [18:24:07] On that side, I've so far found it usable and fine though nothing extraordinary... But MVP works is good, I think ;p [18:24:59] (PS1) Awight: Remove legacy config [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/236058 [18:25:17] wow, I didn't have a .gitreview for my local CentralNotice repo. It's been that long! [18:25:34] * awight hugs AndyRussG [18:28:48] AndyRussG: I agree that we should carefully spec out requirements for the diet module, all I'm gonna do for now is replicate existing diet features, if that makes sense to you? [18:29:02] Sure [18:29:12] * AndyRussG hugs everyone back [18:29:16] :D [18:29:55] Heh you may not have a CentralNotice/.gitreview, but I don't even have a working DI, so also thanks for staying on top of that! [18:30:07] (PS3) Ejegg: KVStore: remove error cookie [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235667 (owner: AndyRussG) [18:30:49] (CR) Ejegg: [C: 2] "Good implementation of a necessary change!" [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235667 (owner: AndyRussG) [18:31:02] Wee thanks ejegg :) [18:31:30] Heh, seems like we want to get that out before setting too many two year cookies! [18:31:53] And that documentation is really good! [18:32:32] Why do we have this cookie at all? [18:32:38] Can we do without it? [18:32:49] Is it just the fallback for localstorage? [18:33:14] it was keeping track of how often localstorage errors occur [18:33:27] (Merged) jenkins-bot: KVStore: remove error cookie [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235667 (owner: AndyRussG) [18:33:27] If we do go with an ultracompact cookie, please include an API version number [18:33:44] that change got rid of the cookie entirely [18:33:50] ejegg: right. hehe /me calms down [18:34:27] (CR) AndyRussG: "Cool! Just one question..." (1 comment) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/236058 (owner: Awight) [18:34:29] oh, but should we maybe version the stuff we're dumping in localstorage? [18:34:48] i think definitely yes [18:34:58] y [18:35:07] ejegg: thanks [18:35:19] otherwise, future code will start with isset(version) [18:35:22] awight: ejegg: yes, that's the other follow-on patch before we do another deploy [18:35:38] Ahh no wait, version? I was thinking TTL [18:35:39] Hmmm [18:35:52] Yeah version is also a great idea... [18:36:49] Yeah w/ the change instead of storing localStorage errors, we just mention there was one when we send a log sample [18:36:56] Keeping both is nice, yeah. TTL is already covered by cookie expiry? [18:37:24] awight: ttl on the log entries in localStorage, not cookie [18:39:11] bummer there's no expiration in the localStorage API [18:39:44] gotta add timestamps and periodic sweeps [18:39:51] yeah! what an oversight [18:40:10] It must have been discussed... I'm morbidly curious what the design rationale was [18:42:32] whoa, for a while you could set globalStorage to share data with other sites! [18:42:39] ok guys i gotta get on the road. have a good weekend! [18:42:49] Have a good trip cwdent! [18:43:01] thanks! [18:45:04] fundraising-tech-ops, operations: build libanon package for trusty - https://phabricator.wikimedia.org/T110739#1609735 (Krenair) [18:45:18] cwdent|afk: cya! [18:55:25] Turns out, expressing the fullscreen thing is difficult. I might punt that part to a second mixin [19:00:40] (PS1) Ejegg: Add version to banner history log entries in KV store [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/236069 [19:04:28] awight do you have a minute for a sql sanity check? legal is asking for a # so I want to make sure it’s right [19:04:38] also hello! :) [19:04:40] fundraising-tech-ops, operations: reformulate kafkatee package to work with Trusty - https://phabricator.wikimedia.org/T110591#1610291 (Ottomata) Done https://gerrit.wikimedia.org/r/#/c/236066/ http://apt.wikimedia.org/wikimedia/pool/main/k/kafkatee/ [19:07:48] (PS1) Awight: Disable some unused banner mixin form elements [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/236070 [19:08:32] ccogdill: yes I do, and hi! [19:09:00] awesome, thanks awight. trying to get the total $ from Illinois in FY 13-14 [19:09:04] here’s my query: select sum(cc.total_amount) from civicrm_contribution cc LEFT JOIN civicrm_address a ON cc.contact_id = a.contact_id LEFT JOIN civicrm_state_province s ON a.state_province_id = s.id WHERE cc.receive_date >='2013-07-01' AND cc.receive_date <='2014-06-30' AND s.abbreviation = 'IL' AND a.is_primary = 1; [19:09:57] I’m basing this off a query I used about 6 months ago… can’t remember why I used left joins. so I wasn’t sure about this one [19:15:09] ccogdill: don't trust the state data btw. At least, before you use it you should do a basic check for data quality, maybe by counting what proportion of people in FY 13-14 had state data at all. [19:15:26] well [19:15:53] I didn’t totally trust it so I modified the query like so: select sum(cc.total_amount), s.abbreviation from civicrm_contribution cc LEFT JOIN civicrm_address a ON cc.contact_id = a.contact_id AND is_primary = 1 LEFT JOIN civicrm_state_province s ON a.state_province_id = s.id JOIN civicrm_country u on u.id = a.country_id WHERE cc.receive_date >='2013-07-01' AND cc.receive_date <='2014-06-30' AND u.iso_code = 'US' GROUP [19:15:54] s.abbreviation; [19:15:57] and the output was weird [19:16:24] I get $33.8 million NULL plus all the states, whose $ adds up to about $25 m [19:16:42] so what should I give legal? :/ [19:16:56] oh cool, so you did exactly that already [19:17:13] fundraising-tech-ops, operations: package udp-filter for Trusty, for use on fundraising banner_logger - https://phabricator.wikimedia.org/T110592#1610336 (Ottomata) Hm, Jeff, both udp-filter and libanon are installed from packages on stat1002, which is a Trusty box. I just tried it with both anonymizatio... [19:17:57] yeah and those #s dont make any sense altogether. I can’t figure out what that Null means. but I also didn’t know how to best rewrite it [19:17:58] so... perhaps you could multiply the number you give legal by a guess factor, based on how many people with state info are from IL. and tell legal you mathed [19:18:51] "null" means that you left joined between a contribution and the state names, but the contribution didn't have any state info, [19:19:08] but the NULL + state data equals twice as much as what we recorded raising in FY 13-14 [19:19:13] per https://docs.google.com/spreadsheets/d/1PCOiU0A-5Cb8BLbxm26Wz5FNNWCyO4pKMKRDunPbZU0/edit#gid=6 [19:19:25] Does 33.8 + 25 add up to the real total $? [19:19:32] oic [19:19:48] so that’s why I was hoping to just throw out the nulls... [19:19:50] lemme look at the queries, then [19:20:00] hehe that would be incredibly sketchy [19:20:10] sorry :( I thought this would be simple and then it wasn't [19:20:20] it's fun, no worries! [19:20:26] haha [19:21:17] I dig this stuff too. One of these days I'm going to have to learn enough about that database to help you kick it around. [19:22:06] I have to agree it’s fun! until you hit a road block [19:22:13] the more, the merrier :p [19:22:58] Indeed [19:23:50] wow, you remembered is_primary. That one bites me *every* time [19:24:02] I think you’ve drilled it into my head enough times [19:25:44] Ah, to be young :p [19:39:15] ccogdill: Oh tricky, maybe it was because of the left join on address, but inner join on country. I can imagine that would cause weird unknown country cases to fall into the null state group [19:39:37] ah [19:39:53] so left join the country too? [19:42:45] hmm that didn’t change the output [19:42:53] no... I think inner join the address, trying it myself [19:43:58] I see 52 states :) [19:44:17] hey, they're real things! [19:44:39] * awight tears up at colonial patria [19:44:51] haha [19:45:01] whew [19:46:11] so take off the left join for address but keep the left join for state_province? [19:46:32] ccogdill: hehe, I think I found a simpler explanation: the sum of all null state donations was actually 3.38 $M [19:46:48] :| [19:47:01] awkward :p [19:47:05] yeah… [19:47:27] whoops. so does that mean I had the correct data all along? [19:47:40] yeah... so *cough* just say IL was probably like 5% higher cos of the donations we don't have state info for. [19:47:51] okay thank you [19:47:54] lemme get the exact multipler [19:47:57] * ccogdill goes and hides in corner [19:48:27] hahaha you'd done all the work already [19:52:03] well thank you for pointing out the obvious. sorry for the time suck! [19:52:35] I get, 1,269,492 donations with known state, of which 47,998 or 3.78% are from IL. We can guess that of the 254,539 unknown donations, 9,600 are really from IL, and without adjusting for per-state average donation variations, that would be about 3.38M$ x 3.78% = $130,000 additional bucks [19:54:42] awesome [19:55:04] I’ll put this on fun sql soon, promise [20:00:17] AndyRussG: Do you think it's worthwhile to make the mixin backwards-compatible with existing BannerShowHideCountDate.js cookies? [20:00:47] awight: yes sounds good! I think they have the cookie names as parameters... [20:01:19] That part is gross, looking forward to abstracting that to "count group" or something once we own the code. [20:01:37] awight: btw some more food for thought: make it not use cookies, but the KV store, and only use the cookie as a fallback bwahahahaha [20:01:59] mentioned the idea here BTW https://phabricator.wikimedia.org/T110353 [20:02:59] I think if I'm doing a purely migrational step in the evolution of this feature, I should just port the onwiki js [20:03:07] * awight dashes for headphones [20:07:04] Hangouts hates me, one sec. [20:58:04] (PS5) Ori.livneh: Migrate to a terser cookie name and format [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 (https://phabricator.wikimedia.org/T110353) [20:59:27] (CR) jenkins-bot: [V: -1] Migrate to a terser cookie name and format [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 (https://phabricator.wikimedia.org/T110353) (owner: Ori.livneh) [21:00:08] (PS6) Ori.livneh: Migrate to a terser cookie name and format [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 (https://phabricator.wikimedia.org/T110353) [21:01:17] (CR) jenkins-bot: [V: -1] Migrate to a terser cookie name and format [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 (https://phabricator.wikimedia.org/T110353) (owner: Ori.livneh) [21:05:07] (PS7) Ori.livneh: Migrate to a terser cookie name and format [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 (https://phabricator.wikimedia.org/T110353) [21:05:31] (CR) Ori.livneh: "The QUnit failures are due to a flapping test, and are not related to this change." [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 (https://phabricator.wikimedia.org/T110353) (owner: Ori.livneh) [21:12:30] (PS10) Ejegg: Handle errors in Amazon API calls [extensions/DonationInterface] (amazon) - https://gerrit.wikimedia.org/r/233993 (https://phabricator.wikimedia.org/T108123) [21:12:48] (CR) Ejegg: "PS10: WS" [extensions/DonationInterface] (amazon) - https://gerrit.wikimedia.org/r/233993 (https://phabricator.wikimedia.org/T108123) (owner: Ejegg) [21:25:55] (CR) AndyRussG: Migrate to a terser cookie name and format (1 comment) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 (https://phabricator.wikimedia.org/T110353) (owner: Ori.livneh) [21:27:40] is there any fr tech type maint going on? we are seeing a bit of flakying on https://payments-listener.wikimedia.org/globalcollect and https://frdata.wikimedia.org endpoints [21:28:38] (PS1) Ejegg: WIP move subscription cancel into its own script [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/236204 (https://phabricator.wikimedia.org/T110917) [21:28:56] chasemp: No code changes there... The error seems to be, "Connection to the server failed" [21:39:18] ooh, payments.error is the slimmest I've ever seen it on a day with money coming in [21:46:01] It's not healthy to lose weight so quickly... [22:16:16] bah, still not letting me end a subscription with nothing pending on it. saying end_order is not possible in this state. [22:17:25] I wonder what get_order says? [22:17:45] Sounds like a valid question to put to GC, either way [22:18:12] It would make sense to let us cancel orders before the refunds settle, IMO [22:18:46] yeah [22:18:58] OK, let me dig up an email address [22:27:06] (PS8) Ori.livneh: Migrate to a terser cookie name and format [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 (https://phabricator.wikimedia.org/T110353) [22:28:08] AndyRussG: s/Legacy support/Legacy hiding and impression counting support/ ? [22:28:11] (PS9) Ori.livneh: Migrate to a terser cookie name and format [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 (https://phabricator.wikimedia.org/T110353) [22:28:54] awight: hmmm... dunno, maybe it's something to evolve and keep around later? Or will it always be legacy? [22:29:04] (CR) jenkins-bot: [V: -1] Migrate to a terser cookie name and format [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 (https://phabricator.wikimedia.org/T110353) (owner: Ori.livneh) [22:30:39] (PS2) Ejegg: WIP move subscription cancel into its own script [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/236204 (https://phabricator.wikimedia.org/T110917) [22:36:05] Nah, it seems like legacy and headed for the dump. But maybe it's worthwhile to distinguish this field group from other legacy things? [22:43:45] Am I misreading this? BannerShowHideCountDate.js doesn't impose a maximum limit on the number of impressions an individual sees, it's a cycle that can be repeated forever? [22:43:50] the-wub: if you're around, ^ [22:46:24] Looks like recent banners are restarting the cycle one a month. [22:49:07] (CR) AndyRussG: [C: -1] "Nice!! Almost there, I think... :D" (1 comment) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 (https://phabricator.wikimedia.org/T110353) (owner: Ori.livneh) [22:49:45] awight: yes, that's intentional. users should see at most one banner per month [22:50:09] awight: taking a peek [22:50:20] in practice they might not even see that, as we have the campaigns throttled, and they have to 'wait' for 5 impressions [22:52:16] the-wub: cool. I'm trying to port existing logic to a campaign mixin, just making sure I understand it. [22:52:30] Which hiding methods are currently in use? [22:52:46] Just this and the fullscreen -> slim thing? [22:54:02] Yep, BannerShowHideCountDate.js and https://meta.wikimedia.org/wiki/MediaWiki:FR2014/Resources/ShowHideCheckFullscreen.js [22:55:18] oh also there is https://meta.wikimedia.org/wiki/MediaWiki:CentralNotice/Resources/MaxViews.js which is a simpler one used for some community campaigns [22:56:25] Great to hear there isn't some funky inline js out there! [22:57:18] awight: the-wub: yes the public policy campaign has that last one [22:57:49] the-wub: is there some on-wiki place I should mention the CN update, or anywhere other than the centralnotice-admins mailing list? [22:58:03] This actually works, which is really nice: https://meta.wikimedia.org/wiki/Special:WhatLinksHere/MediaWiki:CentralNotice/Resources/MaxViews.js [22:58:40] AndyRussG: I know, I made it :P so do the android app banners [22:59:10] AndyRussG: I can't think of anywhere on wiki... [22:59:24] ahhh right! [22:59:29] the-wub: Mind if I make a single mixin, that includes a way to disable the wait cycling stuff? [22:59:54] AndyRussG: the CN calendar could include releases and link to release notes [23:00:03] sure awight, whatever you think is best [23:00:23] Yeah I was gonna say, maybe the talk page of some CN campaign calendar? also maybe some news page that meta folks tend to read? [23:00:38] oh, also there is https://meta.wikimedia.org/wiki/MediaWiki:CentralNotice/Resources/MinEditsMaxViews.js which isn't being used currently but might be useful in future [23:00:46] awight: ^ [23:01:52] awight: ooh that links-to page is cool [23:02:05] maybe min-edits is a second mixin, though? [23:02:15] That's weird, what's the rationale for it? [23:02:50] "Inspire" campaign. hum [23:02:57] yeah, would make sense. we don't need it right away though, in fact I could probably manage to write that myself at some point. [23:03:15] just to target more experienced editors. that was a grants campaign [23:03:25] awight: why not go all the way? make a single mixin that provides all the functionality except the fullscreen, make it start using localstorage and a cookie only as a fallback, and include a migration script¡ [23:03:27] ? [23:04:22] I'm definitely leaning towards the last part, to migrate cookies into localstorage as we go. [23:04:32] min-edits really does seem unrelated, though [23:04:49] Ah yeah that should be separate [23:05:09] Yeah they don't interact [23:05:57] I was reading the coments on performance's remove cookie phab task, it seems like they're a real draw. Something about bytes being more expensive because of tcp negotiation or munchkins or something [23:06:01] cookie bytes that is [23:06:03] hahah [23:06:23] * AndyRussG laughs at unintended puns [23:08:23] http://cdn.meme.am/instances/53885117.jpg [23:10:12] ohnoes we hid them to do away with child obesity [23:11:14] http://images.sodahead.com/polls/000799559/polls_6a00d8341c591153ef0120a60cac2b970c_800wi_5744_128805_answer_1_xlarge.jpeg [23:12:01] There is a thriving meme community behind these otherwise unfunny, spongy cookies [23:12:43] rrrg no wonder performance hates 'em [23:35:27] Have a great weekend, folks! [23:40:01] bye! [23:41:57] (PS1) Awight: WIP Banner diet mixin [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/236229 [23:42:14] I have a kid up in my business, might not surface again until late... [23:42:50] AndyRussG: nothing much to see in my patch, but I've added a helpMsg field [23:43:04] needs padding. [23:43:18] (CR) jenkins-bot: [V: -1] WIP Banner diet mixin [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/236229 (owner: Awight) [23:43:41] ah k [23:43:58] ejegg|away: cya! [23:44:33] see you next week! [23:44:35] awight: fun stuff! (the patch :) ) [23:44:49] awight|brble: enjoy the weekend! [23:44:59] (PS10) Ori.livneh: Migrate to a terser cookie name and format [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 (https://phabricator.wikimedia.org/T110353) [23:45:58] you too, don't have any banner history nightmares! [23:46:09] (CR) jenkins-bot: [V: -1] Migrate to a terser cookie name and format [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 (https://phabricator.wikimedia.org/T110353) (owner: Ori.livneh) [23:51:29] (PS11) Ori.livneh: Migrate to a terser cookie name and format [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 (https://phabricator.wikimedia.org/T110353) [23:54:37] (CR) AndyRussG: "Thanks....!!! Hmmm still the same test issues, also locally on Special:JavaScriptTest (inconsistently, though, gotta refresh a bunch of ti" (1 comment) [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 (https://phabricator.wikimedia.org/T110353) (owner: Ori.livneh) [23:57:00] (CR) AndyRussG: [V: -1] "Same test issue on PS11" [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/235979 (https://phabricator.wikimedia.org/T110353) (owner: Ori.livneh)