Introduce permission for the use of colour codes on signs

[baailey]

Hi, when going through all the permissions I noticed that this plugin doesn't have a permission to specify whether colour codes can be used on signs. I can't really comprehend why?

I quite like this plugin as it simply just stands out from the rest, but I feel the only letdown is the lack of permissions for things related to colour codes.

If this could be implemented it would be appreciated. Thanks.

[Deltik]

Hello, and thank you for the feature suggestion!

SignEdit for Bukkit doesn't have any permissions to restrict the content of the signs. This was my intentional design choice for the following reasons:

• Other plugins already provide sign content permissions – SignEdit for Bukkit >= 1.12.3 (released 2020-08-19) integrates seamlessly with other permissions plugins that change the lines of signs based on what's allowed to be in the text. I recommend EssentialsX for sign color permissions. Players without the essentials.signs.color permission have colors removed when they try to change a sign with a /sign subcommand. This screenshot shows what happens when EssentialsX strips out formatting codes after a player runs /sign set 3 &b&lSignEdit:
  
• No single source of truth for color permissions – Suppose color permissions were defined in both EssentialsX and SignEdit for Bukkit. If colors were allowed in EssentialsX but the operator forgot to add the permission for SignEdit for Bukkit, players may be confused that the new signs they create have color but the signs they edit have color removed. I don't want to interfere with other permissions plugins.
• Opt-in color permissions may be overlooked – Reading documentation can be exhausting for an operator. They could forget to enable colors in SignEdit for Bukkit, which may lead to confusing behavior (see previous bullet point).
• Opt-out color permissions go against the permission granting model – If there was a permission that if granted would deny colors, an operator using blanket/star/glob permissions may disable colors by trying to grant all permissions. This may lead to frustration as an operator would then need to craft globs to grant the right permissions under the signedit group.
• SignEdit for Bukkit is not a permissions plugin – The permissions currently registered by the plugin are just to enable subcommands. They are not structured to decide what can and can't go into sign text.
• How granular should the permissions be? – All formatting codes? How about just colors? Or just obfuscated text? Or just emphasis codes? Or sRGB codes? Or just dark purple? Or some combination of these?
• Content control adds complexity – SignEdit for Bukkit just makes it easy to edit existing signs. Adding a content validator might start a cycle of feature creep and make it harder for me to maintain this plugin.

The only reason I can think of to ban colors inside SignEdit for Bukkit is that vanilla Minecraft doesn't convert ampersand-style formatting codes to real formatting codes, but this is not a server-side restriction―a modded Minecraft client could send real formatting codes and make color sign text on a vanilla Minecraft server (without plugins). In this case, SignEdit for Bukkit just offers a convenient syntax to do what was already possible.

[baailey]

Sorry, bit confused. I've tried using EssX as the permission handler but by following the exact same steps as you, /sign can still be used to create signs with colour codes? Is there a setting I'm missing?

[Deltik]

In whatever permissions system you are using, revoke or do not grant the essentials.signs.color permission. Note that if you are an operator, you get the permission granted even if it is absent in the configuration. You may need to /deop <yourself> to test the reduced privileges.

Last I knew, EssentialsX itself doesn't have a robust permissions system, so you might want to consider using a plugin dedicated to managing permissions like LuckPerms.

Note that EssentialsX support is out of scope of SignEdit for Bukkit, so if you need help with their permissions setup, try asking their community: https://essentialsx.net/community.html

[baailey]

I have only granted my alt signedit.sign.set.

My understanding from your explanation is that if the user does not have essentials.signs.color and they try add colours via your plugin, the colours shouldn't work?

[Deltik]

Right, SignEdit for Bukkit integrates with a specific hook that sends the updated sign contents to other plugins and gives other plugins a chance to edit the sign contents. EssentialsX listens on the other end and strips the colors if permission essentials.signs.color is not granted.

[baailey]

That is not the case for me when testing. With an alt that only has access to signedit.sign.set I have them place a sign, do /sign 3 &bhi and the colour codes work. I'm not sure what else to do here. This hook works fine with WorldGuard and ChestShop from testing, so I'm a bit stuck..

[baailey]

Is this a bug? Or does it work as intended for you?

[Deltik]

It's a bug! SignEdit for Bukkit >= 1.12.2, <= 1.12.8 incorrectly assumes that an array of the sign lines passed through a SignChangeEvent will be mutated in-place. A third-party plugin may change the sign lines in the SignChangeEvent, but the updated text will be discarded because SignEdit is using the old references.

This bug will be fixed in the next release. Hang tight!