This was soft-deprecated in 0171846c, since when all uses in Wikimedia
production code have been removed. As this is such a vital and widely-
used method, we'll want to deprecate it for at least two releases. and
so we should get this in at a time when we're willing to fix many such
uses. Why not now?
Bug: T270450
Change-Id: I8ac4a91d77c2bb748183b69b3e901cce93cbc940
Replacing the mock InterwikiLookup used in
MediaWikiTitleCodecTest revealed that that test was,
because of the mock not behaving correctly, testing the
wrong thing - interwiki prefixes are *not* case sensitive,
and are always converted to lowercase in the actual
ClassicInterwikiLookup. Fixed those expectations.
Change-Id: I242431e88860b7700a9f93f77a0fe195fd748800
Most needed for moving forward with the removal of uses
of the Revision class, and remove User::getNewtalk at
the same time to be consistent. All of this code was
already hard deprecated in 1.35.
- User::getNewtalk
- User::getNewMessageLinks (could return Revision objects)
- UserRetrieveNewTalks hook (could return Revision objects)
- User::getNewMessageRevisionId (used ::getNewMessageLinks)
- User::setNewtalk (accepted Revision object parameters)
Bug: T247143
Bug: T277511
Change-Id: Ib4fd1e4cbc5ba1497658190b6c6ea3c6a5dc97f0
All hard deprecated in 1.35
* BeforeHttpsRedirect
* CanIPUseHTTPS
* UserRequiresHTTPS
Also soft deprecate the wfCanIPUseHTTPS
method, which always returns true. Will
be hard deprecated once callers are updated
Change-Id: Ie6d71809d09edf6be9b8280debeb152ef7fce398
Ended up using
grep -Prl '\->setMethods\(' . | xargs sed -r -i 's/setMethods\(/onlyMethods\(/g'
special-casing setMethods( null ) -> onlyMethods( [] )
and then manual fix of failing test (from PS2 onwards).
Bug: T278010
Change-Id: I012dca7ae774bb430c1c44d50991ba0b633353f1
While creating users, we have several interesting corner cases:
- When creating a new User, we actually rely on the 'unique'
constraint on actor_name. This is important if something calls
'User::createNew' with a name that is already occupied by an
existing anon actor with no user. This is quite a weird corner case,
but there's a test for that. We could probably assimilate this
nicly in actor store by checking whether the user id in the database
for the actor we found is the same as user id in the passed in user identity.
- Even more interesting use-case is 'subsuming' existing actors with
reserved user names. When we call User::newSystemUser, and there is
already an actor with the same reserved name, we 'subsume' that actor
and take over it's actor_id for our new system user. This can now be
done with an upsert. This state of having reserved actor with no user
is not easy to cause, but imports or updating from old MW versions
seem to be able to produce this state. Archeology revealed that
'subsuming' existing actor was added for installer.
Change-Id: I16b2f088217db0283215fc2ef5fb04a3742e1626
Code that needs to store an actor ID in the database to
represent a UserIdentity, or needs to construct a UserIdentity based on
an actor ID loaded from the database, should use the ActorNormalization
service.
Note: The getActorId() method is removed from the UserIdentity interface,
but all concrete classes continue to support it for now.
UsererIdentityValue::getActorId() is hard deprecated and should
be removed in 1.37. It always returns 0.
User::getActorId() is not deprecated at this point.
Bug: T274179
Depends-On: Id2b3ddf6a2a7cdf90f8936a69148d2cce6fde237
Change-Id: I9925906d11e47efaec3c1f48d5cb3f9896a982c1
User::isValidUserName() is soft deprecated since 1.35 and unused. It should be replaced with the UserNameUtils service.
Bug: T274211
Change-Id: I7a9db0b083cbbb98de1d5728a2a8046b8106233e
User::getFirstEditTimestamp() and User::getLatestEditTimestamp() are soft deprecated and unused and thus should be hard deprecated.
Bug: T274211
Change-Id: Ib2da53256d7290f6d9a768c0c0708ab9e8e072ed
ActorNormalization should only be used in contexts where a DB connection
is already being used, or at least easily available.
Bug: T276986
Change-Id: Ie8aadaffa4a30e63fcad0502d45b8ec364fc79ef
Replace UserIdentity::getUserId with ::getId
Add $wikiId = self::LOCAL as an optinal parameter to User and
UserIdentity
Bug: T275482
Change-Id: I44494845c469a14284c3e23cb620e5a7cbf59cd5
Broad goal: we would like to stardadize better on normalizing user names.
Idea of this patch:
1. The 'validate' parameter is not used anywhere.
2. For possible validation levels:
- NONE will create a user with non-canonicalized user name in DB,
which in many codepaths will be inaccessible, since in many codepaths
we canonicalize the user name. It could be potentially useful for
creating system users with IP as a name, but I would argue it's a very
bad idea.
- VALID is the default.
- USABLE/CREATABLE - these check for reserved user names, so most of
the use-cases will want a system user with a reserved name. Passing
USABLE/CREATABLE essentially means you want to subsume a usable
non-reserved user account for system user, which is not a great idea.
if some code ever needs to do it (now none passes these options) -
then it can just use UserNameUtils and check explicitly.
Bug: T273933
Change-Id: I6f17349d84bd558df41fecfd19895e8c0dde4067
User shouldn't be serialized, but it sometimes still is,
so until we introduce NotSerializableTrait in User,
clear-out Authority memoization.
Change-Id: I641c2721de8c6ebe9bfcd87cfcebff60dc091126
Ideally, only User associated with the global request
should be associated with UserAuthority. For a random
user instance, not the current performer, checking permissions
should be based solely on user groups and perhaps an
existing block. Right now however, PermissionManager
is coupled with global request, so we still instantiate
a UserAuthority for non-current users. This mimics the
behaviour we've had before. As we refactor PermissionManager,
we will be able to replace Authority implementation in this case,
or even entirely prohibit non-performer authority.
Bug: T271459
Depends-On: Iebf2dca34eea751391d9740443c195287399aa5c
Change-Id: Ib094e498fd883db23f2763f171281b1c9e99217e
The InterwikiLoadPrefix hook isn't compatible with Parsoid, as it is
unidirectional and doesn't support enumerating all valid prefixes
(T270444). Set/reset $wgInterwikiCache to mock the interwiki table
for parserTests and other unit tests instead.
This is a soft deprecation, as the used-in-production
Extension:Interwiki still uses InterwikiLoadPrefix, although not in a
way that would break Parsoid (since $wgInterwikiCache is set in
production).
Bug: T270444
Change-Id: If2507017c99c4ee42c104a0890bc45a84d7239d5
Some User methods fail if they are called before $wgRequest is
set. But according to the Setup.php comment, it is only set for b/c.
The global request object can be lazy-initialised at any time.
This is sufficient to avoid T263911 (loss/obfuscation of the $wgServer
error message).
In tests, try to keep $wgRequest and RequestContext::$request in sync.
Introduce MediaWikiIntegrationTestCase::setRequest() which sets both at
once, and use that instead of setMwGlobals() or direct assignment.
BlockManagerTest was accidentally exploiting the fact that the global
context request and $wgRequest were separate objects. Making them the
same causes session cookies to appear in the response, breaking the
cookie counts. Use a new response for the test.
Bug: T263911
Bug: T245940
Change-Id: I2be99f7251a837bc6b62be0b152038157dec10f2
These accounts are usually very old and User::getRegistration returns
null for them because user_registration is null. Treat these accounts
as old enough to be in the most experienced group and only decide
on edit count. Fix queries in recent changes to avoid comparisons
with nulls as well.
Also improve documentation of User::getExperienceLevel.
Change-Id: I6090cf9b9097069469e8e547b217f0d16f0fe372
My dev wiki has some settings for these globals,
which results in broken test
1) UserTest::testGetEffectiveGroups
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
Array (
- 0 => 'autoconfirmed'
- 1 => '*'
- 2 => 'user'
+ 0 => '*'
+ 1 => 'user'
)
Change-Id: Id062c92aefdf9381d7575ece95124d62ec315aa4
User objects are apparently serialized somewhere, removing
the trait until this gets fixed.
Remove UserTest::testSerialization_fails to
allow this change for now.
Bug: T264363
Change-Id: Id804755653452dc94184e5e481efcac3053e6535
The NonSerializableTrait prevents object serialization via php's native
serialization mechanism. Most objects are not safe to serialize, and
NonSerializableTrait provides a covenient and uniform way to protect
against serialization attempts.
This patch applies the NonSerializableTrait to some key classes in
MediaWiki.
Bug: T187731
Bug: T259181
Change-Id: I0c3b558d97e3415413bbaa3d98f6ebd5312c4a67
Without this, a user created from an invalid user ID would end up
representing the current requests IP address, which may lead to
confusion. Using the reserved name "Unknown user" seems safer.
Change-Id: Icbfe7c3a561ac927713b610ac9a0b5e6b88bf2f0
