Allow disabling scheduling feature on custom scripts

[rodvand]

NetBox version

v3.4.1

Feature type

New functionality

Proposed functionality

Allow an option to to disable the scheduling feature for specific custom scripts.

Not all Custom Scripts are made to be scheduled, so it would be nice if we could just toggle a variable or something similar within a script to hide the scheduling feature for that specific script.

Use case

Avoid the scheduling tab showing up when the script is not intended for scheduling.

Database changes

None, I think.

External dependencies

No response

[jeremystretch]

Avoid the scheduling tab showing up when the script is not intended for scheduling.

This describes the desired behavior, but not the justification for it. What's the harm in presenting the option to schedule a script even when it may not be needed?

[rodvand]

Avoid the scheduling tab showing up when the script is not intended for scheduling.

This describes the desired behavior, but not the justification for it. What's the harm in presenting the option to schedule a script even when it may not be needed?

I'm sure we will be ok with the scheduling option present, but we have various workflows which we would not want to schedule. As an example we have a provisioning workflow where the user is required to input NetBox data as the provisioning is done. To ensure the accuracy of this we want it to be done while actually doing the provisioning, and we would not want someone to schedule this (I can see someone planning to do a provision, schedule it, and then something else occurs and they don't actually do the provisioning, but the NetBox job still runs, and then we have an issue). That's why I would like having the ability to hide the scheduling form fields with a toggle somehow.

[PieterL75]

I like the idea, but maybe the 'schedule script' should be a separate menuitem.
Having a script with parameters is one thing,
But scheduling it, is a whole different thing. What if I want to schedule a script 2 times with different datafields, or run a script on 3 different schedules ?
My proposal is to create a 'scheduler' that can run scripts and reports, with datavalues per scheduling.

[michael-edobor]

Avoid the scheduling tab showing up when the script is not intended for scheduling.

This describes the desired behavior, but not the justification for it. What's the harm in presenting the option to schedule a script even when it may not be needed?

Two reasons:

There are scripts designed to be run only once manually and in real-time.
Secondly, presenting the schedule option for all scripts potentially increases administrative overhead to manage or cancel these scheduled scripts. We also do not want to give users permissions to cancel job schedules as they may cancel or view 'jobs' created for other users.

In my environment, I have a script that manually sends email notifications "New device onboarding" to specific people when new circuits are created. It is designed to be triggered manually as the user must conduct manual background checks before notifying other team members via the script. With the scheduling options visible to the user without any form of logic to prevent the schedule from being run, this will cause workflow disruptions as users may be getting emails every X minutes (depending on the user input).

Two ways to approach this:

1. Modify the Script class to have an optional schedulable parameter (maybe a bool) that can be defined by a Script's author. This parameter is then used when rendering the UI.
2. Pass the scheduling parameters from the UI during the script run into the 'data' dict so script authors can override the script schedule set in the UI or perform safety checks. E.g Preventing the email scripts from going off every minute. Script authors can define 'run' constraints better.

The first one is a better approach in my opinion.

[ITJamie]

the first approach suggested by @michael-edobor would be best. that way if people share scripts for certain tasks to customers or even shared online, it cant be scheduled accidentally by someone who isnt aware of the scripts limitations or risks

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

[jeremystretch]

I'm going to tag this for v3.5, with the following definition of scope: Introduce a variable on the base report & script classes that an author can set to false to disable scheduling. (It's being tagged for v3.5 because the introduction of this variable is considered a potentially breaking change.)