Sphene Community Tools

The current permissions system is not really sufficient for most purposes (except websites with 1 admin and a couple of users.. like on my site ;) ) - so i'm looking in improving the flexibility.
I would welcome ideas and feedback.

The current system works in the following way:
Every category has three properties: allowview, allowthread, allowreplies which can each have one of the following values:
* All Users
* Loggedin Users
* Members of the Group
* Staff Members
* Nobody

(All categories of a website are parts of a single group .. so 'Members of the Group' is usually more or less useless if you only run one website with SCT - although it allows you to differentiate between normal logged in users and users who have authorized.. a bit more :) )

So - what is wrong with this:
- There is no way to give one member of a group more privileges then anyone else
- With more admin features in the board (annotation, moving of threads, etc.) there will be a need for more permissions where these 4 different user categories are no longer enough


i see four posibilities:

1.) Introduce "userlevel" into the Group architecture.. which allows you to set permissions like 0 - Normal group members, 1 - privileged group members, 2 admin group members
2.) Introduce custom flags (like - 'normaluser', 'moderator', 'administrator') into the Groups - an administrator can assign flags to members of the group and then decide which flag is required for viewing, posting threads or replies in a category.
3.) Introduce predefined flags (like 'view', 'post', 'movethread', 'annotatepost', 'lockthread', 'stickythread', etc.) which an administrator can assign to members of a group. (seems like an administrative nightmare - but is the most flexible)
4.) Allow an administrator to assign Moderators to a given category - this would allow those users to execute all admin features in the given board.

1 and 2 also require additional category-fields - at least a 'allowadministration' which defines who is allowed to execute administrative features like moving, locking, making a thread sticky, etc.


So - what do you think ? Maybe the 3rd option with a way to further group members of a ... Group - ("\PermissionUserGroup") ?

(hmm.. cool, i didn't realize the poll options are getting reversed)

It looks like #3 is closest to how the auth_user permissions work in Django, right? You define a group and its permissions, then declare that a user is part of that group. And then #4 would just be a matter of adding a person to the Moderators group for a perticular category.

I just know that my client is pretty picky in this area, and would always want the most complex control over things. :)

I don't see the #3 as a "real" Admin nightmare and I agree that maybe it's the "best" option for flexibility sake. I also believe that admin and moderators are necessary for any forum that can get big enough, and these improvements are necessary.

(btw: thank you Herbert for the fast improvements in forum. I just can see hot topic and images and it was proposed only days ago =D )

I agree! Thanks again, Herbert. Your quick additions are making my life a lot easier.

hehe, no problem - it just fitted my (imaginary) roadmap well :) (and i want to make a 0.3 release) especially since most of them are really basic forum features - slowly it actually starts looking like one ;)

as for the permissions .. my current favorite are predefined flags (3) plus a way to group users .. so administrators don't need to assign flags to every single user... but just add them to a predefined user group (this .. user group .. has of course be part of the community-'Group')
(and.. i made a typo in the poll answers.. i wrote 2 + \PermissionUserGroup - .. although it should have been 3 :| well .. i guess it is time to create a 'edit poll' feature ;)

What do you think about this organization + naming for permissions ..

An administrator [for a community Group] can create 'Roles' which part of a Group..
This role is basically a collection of predefined 'PermissionFlags' (like board_reply, board_postthread, board_annotate). django User objects are then added to these Roles by the admin.

To activate the assigned permissions the roles have then to be added to board categories.


An example .. I want to have a user who is allowed to annotate posts in the board. I would create a new role 'Moderator' and add the predefined role 'board_annotate' to it - and assign the given user to this role. Afterwards i go to the categories where the user should receive this permission and add the 'Moderator' role.

what do you think ? This concept could be easily used the same way for the wiki ..

That sounds good to me. At this point my client doesn't have much of a choice because the deadline is coming up very quickly.

Hey Herbert, any thoughts on how you're going to handle this? I need to know if I have to go in there an see what I can do to get things going for my client. Our deadline is approaching quickly! :)

Thanks.

i am currently implementing it as i stated in my last post .. i still have to think about how (or .. when) these roles would be "global" permissions .. and when they would only be active for a given board category .. it shouldn't take long for me to figure that one out :) .. if you have any additional requirements i haven't thought of yet .. now would be a good time to tell me so ;)