Show parent object in IP interface assignment UI #8977

New Issue

adam · 2025-12-29T20:43:35+01:00

adam commented

2025-12-29 20:43:35 +01:00

Originally created by @sol1-matt on GitHub (Dec 18, 2023).

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 https://github.com/netbox-community/netbox/issues/12751#issuecomment-1858492734_

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

Originally created by @sol1-matt on GitHub (Dec 18, 2023). ### 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 ![image](https://github.com/netbox-community/netbox/assets/17868735/495ba15a-cf7a-4938-a2dc-ac3882b4b242) _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 https://github.com/netbox-community/netbox/issues/12751#issuecomment-1858492734_ ### 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. ![image](https://github.com/netbox-community/netbox/assets/17868735/c772e50d-138b-466d-a2ea-4a362b14459b) 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_

adam added the type: feature label 2025-12-29 20:43:35 +01:00

adam closed this issue

2025-12-29 20:43:35 +01:00

adam commented

2025-12-29 20:43:35 +01:00

@sol1-matt commented on GitHub (Dec 18, 2023):

Related to #12751, a narrower scope.

@sol1-matt commented on GitHub (Dec 18, 2023): Related to #12751, a narrower scope.

adam commented

2025-12-29 20:43:36 +01:00

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

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 commented on GitHub (Dec 20, 2023): 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.

adam commented

2025-12-29 20:43:36 +01:00

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

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.

@jeffgdotorg commented on GitHub (Dec 20, 2023): 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.

adam commented

2025-12-29 20:43:36 +01:00

@sol1-matt commented on GitHub (Dec 20, 2023):

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 commented on GitHub (Dec 20, 2023): > 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.

adam commented

2025-12-29 20:43:37 +01:00

@sol1-matt commented on GitHub (Dec 20, 2023):

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

@sol1-matt commented on GitHub (Dec 20, 2023): 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_

adam commented

2025-12-29 20:43:37 +01:00

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

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.

@jeremystretch commented on GitHub (Dec 20, 2023): > 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.

adam commented

2025-12-29 20:43:37 +01:00

@DanSheps commented on GitHub (Dec 20, 2023):

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.

@DanSheps commented on GitHub (Dec 20, 2023): > 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.

adam commented

2025-12-29 20:43:40 +01:00

@sol1-matt commented on GitHub (Dec 21, 2023):

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.

@sol1-matt commented on GitHub (Dec 21, 2023): > 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.

adam commented

2025-12-29 20:43:41 +01:00

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

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.

@jeremystretch commented on GitHub (Dec 21, 2023): > 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.

adam commented

2025-12-29 20:43:43 +01:00

@sol1-matt commented on GitHub (Dec 21, 2023):

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.

@sol1-matt commented on GitHub (Dec 21, 2023): > 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.

adam commented

2025-12-29 20:43:46 +01:00

@DanSheps commented on GitHub (Dec 21, 2023):

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.

@DanSheps commented on GitHub (Dec 21, 2023): > > 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.

adam commented

2025-12-29 20:43:46 +01:00

@jronnblom commented on GitHub (Jan 16, 2024):

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.

@jronnblom commented on GitHub (Jan 16, 2024): 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. <img width="537" alt="Screenshot 2024-01-16 at 11 44 13" src="https://github.com/netbox-community/netbox/assets/480017/83c836d4-add5-4eed-9d9a-9983990b644f">

adam commented

2025-12-29 20:43:46 +01:00

@jeremystretch commented on GitHub (May 14, 2024):

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

@jeremystretch commented on GitHub (May 14, 2024): This has been implemented in NetBox v4.0. For any proposed improvements to the current implementation, please submit a new feature request. ![screenshot](https://github.com/netbox-community/netbox/assets/13487278/eee06144-66bc-48b7-ab82-13458e58476a)

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#8977