Both in the order of the cross-wiki bundles themselves, and
in the message in the notification body.
ForeignNotifications tracks timestamps per wiki per section,
and exposes these through getWikiTimestamp(). ApiEchoNotifications
adds these timestamps to the sources manifest, and also sorts
the list of wikis by timestamp (it'd be nicer to do this in
ForeignPresentationModel instead, but then we'd have to create a new
ForeignNotifications instance which causes a duplicated DB query).
NotificationsModel receives the timestamp for its wiki as its
fallback timestamp, and makes getTimestamp() return this value
during the pre-population phase. This causes its parent to
automatically sort it correctly.
Because the timestamp of a wiki depends on the section (alerts vs messages),
we can't put it in the global sources manifest at the top level
of the API response. Instead, get rid of this global sources
manifest and put all the sources data in the foreign notifications
directly. This allows us to specify different timestamps, and also
allows us to get rid of code in EchoApi that was already remapping
the API response to this format.
Bug: T130298
Change-Id: Ie083fbb1ccaf74fbe804633d87ef03c9e71b120f
This is to wrap the mobile notifications in MobileFrontend with
a pendingElement and organize the API calls specifically for the
mixed popup in mobile.
Also added a specific 'ext.echo.ui.mobile' module so we don't
load unnecessary files for mobile.
Bug: T124188
Change-Id: I4a8be19a79b9e38c21907bb9d4123540a648c535
These strings must be passed exactly to the API untranslated for it
to work, so the developer-facing API documentation should reflect that.
Bug: T126908
Change-Id: Ie58611ac7dd510341867b6e86e3ffd71ad9aa1c6
Add a 'mark as unread' to all unread notifications and allow them
to be marked unread. These notifications will no longer be automatically
marked as read when the pages they refer to are visited.
Bug: T73564
Change-Id: I677d3c0399e46fd7c35531df1cc0e61db2d4eb1b
Don't try to render if page was deleted, and fix 'extra' parameter
(was breaking message key and thus rendering)
Bug: T129641
Change-Id: I5d0fdfd3921427993211969eb5793f8e9e7667a8
This reverts commit e372f3ce6f.
The previous attempt was broken because
EchoTargetPageMapper::fetchByUserPageId() returns a list of
EchoTargetPage objects, not a single one.
Bug: T117531
Change-Id: Id02a025e3736a7b92d9d6fb8adf29ef674f8e2fa
We have a wrapper around logInteraction() called logNotificationImpressions()
that logs impressions uniquely (i.e. logs each notification impression only once),
but in addition to calling that (from NotificationsWidget), we were also manually
calling logInteraction() to log impressions from NotificationBadgeWidget
and NotificationGroupItemWidget. This resulted in two impression events
for every notification, each with different data, one of which is logged
only once and one of which can be logged multiple times.
Remove the manual logImpression() calls and route everything through
logNotificationImpressions(), which is called from only one place:
NotificationsWidget. Add support for logging foreign wikis to
logNotificationImpressions(), as it was previously missing.
This causes us to lose the notification type information in these
events, but that can also be derived after the fact by looking
up the event_id in the echo_event table.
Whether impression logging is even useful is another question,
but it certainly isn't useful if we log duplicate impression
events with different data.
Change-Id: I19b76a4ce796b21e9347dd9392af24918db82e18
Title::newFromId() can return null, and if this were the case the
instance caching would never work, so it would continually make useless
database queries.
Initialize the $title member variable as false to begin with, and use
that to check whether we've already checked Title::newFromId().
Change-Id: Id07c2c963ffcd03e212bed0a666735bcb68b92e0
