If a player or a command block executes a /tellraw command which has some interactivity with it, (eg. Click here to reset the minigame), the command which it is told to execute is done from the permission level of the player who clicks the dialog. This means that if a server owner wants to use /tellraw for a store or some minigame, the players who interact with it need to be able to use the commands the /tellraw uses, which could be dangerous for the server. Adventure maps that use /tellraw would need to keep cheats enabled, which is not ideal.
This may be intended for safety reasons, but it seems to break the tellraw feature.
A solution might be to execute commands that are part of /tellraw from the permissions of the person/commandblock issuing the /tellraw command. This way, for example, if a player who can use /tellraw and /give, but not /ban would not be able to create a dialog that would ban players, but could make one that can give a player an item.
Linked issues
is duplicated by 2
Comments 6
Another feature may be added sometime in the future as a kind of 'sudo', but this is completely intentional right now.
It's now 14w05a, how is this still intentional? After changing all IDs into mandatory text (which I do like but not the fact that's it mandatory, but I digress), I think you guys would have done something for this? It's been about five months now, can this please be fixed/implemented?
Confirmed. This actually destroys /tellraw's run_command feature, and even contradicts Dinnerbone's own example usage of it. I doubt it's intended, and I sincerely hope it isn't. Forcing a mapmaker to op players for a map to function does just the opposite of encouraging safety.
I was excited when I realized /tellraw lets a mapmaker create functioning spell systems (via /summon, which can now summon entities relative to the player!), but this behavior negates its entire purpose (if the player is an op, they can already do whatever they want).