Permissions Permission structure
 

We all know that in its current state, its a headache to manage the permissions in a board with a dozen usergroups and hundreds of subforums. The current backend of forum permissions is very mature and works very well as it was designed (not so much the admincp front-end). But at some point of the refactoring and modernization of vb, it'll have to be changed to make it easier to us to manage all the growing complexity of our communities.

Problems of the current system

A.- Due to the insane amount of permissions, it's extremely easy to give some unwanted permissions (even vb.com did that mistake once). When adding an ew usergruop, the safest way is to use the function "Create Usergroup Based off of Usergroup", which pretty much creates a copy of an existing group (for instance, registered users) and lets you customize it. But future changes to the base group would not be transfered to the "child" group, so you'd have to manually edit every existing group.

B.- It's impossible to remove permissions granted by a usergroups, except by removing the user from that group. For instance, if you let all your users upload attachments, but an user abuses the system, you are forced to create a new usergrup that has the same permissions as "registered users", only removing the related to attachments.
The other way would be to use infraction groups. But that is not flexible enough, since it's only determined by infraction points not by infraction type. For instance, both an infraction due to abuse of attachments and another one due to abuse of the blog could be worth the same amount of points, but the first one should lead to a "no attachments" group and the second one to a "no blogs". As of now, it's impossible to do so.


Suggestion 1: Inheritance

The first suggestion is to use an inheritance system pretty much as the style system. That is, every group could have a parent. If a concrete permission is not set in a given group, in inherits the value from its parent group.

This would solve most of the aspects of problem A. However, it does not address problem B; we'd need some overhaul of the infractions system.


Suggestion 2: Three valued permissions

Instead of using binary yes-no permissions, there should be three possible values:

- Granted
- Not granted (not set, neutral, or whatever you want to spell it)
- Forbidden

If a user belongs to a usergroup that has a given setting as "forbidden," he or she is automatically forbidden that permission, independently of the value in his/her other groups.

Otherwise, if a none of his/her groups forbids that permission, the most permissive setting applies (like in the current system: yes = granted, no = not granted).

When creating a new group, everything (usergroup permissions, forum permissions, CMS, blog, everything) should default to "Not granted." That way, you don't need to worry about granting (or forbidding) unwanted permissions. You know that the group would be neutral to everything you don't change on it. This pretty much tries to solve problem A.

This setting would allow us to create "No blogs", "No attachments", etc. groups that have neutral values to everything, but are set to negate the appropriate permission. This solves problem B.

With this approach, we could also get rid of the "This Usergroup is not a 'Banned' Group" setting, that is very hard to understand to new vb admins. The infraction system would only need to introduce the user in the appropriate group which has some permissions set as forbidden (and remove him/her after the infraction expires).

The biggest drawback of this structure is that now permissions are no longer bit fields, but we'd need at least two bits for every permission. I don't think it should be a problem in terms of db size, but it might need a lot of programming changes.

If I had to program this (and I'm not pro at all, only a begging amateur), I think it should be possible to retrieve everything with a single query, perhaps with some GROUP BY statments and some MIN (to check if there is some forbidden) and MAX (to check for granted settings) aggregate functions. I have no idea if this would be scalabe and efficient, but I'm sure the gurus at vb team can come up with much better ways to do it.

Also, note that this is not incompatible with suggestion 1, tho the need for inheritance would probably be smaller.


And the UI

The admincp interface also needs some serious workout. That's why I also support suggestions from this thread. For instance, we absolutely need:

• A way to see all the forum permissions of a given usergroup.
• A way to see all the permissions of a given forum for all the usergroups.