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

Layout improvements for IP Addresses shown under Device #696

New Issue
Closed
opened 2025-12-29 16:24:51 +01:00 by adam · 12 comments
adam commented 2025-12-29 16:24:51 +01:00
Owner
Copy Link

Originally created by @candlerb on GitHub (Feb 7, 2017).

A couple of suggestions for layout improvements when looking at a device /dcim/devices/<N>/, specifically the table of IP Addresses (shown under Secrets).

Include IP Address Status

Next to each IP address, also display the IP Address Status with its coloured label.

This would be helpful because we have some deprecated addresses still associated with their original interface, and it would be good to distinguish the current and previous addresses.

Addresses in Interfaces table

Larger change:

Merge the IP Addresses table into the Interfaces table, so that the addresses are grouped under each interface.

This would make it clear to the end user that the data model associates addresses with interfaces, not directly with devices (apart from the primary addresses).

I think this would also balance the screen layout better for the server case, given that the left-hand column is very full, but the right-hand column has only interfaces (and often only one).

Of course, switches and routers have many interfaces. If they are layer 2 devices they won't have IP addresses associated with each interface, so the layout won't change. For routers, I think it's still clearer to see the interfaces with the IP address next to each one, rather than one table of addresses and a separate table of interfaces.

Originally created by @candlerb on GitHub (Feb 7, 2017). A couple of suggestions for layout improvements when looking at a device `/dcim/devices/<N>/`, specifically the table of IP Addresses (shown under Secrets). #### Include IP Address Status Next to each IP address, also display the IP Address Status with its coloured label. This would be helpful because we have some deprecated addresses still associated with their original interface, and it would be good to distinguish the current and previous addresses. #### Addresses in Interfaces table Larger change: Merge the IP Addresses table into the Interfaces table, so that the addresses are grouped under each interface. This would make it clear to the end user that the data model associates addresses with interfaces, not directly with devices (apart from the primary addresses). I think this would also balance the screen layout better for the server case, given that the left-hand column is very full, but the right-hand column has only interfaces (and often only one). Of course, switches and routers have many interfaces. If they are layer 2 devices they won't have IP addresses associated with each interface, so the layout won't change. For routers, I think it's still clearer to see the interfaces with the IP address next to each one, rather than one table of addresses and a separate table of interfaces.
adam added the type: feature label 2025-12-29 16:24:51 +01:00
adam closed this issue 2025-12-29 16:24:51 +01:00
adam commented 2025-12-29 16:24:52 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Feb 7, 2017):

For completeness: this would also place the management IP addresses under the management interfaces.

Right now if a device has two service addresses and two ILO addresses, they are displayed as a list of 4 addresses - correctly labelled with the interface names of course, but it's up to you to infer which is management and which is service, by looking for corresponding named interfaces under "Critical Connections" and "Interfaces" respectively.

Right now, the 'primary' address is flagged, but management address(es) are not flagged. This need would go if management address(es) were shown under the corresponding management interface.

@candlerb commented on GitHub (Feb 7, 2017): For completeness: this would also place the management IP addresses under the management interfaces. Right now if a device has two service addresses and two ILO addresses, they are displayed as a list of 4 addresses - correctly labelled with the interface names of course, but it's up to you to infer which is management and which is service, by looking for corresponding named interfaces under "Critical Connections" and "Interfaces" respectively. Right now, the 'primary' address is flagged, but management address(es) are not flagged. This need would go if management address(es) were shown under the corresponding management interface.
adam commented 2025-12-29 16:24:52 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 17, 2017):

@candlerb Could you provide a mock-up please?

@jeremystretch commented on GitHub (Mar 17, 2017): @candlerb Could you provide a mock-up please?
adam commented 2025-12-29 16:24:52 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Mar 17, 2017):

Current:

netbox-current

First proposal:

netbox-proposed

I'm terrible at visual layout, but logically that's what I'd like to see - IP address(es) under each interface or management port.

