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

Display virtual interfaces with a different background color #4469

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

Originally created by @hoalex on GitHub (Jan 18, 2021).

Environment

  • Python version: 3.6.8
  • NetBox version: 2.10.2

Proposed Functionality

Display virtual interfaces on a device's interface table with a different background color (e.g. yellow).

Use Case

With the new look in Netbox 2.10, virtual interfaces can only be distinguished from physical interfaces by looking at the "Type" column.
On Netbox versions < 2.10, virtual interfaces ("Virtual", "LAG") were shown with a yellow background in a device's interface list. This made it easy to quickly distinguish virtual from physical interfaces, which was especially useful since virtual interfaces may have names that put them in between other physical interfaces. It would be nice to keep this functionality in the future.

Database Changes

None

External Dependencies

None

Originally created by @hoalex on GitHub (Jan 18, 2021). <!-- NOTE: IF YOUR ISSUE DOES NOT FOLLOW THIS TEMPLATE, IT WILL BE CLOSED. This form is only for proposing specific new features or enhancements. If you have a general idea or question, please start a discussion instead: https://github.com/netbox-community/netbox/discussions NOTE: Due to an excessive backlog of feature requests, we are not currently accepting any proposals which significantly extend NetBox's feature scope. Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report. --> ### Environment * Python version: 3.6.8 * NetBox version: 2.10.2 <!-- Describe in detail the new functionality you are proposing. Include any specific changes to work flows, data models, or the user interface. --> ### Proposed Functionality Display virtual interfaces on a device's interface table with a different background color (e.g. yellow). <!-- Convey an example use case for your proposed feature. Write from the perspective of a NetBox user who would benefit from the proposed functionality and describe how. ---> ### Use Case With the new look in Netbox 2.10, virtual interfaces can only be distinguished from physical interfaces by looking at the "Type" column. On Netbox versions < 2.10, virtual interfaces ("Virtual", "LAG") were shown with a yellow background in a device's interface list. This made it easy to quickly distinguish virtual from physical interfaces, which was especially useful since virtual interfaces may have names that put them in between other physical interfaces. It would be nice to keep this functionality in the future. <!-- Note any changes to the database schema necessary to support the new feature. For example, does the proposal require adding a new model or field? (Not all new features require database changes.) ---> ### Database Changes None <!-- List any new dependencies on external libraries or services that this new feature would introduce. For example, does the proposal require the installation of a new Python package? (Not all new features introduce new dependencies.) --> ### External Dependencies None
adam added the type: featurestatus: needs ownerpending closure labels 2025-12-29 18:36:20 +01:00
adam closed this issue 2025-12-29 18:36:20 +01:00
adam commented 2025-12-29 18:36:21 +01:00
Author
Owner
Copy Link

@lampwins commented on GitHub (Jan 19, 2021):

On the one hand, this might be considered a regression, but on the other, the interfaces table has historically been extremely complicated to render. With the refactor of all component tables, this might have actually been intended to reduce the complexity of the template.

@lampwins commented on GitHub (Jan 19, 2021): On the one hand, this might be considered a regression, but on the other, the interfaces table has historically been extremely complicated to render. With the refactor of all component tables, this might have actually been intended to reduce the complexity of the template.
adam commented 2025-12-29 18:36:21 +01:00
Author
Owner
Copy Link

@cpmills1975 commented on GitHub (Jan 20, 2021):

For what it is worth, I preferred the previous (extremely complicated) interfaces table, although I absolutely understand the desire to move towards a common table model across all component types. Would it be possible to compromise and as the OP requests, show virtual interfaces in a different color?

@cpmills1975 commented on GitHub (Jan 20, 2021): For what it is worth, I preferred the previous (extremely complicated) interfaces table, although I absolutely understand the desire to move towards a common table model across all component types. Would it be possible to compromise and as the OP requests, show virtual interfaces in a different color?
adam commented 2025-12-29 18:36:21 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 21, 2021):

Device components no longer use separate HTML templates; they are rendered using Table classes (from django-tables2). I'll mark this as "needs owner" for anyone who wants to take a shot at it, but please bear in mind that any acceptable solution must be succinct and highly maintainable (no hacking on the table classes, please).

@jeremystretch commented on GitHub (Jan 21, 2021): Device components no longer use separate HTML templates; they are rendered using Table classes (from django-tables2). I'll mark this as "needs owner" for anyone who wants to take a shot at it, but please bear in mind that any acceptable solution must be succinct and highly maintainable (no hacking on the table classes, please).
adam commented 2025-12-29 18:36:22 +01:00
Author
Owner
Copy Link

@cpmills1975 commented on GitHub (Jan 23, 2021):

I've had a look through the CSS classes and can see that the background colour of the row matches the colour of the cable status - green (success) for 'connected', yellow (warning) for decommissioning and blue (info) for planned.

I recall virtual interfaces were coloured yellow in earlier versions of netbox but of course that would now clash with decommissioning.

I'm thinking that since virtual interfaces can't have a cable connected to them, there would be no harm in colouring them, so long as the colours are different to the cable colours.

Sticking with the bootstrap colour scheme, would the devs accept rows with cables set to decommissioning to red (danger) to free up using yellow (warning) for virtual interface rows? Would the colour of the label for decommissioning need to also change to red or would it be acceptable to keep the label yellow but have the rows red (this doesn't feel right to me to be honest)? As far as I can see, red isn't currently used for any other cable status, but other areas of the UX use yellow for decommissioning and red for more problematic statuses - failed etc.

@cpmills1975 commented on GitHub (Jan 23, 2021): I've had a look through the CSS classes and can see that the background colour of the row matches the colour of the cable status - green (success) for 'connected', yellow (warning) for decommissioning and blue (info) for planned. I recall virtual interfaces were coloured yellow in earlier versions of netbox but of course that would now clash with decommissioning. I'm thinking that since virtual interfaces can't have a cable connected to them, there would be no harm in colouring them, so long as the colours are different to the cable colours. Sticking with the bootstrap colour scheme, would the devs accept rows with cables set to decommissioning to red (danger) to free up using yellow (warning) for virtual interface rows? Would the colour of the label for decommissioning need to also change to red or would it be acceptable to keep the label yellow but have the rows red (this doesn't feel right to me to be honest)? As far as I can see, red isn't currently used for any other cable status, but other areas of the UX use yellow for decommissioning and red for more problematic statuses - failed etc.
adam commented 2025-12-29 18:36:22 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Mar 19, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@stale[bot] commented on GitHub (Mar 19, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 18:36:22 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Apr 14, 2021):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Apr 14, 2021): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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 pending closure status: needs owner 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#4469
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?