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

support color attribute on module type and device type import and export #6762

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

Originally created by @oasys on GitHub (Aug 2, 2022).

Originally assigned to: @oasys on GitHub.

NetBox version

v3.2.7

Feature type

Change to existing functionality

Proposed functionality

When importing module types via the web interface (Devices -> Module Types -> Import), allow specifying color attribute for front and rear ports. Also, when exporting module types via the web interface (Devices -> Module Types -> Export -> All Data (YAML)) include the color attribute for front and rear ports, if defined.

An example import file:

manufacturer: Generic
model: test-device
part_number: ''
comments: ''
front-ports:
- name: '1'
  type: lc
  rear_port: '1'
  rear_port_position: 1
  label: ''
  color: '3f51b5'
  description: ''
- name: '2'
  type: lc
  rear_port: '1'
  rear_port_position: 2
  label: ''
  color: '3f51b5'
  description: ''
rear-ports:
- name: '1'
  type: mpo
  positions: 2
  label: ''
  color: '000000'
  description: ''

Currently, it appears that the color field is ignored.

An export of that module type does not show the color.

manufacturer: Generic
model: test-device
part_number: ''
comments: ''
front-ports:
- name: '1'
  type: lc
  rear_port: '1'
  rear_port_position: 1
  label: ''
  description: ''
- name: '2'
  type: lc
  rear_port: '1'
  rear_port_position: 2
  label: ''
  description: ''
rear-ports:
- name: '1'
  type: mpo
  positions: 2
  label: ''
  description: ''

I see similar behavior with device types.

I'm not sure to consider this omission a bug or not, so am submitting as a FR.

Use case

It is useful to create a library of device type and module types outside of netbox for easy import into new installations. This would allow the inclusion of the color field in the objects in this library.

Database changes

none

External dependencies

none

Originally created by @oasys on GitHub (Aug 2, 2022). Originally assigned to: @oasys on GitHub. ### NetBox version v3.2.7 ### Feature type Change to existing functionality ### Proposed functionality When importing module types via the web interface (Devices -> Module Types -> Import), allow specifying `color` attribute for front and rear ports. Also, when exporting module types via the web interface (Devices -> Module Types -> Export -> All Data (YAML)) include the `color` attribute for front and rear ports, if defined. An example import file: ```yaml manufacturer: Generic model: test-device part_number: '' comments: '' front-ports: - name: '1' type: lc rear_port: '1' rear_port_position: 1 label: '' color: '3f51b5' description: '' - name: '2' type: lc rear_port: '1' rear_port_position: 2 label: '' color: '3f51b5' description: '' rear-ports: - name: '1' type: mpo positions: 2 label: '' color: '000000' description: '' ``` Currently, it appears that the `color` field is ignored. An export of that module type does not show the color. ```yaml manufacturer: Generic model: test-device part_number: '' comments: '' front-ports: - name: '1' type: lc rear_port: '1' rear_port_position: 1 label: '' description: '' - name: '2' type: lc rear_port: '1' rear_port_position: 2 label: '' description: '' rear-ports: - name: '1' type: mpo positions: 2 label: '' description: '' ``` I see similar behavior with device types. I'm not sure to consider this omission a bug or not, so am submitting as a FR. ### Use case It is useful to create a library of device type and module types outside of netbox for easy import into new installations. This would allow the inclusion of the color field in the objects in this library. ### Database changes none ### External dependencies none
adam added the status: acceptedtype: feature labels 2025-12-29 19:45:08 +01:00
adam closed this issue 2025-12-29 19:45:08 +01:00
adam commented 2025-12-29 19:45:09 +01:00
Author
Owner
Copy Link

@oasys commented on GitHub (Aug 3, 2022):

I have some working changes.

https://github.com/oasys/netbox/tree/9906-support-color-on-frontrearport-import-export

If you want to assign to me, I will submit a PR.

@oasys commented on GitHub (Aug 3, 2022): I have some working changes. https://github.com/oasys/netbox/tree/9906-support-color-on-frontrearport-import-export If you want to assign to me, I will submit a PR.
adam commented 2025-12-29 19:45:09 +01:00
Author
Owner
Copy Link

@oasys commented on GitHub (Aug 3, 2022):

#9911 submitted.

Should I also look at the other components, such as power ports (which I don't currently use) and others and add missing attributes? Or should we keep this change to only the color field for the front/rear ports as I originally submitted?

@oasys commented on GitHub (Aug 3, 2022): #9911 submitted. Should I also look at the other components, such as power ports (which I don't currently use) and others and add missing attributes? Or should we keep this change to only the color field for the front/rear ports as I originally submitted?
adam commented 2025-12-29 19:45:09 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 3, 2022):

Thanks @oasys! Let's keep this one confined to the color fields for front/rear ports. IIRC that's all that has been added recently, but if you find anything else missing an additional bug report would be much appreciated!

@jeremystretch commented on GitHub (Aug 3, 2022): Thanks @oasys! Let's keep this one confined to the color fields for front/rear ports. IIRC that's all that has been added recently, but if you find anything else missing an additional bug report would be much appreciated!
adam commented 2025-12-29 19:45:09 +01:00
Author
Owner
Copy Link

@oasys commented on GitHub (Aug 3, 2022):

Agreed. FWIW, I just checked the to_yaml return values for the other component templates (ConsolePorts, ConsoleServerPorts, PowerPorts, PowerOutlets, and Interfaces), and I don't see anything else missing.

@oasys commented on GitHub (Aug 3, 2022): Agreed. FWIW, I just checked the `to_yaml` return values for the other component templates (ConsolePorts, ConsoleServerPorts, PowerPorts, PowerOutlets, and Interfaces), and I don't see anything else missing.
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: 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#6762
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?