starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-13 22:03:32 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Copy Template object Descriptions from DeviceType to Device during instantiation #10010

New Issue
Closed
opened 2025-12-29 21:25:36 +01:00 by adam · 1 comment
adam commented 2025-12-29 21:25:36 +01:00
Owner
Copy Link

Originally created by @ZPrimed on GitHub (Jul 26, 2024).

NetBox version

v4.0.7

Feature type

Change to existing functionality

Proposed functionality

I am filing this FR after reading the (closed) Issue #16275.

I propose that the Description field on various DeviceType "ThingTemplate" entities (InterfaceTemplate, FrontPortTemplate, RearPortTemplate, etc) be copied into each corresponding "Thing" on new Devices when they are instantiated via the DeviceType.

I am not a developer, but I tried to look through the code, and this didn't seem like it should be a major request, as other properties (Name and Label) are already being copied from the ThingTemplate when spawning a Device from a DeviceType. It's entirely possible I'm very wrong though. 😄 If this functionality is significantly difficult to implement, I'm not going to pitch a fit, but I wanted to raise my use case and it felt "wrong" to reply to a closed Issue for that.

Use case

My environment has many Devices that are substantially identical (albeit not 100%), spread across many sites. Including our "default" Interface & Front/RearPort Descriptions on the DeviceType (through the InterfaceTemplate | FrontPortTemplate | RearPortTemplate items attached to it) would significantly reduce the amount of labor required to "deploy"/describe those Devices in NetBox.

As it stands now, we need to enter a bunch of Descriptions by hand via the GUI, or create a script to automate the Device creation and then subsequent addition of Description text to various items. Note that in some cases, the "Description" here is simply a qualifier on a dumb Device like a fiber patch panel, so it's not something I could populate via network interrogation.

What is the purpose of DeviceType, if not to help reduce repetitive tasks?

FWIW, I do understand the current use-case for ThingTemplate.Description "staying behind" in the DeviceType, although I would argue that it is of fairly limited utility, and "special case DeviceType entries" could be served via the Notes field on a DeviceType. NetBox already copies other values from ThingTemplates (Name & Label), so it seems logical to me that Port/Interface Descriptions should also be copied, and obviously I'm not the only one who thought this way (per Issue #16275 and possibly others although I didn't turn up much else in a few searches).

Even in the case where you don't want a Description carried forward from the DeviceType, it is significantly quicker and easier to select a group of interfaces on a device, Mass-Edit, and Null the Description field, than it is to manually insert multiple different Descriptions on separate noncontiguous ports to align with a "default."

If Django simply isn't capable of doing this without significant work, I totally understand that development efforts go where they benefit most and I apologize for wasting everyone's time. 🙂 (Obviously I "could" fork the code and fix it myself, if I had the skills to do so.)

If I haven't swayed opinion at all on this, can I at least suggest a column/display name change or help text somewhere on the Template/DeviceType side? Something to clarify that the Description entries for ports/interfaces/etc are not going to be copied into the "real" Device. This might also prevent future Issues being raised over the behavior. 😉

Database changes

None expected

External dependencies

None

Originally created by @ZPrimed on GitHub (Jul 26, 2024). ### NetBox version v4.0.7 ### Feature type Change to existing functionality ### Proposed functionality I am filing this FR after reading the (closed) Issue #16275. I propose that the `Description` field on various DeviceType "ThingTemplate" entities (InterfaceTemplate, FrontPortTemplate, RearPortTemplate, etc) be **copied** into each corresponding "Thing" on new Devices when they are instantiated via the DeviceType. I am **not** a developer, but I tried to look through the code, and this didn't _seem_ like it should be a major request, as other properties (Name and Label) are already being copied from the ThingTemplate when spawning a Device from a DeviceType. It's entirely possible I'm very wrong though. 😄 If this functionality is significantly difficult to implement, I'm not going to pitch a fit, but I wanted to raise my use case and it felt "wrong" to reply to a closed Issue for that. ### Use case My environment has many Devices that are substantially identical (albeit not 100%), spread across many sites. Including our "default" Interface & Front/RearPort Descriptions on the DeviceType (through the InterfaceTemplate | FrontPortTemplate | RearPortTemplate items attached to it) would **significantly** reduce the amount of labor required to "deploy"/describe those Devices in NetBox. As it stands now, we need to enter a bunch of Descriptions by hand via the GUI, or create a script to automate the Device creation and then subsequent addition of Description text to various items. Note that in some cases, the "Description" here is simply a qualifier on a dumb Device like a fiber patch panel, so it's not something I could populate via network interrogation. What is the purpose of DeviceType, if _not_ to help reduce repetitive tasks? FWIW, I _do_ understand the current use-case for ThingTemplate.Description "staying behind" in the DeviceType, although I would argue that it is of fairly limited utility, and "special case DeviceType entries" could be served via the Notes field on a DeviceType. NetBox _already_ copies other values from ThingTemplates (Name & Label), so it seems logical to me that Port/Interface Descriptions should also be copied, and obviously I'm not the only one who thought this way (per Issue #16275 and possibly others although I didn't turn up much else in a few searches). Even in the case where you *don't* want a Description carried forward from the DeviceType, it is significantly quicker and easier to select a group of interfaces on a device, Mass-Edit, and Null the Description field, than it is to manually insert multiple different Descriptions on separate noncontiguous ports to align with a "default." If Django simply isn't capable of doing this without significant work, I totally understand that development efforts go where they benefit most and I apologize for wasting everyone's time. 🙂 (Obviously I "could" fork the code and fix it myself, if I had the skills to do so.) If I **haven't** swayed opinion at all on this, can I at least suggest a column/display name change or help text somewhere on the Template/DeviceType side? Something to clarify that the Description entries for ports/interfaces/etc are **not** going to be copied into the "real" Device. This might also prevent future Issues being raised over the behavior. 😉 ### Database changes None expected ### External dependencies None
adam added the type: featurestatus: duplicate labels 2025-12-29 21:25:36 +01:00
adam closed this issue 2025-12-29 21:25:36 +01:00
adam commented 2025-12-29 21:25:37 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 26, 2024):

This behavior has already been proposed, considered, and rejected for good reason. Please don't open duplicate issues., as it distracts from work that needs to be done.

If you want to alter NetBox's behavior, you are free to fork the code base and make whatever changes you wish to suit your use case.

@jeremystretch commented on GitHub (Jul 26, 2024): This behavior has already been proposed, considered, and rejected for good reason. Please don't open duplicate issues., as it distracts from work that needs to be done. If you want to alter NetBox's behavior, you are free to fork the code base and make whatever changes you wish to suit your use case.
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: duplicate 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#10010
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?