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 (
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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l