TotalFreedom
Permissions support
Basically, my idea is that TFM would assign permission nodes to each admin based on their rank.
They could be something like this: tfm.super tfm.telnet tfm.senior
If no permissions plugin is installed, this would not affect anything. If one is, then the permissions.yml file can be used to set permission nodes for the above. This should be the easiest method of adding permissions support to TFM. It would open new possibilities for using plugins like PermissionsEx with TFM without requiring it be used or not.
Or the TFM could just be designed to be self-sustaining and not effect any other plugins, i.e. not executing player.setOp, but an alternative which only gives access to commands for the OP rank within the TFM. This means a permission plugin could have FULL control over all the other plugins (which use permissions to control what features are allowed or not) and allow things like the worldedit block blacklist to function without the plugin being modified, or disallow players to tp other players to themselves or tptoggle others.
Commodore, there are permissions plugins which can fully control permissions for ops, even overriding plugin defaults. What I am suggesting would allow easy integration with Permissions and TFM's admin system.
I like the idea. TFM would therefore act as its own permissions system, and thus improve the ability be hooked into as an API. (Also relevant: https://github.com/TotalFreedom/TotalFreedomMod/issues/1944). I don't see how this could be of harm, provided implementation is not costly.
Or maybe I'm getting at this from the wrong way, and you intend to replace TFM's permission system, and replacing it with the Bukkit permission system?
What I want to see is TFM be able to control permission nodes either directly, or indirectly (i.e. via aliasing with the Bukkit spigot.yml). If TFM could act as its own Permissions plugin where nodes can be assigned to Non-op (for someone who gets smited or not opped yet), Op, Super, Telnet, Senior that'd be ideal.
Also admins flagged as imposter should get non-op permissions instead of the admin. Either that or have an imposter group of permissions.
I dont see the value to adding external permission handling into TFM in any capacity myself. The entire point of TFM is that it handles all appropriate permissions its self, adding PEX or Group Manager to actually manage these permissions just seems cluttered and messy. If you're looking to use TFM in place of PEX or Group Manager, then thats a different story, but otherwise I dont see this being of any value, because it just undermines TFM's own permissions handling...
@Wild1145 Think he means using TFM in place of PEX so we can get rid of PEX.
@OxLemonxO That would be ideal. Controlling who gets what permission nodes is the end goal.
@Commodore64x @ChargedCreeper That is what I was trying to establish. Yes, I think that was always a longer term aim of the project so we could avoid having to modify some plugins too much. Currently any plugins can be modified to TFM handles its permissions if required.
I'm confused why we have to reinvent the wheel to make permissions work on a free op server. We don't have to override and remake every command. @ChargedCreeper If we just worked in a way to make the TFM compatible with other plugins without modifying them, or adding in repeat code into the TFM then we should do that, and as I see it there are ways to do that.
@Commodore64x That is what this issue is about. This is about allowing TFM to handle permissions for other plugins in addition to its own in-house permissions system.
@Wild1145 I know that, but why does the TFM need to handle permissions? There are an abundance of permission plugins out there that will be way more advanced than anything we could code with our current resources. The way I see it this is another logstick scenario - compared to CoreProtect logstick is inferior in every way, we risk repeating that and creating an inferior permission system where a much more advanced plugin could do the work. That isn't to say we don't need to modify the TFM - This is what I propose and it is much, much, simpler: Players are no longer technically 'opped' (Player#setOp()), instead they are 'added' to an op list which is stored as a YAML file, much like the admin list. The entries are: Ips, names, and rank. This has an added benefit of allowing titles or ranks like master builder to be assigned to ops and allowed for extended logging of op accounts and ips. Admins retain their op status and have access to all perms, anything that shouldn't be given to admins is blocked with the command blocking system. A plugin bridge is then created within the TFM for the selected permission plugin, its function to create 1 group and assign it perms found in the config. The group name is called "Op" and every time an opping/deoping function takes places this group is removed/added to the player. This effectively replicates the opping/deopping with Player#setOp but allows the permission plugin to control what permissions are given.
@Commodore64x What you are suggesting undermines the entire system we have for TotalFreedom, and breaks the fact we are actually all-op. Otherwise we can no longer claim to be all-op. A wide amount of other servers have tried to run things in that way, and they failed horrifically. You also roll back YEARS of development on TFM, and undermine the entire purpose of this plugin.
The Core Protect and Logstick argument is for another time, but your statement is grossly inaccurate. What you've done is moved from a lightweight system that does what it needs to do, to an exceptionally bloated system that adds MAJOR overhead to the day-to-day operation of TF that we did not want and did not need. Core Protect was never put through any sort of extensive testing and should never have been added.
What you propose will actually be far far more complex, and will break a lot of the current architecture of the server, requiring major re-writes across the board, and major configuration changes. I dont see that being in the best interests of this project.
@Wild1145 I agree, and my suggestion is designed to be in the best interest of TFM and the TF server as a whole.
Also, I will look into the permissions API.
@ChargedCreeper I have no issue what so ever with having TFM handle other plugins permissions, thats part of its purpose. I do have an issue with making TFM dependent on PEX or Group Manager, as that undermines the entire permissions system and current architecture that has been built on this plugin.
@Wild1145 I had taken that into consideration when making the suggestion. What I'm suggesting is for TFM to provide the same sort of functionality as PEX and GM (in terms of managing permission node assignment), not to depend on them.
Thats the problem here, 'some sort' doesn't cut it, I suggested a very valid method of working around this problem, the main tripping points seems to be the semantic of not actually getting player#setOp which makes no difference to player or admin experience anyway. I digress, what you are suggesting is overriding player#setOp which basically goes against how spigot was designed. Only trusted people are meant to have player#setOp whereas others get individual permissions. I am highly doubtful it is possible to override player#setOp but I will do some further research.
On investigating this I found this: "OP get all permissions unless specifically stated by the plugin's yml file". i.e. unless the command has default: false you can't block individual permission nodes for players that have setOp(true). The only solution that came close to what you want is this: The easiest way to do this would be to take op away from them, then give them the following permission nodes using /pex user <user> add <permission>: First, give them *. This allows them to "use" any permission node. Then, give them -essentials.vanish.*. This overrides the previous node, preventing them from using vanish. I really don't think it is possible to remove permission nodes from ops, but we will see.
@Commodore64x We may have to customise plugins. The intent here is to provide an actual OP experience. Otherwise we may as well trash TFM and move to Pex / GM and a load of shitty plugins, and wait a few days before people exploit it and elevate their own privileges... This probably wont be a simple issue, and we will probably need to continue to customise 3rd party plugins, thats just the nature of the type of server we have created...
@Wild1145 but according to Windows the whole idea of this is to remove the need to edit plugins.
@Commodore64x I cant see that being practical without removing the ability to actually op someone...
I originally misunderstood the suggestion. Removing the 'accepted' label. If after discussion it turns out this feature is desirable within TFM, we can readd the label.