Last modified: 2010-05-15 16:02:53 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 17077 - Sysop and bureaucrat rights not effective after adding user via UserLoadFromSession hook.
Sysop and bureaucrat rights not effective after adding user via UserLoadFromS...
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
All Solaris
: Normal major (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2009-01-19 14:35 UTC by Sam Sexton
Modified: 2010-05-15 16:02 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

Report to MW Support desk with details and code. (11.90 KB, text/plain)
2009-01-19 14:37 UTC, Sam Sexton

Description Sam Sexton 2009-01-19 14:35:30 UTC
I submitted the attached report to the [ Support Desk] as an Extension problem - perhaps not totally accurate, but it appeared to be the most appropriate classification. However, the only update has been by myself. 

I've since delved a bit deeper but am not so gradually getting out of my depth and seriously suspect that a bug might be involved as this hook was only introduced in 1.13.0 - although I realise that there are a few extensions using it. I thought that bug 14914 might have been helpful, but it appears not. 

Since the report below, I have dug down through SpecialPage:getUsablePages, userCanExecute in the same script and isAllowed in User.php, but would appreciate some help on this, as it (and a problem with export/import) is holding up implementation of the new version of the wiki. 

Here is a sample of debug output from SpecialPage.php[getUsablePages] and User.php[isAllowed] from my accessing the Special Pages page - as shown below, Userlist shows me as sysop and breaucrat:

TGST: action is mergehistory
TGST: Right: createaccount
TGST: Right: read
TGST: Right: edit
TGST: Right: createpage
TGST: Right: createtalk
TGST: Right: writeapi
TGST: Right: move
TGST: Right: move-subpages
TGST: Right: read
TGST: Right: edit
TGST: Right: createpage
TGST: Right: createtalk
TGST: Right: writeapi
TGST: Right: upload
TGST: Right: reupload
TGST: Right: reupload-shared
TGST: Right: minoredit
TGST: Right: purge
TGST: Right: autoconfirmed
TGST: Page MergeHistory User: Sam.Sexton CAN NOT see page.

This is logically consistent as far as it goes, but inconsistent with my being both sysop and bureaucrat. For a long time I suspected that I'd missed a step from creating the user account, but now I'm not so sure and would appreciate a much more experienced opinion on the problem.

Many thanks in advance.
Comment 1 Sam Sexton 2009-01-19 14:37:26 UTC
Created attachment 5700 [details]
Report to MW Support desk with details and code.

This attachment contains full (I hope!) details of the problem and the relevant code.
Comment 2 Sam Sexton 2009-01-20 10:28:09 UTC
What appears to be the same problem has been reported just below my submission to the Support Desk at I have asked for further information and will also go now and do some more digging.
Comment 3 Sam Sexton 2009-01-20 11:43:28 UTC
I've just installed the NamespacePermissions extension and the groups required for that are similarly affected. i.e. I (as Sam.Sexton) am in the ns100RW group, but can't create a page in that namespace. As SS I can do so. So, it looks to be a general group permission problem rather than specific to Sysops and Bureaucrats - as expected, but I thought it best to verify.
Comment 4 Sam Sexton 2009-01-20 14:23:12 UTC
I've added some debug code to getRights() in User.php and am getting close to the problem:

 this->effectiveGroup: *
 this->effectiveGroup: user
 this->effectiveGroup: autoconfirmed

but I'm now in oodles of groups (as Sam.Sexton):

(first | last) View (previous 50) (next 50) (20 | 50 | 100 | 250 | 500)

    * SS ‎(bureaucrat, nsIGRW, sysop)
    * Sam.Sexton ‎(bureaucrat, nsARCHRW, nsARCH_TalkRW, nsD3PRIVRW, nsD3PRIV_TalkRW, nsDEVRW, nsDEV_TalkRW, nsDOCRW, nsDOC_TalkRW, nsIGRW, nsIG_TalkRW, sysop)
    * West.Sst-noreply
    * WikiSysop ‎(bureaucrat, sysop)

(first | last) View (previous 50) (next 50) (20 | 50 | 100 | 250 | 500)

Hmm - I have had a problem with phpMyAdmin reporting the absence of mcrypt (due to build problems which I reported many weeks ago, but have had no response - I'll go back and try again or see if there's a later version). I would be a little surprised if this were related to the problem, but would feel guilty not mentioning it.
Comment 5 Sam Sexton 2009-01-20 15:39:39 UTC
I've now added some additional code to my hook, to show the real name and groups after loading the user from the database. I really a PHP novice, so it's possible I'm not doing this properly, but the relevant code is:

  // Load the existing or newly-created user from the database ...
  if ( !$user->loadFromDatabase() ) {
    logTGST("loadFromDatabase failed for user ID $user->mId");
  } else { // Additional debugging ...
    logTGST("loadFromDatabase succeeded for user ID $user->mId");
    logTGST("  real name: $user->mRealName");
    logTGST("  groups: $user->mGroups");
  return $user

and the logged output is:

2009-01-20 15:33:37 loadFromDatabase succeeded for user ID 1004
2009-01-20 15:33:37   real name: Sam Sexton
2009-01-20 15:33:37   groups: 

So it would _appear_ that either I'm interpreting what getGroups() does incorrectly, or the group membership is not being recognised correctly. Any suggestions?!
Comment 6 Sam Sexton 2009-01-21 10:34:38 UTC
I've finally solved this myself - the crucial clue was finding out that in loadFromDatabase(), mGroups is nullified and the assignment of the groups deferred to loadGroups(), which is called by saveToCache() - this in turn is called from loadFromId(), so I added a call to saveToCache() to my hook and at long last, I can see the restricted groups. I will sanitise my code and add it to the discussion page at so that it can serve as an example of what's needed - adding the call wasn't really too obvious! ;-)
Comment 7 Roan Kattouw 2009-02-03 15:13:10 UTC
*** Bug 17339 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.