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

Remove support for reports in NetBox v4.0 #8011

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

Originally created by @jeremystretch on GitHub (May 5, 2023).

Originally assigned to: @arthanson on GitHub.

Proposed Changes

Remove all support for custom reports. Support for custom scripts will remain in place.

This change is being proposed for NetBox v4.0 to allow users ample time to prepare for the migration.

Justification

There's a lot of overlap in functionality between reports and scripts, and dropping reports in favor of scripts will allow us to simplify the user experience and remove a substantial amount of largely redundant code.

Impact

All reports will need to be converted to scripts, which should be fairly straightforward. We can produce supporting documentation to assist users with this process.

Originally created by @jeremystretch on GitHub (May 5, 2023). Originally assigned to: @arthanson on GitHub. ### Proposed Changes Remove all support for custom reports. Support for custom scripts will remain in place. This change is being proposed for NetBox v4.0 to allow users ample time to prepare for the migration. ### Justification There's a lot of overlap in functionality between reports and scripts, and dropping reports in favor of scripts will allow us to simplify the user experience and remove a substantial amount of largely redundant code. ### Impact All reports will need to be converted to scripts, which should be fairly straightforward. We can produce supporting documentation to assist users with this process.
adam added the status: acceptedtype: deprecationbreaking change labels 2025-12-29 20:31:07 +01:00
adam closed this issue 2025-12-29 20:31:07 +01:00
adam commented 2025-12-29 20:31:08 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (May 8, 2023):

We primarily use reports for compliance and referential integrity between multiple systems today. From a UX perspective, having the Run Again button, the individual test cases with their status badges, and the ability to reference an object directly within the logs are critical to our workflow. I'm all for consolidating these two pieces of functionality, as it would help with a lot of duplicate code on our end too, but it's not clear to me what the straightforward path to convert from a report to a script is at this point. I know Nautobot did something like this with their Jobs functionality by incorporating run(), test_*(), and post_run() methods within the same class. My vote would be to merge the existing Script and Report functionality in a similar way. It looks like they've added some other nice features, like job buttons within object views and approval functionality as well.

@sleepinggenius2 commented on GitHub (May 8, 2023): We primarily use reports for compliance and referential integrity between multiple systems today. From a UX perspective, having the *Run Again* button, the individual test cases with their status badges, and the ability to reference an object directly within the logs are critical to our workflow. I'm all for consolidating these two pieces of functionality, as it would help with a lot of duplicate code on our end too, but it's not clear to me what the straightforward path to convert from a report to a script is at this point. I know *Nautobot* did something like this with their [Jobs](https://docs.nautobot.com/projects/core/en/stable/additional-features/jobs/) functionality by incorporating `run()`, `test_*()`, and `post_run()` methods within the same class. My vote would be to merge the existing *Script* and *Report* functionality in a similar way. It looks like they've added some other nice features, like job buttons within object views and approval functionality as well.
adam commented 2025-12-29 20:31:08 +01:00
Author
Owner
Copy Link

@ITJamie commented on GitHub (Aug 16, 2023):

from a permissions POV we have reports and scripts separate right now. once this happens any user who needs to run a report will need the run script permission. this will allow users a higher level of access to make changes

Having a specific permission for scripts that would set whether the user can run scripts which make changes or not would be good.
otherwise there's a risk that a user could run a script thinking it just was a "report" and it making changes.

the current split between reports + scripts effectively handles this but once combined it changes the risk profile

@ITJamie commented on GitHub (Aug 16, 2023): from a permissions POV we have reports and scripts separate right now. once this happens any user who needs to run a report will need the run script permission. this will allow users a higher level of access to make changes Having a specific permission for scripts that would set whether the user can run scripts which make changes or not would be good. otherwise there's a risk that a user could run a script thinking it just was a "report" and it making changes. the current split between reports + scripts effectively handles this but once combined it changes the risk profile
adam commented 2025-12-29 20:31:08 +01:00
Author
Owner
Copy Link

@ross-cello commented on GitHub (Nov 7, 2023):

Heya team, regarding this report deprecation and the mention of supporting documentation and/or transitional function for Scripts; do you happen to have a target minor release prior to 4.0 for these considerations?

I'm also mindful of permissions in particular, but appreciate that none of these aspects might be on your radar yet.

@ross-cello commented on GitHub (Nov 7, 2023): Heya team, regarding this report deprecation and the mention of supporting documentation and/or transitional function for Scripts; do you happen to have a target minor release prior to 4.0 for these considerations? I'm also mindful of permissions in particular, but appreciate that none of these aspects might be on your radar yet.
adam commented 2025-12-29 20:31:08 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 7, 2023):

