User-options related classes are being moved to the MediaWiki\User\Options namespace in MediaWiki Core; reflect that change here.
Bug: T352284
Depends-On: I9822eb1553870b876d0b8a927e4e86c27d83bd52
Change-Id: Ic3e56c6e2ec606bbecbd630d8ad96d111cab24d3
When MWEchoNotifUser::getGlobalMemcKey does not find a global user,
MWEchoNotifUser::getCountsAndTimestamps can return null for 'global' key
Just fall back to the local count/timestamp
Bug: T317330
Change-Id: Ie11b0c93c0a45fb1f873bd26788beaa3d0c6a9d7
Moved the factory deeper into the code right before the one usage it
still needed a full user object
Narrow done method arguments from User to UserIdentity
and use the identity directly
Change-Id: Ic118f23ef504c7fda892480df61ea68c10915f78
The global function wfWikiID() is deprecated since 1.35 and it's usages
should be replaced with WikiMap::getCurrentWikiId().
Bug: T298059
Change-Id: Ia8cbc992eb80ee6d531cf11bdf2bc06181bce8b0
Replace User::getOption() with UserOptionsLookup::getOption() since this method will be hard-deprecated.
Bug: T296083
Change-Id: I0ecdc63b0344bc4c24196cc5edb3d02b6a7ed615
Adds AttributeManager to EchoServices so that dependencies of
AttributeManager can be injected.
Bug: T275148
Change-Id: I4fa5084d72914d16b6d218e7dd3521f5a1919b80
isRegistered is part of the slick UserIdentity interface, i.e.
it's the more "canonical" form. This change makes it a bit
easier to move away from using the huge (4000+ LOC) User class
everywhere, in favor of the UserIdentity interface, where
possible.
This patch is meant as a small step towards this goal. I tried
to replace some usages of User type hints already, but prefer
to go in small, incremental steps.
Change-Id: I039c7a18672dfb6ea9507752bce9ea754babd690
As noted in Ic22075bb5e, UserNotificationGatewayTest relies on the presence of
globals. When Ic22075bb5e is merged, UserNotificationGatewayTest will fail in
CI. This patch injects the configuration object into UserNotificationGateway.
Change-Id: I9c15a588a76a41a3ebfb59dac7f0761f756008ff
$wgEchoSectionTransition was introduced when we moved some notification
types between sections (alert, message).
$wgEchoBundleTransition was introduced when we made bundles dynamic
and expandable.
Both flags have been OFF for years and are not needed anymore.
This patch removes all traces of them.
Bug: T140710
Change-Id: I16a5d54b09e71997f80208db6f4fbdb040d03ab1
This code improvements seeks to improve on code readability, consistency,
maintainability and efficiency.
Change-Id: I4f07886044e9a75824f9e7ddad039f3112b1c4a1
Add a markasreadwiki parameter, and use cross-wiki API proxying to mark
the specified notification(s) as read on the originating wiki.
This allows notifications to be marked as read when the primary link is
followed, even if the primary link points to a different wiki.
Bug: T179765
Change-Id: Id7e1e11997173e1578e33cd189dc0f93a5e4ba63
There are about 200 of such generic "array" type hints in this code base,
the majority in @param tags. I started with what I found most relevant:
@var and @return tags. I might continue working on this later, but
wanted to stop for now to keep this patch moderately small.
Change-Id: Iff0d9590a794ae0f885466ef6bb336b0b42a6cd3
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
