This fixes a fatal error in the deferred update from addUserToGroup(),
due to it not specifying a dbDomain parameter. This bug was
introduced in 2020 with commit 40b88d635b.
== Scenario
Use meta.wikimedia.org/wiki/Special:UserRights to act on
`Example@otherwiki`.
> DBConnectionError:
> Cannot access the database: Unknown database 'metawiki'
== Problem
The domain param to getConnection() is optional for the common case of
connecting to the core database of the wiki's main load balancer.
This is the one kind of shared state we tolerate since it is
deterministically derived from site configuration, and is safely
dependency-injected from service wiring.
But, when obtaining a LoadBalancer for a foreign wiki, one must
basically always pass this to getConnection() as otherwise it will
try to connect to the local wiki database (e.g. metawiki) while
calling the LoadBalancer for otherwiki.
== Consideration
* The LoadBalancer objects should and are shared for dbs on the
same section, thus preserving the dbDomain from the LBFactory
method call is impractical, and probably also too magical/fragile
in practice due to increasing the distance between these
responsiblities and creating more easy-to-forget state.
* There is no obvious default for any given loadbalancer other than
the local wiki's db. There are typically many wikis on the same
LB.
* For external LBs, we actually do sometimes make use the current wiki,
e.g. ExternalStore is structured as tables inside a DB for each
wiki.
Bug: T193565
Change-Id: Ic82c264f7d3bbb1403600d21cfed3516f854332a
Now largely automated:
VARS=$(grep -o "'[A-Za-z0-9_]*'" includes/MainConfigNames.php | \
tr "\n" '|' | sed "s/|$/\n/;s/'//g")
sed -i -E "s/'($VARS)'/MainConfigNames::\1/g" \
$(grep -ERIl "'($VARS)'" includes/)
Then git add -p with lots of error-prone manual checking. Then
semi-manually add all the necessary "use" lines:
vim $(grep -L 'use MediaWiki\\MainConfigNames;' \
$(git diff --cached --name-only --diff-filter=M HEAD^))
I didn't bother fixing lines that were over 100 characters unless they
were over 120 and triggered phpcs.
Bug: T305805
Change-Id: I74e0ab511abecb276717ad4276a124760a268147
* Allow EditPage to create a user on page save. This has to be enabled
in config and then activated by the UI/API caller.
* Add an autocreate source for temporary users.
* Allow editing by anonymous users via automatic account creation when
$wgGroupPermisions['*']['edit'] = false. On an edit GET request, use
an unsaved placeholder user to stand in for post-create permissions.
* On preview or aborted save, the username to be created is stashed in a
session and restored on subsequent requests.
* On a (likely) successful page save, create the account.
* Put regular non-temporary users in a "named" group so that they can be
given additional permissions.
* Use a different "~~~" signature for temporary users
* Show account creation warnings on edit and preview.
Change-Id: I67b23abf73cc371280bfb2b6c43b3ce0e077bfe5
Make phan stricter about null types by setting null_casts_as_any_type to
false (the default in mediawiki-phan-config)
Remaining false positive issues are suppressed.
The suppression and the setting change can only be done together
Bug: T242536
Bug: T301991
Change-Id: I0f295382b96fb3be8037a01c10487d9d591e7e01
Fixes a bug where if a group both inherited its rights from some other
group and had rights of its own (which seems like something we should
support), that group would be listed twice on Special:ListGroupRights.
Change-Id: Ie3d93287aa256a7ed50e48a78b5996a193e9b60f
There are common use cases to having a group inherit permissions from
another group. For example, if you have to have a "confirmed" group that
can be manually handed out to grant "autoconfirmed" status, or if you
wanted to make the "sysop" group also have "interface-admin" powers.
Previously to make this work you needed to either copy all the
$wgGroupPermission entries for the second group, or use a
$wgExtensionFunctions to copy it over at runtime. Neither are great
solutions, hence this patch.
This introduces a new configuration option, $wgGroupInheritsPermissions,
that GroupPermissionsLookup will use when determining what permissions
each group has. This option is not recursive for simplicity.
To make this work, Special:ListGroupRights now consults
GroupPermissionsLookup instead of looking at the
$wgGroupPermissions/$wgRevokePermissions globals. It also uses
UserGroupManager to get the list of all groups instead of looking at
more globals.
Anything still directly reading permissions from those globals is liable
to be broken, if they weren't already.
Bug: T275334
Change-Id: Iad72e126d2708012e1e403bee066b3017c16226d
Queries that query a value "1" are expected to return either
that "1" (possibly as a string), or false. It's safe to simply
cast this to bool and use it as it is.
Queries for COUNT(*) are expected to return that number,
possibly as a string. It's not possible for such a query to
return false. And even if, casting to 0 is fine.
I found an existing code style where the table name and the
"1" are on the same line as the selectField() method name, and
applied it to all similar queries.
Change-Id: I9453196281871c03ef03f653f43762eb9284342f
UserGroupManagerFactory takes care of getting the
correct JobQueueGroup for the domain.
Bug: T287808
Change-Id: I548f0c52b298bfcae386ca1a427521c81dc802fe
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
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
In tests, we sometimes pass non-complete user identities into
UserGroupManager, for example with a mock authority we can
pass in UserIdentityValue of a registered user that doesn't exist.
Lazy-loading of such user in the middle of UserGroupManager execution
makes UGM trip on accessing arrays by non-existent keys. This
situation shouldn't really be happening in reality, since loading
of a user shouldn't be changing it's ID or name, but if it ever
does happen, hard-crashing on undefined array index seems worse
then placing a non-reachable-anymore cache entry.
Bug: T284804
Change-Id: Ibbc1c78c50a4ff1e2dcc9ff01e5984154dd210d5
This reverts commit 900c6663b0.
Reason for revert: breaks Parsoid CI. Instead of fixing the test in presence of the FlaggedRevs hook, I would rather convert DefaultPreferencesFactory to Authority and fix the tests once instead of doing it twice.
Change-Id: Iaa440a9804c9ed97339e737162ef64ccf29ceb51
In order to break up cyclic dependency between UserGroupManager
and PermissionManager, introduce a lightweight service for checking
group permissions.
Bug: T254537
Depends-On: I99ab3a69c41b3ec6721f9504ad6c77d3122df591
Change-Id: I1acd55c07d07b4a0d43fd838e11374b6d9be98d9
This includes fixing some mistakes, as well as removing
redundant text that doesn't add new information, either because
it literally repeats what the code already says, or is actually
duplicated.
Change-Id: I3a8dd8ce57192deda8916cc444c87d7ab1a36515
These were never meant to be part of the public interface and should not
ever have been marked with @since. They're only useful for constructing
the respective objects, which no outside users should be doing.
Change-Id: I86e01272d46fc72af32172d8a12b9180971d4613
1. User::addGroup has to be allowed to update the old group
2. Replace use of string constants to identify cache class,
that's prone to typos and errors. Instead, use private constants
3. Update cached user group memberships in place upon modification.
Before UserGroupManager, we've used to do that - this saves some
DB queries, and is better for correctness - for example UserrightsPage
is adding new memberships and then immediately reads from replica,
expecting it's changes to be there already.
We do not know however how many other cases there are which rely
on this pattern, so implement in-place cache update.
Bug: T255330
Change-Id: Ia5ae0e22d4156fd5e4b9aa7eeb801902e79803d1
Additionally, User::checkAndSetTouched was made public and
marked as @internal. Eventually, as User class refactoring
continues, I would expect this to be replaced by some service.
Bug: T252621
Change-Id: I53533f494950d08ee5ed1ec54d24958c21e7b3aa
Introduce a UserGroupManagerFactory and UserGroupManager.
The factory utilizes the same pattern as RevisionStore
for access to user groups of a foreign wiki.
Some user group related methods were ported from User
and UserGroupMembership and deprecated, more methods to
be moved over in future patches, not to make this one to large.
Eventually as all the group-related methods are moved and their
usages are replaced, the need for the UserRightsProxy will disappear,
thus it also will be deprecated and removed. Currently for backwards
compatibility, I've had to create artificial UserIdentityValue
objects in some of the deprecated methods to avoid making transitional
temporary methods in the UserGroupManager that would take user ID
instead of the UserIdentity. All of this will go away once migration
to UserGroupManager is completed.
Bug: T234921
Change-Id: If29c6a03dfdbb80b2e846243f7e384b334da9f07
