This is inconsistent with the access pattern of other constants in
MediaWiki. it's also confusing (e.g. it's unclear to a newcomer why
UserFactory is implementing IDBAccessObject) and it's prone to clashes
(e.g. BagOStuff class has a clashing constant).
It has been already announced: https://w.wiki/9DAX
Bug: T354194
Change-Id: Ic2357634b8385d65b55db2b557191419b06c40e0
This method is a shallow component [1] which is an anti-pattern in
software design (yes, I'm aware I introduced that method). We should
avoid expanding its interface further and focus on the most common
usecase. Since it's not doing much under the hood, it's okay to just
copy-paste the logic into a method in UserGroupManager.
This partially reverts I9e2de1cc84d12443.
[1] Original idea from "Philosophy of software design" book but you can
find short TLDRs in the internet, like:
https://vladimirzdrazil.com/posts/deep-shallow-modules/
Bug: T355813
Change-Id: I8cac972ecc9e962f6605a8feaa24a9e00af07b66
Found via (?<!IDBAccessObject)::READ_
We are planning to deprecate and remove implementing IDBAccessObject
interface just to use the constants.
Bug: T354194
Change-Id: I89d442fa493b8e5332ce118e5bf13f13b8dd3477
To avoid hard-coded of the I92236cea845c10ef1725891a49d48a04d5d3bfad, share the allowed operators.
Bug: T196059
Change-Id: Ic3608097dadccb76f93da02c0611a36f0186a9c7
Instead of calling self::READ_* on these constants, just directly call
it.
Since these classes are public and might be relied on directly in other
places, we can't remove the "implements IDBAccessObject" yet but we will
start doing that soon.
Bug: T354194
Change-Id: I3e26b9fc7f93efdfc55a1790a7cdfa5c0d562303
That would remove the need for passing around LB.
ReadOnlyMode code needs a lot of clean up. In follow up patches, I want
to inject WAN and possibly APCu to this and remove that from LB itself
to decouple LB/LBF from BagOStuff.
In even later patches, I want LB/LBF to set the ReadOnly in the service
instead and reverse the coupling.
Bug: T343917
Change-Id: Ibe7f80292d911fc8953e59f74264c499ab1700d0
The design principle for SelectQueryBuilder was to make the chained
builder calls look as much like SQL as possible, so that developers
could leverage their knowledge of SQL to understand what the query
builder is doing.
That's why SelectQueryBuilder::select() takes a list of fields, and by
the same principle, it makes sense for UpdateQueryBuilder::update() to
take a table. However with "insert" and "delete", the SQL designers
chose to add prepositions "into" and "from", and I think it makes sense
to follow that here.
In terms of natural language, we update a table, but we don't delete a
table, or insert a table. We delete rows from a table, or insert rows
into a table. The table is not the object of the verb.
So, add insertInto() as an alias for insert(), and add deleteFrom() as
an alias for delete(). Use the new methods in MW core callers where
PHPStorm knows the type.
Change-Id: Idb327a54a57a0fb2288ea067472c1e9727016000
This moves the core part of wfGetPrivilegedGroups() out of Wikimedia
config and makes it possible to move functionality built on it into
core.
Bug: T208477
Change-Id: I6536ef2909caeed047447e8b6a25831d6f00d827
The LoadBalancer is for a specific wiki,
so the database on purge should be connected to that wiki as well.
Change-Id: I6d89ff3df58d691474776764a48abd924c6405d5
Using a php parser written on top of ANTLR4, done semi-automatically.
I checked everything and made adjustments.
Bug: T311866
Change-Id: I6150c6909bce8f3dbd745a26380cc0af9d9c547f
* PageEditStash and UserGroupManager: remove the isRegistered
check, which isn't necessary since UserEditTracker will just
return null for users not in the `user` table. Instead handle
a possible null return value.
* LogFormatter: keep the check, to avoid instantiating the
UserEditTracker if not necessary, but check getId instead of
isRegistered, since the check is really for whether the user
is in the `user` table, regardless of their registered status
(e.g. they may be a temporary user).
Change-Id: I62faf9d042a9297bcd662f7908d73d8469b26c98
- Show error when viewing groups for a temp User from Special:UserRights
- Add a fatal error when trying to save groups for temp users from Special:UserRights
- Creating an exception from UserGroupManager when attempting to save groups to a temp user
Bug: T340468
Change-Id: I6892a5303b34a8c1608c81a46c684bcaf74817bd
This reverts commit df1312b799.
Reason for revert: More updates to callers are needed to prevent
throwing errors.
Bug: T340468
Change-Id: I604bef13a550c1bd8fc10396284505f24cf17802
Assert the wiki id of the identity passed to the manager to avoid mixing
up database changes which does not belong to the user id given to the
manager
This removes comments added by first step a3f3e3c
This reintroduce b565ab8
Bug: T337590
Depends-On: Ic449aa0d6b874ac5a2b8bf652c2637188aa0edb6
Depends-On: I2dffe8b633cff182866803ce5cb693f31364f178
Change-Id: Icd2d4efdb84ae085402c9ca59ced7e14be511aa0
Update the following UserGroupManager methods:
* addUserToAutopromoteOnceGroups returns an empty array as it does for
IP users
* getUserAutopromoteOnceGroups returns an empty array
Autopromotion was disabled for temporary users in
d6a3b6cfa8.
Bug: T340464
Change-Id: I090bbd9f16070bf559f5bb87f04aabcf0bedbaf2
- Add new error message specifically for Temp Users
- Prevent calling UserGroupManager::addUserToGroup on a temporary user in Core
Depends-On: 932292
Bug: T340468
Change-Id: I782a16efb20e3b1e2ead4ce5e3bc030d066355de
When we first deploy temporary account autocreation, we want temporary
users to resemble anon users more than registered users, for minimal
community impact.
If we add them to the 'user' group, then they will automatically get
whatever rights a wiki currently assigns to registered users. If we
don't, they will only get rights that are currently given to everyone
(same as anons).
Therefore stop adding them to the 'user' group, and instead add them
to a new 'temp' group, in case site admins want to give them extra
rights.
Bug: T340457
Depends-On: I6333fa2289f3142d1b5cedf2cc910ced3ba5019e
Change-Id: Idb46252fe6533ab0a5410bdb3093043cb359c206
Autopromotion was disabled for temporary users in
d6a3b6cfa8. In that commit,
PermissionManager::getUserImplicitGroups, no longer checks autopromote
groups for temporary users, so PermissionManager::getUserPermissions
no longer finds autopromote groups for temporary users.
In this commit, UserGroupManager::getUserAutopromoteGroups no longer
finds autopromote groups for temporary users.
Bug: T340462
Change-Id: I189391bd9a41718648d198b83736d837c76ead52
I did this using a script written on top of antlr4 parser so it doesn't
have some clean ups a human would do but it's pretty nice already.
Bug: T330640
Change-Id: I608566700c6d737ee986bf47dda87effc69614d6
First step to make UserGroupManager assert the wiki id of the identity
is to pass the check in UserIdentityValue::getId when a cross-wiki
identity is given to the UserGroupManager
Bug: T337590
Change-Id: I2dffe8b633cff182866803ce5cb693f31364f178
Normalize the local wiki name to UserIdentity::LOCAL.
This is similiar to DatabaseBlockStoreFactory.
Rename dbDomain to wikiId to make this difference visible in code
Change-Id: I89679402ef5d2c80809e7b9b5a57d798a2b98a94
