[Feature Request] - Adding 'run script' button in scheduler like script

RouterOS Scripting
1

Currently, testing scripts within a scheduler or on-event function requires adjusting the interval to a very short time, waiting for the execution, and then resetting the interval to its intended long duration. This process is time-consuming and risks unintentional multiple executions if the user forgets to reset the interval. Furthermore, some scripts only run startup system, making manual testing difficult.

The Proposed Solution:

I propose adding a simple button (such as 'Run Now' or 'Run Script') directly within the Scheduler/Event configuration interface.

Benefits:

  • Time-Saving: Allows immediate testing of the script without modifying and then reverting the interval setting.

  • Debugging Efficiency: Provides a quick and reliable way to test code logic and system interactions on demand.

  • Ease of Use: Eliminates the need for indirect or complex procedures to execute the code instantly.

1 Like
2

Yes and No...

You know the existance of system/script?

Just press run...

And on scheduler, just call the script...

1 Like
3

@Moustafa
The "Run Script" button already exists in System Scripts, and you can have both Scheduler and ScriptList open, see (even if it is a bit excessive) this example screenshot:
https://mlapshin.com/wp-content/uploads/2015/09/Mikrotik_settings_w_menu.png

1 Like
4

@jaclaz @rextended

Hey guys, why are you limiting the use of`on-event` to just writing the script name?

Don't you know that you can write any script directly?

Beyond Conventional Limits.

Break the Mold.

5

It's not necessary to create a script every time I need to create a schedule.

6

I did many things in my life but never did that (or at least not intentionally).

I know, maybe rextended doesn't know that? :roll_eyes:

Good for you.

7

@jaclaz
If you wanted to execute two or more scripts simultaneously in sequence, would you create a schedule for each one separately?

The command line must be typed to execute it.

Like this:

/system script run “first script";
/system script run “second script";
8

You can test scheduler on-event script (if is not ROS script name) in CLI with :execute [get “<scheduler_name>” on-event as-string] or if is some short simple script paste it in Terminal surrounded by curly brackets - { <on_event_script> }

9

@optio

actually, I have other solutions.

I've already created a function that does this; I'm just giving it the name

10

Well, testing that way in terminal is not really testing, because scripts behave differently in terminal than they do when executing in background.

But I agree that when you want to write a script that is that complicated that it requires extensive testing, the best way is to start out in terminal, then put it in /system scripts and test again, then call it by name only.

When putting scripts directly in scheduler or other events, I use one-liners only. That is also much easier when editing.

11

:execute without as-string will execute script in background also.

12

@optio @pe1chl
This my basic function.

:global runScheduler do={
    :local "scheduler_name" ([/system scheduler print as-value where name=$1] -> 0 -> "name");
    :local "exec_time" [:time [:execute [/system scheduler get value=on-event $"scheduler_name"] as-string]];
    :put ($"scheduler_name" . ": " . $"exec_time");
};

For your information, I removed a lot of things from it, so no one say things, like: It's preferable to "put this" or "condition" or "Be careful, there will be a problem if this happens."

13

It's a bad habit to assume what isn't written, or even related...

Who ever wrote that?
We're talking about the scheduler here.

And then the "test" button in an on-event, like in a DHCP server, for example, is useless, because the parameters set by the device requesting the IP address don't exist...

[sarcasm]
Well, thank goodness you teach me, otherwise what would I do...
[/sarcasm]

Of course I know, I never create separate scripts but always put them in events without wasting time...

But for those who want the "button" like you, you can create the scripts separately and solve the problem... (except like DHCP serve example)

Or you can issue a command from the terminal and solve the problem...

14

While :execute or some function is same/similar today, one never knows what may change in future. But if you're happy with the solution, no problem. Just that MikroTik has changed permissions schemes pretty regularly, thus @pe1chl's concern:

But 100% agree that a "Run" button in /system/scheduler does seem useful, and odd that it does not have one already...