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

Support for Cable Grouping #11477

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

Originally created by @0lini on GitHub (Aug 12, 2025).

NetBox version

v4.3.6

Feature type

Data model extension

Proposed functionality

Add a feature that allows grouping multiple individual cables into a single logical cable group or cable bundle. This would enable more intuitive representation of physical cable bundles or multi-fiber cables while maintaining the existing one-to-one cable-to-port connection model.

Additionally, it should be possible to assign attributes (e.g., length, installation date, route) at the cable group level that automatically apply or propagate to each cable within the group.

Use case

In fiber optic deployments, it is common to have a single physical cable containing multiple individual fibers—each terminated separately at patch panels or equipment ports. Technicians need to document not only the individual fiber connections but also the physical cable bundle as a whole.

For example, a 24-fiber cable running between two patch panels contains 24 separate fiber strands, each connecting specific ports. Currently, NetBox requires creating 24 separate cable records without a way to link them as part of the same physical cable bundle.

With cable grouping, users can:

  • Create a logical cable group representing the physical 24-fiber cable.
  • Assign attributes such as total cable length, installation date, or route to the group once.
  • Still manage each fiber strand as an individual cable with its own port termination.
  • Easily track, report, and maintain fiber infrastructure with both physical and logical clarity.

Database changes

To support cable grouping, the data model will need to be extended to represent collections of related cables as logical groups or bundles. Key changes may include:

  • A new entity to represent a logical grouping of multiple cables, which can store shared metadata such as group name, type, and common attributes (e.g., length, installation details).
  • Establish a relationship allowing multiple cable records to be linked to a single cable group, enabling one-to-many mapping.
  • Mechanisms to manage and propagate attributes assigned at the group level to the individual cables within the group, ensuring consistency and reducing redundant data entry.
  • Updates to API, UI, and business logic to support creation, modification, visualization, and querying of cable groups along with their member cables.

External dependencies

No response

Originally created by @0lini on GitHub (Aug 12, 2025). ### NetBox version v4.3.6 ### Feature type Data model extension ### Proposed functionality Add a feature that allows grouping multiple individual cables into a single logical cable group or cable bundle. This would enable more intuitive representation of physical cable bundles or multi-fiber cables while maintaining the existing one-to-one cable-to-port connection model. Additionally, it should be possible to assign attributes (e.g., length, installation date, route) at the cable group level that automatically apply or propagate to each cable within the group. ### Use case In fiber optic deployments, it is common to have a single physical cable containing multiple individual fibers—each terminated separately at patch panels or equipment ports. Technicians need to document not only the individual fiber connections but also the physical cable bundle as a whole. For example, a 24-fiber cable running between two patch panels contains 24 separate fiber strands, each connecting specific ports. Currently, NetBox requires creating 24 separate cable records without a way to link them as part of the same physical cable bundle. With cable grouping, users can: - Create a logical cable group representing the physical 24-fiber cable. - Assign attributes such as total cable length, installation date, or route to the group once. - Still manage each fiber strand as an individual cable with its own port termination. - Easily track, report, and maintain fiber infrastructure with both physical and logical clarity. ### Database changes To support cable grouping, the data model will need to be extended to represent collections of related cables as logical groups or bundles. Key changes may include: - A new entity to represent a logical grouping of multiple cables, which can store shared metadata such as group name, type, and common attributes (e.g., length, installation details). - Establish a relationship allowing multiple cable records to be linked to a single cable group, enabling one-to-many mapping. - Mechanisms to manage and propagate attributes assigned at the group level to the individual cables within the group, ensuring consistency and reducing redundant data entry. - Updates to API, UI, and business logic to support creation, modification, visualization, and querying of cable groups along with their member cables. ### External dependencies _No response_
adam added the type: feature label 2025-12-29 21:45:46 +01:00
adam closed this issue 2025-12-29 21:45:46 +01:00
adam commented 2025-12-29 21:45:47 +01:00
Author
Owner
Copy Link

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

This would be great. I ran into a similar issue with bundles of CAT6 cables for our DC structured cabling. So if this get approved please also include CATx cables.

@mkarel commented on GitHub (Aug 13, 2025): This would be great. I ran into a similar issue with bundles of CAT6 cables for our DC structured cabling. So if this get approved please also include CATx cables.
adam commented 2025-12-29 21:45:47 +01:00
Author
Owner
Copy Link

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

A nice to have feature on this would be to have it support nested groups. For example, one group to represent a 144F optical cable, with 12 child groups for each of the buffer tubes/ribbons, which then in turn contains 12 individual fiber strands. Being able to color the group, like you can with the cables themselves, would also be a nice feature and help with documentation. I don't see a reason to limit this to a particular type of cable, but, if so, we would need it for power as well, so we can group the battery and return cables together for our DC power plant.

@sleepinggenius2 commented on GitHub (Aug 14, 2025): A nice to have feature on this would be to have it support nested groups. For example, one group to represent a 144F optical cable, with 12 child groups for each of the buffer tubes/ribbons, which then in turn contains 12 individual fiber strands. Being able to color the group, like you can with the cables themselves, would also be a nice feature and help with documentation. I don't see a reason to limit this to a particular type of cable, but, if so, we would need it for power as well, so we can group the battery and return cables together for our DC power plant.
adam commented 2025-12-29 21:45:48 +01:00
Author
Owner
Copy Link

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

