[00:16:10] (03PS1) 10Mattflaschen: Correct section (alert/message/all) [extensions/Echo] - 10https://gerrit.wikimedia.org/r/297718 [00:43:48] 10Notifications, 07Browser-Support-Firefox, 07Mobile: On Android Firefox, dot dot dot menu items are sometimes hidden until reflow - https://phabricator.wikimedia.org/T139553#2435804 (10Mattflaschen-WMF) [07:55:44] 03Collab-Team-Q1-July-Sep-2016, 10Notifications: Make the notification highlights work better across wikis - https://phabricator.wikimedia.org/T134855#2436331 (10Pginer-WMF) Related to the discussion, I was asked to clarify the general behaviour for this: - The purpose of the highlight (as well as the badge) i... [08:21:19] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 13Patch-For-Review, 07User-notice: Unread notifications are not always at the top of the flyout/popup - https://phabricator.wikimedia.org/T139521#2436370 (10Trizek-WMF) [08:23:56] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 13Patch-For-Review, 07User-notice: Unread notifications are not always at the top of the flyout/popup - https://phabricator.wikimedia.org/T139521#2434637 (10Trizek-WMF) Would that fix be on next week train? [08:28:02] 10Collab-Notifications-Page, 03Collab-Team-Q1-July-Sep-2016, 10MediaWiki-Special-pages, 07User-notice: Set a max-width for Special:Notifications page - https://phabricator.wikimedia.org/T137425#2436380 (10Trizek-WMF) [08:28:28] 10Collab-Notifications-Page, 03Collab-Team-2016-Apr-Jun-Q4, 13Patch-For-Review, 07User-notice, and 2 others: Notifications page: Notification bodies are not truncated - https://phabricator.wikimedia.org/T138433#2436382 (10Trizek-WMF) [08:35:30] 10Collab-Notifications-Page, 03Collab-Team-2016-Apr-Jun-Q4: [betalabs] Special:Notifications page has wrong sorting order after messages are 'Marked as unread' - https://phabricator.wikimedia.org/T136885#2350991 (10Trizek-WMF) I've tried it, and managed to reproduce it in production. Page 1: {F4247943} Page... [09:27:48] 06Collaboration-Team-Interested, 10Thanks, 10Pywikibot-Thanks, 10Pywikibot-core, 05Google-Summer-of-Code-2016: Midterm evaluation for "Pywikibot support for Thanks" - https://phabricator.wikimedia.org/T138304#2436495 (10Qgil) @darthbhyrava thank you for your understanding and your kind words. I am lookin... [10:41:38] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 13Patch-For-Review, 07User-notice: Unread notifications are not always at the top of the flyout/popup - https://phabricator.wikimedia.org/T139521#2436730 (10SBisson) >>! In T139521#2436372, @Trizek-WMF wrote: > Would that fix be on next week train? I'm hopin... [11:05:38] (03CR) 10Addshore: [V: 031] Echo notifications for simple mention failures [extensions/Echo] - 10https://gerrit.wikimedia.org/r/295351 (https://phabricator.wikimedia.org/T136326) (owner: 10WMDE-Fisch) [11:11:42] 10Flow: Flow spam filter should display warnings in yellow, not in red - https://phabricator.wikimedia.org/T139588#2436840 (10Elitre) [11:25:17] (03CR) 10Addshore: [C: 04-1] "It looks like grouping doesn't yet work on Special:Notifications, but that doesn't matter too much." (032 comments) [extensions/Echo] - 10https://gerrit.wikimedia.org/r/295351 (https://phabricator.wikimedia.org/T136326) (owner: 10WMDE-Fisch) [12:31:13] (03PS1) 10Sbisson: Followup to I95dc3d70c8: Get rid of job queue entry for email bundling [extensions/Echo] - 10https://gerrit.wikimedia.org/r/297780 (https://phabricator.wikimedia.org/T135446) [12:36:52] (03CR) 10Sbisson: [C: 032] Correct section (alert/message/all) [extensions/Echo] - 10https://gerrit.wikimedia.org/r/297718 (owner: 10Mattflaschen) [12:44:50] (03Merged) 10jenkins-bot: Correct section (alert/message/all) [extensions/Echo] - 10https://gerrit.wikimedia.org/r/297718 (owner: 10Mattflaschen) [12:58:31] 10Flow, 10Notifications: New notifications layout is underparsed - https://phabricator.wikimedia.org/T139602#2437254 (10IKhitron) [12:58:39] 10Flow, 10Notifications: New notifications layout is underparsed - https://phabricator.wikimedia.org/T139602#2437266 (10IKhitron) p:05Triage>03High [13:05:56] 10Flow, 10Notifications: New notifications layout is underparsed - https://phabricator.wikimedia.org/T139602#2437277 (10Amire80) To provide a bit more context, here are the topics which appear in the tags: - https://he.wikipedia.org/wiki/%D7%A0%D7%95%D7%A9%D7%90:T79x46a1eb8oobny - https://he.wikipedia... [13:05:56] (03PS1) 10Sbisson: Check for empty array before calling max() [extensions/Echo] - 10https://gerrit.wikimedia.org/r/297785 (https://phabricator.wikimedia.org/T139529) [13:06:27] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 13Patch-For-Review, 07Wikimedia-log-errors: Array must contain at least one element in ApiEchoNotifications. php on line 341 - https://phabricator.wikimedia.org/T139529#2437281 (10SBisson) a:03SBisson [13:08:25] 03Collab-Team-2016-Apr-Jun-Q4, 10Flow, 10Notifications: New notifications layout is underparsed - https://phabricator.wikimedia.org/T139602#2437288 (10SBisson) a:03SBisson [13:37:22] 10Collab-Notifications-Page: Add a "mark all as read" in the "unread" section of Special:Notifications - https://phabricator.wikimedia.org/T139608#2437395 (10Trizek-WMF) [13:40:15] (03PS1) 10Sbisson: Simplify compact headers so they don't under- or over-parse [extensions/Flow] - 10https://gerrit.wikimedia.org/r/297788 (https://phabricator.wikimedia.org/T139602) [13:41:14] 10Flow: Flow spam filter should display warnings in yellow, not in red - https://phabricator.wikimedia.org/T139588#2437427 (10Trizek-WMF) Is it the case on other wikis? It it really linked to "thanks"? I've tried on [[ https://fr.wikipedia.org/wiki/Sujet:T7aao2owqnutx76s | fr.wp ]] and [[ https://www.mediawiki.o... [13:42:33] 10Flow: Flow spam filter should display warnings in yellow, not in red - https://phabricator.wikimedia.org/T139588#2437431 (10Elitre) Forgot to add that Matma tweaked the filter a bit later, so you can't reproduce. [13:43:01] 10Collab-Notifications-Page: Add a "mark all as read" in the "unread" section of Special:Notifications - https://phabricator.wikimedia.org/T139608#2437432 (10SBisson) [13:43:04] 10Collab-Notifications-Page, 03Collab-Team-2016-Apr-Jun-Q4, 13Patch-For-Review, 07User-notice: Turn the cog icon into a menu - https://phabricator.wikimedia.org/T115528#2437434 (10SBisson) [13:46:19] 10Notifications: Notifications not updated across languages - https://phabricator.wikimedia.org/T139454#2437456 (10CFCF) [13:48:50] legoktm: are you around? I don't expect you to be but check just in case. [13:51:24] (03PS1) 10Sbisson: Correct section (alert/message/all) [extensions/Echo] (wmf/1.28.0-wmf.9) - 10https://gerrit.wikimedia.org/r/297792 [13:55:14] matt_flaschen: let me know when you're around [13:58:16] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 07Wikimedia-log-errors: Undefined property: stdClass::$event_deleted in Event.php - https://phabricator.wikimedia.org/T139536#2437499 (10SBisson) a:03SBisson [14:08:22] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 07Wikimedia-log-errors: Undefined property: stdClass::$event_deleted in Event.php - https://phabricator.wikimedia.org/T139536#2437550 (10SBisson) This is worrying. Can you give more information about where and when this is/was happening? Thanks. [14:34:44] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 13Patch-For-Review, 05WMF-deploy-2016-07-05_(1.28.0-wmf.9): wikitext pages: Mention notifications prepend section title to text excerpts - https://phabricator.wikimedia.org/T134922#2437607 (10SBisson) >>! In T134922#2435634, @Etonkovidova wrote: > @SBisson... [15:06:08] (03CR) 10Thcipriani: [C: 032] "SWAT" [extensions/Echo] (wmf/1.28.0-wmf.9) - 10https://gerrit.wikimedia.org/r/297792 (owner: 10Sbisson) [15:13:02] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 13Patch-For-Review, 07User-notice: Unread notifications are not always at the top of the flyout/popup - https://phabricator.wikimedia.org/T139521#2437660 (10Trizek-WMF) I was asking to know in which section of Tech News I have to add it. :) [15:13:12] (03Merged) 10jenkins-bot: Correct section (alert/message/all) [extensions/Echo] (wmf/1.28.0-wmf.9) - 10https://gerrit.wikimedia.org/r/297792 (owner: 10Sbisson) [15:45:57] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 07Wikimedia-log-errors: Undefined property: stdClass::$event_deleted in Event.php - https://phabricator.wikimedia.org/T139536#2437766 (10MaxSem) >>! In T139536#2437550, @SBisson wrote: > This is worrying. Can you give more information about where and when this... [15:54:41] 10Notifications, 10The-Wikipedia-Library: Notify editors that they are now eligible for the Wikipedia Library program - https://phabricator.wikimedia.org/T132084#2437791 (10Sadads) As a followup to the comment on T132088#2360795 -- @Catrope we talked to @Quiddity and @jmatazzoni about creating a notification t... [16:13:11] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 07Wikimedia-log-errors: Undefined property: stdClass::$event_deleted in Event.php - https://phabricator.wikimedia.org/T139536#2437853 (10SBisson) Is there a stacktrace in the log? [16:16:38] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 07Wikimedia-log-errors: Undefined property: stdClass::$event_deleted in Event.php - https://phabricator.wikimedia.org/T139536#2437888 (10MaxSem) No. [16:37:46] (03Abandoned) 10Sbisson: Simplify compact headers so they don't under- or over-parse [extensions/Flow] - 10https://gerrit.wikimedia.org/r/297788 (https://phabricator.wikimedia.org/T139602) (owner: 10Sbisson) [16:39:31] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 13Patch-For-Review, 05WMF-deploy-2016-07-05_(1.28.0-wmf.9), 05WMF-deploy-2016-07-12_(1.28.0-wmf.10): Bundled notifications: New lines preserved in text excerpts - https://phabricator.wikimedia.org/T139321#2437996 (10Etonkovidova) Checked the fix in betalabs... [16:52:30] 03Collab-Team-2016-Apr-Jun-Q4, 10Flow, 10Notifications, 13Patch-For-Review: New notifications layout is underparsed - https://phabricator.wikimedia.org/T139602#2437254 (10Etonkovidova) In betalabs: {F4249931} [17:01:04] 06Collaboration-Team-Interested, 10Flow, 10Analytics, 06Community-Tech, and 6 others: statistics about edit conflicts according to page type - https://phabricator.wikimedia.org/T139019#2416933 (10Milimetric) Putting this on our Radar until the project is better defined (right now it's a bit more like a res... [17:03:24] 03Collab-Team-2016-Apr-Jun-Q4, 10Flow, 10Notifications, 13Patch-For-Review: New notifications layout is underparsed - https://phabricator.wikimedia.org/T139602#2438088 (10IKhitron) BTW, @Amire80, you have one more success for Wednesday deployment. [17:11:33] 10Flow: flow-new-post permissions does not seem to work - https://phabricator.wikimedia.org/T139627#2438101 (10cristianbaldi) [17:15:18] (03PS1) 10Sbisson: flow-post-reply: show compact header on one line [extensions/Flow] - 10https://gerrit.wikimedia.org/r/297820 (https://phabricator.wikimedia.org/T139602) [17:17:00] (03PS1) 10Sbisson: compact-header should be parse because it includes formatting [extensions/Echo] - 10https://gerrit.wikimedia.org/r/297821 (https://phabricator.wikimedia.org/T139602) [17:17:33] mooey|away: https://gerrit.wikimedia.org/r/297821 AND https://gerrit.wikimedia.org/r/297820 [17:19:11] 10Collab-Notifications-Page, 03Collab-Team-2016-Apr-Jun-Q4: Mark as seen notifications from the Notifications Page - https://phabricator.wikimedia.org/T136576#2438161 (10jmatazzoni) a:03Mooeypoo [17:29:45] matt_flaschen: I promise to test https://gerrit.wikimedia.org/r/#/c/293229/1 tomorrow or early next week. I would test it right now but with the big deployment I don't want to risk breaking my mw-vagrant and having recreate it. [17:31:42] Thanks, stephanebisson. [17:31:47] stephanebisson, through a quick quick look, the first 297821 looks fine, the second looks meh (str_replace? meh) but I haven't tested yet. I'm going to the office now, so I'll test as soon as I arrive [17:32:06] mooey|away: told you it was hacky [17:32:10] Indeed [17:32:32] There's gotta be a better way - but we can also merge the hack (just add a HACK comment or something) and fix things better later [17:32:44] ok, i'll be back in a bit [17:32:51] I would be happy to have a better solution [17:34:58] (03PS2) 10Sbisson: flow-post-reply: show compact header on one line [extensions/Flow] - 10https://gerrit.wikimedia.org/r/297820 (https://phabricator.wikimedia.org/T139602) [17:35:59] backfillUnreadWikis just started metawiki a moment ago. [17:36:31] matt_flaschen: how long has it been running? [17:38:33] wow, there's sooo many sites in group1 [17:38:44] (03CR) 10Mattflaschen: [C: 032] Add VE module check to #isSupported [extensions/Flow] (REL1_27) - 10https://gerrit.wikimedia.org/r/295459 (https://phabricator.wikimedia.org/T131055) (owner: 10Paladox) [17:46:44] (03Merged) 10jenkins-bot: Add VE module check to #isSupported [extensions/Flow] (REL1_27) - 10https://gerrit.wikimedia.org/r/295459 (https://phabricator.wikimedia.org/T131055) (owner: 10Paladox) [17:46:46] matt_flaschen: also, do you have a way to check that the Echo tables are up-to-date in all DBs? (T139536) [17:46:46] T139536: Undefined property: stdClass::$event_deleted in Event.php - https://phabricator.wikimedia.org/T139536 [17:48:05] stephanebisson, yeah, I can loop through and check them. [17:48:53] stephanebisson, running since about 4:30 PM yesterday. [17:49:26] (03Merged) 10jenkins-bot: Use VisualEditorSupportCheck [extensions/Flow] (REL1_27) - 10https://gerrit.wikimedia.org/r/295462 (https://phabricator.wikimedia.org/T135901) (owner: 10Paladox) [17:50:57] 03Collab-Team-2016-Apr-Jun-Q4, 06Collaboration-Team-Interested, 10Notifications: Mark notifications as read/unread with blue dot does not work in some circumstances - https://phabricator.wikimedia.org/T139147#2438316 (10Whatamidoing-WMF) Pings work correctly on the Beta Cluster. (I don't know if Flow thread... [17:53:03] (03PS1) 10Sbisson: Undefined property: stdClass::$event_deleted [extensions/Echo] - 10https://gerrit.wikimedia.org/r/297831 (https://phabricator.wikimedia.org/T139536) [18:03:22] stephanebisson, don't we want unread to be first? Why is read 0 in https://gerrit.wikimedia.org/r/#/c/297614/2/includes/model/Notification.php ? [18:04:07] (03CR) 10Mattflaschen: [C: 032] compact-header should be parse because it includes formatting [extensions/Echo] - 10https://gerrit.wikimedia.org/r/297821 (https://phabricator.wikimedia.org/T139602) (owner: 10Sbisson) [18:08:18] Oh, I didn't know about stripAllTags in core. That could be useful sometimes. [18:08:29] 03Collab-Team-Q1-July-Sep-2016, 10Notifications: Make the notification highlights work better across wikis - https://phabricator.wikimedia.org/T134855#2438412 (10jmatazzoni) Good summary Pau. Thanks! [18:10:05] (03CR) 10Mattflaschen: flow-post-reply: show compact header on one line (031 comment) [extensions/Flow] - 10https://gerrit.wikimedia.org/r/297820 (https://phabricator.wikimedia.org/T139602) (owner: 10Sbisson) [18:10:23] stephanebisson, I thought during standup about just stripping newlines as well, but then I was wondering about

