starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-13 13:53:31 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Quick overview of parent device in IP Address section #11844

New Issue
Open
opened 2025-12-29 21:50:32 +01:00 by adam · 4 comments
adam commented 2025-12-29 21:50:32 +01:00
Owner
Copy Link

Originally created by @MattBoxIT on GitHub (Nov 18, 2025).

NetBox version

v4.3.7

Feature type

New functionality

Proposed functionality

In the Rack Elevation view, hovering the mouse on a rack installed device shows a tooltip with device details (Name, Role, Status, Device Type, Serial, Description).

The proposal is to have the same tooltip when hovering on the PARENT field in the IPAM > IP Addresses page.

Use case

When working with the IP Adresses list, it's often necessary to have an overview about the parent in addition to the name in the parent field.

Fields from parent models can not be added to the page with "Configure Table" function (for instance his description), so it is needed to open the link to the parent page.

This functionality would save a lot of time giving a quick overview of the parent without leaving the page.

As device and vm models are different, the following fields could be considered for the tooltip:

If the PARENT is a DEVICE: Name, Role, Status, Device Type, Serial, Description
If the PARENT is a VM: Name, Role, Status, Serial, Description

Database changes

None expected as there are only queries involved.

External dependencies

None expected as it should affect the configuration of the UI page only.

Originally created by @MattBoxIT on GitHub (Nov 18, 2025). ### NetBox version v4.3.7 ### Feature type New functionality ### Proposed functionality In the Rack Elevation view, hovering the mouse on a rack installed device shows a tooltip with device details (Name, Role, Status, Device Type, Serial, Description). The proposal is to have the same tooltip when hovering on the PARENT field in the IPAM > IP Addresses page. ### Use case When working with the IP Adresses list, it's often necessary to have an overview about the parent in addition to the name in the parent field. Fields from parent models can not be added to the page with "Configure Table" function (for instance his description), so it is needed to open the link to the parent page. This functionality would save a lot of time giving a quick overview of the parent without leaving the page. As device and vm models are different, the following fields could be considered for the tooltip: If the PARENT is a DEVICE: Name, Role, Status, Device Type, Serial, Description If the PARENT is a VM: Name, Role, Status, Serial, Description ### Database changes None expected as there are only queries involved. ### External dependencies None expected as it should affect the configuration of the UI page only.
adam added the type: featurestatus: under reviewnetbox labels 2025-12-29 21:50:32 +01:00
adam commented 2025-12-29 21:50:34 +01:00
Author
Owner
Copy Link

@jnovinger commented on GitHub (Nov 19, 2025):

Thank you for your interest in extending NetBox. Unfortunately, the information you have provided does not constitute an actionable feature request. Per our contributing guide, a feature request must include a thorough description of the proposed functionality, including any database changes, new views or API endpoints, and so on. It must also include a detailed use case justifying its implementation. If you would like to elaborate on your proposal, please modify your post above. If sufficient detail is not added, this issue will be closed.

