Page MenuHomePhabricator

Move User::getRights and related methods into PermissionManager
Closed, ResolvedPublic


The following methods should be factored out of the User class into PermissionManager, leaving only deprecated stubs:

  • User::isAllowed -> PermissionManager::userHasRight or some such
  • User::getRights -> PermissionManager::getUserPermissions.
  • User::groupHasPermission -> PermissionManager::groupHasPermission
  • User::getGroupPermissions -> PermissionManager::getGroupPermissions
  • User::getGroupsWithPermission -> PermissionManager::getGroupsWithPermission
  • User::groupHasPermission -> PermissionManager::groupHasPermission
  • User::isEveryoneAllowed -> PermissionManager::isEveryoneAllowed
  • User::getAllRights -> PermissionManager::getAllPermissions


  • This change should allow us to switch the public method signatures in PermissionManager from USer to UserIdentity. Some internal uses of User will remain for now, but they can be covered by User::newFromIdentity(). (Note that the "new" is a lie, the method will return the original instance if it's already a User object).
  • Implementing getRights needs access to the user's session. This may not be possible for users other than the current user, making the behavior inconsistent in some cases (needs investigation of current behavior!). The method's contract should make this clear. Also, injecting any information about the current user, request or session is awkward for a service object, but should be acceptable due to PHP's per-request execution model, compare T218555.
  • User::getAllGroups is based on the same information as getAllRights, but this fact should not be cemented by exposing getAllGroups in the PermissionManager interface. Instead, we should probably create a GroupManager service at some point.

Event Timeline

daniel updated the task description. (Show Details)

Change 502484 had a related patch set uploaded (by Vedmaka Wakalaka; owner: Vedmaka Wakalaka):
[mediawiki/core@master] Factors out permissions check from User into PermissionManager service

Change 502484 merged by jenkins-bot:
[mediawiki/core@master] Factors out permissions check from User into PermissionManager service

kostajh subscribed.

I had to revert this due to issues noted in T224607. There are three patches attached to that issue which, when merged, should make it OK to merge again. There's a fourth patch ( that proposes to do things in a somewhat different way for the problems encountered with WikibaseLexeme, but it doesn't yet work.

I'd recommend merging the three patches attached to T224607, then merging, then looking at again.

@kostajh @daniel I am a bit confused about how this could result in broken CI, could you give me some clues on what did go wrong?

My biggest concern at the moment is to understand how and why the patch was green at the time it was merged ( considering all dependencies were merged beforehand ) [1] but ended up in the broken state. It's clear that for this change to pass some of both core and other extensions tests (which manipulate user or groups permissions in their code) needed to be updated in order to pass, so the change was supplied by a set of smaller patches to failing extensions based on CI results.

But, looking on T224607 I clearly see that CentralAuth and some test in Wikibase\Lexeme started to fail and I can understand why these are failing, but I have no clue why they did not fail during CI before the patch was merged? So, in other words, I think I am trying to understand if, if to say, "production" CI is somehow run different set of tests from the review stage CI?


@Vedmaka those extensions are not included in the set of extensions tested when MediaWiki core patches go through CI. So we only find the problems later, when someone tries to merge or publish a patch related to those extensions. There's some discussion of it here fwiw

@kostajh ah, I've got it, thanks! That makes it clear and at the same time makes things worse - at first glance, I don't see any good solution to make this patch compatible with every extension ( see ) since the change seems to be simply way too radical.

The only workaround that could to work is to "rewind" it back and get rid of individual configuration values being passed into PermissionManager constructor during the wiring phase and replace it with the whole Config instance injection - that's not cool, but that would ensure that PermissionManager is always working with actual globals values and will eliminate the need to reset it. We probably may need to also get rid of caching inside the service, depending on the situation. @daniel any thoughts on this?

Change 514474 had a related patch set uploaded (by Daniel Kinzler; owner: Vedmaka Wakalaka):
[mediawiki/core@master] Re-apply: Factors out permissions check from User into PermissionManager service

Change 514474 merged by jenkins-bot:
[mediawiki/core@master] Re-apply: Factors out permissions check from User into PermissionManager service

Let's hope this doesn't break CI again :)