One Time Script Run

[tim104979]

At the moment we are using another RMM and we use Run on onboarding a lot

What it does is when a client gets onboarded into the rmm it runs a script one time (in our instance a custom anydesk client and reports the id back)

[ToddHebebrand]

Good ask, and worth splitting into its two halves, because one already exists:

Ad-hoc one-time runs exist today. POST /scripts/:id/execute takes a list of device ids and runs immediately — no automation or schedule object is created (triggerType: 'manual'). In the UI that's the Run Script action on a device's detail page, and the multi-device execute modal on the Scripts page.

"Run on onboarding" does not exist yet — and that's the actual feature here. There's currently no trigger point that fires a script exactly once when a device first enrolls. The execution primitive is already shared (executeScriptOnDevices()), so the work is a run-on-enrollment script reference on the org/site (or enrollment key) config plus a hook at first agent check-in — a well-bounded feature, not new plumbing.

Your AnyDesk example ("runs once and reports the id back") is a two-parter, and the second half is tracked separately: #2698 covers letting a script write values (like that AnyDesk id) back into device custom fields, and most of its plumbing exists too. The pair together gives you the full Tactical-style workflow.

Keeping this open as the tracker for the onboarding trigger.

[tim104979]

is it also possible to see the output of the scripts when the run as automation?
a little bit like this. This shows the latest run of the script with the output that we set inside of the script

[ToddHebebrand]

Different ask than the last round — and it turned out to be worth digging into, because it's not just a missing UI column.

Manual runs already show what you're describing: script execution history and the device history tab both surface stdout, because those paths write a script_executions row that gets filled in when the agent result comes back.

Automation-triggered script actions don't — and the output is actually being dropped, not just hidden. The automation runtime queues the command with a synthetic execution id (runId:deviceId:actionIndex) instead of a real execution row. When the result arrives, the handler that would normally save stdout tries to match that string against a UUID column, fails, and the error is swallowed into a server-side log. So today the script's output isn't stored anywhere retrievable. There's even a column that was clearly meant for it (automation_run_device_results.output), but it only ever receives the automation's own log lines, and the run-history panel doesn't render it anyway.

Filed as #3162 with the full file:line trail — the fix is to persist the real stdout for automation runs and render it in the run-history expanded panel, which lands exactly the inline latest-run output view you're pointing at. It's distinct from both the onboarding trigger tracked here and the custom-field feature in #2698.

Status: gap confirmed and tracked in #3162; this discussion stays the tracker for the run-on-onboarding feature.

[tim104979]

the problem i am facing now is that the automation does not finish:

the first and the last one are manually triggerd and take les than a second to complete the automation does not complete at all

[tim104979]

There is also no way to stop the script from the interface when it is running

[ToddHebebrand]

Both of those are real, and neither is the onboarding feature this thread tracks — so I've split them out rather than let them sit here.

The automation that never finishes is a known regression, already filed as #3445. Your screenshot matches it exactly: manual runs of the same script complete in seconds, the automation-triggered one hangs. The cause is that at v0.103.0 the automation runtime never created a script_executions row at all, so there was nothing to strand. v0.104.0 (#3162) started inserting a real row — which is what makes the output visible, the thing you asked for last round — and those rows are now not being closed out on the automation path. The long duration you see is the deadline elapsing, not the script running: it is your configured script timeout plus a fixed 5-minute grace buffer, so a 3600-second timeout produces almost exactly the 65 minutes on that row.

Being straight about status: the mechanism is understood, the root cause of why the automation path misses the result is not yet. Two earlier explanations on #3445 were wrong and have been corrected in-thread. Follow #3445 for the fix.

No way to stop a running script is a genuine gap, and it was not filed. Now #3525. I checked before answering — backup jobs, restores and contracts all have a cancel endpoint, and scripts have none on any surface. So today the only exits from a dispatched script are the agent returning a result or the deadline expiring, which is the 65 minutes you are watching. There is deliberately no button rather than a broken one.

Worth flagging one thing from that issue, because it affects what you get first: cancel is not really a UI task. Stopping the tracking without also killing the process on the endpoint gives you a button that reports something untrue. The agent-side kill is the part that needs checking, and it decides whether this is small or medium.

This discussion stays the tracker for run-on-onboarding, which is still the original ask and still not built. #2698 covers the write-values-back half of your AnyDesk workflow.

Thanks for keeping at this one — the cancel gap only surfaced because you mentioned it in passing.

[tim104979]

No problem, when i find more stuff i will let you know. Thanks for all te progress with the project