In fiber optic deployments, it is common to have a single physical cable containing multiple individual fibers—each terminated separately at patch panels or equipment ports. Technicians need to document not only the individual fiber connections but also the physical cable bundle as a whole.

This is not what I would call a bundle, though: It's a single cable with dozens of individual fiber strands within it. While introducing the concept of a cable bundle may be useful to represent e.g. 24 CAT6 cables zip-tied together between patch panels, I don't think it's a good solution for your use case regarding multi-strand fiber.

This is an area that has been on our backlog to explore further.

@jeremystretch commented on GitHub (Aug 14, 2025): > In fiber optic deployments, it is common to have a single physical cable containing multiple individual fibers—each terminated separately at patch panels or equipment ports. Technicians need to document not only the individual fiber connections but also the physical cable bundle as a whole. This is not what I would call a bundle, though: It's a single cable with dozens of individual fiber strands within it. While introducing the concept of a cable bundle may be useful to represent e.g. 24 CAT6 cables zip-tied together between patch panels, I don't think it's a good solution for your use case regarding multi-strand fiber. This is an area that has been on our backlog to explore further.
adam commented 2025-12-29 21:45:48 +01:00
Author
Owner
Copy Link

@0lini commented on GitHub (Aug 15, 2025):

In fiber optic deployments, it is common to have a single physical cable containing multiple individual fibers—each terminated separately at patch panels or equipment ports. Technicians need to document not only the individual fiber connections but also the physical cable bundle as a whole.

This is not what I would call a bundle, though: It's a single cable with dozens of individual fiber strands within it. While introducing the concept of a cable bundle may be useful to represent e.g. 24 CAT6 cables zip-tied together between patch panels, I don't think it's a good solution for your use case regarding multi-strand fiber.

This is an area that has been on our backlog to explore further.

Thanks for clarifying — yes, I agree this is indeed a multi-strand cable scenario rather than a traditional “bundle” of separate cables.

My goal is to be able to model a single physical cable (e.g., a 24-fiber trunk) with individually addressable strands that can each be terminated and traced, while keeping the physical attributes (length, route, installation details) at the parent cable level.

@0lini commented on GitHub (Aug 15, 2025): > > In fiber optic deployments, it is common to have a single physical cable containing multiple individual fibers—each terminated separately at patch panels or equipment ports. Technicians need to document not only the individual fiber connections but also the physical cable bundle as a whole. > > This is not what I would call a bundle, though: It's a single cable with dozens of individual fiber strands within it. While introducing the concept of a cable bundle may be useful to represent e.g. 24 CAT6 cables zip-tied together between patch panels, I don't think it's a good solution for your use case regarding multi-strand fiber. > > This is an area that has been on our backlog to explore further. Thanks for clarifying — yes, I agree this is indeed a multi-strand cable scenario rather than a traditional “bundle” of separate cables. My goal is to be able to model a single physical cable (e.g., a 24-fiber trunk) with individually addressable strands that can each be terminated and traced, while keeping the physical attributes (length, route, installation details) at the parent cable level.
adam commented 2025-12-29 21:45:49 +01:00
Author
Owner
Copy Link

@0lini commented on GitHub (Aug 15, 2025):

Should I create a separate FR for multiple conductors in a single cable scenario?

@0lini commented on GitHub (Aug 15, 2025): Should I create a separate FR for multiple conductors in a single cable scenario?
adam commented 2025-12-29 21:45:49 +01:00
Author
Owner
Copy Link

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

What sounds simple gets quiet complex when tracing connectivity. I agree with Jeremy this needs to be explored further. As someone who has deployed cable management systems i can attest to the complexity detail can bring.

@mistn003 commented on GitHub (Aug 15, 2025): What sounds simple gets quiet complex when tracing connectivity. I agree with Jeremy this needs to be explored further. As someone who has deployed cable management systems i can attest to the complexity detail can bring.
adam commented 2025-12-29 21:45:49 +01:00
Author
Owner
Copy Link

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

I've just opened FR #20151 to break out the idea of cable bundles and avoid confusion. That will likely be tagged for a future milestone.

I don't think there's anything else we can do with this FR at the moment so I'm going to close it out. As I mentioned, the management of individual fiber strands and related concepts has been on our backlog to explore, and is sure to require lengthy research and discussion. I'm hopeful that we can make some progress on this topic in the near future.

@jeremystretch commented on GitHub (Aug 21, 2025): I've just opened FR #20151 to break out the idea of cable bundles and avoid confusion. That will likely be tagged for a future milestone. I don't think there's anything else we can do with this FR at the moment so I'm going to close it out. As I mentioned, the management of individual fiber strands and related concepts has been on our backlog to explore, and is sure to require lengthy research and discussion. I'm hopeful that we can make some progress on this topic in the near future.
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#11477
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?