@jnovinger commented on GitHub (Nov 19, 2025): Thank you for your interest in extending NetBox. Unfortunately, the information you have provided does not constitute an actionable feature request. Per our [contributing guide](https://github.com/netbox-community/netbox/blob/main/CONTRIBUTING.md), a feature request must include a thorough description of the proposed functionality, including any database changes, new views or API endpoints, and so on. It must also include a detailed use case justifying its implementation. If you would like to elaborate on your proposal, please modify your post above. If sufficient detail is not added, this issue will be closed.
adam commented 2025-12-29 21:50:35 +01:00
Author
Owner
Copy Link

@MattBoxIT commented on GitHub (Nov 19, 2025):

Thank you for your interest in extending NetBox. Unfortunately, the information you have provided does not constitute an actionable feature request. Per our contributing guide, a feature request must include a thorough description of the proposed functionality, including any database changes, new views or API endpoints, and so on. It must also include a detailed use case justifying its implementation. If you would like to elaborate on your proposal, please modify your post above. If sufficient detail is not added, this issue will be closed.

Thanks, I have reworked the request.

@MattBoxIT commented on GitHub (Nov 19, 2025): > Thank you for your interest in extending NetBox. Unfortunately, the information you have provided does not constitute an actionable feature request. Per our [contributing guide](https://github.com/netbox-community/netbox/blob/main/CONTRIBUTING.md), a feature request must include a thorough description of the proposed functionality, including any database changes, new views or API endpoints, and so on. It must also include a detailed use case justifying its implementation. If you would like to elaborate on your proposal, please modify your post above. If sufficient detail is not added, this issue will be closed. Thanks, I have reworked the request.
adam commented 2025-12-29 21:50:35 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 20, 2025):

While I appreciate the intent here, I don't think this is a pattern we want to introduce. The assigned object (device or VM) is already linked for easy reference. Attempting to incorporate additional data complicates the view and introduces what is IMO an anti-pattern of burying data in non-obvious places.

If we were to introduce such a pattern, it would need to applied consistently and dynamically throughout the UI. The best analog I can think of is how GitHub provides a dynamic pop-up preview when you hover a link to an issue in a comment like this. Still, it doesn't seem worth the effort IMO because we would need to support the same behavior consistently for all object types (not just devices/VMs).

@jeremystretch commented on GitHub (Nov 20, 2025): While I appreciate the intent here, I don't think this is a pattern we want to introduce. The assigned object (device or VM) is already linked for easy reference. Attempting to incorporate additional data complicates the view and introduces what is IMO an anti-pattern of burying data in non-obvious places. If we _were_ to introduce such a pattern, it would need to applied consistently and dynamically throughout the UI. The best analog I can think of is how GitHub provides a dynamic pop-up preview when you hover a link to an issue in a comment [like this](https://github.com/netbox-community/netbox/issues/20821). Still, it doesn't seem worth the effort IMO because we would need to support the same behavior consistently for _all_ object types (not just devices/VMs).
adam commented 2025-12-29 21:50:35 +01:00
Author
Owner
Copy Link

@MattBoxIT commented on GitHub (Nov 24, 2025):

While I appreciate the intent here, I don't think this is a pattern we want to introduce. The assigned object (device or VM) is already linked for easy reference. Attempting to incorporate additional data complicates the view and introduces what is IMO an anti-pattern of burying data in non-obvious places.

If we were to introduce such a pattern, it would need to applied consistently and dynamically throughout the UI. The best analog I can think of is how GitHub provides a dynamic pop-up preview when you hover a link to an issue in a comment like this. Still, it doesn't seem worth the effort IMO because we would need to support the same behavior consistently for all object types (not just devices/VMs).

Thanks, I just wanted to clarify that the intention was not to incorporate additional data to the view.
I called it tooltip but it's almost the same as the dynamic pop-up preview described in your example, and it would fit the need perfectly.

Another use case would be in the interfaces view of a switch to quickly get info about connected devices.
I can't find an use case that worth the effort for other objects in my scenario, but I could provide more for devices/VMs.
Does this change anything in the feature evaluation?

@MattBoxIT commented on GitHub (Nov 24, 2025): > While I appreciate the intent here, I don't think this is a pattern we want to introduce. The assigned object (device or VM) is already linked for easy reference. Attempting to incorporate additional data complicates the view and introduces what is IMO an anti-pattern of burying data in non-obvious places. > > If we _were_ to introduce such a pattern, it would need to applied consistently and dynamically throughout the UI. The best analog I can think of is how GitHub provides a dynamic pop-up preview when you hover a link to an issue in a comment [like this](https://github.com/netbox-community/netbox/issues/20821). Still, it doesn't seem worth the effort IMO because we would need to support the same behavior consistently for _all_ object types (not just devices/VMs). Thanks, I just wanted to clarify that the intention was not to incorporate additional data to the view. I called it tooltip but it's almost the same as the dynamic pop-up preview described in your example, and it would fit the need perfectly. Another use case would be in the interfaces view of a switch to quickly get info about connected devices. I can't find an use case that worth the effort for other objects in my scenario, but I could provide more for devices/VMs. Does this change anything in the feature evaluation?
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 netbox status: under review type: feature
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#11844
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?