PermissionsManager and DefaultPermissionsProvider improvements

[OMEGA3065]

Provides new methods which can be used to interact with the PermissionManager and DefaultPermissionsProvider in more ways without the need for publicizing the assembly.

This PR was made because of a suggestion: #424

The changes made to the PermissionManager are mostly QoL with 1 exception.
List of changes:

• RegisterProvider<T> using Activator.CreateInstance even though the type argument was specified as supporting a parameterless constructor. Modified code so instead of using Activator.CreateInstance<T>() it uses new T().
• GetProvider(Type type) which allows to get a provider even if we only have it's type object (runtime) as provided by GetPermissionsByProvider
• TryGetProvider<T>(out provider) -> T which allows the caller to automatically have the returned type be the type provided as an argument.

The changes made to the DefaultPermissionsProvider allow for more interaction concerning obtainging full lists of permissions provided by a UserGroup and allowing for runtime registration of .
List of changes:

• RegisterProvider<T> using Activator.CreateInstance even though the type argument was specified as supporting a parameterless constructor. Modified code so instead of using Activator.CreateInstance<T>() it uses new T().
• GetProvider(Type type) which allows to get a provider even if we only have it's type object (runtime) as provided by GetPermissionsByProvider
• TryGetProvider<T>(out provider) -> T which allows the caller to automatically have the returned type be the type provided as an argument.
• GetPlayerGroup was made public
• GetPermissionGroup was added to allow the caller obtain the PermissionGroup based on a string UserGroup registry name.
• GetPermissions was made public
• AddPermissionGroup was added to allow the caller to add / override existing groups.
• RemovePermissionGroup same reason as AddPermissionGroup` but for removal of groups.

[OMEGA3065]

I might respond faster if receive a ping in the discord: <@799984967227670529>

[davidsebesta1]

Nice work, but needs some changes. Could you please also include link to some testing plugin code?

[OMEGA3065]

@davidsebesta1 Made a simple ish plugin which covers most of the changes.
https://github.com/OMEGA3065/PermissionTest

It requires Axwabo's CommandSystem plugin (I am sorry but I am never using the vanilla system again)

You can use the commands:
ggp - lists perms of a group supplied as arg
gmg - combines roles into 1 multirole to provide all perms of the subroles (uses inheritance)
rmg - removes your custom group -> note this only removes the default provider group and not your actual UserGroup
apmg - adds permissions to a specified permission group, pretty sure labapi has this somewhere built-in but it's whatever
cperms - lists all your permissions for each permission provider you have, good for checking what perms you have on the DefaultPermissionProvider

Some screenshots: (note I started of with having the rank8 so I can access console)

[davidsebesta1]

Much better 👍
Make sure you also add the methods you added to DefaultPermissionProvider to IPermissionsProvider too

[davidsebesta1]

Id make this false by default and add it as optional param to constructor

[OMEGA3065]

If the caller is allowed to do this without the knowledge of what the flag does, they could end up overriding their config files and will be unable to modify the PermissionGroup after it's creation.
If you think this behavior is fine, I can of course change it.

[OMEGA3065]

If the caller is allowed to do this without the knowledge of what the flag does, they could end up overriding their config files and will be unable to modify the PermissionGroup after it's creation. If you think this behavior is fine, I can of course change it.

What I mean by "do this" is change the value of the IsRuntime property.

[OMEGA3065]

@davidsebesta1

Much better 👍 Make sure you also add the methods you added to DefaultPermissionProvider to IPermissionsProvider too

My intent was not to create a breaking change since anybody who has a custom IPermissionProvider would need to change their code if I added new methods. I could create a new interface with these runtime methods which would prevent the issue as far as I can see.

[davidsebesta1]

My intent was not to create a breaking change since anybody who has a custom IPermissionProvider would need to change their code if I added new methods.

15.0 will have major breaking changes and we do not have any more updates planned before that. You are good to make these changes

[OMEGA3065]

My intent was not to create a breaking change since anybody who has a custom IPermissionProvider would need to change their code if I added new methods.

15.0 will have major breaking changes and we do not have any more updates planned before that. You are good to make these changes

I found another reason against this change. I currently have a custom IPermissionProvider which doesn't use PermissionGroups in any capacity. All of the new methods do in fact use PermissionGroups and as such would not fit in very well. Again I could maybe make another interface with these methods, but I am not sure how useful this would be.