Users can
probably part of several groups.
This sounds like a good, solid approach. One thing that might be worth
considering (you may not want to code it fully straight away, but
maybe bear it in mind while designing the architecture, so that it's
feasible) is defining relationships between groups. e.g.:
* inheritance: Define permissions["Sysop"] = permissions["Logged in
user"] + delete, undelete, protect, ...
** no need to explicitly change rights of all groups if you change the
rights of a more general group; e.g. adding a globally usable Special:
page shouldn't require changes to the permissions for group "Sysop" as
well as group "Logged in user"
** another way of looking at this is: "Sysop" implies "Logged in
user"
* cumulative: Define permissions["Sysop"] = delete, undelete, protect
** leave the wiki-organiser to assume that all users with "Sysop"
status will also have "Logged in user" status in order to do the more
mundane tasks
** this is the easier way to go, and is useful anyway for things like
permissions["trusted SQL-savvy user"]="Special:AskSQL" which
shouldn't
imply any other rights, just be added to them
I hope this message isn't too waffly, and you get the general drift of
what I'm on about. Like I say, these are mainly just eventual aims to
keep in mind since you're essentially designing from scratch, rather
than immediate to-do items.
Hello,
Actually each group need to be assigned every needed rights. There is
nothing like inheritance / cumulation. So one have to:
Anonymous = permission(read)
LoggedIn = permission(read, write)
Sysop = permission(read, write, delete)
Bureaucrat = permission(makesysop)
This way bureaucrat account is only to make sysop.
We want 1.4beta to be out by the end of the year and I personally would
like to get the user right system in 1.4 (as it's a big new feature).
As I am slowly coding it, I will try to keep it as simple as possible
and then we can enhance it with inheritance later in 1.4.x versions .
cheers,
--
Ashar Voultoiz - WP++++