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

Add color field to interfaces #5361

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

Originally created by @ypid on GitHub (Sep 11, 2021).

NetBox version

v3.0.2

Feature type

Data model extension

Proposed functionality

See #3682.

Use case

Network devices can also have color coded ports, for example to differentiate WAN and LAN ports of a consumer grade router.

Database changes

Yes, similar to #3682.

External dependencies

No.

Originally created by @ypid on GitHub (Sep 11, 2021). ### NetBox version v3.0.2 ### Feature type Data model extension ### Proposed functionality See #3682. ### Use case Network devices can also have color coded ports, for example to differentiate WAN and LAN ports of a consumer grade router. ### Database changes Yes, similar to #3682. ### External dependencies No.
adam added the type: feature label 2025-12-29 19:27:08 +01:00
adam closed this issue 2025-12-29 19:27:08 +01:00
adam commented 2025-12-29 19:27:08 +01:00
Author
Owner
Copy Link

@thatmattlove commented on GitHub (Oct 5, 2021):

Is there any reason why tags aren't suitable for the use-case? Tags are also colored, and you can assign more than one, and consume them in other useful ways (filtering, API, etc).

@thatmattlove commented on GitHub (Oct 5, 2021): Is there any reason why tags aren't suitable for the use-case? Tags are also colored, and you can assign more than one, and consume them in other useful ways (filtering, API, etc).
adam commented 2025-12-29 19:27:08 +01:00
Author
Owner
Copy Link

@ypid commented on GitHub (Oct 9, 2021):

Tags are only available for Devices, but the Interface color is usually already defined at the Device Type level. Tags don’t really cut it. It would also be a totally different UX compared to front/back ports.

@ypid commented on GitHub (Oct 9, 2021): Tags are only available for Devices, but the Interface color is usually already defined at the Device Type level. Tags don’t really cut it. It would also be a totally different UX compared to front/back ports.
adam commented 2025-12-29 19:27:09 +01:00
Author
Owner
Copy Link

@thatmattlove commented on GitHub (Oct 16, 2021):

That's fair. Since tags can't be applied to a Device Type's interface, you'd have to individually edit each Device instance's interfaces to apply your logic. We'll review the request in further detail.

@thatmattlove commented on GitHub (Oct 16, 2021): That's fair. Since tags can't be applied to a Device Type's interface, you'd have to individually edit each Device instance's interfaces to apply your logic. We'll review the request in further detail.
adam commented 2025-12-29 19:27:09 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Oct 19, 2021):

Is there any reason custom fields, which are available for interfaces now, aren't usable for this?

NetBox is heavily used in the Enteperise space, and a great deal of ports in that space are not "colored"

@DanSheps commented on GitHub (Oct 19, 2021): Is there any reason custom fields, which are available for interfaces now, aren't usable for this? NetBox is heavily used in the Enteperise space, and a great deal of ports in that space are not "colored"
adam commented 2025-12-29 19:27:09 +01:00
Author
Owner
Copy Link

@ypid commented on GitHub (Oct 20, 2021):

Same issue as with Tags. Even in the Enterprise, network admins still deal with "consumer" equipment, for example when connecting a site to the Internet. And there it can be a big help when you can say on the phone "the yellow port (LAN)" should be plugged in.

@ypid commented on GitHub (Oct 20, 2021): Same issue as with Tags. Even in the Enterprise, network admins still deal with "consumer" equipment, for example when connecting a site to the Internet. And there it can be a big help when you can say on the phone "the yellow port (LAN)" should be plugged in.
adam commented 2025-12-29 19:27:09 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Oct 27, 2021):

Even in the Enterprise, network admins still deal with "consumer" equipment, for example when connecting a site to the Internet.

These sound like 1-offs which can be dealt with with custom fields. I don't see any reason to introduce a feature that the vast majority of people won't really worry about when it can be accomplished by a custom field.

@DanSheps commented on GitHub (Oct 27, 2021): > Even in the Enterprise, network admins still deal with "consumer" equipment, for example when connecting a site to the Internet. These sound like 1-offs which can be dealt with with custom fields. I don't see any reason to introduce a feature that the vast majority of people won't really worry about when it can be accomplished by a custom field.
adam commented 2025-12-29 19:27:09 +01:00
Author
Owner
Copy Link

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

I'm with @DanSheps on this. I don't see why it would even be necessary to track these colors, since the interfaces are already labeled. FYI color was added to pass-through ports because different color modules are often used to convey some attribute of the physical path. Such is not the case with interfaces. IMO if you really need to track this, a custom field is the answer.

@jeremystretch commented on GitHub (Nov 15, 2021): I'm with @DanSheps on this. I don't see why it would even be necessary to track these colors, since the interfaces are already labeled. FYI color was added to pass-through ports because different color modules are often used to convey some attribute of the physical path. Such is not the case with interfaces. IMO if you really need to track this, a custom field is the answer.
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#5361
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?