Display IP role labels in interfaces table #5136

@thatmattlove commented on GitHub (Aug 4, 2021):

What would you think about a tooltip instead of displaying a badge? Within a tooltip, we could easily display multiple pieces of information about the related object without having to sacrifice horizontal screen real estate.

@thatmattlove commented on GitHub (Aug 4, 2021): What would you think about a [tooltip](https://getbootstrap.com/docs/5.1/components/tooltips/) instead of displaying a badge? Within a tooltip, we could easily display multiple pieces of information about the related object without having to sacrifice horizontal screen real estate.

adam commented

@candlerb commented on GitHub (Aug 4, 2021):

I would still like the special addresses to be visually distinct, without having to hover over them.

How about: colourize the address and have a tooltip? For example, if the IP address is CARP, then show it as white on a green background (like the "CARP" label is); the tooltip shows that the role is CARP.

Potentially this could also be used to highlight status (!= Active).

If the address has both status != Active and role != None, one of these would have to take precedence in the colourization (although the tooltip can show both). I don't really mind; arguably if an address is Deprecated or Reserved this is most important thing to highlight. In any case, it's unlikely to have status DHCP or SLAAC and have a role associated with it.

@candlerb commented on GitHub (Aug 4, 2021): I would still like the special addresses to be visually distinct, without having to hover over them. How about: colourize the address *and* have a tooltip? For example, if the IP address is CARP, then show it as white on a green background (like the "CARP" label is); the tooltip shows that the role is CARP. Potentially this could also be used to highlight status (!= Active). If the address has both status != Active and role != None, one of these would have to take precedence in the colourization (although the tooltip can show both). I don't really mind; arguably if an address is Deprecated or Reserved this is most important thing to highlight. In any case, it's unlikely to have status DHCP or SLAAC *and* have a role associated with it.

adam commented

@bellwood commented on GitHub (Aug 6, 2021):

Tooltips aren't particularly mobile friendly so a single label would probably suffice.

@jeremystretch I have a PR to resolve this if you're willing to accept one for this feature request.

Edit: This would actually be a badge-success as 3.0 appears to be using badges over labels

@bellwood commented on GitHub (Aug 6, 2021): Tooltips aren't particularly mobile friendly so a single `label` would probably suffice. @jeremystretch I have a PR to resolve this if you're willing to accept one for this feature request. Edit: This would actually be a `badge-success` as 3.0 appears to be using badges over labels

adam commented

@bluikko commented on GitHub (Aug 16, 2021):

These labels used to show and were really useful. I guess they were lost when the tables were changed from templates.

@bluikko commented on GitHub (Aug 16, 2021): These labels used to show and were really useful. I guess they were lost when the tables were changed from templates.

adam commented

@candlerb commented on GitHub (Aug 17, 2021):

Here is proof-of-concept of labels beside addresses:

I rather like this, although it would be nice to bump the label up a pixel or two.

This patch (to Netbox v2.11.11) implements it, if you want to try it out for yourself:

--- a/netbox/dcim/tables/template_code.py
+++ b/netbox/dcim/tables/template_code.py
@@ -42,7 +42,10 @@ DEVICEBAY_STATUS = """

 INTERFACE_IPADDRESSES = """
 {% for ip in record.ip_addresses.all %}
-    <a href="{{ ip.get_absolute_url }}">{{ ip }}</a><br />
+    <a href="{{ ip.get_absolute_url }}">{{ ip }}</a>
+    {% if ip.status != 'active' %} <span class="label label-{{ ip.get_status_class }}">{{ ip.get_status_display %}</span>{% endif %}
+    {% if ip.role %} <span class="label label-{{ ip.get_role_class }}">{{ ip.get_role_display }}</span>{% endif %}
+    <br />
 {% endfor %}
 """

And here's what happens if the IP address itself is colorized if it has a non-active status or non-null role applied.

It's not great that the font sizes don't match. The label class sets font-size: 75%, but resetting it to 100% is worse:

Anyway, again here's the code for tinkering.

--- a/netbox/dcim/tables/template_code.py
+++ b/netbox/dcim/tables/template_code.py
@@ -42,7 +42,7 @@ DEVICEBAY_STATUS = """

 INTERFACE_IPADDRESSES = """
 {% for ip in record.ip_addresses.all %}
-    <a href="{{ ip.get_absolute_url }}">{{ ip }}</a><br />
+    <a {% if ip.status != 'active' %}class="label label-{{ ip.get_status_class }}"{% elif ip.role %}class="label label-{{ ip.get_role_class }}"{% endif %} href="{{ ip.get_absolute_url }}">{{ ip }}</a><br />
 {% endfor %}
 """

@candlerb commented on GitHub (Aug 17, 2021): Here is proof-of-concept of labels beside addresses: ![image](https://user-images.githubusercontent.com/44789/129731409-6ce017e3-a9b0-4440-866e-e1ee44b7f433.png) I rather like this, although it would be nice to bump the label up a pixel or two. This patch (to Netbox v2.11.11) implements it, if you want to try it out for yourself: ``` --- a/netbox/dcim/tables/template_code.py +++ b/netbox/dcim/tables/template_code.py @@ -42,7 +42,10 @@ DEVICEBAY_STATUS = """ INTERFACE_IPADDRESSES = """ {% for ip in record.ip_addresses.all %} - <a href="{{ ip.get_absolute_url }}">{{ ip }}</a> + <a href="{{ ip.get_absolute_url }}">{{ ip }}</a> + {% if ip.status != 'active' %} {{ ip.get_status_display %}{% endif %} + {% if ip.role %} {{ ip.get_role_display }}{% endif %} + {% endfor %} """ ``` And here's what happens if the IP address itself is colorized if it has a non-active status or non-null role applied. ![image](https://user-images.githubusercontent.com/44789/129732231-975e19e3-4eda-435f-8bb0-43847d596b96.png) It's not great that the font sizes don't match. The label class sets `font-size: 75%`, but resetting it to 100% is worse: ![image](https://user-images.githubusercontent.com/44789/129732879-fdd52161-8109-443c-b513-ad3b0c0359ff.png) Anyway, again here's the code for tinkering. ``` --- a/netbox/dcim/tables/template_code.py +++ b/netbox/dcim/tables/template_code.py @@ -42,7 +42,7 @@ DEVICEBAY_STATUS = """ INTERFACE_IPADDRESSES = """ {% for ip in record.ip_addresses.all %} - <a href="{{ ip.get_absolute_url }}">{{ ip }}</a> + <a {% if ip.status != 'active' %}class="label label-{{ ip.get_status_class }}"{% elif ip.role %}class="label label-{{ ip.get_role_class }}"{% endif %} href="{{ ip.get_absolute_url }}">{{ ip }}</a> {% endfor %} """ ```

adam commented

@bluikko commented on GitHub (Aug 19, 2021):

labels beside addresses

With the caveats on colorizing the address it self (small font / does not line up horizontally with the others; user needs to figure out what the colors mean), IMO the labels beside addresses look the best.

Horizontal screen real estate is precious and needs to be conserved (yay the new collapsible menu in v3!) - I guess adding it in a new column (that can be hidden in the column selection) would be much more work than your simple change? I would prefer to always see the labels but some other people may not need them...

@bluikko commented on GitHub (Aug 19, 2021): > labels beside addresses With the caveats on colorizing the address it self (small font / does not line up horizontally with the others; user needs to figure out what the colors mean), IMO the labels beside addresses look the best. Horizontal screen real estate is precious and needs to be conserved (yay the new collapsible menu in v3!) - I guess adding it in a new column (that can be hidden in the column selection) would be much more work than your simple change? I would prefer to always see the labels but some other people may not need them...

adam commented

@candlerb commented on GitHub (Aug 19, 2021):

Adding a new column would not be difficult. But I don't like it, because the labels would not be immediately next to the addresses. When you have multiple addresses on an interface, and some addresses are wider than others, it makes the association between address and label unclear. This is a single table cell, with multiple addresses on multiple lines split by  

@candlerb commented on GitHub (Aug 19, 2021): Adding a new column would not be difficult. But I don't like it, because the labels would not be immediately next to the addresses. When you have multiple addresses on an interface, and some addresses are wider than others, it makes the association between address and label unclear. This is a single table cell, with multiple addresses on multiple lines split by ` `

adam commented

@thatmattlove commented on GitHub (Aug 19, 2021):

I took a swing at implementing @candlerb's solution in the beta, while also using tooltips to show the status or role display text. Thoughts?

@thatmattlove commented on GitHub (Aug 19, 2021): I took a swing at implementing @candlerb's solution in the beta, while also using tooltips to show the status or role display text. Thoughts? ![netbox-6881-proposed-1](https://user-images.githubusercontent.com/42724207/130107230-c43d0d24-2c23-43dc-b3fa-8691dba22ebf.gif)

adam commented

2025-12-29 19:24:41 +01:00

@candlerb commented on GitHub (Aug 19, 2021):

There is a problem with this patch: it removes the  , so if you have two addresses on an interface they can display side by side. I see this with an IPv4 and an IPv6 address on the same interface:

@candlerb commented on GitHub (Aug 19, 2021): There is a problem with this patch: it removes the ` `, so if you have two addresses on an interface they can display side by side. I see this with an IPv4 and an IPv6 address on the same interface: ![image](https://user-images.githubusercontent.com/44789/130137506-f169b149-3a2b-4ee0-9c5e-81a7dc6182ea.png)

adam commented

@thatmattlove commented on GitHub (Aug 19, 2021):

This is supposed to mitigate that, and does when the badge classes are applied. I did not, however, test this with multiple IPs without badge classes (i.e. active status with no role). I'll take a look.

@thatmattlove commented on GitHub (Aug 19, 2021): [This](https://github.com/netbox-community/netbox/blob/a71604e79fd51cfce5e3e0c4943c72325e6b2ee3/netbox/project-static/styles/netbox.scss#L806) is supposed to mitigate that, and does when the `badge` classes are applied. I did not, however, test this with multiple IPs _without_ `badge` classes (i.e. active status with no role). I'll take a look.

adam commented

2025-12-29 19:24:41 +01:00

@thatmattlove commented on GitHub (Aug 19, 2021):

I'm not able to reproduce this. I also noticed that your screenshot doesn't have the IPs in a monospace font, which was one of the changes I added. How are you testing this?

@thatmattlove commented on GitHub (Aug 19, 2021): I'm not able to reproduce this. I also noticed that your screenshot doesn't have the IPs in a monospace font, which was one of the changes I added. How are you testing this?

adam commented

2025-12-29 19:24:41 +01:00

@bluikko commented on GitHub (Aug 20, 2021):

There used to be "Primary" label before. I think that would be useful to have. Maybe italic IP address? Or some color?

@bluikko commented on GitHub (Aug 20, 2021): There used to be "Primary" label before. I think that would be useful to have. Maybe italic IP address? Or some color?

adam commented

@bluikko commented on GitHub (Aug 20, 2021):

I'm not able to reproduce this. I also noticed that your screenshot doesn't have the IPs in a monospace font, which was one of the changes I added. How are you testing this?

If you look at your patch diff, the   between IP addresses (for loop iterations) is indeed removed.

@bluikko commented on GitHub (Aug 20, 2021): > I'm not able to reproduce this. I also noticed that your screenshot doesn't have the IPs in a monospace font, which was one of the changes I added. How are you testing this? If you look at your patch diff, the ` ` between IP addresses (for loop iterations) is indeed removed.

adam commented

@thatmattlove commented on GitHub (Aug 20, 2021):

If you look at your patch diff, the   between IP addresses (for loop iterations) is indeed removed.

Yes, this was intentional. display: block, applied via the .table-badge class accomplishes the same goal, without adding unneeded elements and adding a break to single addresses when it's not needed.

@thatmattlove commented on GitHub (Aug 20, 2021): > If you look at your patch diff, the ` ` between IP addresses (for loop iterations) is indeed removed. Yes, this was intentional. `display: block`, applied via the `.table-badge` class accomplishes the same goal, without adding unneeded elements and adding a break to single addresses when it's not needed.

adam commented

@bluikko commented on GitHub (Aug 20, 2021):

If you look at your patch diff, the   between IP addresses (for loop iterations) is indeed removed.

Yes, this was intentional. display: block, applied via the .table-badge class accomplishes the same goal, without adding unneeded elements and adding a break to single addresses when it's not needed.

I see - didn't scroll down there.

@bluikko commented on GitHub (Aug 20, 2021): > > If you look at your patch diff, the ` ` between IP addresses (for loop iterations) is indeed removed. > > Yes, this was intentional. `display: block`, applied via the `.table-badge` class accomplishes the same goal, without adding unneeded elements and adding a break to single addresses when it's not needed. I see - didn't scroll down there.

adam commented

@candlerb commented on GitHub (Aug 20, 2021):

How are you testing this?

Just a "git pull" on the feature branch. A Shift-Reload has fixed it - must be the old CSS cached in the browser.

I'm afraid I don't really like the mono font here, because it's (a) inconsistent with text in other columns in that view:

and (b) it's inconsistent with how IP addresses are rendered everywhere else:

I tried turning off the monospace font, setting font size 0.875rem to match the rest, and bringing down padding and margin:

However there's still some CSS nonsense which means an unlabeled item is spaced further away than the spacing between labeled items:

(not an optical illusion: I've measured it)

@candlerb commented on GitHub (Aug 20, 2021): > How are you testing this? Just a "git pull" on the feature branch. A Shift-Reload has fixed it - must be the old CSS cached in the browser. I'm afraid I don't really like the mono font here, because it's (a) inconsistent with text in other columns in that view: ![image](https://user-images.githubusercontent.com/44789/130190456-954255f5-176f-4ff5-87b7-9466a66b9d32.png) and (b) it's inconsistent with how IP addresses are rendered everywhere else: ![image](https://user-images.githubusercontent.com/44789/130189088-ab5a359b-637f-40e7-9eee-09d89e3192b1.png) I tried turning off the monospace font, setting font size 0.875rem to match the rest, and bringing down padding and margin: ![image](https://user-images.githubusercontent.com/44789/130190618-b201745f-733b-41e4-ba8f-c3a2978d5e49.png) However there's still some CSS nonsense which means an *unlabeled* item is spaced further away than the spacing between labeled items: ![image](https://user-images.githubusercontent.com/44789/130189917-c2a57687-331c-41bc-9734-40d3e33b508a.png) (not an optical illusion: I've measured it)

adam commented

@bluikko commented on GitHub (Aug 20, 2021):

However there's still some CSS nonsense which means an unlabeled item is spaced further away than the spacing between labeled items

A naive suggestion: put a label around all of them, in your 3rd IP address of last screenshot label being transparent?

@bluikko commented on GitHub (Aug 20, 2021): > However there's still some CSS nonsense which means an _unlabeled_ item is spaced further away than the spacing between labeled items A naive suggestion: put a label around all of them, in your 3rd IP address of last screenshot label being transparent?

adam commented

@candlerb commented on GitHub (Aug 20, 2021):

I also want to avoid over-wide vertical spacing when unbadged addresses are next to each other (the normal case).

I generally get lost in a myriad of overriding and inherited CSS properties, but here's my solution:

Implementation:

--- a/netbox/project-static/styles/netbox.scss
+++ b/netbox/project-static/styles/netbox.scss
@@ -800,18 +800,22 @@ table tbody {
 // Style objects with statuses/roles within a table. As of implementation, used for IP addresses
 // assigned to interfaces.
 table .table-badge-group {
-  font-family: $font-family-monospace;
-
   .table-badge {
     display: block;
     width: min-content;
     // Apply badge padding so that IP addresses *not* within a badge appear aligned with IP
     // addresses that *are* within a badge.
-    padding: $badge-padding-y $badge-padding-x;
+    padding: 0.1em $badge-padding-x;
+    font-size: $font-size-sm;
+    font-weight: $font-weight-base;
+  }
+
+  // Addresses with an actual badge get this class too
+  .badge {
+    padding-top: $badge-padding-y;
+    padding-bottom: $badge-padding-y;
     margin-top: map.get($spacers, 1);
     margin-bottom: map.get($spacers, 1);
-    font-size: $font-size-xs;
-    font-weight: $font-weight-base;
   }
 }

@candlerb commented on GitHub (Aug 20, 2021): I also want to avoid over-wide vertical spacing when unbadged addresses are next to each other (the normal case). I generally get lost in a myriad of overriding and inherited CSS properties, but here's my solution: ![image](https://user-images.githubusercontent.com/44789/130197483-8f4a2c13-61a3-426a-90e0-c53698dbd00d.png) Implementation: ``` --- a/netbox/project-static/styles/netbox.scss +++ b/netbox/project-static/styles/netbox.scss @@ -800,18 +800,22 @@ table tbody { // Style objects with statuses/roles within a table. As of implementation, used for IP addresses // assigned to interfaces. table .table-badge-group { - font-family: $font-family-monospace; - .table-badge { display: block; width: min-content; // Apply badge padding so that IP addresses *not* within a badge appear aligned with IP // addresses that *are* within a badge. - padding: $badge-padding-y $badge-padding-x; + padding: 0.1em $badge-padding-x; + font-size: $font-size-sm; + font-weight: $font-weight-base; + } + + // Addresses with an actual badge get this class too + .badge { + padding-top: $badge-padding-y; + padding-bottom: $badge-padding-y; margin-top: map.get($spacers, 1); margin-bottom: map.get($spacers, 1); - font-size: $font-size-xs; - font-weight: $font-weight-base; } } ```

adam commented

@candlerb commented on GitHub (Aug 20, 2021):

@bluikko: as for "primary" address, how about a small star or other icon next to it?

@candlerb commented on GitHub (Aug 20, 2021): @bluikko: as for "primary" address, how about a small star or other icon next to it?

adam commented

@bluikko commented on GitHub (Aug 20, 2021):

@bluikko: as for "primary" address, how about a small star or other icon next to it?

Sounds to me as good as any visual cue.

@bluikko commented on GitHub (Aug 20, 2021): > @bluikko: as for "primary" address, how about a small star or other icon next to it? Sounds to me as good as any visual cue.

adam commented

@candlerb commented on GitHub (Aug 20, 2021):

OK, perhaps should make that a separate feature request though. Since "primary" is an attribute of the device, not the address or the interface, it may need some more plumbing to get it through to the interfaces table.

@candlerb commented on GitHub (Aug 20, 2021): OK, perhaps should make that a separate feature request though. Since "primary" is an attribute of the device, not the address or the interface, it may need some more plumbing to get it through to the interfaces table.

adam commented

@bluikko commented on GitHub (Aug 20, 2021):

OK, perhaps should make that a separate feature request though.

I am happy to do that since there's not much I can do otherwise to help. Please thumbs-up if you aren't making it yourself.

@bluikko commented on GitHub (Aug 20, 2021): > OK, perhaps should make that a separate feature request though. I am happy to do that since there's not much I can do otherwise to help. Please thumbs-up if you aren't making it yourself.

adam commented

@thatmattlove commented on GitHub (Aug 20, 2021):

@candlerb Points taken, 9d46987 should contain the same/similar outcome, just a slightly different CSS approach. Please test and confirm it's to your liking, and we can close this one out.

@thatmattlove commented on GitHub (Aug 20, 2021): @candlerb Points taken, 9d46987 should contain the same/similar outcome, just a slightly different CSS approach. Please test and confirm it's to your liking, and we can close this one out.

adam commented