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 support for templateable device-type descriptions #4824

New Issue
Closed
opened 2025-12-29 19:20:58 +01:00 by adam · 3 comments
adam commented 2025-12-29 19:20:58 +01:00
Owner
Copy Link

Originally created by @martinum4 on GitHub (Apr 24, 2021).

NetBox version

v2.11.1

Feature type

Data model extension

Proposed functionality

As described in the documentation descriptions are lost when generating a device from a device-type-template.

However in quite a few cases it is beneficial to have the interface or port-corresponding information written into the devices itself.

Use case

Examples:

  • Specifying allowed SFP-Power draw
  • Specifying PoE-Wattage
  • Marking Combo-Ports (#3189)
  • Marking Amperage of power ports (since some connectors e.g. IEC60309 connectors are available for 16/32/63A)
  • Informing about port specialties in regard to Crossover/MDI-X

Database changes

Needs an extra field

External dependencies

none

Originally created by @martinum4 on GitHub (Apr 24, 2021). ### NetBox version v2.11.1 ### Feature type Data model extension ### Proposed functionality As described in the [documentation](https://netbox.readthedocs.io/en/stable/core-functionality/device-types/#device-component-templates) descriptions are lost when generating a device from a device-type-template. However in quite a few cases it is beneficial to have the interface or port-corresponding information written into the devices itself. ### Use case Examples: - Specifying allowed SFP-Power draw - Specifying PoE-Wattage - Marking Combo-Ports (#3189) - Marking Amperage of power ports (since some connectors e.g. IEC60309 connectors are available for 16/32/63A) - Informing about port specialties in regard to Crossover/MDI-X ### Database changes Needs an extra field ### External dependencies none
adam added the type: featurepending closure labels 2025-12-29 19:20:58 +01:00
adam closed this issue 2025-12-29 19:20:58 +01:00
adam commented 2025-12-29 19:20:59 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 24, 2021):

IMO none of these examples are good uses of the description field, which is merely a string of free-form text and intended to be applied verbatim to an interface's configuration (e.g. description "what it says in NetBox").

Specifying allowed SFP-Power draw

This is an attribute of the installed optic, rather than the interface itself.

Specifying PoE-Wattage

This would be covered by #1099 (PoE modeling).

Marking Combo-Ports

This is a function of the device type; it does not change across instances of the device.

Marking Amperage of power ports

A custom field would be ideal for this.

Informing about port specialties in regard to Crossover/MDI-X

Not really sure what you mean here, but a tag would likely be more appropriate.

@jeremystretch commented on GitHub (Apr 24, 2021): IMO none of these examples are good uses of the description field, which is merely a string of free-form text and intended to be applied verbatim to an interface's configuration (e.g. `description "what it says in NetBox"`). > Specifying allowed SFP-Power draw This is an attribute of the installed optic, rather than the interface itself. > Specifying PoE-Wattage This would be covered by #1099 (PoE modeling). > Marking Combo-Ports This is a function of the device type; it does not change across instances of the device. > Marking Amperage of power ports A custom field would be ideal for this. > Informing about port specialties in regard to Crossover/MDI-X Not really sure what you mean here, but a tag would likely be more appropriate.
adam commented 2025-12-29 19:21:00 +01:00
Author
Owner
Copy Link

@martinum4 commented on GitHub (Apr 25, 2021):

Oh, these are for configuration use only? I would have taken it more broadly as an information field.

This is an attribute of the installed optic, rather than the interface itself.

There are two levels defined here, 1W and 1.5W, the latter requires a device-sided heatsink.

This is a function of the device type; it does not change across instances of the device.

Exactly this is why i want this information to be visible in all port descriptions that are created from the template.

A custom field would be ideal for this.

I just tried and the custom field does not show up in the port template, only in the final port of a device and thus not prefilled.

Not really sure what you mean here, but a tag would likely be more appropriate.

As in e.g. "nonstandard behaviour"?

@martinum4 commented on GitHub (Apr 25, 2021): Oh, these are for configuration use only? I would have taken it more broadly as an information field. >This is an attribute of the installed optic, rather than the interface itself. There are two levels defined here, 1W and 1.5W, the latter requires a device-sided heatsink. > This is a function of the device type; it does not change across instances of the device. Exactly this is why i want this information to be visible in all port descriptions that are created from the template. > A custom field would be ideal for this. I just tried and the custom field does not show up in the port template, only in the final port of a device and thus not prefilled. > Not really sure what you mean here, but a tag would likely be more appropriate. As in e.g. "nonstandard behaviour"?
adam commented 2025-12-29 19:21:00 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 25, 2021):

Oh, these are for configuration use only?

Yes, that's the field's intended use.

Exactly this is why i want this information to be visible in all port descriptions that are created from the template.

It's already available via the device's relationship to the device type. Replicating it is unnecessary and redundant.

I'm sorry but I don't really follow your other questions. Please consider opening a discussion if you'd like assistance with using custom fields and tags, as a feature request isn't the best place for such discussion.

@jeremystretch commented on GitHub (Apr 25, 2021): > Oh, these are for configuration use only? Yes, that's the field's intended use. > Exactly this is why i want this information to be visible in all port descriptions that are created from the template. It's already available via the device's relationship to the device type. Replicating it is unnecessary and redundant. I'm sorry but I don't really follow your other questions. Please consider opening a discussion if you'd like assistance with using custom fields and tags, as a feature request isn't the best place for such discussion.
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 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#4824
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?