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

[candlerb]

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...

--> change the device selection -->

... 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:

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:
   

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.

[ZPrimed]

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

[candlerb]

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.

[jeremystretch]

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.

[github-actions]

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.

[jeremystretch]

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