[DONE] Groups and permissions refactor

[xoft]

I'd like to refactor the groups and permissions system; they need to be changed anyway due to the UUID changes, so I thought we might upgrade them in the process. This thread should serve as a discussion about the changes.

Currently, groups serve a dual purpose - to give players permissions and for the message visuals. They support (multiple) inheritance to make the setup easier and to allow for logical categories. A player can be assigned to multiple groups, the first group is used as the source of the visuals.

This system is slightly unintuitive for server admins. They want to be able to "rank" players - set them in a single rank where the player receives a well-defined set of permissions and visuals. When the rank is changed, the old rank should be completely forgotten and overwritten by the new rank - a player can only have a single rank.

Therefore, it would make sense to insert a new class type into the hierarchy: A single player has a reference to a single rank, which defines the visuals for the player's messages and a set of groups; each group defines only the permissions, possibly inheriting from other groups:

cPlayer <-> Rank <-> PermissionGroups[]

This will allow us to implement a simple well-defined "rank" command, plus a clear and concise way to specify permissions for each rank.

The underlying objects should have the following structure:

Player:
- Rank (by name)

Rank:
- Name
- Message name color code
- Message prefix
- Message postfix
- List of PermissionGroups

PermissionGroup:
- List of permissions
- List of groups it inherits from

The DB tables representing these objects should have the following layout:

PlayerRank:
- PlayerUUID
- PlayerName
- RankID (links with a Rank record)

Rank:
- RankID
- Prefix, Postfix, etc.

PermissionGroup:
- GroupID
- GroupName

RankPermissionGroups:
- RankID (links with a Rank record)
- GroupID (links with a PermissionGroup record)

PermissionItem:
- GroupID (links with a PermissionGroup record)
- Permission


Additionally, the Rank and PermissionGroup objects will be managed by a cRankManager class. It will load the ranks and groups on server startup, will provide API methods for managing them, and will provide each cPlayer with the resolved rank and permissions. The storage will be most likely in a SQLite database, the data structure is no longer easy enough for simple text files, instead, a plugin (the Core?) will provide commands and webadmin UI to manipulate ranks, groups and permissions.

The final part will be implementing hooks so that ranks, groups and permissions can be provided by external plugins. This will allow plugin writers to create plugins that store the permissions in an external database, possibly sharing the DB with an external system, such as we-based eshop for the server.

Thoughts?

[archshift]

Sounds like a good idea to me!

[bearbin]

Only thing I want to say - if you have multiple permissiongroups per rank, what's the point of having permissiongroups inherit others?

Otherwise, looks great.

[xoft]

True, it's somewhat duplicating solution to the same problem. I thought server admins like groups with inheritance, that's why I automatically put it in.

I'd like to hear some feedback from someone who runs a server and has some experience with this, would this style of setting permissions suit your needs? If not, what would you add / change / remove?

[tonibm19]

I like actual permissions system, I would stay with it.
If changing, the one you proposed seems good, it's just I don't think permissiongroups are necessary.

[xoft]

The current system has problems - each group defines the player color, so which one to choose if the player is in multiple groups? And how do you implement a "/rank" command, does it remove all groups and add only the single group given?

So how would you assign permissions then? Directly to ranks? That will be a lot of work without groups - many ranks share subsets of permissions, you'd have to add each subset to each rank, instead of having it grouped and only reusing the group.

[tonibm19]

I would allow only one rank for player. A player doesnt need to be admin and mod at the same time, or VIP and mod.

[xoft]

Of course, that's already written there. But to define the permissions for the rank, you can use groups. So you can have a group "WorldEditSaveLoad" and add that group to admin and mod ranks.

[tonibm19]

Ahh, now I understood, that could be usefull.

[AntherusCraft]

I think it's a great idea to make the rank system more "definable" so you have more options for each group. In my opinion it is also useful to seperate the permission groups and the groups themselves so you can easily instead of extending groups list permission groups, thats definetly more clear. Another usefull feature would be to be able to manage the groups per command ingame, for example if your an admin of a server but you don't have access to the console/vserver/root or whatever you couldn't manage the groups. 2 commands are enough, one for the groups itself and one for the permission-goups, like so:
/group [add/remove] [Group/MessageColor/Prefix/PrefixColor/Permissions] [Groupname/Color/Prefix/Color/PermissionGroup]
/permission [create/add/remove] [PermissionGroup] [[Permission]]

and then of course the /rank command to give someone a rank.