Do this by default in EventPresentationModel so it automatically works
for all email subject messages.
Update messages to use this parameter. Also update email subject
messages that were trying to use parameters that didn't exist, and fix
message documentation that was completely wrong about what the
parameters were.
Also update translated messages to account for parameter shifts (in many
cases, these messages were using the wrong parameter or a nonexistent
one).
Bug: T219620
Change-Id: Ia420c4db13c95d91e1bfc4c7950942df5858379b
Format user-rights reason as plain text
in both web and email since links
in notification body are not supported.
Bug: T172636
Change-Id: Ief5ff0aff18aad070f4388e075b5aae072d8f101
Includes feature flag, presentation model.
Temporarly hooks to new user creation.
Bug: T165755
Bug: T165754
Change-Id: Ic0a2ca07b0cd1597e5534bb1f3b748beb215ddfc
There's a lot more that could be done to improve user "rights"
notifications (really user group notifications), but this will do for now.
Bug: T159301
Depends-On: I5d32445f8e5b41599889b8488a2431e7a908f858
Change-Id: I27d52bc5c39219c832bf63a491faa1e421b0c024
There are many API messages in Echo, so to make it easier
for translators, they are now in a separate group.
This is similar in Flow.
Must be merged along with the translatewiki change at
Iecedfe4cb9dc8e62a446a3e1c415a79e116ca27e
Change-Id: I1d3baea708107a7f15bf19671f7386eaf7e33a1b
See Iae0e2ce3. Since Echo master requires core master, this just depends
on the master patch instead of trying to maintain BC.
Depends-On: Iae0e2ce3bd42dd4776a9779664086119ac188412
Change-Id: Icc088b31bc99e03ac88dfb44329df55318bf99b5
Make sure we pass the current user to the message, since empty
{{GENDER:|}} doesn't seem to work in PHP.
- Add parameter to documentation
- Add {{GENDER}} syntax to en.json as example
- Add parameter to the message creation
Bug: T144538
Change-Id: Ifc5e3bbe8309cc9ce120b7d61cdc050d7055aacc
Mainly used for mobile actions, and should be appended to the
overlay - this widget assumes it should appear and then fade out
with some confirmation message.
Also moved 'doubleCheck' icon to the ooui definitions, including
an inverted icon that is necessary for this widget.
Bug: T141404
Change-Id: I67a44962eaee6b7bd8cac26dcb5277177fa5d224
Allow extensions to add dynamic actions that perform some
API request and display a confirmation message.
Bug: T132975
Change-Id: Ib16d57c3f1a11a9749564c6e2112bf1ca32c55e8
Adds common bundling including messages and icons.
Bundling relates to revision now.
Changed order how notifications are generated. Now errors will
show first, since they are generated last.
Bug: T140224
Change-Id: I1069aeb5523db8710da4e8e21065bf447d031e3c
Make it optional through the unpgrouppages parameter, so that
generic usage of the unreadnotificationpages API is still possible.
In the front-end, store which display title maps to what set of titles,
and pass in the full set rather than just the display title when
filtering by a page.
Bug: T137502
Change-Id: I443ca00ff5e5d36fd6910101226358942e6aa8ee
Adds new notification type and icon for successful mentions.
Complements existing test to consider successful mentions.
Bug: T139623
Change-Id: I7a77b40e8b14c95cadb9023065ee916247feacf9
- 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
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
Add a global-wiki 'mark all as read' to the Special:Notifications page.
The 'mark all as read' will makr all notifications in the given
wiki. The context of the wiki changes when filters are chosen,
and so the message of the button changes as well.
Bug: T115528
Change-Id: Ibd9dcdf7072d6cbc1a268c18e558e6d0df28f929
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
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
Add a sidebar with cross-wiki sources and pages of unread notifications.
The filter allows the user to fetch notifications from a foreign source
and specific pages if those exist.
Bug: T129366
Change-Id: I57d827a47f80274d75364c2099a9624049a26834
The zero results can either be because there are no notifications
at all for this user in the local wiki, or because there are no
results for the specific filter. Both messages are used for either
case.
Also, clean up the display of push/pop pending for the inbox widget
and hide the label in case the message count is 0 or 1 notifications
as it is unhelpful and irrelevant in these cases.
Bug: T136586
Bug: T136574
Bug: T129363
Change-Id: I1465f772bb9f5247df645d6612f951e5fd7d38cf
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
Allow marking notifications as read per 'section' (days) in the
Special:Notifications page.
Bug: T115528
Bug: T134204
Change-Id: I7324a2c693aa92b9327cf8ff98f125293d5fba10
Formatters based on presentation models for
individual event emails and digest (daily, weekly)
plain text emails.
Bug: T121067
Change-Id: I4eceaf521315adab7429a8a73ffca70ebcddab86
Passing a param 'wiki' with a list of wiki names will now
result in getting notifications from these wikis too.
It'll execute multi-curl calls to the given wikis to fetch
their results.
Bug: T130636
Change-Id: I89df54366501acfe3e5cf6d2f313ee32694ba387
Replace getAlertEvents and getMessageEvents with
getEventsForSection.
Also, add IDs for linking to sections
Bug: T123018
Change-Id: Ic480320a52a401609d853fc8c75c781b89bb8722
Removing the info popup because we don't have to show
a privacy notice when linking within the wiki.
This adds a database query to every page view for logged-in
users; If78bfc710, once merged, will fix that.
Bug: T117669
Change-Id: I8451db34ae8e94264e4921ecd6df6e4b32c7623a
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
I thought the name was confusing, and would be even more so
if we get real notifications from other sources.
Meanwhile also split $crossWikiSummary into 2 properties:
- 1 with the class
- 1 to indicate if it should be used
Change-Id: I0e83be7924c8c77680ea1ada3f2bd6a190ce6149
It's (mostly) unused, and it would become problematic once we have
notifications from multiple places (where those ids could conflict)
Change-Id: Ib3bb5ae1e5689037b38290c9ce3d8691f52582b0
There was no need to merge this, and I suggest it is reverted. Parameterless use of GENDER is supported
already.
"{{GENDER:|male|female|other}}" will switch for the
current user.
This reverts commit c8b80f2003.
Change-Id: I15a0bd79abea9d9f0e9b0547c87e848ebf88b5de
