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

Cloning a DeviceType should include all components #9894

New Issue
Closed
opened 2025-12-29 21:24:04 +01:00 by adam · 8 comments
adam commented 2025-12-29 21:24:04 +01:00
Owner
Copy Link

Originally created by @llamafilm on GitHub (Jun 24, 2024).

NetBox version

v4.0.5

Feature type

Change to existing functionality

Proposed functionality

When you click Clone on a Device Type, it will not prompt for confirmation, and immediately create a new Device Type with all the same properties and components (Interfaces, Power Ports, Power Outlets, Console/Front/Rear Ports, Module/Device Bays, and Inventory Items). Fields with unique constraint (model and slug) will have -clone appended.
The user will be redirected to the new object's page, where they can click Edit to make any changes necessary.

Use case

The word "clone" implies that the new object should match the original as closely as possible. Every time I clone a Device Type, it takes extra time to recreate all the power ports, interfaces, etc. Most of the time the components are identical. Even if not identical, they should be very similar, so it's faster to modify them instead of recreating. If the components are so different that this behavior is not desirable, then I think cloning doesn't really make sense and it would be better to create a new device from scratch.

Examples:

  • Cloning an Arista CCS-720XP-24Y6-F to make a CCS-720XP-24ZY4-F. This requires recreating 30 interfaces, a console port, and 2 module bays. Ideally, after cloning you would just have to bulk-edit the interfaces to change 1G to 2.5G.

  • Cloning a Supermicro 7048GP to a 7049GP. This requires recreating 2 power ports and 3 interfaces. I'd also like to model PCIe slots as module bays in the future, and cloning those components would help there too.

Database changes

I don't think so

External dependencies

No response

Originally created by @llamafilm on GitHub (Jun 24, 2024). ### NetBox version v4.0.5 ### Feature type Change to existing functionality ### Proposed functionality When you click **Clone** on a Device Type, it will not prompt for confirmation, and immediately create a new Device Type with all the same properties and components (Interfaces, Power Ports, Power Outlets, Console/Front/Rear Ports, Module/Device Bays, and Inventory Items). Fields with unique constraint (model and slug) will have `-clone` appended. The user will be redirected to the new object's page, where they can click **Edit** to make any changes necessary. ### Use case The word "clone" implies that the new object should match the original as closely as possible. Every time I clone a Device Type, it takes extra time to recreate all the power ports, interfaces, etc. Most of the time the components are identical. Even if not identical, they should be very similar, so it's faster to modify them instead of recreating. If the components are so different that this behavior is not desirable, then I think cloning doesn't really make sense and it would be better to create a new device from scratch. **Examples**: - Cloning an Arista CCS-720XP-24Y6-F to make a CCS-720XP-24ZY4-F. This requires recreating 30 interfaces, a console port, and 2 module bays. Ideally, after cloning you would just have to bulk-edit the interfaces to change 1G to 2.5G. - Cloning a Supermicro [7048GP](https://www.supermicro.com/products/system/4U/7048/SYS-7048GR-TR.cfm) to a [7049GP](https://www.supermicro.com/products/system/4U/7049/SYS-7049GP-TRT.cfm). This requires recreating 2 power ports and 3 interfaces. I'd also like to model PCIe slots as module bays in the future, and cloning those components would help there too. ### Database changes I don't think so ### External dependencies _No response_
adam added the type: featurepending closurestatus: revisions needed labels 2025-12-29 21:24:04 +01:00
adam closed this issue 2025-12-29 21:24:04 +01:00
adam commented 2025-12-29 21:24:04 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 25, 2024):

Thank you for your interest in extending NetBox. Unfortunately, the information you have provided does not constitute an actionable feature request. Per our contributing guide, a feature request must include a thorough description of the proposed functionality, including any database changes, new views or API endpoints, and so on. It must also include a detailed use case justifying its implementation. If you would like to elaborate on your proposal, please modify your post above. If sufficient detail is not added, this issue will be closed.