@ITJamie raises a good point about a core difference between reports and scripts. Reports are intended (but are not technically required) to be read-only, whereas scripts generally make changes to data. The other core difference IMO is that reports serve to produce well-formatted pass/fail results, whereas scripts are completely open-ended.

Maybe instead of trying to mash these two resources into one, we'd be better served by further differentiating them. One improvement could be to restrict database write operations during the execution of a report, ensuring that a report cannot inadvertently alter data.

@jeremystretch commented on GitHub (Dec 7, 2023): @ITJamie raises a good point about a core difference between reports and scripts. Reports are intended (but are not technically required) to be read-only, whereas scripts generally make changes to data. The other core difference IMO is that reports serve to produce well-formatted pass/fail results, whereas scripts are completely open-ended. Maybe instead of trying to mash these two resources into one, we'd be better served by further differentiating them. One improvement could be to restrict database write operations during the execution of a report, ensuring that a report cannot inadvertently alter data.
adam commented 2025-12-29 20:31:09 +01:00
Author
Owner
Copy Link

@ITJamie commented on GitHub (Dec 8, 2023):

If we do extend reports instead of depreciating it, we should extend reports to display returned data like scripts can.

We have a few "reports" that we have to run as scripts so they can return csv or json data.

The actual report/script classes under the hood could be merged or have a shared parent class in the longterm to get the featureset and response methods to be the similar but still easily maintainable

@ITJamie commented on GitHub (Dec 8, 2023): If we do extend reports instead of depreciating it, we should extend reports to display returned data like scripts can. We have a few "reports" that we have to run as scripts so they can return csv or json data. The actual report/script classes under the hood could be merged or have a shared parent class in the longterm to get the featureset and response methods to be the similar but still easily maintainable
adam commented 2025-12-29 20:31:09 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Dec 11, 2023):

Maybe instead of trying to mash these two resources into one, we'd be better served by further differentiating them. One improvement could be to restrict database write operations during the execution of a report, ensuring that a report cannot inadvertently alter data.

Could we maybe do a hybrid approach?

  • Merge reports in with scripts
  • A "script" is a report if it inherits from the "Reports" Superclass
  • Reports a restricted from modifying non-report objects

This might also open up the ability to write scripts that can display that nicely formatted pass/fail result that reports can. It also allows overall efficiencies under the hood.

@DanSheps commented on GitHub (Dec 11, 2023): > Maybe instead of trying to mash these two resources into one, we'd be better served by further differentiating them. One improvement could be to restrict database write operations during the execution of a report, ensuring that a report cannot inadvertently alter data. Could we maybe do a hybrid approach? * Merge reports in with scripts * A "script" is a report if it inherits from the "Reports" Superclass * Reports a restricted from modifying non-report objects This might also open up the ability to write scripts that can display that nicely formatted pass/fail result that reports can. It also allows overall efficiencies under the hood.
adam commented 2025-12-29 20:31:09 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 11, 2024):

We decided in the maintainers' meeting today to proceed with this change, merging reports into scripts.

@jeremystretch commented on GitHub (Jan 11, 2024): We decided in the maintainers' meeting today to proceed with this change, merging reports into scripts.
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 breaking change status: accepted type: deprecation
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#8011
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?