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

IP address status appearance is inconsistent #5592

New Issue
Closed
opened 2025-12-29 19:29:52 +01:00 by adam · 6 comments
adam commented 2025-12-29 19:29:52 +01:00
Owner
Copy Link

Originally created by @abrahamvegh on GitHub (Oct 31, 2021).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v3.0.8

Python version

3.7

Steps to Reproduce

  1. Create a device with an interface
  2. Create some IPs:
    • ::1/128, status Active, role Loopback
    • 2001:db8::68/128, status Reserved, no role
    • 2001:db8::69/128, status Active, no role
  3. Assign all of these IPs to the interface on the device

Expected Behavior

When viewing the Interface in the context of a list (e.g. netbox-url/dcim/devices/{device-id}/interfaces/), IPs with the status of Active with no Role assigned should appear visually with the same border appearance as other IPs, with the Active color background.

Observed Behavior

The Active IP just looks like a link, instead of a pill like I would expect:
Screen Shot 2021-10-31 at 11 24 49 AM

Originally created by @abrahamvegh on GitHub (Oct 31, 2021). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v3.0.8 ### Python version 3.7 ### Steps to Reproduce 1. Create a device with an interface 1. Create some IPs: - `::1/128`, status `Active`, role `Loopback` - `2001:db8::68/128`, status `Reserved`, no role - `2001:db8::69/128`, status `Active`, no role 1. Assign all of these IPs to the interface on the device ### Expected Behavior When viewing the Interface in the context of a list (e.g. `netbox-url/dcim/devices/{device-id}/interfaces/`), IPs with the status of `Active` with no `Role` assigned should appear visually with the same border appearance as other IPs, with the `Active` color background. ### Observed Behavior The `Active` IP just looks like a link, instead of a pill like I would expect: <img width="196" alt="Screen Shot 2021-10-31 at 11 24 49 AM" src="https://user-images.githubusercontent.com/53161/139590637-736a1cda-e1ab-4e1c-a801-188b67bf033e.png">
adam added the type: bugstatus: accepted labels 2025-12-29 19:29:52 +01:00
adam closed this issue 2025-12-29 19:29:53 +01:00
adam commented 2025-12-29 19:29:53 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 1, 2021):

The problem seems to be that we're trying to cram too much information into a single table cell. It's not practical to convey the address, status, and role of every IP address assigned to the interface. IMO we should only highlight IPs with a noteworthy status (i.e. not "active") and ignore role entirely.

@jeremystretch commented on GitHub (Nov 1, 2021): The problem seems to be that we're trying to cram too much information into a single table cell. It's not practical to convey the address, status, _and_ role of every IP address assigned to the interface. IMO we should only highlight IPs with a noteworthy status (i.e. not "active") and ignore role entirely.
adam commented 2025-12-29 19:29:53 +01:00
Author
Owner
Copy Link

@abrahamvegh commented on GitHub (Nov 1, 2021):

Disagree, I think it's the right place for the information to all be visible (although I could hear an argument for hiding Loopback addresses behind a "+2" bubble or something like that), and I appreciate the density I get from how the display works right now.

The purpose of the bug report is to highlight a visual inconsistency, not lose what I consider to be a feature. 😅

@abrahamvegh commented on GitHub (Nov 1, 2021): Disagree, I think it's the right place for the information to all be visible (although I could hear an argument for hiding Loopback addresses behind a "+2" bubble or something like that), and I appreciate the density I get from how the display works right now. The purpose of the bug report is to highlight a visual inconsistency, not lose what I consider to be a feature. 😅
adam commented 2025-12-29 19:29:54 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 1, 2021):

IPs with the status of Active with no Role assigned should appear visually with the same border appearance as other IPs

Active is the default state for an IP address: Why would we highlight it? Again, we have three things going on:

  1. Address (one line of text per IP)
  2. Status (background color)
  3. Role (???)

Bear in mind the purpose of this table is to display interfaces, not IP addresses. The assigned IP address are provided for convenience, and a simple click on any of them will lead you to its complete detailed view. Or, alternatively, you could view the list of IP addresses filtered by assigned device if that's what you're primarily interested in.

@jeremystretch commented on GitHub (Nov 1, 2021): > IPs with the status of Active with no Role assigned should appear visually with the same border appearance as other IPs Active is the default state for an IP address: Why would we highlight it? Again, we have three things going on: 1. Address (one line of text per IP) 2. Status (background color) 3. Role (???) Bear in mind the purpose of this table is to display interfaces, not IP addresses. The assigned IP address are provided for convenience, and a simple click on any of them will lead you to its complete detailed view. Or, alternatively, you could view the list of IP addresses filtered by assigned device if that's what you're primarily interested in.
adam commented 2025-12-29 19:29:54 +01:00
Author
Owner
Copy Link

@abrahamvegh commented on GitHub (Nov 3, 2021):

Bear in mind the purpose of this table is to display interfaces, not IP addresses.

After further thought, this kept sticking with me, and you’re completely right. The column has always felt a little odd to me, especially on devices where I have quite a few IPs assigned.

I would propose removing the actual IPs from that view, in favor of a simple count, or perhaps a count of v4/v6 addresses (still only in a single column field).

If there was a desire to retain some of the existing functionality while reducing the clutter for this particular area, I could envision displaying the bubbles with the status and/or role influencing the colors as they do now, but still only displaying a count rather than the addresses themselves.

@abrahamvegh commented on GitHub (Nov 3, 2021): > Bear in mind the purpose of this table is to display interfaces, not IP addresses. After further thought, this kept sticking with me, and you’re completely right. The column has always felt a little odd to me, especially on devices where I have quite a few IPs assigned. I would propose removing the actual IPs from that view, in favor of a simple count, or perhaps a count of v4/v6 addresses (still only in a single column field). If there was a desire to retain some of the existing functionality while reducing the clutter for this particular area, I could envision displaying the bubbles with the status and/or role influencing the colors as they do now, but still only displaying a count rather than the addresses themselves.
adam commented 2025-12-29 19:29:54 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 9, 2021):

I'm just going to leave it at IP address & status. I believe that's sufficient given the context.

@jeremystretch commented on GitHub (Nov 9, 2021): I'm just going to leave it at IP address & status. I believe that's sufficient given the context.
adam commented 2025-12-29 19:29:55 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Nov 12, 2021):

I have a bunch of routing devices where there are one of more main addresses on an interface, plus a VRRP address.

I wanted the VRRP address to be visually distinct; I invested some time implementing this in #6881, and I am sad that now this is gone. There's not even a tooltip now.

@candlerb commented on GitHub (Nov 12, 2021): I have a bunch of routing devices where there are one of more main addresses on an interface, plus a VRRP address. I wanted the VRRP address to be visually distinct; I invested some time implementing this in #6881, and I am sad that now this is gone. There's not even a tooltip now.
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 status: accepted type: bug
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#5592
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?