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

Site-Based Filtering for Bulk Import #11459

New Issue
Closed
opened 2025-12-29 21:45:31 +01:00 by adam · 6 comments
adam commented 2025-12-29 21:45:31 +01:00
Owner
Copy Link

Originally created by @mkarel on GitHub (Aug 8, 2025).

NetBox version

v4.3.5

Feature type

New functionality

Proposed functionality

Similar to Feature Request 19840 , it would be highly beneficial to extend site-based filtering capabilities to the bulk import process for the following object types:

  • Modules
  • Interfaces
  • Front Ports
  • Rear Ports
  • Console Ports
  • Console Server Ports
  • Power Ports
  • Power Outlets
  • Module Bays
  • Device Bays
  • Wireless Links

Use case

This enhancement would streamline bulk data management and improve operational efficiency by allowing users to target specific devices within a site. It would also eliminate the need to manually look up device IDs for device's when you have an environment where devices share the same name across multiple sites.

Database changes

None

External dependencies

None

Originally created by @mkarel on GitHub (Aug 8, 2025). ### NetBox version v4.3.5 ### Feature type New functionality ### Proposed functionality Similar to Feature Request [19840](https://github.com/netbox-community/netbox/pull/19923) , it would be highly beneficial to extend site-based filtering capabilities to the bulk import process for the following object types: - Modules - Interfaces - Front Ports - Rear Ports - Console Ports - Console Server Ports - Power Ports - Power Outlets - Module Bays - Device Bays - Wireless Links ### Use case This enhancement would streamline bulk data management and improve operational efficiency by allowing users to target specific devices within a site. It would also eliminate the need to manually look up device IDs for device's when you have an environment where devices share the same name across multiple sites. ### Database changes None ### External dependencies None
adam added the type: feature label 2025-12-29 21:45:31 +01:00
adam closed this issue 2025-12-29 21:45:31 +01:00
adam commented 2025-12-29 21:45:32 +01:00
Author
Owner
Copy Link

@gadler01 commented on GitHub (Aug 8, 2025):

I agree with mkarel. We move datacenters and often have multiple sites containing the same device that is being moved.

@gadler01 commented on GitHub (Aug 8, 2025): I agree with mkarel. We move datacenters and often have multiple sites containing the same device that is being moved.
adam commented 2025-12-29 21:45:33 +01:00
Author
Owner
Copy Link

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

While I appreciate the use case, we cannot keep adding columns arbitrarily to the myriad import forms. (Consider hypothetical similar requests for location, region, etc.) If we want to support this functionality, a more robust mechanism of dynamically extending the import forms needs to be identified (e.g. by specifying device.site rather than treating site as its own field).

@jeremystretch commented on GitHub (Aug 14, 2025): While I appreciate the use case, we cannot keep adding columns arbitrarily to the myriad import forms. (Consider hypothetical similar requests for location, region, etc.) If we want to support this functionality, a more robust mechanism of dynamically extending the import forms needs to be identified (e.g. by specifying `device.site` rather than treating `site` as its own field).
adam commented 2025-12-29 21:45:33 +01:00
Author
Owner
Copy Link

@mkarel commented on GitHub (Aug 14, 2025):

@jeremystretch I agree that arbitrarily adding columns to a wide range of import forms wouldn’t be ideal. I also support enhancing import functionality to allow the use of objecttype.property (e.g., device.site) in import files, enabling additional fields to be populated and used to target devices if that is seen a better solution then adding site to each import function.

This feature request stemmed from a situation I encountered that closely mirrored the referenced issue. I was importing front and rear ports for patch panels at a site where we reused the same names due to our naming conventions. As a result, I had to rely on device.id to complete the import, which required extra effort. If I had been able to include the site name in the import to target only devices within that site, it would have saved a significant amount of time.

I believe @gadler01 ran into a similar challenge when importing interfaces, as device names are reused between the source and destination data centers.

Interestingly, your proposed solution is something I initially tried as a workaround.

@mkarel commented on GitHub (Aug 14, 2025): @jeremystretch I agree that arbitrarily adding columns to a wide range of import forms wouldn’t be ideal. I also support enhancing import functionality to allow the use of objecttype.property (e.g., device.site) in import files, enabling additional fields to be populated and used to target devices if that is seen a better solution then adding site to each import function. This feature request stemmed from a situation I encountered that closely mirrored the referenced issue. I was importing front and rear ports for patch panels at a site where we reused the same names due to our naming conventions. As a result, I had to rely on device.id to complete the import, which required extra effort. If I had been able to include the site name in the import to target only devices within that site, it would have saved a significant amount of time. I believe @gadler01 ran into a similar challenge when importing interfaces, as device names are reused between the source and destination data centers. Interestingly, your proposed solution is something I initially tried as a workaround.
adam commented 2025-12-29 21:45:33 +01:00
Author
Owner
Copy Link

@gadler01 commented on GitHub (Aug 15, 2025):

I agree wholeheartedly with @mkarel . We move datacenters and as such have duplicate devices in the source and the destination. In v3 this was possible because the device was unique per site. It's difficult with the dependence on to device.site being the requirement.

@gadler01 commented on GitHub (Aug 15, 2025): I agree wholeheartedly with @mkarel . We move datacenters and as such have duplicate devices in the source and the destination. In v3 this was possible because the device was unique per site. It's difficult with the dependence on to device.site being the requirement.
adam commented 2025-12-29 21:45:33 +01:00
Author
Owner
Copy Link

@arthanson commented on GitHub (Sep 11, 2025):

Thank you for your interest in extending NetBox. Unfortunately, as Jeremy pointed out we cannot keep adding arbitrary columns.

You are welcome to open a new feature request if there is another proposed solution beyond just adding some extra columns, but a fairly detailed implementation proposal would be needed. Per our contributing guide, a feature request must include a thorough description of the proposed functionality, including any database changes, new views or API endpoints, and so on. It must also include a detailed use case justifying its implementation.

@arthanson commented on GitHub (Sep 11, 2025): Thank you for your interest in extending NetBox. Unfortunately, as Jeremy pointed out we cannot keep adding arbitrary columns. You are welcome to open a new feature request if there is another proposed solution beyond just adding some extra columns, but a fairly detailed implementation proposal would be needed. Per our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md), a feature request must include a thorough description of the proposed functionality, including any database changes, new views or API endpoints, and so on. It must also include a detailed use case justifying its implementation.
adam commented 2025-12-29 21:45:34 +01:00
Author
Owner
Copy Link

@mkarel commented on GitHub (Sep 12, 2025):

Thanks again for reviewing this. I understand the reasoning behind closing the request.

I wanted to clarify that I don’t see this as “adding a column just to add a column.” For example, when importing interfaces for devices that share the same name across different sites, the only method is to use the <device.id> field—a workaround that’s not well documented and requires manually looking up each device ID.

Being able to include <device.site> alongside in the import would allow for better scoping and targeting of devices in these scenarios, making the process more intuitive and efficient.

Thanks again for all you do!

@mkarel commented on GitHub (Sep 12, 2025): Thanks again for reviewing this. I understand the reasoning behind closing the request. I wanted to clarify that I don’t see this as “adding a column just to add a column.” For example, when importing interfaces for devices that share the same name across different sites, the only method is to use the <device.id> field—a workaround that’s not well documented and requires manually looking up each device ID. Being able to include <device.site> alongside <device> in the import would allow for better scoping and targeting of devices in these scenarios, making the process more intuitive and efficient. Thanks again for all you do!
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 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#11459
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?