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

Ability to synchronize reports & scripts from a remote data source #7710

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

Originally created by @jeremystretch on GitHub (Mar 2, 2023).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v3.4.5

Feature type

New functionality

Proposed functionality

NetBox has long supported custom scripts and reports as ways of enhancing its functionality. Currently, these are Python modules and scripts which must be uploaded to the configured storage system for use, and manually updated whenever changes are needed.

NetBox v3.5 introduces the ability to synchronize arbitrary data from a remote source (see #11558). This FR proposes leveraging this new ability to automatically update custom scripts and reports from an external source, such as a git repository.

I see two potential options for implementation:

Option A: Replication to files on disk

This is the more lightweight approach. One or more remote data sources could be designated (through a mechanism to be determined) as containing NetBox scripts or reports. The DataFiles produced from this source would be automatically replicated to the local storage backend within the REPORTS_ROOT or SCRIPTS_ROOT path as appropriate.

Option B: Create reports & scripts as database objects

This approach would be more involved, effectively changing the manner in which we manage scripts and reports. Rather than being stored as files on disk, each report and script module would exist as a database object. Replicating content from a DataFile would then follow the same pattern as we've implemented for config templates and other models. However, I'm not sure how feasible this approach is; further exploration is needed.

Use case

The ability to automatically update custom scripts and reports will obviate the need to apply changes manually to files on disk, and greatly simplify their administration.

Database changes

Option A as outlined above requires no changes to the database. Option B would entail replacing the "fake" Report and Script models under extras with concrete models with actual database tables.

External dependencies

None

Originally created by @jeremystretch on GitHub (Mar 2, 2023). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v3.4.5 ### Feature type New functionality ### Proposed functionality NetBox has long supported [custom scripts](https://docs.netbox.dev/en/stable/customization/custom-scripts/) and [reports](https://docs.netbox.dev/en/stable/customization/reports/) as ways of enhancing its functionality. Currently, these are Python modules and scripts which must be uploaded to the configured storage system for use, and manually updated whenever changes are needed. NetBox v3.5 introduces the ability to synchronize arbitrary data from a remote source (see #11558). This FR proposes leveraging this new ability to automatically update custom scripts and reports from an external source, such as a git repository. I see two potential options for implementation: ### Option A: Replication to files on disk This is the more lightweight approach. One or more remote data sources could be designated (through a mechanism to be determined) as containing NetBox scripts or reports. The DataFiles produced from this source would be automatically replicated to the local storage backend within the `REPORTS_ROOT` or `SCRIPTS_ROOT` path as appropriate. ### Option B: Create reports & scripts as database objects This approach would be more involved, effectively changing the manner in which we manage scripts and reports. Rather than being stored as files on disk, each report and script module would exist as a database object. Replicating content from a DataFile would then follow the same pattern as we've implemented for config templates and other models. However, I'm not sure how feasible this approach is; further exploration is needed. ### Use case The ability to automatically update custom scripts and reports will obviate the need to apply changes manually to files on disk, and greatly simplify their administration. ### Database changes Option A as outlined above requires no changes to the database. Option B would entail replacing the "fake" Report and Script models under `extras` with concrete models with actual database tables. ### External dependencies None
adam added the status: acceptedtype: feature labels 2025-12-29 20:27:20 +01:00
adam closed this issue 2025-12-29 20:27:20 +01:00
adam commented 2025-12-29 20:27:20 +01:00
Author
Owner
Copy Link

@ryanmerolle commented on GitHub (Mar 2, 2023):

I propose this for milestone 3.5. Objections?

@ryanmerolle commented on GitHub (Mar 2, 2023): I propose this for milestone 3.5. Objections?
adam commented 2025-12-29 20:27:21 +01:00
Author
Owner
Copy Link

@pycolas commented on GitHub (Mar 5, 2023):

Nice feature.
I would imagine something like in Ansible Tower : create the script entry in Netbox where you manage when it runs, who can run it, etc, and the source code stored in a git repository.
https://docs.ansible.com/ansible-tower/latest/html/userguide/projects.html.

@pycolas commented on GitHub (Mar 5, 2023): Nice feature. I would imagine something like in Ansible Tower : create the script entry in Netbox where you manage when it runs, who can run it, etc, and the source code stored in a git repository. https://docs.ansible.com/ansible-tower/latest/html/userguide/projects.html.
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#7710
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?