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

Cable Export current format is not able to be used for import #4642

New Issue
Closed
opened 2025-12-29 19:19:03 +01:00 by adam · 13 comments
adam commented 2025-12-29 19:19:03 +01:00
Owner
Copy Link

Originally created by @jcralbino on GitHub (Mar 10, 2021).

NetBox version

v2.10.5

Feature type

Change to existing functionality

Proposed functionality

When we export the cable from the URL /dcim/cables/
We get a file with this headers:
"termination_a_type termination_a_id termination_b_type termination_b_id type status label color length length_unit"
This is not able to be used directly for the import feature.
I propose to have also an export option, following with the same headers used in the import option.
This are
side_a_device,side_a_type,side_a_name,side_b_device,side_b_type,side_b_name

Use case

To simplify the population of cabling having an export that provides a correct template to be used is extremely valuable. This enables all users to do a bulk creation of the cables.
It also allows us to export the information, and if we have the name of the devices we can used this to provide additional information to other field teams.

This allow to have a more friendly and intuitive UI

Database changes

No DB Changes required

External dependencies

No additional Dependencies

Originally created by @jcralbino on GitHub (Mar 10, 2021). ### NetBox version v2.10.5 ### Feature type Change to existing functionality ### Proposed functionality When we export the cable from the URL /dcim/cables/ We get a file with this headers: "termination_a_type termination_a_id termination_b_type termination_b_id type status label color length length_unit" This is not able to be used directly for the import feature. I propose to have also an export option, following with the same headers used in the import option. This are side_a_device,side_a_type,side_a_name,side_b_device,side_b_type,side_b_name ### Use case To simplify the population of cabling having an export that provides a correct template to be used is extremely valuable. This enables all users to do a bulk creation of the cables. It also allows us to export the information, and if we have the name of the devices we can used this to provide additional information to other field teams. This allow to have a more friendly and intuitive UI ### Database changes No DB Changes required ### External dependencies No additional Dependencies
adam added the type: featurestatus: needs ownerpending closure labels 2025-12-29 19:19:03 +01:00
adam closed this issue 2025-12-29 19:19:03 +01:00
adam commented 2025-12-29 19:19:03 +01:00
Author
Owner
Copy Link

@hellerve commented on GitHub (Apr 7, 2021):

Hey! I’d be happy to work on this. I’d say the side_* format is preferable, since it’s more human-readable than IDs; does that match what y’all think?

@hellerve commented on GitHub (Apr 7, 2021): Hey! I’d be happy to work on this. I’d say the `side_*` format is preferable, since it’s more human-readable than IDs; does that match what y’all think?
adam commented 2025-12-29 19:19:04 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 7, 2021):

Hey @hellerve! I haven't had much time to dig into this yet, though one issue is that the current import format doesn't allow for connecting cables to circuit terminations or power feeds.

@jeremystretch commented on GitHub (Apr 7, 2021): Hey @hellerve! I haven't had much time to dig into this yet, though one issue is that the current import format doesn't allow for connecting cables to circuit terminations or power feeds.
adam commented 2025-12-29 19:19:04 +01:00
Author
Owner
Copy Link

@hellerve commented on GitHub (Apr 7, 2021):

Oh, that makes sense! This is because circuit terminations are part of circuits and power feeds of power panels instead of devices, is that correct? I suppose one could add those as keys as well, but I understand how that just complicates things and makes them finnicky...

@hellerve commented on GitHub (Apr 7, 2021): Oh, that makes sense! This is because circuit terminations are part of circuits and power feeds of power panels instead of devices, is that correct? I suppose one could add those as keys as well, but I understand how that just complicates things and makes them finnicky...
adam commented 2025-12-29 19:19:04 +01:00
Author
Owner
Copy Link

@hellerve commented on GitHub (Apr 7, 2021):

How about adding side_a_parent_type and side_a_parent_name (for both sides, of course), similar to what we have for the actual components?

@hellerve commented on GitHub (Apr 7, 2021): How about adding `side_a_parent_type` and `side_a_parent_name` (for both sides, of course), similar to what we have for the actual components?
adam commented 2025-12-29 19:19:04 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 7, 2021):

Yeah, we'll probably need to take that sort of approach. It gets tricky though, because circuits for example don't have a name field. The simplest way is to specify a (type, ID) tuple (like how the current CSV export works), but of course that's not terribly user-friendly.

