On May 18, 2008, at 9:47 AM, DanTMan wrote:
That restrictive rights extension is doomed to be
filled with bugs.
Especially since you are using ! instead of an explicit === false
test.
changed.
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.
I don't think you understand the way this works, and perhaps I need to
reword the documentation. I'm using explicit to mean
(isset($wgPermissions[group][action]) && ! $wgPermissions[group]
[action]) as opposed to just (! $wgPermissions[group][action]).
The scenarios you posit will not happen because sysop has no edit key
in the $wgPermissions array. The extension never tries to unset
$wgPermissions[sysop][edit], and if it did, it would have no effect
because $wgPermissions[sysop][edit] isn't set in the first place. The
edit permission for sysop inherits from user. Similarly,
autoconfirmed won't be affected because User->getGroups, unlike User-
getEffectiveGroups only looks at what's in the
groups table. Which
means that it also doesn't return user or *. I guess
that means that
it doesn't allow restricting user more than *, but that's not
something I'm interested in changing.
Since it only unsets elements from the $wgPermissions array, I don't
see how it's dependent on the order of the array.
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.
I'm glad you're getting something positive out of this exchange...
it's only been there since 1.11.
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.
In some cases it is easier to do things the way you suggest, and I
said so in the usage section of the page for the extension. It's not
easier in our actual use case, which we've been doing for over a year,
where the students represent a very minor component of the user
community - the majority are scientists who haven't considered using
the wikis for teaching - and we want our users to spread account
registration through the community. The way we're doing it, only the
subset of those users who want to have more restricted accounts for
their students even have to learn ANYTHING about the rights system.
If they have to elevate the users they create to another group, it's
not going to happen.
I'm sure there are other ways to do it; perhaps by hooking at
AddNewAccount to automate adding new users to a default group with the
permissions I now give to user. Implementing that approach, however,
means going back over the database and upgrading all the preexisting
nonstudent accounts to an additional group. And it seems to me that
would make managing permission subsets messier. To fully implement
that allowing for other possible configurations, I'd end up with user
being just * with a registered account, default with what user has
now, and some messy subset of groups with permutations of positive
permissions beyond user.
While that could be done, I'm not going to do it just because you keep
invoking a "proper permissions model". If you have some source for
what a "proper permissions model" is and why alternative models are
improper, please point me to something to read, and I'll look at it.
Just invoking the term doesn't help me understand why what I'm doing
is improper rather than just different. I'm a biologist, not a
computer scientist, but to the extent that I can understand what I can
find via googling various permutations of "permissions model
inheritance design", there are alternative models, and I'm seeing
papers that argue against unconditional permissions inheritance.
Allowing admins to create groups where inherited permissions are
revoked makes it easier to modify the permissions model as new
circumstances arise - that's exactly how it came up for us.
Having non-default groups with fewer permissions at all is the only
thing in RestrictiveRights. Controlling who has permission to change
group membership is in UserRightsList. The two are both needed for my
permissions model, but they're separate issues, and the two extensions
should work without each other... which is why I separated them. The
management of a subset of users based on the creation log doesn't have
to be applied to the group user.
Finally, I really appreciate your guidance on the code, but I'd also
appreciate it if you'd leave my sanity, or lack thereof, out of future
discussion.
JH
~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: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
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
=====================================
Jim Hu
Associate Professor
Dept. of Biochemistry and Biophysics
2128 TAMU
Texas A&M Univ.
College Station, TX 77843-2128
979-862-4054