Completely remove the EchoMail and EchoInteraction instruments,
supporting code, and config variables. Note well that the
EchoEventLoggingSchemas config included an entry for the
already-decommissioned Echo instrument so remove that too.
Bug: T344167
Change-Id: Ic0c44737d2c4a78ec19e67b8b8cd4e6cfb8e14fa
Pass a relevant number of unread notifications to the messages
'echo-mark-all-as-read' and 'echo-mark-wiki-as-read' each time
they are used, in order to facilitate the use of PLURAL in
the messages. This allows translators to say e.g. "mark both as
read" when there are two unread notifications, for instance.
Bug: T321462
Change-Id: Ida65be2d7f2663d9802f71c7ea1eb588db8cd254
This allows skins to make modifications to the final output.
This will be used in Vector to make the Echo icon consistent with
other icons.
Bug: T257143
Change-Id: I9fe8c921956ede164d93cb1f42647cf4b80ca976
* Rename to match their upstream names.
* For icons without upstream versions, fix canvas to 20x20.
* Use consistent suffices to indicator colour.
Change-Id: Ie6252a8ccbba79143a0f77536c6470b4350be1ad
hideWhenOutOfView is for preventing popups from appearing
outside their container, but in this case the container
is the document, so it is already clipped.
Bug: T178384
Change-Id: Ie0cd83849446cf74b61e708f0a1fa79f2384a94a
This will solve multiple issues with the design having to overcome
the theme-based design for the #p-tools.
Bug: T156080
Change-Id: Ibfcdfeea649e566059fd88485e146fbad2201016
The current initial message in the button label is "Alerts (x)" or
"Notices (x)" but when the badge loaded, we changed that to only show
the rendered number. This is inconsistent; the badge should always
update the label properly, even if it's not visible in most cases.
Bug: T173970
Change-Id: I6a5e13fc36ddb1bf467c712fcf49af3b18e582d0
Just show the textual "Alerts (1)" and "Notices (1)".
Updated NotificationBadgeWidget to use that internally as label,
same as the PHP-generated list item does after d4d325e7.
Bug: T141944
Change-Id: I468c67b0866530e21c9af32cd02816075a3693a1
Separate the behavior of promise vs event when changes happen and
we need to clip the popup. The popup should only clip itself after
the DOM has finished populating, not "just" after the model has
been populated with data.
Adding an event that triggers whenever the main list changes anything
that is in its DOM, and having the badge widget trigger a popup clip
will solve this issue and untangle the expectation of the promises
vs. the widgets populating themselves through the events.
Change-Id: Iff9996eb1810e7ade135359139e16837e6dc74f0
Added the following Javascript hooks:
* ext.echo.notifications.beforeRender: Firing before a group of
notification widgets are rendered, whether in the popup, in
the special page, or in a cross-wiki bundle (which requires
async loading)
* ext.echo.badge.countChange: Fired when the badge count changes
with the notification type, count and the label count for
display purposes.
* ext.echo.popup.onInitialize: Fired when the popup is opened and
after notifications were fetched, with the context of the popup
notification type.
* ext.echo.special.onInitialize: Fired when the special page is
ready and notifications were fetched. Note that it will be fired
whenever the special page is updated with notifications list,
as well, like when changing filter, remote wiki or pagination.
The hooks were also documented in hooks.txt
Bug: T146296
Change-Id: Ie3dc97f97e8d1f90b67f62fcdc65dd29cb379aad
This transforms seenTime concept to a global property for all wikis
and sources, and updates the global seen time on opening the popup.
Bug: T134855
Change-Id: I67bcc4b346237317c7a9204dd43cd0e9ee02792f
Has bugs, and will likely cause deployment problems.
This'll need to be reverted in wmf.19 at least
until we fix it up.
This reverts commit 00e0b9f45d.
Change-Id: Ia9d220ebcb607f96dee6bc856755305ed8501fcc
This follows the generalization we made in the back-end and allows
us to always use the same method to get capped notification count
in the display.
Bug: T144707
Change-Id: I4d7f406b05a195972dca0d2088bde2ff739d313d
- Add a 'hasUnseen' data to the xwiki bundle so the badge can
consider its value when changing its color even without the
bundle being opened.
- Check and store seenTimes from all sources that the xwiki
has in a new JS object that the SeenTimeModel can store
Bug: T134855
Change-Id: Ifdcee88b4378cdc7acb4ae5c0cbc60b76339757e
The actions logged:
* Popup: Mark all notifications in the popup as read
- Event ID is omitted
- Context 'flyout'
* Special page: Mark all notifications in current wiki
as read
- Event ID is omitted
- Context 'archive'
Bug: T127955
Change-Id: Id7c091f9e0cf0dd3745d33e335ab44706581d7f3
The fade in/out animation is asynchronous. This means that if we are
sorting multiple items one after the other, by the time the item faded
out, it will be reinserted back into the wrong position, breaking the
sorting.
This also broke the promise of OO.SortedEmitterList whereby all its items
are always in order.
The way to fix this was to force a better synchronization with the item
order while we hide and show the item in its new place. To do that,
a new widget is created as a fake clone of the old one, in the original
position of the old one. The original item is then reinserted (while hidden)
to the proper location -- preserving order. The fake clone is then faded
out, and the real item is then faded in.
For this to work properly, the cloned item had to preserve some of the
original item's information, like timestamp, foreigness and id. However,
since both the real item and the fake new clone have the same details,
the clone fakes its ID by adding a fraction to it - promising that the
fallback in case of equal timestamps (which happens on the real and
cloned items) will still resolve with some decision about the placement
of the items rather than (falsely but understandably) decide they are
both the same.
Since this whole animation is somewhat of a hack, the list now has a
configuration parameter to turn the animation on.
The animation is on in the popups, but off in the special page.
Bug: T141419
Change-Id: Ic7c35e5ddefc51bf7fde497eab36414b4dddcd9e
* Add ISO 8601 date format to notification output
This is actually supposed to be the only output date format used,
per https://www.mediawiki.org/wiki/API:Data_formats#Timestamps , but
I'm not doing anything to deprecate the others right now.
* Change wgEchoSeenTime to use ISO 8601. mwgrep and extension grep do
not show any usages. However, since it is a breaking change, to
minimize disruption, I'm also using this opportunity to change
'message' to 'notice'.
* Remove wgEchoInitialNotifCount. I was going to also change 'message'
to 'notice' here too, but then I saw it was totally unused.
(It was read in Echo to populate a JS variable, but then it was
unused.)
* Make sure the Special:Notifications page aggregation by days is
done by local days, even though the timestamp per item is still
UTC. This is to make sure the days are displayed correctly in
the local timezone.
* Change all reverse sorting callbacks to handle comparisons of
ISO 8601.
Bug: T141413
Change-Id: I20271345c7d350dc3e7f467288e5cdc98e6250cc
And change all CSS and JS dependent calls/tags based on the new
tooltip message and ID of the personal tool <li> item.
Change-Id: I136fabe5710f90da10eb8d4afe92acdb77571eec
This organizes the operation of seenTime so we can store and
follow up on it based on different sources, as well as update
it correctly remotely when needed.
Change-Id: I629ecfc84999be998b45c9c7adb00ea7e3e51742
The message for tooltip-pt-notifications-message was removed to comply
with the new naming. The problem is that in the back end, sections are
still defined as 'message' vs 'alerts' and the sections in the user
toolbar are defined with those terms. In no-JS mode (which is before
the user clicks any of the badges) this tooltip is created automatically
by MediaWiki based on class names.
It's easier to return the message key with different text for translation
and wait for the bigger tech debt to correct all instances of 'message'
to 'notice' (including in the API, which would require a much more
massive work)
Bug: T139520
Change-Id: I6368b63e38f64aa065f2580df812de1c63a93716
