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
