[00:05:36] (PS1) Ejegg: Replace donatewiki counts table with view [wikimedia/fundraising/tools/DjangoBannerStats] - https://gerrit.wikimedia.org/r/259623 (https://phabricator.wikimedia.org/T114010) [00:06:57] (CR) Awight: [C: -1] "Needs manual rebase... V-1 just as a reminder of that." [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/254364 (https://phabricator.wikimedia.org/T116317) (owner: Eileen) [00:07:07] (CR) Awight: "err, CR-1" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/254364 (https://phabricator.wikimedia.org/T116317) (owner: Eileen) [00:08:41] ejegg: would you call Mustache.php the "controller" or the "viewmodel" or something like that? [00:10:16] cwd I'd call it the controller [00:10:32] and the data context the viewmodel [00:11:28] cool yeah [00:11:39] just thinking about, if it gets huge, how we'd want to split it up [00:12:07] it's not bad yet but i could see it becoming responsible for a lot [00:13:11] we might end up wanting to namespace the template data somehow? [00:14:14] (PS7) Cdentinger: mustache l10n [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/258099 (https://phabricator.wikimedia.org/T120992) [00:15:07] ^ proof of concept for actually switching on country, required some minor rearranging [00:16:23] ejegg: oh also, i responded here: https://gerrit.wikimedia.org/r/#/c/258099/5/gateway_forms/Mustache.php but it got paved over by new PS [00:16:56] oh cool, lemme take a look! [00:23:33] cwd we can use nested objects in the data context, right? [00:24:08] ejegg: yeah i think mustache uses dot syntax? [00:24:17] afaik, yah [00:24:47] (CR) Awight: "This looks great! I'd like to poke at it a bit, will get back to you in a few..." (2 comments) [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/258099 (https://phabricator.wikimedia.org/T120992) (owner: Cdentinger) [00:25:07] that dot thing absolutely kills me [00:25:23] I think it's a lightncandy bug actually--you can't get any variables outside of the conditional variables's scope [00:25:36] switching machines... [00:30:52] (CR) Eileen: "I thought about that - but not getting or setting custom data via the api when check_permissions=0 (the default behaviour for php) is a le" [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/258918 (https://phabricator.wikimedia.org/T121284) (owner: Eileen) [00:40:15] (PS2) Eileen: Add upgrade hook to remove duplicate 'Refunded' contribution status [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/254364 (https://phabricator.wikimedia.org/T116317) [00:46:23] (PS3) Eileen: Add upgrade hook to remove duplicate 'Refunded' contribution status [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/254364 (https://phabricator.wikimedia.org/T116317) [00:48:52] (CR) Eileen: "I've incremented the update version. Note it won't run on staging because in my previous testing I took the version on staging too high :-" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/254364 (https://phabricator.wikimedia.org/T116317) (owner: Eileen) [01:31:04] Hello all [01:45:04] Fundraising-Backlog, MediaWiki-extensions-CentralNotice: Wrap calls to LocalStorage in try/catch block to prevent exceptions for the cookieless - https://phabricator.wikimedia.org/T121738#1886702 (AndyRussG) NEW [01:51:57] Fundraising Sprint Zapp, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Unplanned-Sprint-Work, Patch-For-Review: Need to see UTM Source/UTM Campaign in Civi - https://phabricator.wikimedia.org/T121284#1886734 (Eileenmcnaughton) The upgrade script is pending deploy now - @awight - I think i... [03:41:55] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: Deleted contacts: contributions tab has a count, but no contributions appearing - https://phabricator.wikimedia.org/T121717#1886782 (Eileenmcnaughton) I tried to replicate this elsewhere but was unable to replicate on civicrm demo sites or on my local (... [12:05:28] Fundraising-Backlog, Continuous-Integration-Config: Continuous integration: wikimedia/fundraising/tools/DjangoBannerStats needs V+2 jobs - https://phabricator.wikimedia.org/T121723#1887317 (hashar) Looks like a django plugin, so we could bring in a specific Django version in the test environment and appa... [12:05:45] Fundraising-Backlog, Continuous-Integration-Config: Continuous integration: wikimedia/fundraising/tools/DjangoBannerStats needs V+2 jobs - https://phabricator.wikimedia.org/T121723#1887319 (hashar) p:Triage>Normal [13:54:33] (PS2) Zfilipin: Update mediawiki_selenium Ruby gem to the latest version [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/259511 (https://phabricator.wikimedia.org/T114241) [15:33:16] Fundraising Sprint Yo La Tengo, Fundraising Sprint Zapp, Fundraising-Backlog, MediaWiki-extensions-DonationInterface, and 2 others: Globalcollect Status 25/404 errors - https://phabricator.wikimedia.org/T120030#1887645 (MBeat33) The latest from GC is: // The session logs didn't reveal any trends r... [15:50:21] Fundraising-Backlog: Include URL of error page in mailto: link when donation fails - https://phabricator.wikimedia.org/T117271#1887667 (atgo) @awight probably donatewiki, but basically any time we show an error page. [16:43:13] (CR) Ejegg: "Works fine locally, though I'm not sure we should be letting people choose 'Outside...' XX states/provinces." [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/258099 (https://phabricator.wikimedia.org/T120992) (owner: Cdentinger) [17:00:51] from Twitter, in response to tweet about the aggressive banners: "more like Gimme Wales". [17:01:02] probably not new, but new to me. [17:01:03] :) [17:35:53] hey, do you by any chance have an email/doc about how it’s not our problem PCI-wise if people send us CC#s? we track these tickets and I’m wondering if we really need to [17:35:57] awight [17:36:56] Hi! [17:37:13] I'm certain of that fact, but lemme try to find some CYA documentation... [17:38:34] MBeat: https://collab.wikimedia.org/wiki/Fundraising/Engineering/PCI_Questions#For_Donor_Services [17:38:44] TY [17:42:03] Do donors get crazier as the month goes on? [17:42:59] sending your full card # in an email subject line might be crazy, yes [17:43:46] hehehehe [17:43:59] Very open and collaborative spirit, though [17:44:04] that's some enthusiastic giving [17:47:06] true, hard to find too much fault with the intention [17:49:03] hey AndyRussG [17:49:08] atgomez: hi! [17:49:12] morning~ [17:49:15] or afternoon, for you [17:49:28] heh rainy day afternoon [17:49:46] Almost the shortest day of the year, too! It'll be dark in like 3 hours [17:49:52] oy [17:49:59] oigo [17:50:20] so AndyRussG did you see meganhernandez's email about the impressions? [17:50:23] Yep [17:50:49] (just a few minutes ago... I got back from the dentist a little while ago actually) [17:50:58] aww [17:51:18] eh it's OK. Just a surprise root canal! I go back tomorrow for the filling [17:51:19] so i'm meeting with her in 10 min - anything i should tell her besides to wait for a response? [17:51:24] EE! terrible. [17:51:42] Heh it's the first time I've had one. Could be worse. Feels weird... [17:51:52] is it numb….? [17:51:56] Completely [17:51:59] ahhh [17:52:02] yeah that's always weird [17:52:52] So yeah the first thing to do as per her e-mail is shore up whether or not we are in fact missing sending banners to some users [17:53:25] I had a tiny question about the banner impression stats--do the WMF pageview numbers include any "unique" counts? [17:53:27] I think we need a plan... Since there are a lot of possible routes, even so [17:53:42] awight: huh? [17:54:39] atgomez: We can talk to analytics and mobile teams for starters [17:54:54] Share the page w/ notes a more widely [17:55:23] ok, so we think there's some part that we don't understand [17:55:26] ...? [17:55:41] atgomez: just as in the e-mail, percentages are guesses [17:56:02] alright, so by collaborating with the other teams we'd try to sort out those percentages more exactly? [17:56:20] and see if there's a gap where it's coming from? [17:56:48] atgomez: exactly [17:56:51] cool [17:56:57] does that sound like the best next step to you? [17:57:08] atgomez: yes. also, we need to take more samples. Right now we're only looking at a single hour [17:57:18] ahhh [17:57:34] How and when and if that amoutn varies could also tell us a lot [17:57:55] Also we should do a regional (sub-country) breakdown, if possible. I think we can [17:58:15] ok [17:58:18] awight: what do u mean exactly by "unique countes" [17:58:19] ? [17:58:39] i'll pass this onto her verbally for now, and we can go from there [17:58:44] atgomez: cool thanks! [17:58:59] let's plan to send end of day daily updates though until this is resolved [17:59:05] atgomez: yeah a regional breakdown should give us clues as to whether it's network-latency related [17:59:16] ahhh rad [17:59:16] atgomez: yeah that makes a lot of sense [17:59:46] also also i'll see if she can help us get support from analytics [17:59:51] i'll work on reading/mobile :) [17:59:54] if you have any issues [18:00:15] atgomez: ah K... so you want to reach out there? I was thinking a first stab could just be some IRC messages [18:01:06] i think if you take a fast pass with IRC, that's great [18:01:25] but also she can let the managers of those teams know that we're digging at this, in case the other teams work is disrupted [18:01:28] atgomez: great! I'll let you know what comes of it, in case more is needed [18:01:31] thanks [18:01:36] cool [18:02:05] awight: cwd: XenoRyet: ^ also if u have any more suggestions on where to go with the impressions quest, please LMK. I'm worried that I may be chasing underground rabbits while missing something that's staring us in the face 8p [18:02:12] ejegg|nosh: ^ [18:10:22] AndyRussG: megan suggests including ellery and mikhail in the conversation as much as possible [18:10:56] atgomez: yep that sounds good [18:11:50] atgomez: Mikhail Popov, right? [18:13:00] atgomez: end-of-the day updates around 7 or 8pm Pacific Time are OK? [18:19:52] AndyRussG: Sorry, I'm busy dealing with more fallout from my letter yesterday x-p [18:20:07] AndyRussG: I was thinking that uniques would give you another useful data point. [18:20:47] Like, unique visitors to content pages vs. unique visitors to /beacon/impression [18:21:16] AndyRussG: yep yep! [18:23:57] AndyRussG: I still like the os_family limits better than access_method=mobile web, but that's all I can think of [18:23:59] awight: right.... K yeah indeed in some of the research there's talk about uniques [18:24:22] ejegg: ah K, noted, thx!! [18:24:43] numbers for some countries are much better that way, but for US it's only a few percent closer [18:24:54] ejegg: awight: cwd: XenoRyet: WRT something staring us in the face, I'm thinking maybe some dumb and obvious bug I've overlooked [18:25:02] ejegg: hmm! [18:25:28] boy, i am barely even familiar with the problem [18:25:44] sounds like it goes deep [18:26:27] AndyRussG: You've exhausted the device targeting silliness? [18:26:35] That's me as well. I'll do some noodling on it though, in case there's something that only unfamiliar eyes would see. [18:26:46] cwd: XenoRyet: amazing, thx! [18:26:59] Fundraising-Analysis, Analytics-Backlog: FR tech hadoop onboarding {flea} - https://phabricator.wikimedia.org/T118613#1888233 (Milimetric) [18:27:44] I think I remember numbers for different mobile browsers were fairly different. I'll see if I can narrow that down [18:27:46] awight: yes, unless there's a bug somewhere that causes some mobile browsers to not show banners only some of the time... Not unthinkable, but doesn't sound likely, I think [18:27:52] why do we gitignore vendor on DI master? isn't it a submodule in production? [18:28:32] cwd yeah, it's a submodule in the deployment branch [18:28:49] I think we wanted master commits to not require the multistep submodule dance [18:28:56] ejegg: on that, there's also some data in a spreadsheet that I attached to one of the e-mails, though that was before Ellery's more refined queries [18:29:38] ah, cool [18:29:41] ejegg: the pain in working manually with those is making the correlation table... We really should code that up [18:29:56] the correlation table? [18:30:15] Hmm I guess we could also just do a join like Ellery did on Hive! [18:30:31] (didn't know u could do that with Hive at the time) [18:30:36] yeah, I've just been doing variations of his query from the email [18:30:59] Seems like you can use almost all the SQL you want there - pretty handy! [18:32:14] Yeah, one column with a string concatenating browser family and major version number, then percentage of the total in pageviews for the time slot in one column, and percentage of total impressions in the time slot in the other column [18:32:43] AndyRussG: What I was imagining is that you could group results by the recordimpression "device" param, and compare that to the pageview UAs grouped by getDeviceCode() regex [18:33:20] cwd: yeah, we were following the precedent set by WMF MediaWiki deployment [18:33:27] So far I only highlighted discrepancies where it was 0 in impressions, but if it's 50% in pageviews and 10% of impressions in a big enough sample size, that'd be significant [18:33:32] awight: interesting! yeah [18:33:42] awight, ejegg: so donationinterface/deployment is a safe place to run composer update, once changes to composer.json are merged from master? [18:33:47] The known issue is that all "unknown" devices jut don't get banners. That could also change [18:34:35] cwd: hrm, we should document here: https://collab.wikimedia.org/wiki/Fundraising/Engineering#Deploy_Fundraising_Code [18:34:39] ejegg: awight: if u feel like sharing any notes on the collab page or the phab task, that'd be amazing :) [18:35:37] cwd: I think we're actually checking composer.json into master, right? [18:35:44] sorry--composer.lock [18:35:51] awight: yeah [18:36:04] just wondering cause some of the repos blow up if you composer install [18:36:31] so the flow is like, do composer update on master, but when deploying (in a separate directory!), only run composer install. [18:37:31] cool [18:37:35] makes sense [18:37:43] just gonna try this out: https://github.com/sokil/php-isocodes [18:38:16] cwd: have you looked at Extension:cldr? [18:38:37] awight: not closely, ejegg mentioned it...didn't have...something [18:38:45] i'll look into it [18:39:28] i think i've successfully adopted the workflow of editing all the extensions as submodules and not moving the extensions directory around [18:39:37] is there any reason not to do this? [18:39:43] It's fine to pull in a new library, but I'd suggest getting everything you can from cldr first. [18:39:52] Only using the new library for things that are missing. [18:40:37] yeah [18:40:54] well...if the only states we're missing are for AU this may be a premature optimization [18:41:22] I can certainly make another of those files in includes/ [18:42:02] cwd yeah, no subdivisions [18:42:23] ejegg: does subdivisions encompass states? [18:42:38] right, that's states/provinces [18:42:53] that sokil lib looks pretty good [18:43:05] yeah, it's got everything, and translations of everything [18:43:30] it's got the ISO codes as compound -, which is a little annoying but should be easy to split [18:44:03] Only thing left is the appropriate 'Select an X' dropdown prompy [18:44:06] *prompt [18:44:20] i like prompy [18:44:44] sounds like plumpy nut. Which is totally nothing dirty. [18:45:26] i heard a woman the other day use the "word" challengy in place of challenging [18:45:30] i had a hard time with that [18:49:06] <_ [18:49:09] >_> [18:49:27] TIL of pumpy'nut [18:49:31] pretty awesome [18:50:26] *l [19:04:26] Fundraising Dash, Fundraising Sprint Yo La Tengo, Fundraising Sprint Zapp, Fundraising-Backlog, and 2 others: Add numeric filters to common filter component - https://phabricator.wikimedia.org/T120678#1888281 (Ejegg) Open>Resolved [19:04:43] Fundraising Dash, Fundraising Sprint Yo La Tengo, Fundraising Sprint Zapp, Fundraising-Backlog, and 4 others: Dash: breakdown bars - https://phabricator.wikimedia.org/T86094#1888282 (Ejegg) Open>Resolved [19:05:54] Fundraising Dash, Fundraising Sprint Yo La Tengo, Fundraising Sprint Zapp, Fundraising-Backlog, and 2 others: Allow user to create and add widgets to multiple boards - https://phabricator.wikimedia.org/T120673#1888284 (Ejegg) Open>Resolved [19:10:38] Fundraising-Backlog: Amazon "session expired" donation error when logging in - https://phabricator.wikimedia.org/T120680#1888288 (MBeat33) We continue to see these sporadically, about 10 cases this month. The donor in #191006 sent a screenshot of what they see: {F3113045} [19:29:58] awight, ejegg: is there any time we'd want to show city/postal code but not state? [19:30:39] hmm, maybe little countries? [19:30:42] Maybe for countries where we don't ask for state [19:30:50] hehe "little" is a cuter way to put it [19:31:32] are there those? it seems like it's either full address or no address [19:32:14] or anyway i can't find any others [19:34:51] If it's just an optimization like (if need_state (if need_city ...)), I'd say leave them independent. [19:35:05] R u asking cos the stylesheets are crazy? [19:35:47] awight: nah i'm just thinking of the simplest implementation that covers all the cases [19:36:05] like if we don't ever *need* them to be separate, it's a little simpler [19:36:47] but if we do now's an easy time to build it [19:38:31] meganhernandez: Hey, we had a quick question for you--do you think we'll sometimes want to collect City but not State? [19:38:54] I know we have done that in the past, but I'm not sure if we plan to do that going forward. [19:39:08] hi awight hmm [19:39:12] in the US or anywhere? [19:40:27] anywhere [19:40:31] Hi! [19:52:19] this one's interesting: https://payments.wikimedia.org/index.php?title=Special:GlobalCollectGateway&appeal=JimmyQuote&ffname=cc-vmad&payment_method=cc&language=en&country=AU [19:52:28] state but no address/city/postal code [19:53:02] Funky! [19:53:14] meganhernandez: ping [19:53:24] oh sorry awight [19:53:50] maybe in some countries that don’t have states. or where state isn’t required [19:54:19] OK, that makes sense. Thanks! [19:54:23] i can’t think of a good example rihgt now [19:54:47] i would love to try and outline every case we're going to want to cover [19:54:59] i'm in a good place to make it flexible [19:55:42] Well, I think the -state +city scenario is at least forseeable as part of an A/B test [19:58:30] currently the logic is sort of split between the adapter and Mustache.php [19:58:59] you can say "address" is required in the adapter and the mustache controller will work some magic [19:59:09] based on country [19:59:21] or you can specify which fields you want in the adapter [19:59:32] but there's be no way to for instance pass in a list of countries [19:59:42] i would love to consolidate this somewhere [20:00:58] Fundraising Sprint William Shatner, Fundraising Sprint X-Ray Spex, Fundraising Sprint Yo La Tengo, Fundraising Sprint Zapp, and 2 others: Track email clickthroughs on donate wiki - https://phabricator.wikimedia.org/T114010#1888434 (CCogdill_WMF) Thanks, @Ejegg! Exciting to have a query to run :)... [20:01:04] I haven't had any insight into how that data structure should look, either. [20:05:26] cwd: My only thoughts so far were https://gerrit.wikimedia.org/r/#/c/65003/4/globalcollect_gateway/globalcollect.spec.yml,unified [20:06:12] I imagined that we could have arbitrary overrides at any level of the data, like countries.US.required_fields = detailed_address... [20:06:32] I never did find an adequate data structure for that, though. Nor convince myself that this was a good idea. [20:07:07] it's a tough one, but i definitely think it should be in a config file like that [20:07:55] Something like CSS, where we have a default order of precedence and lots of levels can override each other. [20:08:34] general config < gateway config < country config < payment method config < submethod [20:08:37] donno [20:09:03] totally, but i would like to be able to look for it in one place [20:09:27] agreed [20:09:33] well, maybe a small number of places. [20:09:41] I'd prefer if payment processors were more modular [20:09:53] then there are DI-wide default [20:10:00] and maybe a very small number of WMF overrides [20:11:42] well, if you think getting pedantic about this is a good use of my time right now i'm happy to stab until something everyone likes comes out [20:12:01] luckily the list of processors on mustache is small so if there is refactoring required it won't be too bad [20:12:23] and if we get this stuff in good shape we should be able to roll the rapidhtml stuff over more easily [20:13:18] I think the cascading config is probably too big of a project to do before Adyen-US, unless you're imagining a shortcut? [20:14:51] hmm, well i can certainly get the state dropdown on there pretty easily in the short term [20:15:37] i'm wondering how big of a project the top down config actually is [20:15:48] nothing we'd want to deploy while the fundraiser is going on [20:15:52] +1 [20:15:58] truf [20:16:17] That prototype patch I did took under a day, it's probably two weeks to do it right, though [20:16:33] or months. I'm terrible at estimating. [20:17:17] heh [20:17:24] hofstadter!!! [20:21:09] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, fundraising-tech-ops, MediaWiki-extensions-DonationInterface: Document existing queue usage - https://phabricator.wikimedia.org/T121792#1888474 (awight) NEW [20:53:40] Fundraising Tech Backlog: look at possible drupal logging snafu causing excessive log volume - https://phabricator.wikimedia.org/T121799#1888591 (Jgreen) NEW [21:03:09] Sorry friends, I gotta do my other procrastinating now... [21:11:52] just 4 remotes in a hangout [21:11:59] or should i say "cloud office" [21:14:43] Fundraising-Backlog, MediaWiki-extensions-DonationInterface: DonationInterface should log client-side errors - https://phabricator.wikimedia.org/T121800#1888645 (Ejegg) NEW [21:19:41] hey awight|not ejegg I bottled out of deploying that update to the campaign stuff yesterday when the strategy mtg was on - cos I didn't know if drupal needed to come down - i think the update query is around 30 - 40 sec & would lock the tables for that long... [21:20:33] hmm, we could just stop the queue consumer and tell ppl to expect a bit of slowness [21:21:45] ok - I just felt a bit nervous doing it... [21:22:06] Let me take a quick look at the script... [21:22:24] sure - in wmf_civicrm.install [21:22:54] (PS1) Ejegg: WIP log client-side errors [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/259795 (https://phabricator.wikimedia.org/T121800) [21:23:52] (CR) jenkins-bot: [V: -1] WIP log client-side errors [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/259795 (https://phabricator.wikimedia.org/T121800) (owner: Ejegg) [21:36:46] sorry eileen1, I got totally distracted. Getting back to that backfill script [21:37:45] ejegg: :-) [21:40:56] Looks good to me! Let's just send a quick note out and disable the queue consumers for the minute it'll take to run [21:41:04] cool [21:42:21] You want to write the email, or should I? [21:42:32] I was wondering that too :-) [21:42:41] Heh, ok, I will [21:45:08] Fundraising Sprint Zapp, Fundraising-Backlog, Wikimedia-Fundraising, MediaWiki-extensions-CentralNotice, and 2 others: Invalidate "waitdate" status whenever the impression diet maximum impressions limit is increased - https://phabricator.wikimedia.org/T121178#1888699 (Pcoombe) Open>Resolved... [21:45:56] eileen1: is the code up in prod? [21:46:32] ejegg: no - I didn't start the deploy yet - it's still in master - you want me to do that now [21:47:00] Sure! [21:47:18] I'll get ready to shut down the intake as soon as you're ready to rsync [21:50:40] (PS1) Eileen: Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/crm into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/259859 [21:51:43] (CR) Eileen: [C: 2] "Self-merging - deployment" [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/259859 (owner: Eileen) [21:52:15] eileen1: I said 15 min in the email, wanted to give them a chance to read it [21:52:19] hope that timing is OK [21:54:43] ejegg: yeah I think It's all ready - I'll just make a coffee [21:54:53] & then click go [21:54:59] cool, I've got all the buttons ready to stop the inflow [21:58:28] Wikimedia-Fundraising, Accessibility: donate.wikimedia.org forms should be more usable with keyboard - https://phabricator.wikimedia.org/T121803#1888753 (Pcoombe) NEW a:Pcoombe [21:59:05] Wikimedia-Fundraising, Accessibility: donate.wikimedia.org forms should be more usable with keyboard - https://phabricator.wikimedia.org/T121803#1888753 (Pcoombe) [21:59:07] Fundraising-Backlog, Wikimedia-Fundraising, MediaWiki-extensions-CentralNotice, MediaWiki-extensions-DonationInterface, and 2 others: Triage accessibility for donor-facing Fundraising components - https://phabricator.wikimedia.org/T87667#1888762 (Pcoombe) [22:05:46] eileen1: ok, I'll shut down the consumers in a sec [22:05:59] ejegg: cool [22:06:05] I'm ready [22:07:01] ok eileen1, all the inflow should be turned off [22:08:32] that was a short nap! [22:09:18] heh, i've never been able to nap [22:09:28] i try every now and then but it never goes anywhere [22:10:36] !log Updating civicrm from b307d744def9289a7f86cb02bc6e1a00225e474d to cb5e20c29d7376920c45eb5c343e6ee464217833 [22:10:44] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log, Master [22:12:15] ejegg: well I've run everything - no evidence the upgrade script has run as yet - I'm assuming the instructions here do run it ? https://collab.wikimedia.org/wiki/Fundraising/Engineering#Deploy_Fundraising_Code [22:12:32] eileen1: I'm already logged in to the CRM box [22:12:38] I'll just run updatedb there [22:12:50] ah ok - I was assuming the script ran that [22:13:06] so there is something missing on those instructions… [22:13:33] ah, there are other instructions for the crm deploy someplace [22:13:41] oh.. [22:13:55] hmm, all I see is the drupal 7.41 system table update [22:14:09] well I'm glad now I was too scared to do it on my own [22:14:53] ejegg: ah frigg - it didn't merge! https://gerrit.wikimedia.org/r/#/c/259859/ [22:14:59] I thought I saw it had :-( [22:15:10] argh! [22:15:39] (CR) Eileen: [V: 2] Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/crm into deployment [wikimedia/fundraising/crm] (deployment) - https://gerrit.wikimedia.org/r/259859 (owner: Eileen) [22:15:50] now it has! [22:17:00] ok, take two [22:17:44] wanna do the update/sync bit again? [22:17:58] !log update CiviCRM from b307d744def9289a7f86cb02bc6e1a00225e474d to cb5e20c29d7376920c45eb5c343e6ee464217833 [22:18:06] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log, Master [22:18:28] ejegg: done… [22:18:39] cool, i see the update [22:18:42] running it! [22:21:45] still chugging... [22:23:11] done! [22:23:50] yep & the search results look right now too [22:24:16] (I'm really enjoying that little arrow I added to show payments on the results) [22:24:32] hehe, nice [22:25:31] ok, queue jobs are looking good. [22:25:40] i'll sound the all clear [22:25:48] then I have to head out [22:25:50] OK cool [22:25:56] thanks! [22:26:31] see ya later! [22:27:19] Fundraising Sprint Zapp, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Unplanned-Sprint-Work, Patch-For-Review: Need to see UTM Source/UTM Campaign in Civi - https://phabricator.wikimedia.org/T121284#1888990 (Eileenmcnaughton) Numbers are looking good now - ok to close @caitvirtue ? [22:27:36] Fundraising Sprint Zapp, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Unplanned-Sprint-Work, Patch-For-Review: Need to see UTM Source/UTM Campaign in Civi - https://phabricator.wikimedia.org/T121284#1874602 (Eileenmcnaughton) [23:16:35] Fundraising Sprint Zapp, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: [Please rename me] UI Sillyness: The boxes don't fit in the other boxes the right way - https://phabricator.wikimedia.org/T117614#1889175 (CaitVirtue) p:Normal>Low [23:18:22] Fundraising Sprint Zapp, Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM: [Please rename me] UI Sillyness: The boxes don't fit in the other boxes the right way - https://phabricator.wikimedia.org/T117614#1779761 (CaitVirtue) Reopening this task. Still low priority but not resolved as per screensho...