@jeremystretch commented on GitHub (Apr 7, 2021): Yeah, we'll probably need to take that sort of approach. It gets tricky though, because circuits for example don't have a `name` field. The simplest way is to specify a (type, ID) tuple (like how the current CSV export works), but of course that's not terribly user-friendly.
adam commented 2025-12-29 19:19:05 +01:00
Author
Owner
Copy Link

@hellerve commented on GitHub (Apr 7, 2021):

Right, that all makes sense. I’ll try to tinker with it a bit tomorrow and see whether I can come up with something complete and UX-friendly.

@hellerve commented on GitHub (Apr 7, 2021): Right, that all makes sense. I’ll try to tinker with it a bit tomorrow and see whether I can come up with something complete and UX-friendly.
adam commented 2025-12-29 19:19:05 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Nov 12, 2021):

The default CSV export format with v3.0.9 is even less compatible with import:

  • there is a single column "Length" which contains a value like 300.00 Centimeters (import requires separate length and length_unit columns)
  • although type/length/label are present, "color" is missing
@candlerb commented on GitHub (Nov 12, 2021): The default CSV export format with v3.0.9 is even less compatible with import: - there is a single column "Length" which contains a value like `300.00 Centimeters` (import requires separate `length` and `length_unit` columns) - although type/length/label are present, "color" is missing
adam commented 2025-12-29 19:19:05 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Nov 12, 2021):

If you ignore circuits for now, it's possible to use an export template to format the cable data in a way that's compatible with import: see https://github.com/netbox-community/netbox/discussions/7792#discussioncomment-1631444

Some care is required because an error in the export template causes silent fallback to standard CSV export: #7813

@candlerb commented on GitHub (Nov 12, 2021): If you ignore circuits for now, it's possible to use an export template to format the cable data in a way that's compatible with import: see https://github.com/netbox-community/netbox/discussions/7792#discussioncomment-1631444 Some care is required because an error in the export template causes silent fallback to standard CSV export: #7813
adam commented 2025-12-29 19:19:06 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jan 12, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jan 12, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:19:06 +01:00
Author
Owner
Copy Link

@xenDE commented on GitHub (Jan 19, 2022):

please add compatible import/export format.

its horrible to add rear-port cables of multiple 48port patch pannels.
or allow regex like "Patch123-c[1-48] >> Patch456-c[1-48]" for adding cables.

this is a real show stopper here. i have no idea, how users add the cables between patchpannels.

@xenDE commented on GitHub (Jan 19, 2022): please add compatible import/export format. its horrible to add rear-port cables of multiple 48port patch pannels. or allow regex like "Patch123-c[1-48] >> Patch456-c[1-48]" for adding cables. this is a real show stopper here. i have no idea, how users add the cables between patchpannels.
adam commented 2025-12-29 19:19:06 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Jan 19, 2022):

If you want to create bulk connections between patch panels, then use the custom script here. It supports patterns like you showed. Also ref. previous issue #2855 specifically for this use case (but it's locked)

If you want to export cables in CSV format so that you can modify them and re-import them, then use the cable export template here.

@candlerb commented on GitHub (Jan 19, 2022): If you want to create bulk connections between patch panels, then use the custom script [here](https://github.com/netbox-community/reports/blob/master/scripts/multi_connect.py). It supports patterns like you showed. Also ref. previous issue #2855 specifically for this use case (but it's locked) If you want to export cables in CSV format so that you can modify them and re-import them, then use the cable export template [here](https://github.com/netbox-community/netbox/discussions/7792#discussioncomment-1631444).
adam commented 2025-12-29 19:19:06 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 19, 2022):

@xenDE please don't comment on feature requests to ask for assistance. If you'd like help figuring out how to accomplish something in NetBox, please open a discussion.

@jeremystretch commented on GitHub (Jan 19, 2022): @xenDE please don't comment on feature requests to ask for assistance. If you'd like help figuring out how to accomplish something in NetBox, please open a [discussion](https://github.com/netbox-community/netbox/discussions/new).
adam commented 2025-12-29 19:19:06 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 18, 2022):

Closing for inactivity

@jeremystretch commented on GitHub (Feb 18, 2022): Closing for inactivity
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 pending closure status: needs owner 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#4642
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?