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

Support custom scripts for automatically manipulating objects #2799

New Issue
Closed
opened 2025-12-29 18:22:16 +01:00 by adam · 4 comments
adam commented 2025-12-29 18:22:16 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Aug 9, 2019).

Originally assigned to: @jeremystretch on GitHub.

Environment

  • Python version: 3.5.2
  • NetBox version: 2.6.2

Proposed Functionality

Extend NetBox to allow users to run custom scripts natively within the UI, in a similar fashion to how reports are used today. This is essentially a mechanism for integrating standalone scripts into the NetBox UI and API.

For example, a developer might write a script to automatically populate the appropriate devices and prefixes for a new site being deployed. The script would prompt a user for several variables as a web form, and when submitted the script will run, using the provided data to automatically build objects in NetBox.

This idea was split from #1364 (deployment templates) and covers much of its scope. However, we opted to keep #1364 open as an FR for a more user-friendly feature in the future (one which does not require custom scripting).

Use Case

Custom scripts can be used for many things, such as:

  • Populating the necessary objects for a new site from a standard design
  • Migrating a set of objects through a series of complex bulk operations
  • Cleaning up or removing data which does not conform to validation rules

Database Changes

This remains to be determined, though it likely will not require any database changes.

External Dependencies

None

Originally created by @jeremystretch on GitHub (Aug 9, 2019). Originally assigned to: @jeremystretch on GitHub. ### Environment * Python version: 3.5.2 * NetBox version: 2.6.2 ### Proposed Functionality Extend NetBox to allow users to run custom scripts natively within the UI, in a similar fashion to how [reports ](https://netbox.readthedocs.io/en/stable/additional-features/reports/) are used today. This is essentially a mechanism for integrating standalone scripts into the NetBox UI and API. For example, a developer might write a script to automatically populate the appropriate devices and prefixes for a new site being deployed. The script would prompt a user for several variables as a web form, and when submitted the script will run, using the provided data to automatically build objects in NetBox. This idea was split from #1364 (deployment templates) and covers much of its scope. However, we opted to keep #1364 open as an FR for a more user-friendly feature in the future (one which does not require custom scripting). ### Use Case Custom scripts can be used for many things, such as: * Populating the necessary objects for a new site from a standard design * Migrating a set of objects through a series of complex bulk operations * Cleaning up or removing data which does not conform to validation rules ### Database Changes This remains to be determined, though it likely will not require any database changes. ### External Dependencies None
adam added the status: accepted label 2025-12-29 18:22:16 +01:00
adam closed this issue 2025-12-29 18:22:16 +01:00
adam commented 2025-12-29 18:22:17 +01:00
Author
Owner
Copy Link

@sdktr commented on GitHub (Aug 12, 2019):

Very cool idea! Is this functionality intended method of invocation GUI only? Or do you plan to add API endpoints for it as well?
Might be a slippery-slope regarding what the consumer should be able to handle itself or let Netbox handle for him. On the other hand keeping logic in one place (like a netbox-script) independent of the consumer sounds tempting as well..

@sdktr commented on GitHub (Aug 12, 2019): Very cool idea! Is this functionality intended method of invocation GUI only? Or do you plan to add API endpoints for it as well? Might be a slippery-slope regarding what the consumer should be able to handle itself or let Netbox handle for him. On the other hand keeping logic in one place (like a netbox-script) independent of the consumer sounds tempting as well..
adam commented 2025-12-29 18:22:17 +01:00
Author
Owner
Copy Link

@darcynz commented on GitHub (Aug 14, 2019):

This looks fantastic and will greatly enable Netbox.

Wishful thinking, but it would add to its versatility if the scripts could be triggered by or linked to
the webhook functionality.

Imagine that might open / create other problems.

@darcynz commented on GitHub (Aug 14, 2019): This looks fantastic and will greatly enable Netbox. Wishful thinking, but it would add to its versatility if the scripts could be triggered by or linked to the webhook functionality. Imagine that might open / create other problems.
adam commented 2025-12-29 18:22:17 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 14, 2019):

Or do you plan to add API endpoints for it as well?

I'd like to try a new approach for this feature. Whereas normally something like this would be introduced in a beta for testing, and then finalized in an official 2.x release, I'm going to introduce the tentative implementation in a 2.6.x patch release so people can preview the feature before it becomes "official." (We can do this only because the feature does not introduce any breaking changes.) My thought is that this will allow us to gather feedback and real-world use cases prior to establishing an API for it. The API endpoint will be introduced as part of the 2.7 release.

@jeremystretch commented on GitHub (Aug 14, 2019): > Or do you plan to add API endpoints for it as well? I'd like to try a new approach for this feature. Whereas normally something like this would be introduced in a beta for testing, and then finalized in an official 2.x release, I'm going to introduce the tentative implementation in a 2.6.x patch release so people can preview the feature before it becomes "official." (We can do this only because the feature does not introduce any breaking changes.) My thought is that this will allow us to gather feedback and real-world use cases prior to establishing an API for it. The API endpoint will be introduced as part of the 2.7 release.
adam commented 2025-12-29 18:22:17 +01:00
Author
Owner
Copy Link

@sdktr commented on GitHub (Aug 16, 2019):

Or do you plan to add API endpoints for it as well?

I'd like to try a new approach for this feature. Whereas normally something like this would be introduced in a beta for testing, and then finalized in an official 2.x release, I'm going to introduce the tentative implementation in a 2.6.x patch release so people can preview the feature before it becomes "official." (We can do this only because the feature does not introduce any breaking changes.) My thought is that this will allow us to gather feedback and real-world use cases prior to establishing an API for it. The API endpoint will be introduced as part of the 2.7 release.

That sounds like a smooth plan to fuel feedback and adoption

@sdktr commented on GitHub (Aug 16, 2019): > > Or do you plan to add API endpoints for it as well? > > I'd like to try a new approach for this feature. Whereas normally something like this would be introduced in a beta for testing, and then finalized in an official 2.x release, I'm going to introduce the tentative implementation in a 2.6.x patch release so people can preview the feature before it becomes "official." (We can do this only because the feature does not introduce any breaking changes.) My thought is that this will allow us to gather feedback and real-world use cases prior to establishing an API for it. The API endpoint will be introduced as part of the 2.7 release. That sounds like a smooth plan to fuel feedback and adoption
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
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#2799
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?