Perm tree of unassigned permissions
mareksipos93 opened this issue · 24 comments
Hi,
I really like the ability to show the tree of permissions requested by plugins. It's super nice for server admins.
I would like to request new function.
Add an option to filter the tree and show only those permissions which are assigned to nobody.
Why?
Well let's see that player or admin tries to do something - for example run a command and error message is shown - Not enough permissions.
Server admin could just generate filtered tree and see which permissions are not assigned but were requested.
Very often there are cases of requested permissions which are not properly documented by plugin author. And server admin would be able to assign even those undocumented permissions.
Thank you
You can use the Verbose feature of LuckPerms for that. See the wiki page about Verbose for more information
But I don't need permission for exact command, I want to see all denied commands of players and add required permissions to server. Players dont usually report when some command was denied for them. They just keep playing :)
Example:
Server runs for 5 days. Players are playing. Server admin added all documented permissions from all plugins... but sometimes something doesn't work because it needs extra permission which was not documented.
And that's where filtered tree would be super useful. Admin just can from time to time generate filtered tree and add all missing permissions.
if it doesn't work you can use the verbose feature as mentioned above to see what permission is missing. don't just add permissions just to add them.
Then you need to advise your players to report if something doesnt work or is a feature request.
I did of course, and lot of server admins did as well, but we cannot change player's mind. And that's why there is this suggestion. But if you decided ahead to deny it, then it's okay, just close it. It will be much better than finding reasons why to NOT implement this. :)
This suggestion is 3 days old. Instead of finding unnecessary reasons why to NOT implement this you could have it already implemented as new feature of LuckPerms.
Basically what we need is to
- Add new flag for tree command
- If that flag is used, only those items will be added to the tree, which are not assigned anywhere.
Once that player logs in you can monitor the perms being used to see what doesnt work as intended.
I agree with that, but for that I need this required functionality.
if it doesn't work you can use the verbose feature as mentioned above to see what permission is missing. don't just add permissions just to add them.
Verbose is not an option as explained above. I cannot verbose command or functionality player tries to use, because I mostly don't know that players try to use them.
The reason is not to "just add permissions" - the reason is to make all potential functionality available to players (if appropriate).
Example: imagine that plugin 'residence' has some flag that is actually very useful - but not documented.
Player coming from another server has used that flag before, he comes to new server, tries it and - it doesn't work, because server admin didn't know about it. And player leaves.
With filtered perm tree server admin would just check it and see - oh, there is permission from residence that I didn't know about and added it yet! And he adds it - so future players will be able to use that feature.
You can specify a player for /lp tree. Then LP will calculate each permissions known to it for that player. That will naturally also show all unassigned permissions.
Don’t know for sure but the command should be /lp tree . <user>
You can specify a player for
/lp tree. Then LP will calculate each permissions known to it for that player. That will naturally also show all unassigned permissions.Don’t know for sure but the command should be
/lp tree . <user>
I'm sorry, but how is that related to what I need?
I don't know which player tried to use functionality which was denied because of missing permission.
Also I don't want to traverse whole tree - I want to show unassigned permissions ONLY - that's the point.
My suggestion shows the calculated value. Meaning you can see if a permission is true, false or unassigned. At least for a single player. That's pretty much half way already.
It's not, sadly. Each permission may be assigned to someone else / some other group, so it doesn't help at all. It would be even worse than plain tree.
Man. That sounds like a seriously messed up permissions setup. Utilizing inheritance will certainly help that mess.
I'm using inheritance. Some permissions for player are false in some worlds and then they are overriden by true permissions for admins for that world. How is that messed up may I ask?
Example: /kit command is disabled for players in minigames world, but it's enabled again for admins because they inherit from players.
Still don't understand how is that related AND I don't think that you understand what this suggestion is about anyway - because then you wouldn't suggest things that are not related at all to what am I asking for.
You want to see unassigned permissions. Which can be done with /lp tree. You can't see globally unassigned permissions.
Nobody can. And that's why there is this suggestion.
Another example: today in the morning one player asked me why they are not allowed to remove all flags from residence plugin using /res clearflags.
The permission is residence.command.clearflags and was nowhere documented. I was even not aware of this command.
With /lp tree showing only unassigned permissions this would solve the problem. I was lucky this time because one of my players actually told me that something is wrong. But who knows how many players tried to use that command before and how many commands are still unavailable to players from all plugins...
Manual traversing the whole lp tree is really painful, because it needs to be done frequently as new permission invocations may be added over time.
In that very case you could have used /lp tree . <player> and seen which permissions related to /res they have and which one's they don't. Assuming the permission nodes of the plugin the command belongs to start with xxx, you can also do /lp tree xxx <user> which only shows a subtree. The case you described is exactly where using that version of the tree command is most useful for.
I know - I've solved this. But that's one specific case where player actually reported that he has a problem - and that's very rare.
What would you use as arguments for /lp tree <scope> <player> if that player didn't report that command /res clearflags doesn't work for him?
You wouldn't know scope NOR player. And you are left with basic /lp tree. And that means manually traversing the whole tree repeatedly over time. There is no other way.
With my suggestion you would just generate filtered tree, see which permissions are not assigned to anybody and immediately see potential issues.
Regarding the player problem, you can use any player in the group you're trying to debug.
The thing is, the functionality is not in the plugin. And likely won't come because in all honesty, it's fairly specific and I don't think the effort needed to implement it is worth the result.
But that's not my decision. It's up to @lucko to implement it or not.
Now with these suggestions, I'm trying to show you alternatives. Which you seem to happily reject. Which begs the question how important the thing is for you after all. Because if it really was, you'd be more than happy to have at least some way to somewhat get what you want.
Regarding the player problem, you can use any player in the group you're trying to debug.
The thing is, the functionality is not in the plugin. And likely won't come because in all honesty, it's fairly specific and I don't think the effort needed to implement it is worth the result.
But that's not my decision. It's up to @lucko to implement it or not.Now with these suggestions, I'm trying to show you alternatives. Which you seem to happily reject. Which begs the question how important the thing is for you after all. Because if it really was, you'd be more than happy to have at least some way to somewhat get what you want.
That's not true. Right now I'm using just plain /lp tree and checking the whole large tree by myself, but it's not acceptable in the long run.
I'm refusing your suggestions because they are not relevant at all. I want to show ONLY unassigned permissions, not all permissions invoked by that player or group.
I understand what you're trying to say and I feel like it could be a fairly easy task to complete.
Generate a list of all cached permissions, generate a list of all assigned permissions, remove all assigned permissions from cached permissions, bam, there's your list of unassigned permissions.
This could potentially be done on the web editor, I will make a note to try this in the future.
Thanks for the suggestion.
Brainstone's idea about using player scope in the tree command is a good one - it's what I would've suggested.
At least that way, it highlights really clearly which permissions are missing, so you don't have to go through the whole thing guessing.
Already, that's miles better than any other plugin offers! Not much to complain about there, ay?
I'll keep this idea in mind, however, it's probably not going to be a high priority item as it's quite a niche request. Hope that makes sense & you understand where I'm coming from!
Thanks for the suggestion.
Brainstone's idea about using player scope in the tree command is a good one - it's what I would've suggested.
At least that way, it highlights really clearly which permissions are missing, so you don't have to go through the whole thing guessing.
Already, that's miles better than any other plugin offers! Not much to complain about there, ay?
I'll keep this idea in mind, however, it's probably not going to be a high priority item as it's quite a niche request. Hope that makes sense & you understand where I'm coming from!
Excuse me but how is using player scope good idea?
It will just generate tree of all known permissions for one player... but I don't know which player tried to use functionality with missing permission. Also I would still have traverse the whole tree.
It's a good idea because it separates the permissions in the tree the player already has from the ones they don't have.
If it's a specific command / functionality you're trying to find the permission for, then the verbose command is better suited.