1.19.2: Wildcard permissions for chatcolor not working

[TZ122]

"/version ChatControlRed" - plugin version

10.16.2

Are you using MySQL?

Yes

Are you using BungeeCord?

No

Error log (if applicable)

No response

"/chc debug" output (strongly recommended)

Sent via email

Information about the issue/bug

Hello! I am using GroupManager which supports wildcard permissions. I would like to grant my players to use hex color and colors in their suffix tag.

I have tried granting: chatcontrol.color. chatcontrol.hexcolor. chatcontrol.use.color.suffix

However when I use chatcontrol.color.red for example it works.

Apply_On: is set to suffix

• 'suffix'

I have also tried '*' which would still not allow me to use the colors.

Is there a separate permission that can grant this? Unsure as to why the above setup isnt working

Thanks!

[kangarko]

Hey and sorry for the delay,

I test permissions using LuckPerms and was able to set any suffix, including any hex color and normal colors:

Would you be able to run a test with only these permissions?

default:
  permissions:
  - chatcontrol.command.ignore
  - chatcontrol.command.ignore.list
  - chatcontrol.color.*
  - chatcontrol.hexcolor.*
  - chatcontrol.use.color.suffix
  - chatcontrol.command
  - chatcontrol.command.*
  - chatcontrol.command.tag
  - chatcontrol.command.tag.suffix

I was testing in the game using /tag nick #COLORCODE, let me know if you found the bug in another way.

[TZ122]

This is with the set permissions above: https://imgur.com/nY9VmT8 Unfortunately I still seem to be encountering the issue

[kangarko]

Can you please try clearing your rules/tag.rs file? Make it empty. Perhaps there's a rule blocking the colors maybe?

PS: I see the "unknown" error in command highlightning, this is I believe solved by giving the general "chatcontrol.command" permission or "chatcontrol.command.tag".

[TZ122]

I have removed all the rules and regenerated the files to default. I have also added both the chatcontrol.command and chatcontrol.command.tag so that my permissions look like this. However the color still strips from the command. (It works as an operator, however not with the * permissions)

Default: default: true permissions:

• chatcontrol.channel.autojoin.local.write
• chatcontrol.channel.join
• chatcontrol.channel.join.global.write
• chatcontrol.channel.join.local.write
• chatcontrol.color.*
• chatcontrol.hexcolor.*
• chatcontrol.use.color.suffix
• chatcontrol.command
• chatcontrol.command.*
• chatcontrol.command.tag
• chatcontrol.command.tag.suffix

[TZ122]

I have double checked with the groupmanager developer who has let me know that as long as they are registered permissions should work. Unsure why this seems to be only happening with chatcontrolred permissions + groupmanager

EDIT: tested this against luckperms worked for me however would love to use my standard perm plugin with this^^

[kangarko]

I am so sorry, if that works with LuckPerms then it's likely that GroupManager does not recognize the star permissions. I have no idea how to register them, we do not register permissions anywhere in the plugin, all we do is simply check if the player has the given permission.

[TZ122]

I am so sorry, if that works with LuckPerms then it's likely that GroupManager does not recognize the star permissions. I have no idea how to register them, we do not register permissions anywhere in the plugin, all we do is simply check if the player has the given permission.

Understood thank you. Is there perhaps another solution so that I am able to use this as a compatible plugin?

Is there a permission to grant all color codes without the * appended?

[kangarko]

I could add a workaround permission chatcontrol.color.all but that would be needed for all other permissions where wildcart can be used, such as chatcontrol.command.* and like two dozens of others. I don't think a workaround is a good solution. Any tips from the developer of GM I could do to fix this? Perhaps he can add support for unregistered wildcarts as well.

[ElgarL]

If you check Vault#has instead of Player#has then anonymous wildcards should work fine. Bukkit itself does not understand wildcards and never has. It's a function added by permission plugins. GroupManager being pretty much the first to do this it requires you query the plugin, or at a minimum Vault to test permissions. Luckperms and I believe Pex use reflection to replace the Bukkit permission parser on the Player object. So when you use Player#has you are calling LP code not Bukkits.

[kangarko]

Thanks, but we had to roll back to using Bukkit instead of Vault a couple of years ago, mainly due to a tiny performance penaulty and less compatibility, and the requirement to have Vault on for server owners. If I see a better solution I will implement it.

[TZ122]

Thanks, but we had to roll back to using Bukkit instead of Vault a couple of years ago, mainly due to a tiny performance penaulty and less compatibility, and the requirement to have Vault on for server owners. If I see a better solution I will implement it.

Hate to pry on this however will there be any ETA on resolving this issue? I’m unable to use sections of the plugin to its full extent without this and wasn’t aware that several perm plugins wouldn’t be compatible.

I’m unable to use anything relating to hex in nickname, prefix, suffix & tags (since I can’t grant individually thousands of hex colors). I’ve been able to get around other * perms by manually granting my groups dozens of permissions but I’m unable to use any type of hex for this reason.

