If all server-side cross-wiki requests fail, we'd return an empty API response.
This is invalid, the frontend expects things like list:[] to still be there.
Change-Id: I72fc5a017647ca28abbc061992fa4868ca5737f4
We were using the local user ID instead, which is not the
same on every wiki, which caused strange cache staleness
and pollution behavior.
Run sets through a wrapper function (gets were already wrapped)
so we can update the instance cache and deal with uncomputable
cache keys in one place. A global cache key may be uncomputable
if we fail to obtain the user's global user ID (users aren't
supposed to be unattached, but some are).
Also bump the cache version to get rid of polluted cache entries.
Bumping this version number was probably a good idea anyway,
with all the recent changes.
Bug: T134533
Change-Id: I1c4f0c2f2eded480c80f8ec7a49a04feb7c5ecfb
If we don't initialize $results, getForeignNotifications() will return
null, and this will cause a fatal when trying to += it into an array.
Change-Id: Ibb868cbf0b52ff2de41c5be82c9605801e51ffae
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
Notifications were being marked as read in response to a click event
in JavaScript, but that causes a jarring effect in the UI, and it's
not reliable (the browser could abort the AJAX request).
Instead, add ?markasread=XYZ to the end of every primary link URL,
where XYZ is the event ID.
Bug: T133975
Depends-On: Icb99d5479836fea25a47451b5a758dd71f642f71
Change-Id: I8047d121584b43e6172463a50ad0e0de5f7fa73c
Previously, getNotificationCount() only looked at local notifications,
and foreign notifications were added in separately by getMessageCount()
and getAlertCount(). This didn't make any sense and resulted in
counter-intuitive things like I4d49b543.
Instead, add a $global flag to getNotificationCount(). If $global=false,
the local count is returned as before, but if $global=true, the
global count (=local+foreign) is returned. If $global is omitted,
the user's cross-wiki notification preference determines which is returned.
Update getLastUnreadNotificationCount() in the same way, since it had
the same issues.
Also add caching for global counts and timestamps, using a global
memc key.
Bug: T133623
Change-Id: If78bfc710acd91a075771b565cc99f4c302a104d
Replace getAlertEvents and getMessageEvents with
getEventsForSection.
Also, add IDs for linking to sections
Bug: T123018
Change-Id: Ic480320a52a401609d853fc8c75c781b89bb8722
Instead of checking the cross-wiki notifications preference
in the constructor, move it to a method that other code can reuse.
Also add a parameter allowing foreign notification data to be
inspected even if the user has disabled the preference.
Change-Id: I6600ff27aa5af1737b3a6c3cde586d325886bc86
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
It doesn't use $this, except to call getWikiTitle(), so make that
static too. This allows us to use it in EchoForeignPresentationModel
without creating a second instance there.
Change-Id: If778db0852de1cbf5c2190ce50ce561745bb3887
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
Merge and deploy at the *same time* as:
* BounceHandler - I3c669945080d8e1f67880bd8a31af7f88a70904d
* mediawiki-config - I13817c139967ed9e230cfb0c87c5de66da793c96
Despite claiming to be about categories, $wgEchoDefaultNotificationTypes
was actually configuring both categories and types (which go inside
categories).
For example, 'thank-you-edit' is a type, but 'emailuser' is both
a category and a type (when used as a category, this has special
effects at Special:Preferences).
Since types and categories can and sometimes do have the same names,
this leaves no way to properly and clearly configure them. It also
makes it difficult to document what is going on (as required by
T132127).
Split into three variables:
$wgDefaultNotifyTypeAvailability - Applies unless overriden
$wgNotifyTypeAvailabilityByCategory - By category; this can be and is
displayed at Special:Preferences
$wgNotifyTypeAvailabilityByNotificationType - By type; this cannot
be displayed at Special:Preferences. To avoid confusing the user,
we introduce a restriction (which was previously followed in practice,
AFAICT) that types can only be overridden if the category is not
displayed in preferences.
Otherwise, it can look to the user like a category is on/off, but the
types within might have the opposite state.
Due to this configuration change, this is a breaking change, and needs
coordinated deployments.
This also lays the groundwork for T132127
Also change terminology to consistently use "notify type" for web/email.
It was mixing between that and output format (which unfortunately
sounds like the API format, e.g. 'model').
Bug: T132820
Bug: T132127
Change-Id: I09f39f5fc5f13f3253af9f7819bca81f1601da93
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
This would soon become problematic when output can come from
multiple sources, with potentially conflicting ids.
The ID is already included in the result anyway.
Change-Id: Id92150c71c68958819fe0ee329e70393052c34c9
They were using different code and different approaches.
I've left getSection() and the code for creating a Title
with a section duplicated for now, and I'll move them
into a trait in the next commit. I wanted to do that
separately because we aren't using traits in this
code base yet.
Change-Id: I56cf745d2cc8a6c43caec08024187de9598cecb8
It's (mostly) unused, and it would become problematic once we have
notifications from multiple places (where those ids could conflict)
Change-Id: Ib3bb5ae1e5689037b38290c9ce3d8691f52582b0
We ended up double-parsing section titles, which resulted
in strange behavior when the section title was something like
{{tl|infobox}}.
Bug: T132872
Change-Id: I4434624f392cd0e1df39374d45d60f7d83be7161
This caused notifications on mobile to show notifications for
both alert|message, as the type was always "all".
Bug: T130801
Change-Id: Ice245eb407ca360d8e882c0ba48cb7b3e0ecb851
formatSummary() was first parsing the summary using the
summary parser, then handing off the resulting HTML to
getTextSnippet() which parsed it again with the normal parser.
Bug: T131087
Change-Id: I2724ccb7c23579b3f02dea57d4fc833079169adf
There is currently a hard cap of badge display count.
We'll want to be able to request a different count for other purposes:
cleaning up old notifications, for example. We want to keep around a
certain amount of motifications (which is higher than the display count)
so we must be able to query a different count.
Change-Id: Id460fd7f46e397d22da49283b30fd12a6bbb0c9f
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 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
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
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
We calculate how many messages and alerts are being marked as read, and
subtract them from the count since the database and caches won't be
updated until the end of the request.
For performance, we also get the event_type while doing the
EchoTargetPage lookup query to avoid having to query it individually
later on.
Bug: T117531
Change-Id: I0d9302adf1b4b07a4ff26a04b00d4498aa3fe7ee
When $adjustLength is false, truncation will only happen
when the string is longer than the limit + the length of
the ellipsis to avoid the case where the ellipsis make
the string longer than the original.
Bug: T121822
Change-Id: I731a3c38b96ede6c6510f64771be0b9662dcba43
It's terrible that in groupbysection mode, you still have to pass
messageunreadfirst and alertunreadfirst separately, but at least
this way the unreadfirst feature is available at all in the
non-grouped mode.
Change-Id: Ifb0707be484bda8e33810c888bae1d008cac2d9f
API requests with notgroupbysection disabled but notsection set
to 'alert' would return foreign notification bundles for both
alerts and messages, separately.
The frontend always pasess notgroupbysection=1 in practice because
notmessageunreadfirst=1 doesn't work without it; but regardless of
that, the API module shouldn't return a foreign notification bundle
for messages when only alerts are requested.
Change-Id: I9fa6d1411a8c121591ce6dd75ee8052bcdcb478b
Using wiki names in the header is problematic because the messages
we were using weren't designed to be used in a sentence, only in headings.
This removes the wiki names from the sentence in the header, and
instead puts a comma-separated list (with "and") of wikis in the body.
The messages keep $3 and $4 for backwards compatibility, so translations
of the form "from Commons and 2 other wikis" will keep working.
Bug: T121936
Change-Id: Ideeba794e260b3c388fa29226b53197c050162ef
It wasn't meant to be there, and flow-mention doesn't have it either.
We also don't have any other notification types with
three prioritized secondary links.
Bug: T125949
Change-Id: Icbffa185b1116b1a6beb9bb3585339fdf7e82cdd
The approach here is to use $msg->escaped() to
remove all markup and then replace new lines
with a single space.
Bug: T128062
Change-Id: I1d5a6e57fbae9b6a441671beff1c60720b9445d5
Some notifications return relative urls in their
primary or secondary links. This change makes those
urls absolute so they point to the right wiki
when viewed from another wiki (cross-wiki notifications).
Bug: T125738
Bug: T127697
Change-Id: Ib65337430eb2484f9491668a9998deef70589fb1
It used to be like this, but in order to get the messages badge to show
in the correct circumstances, I had to know if the user had ever had
foreign messages before & I also needed euw_messages_ts even if those
messages had already been read.
Now that we're unconditionally showing messages, we no longer need these
0-value rows.
Bug: T127731
Change-Id: I1fc13bf0e5133ae39224f66d1b5a59c769bfcee2
