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

Usability: cable ends "don't change" unless you deselect and reselect interface #7203

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

Originally created by @candlerb on GitHub (Nov 4, 2022).

NetBox version

v3.3.7

Python version

3.8

Steps to Reproduce

  1. Create a device type with at least one physical 1000baseT interface - say "en0"
  2. Create three devices of this device type - say "dev1", "dev2", "dev3".
  3. Create a cable from dev1 en0 (A end) to dev2 en0 (B end)
  4. Edit this cable
  5. Change the A end device from dev1 to dev3 (but the user doesn't touch the selected interface; it already displays "en0" which is what we want)
  6. Save the cable

Expected Behavior

Cable to be changed so that it connects dev3 en0 to dev2 en0.

Observed Behavior

Nothing happens: there is a pop-up saying Modified cable #NNN but the cable remains as it was before, with the A end on dev1 en0.

What I think is happening: when you change the A end device from "dev1" to "dev3", you still see "en0" selected...

image
--> change the device selection -->
image

... but I believe that this "en0" still refers to "the en0 on dev1" rather than "the en0 on dev3".

Workaround

Delete and re-add the en0 selection next to Interface*. Now if you save, the change is accepted. (However the screen looks identical in both cases, and it's very confusing)

Solution

It note that it is permitted for one end of a cable to connect to two or more different interfaces on different devices. For example, I can connect the A end of this cable to dev1 en0 and dev3 en0 simultaneously. If I then edit this cable, I see:

image

I presume this is an intentional feature, e.g. for modelling QSFP breakout cables where one "end" goes to multiple devices.

If so, then I think the problem is that the interface names are not sufficiently distinguished. In that case, I suggest that either:

  1. They should all be labelled with the device ("dev1 en0", "dev3 en0"); or
  2. The labels can show just the interface name when the device name matches the device selected in the field above, but are qualified with the device name when the device name is different from the selection. For example, if you have selected "dev1" then the interfaces would show "en0" and "dev3 en0", like this:
    image

Option 2 is less visually cluttered for the majority case where all the terminations are associated with a single device. In this case, if you had a single endpoint but you change the device to "dev3" then the interface list would change to show "dev1 en0", and it would be clear that this isn't the interface you want to connect to.

Alternatively, it could be clearer to rework the UI to have each set of terminations on a particular device grouped together, e.g.

  • Device: dev1
  • Interfaces: en0
  • Device: dev3
  • Interfaces: en0
  • + (add another device - adds another row)

Then inside each list of interfaces, you could only select ones relating to the selected device. And if you change the selected device in a given row, it could either blank out the list of interfaces, or replace them with interfaces with corresponding names.

Originally created by @candlerb on GitHub (Nov 4, 2022). ### NetBox version v3.3.7 ### Python version 3.8 ### Steps to Reproduce 1. Create a device type with at least one physical 1000baseT interface - say "en0" 2. Create three devices of this device type - say "dev1", "dev2", "dev3". 3. Create a cable from dev1 en0 (A end) to dev2 en0 (B end) 4. Edit this cable 5. Change the A end device from dev1 to dev3 (but the user doesn't touch the selected interface; it already displays "en0" which is what we want) 6. Save the cable ### Expected Behavior Cable to be changed so that it connects dev3 en0 to dev2 en0. ### Observed Behavior Nothing happens: there is a pop-up saying `Modified cable #NNN` but the cable remains as it was before, with the A end on dev1 en0. What I think is happening: when you change the A end device from "dev1" to "dev3", you still see "en0" selected... ![image](https://user-images.githubusercontent.com/44789/199967496-a2b422e2-5fbd-466b-b627-9eadaca43377.png) --> change the device selection --> ![image](https://user-images.githubusercontent.com/44789/199967518-636155a7-ca19-4a48-b990-b4128f33e1ac.png) ... but I believe that this "en0" still refers to "the en0 on dev1" rather than "the en0 on dev3". ### Workaround Delete and re-add the en0 selection next to __Interface\*__. Now if you save, the change is accepted. (However the screen looks identical in both cases, and it's very confusing) ### Solution It note that it is permitted for one end of a cable to connect to two or more different interfaces *on different devices*. For example, I can connect the A end of this cable to dev1 en0 and dev3 en0 simultaneously. If I then edit this cable, I see: ![image](https://user-images.githubusercontent.com/44789/199970990-a943cfc7-8f58-41f1-9c92-e73af0205d2f.png) I presume this is an intentional feature, e.g. for modelling QSFP breakout cables where one "end" goes to multiple devices. If so, then I think the problem is that the interface names are not sufficiently distinguished. In that case, I suggest that either: 1. They should all be labelled with the device ("dev1 en0", "dev3 en0"); or 2. The labels can show just the interface name when the device name matches the device selected in the field above, but are qualified with the device name when the device name is different from the selection. For example, if you have selected "dev1" then the interfaces would show "en0" and "dev3 en0", like this: ![image](https://user-images.githubusercontent.com/44789/199971381-69c7d05b-d279-49a4-ba51-c0dd26266e01.png) Option 2 is less visually cluttered for the majority case where all the terminations are associated with a single device. In this case, if you had a single endpoint but you change the device to "dev3" then the interface list would change to show "dev1 en0", and it would be clear that this isn't the interface you want to connect to. Alternatively, it could be clearer to rework the UI to have each set of terminations on a particular device grouped together, e.g. * Device: dev1 * Interfaces: en0 * Device: dev3 * Interfaces: en0 * `+` (add another device - adds another row) Then inside each list of interfaces, you could only select ones relating to the selected device. And if you change the selected device in a given row, it could either blank out the list of interfaces, or replace them with interfaces with corresponding names.
adam added the type: bug label 2025-12-29 20:20:25 +01:00
adam closed this issue 2025-12-29 20:20:25 +01:00
adam commented 2025-12-29 20:20:26 +01:00
Author
Owner
Copy Link

@ZPrimed commented on GitHub (Nov 16, 2022):

I believe this is a similar bug as described in #10757, just with cables instead of IPs...

@ZPrimed commented on GitHub (Nov 16, 2022): I believe this is a similar bug as described in #10757, just with cables instead of IPs...
adam commented 2025-12-29 20:20:26 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Nov 16, 2022):

Thanks, yes it's similar. However unlike an IP address assignment, a cable endpoint can be asigned to multiple interfaces on multiple devices simultaneously This means that simply clearing the list of interfaces when you change the selected device is not a solution here.

@candlerb commented on GitHub (Nov 16, 2022): Thanks, yes it's similar. However unlike an IP address assignment, a cable endpoint can be asigned to multiple interfaces on multiple devices simultaneously This means that simply clearing the list of interfaces when you change the selected device is not a solution here.
adam commented 2025-12-29 20:20:26 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 16, 2022):

I presume this is an intentional feature, e.g. for modelling QSFP breakout cables where one "end" goes to multiple devices.

Correct. Altering this behavior without devising a new mechanism for the selection of components would break the ability to terminate a cable to components across different devices.

Any work in this regard is likely going to depend on #10054.

@jeremystretch commented on GitHub (Nov 16, 2022): > I presume this is an intentional feature, e.g. for modelling QSFP breakout cables where one "end" goes to multiple devices. Correct. Altering this behavior without devising a new mechanism for the selection of components would break the ability to terminate a cable to components across different devices. Any work in this regard is likely going to depend on #10054.
adam commented 2025-12-29 20:20:27 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Apr 12, 2023):

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. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Apr 12, 2023): 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. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:20:27 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 12, 2023):

This will be addressed when the cable creation view & form are overhauled as part of #12127 in v3.5.

@jeremystretch commented on GitHub (Apr 12, 2023): This will be addressed when the cable creation view & form are overhauled as part of #12127 in v3.5.
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: bug
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#7203
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?