That is against how MediaWiki works. Every account is part of the user group. And inheritance is done with true always overriding false. In other words, because a student is a user even though createaccount is set to false for them, the fact that they are a user which has createaccount set to true means that they are allowed to create an account. You can't force that off. That's not how MediaWiki's permissions system works, and if the extension is based off that bad assumption then it definitely won't go into svn cause that's the kind of thing that will only work if you hack MediaWiki to work that way, and hacks aren't supported.
Additionally, it's pointless to try and create an extension with a more limited way to manage permissions based off the Userrights stuff. Because if someone can use your form, then can just as easily access the build in Special:Userrights and edit permissions with what they are allowed to do. Restricting that within a extension's special page is pointless because all it gives you is a false sense of security that doesn't exist.
Globals are globals, there is no need for an array. But normally it's done in the form $eg/ShortExtensionName/*GlobalName*. Where eg stands for 'Extension Global' to match with the 'Wiki Global' in MediaWiki.
~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)
Jim Hu wrote:
On May 17, 2008, at 3:27 AM, DanTMan wrote:
<snip>
won't change due to Vampire considerations described previously, unless there's an alternative solution.
Vampire considerations?
Best solution would be to use the same kind of permissions that Special:Userrights requires.
Here's how the vampire model works on our wikis, taking the UserRightsList 0.4 code changes into account. In LocalSettings.php:
$wgGroupPermissions['*']['createaccount'] = false; $wgGroupPermissions['user']['createaccount'] = true; $wgGroupPermissions['*']['edit'] = false; $wgAddGroups['user'][] = 'student'; $wgRemoveGroups['user'][] = 'student'; $wgGroupPermissions['student']['createaccount'] = false;
The key feature is that I can create an account for a professor, who can then create accounts for her students and change their permissions to 'student'. The only difference being that 'student' can't create accounts or manage permissions. But I want that professor to ONLY see the privileges for the accounts she created, and it's just a lot more usable for her if she sees just her users and not everyone in the system. I'm not seeing how to do that by what you're suggesting. The only place I'm seeing the information about who those users are is in the creation log. Is it somewhere else that I'm missing?
I understand that other users who want a UI like what I've written may not want that, and if it's something that makes this unsuitable for svn, perhaps I can modify the setup so that you have to turn vampire permission management on as a conscious choice. I wonder what people would think of a $extVampire or $wgVampire global? ;) Or I guess it could be done with a hook in the extension itself.
... this makes me wonder ... has there been consideration of making a $wgExtGlobals array for extensions to use?
Actually, I think you could get away with inheriting from UserrightsPage, override __construct to pass a different name, and then just override switchForm and editUserGroupsForm. In other words theoretically you could basically override the form displaying functions, and leave all the complex rights handling functions to the UserrightsPage form. /Anyone think a generic version of some special pages for overriding would be good?/
Hmm... my sense is that while this would work, it would be kinda ugly with the current version of SpecialUserRights (1.12 anyway), since there's a bunch of stuff in execute that would be run but ignored. I think a generic version could possibly be set up so that mods like what I'm trying to do are easier by taking more of the code in execute into more granular methods that can be overridden.
But in general, I like the idea of generic special pages designed with overriding possibilities in mind.
<snip>
I think this is improved, but user_registration is in the schema as a string, not a date
I believe MediaWiki stores the times in different ways for different databases. Best thing to do would be to grab the entire timestamp, then use wfTimestamp to convert it to a format which you can then use.
OK... I'll look into that.
<snip>
Jim
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l