This is about the permission system I designed for my Acmlmboard branch (Acmlmboard 2.064).


Permission set shrunk down to the basics

All while still giving enough control of course (you'd be better off using powerlevels otherwise). But for example, we reduce the level of control for cases that aren't needed. Forum moderation permissions are merged into one 'moderate forum' permission, because you will rarely ever need more control over it.

There are no permissions for things like 'view the registration page', 'view the login page', etc... Those things don't need permissions, it all boils down to checking whether the user is logged in.

There are no separate groups for guests and bots. Those get the same permissions as normal users (minus things that require login). It's probably less flexible in restricting what bots can access, though.

The core permission set comprises 17 permissions. Compare that to Blargboard and its 45 possible permissions.


Groups and shiz

Here is how permissions are computed.

First, we take the user's primary group permissions. Second, if the user is in any secondary groups, these groups' permissions can extend those of the primary group. And finally, the user's permissions can restrict the final permission set.

Primary groups also have 'deny masks' that forcefully restrict the final permissions. The use is for example, for a banned user group, so banned users have all their permissions properly revoked even if they belong in secondary groups that would give them permissions.


Compact storage

The Blargboard design took one table row per permission per group/user/forum.

The new design stores permissions in the form of bitmasks. It only takes one table row to store all the permissions for a given group/user/forum, and the final permissions of the current user are computed quickly (really just a series of logical operators).

A downside is that this makes editing permissions via PMA more involved.

____________________
Kuribo64 - melonDS

want some revolution in your coffee?

Global mods may eventually get ability to ban people, and perhaps edit but I don't think so.


It works like for Blargboard. Each group is given a rank value that works kinda like the powerlevels but more flexible. So basically, you can't edit a user if his primary group's rank is higher than yours.

This also prevents things like editing yourself to give yourself more power, and other fun privilege escalations.

____________________
Kuribo64 - melonDS

want some revolution in your coffee?

As Squiddy said. This is my own design, AB2.5 doesn't have to follow it or anything. I'm just providing it for the sake of providing ideas.


The thing about "letting a user edit posts but not move them out", well, in most cases, you will either want your moderators to have all the possible moderative permissions, or you won't care about that. It may have uses though.

But then there is also the part where you're supposed to be able to trust staff members to an extent. If they do stupid shit, you demote/ban them.


As for the guests vs users part. I find it silly to require registration for things like viewing forums or viewing extra pages. Unless registration has an entry barrier (like requiring a specific reg password), each guest is only a few clicks away from becoming a user. Forced registration annoys people and gets you a ton of worthless accounts. This is the main logic behind giving guests the same permissions as normal users.

Of course, there are admins who will want to do those things anyway. But I find them silly.

____________________
Kuribo64 - melonDS

want some revolution in your coffee?

Don't be hard on yourselves guys, flexibility is always good. The real challenge is creating an interface that exposes all of the system's power and doesn't suck.

____________________
Kuribo64 - melonDS

want some revolution in your coffee?