1) The following methods were hard deprecated:
- User::addAutopromoteOnceGroups
- User::getEffectiveGroups
- User::getAutomaticGroups
- User::getFormerGroups
2) User ::getGroups, ::getGroupMemberships, ::addGroup,
::removeGroup were replaced in the production code,
but they were not hard deprecated because of conflict
with UserRightsProxy class.
Bug: T275148
Change-Id: Ia69598316f5dc5dd9511f6112b5b13e1aa07575a
This reverts commit 16fd5aaeae.
Reason for revert: This didn't really help all that much, and I think it's not the root cause. Plus, Krinkle suggested there's issues with it.
Change-Id: Ica835658c2e0aef41399743ac3deffb91fabab0a
In race conditions between threads creating two simultaneous users, this is
creating deadlocks. Moving them to the end of transaction to avoid
this.
Bug: T286521
Change-Id: I995074babbcc65cf9bb23950dd4f9f82ed1d9495
Expose info about user blocks from Authority. This allows calling code
to provide more detailed information to the user about why they are
denied some action on the wiki.
Bug: T271494
Change-Id: Ia84e469888866d72752aad355292666c31e12bad
== Status quo ==
When saving user preferences, we want to lock the rows to avoid
accidentally overriding a concurrent options update. So usually
what extensions do is:
$value = $mngr->getOption( 'option', ..., READ_LOCKING );
if ( $value !== 'new_value' ) {
$mngr->setOption( 'option', 'new_value' );
$mngr->saveOptions()
}
Previously for extra caution we've ignored all caches in options
manager if >= READ_LOCKING flags were passed. This resulted in
re-reading all the options multiple times. At worst, 3 times:
1. If READ_NORMAL read was made for update - that's once,
2. On setOption, one more read, forcefully from primary
3. On saveOptions, one more read from primary, non-locking,
to figure out which option keys need to be deleted.
Also, READ_LOCKING was not used where it clearly had to be used,
for example right before the update. This was trying to fix any
kind of error on part of the manager clients, unsuccessfully so.
== New approach ==
1. Cache modified user options separately from originals and merge
them on demand. This means when refetching originals with LOCKING
we don't wipe out all modifications made to the cache with setOption.
Extra bonus - we no longer need to load all options to set an option.
2. Split the originals cache into 2 layers - one for stuff that
comes from DB directly, and one with applied normalizations and
whatever hooks modify. This let's us avoid refetching DB options
after we save them, but still let's the hooks execute on newly set
options after they're saved.
3. Cache options with all query flags. This is a bit controversial, but
ideally LOCKING flags will be applied on options fetch right before
they are saved. We have to re-read options with LOCKING in saveOptions
to avoid races, but if the caller did 'getOption( ..., LOCKING),
setOption(), save()' we will not need to re-select with LOCKING again.
Bug: T280220
Change-Id: Ibed2789f5260b725fd806b4470631aa30d814ce6
… including PHPDoc tags like `@return <type> $variableName`.
A return value doesn't have a variable name. I can see that
some people do this intentionally, repeating the variable
name that was used in the final `return $var;` at the end
of a method. This can indeed be helpful. I leave a lot of
these untouched and removed them only when it's obviously
wrong, or does not provide any additional information in
addition to what the code already says.
Change-Id: Ia18cd9f25ef658b08ad25b97a744897e2a8deffc
This feature was added to provide a custom error message
if the edit token was present, but trailing slashes were
stripped from it by some ASCII mangling proxy. According
to metrics this has happened 5 times last month, which
IMHO doesn't justify having special handling. Giving a
regular token mismatch error message should be good enough.
Depends-On: Ieb4f6e25a74ecaa1110c59a8d8eed3ca792f2d41
Change-Id: I85759e315581f891721dfac246daaafe956ab201
UserEditTracker now returns null for anonymous users
instead of throwing an exception.
Added new UserEditTracker::setCachedUserEditCount()
method (internal) to handle the user_editcount field
in User::loadFromRow()'s row. This now means that
the creation of one User object can set the cached
value for any other object for the same underlying user
- the alternative (just ignoring the value) would mean
that an extra database read might be needed. This is
only used for users created with a row that includes
the user id - we silently discard the value if
the row doesn't have a user id (or the user id is 0)
to avoid issues with UserEditTracker trying to fetch
the user id and potentially triggering another load.
A follow-up will simplify the UserEditCountUpdate class
to remove storing full UserIdentity objects now that
only the id is needed.
Follow-up: Ibf1482bcbcbf4d56fc06531bb3e17e2a6e3e2e6f
Change-Id: Ie3fb4887d9f2d96b32598865030351bf3bf20ce5
- UserEditCountUpdate: accept UserIdentity instead of User
- Move User::incEditCount() to UserEditTracker
Change-Id: Ibf1482bcbcbf4d56fc06531bb3e17e2a6e3e2e6f
This reverts commit ecf826a2ee.
Reason for revert: need to edit the patch and then it will be GTG in order to finish hard deprecating of User ::getCanonicalName, ::isUsableName, ::isCreatableName
Change-Id: I2f57f56728fcbeada96dc2228f07dc8bcaa5d4f6
This commit was reverted before cause it has changed the initialization order
and broke FlaggedRevs. Now FlaggedRevs issue was addressed, so we can apply
it back.
Bug: T254838
Change-Id: Id29024caf06fcd0d7d4e039aea8142e8131d47a7
In a few places where a PermissionManager is used
but only GroupPermissionsLookup is needed
Also update references to the class in PermissionManager
that referred to it as GroupPermissionLookup
Change-Id: I5d7a13900852a38768a106aeee1ce012c3a04ea2
When a hook handler returns something else, e.g. null, this
will be stored in $this->mEmail and cause unexpected errors
(most notably type mistatches) later. This was not a problem
as long as we didn't use strict `string` type hints. But now
we do.
Change-Id: Iae9806304d8c39496b6d8e49e700f3a2c55520db
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
Given that User::getID is a very common method, used very early
during setup (e.g. during session initialization), only load
its dependency when it's really needed.
Bug: T282320
Change-Id: I6565426e9bf7084b1a33d39b2882639a03210460
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
The user 'Maintenance script' is often used to perform various
automated tasks. Providing it everywhere as a string literal is
error-prone, and errors can be somewhat disruptive (e.g. with
User::newSystemUser with steal=true it can erase the credentials
of a legitimate account). Provide a constant instead.
Also replace existing uses for consistency.
Change-Id: I685a5bfe56bbf1a47f35072f7f7c8be320ee27db
