Players inherit parkour commands without the permission nodes.

[mibby]

It seems players are able to join parkour and use some parkour commands without inheriting any user permissions for it beforehand. There are no permissions in the plugin.yml with default: true inheritence, so I am not entirely sure why players are able to type parkour commands right out the gate without permission to do so.

[A5H73Y]

Given the nature of the plugin, most things shouldn't be locked down. There are many things you can implement to limit what a user can do, for example move Parkour to a different world and restrict access unless they're in the world, you can prevent joining a course via a command, forcing them to use signs to join.

[mibby]

Perhaps, but then what use are the permissions? For example, I would not want my guest rank to be able to join parkour. I'd like to delegate what specific parkour commands and features a user is able to use rather than them inheriting a bunch of things I may not want them to have outright.

[steve4744]

Then you need to negate the permissions you don't want players to have, e.g.
parkour.basic.join: false
then set it to true for ranks able to play parkour.

You could also set a minimum level 1 (or above) for all courses, and 'reward' your ranks with the level needed to play certain courses.

[mibby]

Why not make use of the plugin.yml instead of giving permissions outright in the source and requiring people to negate in their permissions plugin setup? It would be far more optimal and standard according to most plugins available and can default to true for the basic member perms with the option of setting it false inside the jar's .yml.

[steve4744]

Wherever the Permission is defined (in the plugin.yml or in the code), if you want to change the default value you still need to edit a file. I would think the permission plugin config is the standard place to do this.

If you change the defaults in the plugin.yml, everytime Parkour is updated you will need to open the jar and re-edit the plugin.yml to reset the permission defaults for you server.

[mibby]

While that is something I personally would have to do to disable the inherited defaults every time there is an update, it makes far more sense for permissions to be listed and set in the plugin.yml than to force it in the compiled source. As this helps cut down on unnecessarily long negated permission trees and recursive permission checks - both of which can be a small impact on performance with long permission setups.

It as well would provide an accurate and up-to-date list of permissions granted by default and wildcards available that can be used so players don't have to 'guess' what players have access to use / are given by default.

[A5H73Y]

Not entirely sure of what you purpose the change should be, setting the permissions in the config.yml? Isn't that the whole point of a permissions plugin to manage what permissions a player has, or am I missing the point? Sorry, it's been a very long time since I had a server with permissions setup.

[mibby]

Isn't that the whole point of a permissions plugin to manage what permissions a player has

You can delegate plugin permissions by creating a plugin.yml resource that specifies whether a permission node is granted by default to everyone, to OPs only, or set false so players have to specifically add permissions to their permission plugin groups to be able to use that functionality.

Parkour does not seem to use a plugin.yml to delegate permissions. It gives everyone permissions for things by default.

[steve4744]

It gives everyone permissions for things by default.

This is not correct.

A player without any specific permissions can only do the following with /pa:
join
leave
like
info
stats
lobby
perms
quiet
list
help

These are pretty much all of the "basic" commands shown when running "/pa cmds 1".

All the other commands for creating and configuring courses, giving kits, rewards, setting modes, creating/deleting signs, resetting courses, creating/listing/linking parkourblocks....all need a specific permission which will be false be default.

The correct place for these permissions to be managed is via a permission plugin.

[steve4744]

Having said that we could still register the permissions in the plugin.yml. Something like this (not guaranteeing this is 100% correct without testing):

https://pastebin.com/z5faE9Fd

[mibby]

A player without any specific permissions can only do the following with /pa:
join

Hence me stating it provides people permissions for things by default, even if they are 'basic' commands. I may not want guest members to be able to join parkour courses for example and limit it to only members. Which is why a plugin.yml to delegate permissions appropriately would be wonderful so I could manually disable the inherited defaults from within the plugin.yml myself. :)

[Flarkinater]

I came here to ticket this issue, and was surprised to see it was already discussed 4 years ago.
This plugin still defies common "permission convention" in several ways:

1. Permissions are always lower-case, but in this plugin each word is capitalized in the perm (small complaint).
2. Info for every command is visible within /pa cmds, whether or not the player has access to that command. This causes bloat - the players can see tons of info for things they'll never be able to use.
3. The player has access to certain commands by default, it's not documented which commands those are, and there's no way to negate those permissions. One example is /pa info

If all these things seem unnecessary to fix because players "should" have access to certain commands, then you're really underestimating the creativity of server owners. The plugin shouldn't be making assumptions about what the players need on behalf of the server.