- Adds global "$wgEchoMentionStatusNotifications"
to activate mention status notifications.
(must be set before extension is loaded)
- Adds notification types and icon for some basic mention
failures.
- Adds failure and stats for anonymous IP.
- Adds check for links to user subpages.
- Adds config var for max mention notifications allowed.
- Bundles notifications.
- Refactors test for the event generation and adds tests
for unknown users, user links with subpages and failures
for too many mentions.
Bug: T136326
Change-Id: I388bdc3714feb9a2865a5ad10dbeabb0a6a09a4f
Followup to I639b9d9906d3ff37021cb9b5ed3cb401354b5bd9
* Remove deprecated formatter
* Log a warning and fail gracefully
when an event type does not support
Echo presentation model.
Bug: T121612
Change-Id: Ic5712c4ce265b6faabce7a4028b4294fe3c73f18
To allow individual notifications to be
marked as read/unread or moderated,
bundles are created by grouping associated
notifications when they are fetched for display
instead of when they are created.
From a product perspective, this change doesn't
introduce moderation or expandable bundles but
it counts each individual notifications.
For instance, the bundled notification
"3 new topics on PageA" now counts as 3
notifications.
Bug: T93673
Bug: T120153
Change-Id: Iacd098573efd92bb1e3fcd7da4cd40cea9522f15
This script was supposed to be run in production in 2013, but that
never happened. It was also never added to update.php.
* Use makeTitleSafe instead of newFromText, for correctness
* Fetch the columns that the update generator needs
* Replace wrapper for private method with closure
* Make the maintenance script logged
Bug: T136427
Bug: T50059
Change-Id: I6c2972120189f035483b5ca49610c008c4ba2c88
The query shouldn't be too expensive: it'll use an index to narrow
down the resultset for 1 user. After that, it'll be sorted based on
a grouped by value, but that should fit in memory: it'll never be
on more than 2000 entries, which is the max amount of notifications
per user.
Change-Id: I271ea7f7a6e010284739bfce02c4ec8a077148fc
Formatters based on presentation models for
individual event emails and digest (daily, weekly)
plain text emails.
Bug: T121067
Change-Id: I4eceaf521315adab7429a8a73ffca70ebcddab86
This provides a simple unlisted special page,
Special:DisplayNotificationsConfiguration, to document how the
notifications are structured and configured. It shows:
* Which types are in each category
* Which notify types (web/email) can be enabled for each category
* Which notify types are mandatory for each category
* Which notify types are enabled by default:
** For existing users
** For new users
Bug: T132127
Change-Id: I25b447a69a7c984941dfd703345d7977c0000bfe
All extensions seem to have been updated to use the current formats,
so we can get rid of this tech debt.
Depends-On: I7503db28b0d81fb818b525ea9362e49b9b56342a
Change-Id: Idbcbbf95eab1172015bceea4e8124ba4c639efa8
Also removes tests for the class.
Bug: T119253
Change-Id: I4c0d7187c2b847297dd0867faecba26185cfba37
Depends-On: Iccafbbdb06711463fee0f30a11326c7771df30e2
I'm not really sure where to stick the primary link. I could wrap the
entire notification in a <a> tag, but all the text becomes ugly (I
suppose we could hack around it with CSS?). For now I just added it
before all the secondary links.
Change-Id: I4f6add9ecfb367660d1a6346825382ad415bdb77
This implements a backend layer and database storage for tracking what
wikis a user has unread notifications on. It is not yet exposed via any
API.
Whenever the notification counts on the local wiki are reset, a deferred
update is queued to also update the central database table.
Change-Id: Id1498bdeb5811d6848dc66781ffca03e726eab90
Instead of relying on the frontend to render, this enables the frontend
to do it.
The API will now accept a new format: 'model', which is basically the
presentation model's data in json format.
Some of the render code is currently only in the backend (e.g. get icon
path from icon type) so other api formats will stay available. At some
point, however, we may be able to kill those.
Bug: T115418
Change-Id: Ibc3ad54c94d6ea9bf751f3927cf69e1d062f4780
The workflow to format a notification is
* Get EchoEvent, User, and Language
* Get EchoEventFormatter implementation for notification type
** EchoEventFormatter returns structured data about each part of the
notification (header, body, primary link, secondary link(s))
* Each output type will have a formatter class (e.g.
EchoSpecialNotificationsFormatter, EchoPlainTextEmailFormatter) which
takes a EchoEventPresentationModel and generates whatever it wants
(HTML, plain-text email, etc).
Included is an example conversion of the user-rights and mention
formatters. The previous infrastructure will remain in place for
backwards compatability until other extensions can be updated.
Bug: T107823
Change-Id: I4397872a7ec062148dfcb066ddd8ab83f40486ac
So we're not abusing user preferences for the last seen time.
EchoSeenTime is a small wrapper around ObjectCache that handles the
fallback to user preferences during the transition.
All JavaScript code now needs to use mw.config.get('wgEchoSeenTime').
Bug: T95839
Change-Id: Ia45ba5e30eb4564250539d04d5886d2598ebd49a
I tried to stick as close to the existing code as possible.
Special:Notifications is slightly different from the overlay,
however. I made it add .mw-echo-unread class for consistency,
but that JS doesn't record seen time (it only loads older
entries), not does the CSS fadeout apply there (it marks
everything as read as soon as it's displayed, so different
behavior from overlay)
PS: I'm not sure about browser compat for the fadeout. But
even if some obscure browsers don't support this, meh. It's
not an "important" feature that can't be missed.
Bug: T94634
Change-Id: Ibb201823fb52ef8a3d5eaa39b0b724ede8d271d1
