This cache was only used so that, if we're told to clear the newtalk
flag and we already know there are no edit-user-talk notifications, we
won't try to delete them. But that's not a good justification for such a
confusingly-written cache that would have been hard to convert to
getWithSetCallback(), and I'm concerned that using cached data to make
this decision could lead to inconsistencies.
Also remove the notifCountHasReachedMax() check, which made no sense: if
the user has >99 notifications, that is no justification for not marking
their user talk notifications as read when they visit their user talk
page. Whether the displayed notification count will change has no
bearing on whether these notifications should be marked as read (and now
that bundled notifications are counted individually, the displayed count
actually could change).
Bug: T164860
Change-Id: I3ff5c9b31307839b9336bd8856015db9baa52fad
The $cached and $dbSource parameters are now unused, so remove them.
This affects get{Notification,Alert,Message}Count and
getLastUnread{Notification,Alert,Message}Time.
There are some callers in other extensions and in skins, but none of
them pass any parameters (except one, which I fixed in Ice42930280da).
Change-Id: If6f10c4f163ecb1def5a150656a60d1ab5f44d52
We used to have code that called getMemcKey() with a boolean parameter
deciding whether to get a local or global key, but we don't do that
anymore: every code path now knows whether it needs a local or global
key. Consequently, move the code for global cache key generation back to
getGlobalMemcKey(), rather than having both be in getMemcKey() and
getGlobalMemcKey() being a wrapper.
Change-Id: If35bafc53e1e0086c31fd9675a9dc057e36f5717
As Krinkle points out, it always writes to DB_MASTER, so it doesn't make
much sense to offer an option to read from DB_REPLICA. This also
resolves the race condition that I believe arises from the one caller
that passes in DB_REPLICA.
Change-Id: I6976e5479debc3f4a8f28d53b1616c01475772be
To use WANObjectCache correctly in a multi-DC-safe way, we need to use
getWithSetCallback() to read data, and call delete() when it changes.
NotifUser's caching of notification counts and timestamps relied
heavily on set() calls, and so wasn't multi-DC-safe.
Changes in this commit:
* Rather than caching counts/timestamps in separate cache keys, and
using separate cache keys for each section (alert/message/all), put
all this data in an array and store that in a single cache key.
This reduces the number of cache keys per user per wiki from 6 to 1.
* Similarly, use a single global cache key per user. The global check
key for the last updated timestamp is retained, so we now have
2 global cache keys per user (down from 7)
* Remove preloading using getMulti(), no longer needed
* Move computation of counts and timestamps into separate compute
functions (one for local, one for global), and wrap them with
a getter that uses getWithSetCallback().
* Use TS_MW strings instead of MWTimestamp objects internally, to
simplify comparisons and max() operations.
* Make existing getters wrap around this new getter. They now ignore
their $cached and $dbSource parameters, and we should deprecate/change
these function signatures.
* In resetNotificationCounts(), just delete the cache keys. In global
mode, also recompute the notification counts and put them in the
echo_unread_wikis table. We could also set() the data into the cache
at this point, but don't, because you're not supposed to mix set() and
getWithSetCallback() calls and I don't want to find out what happens
if you do.
Bug: T164860
Change-Id: I4f86aab11d50d20280a33e0504ba8ad0c6c01842
We almost always call it with DB_MASTER, and I'm pretty sure that the
one call that uses DB_REPLICA introduces a race condition. I didn't want
to change that quite yet, though, so I left it in for now.
Change-Id: Ia5a59fdda357b799e327b8ed224f3ccb09509a8a
The following sniffs are failing and were disabled:
* MediaWiki.Files.ClassMatchesFilename.NotMatch
* MediaWiki.Files.ClassMatchesFilename.WrongCase
* MediaWiki.Files.OneClassPerFile.MultipleFound
Change-Id: I7cbf305fae765dbf68df07f84992c2d5ed5486c6
Purge all cache when unread count changes and
repopulate on read.
Also fix client-side estimation when
marking a foreign notification as read.
Bug: T151389
Change-Id: I62def3d40a5640e26c234bb0335bc506dbf864a0
$wgEchoConfig is a deeply nested structure that ExtensionRegistry can't handle well.
It also combined different things, and the version number was used for two
separate purposes.
Split this out into $wgEchoCacheVersion, $wgEchoEventLoggingVersion
and $wgEchoEventLoggingSchemas.
Change-Id: I2f9d5d111f7925fb057d423a3e7064bff5040205
Show orange alert for all notification types in the edit-user-talk
category and provide a hook to enable other extensions to prevent
the orange alert from appearing.
Bug: T137954
Change-Id: I0b49c3a5eb0a027f8839ab86e77c527357907dd0
Has bugs, and will likely cause deployment problems.
This'll need to be reverted in wmf.19 at least
until we fix it up.
This reverts commit 00e0b9f45d.
Change-Id: Ia9d220ebcb607f96dee6bc856755305ed8501fcc
- Add a 'hasUnseen' data to the xwiki bundle so the badge can
consider its value when changing its color even without the
bundle being opened.
- Check and store seenTimes from all sources that the xwiki
has in a new JS object that the SeenTimeModel can store
Bug: T134855
Change-Id: Ifdcee88b4378cdc7acb4ae5c0cbc60b76339757e
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
Adds $wgEchoSectionTransition and $wgEchoBundleTransition.
If either of these settings is enabled, we will disbelieve
the alert/message counts in the euw table and obtain them
using server-side cross-wiki API queries instead.
This affects both ApiEchoNotifications (for generating the cross-wiki
summary entry) and the count and timestamp computation in NotifUser.
In bundle transition mode, we trust that notifications are classified
correctly between alerts and messages, but we don't trust the
counts in the table. In section transition mode, we trust that
the sum of the alert and message counts is the correct count,
but we don't trust the alert and message counts individually.
If both modes are enabled, we mistrust anything that's mistrusted
by either mode and only trust what's trusted by both modes.
In any event, we do trust that only the wikis with rows in the
euw table have unread notifications.
Bug: T132954
Change-Id: Ibcc8ac102dac3cf06916d67427b42457fdb93db6
Better idea: invalidate caches in this script, and write
a separate script to recompute existing euw rows.
This reverts commit c83af257d2.
Change-Id: I57bccfb726eada646cb318206d9091a20d59dcf5
This causes it to update the notification count cache as well.
Should we perhaps rename it to recacheNotificationCounts.php?
Bug: T132954
Change-Id: I540c4296f4fbadcf2267d77b53f71ee5c2eb8b52
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
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
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
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
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
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
Current situation: cross-wiki can be enabled on certain wikis &
disabled on others.
Code used to check if cross-wiki was enabled before fetching the
status of unread messages on foreign wikis. However, it would then
write that result to a shared memcached key.
The cross-wiki check should not happen before data is stored to
cache: what is stored should always be for all wikis. Only when
we fetch it, should we check if cross-wiki is enabled. And if it's
not, we can't use the cross-wiki data - we have to hack around it
ourselves...
Bug: T124372
Change-Id: I3d3d54fc3cbfbf73b51e97acfd8d355dd0cea36d
