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 capability to clone items #19

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

Originally created by @bellwood on GitHub (Jun 27, 2016).

Originally assigned to: @jeremystretch on GitHub.

It would be nice to be able to duplicate items where in only the name or other small bit of information is different.

Use case, I have a few different 0U PDU's all with 24 ports, being able to dupe them would be nice

Originally created by @bellwood on GitHub (Jun 27, 2016). Originally assigned to: @jeremystretch on GitHub. It would be nice to be able to duplicate items where in only the name or other small bit of information is different. Use case, I have a few different 0U PDU's all with 24 ports, being able to dupe them would be nice
adam added the status: accepted label 2025-12-29 15:29:46 +01:00
adam closed this issue 2025-12-29 15:29:46 +01:00
adam commented 2025-12-29 15:29:46 +01:00
Author
Owner
Copy Link

@Armadill0 commented on GitHub (Jan 4, 2017):

I would also appreciate such a feature. My colleagues have to create several devices per week which are almost the same. This would massively enhance the speed of creating new devices.

@Armadill0 commented on GitHub (Jan 4, 2017): I would also appreciate such a feature. My colleagues have to create several devices per week which are almost the same. This would massively enhance the speed of creating new devices.
adam commented 2025-12-29 15:29:47 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Feb 8, 2017):

Following along

@ghost commented on GitHub (Feb 8, 2017): Following along
adam commented 2025-12-29 15:29:47 +01:00
Author
Owner
Copy Link

@33Fraise33 commented on GitHub (Aug 29, 2018):

Are there any plans on implementing this feature? Even though it's a "minor feature" it speeds up the process of documenting big installations with equal products of which only the serial number and name are different.

@33Fraise33 commented on GitHub (Aug 29, 2018): Are there any plans on implementing this feature? Even though it's a "minor feature" it speeds up the process of documenting big installations with equal products of which only the serial number and name are different.
adam commented 2025-12-29 15:29:47 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Oct 4, 2018):

Just for informational purposes, I'm adding my comments from NTC Slack concerning this FR:

Yeah, if [this] FR could be extended to include ConfigContexts that would be great!

@bdlamprecht commented on GitHub (Oct 4, 2018): Just for informational purposes, I'm adding my comments from NTC Slack concerning this FR: >Yeah, if [this] FR could be extended to include `ConfigContexts` that would be great!
adam commented 2025-12-29 15:29:48 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Mar 12, 2019):

If someone could extend this to include what they would like to see cloned on the individual models (Ex: Device, do we want: Interfaces, Front Ports, Rear Ports, Console, Power? What about IP Addresses? What about VLANs?)

@DanSheps commented on GitHub (Mar 12, 2019): If someone could extend this to include what they would like to see cloned on the individual models (Ex: Device, do we want: Interfaces, Front Ports, Rear Ports, Console, Power? What about IP Addresses? What about VLANs?)
adam commented 2025-12-29 15:29:49 +01:00
Author
Owner
Copy Link

@33Fraise33 commented on GitHub (Mar 14, 2019):

My idea is the following:

user clicks clone:
The create device form opens with all items filled in from the previous device. That way the most items can be unchanged but the things needed can be changed.

@33Fraise33 commented on GitHub (Mar 14, 2019): My idea is the following: user clicks clone: The create device form opens with all items filled in from the previous device. That way the most items can be unchanged but the things needed can be changed.
adam commented 2025-12-29 15:29:49 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Apr 3, 2019):

@DanSheps:

If someone could extend this to include what they would like to see cloned on the individual models (Ex: Device, do we want: Interfaces, Front Ports, Rear Ports, Console, Power? What about IP Addresses? What about VLANs?)

When you clone a Device, I would say the simplest approach is to give it fresh ports from the Device Type template.

For example: you definitely don't want to copy interface MAC addresses from the original device. It's very unlikely you want to duplicate linked IP addresses, which result in conflicts. I suppose sometimes you might want interface descriptions copied, but other times not (e.g. if description gives specific use case or customer reference)

So having a clean set of components would be fine IMO.

@33Fraise33:

user clicks clone:
The create device form opens with all items filled in from the previous device.

That's a fine suggestion. However the form for creating a device does not include Interfaces (or other components like power ports), and if it did, the Interfaces wouldn't include IP Addresses. This would require the device creation form to be a nested form - which would be a nice feature, but is a separate issue.

Creating the set of components from the Device Type template is (I think) the least surprising behaviour, since this is what a normal Device create does, and indeed is built into the model in Device.save

There is a related issue: in the case of a Virtual Machine, there is no equivalent to Device Type (#1492). Cloning a virtual machine could copy the named set of interfaces from the source, but clean them up (remove MAC/description). If the same logic were implemented for Device I'd be fine with that too.

This could be done by including a hidden field containing either a reference to the source device/VM, or a list of interfaces to create; and probably some text showing what interfaces are going to be created.

(Aside: VMs would particularly benefit from having a nested form, allowing you to create one or more interfaces at the time of creating a VM. A VM with no interfaces is useless, and it's painful to have to go through three different steps: create VM, add interface, add IP address. But that's a point for #1492)

@candlerb commented on GitHub (Apr 3, 2019): @DanSheps: > If someone could extend this to include what they would like to see cloned on the individual models (Ex: Device, do we want: Interfaces, Front Ports, Rear Ports, Console, Power? What about IP Addresses? What about VLANs?) When you clone a Device, I would say the simplest approach is to give it fresh ports from the Device Type template. For example: you definitely don't want to copy interface MAC addresses from the original device. It's very unlikely you want to duplicate linked IP addresses, which result in conflicts. I suppose sometimes you might want interface descriptions copied, but other times not (e.g. if description gives specific use case or customer reference) So having a clean set of components would be fine IMO. @33Fraise33: > user clicks clone: > The create device form opens with all items filled in from the previous device. That's a fine suggestion. However the form for creating a device does not include Interfaces (or other components like power ports), and if it did, the Interfaces wouldn't include IP Addresses. This would require the device creation form to be a nested form - which would be a nice feature, but is a separate issue. Creating the set of components from the Device Type template is (I think) the least surprising behaviour, since this is what a normal Device create does, and indeed is built into the model in [Device.save](https://github.com/digitalocean/netbox/blob/v2.5.9/netbox/dcim/models.py#L1594) ------ There is a related issue: in the case of a Virtual Machine, there is no equivalent to Device Type (#1492). Cloning a virtual machine *could* copy the named set of interfaces from the source, but clean them up (remove MAC/description). If the same logic were implemented for Device I'd be fine with that too. This could be done by including a hidden field containing either a reference to the source device/VM, or a list of interfaces to create; and probably some text showing what interfaces are going to be created. (Aside: VMs would particularly benefit from having a nested form, allowing you to create one or more interfaces at the time of creating a VM. A VM with no interfaces is useless, and it's painful to have to go through three different steps: create VM, add interface, add IP address. But that's a point for #1492)
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
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#19
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?