[00:01:12] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 13Patch-For-Review, 05WMF-deploy-2016-07-26_(1.28.0-wmf.12): [production] minor: 'Mark as read' cross-wiki alerts displays blank flyout - https://phabricator.wikimedia.org/T132202#2485941 (10Quiddity) [00:09:08] 03Collab-Team-Q1-July-Sep-2016, 10Notifications, 07Design: Allow unwatching a Flow topic/board from a notification about that topic/board - https://phabricator.wikimedia.org/T132975#2485957 (10Mattflaschen-WMF) >>! In T132975#2433018, @Pginer-WMF wrote: > In order to avoid increasing the visual language, as... [00:15:14] 10Flow, 10UI-Standardization, 07Design, 07RfC: Review unsubscribe/unwatch icon - https://phabricator.wikimedia.org/T134752#2275790 (10Mattflaschen-WMF) >>! In T134752#2483367, @Volker_E wrote: > As laid out at https://phabricator.wikimedia.org/T132975#2433018 > >> we can start by using the empty star ico... [00:40:24] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 13Patch-For-Review, 05WMF-deploy-2016-07-26_(1.28.0-wmf.12): Add 'seenTime' values for alert/message in the API when fetching list of notifications - https://phabricator.wikimedia.org/T139993#2449229 (10Etonkovidova) @Mattflaschen-WMF - in betalabs 1.28.0-alp... [01:45:38] (03CR) 10Catrope: [C: 032] Check for local unread talk notifications in alert popup too [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300445 (https://phabricator.wikimedia.org/T141047) (owner: 10Mooeypoo) [01:48:55] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 13Patch-For-Review, 05WMF-deploy-2016-07-26_(1.28.0-wmf.12): Add 'seenTime' values for alert/message in the API when fetching list of notifications - https://phabricator.wikimedia.org/T139993#2486050 (10Mattflaschen-WMF) >>! In T139993#2485990, @Etonkovidova... [01:50:15] Have a good night, all. [01:54:34] (03Merged) 10jenkins-bot: Check for local unread talk notifications in alert popup too [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300445 (https://phabricator.wikimedia.org/T141047) (owner: 10Mooeypoo) [03:28:35] (03CR) 10Mattflaschen: [C: 032] "Looks good, works with both one and multiple data attributes." [extensions/Echo] - 10https://gerrit.wikimedia.org/r/299910 (https://phabricator.wikimedia.org/T115845) (owner: 10Mooeypoo) [03:28:56] (03CR) 10Mattflaschen: "Sorry, wrong patch." [extensions/Echo] - 10https://gerrit.wikimedia.org/r/299910 (https://phabricator.wikimedia.org/T115845) (owner: 10Mooeypoo) [06:43:38] (03PS1) 10Aaron Schulz: Convert deferred update to using AtomicSectionUpdate [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300503 [06:46:34] (03CR) 10jenkins-bot: [V: 04-1] Convert deferred update to using AtomicSectionUpdate [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300503 (owner: 10Aaron Schulz) [09:10:21] 03Collab-Team-Q1-July-Sep-2016, 10Notifications, 07Design: Allow unwatching a Flow topic/board from a notification about that topic/board - https://phabricator.wikimedia.org/T132975#2486366 (10RHo) Hi @Mattflaschen-WMF – Since @Pginer-WMF is on vacation until Aug 10, I can outline the reasons for using the u... [09:13:41] 10Flow, 10UI-Standardization, 07Design, 07RfC: Review unsubscribe/unwatch icon - https://phabricator.wikimedia.org/T134752#2275790 (10RHo) I've just commented on that ticket {T132975} with some additional context for the decision. [10:34:19] 10Notifications, 10Mention-Notification, 06TCB-Team, 07German-Community-Wishlist, 03TCB-Team-Sprint-2016-07-14: Bundle mention notifications per save - https://phabricator.wikimedia.org/T140224#2457076 (10MGChecker) Note: It schould be "Username doesn't exist", without a s at the end. [11:16:02] (03PS14) 10WMDE-Fisch: Add mention failure notification for multiple section edits [extensions/Echo] - 10https://gerrit.wikimedia.org/r/298419 (https://phabricator.wikimedia.org/T138942) [11:36:00] (03PS29) 10WMDE-Fisch: Echo notifications for mention failures [extensions/Echo] - 10https://gerrit.wikimedia.org/r/295351 (https://phabricator.wikimedia.org/T136326) [11:37:45] (03CR) 10WMDE-Fisch: "PS 29 slightly changes the naming of the user variable in the extra. The naming is more neutral that way and can be reused better in the f" [extensions/Echo] - 10https://gerrit.wikimedia.org/r/295351 (https://phabricator.wikimedia.org/T136326) (owner: 10WMDE-Fisch) [11:44:28] (03PS15) 10WMDE-Fisch: Add mention failure notification for multiple section edits [extensions/Echo] - 10https://gerrit.wikimedia.org/r/298419 (https://phabricator.wikimedia.org/T138942) [11:47:58] (03CR) 10jenkins-bot: [V: 04-1] Add mention failure notification for multiple section edits [extensions/Echo] - 10https://gerrit.wikimedia.org/r/298419 (https://phabricator.wikimedia.org/T138942) (owner: 10WMDE-Fisch) [11:50:24] (03PS16) 10WMDE-Fisch: Add mention failure notification for multiple section edits [extensions/Echo] - 10https://gerrit.wikimedia.org/r/298419 (https://phabricator.wikimedia.org/T138942) [12:26:52] (03PS1) 10Jakob: Send notification for mentions on changes [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300528 (https://phabricator.wikimedia.org/T138938) [12:29:14] (03CR) 10Hashar: "recheck" [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300503 (owner: 10Aaron Schulz) [12:29:51] (03PS2) 10Jakob: Send notification for mentions on changes [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300528 (https://phabricator.wikimedia.org/T138938) [12:31:08] 10Notifications: Months in the notifications should be lowercase - https://phabricator.wikimedia.org/T141092#2486809 (10Stryn) [12:37:50] (03PS3) 10Jakob: Send notification for mentions on changes [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300528 (https://phabricator.wikimedia.org/T138938) [12:44:09] (03Abandoned) 10Jakob: WIP Send notification for mentions on changes [extensions/Echo] - 10https://gerrit.wikimedia.org/r/297997 (https://phabricator.wikimedia.org/T138938) (owner: 10Jakob) [12:54:45] 10Notifications, 07I18n: Months in the notifications should be lowercase - https://phabricator.wikimedia.org/T141092#2486839 (10matej_suchanek) Same in Czech, seems to be side effect of T137634 [13:10:04] 06Collaboration-Team-Interested, 10Notifications: Sitewide notifications through Echo - https://phabricator.wikimedia.org/T58361#608596 (10Luke081515) Any updates here? [13:16:55] 06Collaboration-Team-Interested, 10Notifications: Sitewide notifications through Echo - https://phabricator.wikimedia.org/T58361#2486884 (10MGChecker) [15:15:27] (03CR) 10WMDE-leszek: [C: 031] "Still CR+1" [extensions/Echo] - 10https://gerrit.wikimedia.org/r/295351 (https://phabricator.wikimedia.org/T136326) (owner: 10WMDE-Fisch) [15:59:07] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications: Change "seenTime" format to ISO 8601 in Notifications front-end - https://phabricator.wikimedia.org/T141115#2487552 (10Mooeypoo) [15:59:29] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 13Patch-For-Review, 05WMF-deploy-2016-07-26_(1.28.0-wmf.12): Add 'seenTime' values for alert/message in the API when fetching list of notifications - https://phabricator.wikimedia.org/T139993#2449229 (10Mooeypoo) >>! In T139993#2486050, @Mattflaschen-WMF wrot... [16:45:51] 03Collab-Team-Q1-July-Sep-2016, 10Notifications: Change "seenTime" format to ISO 8601 in Notifications front-end - https://phabricator.wikimedia.org/T141115#2487804 (10jmatazzoni) [16:53:39] stephanebisson: yes, it's quite interesting to watch notification count updates if notifications were from deleted topics... They get purged from user view very slowly [16:54:04] etonkovidova: yes :( there 's a lot going on in this issue [16:54:19] stephanebisson: yeah [16:54:40] etonkovidova: I know what the problem is but I'm still looking for the solution [16:55:23] stephanebisson: so, the goal is - notificaitons from deleted/suppressed topics and from deleted boards should not be visible to users? [16:55:39] etonkovidova: yes [16:56:07] etonkovidova: same thing for regular pages, but it's handled differently [16:56:23] stephanebisson: ok [16:56:33] 10Collab-Notifications-Page, 03Collab-Team-2016-Apr-Jun-Q4, 13Patch-For-Review, 07User-notice, 05WMF-deploy-2016-07-26_(1.28.0-wmf.12): Turn the cog icon into a menu - https://phabricator.wikimedia.org/T115528#2487876 (10jmatazzoni) Thanks for pointing out these inconsistencies in the numbering system El... [16:58:52] 10Collab-Notifications-Page, 03Collab-Team-2016-Apr-Jun-Q4, 13Patch-For-Review, 07User-notice, 05WMF-deploy-2016-07-26_(1.28.0-wmf.12): Turn the cog icon into a menu - https://phabricator.wikimedia.org/T115528#2487893 (10jmatazzoni) Meanwhile, what about the much simpler issue I pointed out above: > @Mo... [17:27:56] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 13Patch-For-Review, 05WMF-deploy-2016-07-26_(1.28.0-wmf.12): Add 'seenTime' values for alert/message in the API when fetching list of notifications - https://phabricator.wikimedia.org/T139993#2487973 (10jmatazzoni) 05Open>03Resolved [17:28:15] Taking a break for an hour. Ping me on Hangouts if there is anything high-priority. [17:30:30] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 10Collaboration-Community-Engagement, 13Patch-For-Review, 07User-notice: Revise Sorting of Notifications on the Fly-Out Menus - https://phabricator.wikimedia.org/T123018#2487984 (10jmatazzoni) [17:30:33] 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#2487983 (10jmatazzoni) 05Open>03Resolved [17:46:55] (03Abandoned) 10Mooeypoo: [WIP] OOUI'fy the Special Page notification items [extensions/Echo] - 10https://gerrit.wikimedia.org/r/276684 (owner: 10Mooeypoo) [17:50:52] 10Notifications, 07I18n: Months in the notifications should be lowercase - https://phabricator.wikimedia.org/T141092#2486809 (10Etonkovidova) 1.28.0-wmf.11 displays months not capitalized when a week day or today/yesterday is displayed (was addressed in {T137634}) However, months are still capitalized when t... [18:29:37] matt_flaschen, meh, we may have changed 'seenTime' format to 8601, but notification timestamp still either go by mw timestamp or unix.... so I need to convert every time I check. [18:31:05] 03Collab-Team-Q1-July-Sep-2016: Notifications page: remove mw-echo-special-header-link - https://phabricator.wikimedia.org/T141141#2488382 (10Etonkovidova) [18:31:51] 10Collab-Notifications-Page, 03Collab-Team-2016-Apr-Jun-Q4, 13Patch-For-Review, 07User-notice, 05WMF-deploy-2016-07-26_(1.28.0-wmf.12): Turn the cog icon into a menu - https://phabricator.wikimedia.org/T115528#2059159 (10Etonkovidova) Following @jmatazzoni comment above, filed the task - {T141141} [18:52:01] mooeypoo, oh, I see what you mean. [18:52:16] That's stupid, it gives 5 formats, except the one that the docs explicitly say should be the *only* format. [18:52:19] mooeypoo, will add it. [18:53:33] 10Collab-Notifications-Page, 03Collab-Team-2016-Apr-Jun-Q4, 13Patch-For-Review, 07User-notice, 05WMF-deploy-2016-07-26_(1.28.0-wmf.12): Turn the cog icon into a menu - https://phabricator.wikimedia.org/T115528#2488559 (10jmatazzoni) Elena writes: > Following @jmatazzoni comment above, filed the task - T... [19:00:13] (03PS1) 10Mattflaschen: Add ISO 8601 date format to notification output [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300596 [19:08:15] matt_flaschen, also, all seenTime should change; I think we have instances where we send it to the js vars as MW timestamp? [19:08:29] I can't manage to get the wgEchoSeenTime to be ISO [19:08:39] not sure if it's just a matter of flushing cache though [19:08:48] I was going to look into it after lunch [19:08:52] (got food now) [19:11:38] mooey|food, oh, yeah, I didn't change that. Let me take a look to see if there is any usage on wiki. [19:13:48] matt_flaschen, the funny thing is that we wont really be able to "deprecate" the js var format -- but we don't really need to, I don't think [19:14:24] mooey|food, yeah, that's why I'm doing mwgrep. I can't deprecate it. I would have to add utcalert, but that's kind of sucky (the only reason I did it in the other patch is there were already a bunch). [19:14:50] * mooey|food nods [19:14:54] There actually is a way to deprecate wg's, though, come to think of it. [19:15:03] There is? [19:15:04] I'm not sure how straightforward it is to do from server-side (it triggers a console warning). [19:15:12] oh, we can change its name to the new one [19:15:33] wgEchoSeenTime -> wgNotificationSeenTime [19:15:43] the new one will have ISO, old stays the same [19:15:49] then we also make James_F happy [19:15:52] mooey|food, yeah, but still a little crufty. [19:16:11] mooey|food, okay, maybe not wg. Grep mw.log.deprecate in core. [19:16:13] Things like: [19:16:23] resources/src/mediawiki.legacy/wikibits.js: mw.log.deprecate( win, 'addClickHandler', $.noop, msg ); [19:16:32] hm [19:16:34] So you can call window.addClickHandler, but it triggers a warning. [19:16:43] I don't know if it can be used for wg. [19:16:52] mooey|food, I'm inclined to just break compat, but I want to check the usage first. [19:17:19] I think we're the only ones using it, but we can also go to the renaming plan [19:17:30] we wanted to rename Echo to Notifications anyways, no? [19:17:55] Nice [19:17:56] Yes. [19:17:59] mattflaschen@terbium:~$ mwgrep wgEchoSeenTime [19:18:00] (total: 0, shown: 0) [19:18:02] mattflaschen@terbium:~$ mwgrep --user wgEchoSeenTime [19:18:03] (total: 0, shown: 0) [19:18:05] Define "we". [19:18:15] Not used anywhere at all, so I'm just going to break compat. [19:18:17] Product? [19:18:28] James_F mostly, but I thought it was the plan in general [19:18:30] Yeah, I'm kidding. Yes, the official product name is notifications. [19:19:33] (03CR) 10Mattflaschen: [C: 04-1] "Amending" [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300596 (owner: 10Mattflaschen) [19:20:09] matt_flaschen, also, i just realized, changing the name is also good in terms of purging the cache for everyone [19:20:21] otherwise we'll have a bit of mismatch of dates [19:20:40] not really purging, but refreshing the values for sure [19:22:07] mooey|food, no, because we don't cache the page for logged in users. [19:22:18] In Varnish anyway. [19:22:25] matt_flaschen, we cache the value of seen time, no? [19:22:40] oh I see what you mean [19:22:41] mooey|food, I'm not changing the low-level storage, that will stay TS_MW. [19:22:52] matt_flaschen, that won't cause issues? [19:24:02] mooey|food, not if I do it right. In seriousness, don't see a reason to change that. TS_MW is used in a lot of places in the DB. [19:24:26] mooey|food, e.g. rev_timestamp is TS_MW in the DB, but ISO in https://www.mediawiki.org/w/api.php?action=query&prop=revisions&titles=MediaWiki&rvlimit=10 . [19:24:32] * mooey|food nods [19:24:41] I just want to verify we don't get mismatching formats [19:25:07] mooey|food, technically, I don't know if there is a standard that says wg's must be TS_ISO_8601 (there is for API), but no one is using it, so I'm changing it to make it easier for the client-side. [19:25:16] But no reason to change storage. [19:25:35] We do some of the tests in the "back" end too (SpecialNotifications.php for instance) and we need to change those too from simple comparison ( date <= seentime ) to actual date comparison [19:25:42] I don't think equality will work with ISO? [19:26:03] I can do that, btw, as part of the front end change - but just checking [19:26:20] in JS, I'm using moment( notifDate ).isBefore( seenTime ) [19:26:21] mooey|food, no, ISO sorts as a string, as long as it's always the same format. [19:26:37] oh cool so I don't need to use moment at all in comparisons [19:26:39] It's actually basically the exact same as TS_MW, just with some T's, Z's, and dashes. [19:26:53] hm I migth want to do that for timezones, but I think we are correcting for that [19:27:02] mooey|food, it should always end in Z and be UTC, I checked that. [19:27:13] ok awesome [19:27:24] I looked on a wiki that does use a different time zone, but it was still UTC. [19:27:40] regardless, the seen time of any source should always match the timestamp of notifs in terms of timezone [19:27:46] * mooey|food nods [19:27:47] awesome [19:28:02] I will need to translate it back to local, though [19:28:28] I trusted the non UTC reply from local requests, but that is not good practice anyways when we deal with different sources [19:28:52] moment can do that easily [19:29:18] mooey|food, there is a local-timezone for some of the other timestamp formats. E.g. utcmw and mw. I was wondering if you would want that. [19:30:50] mooey|food, but yeah, comparing between different sources will be easier if you just use UTC, so I'm not sure we should add "iso8601". [19:31:28] mooey|food, the way it works, getTime defaults to TS_MW, but you can specify another format in the call. So existing callers are not affected. [19:40:28] matt_flaschen, probably not worth adding local vs utc anymore, but I need to make sure the front end adjusts to that, and translates all timestamps to local time [19:40:56] in the view, that is [19:41:15] I think I"ll keep them utc in the models - that will save us a lot of headache in terms of comparisons and equality checks, etc [19:41:22] the display will then just adjust to local [19:42:20] That makes sense to me. [19:42:40] mooey|food, but make sure that local also affects grouping. [19:43:18] mooey|food, if "yesterday" is all the events that happened UTC yesterday, that will be confusing, even if the dates are displayed locally. [19:44:54] mooey|food, while I'm at it, I will also change it to 'notice', since that is also a breaking change, and I would prefer people can adjust their code once. (In theory there are no WMF-wiki callers, but I can't know about third party). [20:01:42] 03Collab-Team-Q1-July-Sep-2016, 10Notifications, 07I18n: Months in the notifications should be lowercase - https://phabricator.wikimedia.org/T141092#2488693 (10jmatazzoni) [20:13:11] mooeypoo, if I trigger an emit in the constructor, is that bad, or does it not matter since nothing should be listening yet? [20:13:25] I'm fixing the client-side part of the wgEchoSeenTime change. [20:13:41] matt_flaschen, yeah don't emit in the constructor [20:13:48] why do you want to? [20:13:56] mooeypoo, so I can use an existing method and ignore the emit. :) [20:14:06] Won't do it, I can make an internal helper method excluding the emit. [20:14:22] Why would you need to emit from the constructor though, at all? [20:14:35] mooeypoo, I don't, it would just be a side effect I don't care about. [20:15:05] matt_flaschen, what is changing in the event emitting in general with seen time, though? [20:15:57] mooeypoo, nothing, it's about notice/message logic (we need to fix it everywhere...). I wanted to centralize it, but I realized it only applies to the wg currently. [20:16:08] mooeypoo, it will make slightly more sense when you see the code. [20:28:39] (03PS2) 10Mattflaschen: BREAKING CHANGE: More ISO 8601 for seen time [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300596 [20:28:46] ^ mooeypoo [20:52:20] (03PS7) 10Mooeypoo: Redo the notification badges [extensions/Echo] - 10https://gerrit.wikimedia.org/r/299910 (https://phabricator.wikimedia.org/T115845) [20:52:32] matt_flaschen, sorry, was trying to css-frenzy with RoanKattouw to solve some seriously annoying css stuff in the badge fix [20:52:33] looking now [20:53:17] omg are we changing alert/notice in seen time but not anywhere else? [20:53:19] do we want to do that? [20:53:22] it's so confusing :( [20:54:13] mooeypoo, I'm open to some second opinions. RoanKattouw? [20:55:13] He's eating a sandwich, he'll opinionate when he's done. [20:55:19] mooeypoo, I thought it was a good idea since then we only break compat for the wg's once. [20:55:28] matt_flaschen, I'm not necessarily against it, i'm just saying, inconsistencies are confusing. [20:55:35] byt yeah, good point on that [20:55:45] mooeypoo, yeah, but it's already inconsistent. This just makes it still inconsistent, but a tiny bit more inconsistent. [20:56:03] LOL, I meant to say "a tiny bit more consistent" [20:56:05] mooeypoo, there are no other wg's that still use alert/message. [20:56:18] no, but all other **code** uses alert/message [20:56:40] but yeah, youre "correcting" it in the right place, so that shouldn't break anyways [20:56:43] mooeypoo, not exactly, there is notifications-notice. [20:56:47] it's just confusing. I'm not against it. [20:56:56] I agree we need to change it very soon. [20:57:18] Krinkle asked me to look at the buildCssLinks thing, and I keep getting pulled off the mobile task. [20:57:22] Otherwise, I would just do it right now. [20:57:25] matt_flaschen, okay, so this fix only partially fixes the front-end, right? I still need to go in and change the way we compare dates in the controller (after fetching) since the item timestamp we use in there is .utcmw and we need the iso one [20:57:55] matt_flaschen, no I don't think you need to change much, I just want to make sure we're sync'ed [20:58:20] I'll make the rest of the front-end change on top of yours, just to verify I have it all, then +2 it [20:58:22] mooeypoo, oh, doh, I meant to do that but got distracted by the alert/notice thing. [20:58:39] mooeypoo, you can also amend mine if you want. [20:58:46] mooeypoo, or I can do it now. [20:59:23] matt_flaschen, either way. I'm going to have to go in and add the seenTime for external sources in special page too anywyays [20:59:43] it's a different task, but same concept, so if you want to quickly amend yours, awesome, but if you have other things to do, I can pick it up [21:00:05] mooeypoo, okay, I'll amend mine. [21:00:33] (03CR) 10Mooeypoo: [C: 04-1] "Super small petty comment about variable naming." (031 comment) [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300596 (owner: 10Mattflaschen) [21:00:37] I'm petty ^^ [21:00:55] mooeypoo, pot, meet kettle. [21:01:42] :D [21:01:54] matt_flaschen, wait, I just noticed you're removing the initialNotifCount -- is that on purpose? [21:02:07] I guess we're not using the footer notice in general [21:02:07] mooeypoo, yes, it's unused. [21:02:10] * mooeypoo nods [21:02:18] if I were RoanKattouw I'd say split the code to another commit [21:02:25] but RoanKattouw is eating a sandwich [21:02:31] Your call. -1 Is Law [21:02:58] It's not that crucial, honestly. [21:03:20] if it was a huge commit, I would've probably argued for it, but this is tiny, it's fine imho [21:03:24] My justification is that I *would* have changed that wg to alert/notice, but didn't since it was dead code, so I might as well remove the dead code. [21:03:28] (03CR) 10jenkins-bot: [V: 04-1] Redo the notification badges [extensions/Echo] - 10https://gerrit.wikimedia.org/r/299910 (https://phabricator.wikimedia.org/T115845) (owner: 10Mooeypoo) [21:04:44] Good point [21:04:50] Justification: Accepted [21:05:05] (Maybe add that into the commit message -- 'removed unused redundant code' and make RoanKattouw happy) [21:05:17] mooeypoo: Trick suggestion; RoanKattouw is never happy. [21:05:28] mooeypoo, isn't it? [21:05:30] In the commit message. [21:06:03] matt_flaschen, sorry, sorry... I am blind [21:06:15] I totally missed that, even though I *read* it twice. Ha [21:06:26] brb [21:06:28] It's understandable, it's really long. [21:06:31] ;) [21:10:37] mooeypoo, I didn't mean 'style' in the sense of CSS, I meant it in the sense of "the new way" like https://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates , but point taken. [21:13:41] mooeypoo, what do you think of SeenTimeModel working by a Date or Moment object? [21:13:52] mooeypoo, right now, it claims to use number but really doesn't (it's a TS_MW string). [21:24:49] matt_flaschen, the seenTimeModel is supposed to store the values in a consistent way. Whichever way we choose should be easily compared later -- it shouldn't be doing too much "heavy lifting". I think if we can continue simple comparisons of ISO dates, then it can probably stay strings only, no? [21:25:15] It can be string intstead of a number. If we use moment or date in there, we won't be able to use <= comparisons directly [21:25:43] mooeypoo, yeah, true, if string comparisons are a key thing, I'll keep it string. [21:25:55] It will probably just make it easier [21:26:20] matt_flaschen, I was thinking keeping things as straight-forward in the lower levels of the UI, and only using moment to translate from utc to current timezone in the widgets [21:26:42] that way, all and any calculation in the back end and the back-end-of-the-MVC is consistent [21:27:08] otherwise I am worried we'll start getting confusing inconsistencies and worry about creating correct time objects [21:27:36] mooeypoo, I can understand that (just keep it the same kind of string everywhere, easy) [21:27:57] mooeypoo, I was thinking (use a date object so you don't have to worry what kind of string it is, it's a date) [21:28:00] (03CR) 10Catrope: [C: 032] Convert deferred update to using AtomicSectionUpdate [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300503 (owner: 10Aaron Schulz) [21:28:04] I can see both sides, so I'll defer to you. [21:29:12] matt_flaschen, yeah I see the point of the date, but wherever we aren't being consistent, we're using MW timestamp, which requires a format anyways to be translated into moment dates (and js dates, iirc) so it's probably best to just fix everything to use the same string? [21:30:01] I'll do it like that. [21:30:09] * matt_flaschen mutters about operator overloading being removed from ECMAScript 7, so we can't do momentDate <= otherMomentDate [21:30:40] https://www.reddit.com/r/programming/comments/1wtbvy/value_objects_and_operator_overloading_in/ [21:31:36] ooh [21:32:18] (03PS8) 10Mooeypoo: Redo the notification badges [extensions/Echo] - 10https://gerrit.wikimedia.org/r/299910 (https://phabricator.wikimedia.org/T115845) [21:35:48] (03Merged) 10jenkins-bot: Convert deferred update to using AtomicSectionUpdate [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300503 (owner: 10Aaron Schulz) [21:36:07] (03CR) 10jenkins-bot: [V: 04-1] Redo the notification badges [extensions/Echo] - 10https://gerrit.wikimedia.org/r/299910 (https://phabricator.wikimedia.org/T115845) (owner: 10Mooeypoo) [21:37:34] (03PS9) 10Mooeypoo: Redo the notification badges [extensions/Echo] - 10https://gerrit.wikimedia.org/r/299910 (https://phabricator.wikimedia.org/T115845) [21:37:46] * mooeypoo stares at selenium reeeeeally reaally hard [21:37:49] you can click it, I know you can [21:40:29] (03CR) 10jenkins-bot: [V: 04-1] Redo the notification badges [extensions/Echo] - 10https://gerrit.wikimedia.org/r/299910 (https://phabricator.wikimedia.org/T115845) (owner: 10Mooeypoo) [21:46:53] mooeypoo, when we implement the code to do cross-wiki mark seen, we should watch out for different wikis on different versions of the train. [21:47:17] Safe bet is to make sure the updated ApiEchoMarkSeen is on all wikis before starting. Otherwise, old wikis will ignore timestampFormat. [21:50:15] 03Collab-Team-Q1-July-Sep-2016, 10Notifications: Make the notification highlights work better across wikis - https://phabricator.wikimedia.org/T134855#2488844 (10Mattflaschen-WMF) >>! In T134855#2471979, @Catrope wrote: > We discussed this in our team discussion meeting and @Mattflaschen-WMF came up with the f... [21:50:16] matt_flaschen, ... good point [21:56:32] (03PS10) 10Mooeypoo: Redo the notification badges [extensions/Echo] - 10https://gerrit.wikimedia.org/r/299910 (https://phabricator.wikimedia.org/T115845) [21:56:54] matt_flaschen, we can also wait with it until all wikis implemented. It's not a feature that's urgent, I believe? [21:57:05] the local update was more urgent, but the remote update can probably wait [21:59:39] mooeypoo, I think it is actually somewhat annoying people, but I think the best approach is to wait until the server-side API change is on all wikis before merging. [22:01:58] * mooeypoo nods [22:02:08] we can set the commit up but only merge after the train [22:04:17] (03CR) 10jenkins-bot: [V: 04-1] Redo the notification badges [extensions/Echo] - 10https://gerrit.wikimedia.org/r/299910 (https://phabricator.wikimedia.org/T115845) (owner: 10Mooeypoo) [22:04:36] (03PS1) 10Mooeypoo: Hide the 'preferences' link from Special:Notifications JS [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300671 (https://phabricator.wikimedia.org/T115528) [22:04:56] mooeypoo, same issue with utciso8601. We could convert it on the local server, but eh. [22:05:20] mooeypoo, I think easier to temporarily convert on client-side. [22:05:36] It's probably best if we don't convert anything until it is viewed [22:05:39] so only widgets convert [22:05:46] less confusion [22:07:05] (03PS1) 10Mooeypoo: Add a down indicator to the cog menu [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300672 [22:09:13] 10Collab-Notifications-Page, 03Collab-Team-2016-Apr-Jun-Q4, 13Patch-For-Review, 07User-notice, 05WMF-deploy-2016-07-26_(1.28.0-wmf.12): Turn the cog icon into a menu - https://phabricator.wikimedia.org/T115528#2488920 (10Mooeypoo) >>! In T115528#2488559, @jmatazzoni wrote: > Elena writes: > >> Following... [22:10:02] (03PS2) 10Mooeypoo: Hide the 'preferences' link from Special:Notifications JS [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300671 (https://phabricator.wikimedia.org/T115528) [22:10:22] 03Collab-Team-Q1-July-Sep-2016, 13Patch-For-Review: Notifications page: remove mw-echo-special-header-link - https://phabricator.wikimedia.org/T141141#2488941 (10Mooeypoo) a:03Mooeypoo [22:10:46] (03CR) 10Catrope: [C: 032] Add a down indicator to the cog menu [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300672 (owner: 10Mooeypoo) [22:11:09] 03Collab-Team-Q1-July-Sep-2016, 13Patch-For-Review: Notifications page: remove mw-echo-special-header-link - https://phabricator.wikimedia.org/T141141#2488382 (10Mooeypoo) [22:11:11] 10Collab-Notifications-Page, 03Collab-Team-2016-Apr-Jun-Q4, 13Patch-For-Review, 07User-notice, 05WMF-deploy-2016-07-26_(1.28.0-wmf.12): Turn the cog icon into a menu - https://phabricator.wikimedia.org/T115528#2059597 (10Mooeypoo) [22:11:50] (03CR) 10Catrope: [C: 032] Hide the 'preferences' link from Special:Notifications JS [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300671 (https://phabricator.wikimedia.org/T115528) (owner: 10Mooeypoo) [22:12:00] 10Collab-Notifications-Page, 03Collab-Team-2016-Apr-Jun-Q4, 13Patch-For-Review, 07User-notice, 05WMF-deploy-2016-07-26_(1.28.0-wmf.12): Turn the cog icon into a menu - https://phabricator.wikimedia.org/T115528#2488947 (10Mooeypoo) Just to be clear, the 'Preferences' link was removed only from the Javascr... [22:13:40] 10Collab-Notifications-Page, 03Collab-Team-2016-Apr-Jun-Q4: Mark as seen notifications from the Notifications Page - https://phabricator.wikimedia.org/T136576#2488954 (10Mooeypoo) The problems here are (a) the request for updating 'seenTime' takes a little time while things load (and may get interrupted if the... [22:16:02] 03Collab-Team-2016-Apr-Jun-Q4, 03Collaboration-Team-Archive-2015-2016, 10Flow, 10Notifications, and 2 others: Remove Notifications about posts/topics that have been Moderated - https://phabricator.wikimedia.org/T93673#1143233 (10Etonkovidova) Related bugs were filed as {T140836} and {T140327}. Test cases... [22:17:48] mooeypoo, so before we were talking about comparing ISO 8601, like in https://phabricator.wikimedia.org/diffusion/ECHO/browse/master/modules/model/mw.echo.dm.ModelManager.js;1a85e524269b10e01314b855794a71b2445ccc65$115 . [22:17:53] Two things about that: [22:18:11] 1. Did you start changing the notification side to use ISO 8601 (utciso8601, etc.)? [22:18:32] 2. We won't be able to reply on all of the wikis having it right away, again due to cross-wiki. [22:18:41] (03Merged) 10jenkins-bot: Add a down indicator to the cog menu [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300672 (owner: 10Mooeypoo) [22:18:43] If no to #1, I'll do that as well. [22:19:19] s/able to reply/able to rely/ [22:20:15] Regarding #2, I was saying to temporarily convert utcmw to ISO 8601 only if utciso8601 is unavailable. [22:23:08] (03Merged) 10jenkins-bot: Hide the 'preferences' link from Special:Notifications JS [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300671 (https://phabricator.wikimedia.org/T115528) (owner: 10Mooeypoo) [22:44:17] matt_flaschen, yeah I just realized that too [22:45:00] matt_flaschen, that sounds good. If iso doesn't exist, fetch utcunix, even and use moment to convert to iso [22:45:45] We can do that in the controller, where we fetch the timestamp -- if you're doing that, just be careful that we're fetching the timestamp for view and then comparing it in the apiData section of the controller (so there are 2 places in that method) [22:46:58] also, matt_flaschen we are currently storing localized time in the dm.NotificationItem -- we should make everything standard and store utc time with the conversion you are talking about, but then the widgets should convert the view to the correct timezone in moment. That means we need to fetch user.prop.somethingsomethingtimezone for that [22:47:29] matt_flaschen, so my only worry with these conversions is getting inconsistencies in the conversions, but I guess we'll just have to be super careful [22:54:03] mooeypoo, yep. The patch is continuing to expand, but I think we're taking the right approach. [22:54:14] mooeypoo, where do you mean "where we fetch the timestamp" exactly? [22:54:24] I see the other part about the comparison. [22:55:38] 06Collaboration-Team-Interested, 10Notifications: Echo's 'seen time' should be replaced with marking specific notifications as seen - https://phabricator.wikimedia.org/T110731#2489035 (10Mattflaschen-WMF) a:05Mattflaschen-WMF>03None [22:55:55] matt_flaschen, crap, I just saw that the mobile version of Special:Notifications crashes because of mw.Uri... this is really weird, but I'm thinking I may need to add it as a dependency to MobileFrontend's echo module [22:56:29] matt_flaschen, the controller has a few fetching methods, for local notifs, cross wiki, and by date -- but all of them use the same method to then analyze/break down the api data [22:56:41] matt_flaschen, createNotificationData [22:56:53] ^^ that's where we store the notificationItem data + compare with seenTime [22:57:42] so that's where we should go with utc (so the comparison is simple) -- which means that should probably not change much, except changing timestamp: apiData.timestamp.utcmw to apiData.timestamp.utciso8601 or something [22:58:20] **but** two things -- 1) then the notification item *widget* has a timestamp display. That's where we have to convert it to local time through moment (moment should have something like moment( timestamp ).zone( blah ) ) [22:58:47] mooeypoo, okay, I saw createNotificationData, but I thought you were also saying there was something outside that method I had to change. [22:58:53] but I just realized, we need to also do something for the special page... I can take that off your plate if you want, since it's all getting pretty complicated (or you can keep it if you want, up to you) [22:59:14] matt_flaschen, no, that should cover it, except for the special page -- in the special page, when we fetch by date, we use those dates as headers later [22:59:23] that's where we kinda have to convert to local time **first** actually [23:00:02] mooeypoo, yes, that's what I was saying earlier. I will keep working on it, but please review carefully. [23:00:07] because there, if we don't, we'll get wrong day segmentation. If you are looking at the messages at 6pm, but got a message at 4:30pm, it will think it was yesterday, because it's UTC, so it will split it to "yesterday" group [23:00:25] so in there, we will actually need to convert to local time *before* we split the notification into their "day" group [23:01:05] we can keep them in iso format, since moment reads them (just take off the mw formatting string from it) -- but the division to days is critical [23:01:08] * mooeypoo nods [23:02:34] 03Collab-Team-Q1-July-Sep-2016, 10Notifications: Use UTC and ISO 8601 everywhere - https://phabricator.wikimedia.org/T141164#2489042 (10Mattflaschen-WMF) [23:03:04] matt_flaschen, technically, we should stick to utc in the DM items anyways even in the special page (which would be annoying, because it means you need to convert to local for the day-segments but keep utc for DM objects) but in the case of the special page I am thinking it might actually not matter that much - the widgets will convert to proper timezone anyways, and ISO has timezone in it anyways, which will make it standard. **an [23:03:05] d** unlike the popups, the special page never has "mixed" notifs; all notifs are from the same source, so we shouldn't run into comparison issues when we sort etc [23:03:07] does that make sense? [23:05:07] mooeypoo, hmm, I understand your point but I kind of think we should keep it UTC in the model everywhere for consistency. [23:05:18] And to future proof it. [23:05:38] But I'm not sure. [23:05:51] matt_flaschen, I agree, I just don't want you to get down the loop of code-doom [23:06:11] but yeah, ideally, let's keep everything always consistent. UTC everywhere except display **should** be okay [23:06:19] No, it's okay, I think it's just a rabbit hole, not a loop. [23:06:40] hehe good [23:06:42] Although I do see a bunch of branching paths. [23:06:46] So it may actually be a gopher den. [23:06:56] ok, hm, thinking out loud here, semi rubber-ducking consultation question [23:07:02] ha :D [23:07:20] so the only worry I have with our strategy is the sorting [23:07:38] the dm sorts itself and the widgets sort themselves, but the widgets ask the DM for the timestamp [23:07:39] 03Collab-Team-Q1-July-Sep-2016, 10Notifications: Use UTC and ISO 8601 everywhere - https://phabricator.wikimedia.org/T141164#2489056 (10Mattflaschen-WMF) [23:07:58] it shouldn't be a problem because we do a simple <= check, and that doesn't matter if we're looking at UTC or local as long as everything is consistent [23:08:31] mooeypoo, why do the DM and widget both sort themselves? [23:08:35] so I think we're safe... unless I'm missing something? what do you think? Again, I'm only worried about things like the difference of days [23:08:45] matt_flaschen, the popup widget has widgets from multiple models [23:09:05] mooeypoo, so it sorts among the different models, but the models sort within-model? [23:09:12] the list of local items are stored in one list model, the xwiki item is a complex model with sub groups, and then each bundle-notification is its own model [23:09:41] inside themselves, they sort, so that we can ask them individually what their "latest" timestamp is and they just call the top item and ask -- but the widget gets them all, and needs to figure out where to place each one in the main big list [23:09:49] matt_flaschen, exactly [23:10:05] dm sorting isn't strictly needed -- it was more for convenience [23:10:25] the real important sorting is the widget sorting, which is what the user sees. [23:10:47] mooeypoo, yeah, I think it should work, but I haven't gotten deep enough to see how the day-separation on special actually works. But I can't think of any theoretical problems. [23:11:05] so since we're alking about relative dates and a big list, i think we're still safe comparing dates between items [23:11:06] yeah [23:11:20] the only exception is the special page, where we split things up by days, but again, we'll treat that separately anyways [23:11:32] As long as everything uses the same time zone (UTC) when sorting, it will work. [23:11:52] mooeypoo, even the special page could sort as UTC, it just has to segregate and render as local. But it doesn't really matter, it might sort as local, I'll have to see. [23:11:53] * mooeypoo nods [23:12:04] (see what makes more sense) [23:12:14] yeah the issue is the segregation, not the sorting [23:12:23] 10Collab-Notifications-Page, 06Collaboration-Team-Interested, 07Design, 07Tracking: Design adjustments for the Notifications Page - https://phabricator.wikimedia.org/T136567#2489061 (10jmatazzoni) [23:12:26] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 13Patch-For-Review: Project labels inside the cross-wiki bundle should link to the target wiki Notification Page - https://phabricator.wikimedia.org/T127419#2489062 (10jmatazzoni) [23:12:28] 10Collab-Notifications-Page, 03Collab-Team-2016-Apr-Jun-Q4: Mark as seen notifications from the Notifications Page - https://phabricator.wikimedia.org/T136576#2489060 (10jmatazzoni) 05Open>03Resolved [23:12:35] Yeah I thnk it'll be okay, I just wanted to float this and see if we can come up with any theoretical issues with this [23:12:41] i don't think so, though [23:13:43] I actually made a mistake initially in the special page reading the wrong dates and suddenly got my top list to be "tomorrow" (didn't say that, it had the date, because we don't have 'tomorrow' string ,but still) -- it was somewhat amusing [23:18:39] matt_flaschen, sorry to distract you but I can't find it... you have any idea if there's a resource loader module for mw.Uri ? [23:19:15] mooeypoo, yeah, mediawiki.Uri . It is supported for mobile, you just need a dependency. [23:19:17] Got it! [23:19:24] awesome, thanks! [23:19:33] weird that when I debugged that commit nothing failed and now things do [23:19:39] but... whatever :\ [23:19:51] mooeypoo, debug=true? Oh yeah, that totally changes load order. [23:20:07] it fails now with both debug=true and without it [23:20:11] Progress [23:20:16] but it worked when I worked on that patch O.o how weird is that [23:20:40] mooeypoo, I think Krinkle wants to get rid of debug=true and use source maps only. [23:20:42] I only noticed now because jmatazzoni___ asked me why it takes so long to load, and I saw it's not loading, it's broken [23:21:04] eh, as long as we can get proper debug stops in chrome I don't care what we use [23:21:21] but with minified code, debug points are useless [23:21:27] and it's really hard to see where something broke [23:22:23] * mooeypoo grunts [23:22:31] it's still failing. what the hell, MobileFrontend. [23:23:31] oh.... omg I'm silly. [23:27:49] (03PS1) 10Mooeypoo: Add mediawiki.Uri to Special:Notifications dependencies [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300680 [23:28:47] (03PS2) 10Mooeypoo: Add mediawiki.Uri to Special:Notifications dependencies [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300680 [23:29:04] (03CR) 10Catrope: [C: 032] Add mediawiki.Uri to Special:Notifications dependencies [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300680 (owner: 10Mooeypoo) [23:30:53] mooeypoo, yeah, that's the point of source maps, so you can debug minified code. [23:31:54] mooeypoo, also, moment apparently can't render easily to the right flavor of ISO 8601 (either it uses +00:00 or includes milliseconds). But it gives me an excuse to use Y (" Note: This complies with the ISO 8601 standard for dates past the year 9999 ") [23:32:38] Y ? [23:32:54] Also, good thing they plan for that! [23:33:04] "1970 1971 ... 9999 +10000 +10001" [23:33:24] + is the official ISO 8601 'shit just got real' character. [23:33:30] rofl [23:33:49] matt_flaschen, I think there's a formatting thing for moment for iso, no? [23:35:48] (03Merged) 10jenkins-bot: Add mediawiki.Uri to Special:Notifications dependencies [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300680 (owner: 10Mooeypoo) [23:36:52] mooeypoo, yeah, but it doesn't match the server. [23:37:10] mooeypoo, well, I tried .format() and .toISOString(). Neither are quite right. [23:37:29] matt_flaschen, you can format yourself, but that's a little crappy [23:37:37] though it might be okay for this, since it's supposed to be a temporary fallback [23:37:41] mooeypoo, yeah, I'm going to, for that reason. [23:37:52] wait, moment doesn't **recognize** iso, or just doesn't output it right? [23:37:57] i hope it recognizes it right O.o [23:38:53] mooeypoo, it's not that it outputs it wrong per se, but if we are using string sorting, I want it to use *exactly* the same format as the server. [23:39:05] E.g. [23:39:07] moment.utc( 1469218871 * 1000 ).year( 12311 ).format() [23:39:08] "12311-07-22T20:21:11+00:00" [23:39:13] vs. [23:39:16] "utciso8601": "2016-07-22T20:21:11Z", [23:39:23] ahha [23:39:38] matt_flaschen, you think it'll be okay to convert format manually or do you want to go with your idea of date/moment objects? [23:39:54] if we do the date/moment objects, we'll need to adjust all sorting callbacks, but that's not **that** terrible.... [23:40:15] mooeypoo, moment objects, if you're alright with that. [23:43:27] matt_flaschen, so, I am not entirely happy with having moment permeate our entire JS structure, but I can also see issues with not using it. [23:43:29] I'm not sure. [23:44:11] (03PS1) 10Catrope: Follow-up d47f0bd3: only capitalize the first letter of date titles on Special:Notifications [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300683 (https://phabricator.wikimedia.org/T141092) [23:44:26] mooeypoo: ---^^ [23:44:49] 03Collab-Team-2016-Apr-Jun-Q4, 10Notifications, 13Patch-For-Review, 05WMF-deploy-2016-07-26_(1.28.0-wmf.12), 07Wikimedia-log-errors: Array must contain at least one element in ApiEchoNotifications. php on line 341 - https://phabricator.wikimedia.org/T139529#2434975 (10Etonkovidova) Checked betalabs logs... [23:45:01] 03Collab-Team-Q1-July-Sep-2016, 10Notifications: Use UTC and ISO 8601 everywhere - https://phabricator.wikimedia.org/T141164#2489081 (10Mattflaschen-WMF) We may use UTC in the model, since moment's default ISO 8601 formatting does not match the server, so we would have to format it ourselves at least temporari... [23:45:16] matt_flaschen, how temporary is this problem do you think? When everything is matching and sync, will we still need all moment objects? Or is this just for the fallback? [23:46:14] (03CR) 10Mooeypoo: [C: 032] "The fact ::first-letter only works on block elements is ridiculous. Good catch. We should fix the internet." [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300683 (https://phabricator.wikimedia.org/T141092) (owner: 10Catrope) [23:46:24] mooeypoo: https://gerrit.wikimedia.org/r/299916 [23:47:32] mooeypoo, the only other one I can think of maybe is read timestamp. How is that handled when a notification is marked as read? [23:47:44] Seen we explicitly give the client server-generated ISO, so that's fine. [23:48:27] mooeypoo, basically, anywhere we generate a client-side timestamp we would need to format it ourselves I think. That should only happen if there's a time-based action, and the only ones I know of are read and seen. [23:48:33] But seen the server generates the time. [23:49:15] matt_flaschen, we only generate a fallback in notificationItem [23:49:15] For read it does too, but I'm not sure if the client uses that (it doesn't seem to be returned from mark-read API), or generates it's own temporary read timestamp. [23:49:31] and if you look there (have fun) there's a horrific fallback to MW timestamp [23:49:41] so we might as well put a less-horrific fallback to iso there [23:50:47] mooeypoo, what about the read timestamp after mark as read? Does it re-fetch the notification list, not care at all...? [23:51:01] 10Collab-Notifications-Page, 03Collab-Team-2016-Apr-Jun-Q4, 13Patch-For-Review, 07User-notice, 05WMF-deploy-2016-07-26_(1.28.0-wmf.12): Turn the cog icon into a menu - https://phabricator.wikimedia.org/T115528#2489084 (10Etonkovidova) Checked in betalabs. For JS enabled page, the link Preference is gone... [23:51:10] hm we don't care about the read timestamp, we treat it as a boolean [23:51:20] The server can update whatever it wants, but we just check whether or not it was read [23:51:48] The only thing we really touch in terms of timestamp is seen time, and that isn't done by the client either... I'm trying to think if we manipulate or create any other dates, I can't think of any [23:52:02] mooeypoo, thanks, I see, the controller coerces the date to boolean, and presumably when you mark it as read it just updates the boolean. [23:52:07] We do get a response from the server when updating seenTime, but that's just like asking for getting seen time from the API. [23:52:15] * mooeypoo nods [23:52:17] And that is the desired format of ISO. [23:52:27] the server updates the date/time of the read change, but the UI doesn't care [23:53:00] mooeypoo, I'm probably going to break for dinner in 15 minutes or so, but I think we're on the same page. We'll have one permanent ISO 8601 on the client, and one temporary. [23:53:18] * mooeypoo nods [23:53:24] (03Merged) 10jenkins-bot: Follow-up d47f0bd3: only capitalize the first letter of date titles on Special:Notifications [extensions/Echo] - 10https://gerrit.wikimedia.org/r/300683 (https://phabricator.wikimedia.org/T141092) (owner: 10Catrope) [23:53:29] mooeypoo, sadly, Y doesn't work (newer version?). [23:53:36] I think going by strings is the best and simplest, but if you see you're getting into too much of a hole, we can use moment objects. [23:54:12] I'd rather avoid that if possible, though; I kinda like it better with pure strings in the MC and moment/presentation in the V of the mvc [23:54:24] but i'm not completely against it, it depends how horrible the alternative is and how much it's needed [23:54:28] if that makes sense.. [23:55:29] mooeypoo, from my perspective, we could consider moment a "dumb value" (e.g. the way BigInteger is really just a value, despite being implemented as a class), and ignore the logic where it ought to be ignored. [23:55:42] mooeypoo, but I can see the other side too, and I'm willing to try it that way. [23:56:53] 03Collab-Team-Q1-July-Sep-2016, 13Patch-For-Review, 05WMF-deploy-2016-07-26_(1.28.0-wmf.12): Notifications page: remove mw-echo-special-header-link - https://phabricator.wikimedia.org/T141141#2489113 (10Etonkovidova) Checked the fix in betalabs. Before the fix: {F4299014} JS page after the fix: {F4299017} n... [23:57:21] mooeypoo, if only we were using C this wouldn't be an issue. struct tm is clearly a dumb value we can pass around. [23:57:38] Sure, there are ways to format it if you wanted to, but struct tm itself doesn't have any methods. [23:57:52] struct tm [23:57:56] Always a value, guaranteed [23:58:26] Oh, yes, C is always the solution to everything.... [23:58:28] :D [23:59:10] I actually like C. It serves and served it's intended purpose very well. [23:59:19] matt_flaschen, anyways, yeah, I don't think it really matters as long as everything uses the same thing. If it works "simple" with strings it'll probably be the most straight forward (comparisons, sorting, etc) but if it starts getting into being a huge pain, moment works great. [23:59:32] Unfortunately that intended purpose was not rich interactive APIs. [23:59:40] haha [23:59:56] I like C as a letter. I liked it a little less when I was programming in it.