It's probably not realistically possible for a revision to be oversighted
by the time generateMentionEvents() runs, but for consistency
we should be using RAW here.
Change-Id: If73b4abe5fbae5cadb75c5e09137299873f2a764
Right now we don't actually know how many times
each of these cases happen so add some basic tracking
so we can make some informed decisions.
Bug: T135719
Change-Id: Id4d519aefe96ecca2e3c51dd1c8128de70d0caac
Also, get rid of the feature where we hide the project name when there
is only one project available. The titles are always showing.
Bug: T127419
Change-Id: I1b1285d84b7fb4775d13067e6ae1c50602ed3baf
This was causing warnings in production:
Invalid parameter for message "notification-body-edit-user-talk-with-section": a:1:{s:9:"plaintext";N;}
Change-Id: Ibdea5d899caf446a8c7f811416fdabaa3dccccdd
Check for proper unserialization in EchoEvent::loadFromRow(), and return
false if not possible. Callers were updated to check for a false return.
Bug: T73489
Change-Id: I33867aa9bbbc5f0ecfe0d2a9e1b03eb1a937ae83
CA tokens are single-use, and the fact that they even worked
for multiple requests was a race condition. Instead of getting
one CA token and using it for all requests, get a fresh token
for each request.
Bug: T135250
Change-Id: Ie1bbdefd3e265d009d0c42ff27da447b8da7f1fd
This is needed because global tables and cache keys will attempt to be used
even for users who don't have the preference enabled.
Bug: T135266
Change-Id: I6208a12d46c8cd0275a232663cd50ac2bd2fed1c
Allow marking notifications as read per 'section' (days) in the
Special:Notifications page.
Bug: T115528
Bug: T134204
Change-Id: I7324a2c693aa92b9327cf8ff98f125293d5fba10
When updating notification counts, we already called User::invalidateCache(),
which bumps the local user's touched timestamp, which is taken into
account by OutputPage when computing the last-modified timestamp of the response.
However, this only works for one wiki, while the changed global count
needs to be displayed on every wiki. To accomplish this, track the
timestamp of the last update in NotifUser, and hook it into
OutputPageCheckLastModified.
Change-Id: I22c88a017f18a28179906049ee423c2d7e81c939
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
