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

Wireless Link Bulk Import-Device/interface #11181

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

Originally created by @mblumber1 on GitHub (May 15, 2025).

Originally assigned to: @pheus on GitHub.

NetBox version

v4.1.11

Feature type

Change to existing functionality

Proposed functionality

The bulk import functionality for wireless links (https://netbox-demo.netboxlabs.com/wireless/wireless-links/import/) has interface_a and interface_z. What it should have is device_a, interface_a, device_z, interface_z. That would allow us to bulk-import our wireless links.

Use case

I am documenting a wireless ISP where all our radios have the similar interface names (they are unique to the device, not globally unique). I'd like to import our wireless links rather than building them manually. I'm willing to use json / yaml but I cannot figure how to do it even with that. I believe that this functionality would need to be added.

Database changes

None

External dependencies

None

Originally created by @mblumber1 on GitHub (May 15, 2025). Originally assigned to: @pheus on GitHub. ### NetBox version v4.1.11 ### Feature type Change to existing functionality ### Proposed functionality The bulk import functionality for wireless links (https://netbox-demo.netboxlabs.com/wireless/wireless-links/import/) has interface_a and interface_z. What it should have is device_a, interface_a, device_z, interface_z. That would allow us to bulk-import our wireless links. ### Use case I am documenting a wireless ISP where all our radios have the similar interface names (they are unique to the device, not globally unique). I'd like to import our wireless links rather than building them manually. I'm willing to use json / yaml but I cannot figure how to do it even with that. I believe that this functionality would need to be added. ### Database changes None ### External dependencies None
adam added the status: acceptedtype: featurecomplexity: medium labels 2025-12-29 21:41:27 +01:00
adam closed this issue 2025-12-29 21:41:27 +01:00
adam commented 2025-12-29 21:41:28 +01:00
Author
Owner
Copy Link

@pheus commented on GitHub (Jun 4, 2025):

Thanks for the suggestion - I’ve looked into it a bit.

It seems that the current WirelessLink bulk import form expects the interface_a and interface_b fields to be populated with interface IDs, which are unique but not very intuitive to work with, especially in bulk.

If I understand your request correctly, you're proposing the ability to specify devices and interfaces by name instead — e.g., device_a, interface_a, device_b, interface_b. That definitely makes sense for situations where interface names are only unique per device (which is common), and would greatly improve the usability of the import form.

One thought: to ensure device names are uniquely resolved, this might also require including the site (or site_a / site_b) fields, since device names may not be globally unique across sites.

I also need to take a look at the Cable import form to see how it handles device/interface references — it would make sense for these import mechanisms to be consistent.

This sounds like a good quality-of-life improvement.

@pheus commented on GitHub (Jun 4, 2025): Thanks for the suggestion - I’ve looked into it a bit. It seems that the current WirelessLink bulk import form expects the `interface_a` and `interface_b` fields to be populated with interface **IDs**, which are unique but not very intuitive to work with, especially in bulk. If I understand your request correctly, you're proposing the ability to specify devices and interfaces by name instead — e.g., `device_a`, `interface_a`, `device_b`, `interface_b`. That definitely makes sense for situations where interface names are only unique per device (which is common), and would greatly improve the usability of the import form. One thought: to ensure device names are uniquely resolved, this might also require including the `site` (or `site_a` / `site_b`) fields, since device names may not be globally unique across sites. I also need to take a look at the Cable import form to see how it handles device/interface references — it would make sense for these import mechanisms to be consistent. This sounds like a good quality-of-life improvement.
adam commented 2025-12-29 21:41:28 +01:00
Author
Owner
Copy Link

@mblumber1 commented on GitHub (Jun 4, 2025):

Thanks. First I want to thank you for providing the fact that I can use interface IDs; with some creative cross-referencing and db lookups, I can make this bulk import work as it is.

I also agree that this import should be consistent across similar types. You mention cable, the other similar data type is circuit; today you can do a bulk import of circuit information (site/equipment/port) using yaml or json but not with CSV. All three of these (cable, circuit, wireless link) should have site_a/b, device_a/b and interface_a/b in their CSV import template. Actually, is there a restriction that cables have to be local to one site (making the site_a/b potentially unnecessary)?

@mblumber1 commented on GitHub (Jun 4, 2025): Thanks. First I want to thank you for providing the fact that I can use interface IDs; with some creative cross-referencing and db lookups, I can make this bulk import work as it is. I also agree that this import should be consistent across similar types. You mention cable, the other similar data type is circuit; today you can do a bulk import of circuit information (site/equipment/port) using yaml or json but not with CSV. All three of these (cable, circuit, wireless link) should have site_a/b, device_a/b and interface_a/b in their CSV import template. Actually, is there a restriction that cables have to be local to one site (making the site_a/b potentially unnecessary)?
adam commented 2025-12-29 21:41:36 +01:00
Author
Owner
Copy Link

@pheus commented on GitHub (Jun 6, 2025):

Thanks — I didn’t expect that either, so it definitely feels like something that should either be documented more clearly or ideally changed to allow using names instead of IDs.

Regarding circuits:

I assume you're referring to the CircuitTermination bulk import form, which serves a different purpose than the import forms for Cables and WirelessLinks.

I haven’t used circuits extensively, so I might be missing some nuance, but from my understanding, a circuit defines two circuit terminations (A and Z) of a specific type. If the termination is something other than a provider network, it's possible to reference a CableTermination.

So in that case, the circuit doesn't directly reference devices/interfaces — it goes through the CableTermination.

After looking into the CableImportForm, I’ve noticed that there is only a Device field for Side A and B, but it’s missing the Site field. In addition, the import form does not handle the CircuitTermination case. Since this is clearly out of scope for the current issue, I’d suggest we focus on improving the WirelessLink import form for now.

That said, it might be worth opening a separate feature request to allow importing cables that terminate on a CircuitTermination.

As for cables and site limitations:

No, there's no restriction that both ends of a cable must be within the same site. You can definitely create a cable between devices in different sites — though depending on your use case, it might be helpful to make that relationship more explicit during import (e.g., through site_a / site_b), as you suggested.

@pheus commented on GitHub (Jun 6, 2025): Thanks — I didn’t expect that either, so it definitely feels like something that should either be documented more clearly or ideally changed to allow using names instead of IDs. ### Regarding circuits: I assume you're referring to the `CircuitTermination` bulk import form, which serves a different purpose than the import forms for Cables and WirelessLinks. I haven’t used circuits extensively, so I might be missing some nuance, but from my understanding, a circuit defines two circuit terminations (A and Z) of a specific type. If the termination is something other than a provider network, it's possible to reference a `CableTermination`. So in that case, the circuit doesn't directly reference devices/interfaces — it goes through the `CableTermination`. After looking into the `CableImportForm`, I’ve noticed that there is only a `Device` field for Side A and B, but it’s missing the `Site` field. In addition, the import form does not handle the `CircuitTermination` case. Since this is clearly out of scope for the current issue, I’d suggest we focus on improving the `WirelessLink` import form for now. That said, it might be worth opening a separate feature request to allow importing cables that terminate on a `CircuitTermination`. ### As for cables and site limitations: No, there's no restriction that both ends of a cable must be within the same site. You can definitely create a cable between devices in different sites — though depending on your use case, it might be helpful to make that relationship more explicit during import (e.g., through `site_a` / `site_b`), as you suggested.
adam commented 2025-12-29 21:41:36 +01:00
Author
Owner
Copy Link

@pheus commented on GitHub (Jun 6, 2025):

I'd like to give this a try. Can I be assigned?
Thanks!

@pheus commented on GitHub (Jun 6, 2025): I'd like to give this a try. Can I be assigned? Thanks!
adam commented 2025-12-29 21:41:36 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 9, 2025):

@pheus assigned to you, thanks!

@jeremystretch commented on GitHub (Jun 9, 2025): @pheus assigned to you, thanks!
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 complexity: medium 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#11181
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?