Notes:

  1. To make it a bit less busy I've only shown the IP address status when it is not equal to "Active". (Maybe VRF should be hidden if it's "Global"?)
  2. It's still very busy. Maybe the spacing should be increased, or the IP addresses visually separated somehow (in a box? with different background stripe?)
  3. At the moment I've lost the ability to delete an IP address assignment. The trash button could be added back if the IP address is visually separated, but care needed not to become confusing if there are multiple trash buttons under an interface.
  4. Each IP address no longer needs to have its interface name next to it (since it's under the interface). So perhaps the IP address description can go here instead.
@candlerb commented on GitHub (Mar 17, 2017): Current: ![netbox-current](https://cloud.githubusercontent.com/assets/44789/24036091/014d02b2-0af0-11e7-96da-23357d59dc1c.png) First proposal: ![netbox-proposed](https://cloud.githubusercontent.com/assets/44789/24036103/0bb45192-0af0-11e7-994c-f0918ad49eca.png) I'm terrible at visual layout, but logically that's what I'd like to see - IP address(es) under each interface or management port. Notes: 1. To make it a bit less busy I've only shown the IP address status when it is not equal to "Active". (Maybe VRF should be hidden if it's "Global"?) 2. It's still very busy. Maybe the spacing should be increased, or the IP addresses visually separated somehow (in a box? with different background stripe?) 3. At the moment I've lost the ability to delete an IP address assignment. The trash button could be added back if the IP address is visually separated, but care needed not to become confusing if there are multiple trash buttons under an interface. 4. Each IP address no longer needs to have its interface name next to it (since it's under the interface). So perhaps the IP address *description* can go here instead.
adam commented 2025-12-29 16:24:52 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Mar 17, 2017):

I've also lost the "assign IP address" button.

Suggestion 1: extend the "edit interface" page to allow assignment and removal of IP addresses on that interface. This also avoids having buttons next to each IP address to deassign them.

Suggestion 2: add a new button on the interface for "assign IP". The problem here is possible confusion: "+" currently means "connect" rather than "add address". It could be changed to something which looks like a plug, and then use + and - to add and remove IP addresses. But "-" would have to sit next to the address itself.

I think (1) is preferable from a UI point of view, as it means less buttons to choose from; but it might be more work to implement.

@candlerb commented on GitHub (Mar 17, 2017): I've also lost the "assign IP address" button. Suggestion 1: extend the "edit interface" page to allow assignment and removal of IP addresses on that interface. This also avoids having buttons next to each IP address to deassign them. Suggestion 2: add a new button on the interface for "assign IP". The problem here is possible confusion: "+" currently means "connect" rather than "add address". It could be changed to something which looks like a plug, and then use + and - to add and remove IP addresses. But "-" would have to sit next to the address itself. I think (1) is preferable from a UI point of view, as it means less buttons to choose from; but it might be more work to implement.
adam commented 2025-12-29 16:24:52 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Mar 17, 2017):

Another attempt, this time just adding a table row for each IP address:

image

image

HTML:

<tr style="background: #eff">
  <td></td>
  <td><a href="/ipam/ip-addresses/1304/">192.168.5.119</a></td>
  <td>Global</td>
  <td><span class="label label-success">Primary</span></td>
  <td colspan="2"><!-- IP address description goes here --></td>
</tr>

Adding line-height: 0.9; to the td cells squeezes them up a bit. And here I also change the "No console/power ports defined" row from colspan="5" to colspan="7"

image

@candlerb commented on GitHub (Mar 17, 2017): Another attempt, this time just adding a table row for each IP address: ![image](https://cloud.githubusercontent.com/assets/44789/24038632/280c93ae-0afa-11e7-8f28-63b6f613bba8.png) ![image](https://cloud.githubusercontent.com/assets/44789/24038635/32b8de8e-0afa-11e7-9eb3-40b4678084f1.png) HTML: ~~~ <tr style="background: #eff"> <td></td> <td><a href="/ipam/ip-addresses/1304/">192.168.5.119</a></td> <td>Global</td> <td><span class="label label-success">Primary</span></td> <td colspan="2"><!-- IP address description goes here --></td> </tr> ~~~ Adding `line-height: 0.9;` to the td cells squeezes them up a bit. And here I also change the "No console/power ports defined" row from `colspan="5"` to `colspan="7"` ![image](https://cloud.githubusercontent.com/assets/44789/24039209/3aedc888-0afc-11e7-9a64-be2add980643.png)
adam commented 2025-12-29 16:24:53 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 13, 2017):

Thanks @candlerb and @snazy2000 for the inspiration for d5c3f9e. Please review and let me know what you think. I've added a button at the top of the interfaces list to toggle the display of IP addresses.