and
. [18:11:16] matt_flaschen: the excerpt is already plaintext (see notifications/Controller.php:184 in Flow) [18:11:47] stephanebisson, oh, I thought you said it was sometimes plaintext. [18:12:08] stephanebisson, disregard my question about the sorting one. I see it's because newest is first. [18:12:43] (03Merged) 10jenkins-bot: compact-header should be parse because it includes formatting [extensions/Echo] - 10https://gerrit.wikimedia.org/r/297821 (https://phabricator.wikimedia.org/T139602) (owner: 10Sbisson) [18:13:20] the message as a whole ends up being html ($msg->parse()) and that's good because we use formatting in some messages [18:14:27] 03Collab-Team-2016-Apr-Jun-Q4: Users with only cross-wiki notifications see 'No notificaitons' on Special:Notifications page - https://phabricator.wikimedia.org/T139637#2438445 (10Etonkovidova) [18:14:52] stephanebisson, matt_flaschen you still need me for review/help on those two patches? I see one at least was merged, and I'm wondering if I should concentrate on the seen time in special page or stick to the horrible bug you're fixing stephanebisson [18:15:58] 06Collaboration-Team-Interested, 10Flow, 10Notifications, 07Community-Wishlist-Survey: Create a Timer based reminder for workflows - https://phabricator.wikimedia.org/T88781#2438475 (10Quiddity) Related request currently at https://en.wikipedia.org/wiki/Wikipedia:Bots/Requests_for_approval/RemindMeBot [18:16:04] mooey|away: matt_flaschen has merged the first patch. Hopefully he'll merge the second one after I address his question... [18:16:04] stephanebisson, okay, what about \r (see my comment)? [18:16:23] ok let me know if you need me to shift focus back again [18:16:25] I'm going to do a quick test on the sorting one and merge that too. [18:16:29] matt_flaschen: I really don't know, do you think we should? [18:16:42] stephanebisson, yeah. [18:16:54] mooeypoo: but you help in testing those one more time would make me feel better [18:16:59] *your [18:17:02] * mooeypoo nods [18:17:10] stephanebisson, ok, which patch? [18:17:16] matt_flaschen: ok, I'll do it [18:17:36] 297820 ? [18:18:43] mooeypoo: the one in Echo is merge, the Flow one is https://gerrit.wikimedia.org/r/#/c/297820/ but I'm about to udpate it [18:18:47] give me a few minutes [18:18:56] stephanebisson, matt_flaschen also, if we're already doing \r then what about \t ? [18:19:45] isn't there something already in the parser that cleans stuff like that out? [18:20:04] stephanebisson, actually, if there are no

