[01:18:45] 06Collaboration-Team-Triage, 10Thanks, 13Patch-For-Review: Specify which edit was thanked in Special:Log/thanks, both for private and public records' sake - https://phabricator.wikimedia.org/T51087#2665987 (10Tjlsangria) Other useful parameters could include the prefixed page title and the revision ID presen... [03:07:13] (03PS3) 10Tjlsangria: Specify which revision was thanked in Special:Log/thanks [extensions/Thanks] - 10https://gerrit.wikimedia.org/r/311364 (https://phabricator.wikimedia.org/T51087) [03:07:20] (03CR) 10jenkins-bot: [V: 04-1] Specify which revision was thanked in Special:Log/thanks [extensions/Thanks] - 10https://gerrit.wikimedia.org/r/311364 (https://phabricator.wikimedia.org/T51087) (owner: 10Tjlsangria) [03:09:08] (03PS4) 10Tjlsangria: Specify which revision was thanked in Special:Log/thanks [extensions/Thanks] - 10https://gerrit.wikimedia.org/r/311364 (https://phabricator.wikimedia.org/T51087) [08:03:43] 06Collaboration-Team-Triage, 10Flow: Impossible to access to a Flow talk page after enabling/disabeling Flow - https://phabricator.wikimedia.org/T146617#2666292 (10Trizek-WMF) [08:04:41] 06Collaboration-Team-Triage, 10Flow: Impossible to access to a Flow talk page after enabling/disabeling Flow - https://phabricator.wikimedia.org/T146617#2666307 (10Trizek-WMF) p:05Triage>03High Triaging to High: that problem may impact roughly zh.wp, where Flow is a Beta feature. [09:49:42] 03Collab-Team-Q1-July-Sep-2016, 10Edit-Review-Improvements, 06Revision-Scoring-As-A-Service, 10rsaas-editquality: Research how to present ORES scores to users in a way that is understandable and meets their reviewing goals - https://phabricator.wikimedia.org/T146333#2666439 (10Pginer-WMF) @jmatazzoni I hav... [11:22:08] 03Collab-Team-Q1-July-Sep-2016, 10Edit-Review-Improvements-ReviewStream: Research current "new user" definitions and consider whether we need a different name for the ERI “new user” flag - https://phabricator.wikimedia.org/T145157#2666813 (10Pginer-WMF) >>! In T145157#2657649, @jmatazzoni wrote: > @Pginer-WMF,... [11:45:46] 03Collab-Team-Q1-July-Sep-2016, 10Edit-Review-Improvements, 10QuickSurveys: Retool quicksurveys so we can do a survey on one page only - https://phabricator.wikimedia.org/T146495#2663191 (10ovasileva) @Jdlrobson - looking for some background on quicksurveys, found this: https://www.mediawiki.org/wiki/Extens... [13:09:00] (03CR) 10Sbisson: [C: 032] UnreadNotificationCounter should always normalize the count [extensions/Echo] - 10https://gerrit.wikimedia.org/r/312552 (owner: 10Mooeypoo) [13:15:09] (03Merged) 10jenkins-bot: UnreadNotificationCounter should always normalize the count [extensions/Echo] - 10https://gerrit.wikimedia.org/r/312552 (owner: 10Mooeypoo) [13:44:17] (03CR) 10Sbisson: [C: 04-1] "Manual rebase needed :(" [extensions/Echo] - 10https://gerrit.wikimedia.org/r/311063 (owner: 10Mooeypoo) [15:23:25] 03Collab-Team-Q1-July-Sep-2016, 10Edit-Review-Improvements, 06Revision-Scoring-As-A-Service, 10rsaas-editquality: Research how to present ORES scores to users in a way that is understandable and meets their reviewing goals - https://phabricator.wikimedia.org/T146333#2667479 (10jmatazzoni) Getting to Pau's... [15:32:56] 10Collaboration-Team-Sprint-E-Everywhere-2015-07-14, 06Collaboration-Team-Triage, 10Flow: Some Flow topics are not being created properly in core page and revision tables - https://phabricator.wikimedia.org/T105859#2667507 (10ArielGlenn) Reminder that this (maybe is responsible for mediawiki Flow dumps slown... [15:43:50] 03Collab-Team-Q1-July-Sep-2016, 10Edit-Review-Improvements, 06Revision-Scoring-As-A-Service, 10rsaas-editquality: Research how to present ORES scores to users in a way that is understandable and meets their reviewing goals - https://phabricator.wikimedia.org/T146333#2667536 (10jmatazzoni) > 3. Why do we th... [15:49:09] 03Collab-Team-Q1-July-Sep-2016, 10Edit-Review-Improvements, 06Revision-Scoring-As-A-Service, 10rsaas-editquality: Research how to present ORES scores to users in a way that is understandable and meets their reviewing goals - https://phabricator.wikimedia.org/T146333#2667550 (10jmatazzoni) > 2. Why do we av... [16:51:57] 03Collab-Team-Q1-July-Sep-2016, 10Edit-Review-Improvements-ReviewStream, 13Patch-For-Review: Add fields needed by ERI to mediawiki.revision-create - https://phabricator.wikimedia.org/T145164#2667872 (10SBisson) There's a discussion in [[ https://gerrit.wikimedia.org/r/#/c/312274/1//COMMIT_MSG@9 | gerrit ]] a... [16:54:42] 06Collaboration-Team-Triage (Collab-Team-Q2-Oct-Dec-2016), 10Edit-Review-Improvements-RC-Page, 10Collaboration-Community-Engagement, 06Community-Liaisons (Oct-Dec-2016): Create a dedicated pages for ERI Recent Changes Beta project - https://phabricator.wikimedia.org/T146669#2667891 (10Trizek-WMF) [16:54:58] 06Collaboration-Team-Triage (Collab-Team-Q2-Oct-Dec-2016), 10Edit-Review-Improvements-RC-Page, 10Collaboration-Community-Engagement, 06Community-Liaisons (Oct-Dec-2016): Create a dedicated pages for ERI Recent Changes Beta project - https://phabricator.wikimedia.org/T146669#2667904 (10Trizek-WMF) 05Open>... [17:01:54] (03CR) 10Mattflaschen: "I tested re-opt-in a few times with different scenarios (including one trying to be as close as I could to the browser tests, but wasn't a" [extensions/Flow] - 10https://gerrit.wikimedia.org/r/307951 (https://phabricator.wikimedia.org/T120009) (owner: 10Sbisson) [17:14:04] 03Collab-Team-Q1-July-Sep-2016, 10Edit-Review-Improvements, 10QuickSurveys, 06Reading-Web-Backlog: Retool quicksurveys so we can do a survey on one page only - https://phabricator.wikimedia.org/T146495#2668009 (10phuedx) [17:14:16] (03PS20) 10Mooeypoo: Add proper QUnit tests [extensions/Echo] - 10https://gerrit.wikimedia.org/r/311063 [17:21:34] 03Collab-Team-Q1-July-Sep-2016, 10Edit-Review-Improvements, 10QuickSurveys, 06Reading-Web-Backlog: Retool quicksurveys so we can do a survey on one page only - https://phabricator.wikimedia.org/T146495#2668036 (10Jdlrobson) take a look at : * https://en.m.wikipedia.beta.wmflabs.org/wiki/Headings?quicksur... [17:24:07] 03Collab-Team-Q1-July-Sep-2016, 10Edit-Review-Improvements, 10QuickSurveys, 06Reading-Web-Backlog: Retool quicksurveys so we can do a survey on one page only - https://phabricator.wikimedia.org/T146495#2668069 (10Jdlrobson) I should also clarify currently quick surveys do not show if one of the following... [18:18:35] 03Collab-Team-Q1-July-Sep-2016, 10Edit-Review-Improvements, 10QuickSurveys, 06Reading-Web-Backlog: Retool quicksurveys so we can do a survey on one page only - https://phabricator.wikimedia.org/T146495#2668222 (10Pginer-WMF) Desktop: {F4526962} Mobile: {F4526966} [18:27:28] 06Collaboration-Team-Triage, 10Thanks, 13Patch-For-Review: Specify which edit was thanked in Special:Log/thanks, both for private and public records' sake - https://phabricator.wikimedia.org/T51087#2668264 (10Aklapper) As there is a patch available, should this task be reopened? [18:37:08] 03Collab-Team-Q1-July-Sep-2016, 10Flow, 07Regression: Flow as a Beta feature: enable, disable and reenable doesn't seem to work - https://phabricator.wikimedia.org/T138310#2668321 (10Etonkovidova) Betalabs displays the following error page when re-enabling Flow (first there was Flow user talk page, then opt-... [18:50:51] 06Collaboration-Team-Triage, 10Flow: Impossible to access to a Flow talk page after enabling/disabeling Flow - https://phabricator.wikimedia.org/T146617#2666292 (10Etonkovidova) @Trizek-WMF the priority of this issue was elevated. I've added the same error message (from cawiki) and the error backtrace (from be... [18:53:28] stephanebisson: just in unlikely case that you missed it :) - @Trizek filed https://phabricator.wikimedia.org/T146617 the same as T138310 [18:53:28] T138310: Flow as a Beta feature: enable, disable and reenable doesn't seem to work - https://phabricator.wikimedia.org/T138310 [18:53:48] etonkovidova: yes, I saw it [18:54:25] etonkovidova: I'm looking at it right now. I was able to reproduce it locally with 1 user. [18:55:06] stephanebisson: I was sure that you've already seen it :) It's great that it's reproducible locally [19:41:53] 06Collaboration-Team-Triage, 10Flow, 13Patch-For-Review, 05WMF-deploy-2016-09-13_(1.28.0-wmf.19): Type of flow_ext_ref.ref_target incorrect on some tables on Beta Cluster - https://phabricator.wikimedia.org/T110446#2668487 (10Catrope) No, this is still not fixed. Rerunning Matt's command still gives the sa... [20:26:48] 06Collaboration-Team-Triage, 10Thanks, 13Patch-For-Review: Specify which edit was thanked in Special:Log/thanks, both for private and public records' sake, if configured to do so - https://phabricator.wikimedia.org/T51087#2668633 (10Mattflaschen-WMF) 05declined>03Open [21:11:42] 03Collab-Team-Q1-July-Sep-2016, 10Flow: Add debug/warn for cache reads from in-process Memcached cache wrapper - https://phabricator.wikimedia.org/T120007#2668866 (10Catrope) @Mattflaschen-WMF @SBisson Do we still need to do this, with Stephane's current Flow caching patch? [21:16:50] 03Collab-Team-Q1-July-Sep-2016, 06Analytics-Kanban, 10MediaWiki-extensions-WikimediaEvents: EL alarms raw/validated 20160926 - https://phabricator.wikimedia.org/T146674#2668873 (10Mooeypoo) a:03Mooeypoo Okay, I was under the impression that since I tagged the namespace value as 'optional', the logger will... [21:20:04] 03Collab-Team-Q1-July-Sep-2016, 10Flow, 07Easy: Special:EnableFlow should log usage to Special:Log/contentmodel - https://phabricator.wikimedia.org/T105655#1448544 (10Catrope) It's not technically a content model change, because EnableFlow moves the old page and then creates a new Flow page with the same name. [21:30:24] crap crap crap I accidentally clicked Ctrl-Z while in nano editing my commit message.. iirc this moves it to the "background" process in ubuntu. ANYONE knows how to call it back to the forefront? I forgot [21:30:51] ctrl z is sleep signal i think.. suspend. How do I unsuspend [21:32:22] fg [21:32:23] of course [21:34:16] 03Collab-Team-Q1-July-Sep-2016, 10Notifications, 07Documentation: Document technical aspects of cross-wiki notifications (for non MediaWiki-Vagrant users) - https://phabricator.wikimedia.org/T125728#2668948 (10Quiddity) [21:34:18] 03Collab-Team-Q1-July-Sep-2016, 10Collaboration-Team-Archive-2015-2016, 10Notifications, 07Documentation: Document new Echo formatting system - https://phabricator.wikimedia.org/T116612#2668947 (10Quiddity) [21:34:32] mooeypoo: Yes, fg, stands for foreground [21:34:48] yeah i remembered something like that from OS class, of all places [21:35:55] RoanKattouw, I also remember that when I first saw that, I thought "oh, fg like 'fudge! I screwed up!' because 99% of times you do ctrl-Z in linux, you didn't mean to do what it actually did... [21:36:39] (03PS1) 10Mooeypoo: (re)Add JavaScript hooks to Notifications [extensions/Echo] - 10https://gerrit.wikimedia.org/r/312940 (https://phabricator.wikimedia.org/T146296) [21:37:06] 03Collab-Team-Q1-July-Sep-2016, 10Notifications, 13Patch-For-Review: Add hooks (back) to Echo - https://phabricator.wikimedia.org/T146296#2668953 (10Mooeypoo) a:03Mooeypoo [21:38:07] 03Collab-Team-Q1-July-Sep-2016, 10Flow: Add debug/warn for cache reads from in-process Memcached cache wrapper - https://phabricator.wikimedia.org/T120007#2668956 (10Mattflaschen-WMF) The issue this is trying to prevent (reading from the cache on POST) is still a possible problem. It would either return null/... [21:40:36] (03CR) 10jenkins-bot: [V: 04-1] (re)Add JavaScript hooks to Notifications [extensions/Echo] - 10https://gerrit.wikimedia.org/r/312940 (https://phabricator.wikimedia.org/T146296) (owner: 10Mooeypoo) [21:40:52] 03Collab-Team-Q1-July-Sep-2016, 10Notifications, 13Patch-For-Review: Add hooks (back) to Echo - https://phabricator.wikimedia.org/T146296#2668982 (10Mooeypoo) Once this is reviewed/merged, we can fix up navigation-popups code, which listens to a nonexisting hook (https://en.wikipedia.org/wiki/MediaWiki:Gadge... [21:41:31] matt_flaschen, https://phabricator.wikimedia.org/T146296 [21:45:13] mooeypoo, yeah, if I understand the example, $elements is always the same DOM structure, which is useful ($wrapper will be different, but that's fine). [21:46:32] matt_flaschen, $elements can change from firing to firing, but they only include the *actual* elements that are about to be rendered. They may include SingleNotificationItemWidget or CrossWikiNotificationItemWidget or bundle etc - but it will save the hook-user time (and risk of looking for the wrong class) of doing $wrapper.find( '.notifClass' ) [21:47:01] 03Collab-Team-Q1-July-Sep-2016, 10Flow, 07Easy: Special:EnableFlow should log usage to Special:Log/contentmodel - https://phabricator.wikimedia.org/T105655#1448544 (10Mattflaschen-WMF) >>! In T105655#2668901, @Catrope wrote: > It's not technically a content model change, because EnableFlow moves the old page... [21:47:40] so either the user of the hook can use the $wrapper to do whatever (like listening to click events live or whatever) or go over the $elements group... I figured this would be safest for the future so we don't have to run around fixing classes or css-selectors in gadgets [21:48:34] mooeypoo, hmm, I guess passing them the exact notifications would still result in a different DOM structure, because even individual notifications have different DOMs (e.g. secondary links have a separate DOM). [21:48:44] yeah exactly [21:48:48] mooeypoo, what's the advantage of using a single hook, even though the DOM structure passed is different? [21:48:53] Bundle is different than Single notif [21:50:25] matt_flaschen, this way, navpopups, for instance, just lisetns to this hook and handles whatever widgets are going to appear -- not caring *where* this happened. So for example, the popup opens -> navpopup will get all links from each notif in the popup, but it won't yet have the "sub" notifs in the cross-wiki bundle, because they're async. But they also emit the same hook when we expand that bundle and get those notif widgets, so th [21:50:25] gadget doesn't "care" - it'll re-intercept with the new elements. [21:50:57] matt_flaschen, or another example - you go to the inbox page, no matter what filter or pagination button or sidebar thing you click on - the event should fire each time notif widgets are going to be displayed [21:51:14] so the gadgets listens to one event but is sure to always grab notif widgets that are rendered. [21:51:54] matt_flaschen, if there's specific need for hooks for a specific page/operation we can add those, but I didn't really see anyone intending to use those right now, except for knowing when the popup initialized (and I added an event for that) [21:53:21] mooeypoo, I was just wondering if it's going to be a pain to have x? different DOM structures using the same hook. I agree with "you go to the inbox page, no matter what filter or pagination button or sidebar thing you click on" (I think these are the same DOM structure anway). [21:53:52] matt_flaschen, oops I forgot to add this to philip [21:54:17] mooeypoo, but maybe there are too many structures to make it worth it to add a hook for each one (unbundled, cross-wiki bundle, normal bundle itself, on-expand of the normal bundle, on-expand of cross-wiki bundle, special page). [21:54:23] matt_flaschen, they're similar dom structures, from what I could gather they should work similarly enough to whoever wants to grab them but that's also why the $wrapper is first [21:54:44] You're probably right about starting with this, and refning if actually needed. [21:54:45] we used to only give the wrapper... it's still useful, but I didn't want gadgets to start going $wrapper.find( '.mw-echo-ui-notificationItemWidget' ) [21:56:10] hm wait, this should already work with philip... what the hell [21:56:33] ok it works. [21:56:39] yeah, this works with any re-rendering. [21:56:49] matt_flaschen, also, that's why I wanted to name the hook very specifically [21:57:18] 10Collab-Notifications-Page, 06Collaboration-Team-Triage, 07Mobile: [mobile] Add cross-wiki notifications to Special:Notifications page - https://phabricator.wikimedia.org/T146409#2669000 (10Catrope) [21:57:20] 10Collab-Notifications-Page, 06Collaboration-Team-Triage: Cross-wiki notifications in no-JavaScript version of Special:Notifications - https://phabricator.wikimedia.org/T135877#2669003 (10Catrope) [21:57:25] 'ext.echo.notifications.beforeRender' rather than 'beforeShowPopup' or whatever we had before [21:58:32] I agree with naming it clearly, of course. [21:58:56] It's just a question of whether passing various different DOM structures depending on the context is okay. "Yes, until proven otherwise" seems reasonable. [22:00:54] 10Collab-Notifications-Page, 06Collaboration-Team-Triage, 07Regression: [Regression wmf.18] Special:Notifications horizontal scroll linewrap problem on desktop - https://phabricator.wikimedia.org/T146223#2669007 (10Catrope) 05Open>03Resolved a:03Catrope [22:03:56] 03Collab-Team-Q1-July-Sep-2016, 10Notifications, 13Patch-For-Review: Add hooks (back) to Echo - https://phabricator.wikimedia.org/T146296#2669012 (10Quiddity) [22:03:58] 06Collaboration-Team-Triage, 10Notifications: Make a way for editors to have notifications automatically marked as read, when a flyout is opened - https://phabricator.wikimedia.org/T146294#2669011 (10Quiddity) [22:05:56] 06Collaboration-Team-Triage, 10Notifications: [mobile-minor] Special:Notifications: Improve date format display - https://phabricator.wikimedia.org/T146288#2656218 (10jmatazzoni) ()The mark group as read icon is broken.) Anyway, we should look into shorter date format for mobile. [22:06:19] 06Collaboration-Team-Triage (Collab-Team-Q2-Oct-Dec-2016), 10Notifications: [mobile-minor] Special:Notifications: Improve date format display - https://phabricator.wikimedia.org/T146288#2669025 (10jmatazzoni) [22:09:45] 06Collaboration-Team-Triage (Collab-Team-Q2-Oct-Dec-2016), 10Notifications: double-check icon for "Mark group as read" button does not appear on mobile site - https://phabricator.wikimedia.org/T146706#2669030 (10Catrope) [22:17:26] 06Collaboration-Team-Triage, 10Notifications: Determine if multi-reverted edits still send notifications to all non-IP users who were reverted - https://phabricator.wikimedia.org/T146326#2657517 (10Catrope) @Etonkovidova , @Quiddity and I just tried reproducing this on beta labs, and we can confirm that a mult... [22:18:00] 06Collaboration-Team-Triage, 10Notifications: Determine if multi-reverted edits still send notifications to all non-IP users who were reverted - https://phabricator.wikimedia.org/T146326#2669058 (10Quiddity) Note, I asked there: > If the behaviour has changed, do you think it should be re-introduced (with the... [22:27:15] matt_flaschen, also, these hooks fix basics (like the fact we needed to re-add the ones we had before that are still relevant + supporting navpopups that use them) -- but it won't fix the parent task about marking popup content as read. In that case, we'll have to expose the controller, otherwise, if we have the gadget send an API request to mark all as read it will work but the badge+popup won't be updated to show the new state [22:27:42] so ... should I also send the controller instance as a parameter in the popup's initialize hook? [22:27:47] it sounds so... meh... [22:29:26] 06Collaboration-Team-Triage, 10Notifications: Determine if multi-reverted edits still send notifications to all non-IP users who were reverted - https://phabricator.wikimedia.org/T146326#2669088 (10Catrope) Looking at `EditPage::getContentObject()`, it looks like multi-edit reverts don't set `$this->undidRev`,... [22:29:36] matt_flaschen, it also means we're basically exposing the entire backbone of Echo... someone can use a gadget to call for marking specific notifs as read or deleting xwiki, etc. I mean... it's an interface we *could* expose, and I guess that's the meaning of allowing for gadgets, but it is pretty extreme and may allow for fairly destructive actions.... what should we do? [22:29:47] RoanKattouw, also, your opinion on this ^ [22:30:19] mooeypoo: It's already exposed via api.php if you know how to use it [22:30:40] Which, in fact, even has autogenerated docs [22:31:18] And I think that in order to allow meaningful gadgets to be written, you probably need to expose that interface anyway [22:31:25] In a nicer way then "figure out the api.php call" [22:31:27] RoanKattouw, no no [22:31:40] (because if you do that, the in-browser view won't update) [22:31:55] RoanKattouw, okay, a gadget can listen to the popup onInitialize hook and then send an API request to mark-all-as-read [22:31:56] that will work [22:31:57] BUT [22:32:06] that will *not* visibly mark the notifications as read [22:32:37] the only way for such a gadget to also mark notifs as read properly is through the model (bad idea) or the controller (somewhat better, since it will also do *everything it needs to do* when such action is taken) [22:32:43] Right [22:32:50] so if we want to allow a gadget to add functionality of marking-all-as-read or something, we need to expose the controller [22:32:54] So maybe we should expose the controller then [22:32:58] I could send the controller instance as part of the hook [22:33:08] we could absolutely do that, and the user will have access to all actions [22:33:18] but that's the point -- the gadget writers will have access to ALL actions [22:33:21] which can be a good thing [22:33:34] but it can also be pretty destructive ... [22:34:21] matt_flaschen, RoanKattouw, so if we want to expose the controller for this type of thing, I'd have a separate hook for that. Through the controller the gadget can listen to any event it wants anyways because the model manager is stored in the controller as it is [22:35:55] so for instance, have something like mw.hook( 'mw.echo.controllerReady' ).fire( controller ) when the controller is initialized. Gadgets can intercept that hook and do something like controller.getManager().on( 'update', function () { controller.markAllRead( 'local' ) } ) [22:36:10] OR we can have a hook for every occasion, which will probably be an overkill [22:36:59] or just fire that hook whenever the controller finished an API call or something, but that will likely be a lot of specific hooks [22:37:37] RoanKattouw, alternatively, we could add another interface on top of the controller just for what we deem as "safe" to do and expose **that** in the hook... [22:37:46] easier-to-manage wrapper interface. [22:45:51] mooeypoo, gadgets can do pretty much anything, including far more destructive (if done wrongly) actions like editing on your behalf. [22:46:14] matt_flaschen, good point [22:46:32] okay, I guess we can expose the controller. What do you think of my idea of a single hook that exposes the controller, and have the gadget decide what to do with it? [22:46:42] And as RoanKattouw points out, they can already do that. The only difference is whether it reflects immediately, which is a UX question, not a destructiveness question. [22:47:42] mooeypoo, to do things like "mark all alerts as read when the alerts popup is opened", they need to know when the popup is opened. [22:48:22] So either, the controller is passed there, or they need to listen to your suggested controllerReady hook. Not sure which is better. [22:48:37] With controllerReady, they would have to store it for later. [22:48:41] hm [22:48:43] indeed [22:48:50] But we still need a "hook for every occasion" (or rather than occasions that are useful, as needed). [22:48:51] but it sounds so random to send it on popup open [22:49:39] matt_flaschen, ok, I can add the controller to ext.echo.popup.onInitialize [22:50:07] I guess that makes sense for most things to do with the popup. If we get asked, we can have something like ext.echo.special.onInitialize too [22:50:09] mooeypoo, I actually wasn't taking a position on whether to pass the controller in the individual hooks. [22:50:28] Just making the point they need hooks like 'ext.echo.popup.onInitialize' to know *when* it happens, and they need to get the controller at some point. [22:50:37] matt_flaschen, no, but I am convinced either way. I'm trying to write the gadget taht should be written to mark-all-read and this seems to be the best direct approach [22:51:01] well [22:51:06] hm [22:51:29] matt_flaschen, well, if the gadget listens to the manager's "update" event, in the context of the popup that *is* when the popup is populated [22:51:47] in the context of the special page that's when the special page is populated... both of those have a different controller anyways [22:52:14] So I could also have mw.hook( 'ext.echo.controllerInitialized' ).fire( context, controller ) [22:52:21] where context is 'popup' / 'special' [22:52:21] ? [22:52:34] meh,though. [22:52:57] might as well expose it in the ext.echo.popup.onInitialize, and if anyone wants we can add ext.echo.special.onInitialize that fires the same details [22:53:37] mooeypoo, yeah, it sounds like the controllerInitialized would require them to understand more of Echo's control flow (which is probably also more subject to change). [22:53:45] yeah [22:54:02] mooeypoo, also, potential ordering issues, if the ext.echo.controllerInitialized hook is registered after the 'update' event. [22:54:31] Normally, mw.hook solves that through its memory feature, but if you have the use regular events later, you lose that. [22:54:41] 'hooks is registered' meaning 'hook listener is registered' [22:54:41] That should never happen, I was going to register it in the constructor of the controller, and the controller is always the one filling in the model [22:54:42] but yeah [22:54:54] oh good point about the *listener* [22:54:55] ha [22:54:58] Yeah, sorry. [22:55:05] good point [22:57:55] (03PS2) 10Mooeypoo: (re)Add JavaScript hooks to Notifications [extensions/Echo] - 10https://gerrit.wikimedia.org/r/312940 (https://phabricator.wikimedia.org/T146296) [22:57:57] matt_flaschen, ^ better? [22:57:59] I think? [22:59:06] matt_flaschen, I'm setting up a gadget locally to test this [22:59:42] matt_flaschen, another small caveat -- using the controller is definitely better, but honestly, using the 'mark all read' **button** should be preferable, because that also does the whole 'pending' animation and handles errors [22:59:49] which the direct call doesn't do [22:59:57] so now I'm wondering if I can just find the button and click it [23:02:37] (03CR) 10jenkins-bot: [V: 04-1] (re)Add JavaScript hooks to Notifications [extensions/Echo] - 10https://gerrit.wikimedia.org/r/312940 (https://phabricator.wikimedia.org/T146296) (owner: 10Mooeypoo) [23:12:04] (03PS3) 10Mooeypoo: (re)Add JavaScript hooks to Notifications [extensions/Echo] - 10https://gerrit.wikimedia.org/r/312940 (https://phabricator.wikimedia.org/T146296) [23:12:20] boom [23:12:24] matt_flaschen, I have a gadget [23:13:17] (03CR) 10Mattflaschen: (re)Add JavaScript hooks to Notifications (031 comment) [extensions/Echo] - 10https://gerrit.wikimedia.org/r/312940 (https://phabricator.wikimedia.org/T146296) (owner: 10Mooeypoo) [23:14:10] Sounds good so far. I would recommend you use alerts/notices/all. [23:15:49] matt_flaschen, meh, that would be such a pain, though, since in code it uses message :\ [23:16:20] I guess I can switch it up, I'm just worried that then any check you do (especially on the controller) you get the wrong terminology [23:16:56] mooeypoo, I know, but otherwise you're forcing a breaking change later. You have a point that it's still a pain when doing follow-up calls though. [23:16:57] matt_flaschen, this won't work right now but just to show the gadget for the parent task -- https://www.mediawiki.org/wiki/User:MSchottlender-WMF/GadgetEchoMarkAllRead.js [23:17:02] this works for me locally [23:17:12] I guess I can see the argument to just do the breaking change later. [23:17:22] hm yeah I'm worried about inconsistencies [23:17:26] maybe we should. I dunno. [23:18:04] mooeypoo, no I think you're right. [23:18:26] (03CR) 10Mattflaschen: "Actually, never mind. Mooeypoo points out this will be annoying for follow-up calls." [extensions/Echo] - 10https://gerrit.wikimedia.org/r/312940 (https://phabricator.wikimedia.org/T146296) (owner: 10Mooeypoo) [23:18:45] oh ha I was about to comment too [23:18:52] anyways, yeah. The gadget is less of a mess than I thought, actually [23:21:26] (03CR) 10Mooeypoo: "Yeah, the code itself still has 'message' rather than 'notice' - so in the cases especially where we expose the controller, it will expect" [extensions/Echo] - 10https://gerrit.wikimedia.org/r/312940 (https://phabricator.wikimedia.org/T146296) (owner: 10Mooeypoo) [23:25:23] 03Collab-Team-Q1-July-Sep-2016, 10Edit-Review-Improvements, 06Revision-Scoring-As-A-Service, 10rsaas-editquality: Research how to present ORES scores to users in a way that is understandable and meets their reviewing goals - https://phabricator.wikimedia.org/T146333#2669333 (10jmatazzoni) In today's Collab... [23:32:12] 03Collab-Team-Q1-July-Sep-2016, 10Notifications, 13Patch-For-Review: Add hooks (back) to Echo - https://phabricator.wikimedia.org/T146296#2669350 (10Mooeypoo) Just to make @Quiddity happy, after the code is reviewed/merged, we can fix navpopups (above comment) **and** we can easily add a gadget to "mark all... [23:32:22] quiddity, success! [23:32:34] <3 [23:32:43] <333 [23:33:28] also, now I need to *delete* my own gadget from my local wiki so it *stops* marking all alerts as read on open [23:33:32] :P [23:34:24] hehe [23:35:53] quiddity, I'm tempted to add console.log( 'Marked all alerts as read.' ) to the gadget if people start using it a lot... I'm anticipating potential issues that arise where we will *need* to know that this is running... should we trust users to remember they have it on ..? [23:36:29] mooeypoo, no, we definitely can't trust users, but we can check in the DB. :) Console thing is probably a good idea too. [23:36:36] that sounds like a reasonable/useful thing to add. [23:36:41] * mooeypoo nods [23:36:42] mooeypoo, similarly, you don't need to delete it from your local wiki, you can just make it a non-default gadget. [23:36:53] I'll add it to my experimental thing in case someone copies it over [23:37:16] matt_flaschen, that would've worked had I made it an actual gadget... I was lazy so I tested it in my user/common.js ... [23:37:20] * mooeypoo whistles [23:38:40] etonkovidova, did you see that Beta Cluster logs are now at deployment-fluorine02 ? [23:41:18] matt_flaschen: thx! I did not know that [23:42:18] 03Collab-Team-Q1-July-Sep-2016, 10Edit-Review-Improvements, 06Revision-Scoring-As-A-Service, 10rsaas-editquality: Research how to present ORES scores to users in a way that is understandable and meets their reviewing goals - https://phabricator.wikimedia.org/T146333#2669384 (10jmatazzoni) **SUGGESTION #2**... [23:42:40] Welcome [23:45:41] matt_flaschen: hmm... was /srv/mw-log/exception.log also moved ? I see only srv/mw-log/archive [23:53:04] matt_flaschen: and one more question: The error page with e.g. #0 /srv/mediawiki/php-master/extensions/Flow/includes/WorkflowLoaderFactory.php(101): Flow\WorkflowLoaderFactory->loadWorkflowById(Title, Flow\Model\UUID) [23:53:17] etonkovidova, apparently, it's broken. I just saw from a Phabricator email it was moved, but you're right. FIled as T146723 . [23:53:31] matt_flaschen: ah ok :) [23:53:48] T146723: deployment-fluorine02 does not have logs - https://phabricator.wikimedia.org/T146723 [23:53:55] etonkovidova, which task are you referring to about the error page? [23:54:21] matt_flaschen: Task was filed independently. My question is: such error will be somewhere else ? [23:54:27] matt_flaschen: in some logs? [23:55:01] etonkovidova, it should be in exception.log I think. [23:55:05] If that existed. [23:55:56] matt_flaschen: I thought so too. Yes, of course if exception.log existed :) Thx!