@jeremystretch commented on GitHub (Apr 13, 2017): Thanks @candlerb and @snazy2000 for the inspiration for d5c3f9e. Please review and let me know what you think. I've added a button at the top of the interfaces list to toggle the display of IP addresses.
adam commented 2025-12-29 16:24:53 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Apr 13, 2017):

Please review and let me know what you think

It's neat. I like the use of speech bubbles for the IP Description.

I'd still prefer to move "Critical Connections" onto the right-hand column. Reasons:

  1. These are all just types of physical connection, so I feel they logically belong together. That is, the RH column would contain all connections (IP interfaces, management IP interfaces, power, console)
  2. To balance the screen layout better
  3. To give more prominence to "critical connections" which are currently pushed down beneath custom fields, secrets and services
  4. The "show IPs" checkbox (top RH) is currently performing action-at-a-distance, by showing/hiding management IPs low down in the left-hand column
@candlerb commented on GitHub (Apr 13, 2017): > Please review and let me know what you think It's neat. I like the use of speech bubbles for the IP Description. I'd still prefer to move "Critical Connections" onto the right-hand column. Reasons: 1. These are all just types of physical connection, so I feel they logically belong together. That is, the RH column would contain all connections (IP interfaces, management IP interfaces, power, console) 2. To balance the screen layout better 3. To give more prominence to "critical connections" which are currently pushed down beneath custom fields, secrets and services 4. The "show IPs" checkbox (top RH) is currently performing action-at-a-distance, by showing/hiding management IPs low down in the left-hand column
adam commented 2025-12-29 16:24:53 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Apr 13, 2017):

There is a minor issue of alignment of management IP connections versus power/console connections, at least when they are in the "Not connected" state.

image

@candlerb commented on GitHub (Apr 13, 2017): There is a minor issue of alignment of management IP connections versus power/console connections, at least when they are in the "Not connected" state. ![image](https://cloud.githubusercontent.com/assets/44789/25000681/1a4c2d6a-203a-11e7-80e7-e1f9099aae0c.png)
adam commented 2025-12-29 16:24:53 +01:00
Author
Owner
Copy Link

@snazy2000 commented on GitHub (Apr 13, 2017):

Only thing if move stuff to the right is that when you have a switch that has 48 ports it will be quite far down the page.

It would be cool if there was the ability to move the tiles around based on the user's needs and it then saves that to the db

@snazy2000 commented on GitHub (Apr 13, 2017): Only thing if move stuff to the right is that when you have a switch that has 48 ports it will be quite far down the page. It would be cool if there was the ability to move the tiles around based on the user's needs and it then saves that to the db
adam commented 2025-12-29 16:24:53 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Apr 13, 2017):

Only thing if move stuff to the right is that when you have a switch that has 48 ports it will be quite far down the page.

This is true, although they'd still be easy to find by scrolling to the bottom of the page, rather than being buried in the middle of the left-hand column.

Alternatively, I probably wouldn't object to having the "Critical" connections at the top of the RH column.

@candlerb commented on GitHub (Apr 13, 2017): > Only thing if move stuff to the right is that when you have a switch that has 48 ports it will be quite far down the page. This is true, although they'd still be easy to find by scrolling to the bottom of the page, rather than being buried in the middle of the left-hand column. Alternatively, I probably wouldn't object to having the "Critical" connections at the top of the RH column.
adam commented 2025-12-29 16:24:54 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 13, 2017):

I'm going to keep critical connections grouped together as I like being able to see them separately. This is especially valuable for network gear with many interfaces.

The "show IPs" checkbox (top RH) is currently performing action-at-a-distance, by showing/hiding management IPs low down in the left-hand column.

True, I'll fix it so that management interface IPs are always displayed.

@jeremystretch commented on GitHub (Apr 13, 2017): I'm going to keep critical connections grouped together as I like being able to see them separately. This is especially valuable for network gear with many interfaces. > The "show IPs" checkbox (top RH) is currently performing action-at-a-distance, by showing/hiding management IPs low down in the left-hand column. True, I'll fix it so that management interface IPs are always displayed.
adam commented 2025-12-29 16:24:54 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 13, 2017):

This should be good for now. I'm going to close this out. We'll see what people think with the 1.9.6 release.

@jeremystretch commented on GitHub (Apr 13, 2017): This should be good for now. I'm going to close this out. We'll see what people think with the 1.9.6 release.
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 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#696
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?