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?
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?