That restrictive rights extension is doomed to be filled with bugs.
Especially since you are using ! instead of an explicit === false test.
That's not explicit false, that there will remove rights even if
permissions are not set. And there's going to be a horrible amount of
issues with how rag-tag the list of rights are by default. You're also
going based on the order of things in the array. Which is not something
you should be basing on because there's no guarantee of what order
things are going to go in with the rights array. So, theoretically if
someone was a sysop, meaning they have *, user, autoconfirmed, sysop in
their array since 'sysop' comes last because 'sysop' has no 'edit'
explicitly set anyone you give sysop will not be able to edit.
Additionally, since autoconfirmed has absolutely nothing set except
autoconfirmed, once a user account has been active for 4 days or over, a
user account on your extension should suddenly lose it's ability to do
anything on the wiki, including view it.
Though I do thank you for pointing out UserGetRights, that would have
made my semi-shared permissions model a lot easier when I built it in
the past.
It honestly looks like you're overcomplecating the permissions model in
MediaWiki. You're looking at the perspective of creating plain no-rights
accounts, and letting them create restricted accounts which have extra
flags. Honestly that is complete insane. You're trying to give a default
rights group more control over a non-default flag, which in a proper
permissions model is supposed to signify more permissions over the
default inclusive group. Honestly your rights model would be better
handled just by giving professors a 'professor' flag which enables them
to create accounts and if needed put them into a student group. But that
shouldn't restrict rights in any way, just add more, like editing the
wiki or something.
~Daniel Friesen(Dantman) of:
-The Gaiapedia (
On May 17, 2008, at 3:28 PM, DanTMan wrote:
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.
I could have sworn that it worked in an earlier version of MW, but I
see that setting
$wgGroupPermissions['student'] = false;
behaves just like you say it does. However, it was easy to whip up an
extension to modify this behavior without hacking MW, by hooking at
UserGetRights.
http://www.mediawiki.org/wiki/Extension:RestrictiveRights
Obviously, I wish that was the default - I think admins expect that if
they explicitly turn something off in LocalSettings, it should not be
overridden by something else. But that's just me.
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.
I'm not going to update the
mediawiki.org page yet, since I figure
it's likely that you will find other problems (unless you're sick of
this and have given up!), but I have a test revision if you're willing
to keep looking at these
http://trimer.tamu.edu/jh/UserRightsList.0.5a1.tgz
I created an global variable that can be set to allow users who do not
have userrights to modify specific subsets of group membership of
users they created. For my setup, I use:
$egUserRightsListChGrp['user'][] = 'student';
Inside the extension, I modify $wgAddGroups and $wgRemoveGroups based
on $egUserRightsListChGrp, but since this is local to the extension,
it does not affect access to Special:Userrights.
I also changed the date handling based on your suggestions, and did
some other stuff to aid independence from mysql. But I don't have any
installations to test those on.
I hope I'm getting closer to addressing your concerns.
JH
<snip>
=====================================
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