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

Ability to specify related objects by attribute during CSV import #2583

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

Originally created by @jeremystretch on GitHub (May 3, 2019).

Originally assigned to: @jeremystretch on GitHub.

Environment

  • Python version: 3.5.2
  • NetBox version: 2.5.12

Proposed Functionality

Currently, specifying a related object when importing a new object as CSV data requires the related object to have a unique name. For example, importing an IP address assigned to an interface might look like this:

address,status,device,interface
192.0.2.1/24,Active,router3,et-0/0/1

The combination of device name and interface name forms a unique identifier for the interface to which the new IP address should be assigned.

This proposal would allow a related object to be specified by an arbitrary set of fields. For example:

address,status,device,interface
192.0.2.1/24,Active,{site.name: "Raleigh", name: "router3"},et-0/0/1

This would allow the user to have multiple devices named "router3" yet specify the one belonging to site "Raleigh."

The specific formatting is up for debate; the above is intended solely as an illustration of the concept. Special consideration must be given to the use of commas, since parsing of the related object field is being done within the context of processing CSV data.

As I write this, I have to admit it feels like we're trying to squeeze too much functionality out of the CSV format: Maybe a JSON-centric approach would be preferable, but we'd need a low-friction solution for converting spreadsheet data into JSON.

Use Case

This FR was prompted by #2669, which would relax the uniqueness constraint on device and virtual machine names. If a device name cannot be assumed unique, a more robust approach to referencing devices must be implemented. We've already taken a step toward this approach with FlexibleModelChoiceField, which allows referencing an unnamed object by numeric ID (e.g. {{123}}).

Database Changes

None

External Dependencies

Probably none. We may end up using some external parsing library, depending on the approach chosen.

Originally created by @jeremystretch on GitHub (May 3, 2019). Originally assigned to: @jeremystretch on GitHub. ### Environment * Python version: 3.5.2 * NetBox version: 2.5.12 ### Proposed Functionality Currently, specifying a related object when importing a new object as CSV data requires the related object to have a unique name. For example, importing an IP address assigned to an interface might look like this: ``` address,status,device,interface 192.0.2.1/24,Active,router3,et-0/0/1 ``` The combination of device name and interface name forms a unique identifier for the interface to which the new IP address should be assigned. This proposal would allow a related object to be specified by an arbitrary set of fields. For example: ``` address,status,device,interface 192.0.2.1/24,Active,{site.name: "Raleigh", name: "router3"},et-0/0/1 ``` This would allow the user to have multiple devices named "router3" yet specify the one belonging to site "Raleigh." The specific formatting is up for debate; the above is intended solely as an illustration of the concept. Special consideration must be given to the use of commas, since parsing of the related object field is being done within the context of processing CSV data. As I write this, I have to admit it feels like we're trying to squeeze too much functionality out of the CSV format: Maybe a JSON-centric approach would be preferable, but we'd need a low-friction solution for converting spreadsheet data into JSON. ### Use Case This FR was prompted by #2669, which would relax the uniqueness constraint on device and virtual machine names. If a device name cannot be assumed unique, a more robust approach to referencing devices must be implemented. We've already taken a step toward this approach with FlexibleModelChoiceField, which allows referencing an unnamed object by numeric ID (e.g. `{{123}}`). ### Database Changes None ### External Dependencies Probably none. We may end up using some external parsing library, depending on the approach chosen.
adam added the status: acceptedtype: feature labels 2025-12-29 18:20:07 +01:00
adam closed this issue 2025-12-29 18:20:08 +01:00
adam commented 2025-12-29 18:20:08 +01:00
Author
Owner
Copy Link

@tb-killa commented on GitHub (May 6, 2019):

Doesn´t we could use this as Base for the https://github.com/digitalocean/netbox/issues/822 and https://github.com/digitalocean/netbox/issues/451 ??

@tb-killa commented on GitHub (May 6, 2019): Doesn´t we could use this as Base for the https://github.com/digitalocean/netbox/issues/822 and https://github.com/digitalocean/netbox/issues/451 ??
adam commented 2025-12-29 18:20:08 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 6, 2019):

@tb-killa #822, yes. #451 is unrelated to CSV import.

@jeremystretch commented on GitHub (May 6, 2019): @tb-killa #822, yes. #451 is unrelated to CSV import.
adam commented 2025-12-29 18:20:08 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 13, 2019):

I think it makes sense to do something like this:

address,status,device.site,device.name,interface
192.0.2.1/24,Active,Site D,router3,et-0/0/1

I'm just not sure how we'd get there. It likely means throwing out the existing CSV import forms and starting largely from scratch.

@jeremystretch commented on GitHub (Dec 13, 2019): I think it makes sense to do something like this: ``` address,status,device.site,device.name,interface 192.0.2.1/24,Active,Site D,router3,et-0/0/1 ``` I'm just not sure how we'd get there. It likely means throwing out the existing CSV import forms and starting largely from scratch.
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#2583
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?