Please remember this category is for features inside the latest pre-release only. To make a new suggestion for Java (like a block or gameplay suggestion), please use the appropriate category for your suggestion.

← Minecraft: Java Edition Snapshots
30
Follow

Run dialog actions with datapack permission level (not player level)

Currently, it is impossible to create a dialog with input fields that players without op can interact with effectively. As it stands, any dialog input must have their input sent through the command_template on_submit action. However, without op, the only command that can receive such data is the trigger command, which does not accept text or floats, and only allows for a single input.

I propose that a new on_submit type be created for this purpose, called function_macro or something similar. The function macro submit type would accept the name of a function, and when submitted will pass along the input keys as keys for the function macro, and will not require elevated permissions combined with a scary popup to run. The function would run with the function permission level set in server.properties (so by default, dialog actions could not run commands like /op, /tick, or other server commands.)

An example dialog with multiple input fields might look something like this:
text input; key = text_1
text input; key = text_2
boolean input; key = boolean_1
slider input; key = slider_1
on_submit function_macro; id = example_namespace:example_function

Then, the function defined in the datapack "namespace:function" might look something like this:
$say Wow, you typed $(text_1) and $(text_2) in only $(slider_1) seconds, which is very $(boolean_1).

A player without op would therefore be able to pass on inputs to the datapack with dialog inputs, which is currently impossible under the current system.

Avatar
Registered User shared this idea

5 Comments

Please sign in to leave a comment.

Date Votes
Sorted by oldest
  • 6
    Registered User commented
    Comment actions Permalink

    Yes ! I have the same problem, I had the idea with a "submit" command that's works like a function but with non-op permission, but you idea is better for dialogs (but if we want to submit inputs without dialog (to use "submit" as a custom command for anything, my idea is better, and the submit command can be used in dalogs in command templates)

  • 9
    Registered User commented
    Comment actions Permalink

    An alternate idea would be to store the data to storage, but really it's absurd to me that running anything from a dialog isn't run at a high permission level by default. A dialog can only be created by the server, a datapack, or an opped player. I can only assume this is to prevent players from abusing the input structure to run server level commands, but if the dialog can be exploited, that's the fault of whoever created the dialog. Similar systems with macros could already exist before dialogs with the exact same potential for exploits. Scary pop-ups and limiting features doesn't protect server owners, it impedes the datapack creator's ability to effectively use new features and requires their datapacks to rely on third party server side mods to function. The addition of dialogs was a huge win for datpack creators, but this unnecessary limitation quite literally makes it impossible to use dialogs for any vanilla survival use case. I really hope they do something, anything to allow inputs to be used in dialogs that will be seen by non-opped players.

  • 5
    Registered User commented
    Comment actions Permalink

    An alternative, simpler solution would be to raise the default permission level of commands run by the "run_command" action from 0 to 2, no matter the user's current permission level.
    I think the confirmation dialog at these permission levels as well as the permission level set to 0 are pretty nonsensical since level 2 is required to show a dialog anyways, therefore attempting privilege escalation via dialogs would be useless. Also consider making making all of the above world/server options for those who want to change this behaviour on their own accord.

  • 2
    Registered User commented
    Comment actions Permalink

    This limitation essentially makes dialogs useless for me. I suggest removing this limitation or at the very least, make an option somewhere in the dialog code to allow the run_command to bypass permissions. I spent hours making this really cool custom input system for my friends to use on our server, only to be told they can't use it without permissions.

  • 1
    Registered User commented
    Comment actions Permalink

    I think letting `/execute store result` store compunds (and strings, arrays, etc), with /dialog returning one with all keys would be even better, but yes, this would be great