[kangarko]

Try using the next version that will come out later today, I have made some changes there.

[TZ122]

Try using the next version that will come out later today, I have made some changes there.

Hey I receive the following error: https://pastebin.com/7HrmibX8 without wildcard functionality

[kangarko]

That is unfortunately caused by GroupManager, try their 3.0.0 snapshot or open a ticket. They should have some safety check there. We only call Vault, Vault passes the data we give it, I lose control at Vault's point. We do only run the check if the permission is not null.

[TZ122]

Thanks, I updated GroupManager. Unfortunately I am still having issues with not functioning. For example chatcontrol.color.red will work but not chatcontrol.color.

Default: default: true permissions:

• -bukkit.command.kill
• chatcontrol.color.*
• chatcontrol.hexcolor.*
• chatcontrol.channel.autojoin.local.write
• chatcontrol.channel.join
• chatcontrol.channel.join.global.write
• chatcontrol.channel.join.local.write
• chatcontrol.color.*
• chatcontrol.hexcolor.*
• chatcontrol.use.color.suffix
• chatcontrol.command
• chatcontrol.command.*
• chatcontrol.command.tag
• chatcontrol.command.tag.suffix

[ElgarL]

paste a full latest.log from your server startup.

[TZ122]

paste a full latest.log from your server startup.

https://pastebin.com/mFaPNYuE

[ElgarL]

Your startup is perfect (other than litebans). So long as perm checks in ChatControl are now using vault, anonymous wildcards should be working for you. You can increase the logging level in GroupManager to see if it is being asked for the permission checks.

[TZ122]

Thanks, had tried with wildcards from other plugins seemed to work perfect. Hopefully kangarko may have some insight on why this may be happening

[ElBananaa]

Thanks, had tried with wildcards from other plugins seemed to work perfect. Hopefully kangarko may have some insight on why this may be happening

As said above: You can increase the logging level in GroupManager to see if it is being asked for the permission checks.. Do this, and then provide us the output logs so we can easily find the cause of your issue.

[TZ122]

Thanks, had tried with wildcards from other plugins seemed to work perfect. Hopefully kangarko may have some insight on why this may be happening

As said above: You can increase the logging level in GroupManager to see if it is being asked for the permission checks.. Do this, and then provide us the output logs so we can easily find the cause of your issue.

Elgar and I had tested unfortunately spigot logging is broken at the moment. If there is any other way I can test this please let me know and I can provide logs.

[ElgarL]

Jump in discord and I can give you a custom jar with debug. As Spigot no longer supports changing the logging level :(

[ElgarL]

GroupManager_debug.zip ^ Rename to jar instead of zip (Github won't let you upload jars).

[ElgarL]

OK I got the fix. It's the way you need to query vault. It seems if you use Vault.has(player, permission) it never actually queries the plugin.

You need to Vault#playerHas(null, player, permission) This will correctly query the actual permission plugin and not default to the Player permission attachment.

[ElBananaa]

Hey, thanks for the suggestion.

@TZ122 I may have a build which should hopefully fix your issue, any chance you could reach me on discord: Bananaa#1471 I'll provide you the build there since I unfortunately don't have time to run tests right now.

[ElBananaa]

Issue seems to have been fixed with the build provided to the user.

@kangarko I made a PR for both chatcontrol & foundation, feel free to review the changes, but it shouldn't contain any breaking changes.

@ElgarL thanks again for your help with this! :)

[TZ122]

Thanks to everyone above works great!

[ElBananaa]

Alright, so it appears the version I sent now causes some features to break (definitely related to broken perms). I also closed my 2 prs as they actually were not the correct ones (dunno why it took them from the wrong branch).

So for a reason I don't really understand, if we use Vault#playerHas(null, player, permission) wildcards work, but other features appears to be broken (such as sound notifications and announcements.

If we use Vaul#has(sender, permission) then wildcards won't work but everything else will work just fine.

Will try other things in the next few days, but i'm definitely too tired to run more tests rn. @kangarko Can you please have a look?

[kangarko]

That's really strange, at this point I made a workaround to use the Vault method only for color checks and use the Bukkit method for all the other ones. Hopefully that solves this for good!

[ElBananaa]

That's really strange, at this point I made a workaround to use the Vault method only for color checks and use the Bukkit method for all the other ones. Hopefully that solves this for good!

@kangarko Well, if I understand properly what @ElgarL said above, using Bukkit methods works with other permission plugins like LuckPerms or PermissionEX because they use reflections. (This is explained a bit further on the post below, which was actually written by LuckPerms' author.)

GroupManager relies either on vault, or on its own methods for wildcard perms. So I don't think your changes will actually help with this issue (unless I misunderstood something).

[TZ122]

The changes in the latest release seem to work great. I will update here however if I do happen to find something!

[kangarko]

@TZ122 I am rewriting chatcontrol for adventure/mini. Please re-test once V11 is out and lemme know if it breaks again. I am optimizing for performance since I noticed the old code having a drawback.