Connect Form | filter devices which have the chosen Connector Type

[teixemf]

NetBox version

v2.11 beta

Feature type

Change to existing functionality

Proposed functionality

While trying to connect an Interface/Front Port/Rear Port/Circuit Termination to a device, on the Connect Form, the list of devices available to be chosen should be limited to the devices which have the chosen Connector Type.
Same for Power Outlet/Power Feed.

Use case

If for instance, I choose to connect a Switch interface to a Front Port it would be expected to be able to chose from a list of devices which have Front Ports (like patch-panels) and not all the devices available on the rack.
On racks with many devices this could really help to narrow down the devices list.

Database changes

No DB changes.

External dependencies

No dependencies.

[jeremystretch]

I think the idea makes sense in principle, however I worry about the potential it introduces for confusion. For example, suppose a device mistakenly has its console port deleted. When a user goes to connect a cable to a console port and looks for the device, it won't be listed, and it won't be immediately apparent to the user why the device has been omitted.

[phurrelmann]

I see you point Jeremy, but the current situation is more prone to errors. It happens quite often that one inadvertently selects "interface" instead of rear or front ports and only realizes that mistake when the connections dialog errors out late due to mismatching types and makes you re-enter all cable details again. Especially with rear and front ports this gets more attraction. In general there are probably more devices with interfaces in a rack than devices with front and rear ports. Working with front and rear ports always shows all devices in the corresponding dropdowns.
This on my wish list for a long time, but I admit that this is not a blocking issue. It just may improve usability besides sacrificing the edge case you described.

[jeremystretch]

Let me put it this way. Suppose we implement your proposed change, and the next week we get a new bug report:

I was trying to connect a cable to a particular device, but it wasn't showing up in the list. A bunch of other device were, but this one was missing. I thought maybe it was a caching problem so I cleared out the cache, but it didn't help. I double-checked that the device definitely exists and is assigned to the correct site and rack. It was only after 15 minutes of troubleshooting that I realized the device's console port had gotten deleted at some point! Once I added the console port, the device appeared in the list. Please fix NetBox to show all devices when attempting to connect a cable so we can avoid future headaches!

Sounds very reasonable to me.

[jeremystretch]

Discussed this with the other maintainers today. Another option proposed by @checktheroads was to include inapplicable devices but mark them as disabled in the dropdown list. I like this approach, however we should consider the additional performance penalty being imposed (to check for the appropriate type of component assigned to each device in the list).

We would be able to work around the performance penalty by caching e.g. _console_port_count on the Device model. This would also come in handy for the UI, where we display a count of each component type assigned to a device.

[jeremystretch]

I've opened #6347 for component count caching; marking this as blocked for now.

[sdktr]

On our custom frontend we show the inapplicable items as well. We however try to explain WHY an item is unselectable, which greatly helps in the user experience.

Eg: 'Another Circuit is already connected' is shown when hovering the greyed out option. (We use a modal, not a dropdown)

[llamafilm]

I would also like to see this feature implemented. It would make it much easier to find the device you’re looking for, especially for power outlets, which most devices don’t have.

Jeremy’s counter-example sounds like an edge case, accidentally deleting ports from a device.

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

[github-actions]

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.