or
, did you try white-space: nowrap? [18:20:05] https://developer.mozilla.org/en-US/docs/Web/CSS/white-space [18:20:33] That's already there in the mixin, I think [18:20:42] .mw-echo-ui-mixin-one-line-truncated() mixin [18:21:28] matt_flaschen: the funny thing is this: the excerpt is plaintext, it contains \n characters. Including it in a message and using $msg->parse() turns them into

..

[18:22:34] stephanebisson, ah, yeah (two consecutive \n are wikitext for a paragraph). Okay, that makes sense. [18:23:58] stephanebisson, I think plaintextParams should work. [18:24:02] wait, using $msg->plaintextParams() seems to fix it [18:24:10] right [18:24:14] 06Collaboration-Team-Interested, 10Notifications, 07Community-Wishlist-Survey: Create a Timer based reminder for workflows - https://phabricator.wikimedia.org/T88781#2438528 (10Quiddity) [18:24:39] (03PS3) 10Sbisson: flow-post-reply: show compact header on one line [extensions/Flow] - 10https://gerrit.wikimedia.org/r/297820 (https://phabricator.wikimedia.org/T139602) [18:24:44] someone else needs to test this ^ [18:25:21] stephanebisson, will test that one first. [18:30:54] stephanebisson, that works for me [18:31:08] stephanebisson, but I'm confused; yesterday's patch **also** worked for me on the same notification [18:31:33] did we revert it? now in master it's multiline and with your patch it's one-line, but yesterday had the same effect. Am I missing a test case? [18:31:42] mooeypoo: it's best to have flow-post-reply, flow-new-topic, and page-linked [18:31:53] Yeah I am testing flow-post-reply [18:32:04] Let me see flow-new-topic [18:32:20] yep, flow-post-reply works since yesterday but we broken flow-new-topic [18:32:32] stephanebisson, but it doesn't work in master O.o [18:32:33] I'm confused [18:32:38] and page-linked actually because it uses formatting (it bolds the page name0 [18:32:51] mooeypoo, it doesn't work on master because we changed it back to parse() [18:32:54] Hence needing to fix it another way. [18:33:04] mooeypoo: what matt said [18:33:09] ok, that's what I wanted to verify -- we undid what we did yesterday... [18:34:18] stephanebisson, mooeypoo, are either of you getting logged out from Vagrant all the time, starting recently? [18:34:25] no? [18:34:50] The wiki user I mean. [18:34:51] I had that going on a while back, but it got better since I flushed out the ssh stuff and stopped using https [18:34:54] yeah [18:35:11] matt_flaschen: on the contrary, I log out and get log right back in before I have the time to create a new user or login with a different user [18:35:41] since yesterday [18:36:01] I just logged out/in through firefox, and had no issues [18:36:47] Never mind, sorry, I forgot I had test config for the 1 year login cookie thing, where I deliberately set it short. [18:37:29] stephanebisson, I am trying to test new topic, but I can't set any html or newlines in topic titles anyways, and that's what the bundle shows me -- how do I test? [18:38:48] mooeypoo: topic titles allow links but no html, the msg (notification-compact-header-flow-new-topic) contains some html () that you should not see raw [18:39:36] hm, okay, I'm super confused here.. in the bug report, amir also shows the 'x new topics...' and the topics show with ... but I can't reproduce that at all in master - I see the topic titles as bolded (no ) [18:40:03] in master already, without your fix. Your fix works for flow post replies for me, but I can't reproduce the topic bug [18:40:10] mooeypoo: in the bug report, is part of the message, not the topic [18:40:26] stephanebisson, I understand that, but I see the topics as bolded, without the [18:40:36] mooeypoo: you're right [18:40:43] I don't understand the issue? :\ [18:41:02] mooeypoo: the part that matt merged a few minutes ago ($msg->parse()) fixed the new-topic part of the bug [18:41:36] mooeypoo: but it recreated the flow-post-reply part of the bug, that's what the flow patch is addressing [18:41:47] oh, okay, so 297820 fixes flow-post-reply for me, and doesn't touch the already-fixed flow-new-topic [18:42:08] that's what I hope [18:42:09] so that should mean the fix does what it intends, if I undersrtand it right [18:42:33] stephanebisson, yeah, wfm [18:43:56] matt_flaschen: can you deploy those fixes? [18:44:08] stephanebisson, sorry for the confusion, but I want to make sureI don't step on anyone's fix-toes here. It works perfectly for me, Ok to merge? [18:44:15] stephanebisson, I'm done testing the newline one, looks good. [18:44:44] good to merge and deploy, afaik [18:44:56] (03CR) 10Mooeypoo: [C: 032] "WFM" [extensions/Flow] - 10https://gerrit.wikimedia.org/r/297820 (https://phabricator.wikimedia.org/T139602) (owner: 10Sbisson) [18:45:54] the sort order should also be deployed if it passes review (https://gerrit.wikimedia.org/r/#/c/297614/) [18:46:29] stephanebisson, yeah, I was about to test that. So after I merge that we can ask for a window, then deploy all three (parse(), plaintextParams(), sorting). [18:46:41] matt_flaschen: sounds good [18:54:21] (03Merged) 10jenkins-bot: flow-post-reply: show compact header on one line [extensions/Flow] - 10https://gerrit.wikimedia.org/r/297820 (https://phabricator.wikimedia.org/T139602) (owner: 10Sbisson) [18:54:43] stephanebisson, the counter is displaying wrong for me on Echo master. [18:54:53] I have a bunch of unread notifications, but it displays 0 alerts, 2 messages. [18:56:09] 10Collab-Notifications-Page, 03Collab-Team-2016-Apr-Jun-Q4: Notification page side panel: sorting order of pages is incorrect - https://phabricator.wikimedia.org/T139642#2438621 (10Etonkovidova) [19:01:57] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications: Notification count cache got out of sync - https://phabricator.wikimedia.org/T139643#2438657 (10Mattflaschen-WMF) [19:01:59] 10Collab-Notifications-Page, 03Collab-Team-2016-Apr-Jun-Q4: Notification side panel: Tooltips are not provided for truncated titles - https://phabricator.wikimedia.org/T139644#2438669 (10Etonkovidova) [19:02:10] matt_flaschen: you have the transition variables? [19:02:15] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications: Notification count cache got out of sync - https://phabricator.wikimedia.org/T139643#2438683 (10Mattflaschen-WMF) [19:02:43] stephanebisson, yes. [19:02:54] Both true [19:03:17] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications: Notification count cache got out of sync - https://phabricator.wikimedia.org/T139643#2438657 (10Mattflaschen-WMF) [19:05:41] matt_flaschen: if you bump the cache version in Echo.php and play around, does it go back out of sync? [19:05:56] or did you notice when it went out of sync? [19:06:09] stephanebisson, I didn't notice when it first happened. [19:06:13] I'll try changing the cache now. [19:06:21] 10Collab-Notifications-Page, 03Collab-Team-2016-Apr-Jun-Q4: Notification side panel: For current wiki has zero unread notifications the title should be greyed out - https://phabricator.wikimedia.org/T139646#2438712 (10Etonkovidova) [19:08:26] (03PS2) 10Mooeypoo: Properly aggregate the itemUpdate event [extensions/Echo] - 10https://gerrit.wikimedia.org/r/297694 [19:08:50] (03PS3) 10Mooeypoo: Properly aggregate the itemUpdate event [extensions/Echo] - 10https://gerrit.wikimedia.org/r/297694 [19:10:16] (03PS14) 10Mooeypoo: Add a mark-all-read button and a settings menu to Special:Notifications [extensions/Echo] - 10https://gerrit.wikimedia.org/r/296674 (https://phabricator.wikimedia.org/T115528) [19:11:00] 03Collab-Team-2016-Apr-Jun-Q4: Users with only cross-wiki notifications see 'No notificaitons' on Special:Notifications page - https://phabricator.wikimedia.org/T139637#2438764 (10SBisson) [19:11:02] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 13Patch-For-Review: When a user only has foreign notifications, the special page shows "You have no notifications." - https://phabricator.wikimedia.org/T139512#2438766 (10SBisson) [19:11:25] stephanebisson, looks fine after that. Probably I polluted the cache by not doing all the transition steps properly locally. [19:13:20] matt_flaschen: if you had the new code before the transition flags set, you would probably write wrong values to cache [19:13:43] matt_flaschen: if it happens against, you can check if backfillUnreadWikis fixes it [19:16:00] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications: Notification count cache got out of sync - https://phabricator.wikimedia.org/T139643#2438779 (10Mattflaschen-WMF) 05Open>03Invalid We think this was a local-only issue due to not doing all the transition steps properly. [19:29:01] (03CR) 10Mattflaschen: [C: 032] Sort bundled notifications by read status AND timestamp [extensions/Echo] - 10https://gerrit.wikimedia.org/r/297614 (https://phabricator.wikimedia.org/T139521) (owner: 10Sbisson) [19:29:46] 10Collab-Notifications-Page: Notification page: Adjustment of blue dot alignment - https://phabricator.wikimedia.org/T139648#2438820 (10Etonkovidova) [19:31:55] 10Collab-Notifications-Page, 03Collab-Team-2016-Apr-Jun-Q4, 13Patch-For-Review, 07User-notice: List wikis and pages with unread notifications in the Notification Page left nav - https://phabricator.wikimedia.org/T129366#2438837 (10Etonkovidova) The @Pginer-WMF comment about misaligned blue dot was filed as... [19:35:39] (03PS1) 10Mattflaschen: flow-post-reply: show compact header on one line [extensions/Flow] (wmf/1.28.0-wmf.9) - 10https://gerrit.wikimedia.org/r/297853 (https://phabricator.wikimedia.org/T139602) [19:35:51] (03PS1) 10Mattflaschen: compact-header should be parse because it includes formatting [extensions/Echo] (wmf/1.28.0-wmf.9) - 10https://gerrit.wikimedia.org/r/297854 (https://phabricator.wikimedia.org/T139602) [19:36:34] (03Merged) 10jenkins-bot: Sort bundled notifications by read status AND timestamp [extensions/Echo] - 10https://gerrit.wikimedia.org/r/297614 (https://phabricator.wikimedia.org/T139521) (owner: 10Sbisson) [19:38:27] (03PS1) 10Mattflaschen: Sort bundled notifications by read status AND timestamp [extensions/Echo] (wmf/1.28.0-wmf.9) - 10https://gerrit.wikimedia.org/r/297855 (https://phabricator.wikimedia.org/T139521) [19:41:56] (03CR) 10Mattflaschen: [C: 032] Sort bundled notifications by read status AND timestamp [extensions/Echo] (wmf/1.28.0-wmf.9) - 10https://gerrit.wikimedia.org/r/297855 (https://phabricator.wikimedia.org/T139521) (owner: 10Mattflaschen) [19:42:00] (03CR) 10Mattflaschen: [C: 032] flow-post-reply: show compact header on one line [extensions/Flow] (wmf/1.28.0-wmf.9) - 10https://gerrit.wikimedia.org/r/297853 (https://phabricator.wikimedia.org/T139602) (owner: 10Mattflaschen) [19:42:06] (03CR) 10Mattflaschen: [C: 032] compact-header should be parse because it includes formatting [extensions/Echo] (wmf/1.28.0-wmf.9) - 10https://gerrit.wikimedia.org/r/297854 (https://phabricator.wikimedia.org/T139602) (owner: 10Mattflaschen) [19:47:59] (03Merged) 10jenkins-bot: Sort bundled notifications by read status AND timestamp [extensions/Echo] (wmf/1.28.0-wmf.9) - 10https://gerrit.wikimedia.org/r/297855 (https://phabricator.wikimedia.org/T139521) (owner: 10Mattflaschen) [19:51:26] (03Merged) 10jenkins-bot: flow-post-reply: show compact header on one line [extensions/Flow] (wmf/1.28.0-wmf.9) - 10https://gerrit.wikimedia.org/r/297853 (https://phabricator.wikimedia.org/T139602) (owner: 10Mattflaschen) [19:51:32] (03Merged) 10jenkins-bot: compact-header should be parse because it includes formatting [extensions/Echo] (wmf/1.28.0-wmf.9) - 10https://gerrit.wikimedia.org/r/297854 (https://phabricator.wikimedia.org/T139602) (owner: 10Mattflaschen) [19:58:23] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 13Patch-For-Review, 05WMF-deploy-2016-07-05_(1.28.0-wmf.9), 05WMF-deploy-2016-07-12_(1.28.0-wmf.10): Bundled notifications: The counter for bundled notifications shows sum of notifications of Alerts and Mess... - https://phabricator.wikimedia.org/T139323#2438907 [20:06:20] stephanebisson, mooeypoo, deployment done. Testing now. [20:06:36] matt_flaschen: thanks. I'm also testing [20:07:50] Note, It is not on Wikipedia yet. [20:09:40] Weird that user talk replies don't get an exerpt. [20:13:39] matt_flaschen: you mean flowusertalk-post-reply? [20:13:55] stephanebisson, yes. [20:14:30] I just see, "Mattflaschen-WMF‬ posted a reply on your talk page in "‪Test 3‬" (except it's truncated with CSS so I don't really see that Test 3 part). [20:14:33] matt_flaschen: are you saying they are bundled but there is no excerpt, like User1: [20:14:59] stephanebisson, kind of. Screenshot coming. [20:16:34] ahhh, I see. The css truncation is now applied to foreign bundes as well. They used to wrap instead. [20:17:32] stephanebisson, https://phabricator.wikimedia.org/F4250449 , https://phabricator.wikimedia.org/F4250450 . This is not a foreign case, though, just a bundle. [20:17:58] oh, I see [20:18:43] that's what I meant when I said that different expandable notification have different requirements (truncation vs wrapping) [20:19:02] I bet the page-linked with long page names are equally truncated [20:19:49] well, it doesn't look _as_ broken but it's far from perfect [20:21:21] well, there's another issue: flowusertalk-post-reply isn't using the right message for compact-header [20:21:37] stephanebisson, it doesn't really look broken to me, just inconsistent (why doesn't it give me an excerpt). That is probably the root issue (it's using an inconsistent/wrong message). [20:21:50] right [20:21:56] I'll create a patch [20:23:03] Other than that (which is not really related), everything looks good. [20:23:07] it happened when I splitted flow-* from flowusertalk- [20:23:46] I took care of the "auto" messages (notification-header-{$this->type}) but this was in a branch at the time [20:23:55] stephanebisson, can you watch the deploy (for unexpected complications) for 15 minutes, so I can step out? I'll be available on hangout. [20:24:05] sure [20:24:50] Thanks, brb. [20:24:57] (03PS1) 10Mooeypoo: Store local source as 'local' rather than dbName [extensions/Echo] - 10https://gerrit.wikimedia.org/r/297862 [20:31:38] 10Collab-Notifications-Page, 03Collab-Team-2016-Apr-Jun-Q4: [betalabs] Special:Notifications page has wrong sorting order after messages are 'Marked as unread' - https://phabricator.wikimedia.org/T136885#2439060 (10Etonkovidova) From @Mooeypoo observation (confirmed by me) - the issue has nothing to do with... [20:33:54] Back [20:33:56] hmm. [20:34:17] matt_flaschen, could it be that the API constructs the 'continue' value wrong for the first result page? [20:34:56] mooeypoo, I don't know of any bug like that, never say never. [20:34:58] The wrong ordering bug etonkovidova reported happens only when we move from page 1 to page 2, but the code stores the initial continue value properly, and uses it to query properly [20:35:18] but it doesn't happen for any *other* continuous pages, so for page 3 the continue value seems to be correct [20:35:20] this is so weird [20:36:00] mooeypoo, did she get it reproducible? [20:36:02] ok another detail -- it is only wrong when we query the local wiki. It works fine when we query remote wiki [20:36:04] yes [20:36:10] I'm looking at it consistently on master [20:36:14] Steps? [20:36:24] So go to your Special:Notifications page [20:36:42] don't change to any filters, just look at the last section in your page (what date is last) [20:36:59] now click on "next" page... you should expect to see either the last date from the previous page on top, or at least a later date [20:37:07] but what you get is an EARLIER date [20:37:22] only in page2 though. Keep going through the pages, and the dates continuity is correct. [20:37:23] mooeypoo, isn't it reverse chronological? [20:37:31] So if you show more, shouldn't it go backwards? [20:37:38] the problem isn't the order, the problem is that the query of page 2 is wrong date [20:37:44] it should [20:37:47] it shoudl show you an older date [20:37:55] or the same day, whatever you have left from it [20:37:56] So why "you should expect to see either the last date from the previous page on top, or at least a later date" [20:38:11] I would expect to see the same date as the earllest date on the first page, or "at least an *earlier* date" [20:38:16] let's say page 1 of special notifications ends with "thursday" [20:38:31] page 2 should either have, on top, notifications from thursday (older from that day) OR notifications from Friday onwards [20:38:35] so same day or older [20:38:47] mooeypoo, I still don't get that. [20:38:55] Say page 1 shows Thursday through Saturday. [20:38:56] you can't reproduce it? [20:39:04] matt_flaschen: mooeypoo: also, counting msgs (and subsequently the # of pages) is wrong - hopefully, it's the same cause [20:39:05] (03PS1) 10Sbisson: Use the right compact msg for flowusertalk-* expandable notifications [extensions/Flow] - 10https://gerrit.wikimedia.org/r/297888 [20:39:06] No, I haven't tested yet, I mean the explanation doesn't make sense. [20:39:14] oh [20:39:15] uhm [20:39:22] Then page 2 should show e.g. Monday to Thursday, or Monday to Wednesday, etc. [20:39:28] okay, let's say your first page has notifs from Today to Saturday [20:39:32] mooeypoo, why would Friday come into play? [20:39:42] See what I said about page 1 above. [20:39:45] oh [20:39:58] wait, i'm confused now too :D hang on let me re-read and make sense of it [20:40:38] matt_flaschen, no, okay, let's start differently, because day *names* are confusing too (they only show for 1 week) [20:40:41] matt_flaschen: https://gerrit.wikimedia.org/r/297888 [20:42:04] matt_flaschen: can you swat ^ if it passes review,it's pretty bad :(? [20:42:07] stephanebisson, great, will review in time for evening SWAT [20:42:14] thanks [20:42:44] If you have notifs in page 1 Thursday through Saturday (thursday being "today", backwards to Satuday) -- you expect page 2 to show you *older* notifications. To avoid confusion, I'll just use dates instead of day names, so Thursday (7/9) to Saturday (7/3) on page 1. Page 2 should show you anything equal or *older* than 7/3 [20:43:07] I wrote "friday" there because that's before saturday, but it would just show you 7/3 OR 7/2 or older, etc... [20:43:09] that makes sense? [20:43:14] mooeypoo, in my example, I meant Saturday backwards to Thursday, but okay. [20:43:18] Let me look at your example. [20:43:30] matt_flaschen, oh, yeah, I got confused with that (this *is* confusing, yeesh) [20:44:24] mooeypoo, yes, now it makes sense. [20:44:55] matt_flaschen, the problem we are running into is that instead of having page 2 display things either equal or older than 7/3, it suddenly shows you thinks from later -- say, 7/5 [20:44:59] yup, confusing - I guess the source of confusion is where the specific point of pagination in the "stream" of messages will happen [20:45:03] so the 'continue' value seems to be wrong [20:45:15] I have examples where all look fine [20:45:35] but it only happens (A) on the second page (suggesting that the **initial** continue value is wrong) and (B) in local wiki -- if you choose a filter for remote wiki, it works fine for all pages [20:45:40] etonkovidova, ^^ that correct, right? [20:46:06] mooeypoo: correct! [20:46:20] so it sounds like there's something wrong with the initial continue value. The value we get from the API without using an explicit &continue= param [20:46:24] is that possible? :\ [20:47:06] mooeypoo, maybe. I will start the Echo scripts, review stephanebisson's patch, then look at this. Assuming it is higher priority than the iOS thing. [20:47:27] matt_flaschen, I don't know if it is. jmatazzoni___ ? [20:50:11] 06Collaboration-Team-Interested, 10Flow, 10MediaWiki-extensions-MultimediaViewer, 06Reading-Web-Backlog: Media Viewer doesn't trigger on Flow-enabled talk pages - https://phabricator.wikimedia.org/T64594#2439168 (10dr0ptp4kt) p:05Normal>03Low [20:50:27] 10Notifications, 05WMF-deploy-2016-07-05_(1.28.0-wmf.9), 07Wikimedia-log-errors: Notice: Undefined property: stdClass::$event_deleted Event.php on line 259 - https://phabricator.wikimedia.org/T139658#2439171 (10mmodell) [20:51:11] Actually, I'll look at that event_deleted thing first too. [20:51:22] stephanebisson asked me to check the DBs earlier. [20:51:23] 10Notifications, 05WMF-deploy-2016-07-05_(1.28.0-wmf.9), 07Wikimedia-log-errors: Notice: Undefined property: stdClass::$event_deleted Event.php on line 259 - https://phabricator.wikimedia.org/T139658#2439185 (10SBisson) [20:51:25] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 13Patch-For-Review, 07Wikimedia-log-errors: Undefined property: stdClass::$event_deleted in Event.php - https://phabricator.wikimedia.org/T139536#2439187 (10SBisson) [20:53:56] matt_flaschen, according to jmatazzoni___, the pagination bug is worse than the ios bug, so I'm concentrating on it while you work on the other things. I have a feeling this is something weird with timestamp storage or something... [20:55:10] matt_flaschen, double checking things, this is actually consistent for foreign filters too; if I'm on enwiki and I filter for french wiki, page 2 is wrong just as much as page 2 in "local" enwiki is wrong... but in both cases we're asking the direct API for the continue value *and* the notifications, so it *should* be properly localized even if localization is the issue. [20:55:36] This is maddeningly weird. I think we have an issue with the initial continue value, maybe :\ [20:56:27] 10Notifications: edit-thank for new page creation results in a notification that redirects to the Error page. - https://phabricator.wikimedia.org/T139435#2439199 (10Etonkovidova) [21:01:59] matt_flaschen: I'll check back later. Ping me on hangout as needed. [21:12:41] 10Notifications, 07Wikimedia-log-errors: "User::loadFromSession called before the end of Setup.php" warning due to Echo - https://phabricator.wikimedia.org/T139665#2439332 (10Anomie) [21:14:55] matt_flaschen, (not urgent, just updating) -- I am narrowing down the bug further. It doesn't happen when we fetch read or unread notifications, only when we fetch both. I tried this, suspecting a specific line of code in ApiEchoNotifications.php #190 where we do one thing for read/unread and another for querying both. I think the issue is there. [21:17:17] my guess is that the result set in 'fetchByUser' is not sorted by timestamp. [21:18:30] 03Collab-Team-2016-Apr-Jun-Q4, 10Flow, 06Community-Liaisons (Jul-Sep-2016): Add mediawiki.feedback dialog to Flow - https://phabricator.wikimedia.org/T124689#2439424 (10Qgil) p:05Triage>03Low Assuming low priority, better than no priority. [21:19:07] hm, but it is. Gah. [21:20:34] stephanebisson: in case you remember:) Was it filed somewhere that page-less notificaitons are not counted in unread counter in the side panel? [21:20:50] 10Notifications: edit-thank for new page creation results in a notification that redirects to the Error page. - https://phabricator.wikimedia.org/T139435#2439482 (10Mattflaschen-WMF) As expected, works now; looks to be fixed by {T139526}. Reopen if it occurs again. [21:21:04] 10Notifications: edit-thank for new page creation results in a notification that redirects to the Error page. - https://phabricator.wikimedia.org/T139435#2439497 (10Mattflaschen-WMF) [21:22:04] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 07Wikimedia-log-errors: "User::loadFromSession called before the end of Setup.php" warning due to Echo - https://phabricator.wikimedia.org/T139665#2439526 (10Mattflaschen-WMF) [21:22:33] 03Collab-Team-Q1-July-Sep-2016, 10Flow, 10Collaboration-Community-Engagement, 06Community-Liaisons (Jul-Sep-2016): Help to define next steps concerning Flow development, based on Flow satisfaction survey - https://phabricator.wikimedia.org/T137796#2439528 (10Qgil) p:05Triage>03Low Assuming Low priority... [21:26:19] 03Collab-Team-Q1-July-Sep-2016, 10Flow, 10Collaboration-Community-Engagement, 06Community-Liaisons (Jul-Sep-2016): Help to define next steps concerning Flow development, based on Flow satisfaction survey - https://phabricator.wikimedia.org/T137796#2439566 (10Qgil) a:03Trizek-WMF Assuming @Trizek-WMF is a... [21:26:22] Started the scripts for today. Meanwhile, backfillUnreadWikis for group 1 is still on meta. [21:29:35] 10Notifications: "Message" and "alert" notifications flipped - https://phabricator.wikimedia.org/T139677#2439611 (10Kharkiv07) [21:34:26] quiddity, ^^ this seems to be people not expecting the resorting? I can't see an actual technical bug [21:35:18] mooeypoo, it's https://phabricator.wikimedia.org/T123018 and was announced in https://meta.wikimedia.org/wiki/Tech/News/2016/26 plus earlier requests for fedback [21:35:34] i'll comment after my currentmeeting [21:37:08] * mooeypoo nods [21:37:20] quiddity, awesome, I just wanted to make sure it wasn't an actual bug where the popup opened wrong [21:37:56] mooeypoo, it doesn't really make sense until we change the Alerts/Messages verbiage. Is there a bug for that yet? [21:37:57] 10Notifications: "Message" and "alert" notifications flipped - https://phabricator.wikimedia.org/T139677#2439611 (10BethNaught) At VPT the problem has been reported with Chrome 51; I am also experiencing it on Firefox 47. [21:38:13] matt_flaschen, I thought we said it changed? I may have misunderstood [21:38:18] didn't we say stephanebisson changed it? [21:39:39] mooeypoo, my understanding is we were going to change the names as well. [21:39:49] mooeypoo, so instead of Alerts/Messages it was now going to be Notices/Thingies or whatever. [21:39:56] Is that not the case? [21:39:57] Yeah, I remember we talked about it, but I didn't see a bug [21:40:03] and I thought we said it changed this morning [21:40:13] but I may have misunderstood, with all the other issues ongoing [21:40:37] mooeypoo, I recall us talking about how we are going to change it in one of the meetings. Will ask in hangouts. [21:40:52] matt_flaschen, etonkovidova is finding the bug [21:40:53] mooeypoo: https://phabricator.wikimedia.org/T139520 [21:40:55] there [21:41:37] matt_flaschen, I can change it in the i18n - what's the process for proper translation, though? Do we change it and hope translators change too, or do we create a new key/string ? [21:41:40] 03Collab-Team-Q1-July-Sep-2016, 10Notifications, 07Wikimedia-log-errors: "User::loadFromSession called before the end of Setup.php" warning due to Echo - https://phabricator.wikimedia.org/T139665#2439680 (10Mattflaschen-WMF) [21:42:13] mooeypoo, it should be a new key in this case because it's a different concept. [21:42:26] * mooeypoo nods [21:42:33] 10Notifications: "Message" and "alert" notifications flipped - https://phabricator.wikimedia.org/T139677#2439684 (10Kharkiv07) I can confirm with Chrome 51 and IE 11. As pointed out at VPT the headings are correct in each tab, but the alerts are switched. [21:43:00] 03Collab-Team-Q1-July-Sep-2016, 10Notifications: Change tooltip 'Your messages' to 'Your notices' - https://phabricator.wikimedia.org/T139520#2439685 (10Mattflaschen-WMF) We also need icons for this. [21:43:14] First group 2 script: https://phabricator.wikimedia.org/P3364 [21:44:07] 03Collab-Team-Q1-July-Sep-2016, 10Notifications: Change tooltip 'Your messages' to 'Your notices' - https://phabricator.wikimedia.org/T139520#2439688 (10Mattflaschen-WMF) a:03Mooeypoo [21:44:55] mooeypoo, it would be good to get it out for SWAT at 4 PM if possible. Otherwise, it's there until Monday. [21:45:30] mooeypoo, but that might not be doable. [21:45:51] matt_flaschen, but it's not just the tooltip, is it? [21:46:02] i mean, the bug only says tooltip, but it seems to also relate to the title of the popup [21:46:11] mooeypoo, it's everywhere, in my understanding. [21:46:13] but if so, do we change **all** instances of "message" to "notice" ? everywhere? [21:46:50] 10Notifications: edit-thank for new page creation results in a notification that redirects to the Error page. - https://phabricator.wikimedia.org/T139435#2439714 (10Etonkovidova) Confirmed - it works; checked in betalabs. [21:46:56] mooeypoo, you *could* leave it the same internally (method names and such) temporarily, but I think ultimately we should change those too. [21:47:18] yeah i won't deal with method names [21:47:25] but all messages, everywhere, seem to have to switch up [21:47:45] Yeah. [21:47:58] at some point we'd want to change this in the API as well btw [21:48:19] section names are 'alert' and 'message' not 'alert' and 'notice' and this change will make things quite confusing :\ but... yeah. temporary, hopefully. [21:49:11] 03Collab-Team-Q1-July-Sep-2016, 10Notifications: Change tooltip 'Your messages' to 'Your notices' - https://phabricator.wikimedia.org/T139520#2439721 (10Mattflaschen-WMF) [21:49:15] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 10Collaboration-Community-Engagement, 13Patch-For-Review, and 2 others: Revise Sorting of Notifications on the Fly-Out Menus - https://phabricator.wikimedia.org/T123018#2439720 (10Mattflaschen-WMF) [21:49:16] matt_flaschen, what about "echo-category-title-edit-user-talk": "Talk page {{PLURAL:$1|message|messages}}" ? Do I change it? If I do, I'm not creating a new key :\ [21:49:26] I mean I could,but that seems such an overkill if we do it for everything, no? [21:50:34] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 10Collaboration-Community-Engagement, 07User-notice, 05WMF-deploy-2016-07-05_(1.28.0-wmf.9): Change 'messages' to 'notices' internally (method names and such) - https://phabricator.wikimedia.org/T139682#2439722 (10Mattflaschen-WMF) [21:51:12] mooeypoo, actually, that one should stay, since it's specifically a talk page message. It's not directly referring to the alert/message dichotomy. [21:51:39] Anywhere it refers to the alert/message distinction. [21:51:52] well, what about "notification-link-text-view-notice" --> this is the "View message" link [21:52:04] which, btw, would be a nightmare to change because we'll have to change it in Flow and Thanks etc [21:52:06] :\ [21:52:28] I think it's probably okay to leave as-is but if this is a product nomenclature change, we might want to replace it too [21:52:55] mooeypoo, same. It's specifically about edit-user-talk, so I think it should stay 'message'. [21:53:10] mooeypoo, notification-link-text-view-mention is the same for mentions (mentions used to be in alerts, but it's not 'View alert'). [21:53:31] hm, good point [21:53:54] https://phabricator.wikimedia.org/T139682#2439722 is the internal followup. [22:00:45] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 13Patch-For-Review, 07User-notice, and 2 others: Unread notifications are not always at the top of the flyout/popup - https://phabricator.wikimedia.org/T139521#2434637 (10Etonkovidova) Checked in betalabs - the notifications are sorted by their status and th... [22:05:29] ok, I think I Got Them All[tm] [22:06:59] 10Notifications: "Message" and "alert" notifications flipped - https://phabricator.wikimedia.org/T139677#2439611 (10Quiddity) I've written an explanation with many links, at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Notification_issue [22:08:24] matt_flaschen, :(( a lot of the php-side of things builds the i18n messages with "something-something-" + section + "-blah" [22:08:27] aaaaaaaa :\ [22:08:45] ( $section == 'message' ? 'notice' : $section ) everywhere :\ [22:09:12] also, there's no proper i18n documentation in many places so finding WHERE those messages are built is a nightmare [22:10:47] mooeypoo, yeah, I try to put the message key for grepping as recommended, but sometimes it's a pain/not very doable. [22:11:07] mooeypoo, will get cleaned up when we change the internal code, but you're probably wise not to do that in the hour before SWAT on a Thursday. [22:19:13] (03CR) 10Mattflaschen: [C: 032] Use the right compact msg for flowusertalk-* expandable notifications [extensions/Flow] - 10https://gerrit.wikimedia.org/r/297888 (owner: 10Sbisson) [22:19:23] mooeypoo, can you put it up? [22:24:15] matt_flaschen, yeah I'm still looking for 2 messages that I can't grep for [22:24:18] then I'll put it up [22:24:33] xwiki notices are not greppable [22:25:15] the keys I mean... "notification-header-foreign-message" key is ungreppable. [22:25:21] but it appears in the xwiki body/header [22:26:06] (03Merged) 10jenkins-bot: Use the right compact msg for flowusertalk-* expandable notifications [extensions/Flow] - 10https://gerrit.wikimedia.org/r/297888 (owner: 10Sbisson) [22:26:45] mooeypoo, probably EchoForeignPresentationModel.php [22:26:50] ok, got it, but wtf. EchoForeignPresentationModel line #16 ... notification-header-{$this->type}-{$section} [22:27:04] meh and now I need the count message, too [22:27:33] WTWTF? It's missing greppable keys, but probably not the only one you saw like that... [22:27:47] no, I'm adding the greppable keys, but half-guessing here [22:28:00] 03Collab-Team-2016-Apr-Jun-Q4, 10Flow, 10Notifications, 13Patch-For-Review, and 2 others: New notifications layout is underparsed - https://phabricator.wikimedia.org/T139602#2439906 (10Etonkovidova) @SBison in betalabs for bundled notifications. Unbundled are fine. {F4250818} [22:28:13] $this->type in that context is "foreign" it seems [22:28:14] meh [22:29:19] stephanebisson: could it be that https://gerrit.wikimedia.org/r/#/c/297854/ is not merged yet? [22:30:22] mooeypoo, yeah, it's a psuedo-type. I first noticed that when I was working on Special:DisplayNotificationsConfiguration. [22:30:43] etonkovidova, no, you can see it's merged. And I deployed it too. [22:30:49] matt_flaschen, ok, I think I got them all, but I could use someone to verify ( etonkovidova maybe pull the fix too?) [22:31:03] just grunting to make sure banana passes right [22:31:26] etonkovidova, https://phabricator.wikimedia.org/T139602#2439906 is a different bug, but stephanebisson fixed that and I merged it too. [22:31:27] ^^ wow, this is the weirdest professional-related sentence I've ever typed [22:32:04] matt_flaschen, mooeypoo, re: changing Messages to Notices, it might be best to push the change and wait for Monday, to allow translators time to do their work. [22:32:31] quiddity, fair enough. Though that might also help with the "bug" people are reporting [22:32:32] quiddity, I thought about that, but it's very broken as is too. [22:32:50] quiddity, it makes it seem like we're just flipping things around randomly. [22:33:14] true. I'm not sure how to balance the bug, with not presenting an English message to all the non-English editors... :/ [22:33:46] quiddity, they don't have to wait for deployments to update translations. [22:33:57] I think it syncs daily or something. Whereas if we don't do it now we have to wait until Monday morning. [22:34:03] btw, the qqq explanation ofr echo-notification-alert (and echo-notification-alert-text-only) and -notice and notice-text-only is plain wrong. It explains "Label for alert notifications (= non discussion notifications) tab in Echo overlay" [22:34:05] meh [22:34:05] matt_flaschen, true, ok, go for it then [22:34:44] mooeypoo, it was right before the re-sort, right? [22:34:54] what was? [22:35:05] echo-notification-alert [22:35:08] the explanation? I think it's old. It says "tab" :\ [22:35:21] also, I think the echo-notification-alert and -notice is unused. The -text-only is used [22:35:35] But I am VERY tentative in removing it with so many of the i18n keys ungreppable [22:35:47] mooeypoo, oh, yeah (re tab). Yeah, we can do a remove pass later not in as much rush. [22:35:49] regardless, the explanation of the -text-only is the same anyways. We need to change it. [22:36:34] (03PS1) 10Mooeypoo: Change 'messages' to 'notices' throughout the interface [extensions/Echo] - 10https://gerrit.wikimedia.org/r/297913 (https://phabricator.wikimedia.org/T139520) [22:36:37] (03PS1) 10Mattflaschen: Use the right compact msg for flowusertalk-* expandable notifications [extensions/Flow] (wmf/1.28.0-wmf.9) - 10https://gerrit.wikimedia.org/r/297914 [22:38:00] 03Collab-Team-Q1-July-Sep-2016, 10Notifications, 13Patch-For-Review: Change tooltip 'Your messages' to 'Your notices' - https://phabricator.wikimedia.org/T139520#2439946 (10Mooeypoo) This involves more than just the tooltip - the change is for the entire interface, changing 'message' to 'notice' in context o... [22:38:07] matt_flaschen: ok, I probably viewed the cached content for titles. [22:38:13] will try agian [22:39:19] etonkovidova, no, it's an unrelated bug that wasn't merged yet when you tested. [22:39:21] It is merged now. [22:39:53] ok [22:40:50] mooeypoo, echo-notification-alert/notice is used in Resources.php [22:41:00] Unless you mean it's not used client-side. [22:41:22] matt_flaschen, it's called there to be used, but I can't see where it's ACTUALLY being used in the code for the user to see [22:41:36] either javascript or the php that builds the notification body/content [22:41:44] but I am worried I'm missing some key [22:42:53] mooeypoo, yeah, we can come back to that. It's not great that 'notices' and 'notifications' are now two different things. [22:42:55] Oh well. [22:43:14] matt_flaschen, or that in the code we call this 'message' (because API) and in the interface we call it 'notice' [22:43:17] but yeah, meh. [22:46:27] (03CR) 10Mattflaschen: [C: 04-1] Change 'messages' to 'notices' throughout the interface (032 comments) [extensions/Echo] - 10https://gerrit.wikimedia.org/r/297913 (https://phabricator.wikimedia.org/T139520) (owner: 10Mooeypoo) [22:46:44] mooeypoo, the API should change later. [22:46:52] ^ mooeypoo, minor. Testing now. [22:57:22] The "Xy notifications" (e.g. 12 notifications) next to "[All][Read][Unread]" looks out of place [22:57:32] Everything is more chrome-y, and that's just sitting there as plain text. [22:57:55] (03PS2) 10Mooeypoo: Change 'messages' to 'notices' throughout the interface [extensions/Echo] - 10https://gerrit.wikimedia.org/r/297913 (https://phabricator.wikimedia.org/T139520) [22:58:33] matt_flaschen, that was the design given for results that only have 1 page [22:58:41] (03CR) 10Mattflaschen: [C: 032] Change 'messages' to 'notices' throughout the interface [extensions/Echo] - 10https://gerrit.wikimedia.org/r/297913 (https://phabricator.wikimedia.org/T139520) (owner: 10Mooeypoo) [22:59:05] Okay, then it's a design critique. [22:59:33] matt_flaschen, Pauism. [23:02:35] 03Collab-Team-Q1-July-Sep-2016, 10Notifications, 13Patch-For-Review: Change 'messages' to 'notices' everywhere (where 'messages' referred to a section name) - https://phabricator.wikimedia.org/T139520#2440054 (10Mattflaschen-WMF) [23:04:18] mooeypoo, also, I don't know why I only have 45 notifications. [23:04:46] And they only go back to May 9. This is my main account. [23:05:30] In alerts, I see things from 9 months ago. [23:05:48] matt_flaschen, can that be the migration thing? [23:05:58] the scripts or whatever? [23:06:00] mooeypoo, yeah, I was thinking maybe. I'll let that finish before complaining further. [23:06:16] actually, I should probably run those locally in vagrant too.... [23:06:22] (03Merged) 10jenkins-bot: Change 'messages' to 'notices' throughout the interface [extensions/Echo] - 10https://gerrit.wikimedia.org/r/297913 (https://phabricator.wikimedia.org/T139520) (owner: 10Mooeypoo) [23:06:25] completely forgot to do that [23:06:33] mooeypoo, yeah, I forgot to as well, but I did earlier today. [23:07:19] matt_flaschen, which scripts are those? [23:07:20] In prod, even group 1 isn't done unread wikis, let alone group 2 (which is still on azwiki). But I don't know if backfillUnreadWikis should matter for single-wiki. [23:07:29] it's the backfill? those are bundles though [23:07:40] backfillUnreadBundles, backfillUnreadWikis. [23:07:41] (03CR) 10Dereckson: [C: 032] "SWAT" [extensions/Flow] (wmf/1.28.0-wmf.9) - 10https://gerrit.wikimedia.org/r/297914 (owner: 10Mattflaschen) [23:08:24] that was fast. Then again, I have a tiny local wiki [23:08:54] mooeypoo, I'm going to file just in case, because while it's plausible it could be caused by backfillUnreadBundles, that's done in production, and backfillUnreadWikis seems less plausible. [23:08:54] (03PS1) 10Dereckson: Change 'messages' to 'notices' throughout the interface [extensions/Echo] (wmf/1.28.0-wmf.9) - 10https://gerrit.wikimedia.org/r/297919 (https://phabricator.wikimedia.org/T139520) [23:09:38] oy, there are bugs in fetching for the special page [23:09:45] (03CR) 10Dereckson: [C: 032] "SWAT" [extensions/Echo] (wmf/1.28.0-wmf.9) - 10https://gerrit.wikimedia.org/r/297919 (https://phabricator.wikimedia.org/T139520) (owner: 10Dereckson) [23:10:24] I have lots of unread notifications (for testing) and when I look at devwiki "All" filter, I just see unread stuff... as if I have no read notifs from these dates, but then when I click on "read" I see at least 1 notification from "Yesterday" which otherwise showed me only unread before [23:10:28] wtf [23:11:16] Yeah [23:11:31] And I don't think my main account has only 45 notifications. [23:12:34] 03Collab-Team-Q1-July-Sep-2016, 10Notifications: Special:Notifications not showing all my notifications in production - https://phabricator.wikimedia.org/T139696#2440091 (10Mattflaschen-WMF) [23:12:45] mooeypoo, is the popup supposed to have infinite scroll? [23:12:55] Or do you just have to go to Special:Notifications after the first batch. [23:13:17] ok found it [23:13:25] (03PS2) 10Mattflaschen: Change 'messages' to 'notices' throughout the interface [extensions/Echo] (wmf/1.28.0-wmf.9) - 10https://gerrit.wikimedia.org/r/297919 (https://phabricator.wikimedia.org/T139520) (owner: 10Dereckson) [23:13:27] it's a front-end bug, we ask for notunreadfirst: 1 for some weird reason [23:13:46] omg that might actually be the reason for the pagination fluke [23:13:49] ... [23:13:51] * mooeypoo tests [23:14:05] mooeypoo, that should only affect ordering, though, right? [23:14:14] It doesn't even let me page further. [23:14:38] yes, but the front end re-orders again, so if the API returns something that is not properly ordered, it takes the "last notification" as its continue value, right? If the last notif is not REALLY the last notif, then the continue value is wrong [23:14:41] boom [23:15:04] let me test this, though. It makes sense that it would be related, but let me see if that's actually fixing things before I get all giddy [23:16:38] (03Merged) 10jenkins-bot: Use the right compact msg for flowusertalk-* expandable notifications [extensions/Flow] (wmf/1.28.0-wmf.9) - 10https://gerrit.wikimedia.org/r/297914 (owner: 10Mattflaschen) [23:17:41] mooeypoo, I see. The frontend is ordering by date, but the API is not returning in date order, so continue is out of sync. [23:23:56] I think so, yeah [23:31:55] matt_flaschen, SUCCESS. That fixed it :D [23:32:05] both bugs -- the one reported, and the one I just saw [23:32:22] (03PS1) 10Mooeypoo: Only fetch 'unreadfirst' for the Popup, not Special:Notifications [extensions/Echo] - 10https://gerrit.wikimedia.org/r/297924 (https://phabricator.wikimedia.org/T136885) [23:32:24] \o/ [23:33:08] mooeypoo, do you think this could cause the too-few notifications I see on enwiki, or is that something else? [23:33:21] matt_flaschen, hm, that sounds like it's something else [23:33:45] mooeypoo, also, is the popup supposed to have infinite scroll. Or what is supposed to happen if you have more than the initial batch shown? [23:34:18] it will always take unread-first, but the popup also SORTS unreadfirst, so the sorting of both back- and front-end are the same [23:34:24] but also, no infinite scroll anyways [23:34:46] mooeypoo, so you get one batch, then go to S:N for everything else? [23:35:15] hm I am thinking of changing this fix, though. I dislike doing the { unreadFirst: true } in there... maybe I should do "unreadFirst: this.unreadFirst" and have the popup controller set itself up for showing that. Not critical, I can see uses for either, since the fetchLocalNotifications is used only for the popup [23:35:35] matt_flaschen, yeah, because unreadfirst will only work if you continue to have unread messages after the first batch [23:35:45] which is fine in the case of the popup because it ALSO orders things unread-first [23:36:16] mooeypoo, yeah, I'm just asking in general, not because I see a subtle flaw in your patch. [23:36:27] yeah, no I'm just wondering. [23:36:39] but the special page orders by date regardless of read-status, so it should be getting first all notifs for the dates... if the API sends unread first, it may "miss" some read notifications in the middle. [23:37:11] I think the best way to put it is the consistency of the sorting. The popup sorts unread-first + timestamp. So does the API. The special page sorts timestamp-only -- and the API should follow suit (which is why I removed 'unreadfirst' from that call) [23:37:34] mooeypoo, right, it makes sense to me. [23:38:02] woot, I had a feeling it was the continue value being wrong, and something with the sorting - but it turned out that the front end *called* for the wrong sorting. heh [23:38:56] at least that bug is out. I think it's ok to leave it as-is. We're going to have to do a couple of front-end API rewrites soon to avoid caching promises that shouldn't be cached, and we can figure out if we want to generalize "unreadFirst" filter or not. It's really theoretical now, as we have popup and special page, and each use a different call method [23:47:07] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 13Patch-For-Review, 07Wikimedia-log-errors: Undefined property: stdClass::$event_deleted in Event.php - https://phabricator.wikimedia.org/T139536#2435307 (10Krinkle) @Sbisson EchoEvent::loadFromRow <- EchoEvent::newFromRow: 1. EventMapper::fetchById() - Uses... [23:48:39] (03CR) 10Krinkle: Undefined property: stdClass::$event_deleted (031 comment) [extensions/Echo] - 10https://gerrit.wikimedia.org/r/297831 (https://phabricator.wikimedia.org/T139536) (owner: 10Sbisson)