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

Show existing and new connections #8936

New Issue
Closed
opened 2025-12-29 20:43:04 +01:00 by adam · 4 comments
adam commented 2025-12-29 20:43:04 +01:00
Owner
Copy Link

Originally created by @Projects0987 on GitHub (Dec 8, 2023).

NetBox version

3.6.6

Feature type

New functionality

Proposed functionality

The ability to have on an interface a new (purposed) connection so that it can show a connection to a new interface on a future moved,

Use case

If moving connections on a future project/move you can show on an interface the new connection. For example there is a connection from Device A - Device B and there is plans to move the connection on Device A to Device C. This would a an option similar to a virtual interface but can create a connection showing that it a planned/new connection. This would show up under the existing connection.

Database changes

Add to an interface the ability to create a planned connection under the existing connection.

External dependencies

No response

Originally created by @Projects0987 on GitHub (Dec 8, 2023). ### NetBox version 3.6.6 ### Feature type New functionality ### Proposed functionality The ability to have on an interface a new (purposed) connection so that it can show a connection to a new interface on a future moved, ### Use case If moving connections on a future project/move you can show on an interface the new connection. For example there is a connection from Device A - Device B and there is plans to move the connection on Device A to Device C. This would a an option similar to a virtual interface but can create a connection showing that it a planned/new connection. This would show up under the existing connection. ### Database changes Add to an interface the ability to create a planned connection under the existing connection. ### External dependencies _No response_
adam added the type: feature label 2025-12-29 20:43:04 +01:00
adam closed this issue 2025-12-29 20:43:04 +01:00
adam commented 2025-12-29 20:43:04 +01:00
Author
Owner
Copy Link

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

Thanks for your request to add new functionality to NetBox. The proposed functionality section of your issue appears to be cut off, did you mean to write more?

The idea of a “connection in waiting” has clear value in networks that see regular changes. When gamed out, though, it appears at risk of blossoming into a major engineering project. It seems the network model in NetBox would need to be versioned much like a source control repository. That is a beautiful dream, but probably somewhat impractical.

If this assessment is off base, please update your issue to clarify the scope of your vision for the requested functionality.

@jeffgdotorg commented on GitHub (Dec 8, 2023): Thanks for your request to add new functionality to NetBox. The *proposed functionality* section of your issue appears to be cut off, did you mean to write more? The idea of a “connection in waiting” has clear value in networks that see regular changes. When gamed out, though, it appears at risk of blossoming into a major engineering project. It seems the network model in NetBox would need to be versioned much like a source control repository. That is a beautiful dream, but probably somewhat impractical. If this assessment is off base, please update your issue to clarify the scope of your vision for the requested functionality.
adam commented 2025-12-29 20:43:05 +01:00
Author
Owner
Copy Link

@Projects0987 commented on GitHub (Dec 9, 2023):

Sorry to make the proposed not fully clear. Right now you can create a child interface but it is only a virtual interface. What I'm proposing is the ability to add a something like a child interface but it be able to make a connection from that "child interface" to either another "child interface" or just a normal interface and have it marked as planed. Hope this makes it clearer.

@Projects0987 commented on GitHub (Dec 9, 2023): Sorry to make the proposed not fully clear. Right now you can create a child interface but it is only a virtual interface. What I'm proposing is the ability to add a something like a child interface but it be able to make a connection from that "child interface" to either another "child interface" or just a normal interface and have it marked as planed. Hope this makes it clearer.
adam commented 2025-12-29 20:43:05 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Dec 9, 2023):

I thought I once submitted a similar FR, but can't find it anymore.

My proposal would be to allow 2 cables to one interface.
Only one can be in connected state, the other should be in planned or decommissioning state.
That way, you don't need to create temp interfaces and rename them.

@PieterL75 commented on GitHub (Dec 9, 2023): I thought I once submitted a similar FR, but can't find it anymore. My proposal would be to allow 2 cables to one interface. Only one can be in connected state, the other should be in planned or decommissioning state. That way, you don't need to create temp interfaces and rename them.
adam commented 2025-12-29 20:43:06 +01:00
Author
Owner
Copy Link

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

My proposal would be to allow 2 cables to one interface.

This would be in stark violation of a guiding tenet: Model the real world. Not to mention it would be incredibly complex to validate, and offers no additional potential between two possible states.

What this FR boils down to is attempting to track multiple states in parallel, which is not something that NetBox currently supports. Although it's something we may explore in the future, this is a much, much broader topic than the representation of cables. I'm going to close this out as something that we're not currently able to support.

@jeremystretch commented on GitHub (Dec 14, 2023): > My proposal would be to allow 2 cables to one interface. This would be in stark violation of a guiding tenet: Model the real world. Not to mention it would be incredibly complex to validate, and offers no additional potential between two possible states. What this FR boils down to is attempting to track multiple states in parallel, which is not something that NetBox currently supports. Although it's something we may explore in the future, this is a much, _much_ broader topic than the representation of cables. I'm going to close this out as something that we're not currently able to support.
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#8936
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?