This involves:
* Making this value no longer admin-configurable.
* Changing getNotificationCountForOutput to return only a single value
Since there is no + in the formatted value anymore, we can actually
use the same value for both.
This is a B/C break, but hopefully worth it to simplify the method
call.
For now, the excess parameter is just marked unused. It could be
removed at some point if the translations are updated.
This must be merged at the same time as:
* Flow - Ibfa56b1af9e8c56b4c5f900e0d487bc09688b2a2
* MobileFrontend - Ibf784b279d56773a227ff261b75f2b26125bbb63 (well, MF
can be merged first)
* translatewiki - I2a4b6938aed49e4101deb6b9351c43656a863490
Also, change 1 to One/one, per Siebrand on the task. This can easily
be dropped/undone if we don't want it.
Also, remove reference to no-longer-existent notification-page-linked-bundle
Bug: T127288
Change-Id: Iabeaae747f99980c0610d552f6b38f89d940b890
FloatableElement incorrectly believes it doesn't need to
position itself when its closest scrollable is the same as
the closest scrollable of the container. This causes
the dotdotdot menu to be placed at the top left of the screen
if the notifications popup is not scrollable. If it is scrollable,
everything works fine. This regression was introduced by I5b5d7936c4d.
Work around this by setting overflow-x: auto; on the popup body.
This is a no-op, but tricks OOUI into thinking that the popup
body is scrollable even when it visually isn't. We can't use
overflow-y for this, because we still need to set overflow-y: auto;
on the popup body to work around a Chrome bug where right-floated
elements don't move over when the scrollbar appears.
Bug: T130153
Change-Id: I8bd8a26a4931444a760d2159779240272c51f966
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
The previous implementation did the following weird things:
* Stripped tags before parsing
* Stripped templates before parsing using a hacky while loop
that bails after ten attempts
* Decoded entities using htmlspecialchars_decode(), while
html_entity_decode() makes more sense
* ...which meant it had to manually convert   back
to spaces, which is not necessary if you use html_entity_decode()
* Removed any single braces ('{' and '}') from the output
* Rejected the entire output if there were any entities left,
which is fairly likely since htmlspecialchars_decode()
only decodes a few of them
Instead of all this, just parse, strip tags, decode entities
(all of them, not just a few), trim and truncate. In particular,
don't strip templates, because we use getTextSnippet() in mention
notifications, which look weird when {{ping}} templates are stripped.
Bug: T129531
Change-Id: I956b2f6badc40d2f5bf90a0458ccab8b8fc6fefb
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
