On Fri, 22 Oct 2004 17:20:33 +0200, Ashar Voultoiz <hashar(a)altern.org> wrote:
I am currently implementing a new user rights
management system. I just
commited a simple showcase in cvs wich is not usefull at all :o)
The system is actually:
Create or edit a group
Assign to each group some functions (reading page, moving page, read
diffs, access to specific special page).
Then lookup and edit an user and assign him in some groups.
[...]
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.
--
Rowan Collins BSc
[IMSoP]