@jeremystretch commented on GitHub (Jun 25, 2024): Thank you for your interest in extending NetBox. Unfortunately, the information you have provided does not constitute an actionable feature request. Per our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md), a feature request must include a thorough description of the proposed functionality, including any database changes, new views or API endpoints, and so on. It must also include a detailed use case justifying its implementation. If you would like to elaborate on your proposal, please modify your post above. If sufficient detail is not added, this issue will be closed.
adam commented 2025-12-29 21:24:05 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Jun 25, 2024):

Cloning a device type can be accomplished by exporting it as YAML, making the necessary changes to the YAML file, then re-importing it. Unfortunately, there are some fields that are currently missing from the YAML export, like description, custom fields, and tags, so it's a little frustrating, but it does get you all the components at least. It would be nice to see the missing fields from the YAML be addressed. Maybe that would be sufficient to get what you're looking for in this issue?

@sleepinggenius2 commented on GitHub (Jun 25, 2024): Cloning a device type can be accomplished by exporting it as YAML, making the necessary changes to the YAML file, then re-importing it. Unfortunately, there are some fields that are currently missing from the YAML export, like description, custom fields, and tags, so it's a little frustrating, but it does get you all the components at least. It would be nice to see the missing fields from the YAML be addressed. Maybe that would be sufficient to get what you're looking for in this issue?
adam commented 2025-12-29 21:24:05 +01:00
Author
Owner
Copy Link

@llamafilm commented on GitHub (Jun 25, 2024):

@sleepinggenius2 thanks, that's a good idea. If custom fields were included, that would a good workaround, although I would prefer doing it in the GUI.

@llamafilm commented on GitHub (Jun 25, 2024): @sleepinggenius2 thanks, that's a good idea. If custom fields were included, that would a good workaround, although I would prefer doing it in the GUI.
adam commented 2025-12-29 21:24:06 +01:00
Author
Owner
Copy Link

@llamafilm commented on GitHub (Jun 26, 2024):

I just realized there is already an is_cloneable boolean on custom fields so I edited the request to be only about components.

@llamafilm commented on GitHub (Jun 26, 2024): I just realized there is already an `is_cloneable` boolean on custom fields so I edited the request to be only about components.
adam commented 2025-12-29 21:24:06 +01:00
Author
Owner
Copy Link

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

@llamafilm the existing cloning functionality merely compiles a URL which pre-populates certain field values for an object being created. It does not have provide the ability to create additional objects, nor was this ever an intended function.

For this to be an actionable feature request, you'll need to revise your original post above to include a detailed implementation proposal, describing the exact process by which component templates are replicated.

@jeremystretch commented on GitHub (Jul 2, 2024): @llamafilm the existing cloning functionality merely compiles a URL which pre-populates certain field values for an object being created. It does not have provide the ability to create additional objects, nor was this ever an intended function. For this to be an actionable feature request, you'll need to revise your original post above to include a detailed implementation proposal, describing the exact process by which component templates are replicated.
adam commented 2025-12-29 21:24:06 +01:00
Author
Owner
Copy Link

@llamafilm commented on GitHub (Jul 3, 2024):

Okay, I see what you mean. I revised the post.

I think the mechanics of this already exist, because this is essentially what happens when importing a Device Type YAML. (Except that custom fields should also be preserved.)

@llamafilm commented on GitHub (Jul 3, 2024): Okay, I see what you mean. I revised the post. I think the mechanics of this already exist, because this is essentially what happens when importing a Device Type YAML. (Except that custom fields should also be preserved.)
adam commented 2025-12-29 21:24:06 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 10, 2024):

This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.

@github-actions[bot] commented on GitHub (Jul 10, 2024): This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.
adam commented 2025-12-29 21:24:06 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 18, 2024):

This issue is being closed as no further information has been provided. If you would like to revisit this topic, please first modify your original post to include all the requested detail, and then ask that the issue be reopened.

@github-actions[bot] commented on GitHub (Jul 18, 2024): This issue is being closed as no further information has been provided. If you would like to revisit this topic, please first modify your original post to include all the requested detail, and then ask that the issue be reopened.
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: revisions needed 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#9894
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?