Through discussion in previous months on the discord, I think(?) the idea of supporting Bukkit-style permissions natively. We must, of course, additionally support the Vanilla-style OP system since it is actually weirdly a part of the protocol. This issue outlines our steps forward in implementing this feature, considerations, and future steps to complete it.
Now
Our priority is to get something we can build on later, and this suits that need pretty well. The process of updating it shouldn't change much in existing usage of the permissions registry, which is a good sign that this path forward is the one to take.
The permissions system will involve two main parts:
The permissions registry which holds all information from the perms.json file after load-time (at the beginning of the server's execution or after some form of reload command). This is just a cache of the file on the disk already loaded into structures that will allow for easy querying.
The component that is attached to all Player entities that stores their permissions.
Additionally, something similar to these types will be used to store permissions:
pub struct VanillaPermissions {
/// The OP level
level: u8,
/// Whether the player bypasses player count limits
bypasses_player_limit: bool
}
Haven't figured out how to name this struct though
pub struct FooPermissions {
/// A map of permission keys to values
permissions: HashMap<String, String>
}
This is the struct that will be used as a component.
There needs to be chaperone types to serde the permissions, but that's straightforward.
The registry type can be whatever works, probably something like a HashMap<Uuid, CombinedPermissionsStorage>.
It's important to maintain compat, so OP level should be saved to the ops.json file.
The op level should have a magic key minecraft.opLevel or similar that causes it to be written into the vanilla permissions instead of the bukkit-style system.
For now, permissions should be able to be queried, added, loaded on server load, saved on player leave (at a minimum)
Soon
The things described in this part of the issue are things we need to do soon, but aren't requirements (nor should they be added) for the first implementation of the system.
Higher priority:
[ ] Typed permission values
[ ] Quill support for permissions
Lower priority:
[ ] Commands to query permissions information
[ ] Utility trait to make querying permissions easier
Through discussion in previous months on the discord, I think(?) the idea of supporting Bukkit-style permissions natively. We must, of course, additionally support the Vanilla-style OP system since it is actually weirdly a part of the protocol. This issue outlines our steps forward in implementing this feature, considerations, and future steps to complete it.
Now
Our priority is to get something we can build on later, and this suits that need pretty well. The process of updating it shouldn't change much in existing usage of the permissions registry, which is a good sign that this path forward is the one to take.
The permissions system will involve two main parts:
perms.json
file after load-time (at the beginning of the server's execution or after some form of reload command). This is just a cache of the file on the disk already loaded into structures that will allow for easy querying.Player
entities that stores their permissions.Additionally, something similar to these types will be used to store permissions:
Haven't figured out how to name this struct though
This is the struct that will be used as a component.
There needs to be chaperone types to serde the permissions, but that's straightforward.
The registry type can be whatever works, probably something like a
HashMap<Uuid, CombinedPermissionsStorage>
.It's important to maintain compat, so OP level should be saved to the
ops.json
file.The op level should have a magic key
minecraft.opLevel
or similar that causes it to be written into the vanilla permissions instead of the bukkit-style system.For now, permissions should be able to be queried, added, loaded on server load, saved on player leave (at a minimum)
Soon
The things described in this part of the issue are things we need to do soon, but aren't requirements (nor should they be added) for the first implementation of the system.
Higher priority:
Lower priority: