Permission "wild.wildtp" grants permission to use wild on EVERY world using the command /wild while being in that world or using /wild followed by any world specified.
Even explicitely setting wild.wildtp.aworldname" value to false, "aworldname" can still be used either in the command /wild aworldname or left out and a player can use /wild while in the world of that name.

In fact, the only time I seem to ever get the "You don't have permission!" message is when I remove permission to "wild.wildtp" itself. If I remove that permission then a world must always be specified when using the command, since no one knows to do this it is assumed broken at this point. What is interesting is that although I may explicitely set certain world names as NOT allowed, every single one world name will work in this command and it will NEVER say "You don't have permission" as long as a world name is specified when the command is given.

This is with version 2.19

I'm assuming you've configured (or your permissions plugin does so by default) to grant all child permissions of a parent permission?

Bukkit has no concept of child or parent permission nodes, or nodes at all. Just Strings. So unless there's something wrong with the command handler's logic, this is actually being caused by the permission plugin.

Even if that were true, explicitely denying permission to individual child nodes - even if the parent node permission has been granted - it would not allow the action granted by that child node. Since it is still allowing the action by the child node, there is sumething up with this plugin where it is not verifying the child node is permitted. The permissions plugin (LuckPerms) can verify that the user does not have permission to the child node (wild.wildtp.someunauthorizedworld), wildtp should also know that, but doesn't... since it's only checking to see if the user has permission to "wild.wildtp".

There is an option for LuckPerms which causes all child nodes of a parent node to be not allowed unless it is explicitely granted elsewhere. Although this has unexpected harsh functionality with other plugins that don't need such a restriction to work properly under normal conditions, it did not benefit wildtp in any way. Wildtp continues to completely bypass checking for the permission to be used within the world even though it has been explicitly denied as well as denied in general by using that option in LuckPerms. WildTp is not verifying the user has permissions to use the wild tp command in the world they are using it in, it is just that simple.

there is sumething up with this plugin where it is not verifying the child node is permitted.

All it does is a Bukkit hasPermission check. There's another issue where I have added debug messages to check permissions for another command, so if you could test that that'd help. #76

yes but it is not checking for "hasPermission" to the world that the player is actually in (wild.wildtp.worldname) when they use the command... rendering the permission useless. I can verify they do not have the permission, I can also verify the command is run on them anyway. Also it gives the "wait" message 3 times in a single use which is also abnormal, I'm sure.

https://pastebin.com/jSUbS9it -- debug log.

Oooooh just re-read your original post. What you want to do is different then. That command/permission is different, that specifies the worlds they can teleport to; If you don't want players to use /wild in some worlds, deny wild.wildtp in those worlds via per-world permissions.

Why can't you just make your permission work instead of making me use some hacky work-around that no plugin EVER has needed me to utilize. When a user does not have permission to wild.wildtp.someworld, they simply should not be capable of doing so. I should not have to go out of my way to ensure this works, I should know that by not allowing the permission, they do not have the ability to do it. What is the point of this permission node if your plugin is going to continue to ignore it?

That is how I have it setup for mine, I only allow players to go /wild from mall.

Why can't you just make your permission work instead of making me use some hacky work-around that no plugin EVER has needed me to utilize.

This is not a hacky workaround - this is how permission plugins work? If you want players to only have a permission in a specific set of worlds, then you configure the permission to only be applied in that world via the permission plugin. For luckperms, if I recall correctly, the only thing you need to add along with your standard set of commands is to append world=<world name>

wild.wildtp.world.<worldname> is only used to define permission to input the command /wild <worldname>. It is not to prevent use of /wild

Just to clarify my mistake here, what you're attempting to do here is not similar to #76 at all. (The user there is using the correct permission for his needs, i.e. restricting what worlds can be inputted to the /wild <worldname> command.)

I do not want to have to manually provide permissions to every player via command by amending the "worldname" to the command, that is ridiculous, and this is the only plugin that doesn't have permissions per world already built in... except that you do have permissions per world already built in, you just ignore them, which makes no sense. There is a hacky work around method for applying per world permissions which would load individual rulesets for every user as they join, bypassing all caching and speed up that normal permissions get... and I could do it this way so long as I commit to override the permission for every user on join to every world other than the one I want disabled, which is a lot of nonsense to do over a plugin that isn't cooperating with it's own permission's node. If the user is in a world, they should necessarily have permission to wildtp.wild.worldtheyarein whether they are using /wild or /wild worldtheyarein as the command since no one is familiar with that use of the command. I have never seen a user on my server attempt to specify a world when using this command. While it is stated on the plugin page, users with general working knowledge of this plugin don't know about it or simply don't use it since stating the world you're in as part of the command is redundant. The plugin should be checking for the permission in either case, or there isn't a point to it.

I do not want to have to manually provide permissions to every player via command by amending the "worldname" to the command

You don't apply this to every player manually. You do this when you add the permission to the group. I haven't modified permissions for a while so I'll dig up the command...

via command by amending the "worldname" to the command

users with general working knowledge of this plugin don't know about it or simply don't use it since stating the world you're in as part of the command is redundant.

The /wild <worldname> command is different and not for your use case! Some other admins want to provide players a way to specify which world to TP to - and from what I understand, this is not what you want to do.

/lp group default permission set wild.wildtp world=mall

yes it's absolutely essential this permission exists or users would be able to use wildtp to bypass their permission restrictions to access the worlds in some other way using your plugin. But your plugin should still follow that permission if they already have access to the world and just shouldn't be able to use wildtp there. The permission node existing at all suggests that your plugin will be compliant when it is allowed or not..

and yes i can work around the shortcoming by doing something like:
/lp group builder_global permission set wild.wildtp false world=pvp
i still think it should be enough to have denied permission to wild.wildtp.pvp. Thanks.

The permission exists for the command /wild <worldname>. The /wild command by itself can be configured to randomly TP to a different world (see randomWorlds in config), so there are different use cases for these two commands.

• In my case, I only want players to go /wild from a specific world.
  • I grant the group wild.wildtp with context (condition) being world=mall.
• The OP in #76 wants players to go /wild <worldname> from any world, but only to specific worlds.
  • He needs to grant multiple permissions in the format wild.wildtp.world.<worldname>
• In your case, you want players to go /wild from any world except from the PvP world.
  • Basically what you commented above, granting wild.wildtp except in the context where world=pvp. The way you proposed is a valid way (you grant everybody to wild.wildtp and then deny wild.wildtp in context world=pvp)

If your case is you wanted to prevent players from performing /wild pvp then that idea (denying wild.wildtp.pvp) would be the way to do it. Otherwise, yes, denying the permission in that world is the right way to go about preventing use of the /wild command in that world.

Yes assigning the permission in context gets the job done, but the permission node existing as well as being ignored means players have access to worlds they would not normally have access to simply by specifying the world in the command. I have to explicitly deny access to each individual world they should not be able to visit as well as to every world I don't want /wild used in. But since /wildtp is an all inclusive command and is allowed everywhere by default, they can still do this in worlds they can visit even if they should not be able to use /wildtp to get there. I'm not arguing something different here, but I can't think of any case other than exploiting the security flaw this opens up that you would want to NOT verify the user has permission to "wild.wildtp.world" prior to allowing them to /wild while in world. All this does is allow them to use wildtp in world they can't /wildtp world to. Why would that be desirable in any way? I understand the need to make it so that a user can't bypass their own world permissions by using wildtp to get to worlds restricted from them... but I can't comprehend why you'd still want them to use the main command if they got their via other means. If they can get there via other means, then there's no problem with them using the command... why wouldn't they already have access to "wild.wildtp.world"? why would I want to prevent that if I wanted them to still use /wild once they got there? Your use scenario seems a bit more primed for contextual permissions than mine does. You could grant a person wild.wildtp.someworld permission while only in a particular world and still make that work even if you made the change I'm suggesting. The #76 example - while doing something slightly different, would not need to change their approach in any way since the individual world permission nodes have to still be there and set in either case. Default use and set up of the plugin - however - should probably be on the side of verifying the user has permission to use the command in the world they are in, not assuming that they should be able to use the command if they are in a different world and just know that the command will accept the argument of a world name (which virtually no users realize). I just don't believe this is intended behavior at all and I can think of no exception where that would actually be desirable. If you only want it allowed to be used within a single world, I agree that a contextual permission is the way to go. But I don't think preventing it from being used in a single world should have the same sort of set up... since you have the permission node available to look at, I think it should be checked when /wildtp is used.

but the permission node existing as well as being ignored means players have access to worlds they would not normally have access to simply by specifying the world in the command.

Again as I mentioned prior, this is a different functionality.

Btw, I don't have any other wild.wildtp permissions assigned and I'm unable to do /wild <world> from the mall world so I don't know what the rest of the wall of text is about. Using version 2.19-b705f92 as per /version wild

https://luckperms.net/editor/MLl7T9e6Qu if you're interested in my permissions setup.