Trigger edit replacement - "Edit Runtime"

[MetRonnie]

As discussed in cylc/cylc-flow#3751, implement the front-end of trigger-edit capability. This will take the task's [runtime] info from GraphQL (cylc/cylc-flow#5054) and display it as a form, allowing user to add/remove/edit fields (but not the inherit field).

[hjoliver]

A note, offline, from one of our main sites:

our most common edit run is to change a line that looks like:
rose task-run arg1 arg2 arg3
to
rose task-run arg1 arg2 arg3 –new
To force something to re-run from scratch (for example if the model was unstable)

Probably stating the obvious at this point, but the script items will need text-edit capability, potentially for a large amount of scripting.

[hjoliver]

What did we decide to rename this capability to, now that "trigger edit" and "edit run" are no longer appropriate (triggering will be separate)?

• stick with broadcast, for former use cases of that and for the more restricted one-off "edit run" style use?
  • this name is a fairly obtuse reference to the idea of "broadcasting" new settings to tasks via the scheduler, but it might not be so obvious to users
• set-runtime or task-runtime?
• override?
• ???

[hjoliver]

Note security concerns here: cylc/cylc-flow#2687 (comment)

Initially, I guess we can just make sure cylc broadcast as a whole defaults to the most restrictive authorization level.

Later we might need to consider singling out script and environment items as more dangerous.

[MetRonnie]

What did we decide to rename this capability to, now that "trigger edit" and "edit run" are no longer appropriate (triggering will be separate)?

I had settled upon "Edit Runtime", but open to suggestions

[hjoliver]

Right, thanks, I recall that from the meeting now. "Edit Runtime" is quite good - it is descriptive and it's reminiscent of the original "edit run" description of "trigger --edit".

We should consider changing the CLI command name cylc broadcast to cylc edit-runtime too. (We can provide an alias to the old name, of course).