starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Allow disabling scheduling feature on custom scripts #7390

New Issue
Closed
opened 2025-12-29 20:22:47 +01:00 by adam · 7 comments
adam commented 2025-12-29 20:22:47 +01:00
Owner
Copy Link

Originally created by @rodvand on GitHub (Dec 20, 2022).

Originally assigned to: @jeremystretch on GitHub.

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

Originally created by @rodvand on GitHub (Dec 20, 2022). Originally assigned to: @jeremystretch on GitHub. ### 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_
adam added the status: acceptedtype: feature labels 2025-12-29 20:22:47 +01:00
adam closed this issue 2025-12-29 20:22:47 +01:00
adam commented 2025-12-29 20:22:51 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 22, 2022):

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?

@jeremystretch commented on GitHub (Dec 22, 2022): > 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?
adam commented 2025-12-29 20:22:52 +01:00
Author
Owner
Copy Link

@rodvand commented on GitHub (Dec 28, 2022):

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.

@rodvand commented on GitHub (Dec 28, 2022): > > 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.
adam commented 2025-12-29 20:22:52 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Dec 29, 2022):

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.

@PieterL75 commented on GitHub (Dec 29, 2022): 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.
adam commented 2025-12-29 20:22:52 +01:00
Author
Owner
Copy Link

@michael-edobor commented on GitHub (Dec 29, 2022):

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.

@michael-edobor commented on GitHub (Dec 29, 2022): > > 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.
adam commented 2025-12-29 20:22:53 +01:00
Author
Owner
Copy Link

@ITJamie commented on GitHub (Jan 4, 2023):

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

@ITJamie commented on GitHub (Jan 4, 2023): 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
adam commented 2025-12-29 20:22:53 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Apr 13, 2023):

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.

@github-actions[bot] commented on GitHub (Apr 13, 2023): 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](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:22:53 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 17, 2023):

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.)

@jeremystretch commented on GitHub (Apr 17, 2023): 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.)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: accepted type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#7390
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?