Show parent object in IP interface assignment UI

[sol1-matt]

NetBox version

v3.6.7

Feature type

Change to existing functionality

Proposed functionality

Make the following changes to the Interface field UI on IP Address assignment.

• The interface displayed value shown for each IP contains the parent object and interface name
• The find as you type functionality works on both the parent object and interface name values when searching and selecting Interfaces

In the screen shot example Netbox01 is the device/vm name and ens192 is the interface name

There would be no change to the stored data, this is purely a change to the UI that shows the relationship between a interface and it's parent.

Narrowed FR from this comment by @jeremystretch in #12751 (comment)_

Use case

It would make assigning interfaces to IP addresses dramatically simpler and quicker as the user would only need to select the correct type and enter the parent object name, the parent name is generally globally unique unlike the interface names which are unique to the parent only and commonly the same across multiple devices.

Currently the user needs to open an advanced search window and find interfaces for the parent from there.

When editing a ip address with an existing assigned interface and parent the user needs to close the editing window to see what the assigned parent is.

By adding the parent to the UI value only users would also be able to see the parent object in the edit window which is useful as a cross reference when doing a lot of data entry or they are distracted while working.

Database changes

The database wouldn't need any changes.

I'm not sure if the model currently support find as you type over multiple fields, it could be the solution is a display_parent_interface field which contains the name of the parent and interface and is used by find as you type and for display of the interface name in IP address editing.

External dependencies

No response

[sol1-matt]

Related to #12751, a narrower scope.

[jeffgdotorg]

Thanks for the FR! To be sure that we've correctly understood the proposed functionality, can you please confirm that you're asking for the name of the interface's parent (Device or VM) be shown alongside each potential interface? If this isn't quite right, please set me straight.

[jeffgdotorg]

As a note to our future selves, @jeremystretch thinks this FR describes a narrower, entirely valid, and more readily achievable subset of what's described in #13283.

[sol1-matt]

Thanks for the FR! To be sure that we've correctly understood the proposed functionality, can you please confirm that you're asking for the name of the interface's parent (Device or VM) be shown alongside each potential interface? If this isn't quite right, please set me straight.

That is correct, the interface parent object name (device or vm) besides the interface name for display purposes.

The bit you left out is I'm also requesting the "find as you type" lookup would work based on this value as well.

[sol1-matt]

added a edit to the original submission for the 1st screenshot defining where the values come from.

In the screen shot example Netbox01 is the device/vm name and ens192 is the interface name

[jeremystretch]

The bit you left out is I'm also requesting the "find as you type" lookup would work based on this value as well.

The filtering logic is decoupled from the displayed label, and is handled by the ?q= query filter. This does not match on the parent device name, nor would I expect most users to desire that.

[DanSheps]

As a note to our future selves, @jeremystretch thinks this FR describes a narrower, entirely valid, and more readily achievable subset of what's described in #13283.

This only tackles IP interface assignment, not any of the many other use-cases for #13283.

I think this would be a good intermediate step, if there is a need, however I don't think abandoning work on #13283 would be wise. There is definitely a need elsewhere for this same functionality (VLAN, Locations, Regions, etc) elsewhere.

[sol1-matt]

The filtering logic is decoupled from the displayed label, and is handled by the ?q= query filter. This does not match on the parent device name, nor would I expect most users to desire that.

I'm going to disagree with users wanting to be able to find interfaces based on their parent when they are specifically looking for interfaces to add a IP to. This FR is based on feedback from users I support who unanimously told me they wanted to search for interfaces by finding the parent first.

In general interface names are common on different hosts, searching for eth0 for instance could return 1000's of results, where are the host name itself is unique.

The specific use case I'm thinking of is where a user is creating a IP or has found an existing IP and wants to assign it to a existing host (device or vm) and interface, very common for the users I support.
The user knows the host and interface name, but "find as you type" on the interface name isn't helpful as it returns 100's or 1000's of results.

The feedback I got was the old system where you could search for the device/vm then interface

• Select type
• Find as you type host (the correct type field device/vm is already present)
• Select or Find as you type interface

was a lot simpler and easier to use than the new search pop up where you have to

• Select type
• Select advanced filtering button to the right
• Pop up loads
• Select the correct field and Find as you type hostname
• Select or Find as you type interface

and not just in the number of steps but the complexity too. The new search pop up is very powerful which means it is also complex compared to a tab and 2 fields that existed previously, at the moment users have to use it 100% of the time when assigning IP's to existing device/vm interfaces. This last point isn't a huge problem, but it is a repetitive problem if a user spends lot of time assigning IP's to existing hosts/interfaces.

To be clear I like the new advanced filtering pop up, it is a excellent tool for the 5% of the time, but for the majority of users I'm spoken to it is more complex and more work to do the data entry.

[jeremystretch]

In general interface names are common on different hosts, searching for eth0 for instance could return 1000's of results, where are the host name itself is unique.

Conversely, matching interfaces by device name would return all the interfaces for that device, defeating its purpose. This is my point, and it's one of the reasons none of the general purpose q filters - for any model - match on related objects.

[sol1-matt]

Conversely, matching interfaces by device name would return all the interfaces for that device, defeating its purpose. This is my point, and it's one of the reasons none of the general purpose q filters - for any model - match on related objects.

This is true, I know users who have 1000's of interfaces on a single host and I'm not suggesting we solve one problem and introduce another one.

The solution I see would to be able to "find as you type" both the parent and interface.
For example if you have 10 netbox vm's named netbox[1-10] each with interfaces eth[0-99] typing netbox eth0 in the find as you type Interface field would filter the results for anything that matches eth0 on all 10 hosts. Typing netbox01 eth1 would return eth1 - 10 for netbox01.

I just tested find as you type and it isn't promiscuous enough for netbox eth0 to return any results. It looks like the match happens from the whole string and not a combination of parts. I wouldn't consider this a blocker, it is still useful as a contains substring match.

This is why I suggested that that a new field be added display_parent_interface which was just a combination of the parent and interface in from the interface model. It could then be used for display and find as you type.

@jeremystretch if you aren't opposed to the idea all together I have some time next week, late next week :),. It might be a small enough problem for me to create a proof of concept.

[DanSheps]

The filtering logic is decoupled from the displayed label, and is handled by the ?q= query filter. This does not match on the parent device name, nor would I expect most users to desire that.

I'm going to disagree with users wanting to be able to find interfaces based on their parent when they are specifically looking for interfaces to add a IP to. This FR is based on feedback from users I support who unanimously told me they wanted to search for interfaces by finding the parent first.

This would be a separate FR then, IMO. While I think it is handy to be able to search for the parent myself, you are still going to have to sift through the list of interfaces to find the appropriate interface.

In general interface names are common on different hosts, searching for eth0 for instance could return 1000's of results, where are the host name itself is unique.

And this FR would be a step towards making it easier. You can already filter specifically by device though by using the selector.

The specific use case I'm thinking of is where a user is creating a IP or has found an existing IP and wants to assign it to a existing host (device or vm) and interface, very common for the users I support. The user knows the host and interface name, but "find as you type" on the interface name isn't helpful as it returns 100's or 1000's of results.

You should be using the interface selector in that instance.

[jronnblom]

We have the same problem. I have multiple devices at customer sites that have the same name "Vlanif10". Would be much faster if it would show the device name before the interface name.

[jeremystretch]

This has been implemented in NetBox v4.0. For any proposed improvements to the current implementation, please submit a new feature request.