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 scope_name field when doing bulk ipam.prefixes imports #10687

New Issue
Closed
opened 2025-12-29 21:34:49 +01:00 by adam · 6 comments
adam commented 2025-12-29 21:34:49 +01:00
Owner
Copy Link

Originally created by @dhoffend on GitHub (Jan 23, 2025).

NetBox version

v4.2.2

Feature type

Change to existing functionality

Proposed functionality

Add scope_name in addition or as alternative field to scope_id when doing builk ipam.prefix (and others) imports.

Use case

Before updating from v4.1 to v4.2 we noticed the breaking change about the removal of the site field which got replaced by a combination of scope_type and scope_id. I don't question the need for the multipe scope types, but to have a better migration when doing bulk imports it would be nice to have a scope_name field in addition to scope_id. Of course you can only have one field filled (id or name).

Sure this would cause an id-lookup when scope_name is used (like in v4.1) but it would help the transition (we would just have to add scope_type=dcim.site and rename the csv field site to scope_name and continue instead of using numeric ids during mass imports.

Database changes

Not that I know of

External dependencies

None

Originally created by @dhoffend on GitHub (Jan 23, 2025). ### NetBox version v4.2.2 ### Feature type Change to existing functionality ### Proposed functionality Add `scope_name` in addition or as alternative field to `scope_id` when doing builk `ipam.prefix` (and others) imports. ### Use case Before updating from v4.1 to v4.2 we noticed the breaking change about the removal of the `site` field which got replaced by a combination of `scope_type` and `scope_id`. I don't question the need for the multipe scope types, but to have a better migration when doing bulk imports it would be nice to have a `scope_name` field in addition to `scope_id`. Of course you can only have one field filled (id or name). Sure this would cause an id-lookup when scope_name is used (like in v4.1) but it would help the transition (we would just have to add scope_type=dcim.site and rename the csv field site to scope_name and continue instead of using numeric ids during mass imports. ### Database changes Not that I know of ### External dependencies None
adam added the type: featurestatus: duplicate labels 2025-12-29 21:34:49 +01:00
adam closed this issue 2025-12-29 21:34:49 +01:00
adam commented 2025-12-29 21:34:50 +01:00
Author
Owner
Copy Link

@KPTheProf commented on GitHub (Jan 30, 2025):

I second this request, not been able to import using the scope name is major headache for us.
Users will only have the scope name data (i.e. site name if importing a dcim.site), the scope_id is just an internal reference.
I don't understand why this was changed to scope_id in the first place!

@KPTheProf commented on GitHub (Jan 30, 2025): I second this request, not been able to import using the scope name is major headache for us. Users will only have the scope name data (i.e. site name if importing a dcim.site), the scope_id is just an internal reference. I don't understand why this was changed to scope_id in the first place!
adam commented 2025-12-29 21:34:50 +01:00
Author
Owner
Copy Link

@bctiemann commented on GitHub (Feb 27, 2025):

This would apply to all GenericForeignKey relationships in scoped models. We would need a general way of specifying additional or alternate fields -- we default to id but can specify another field with unique values. For example we would replace scope_id with a generic scope column which would need an arbitrary accessor defined for it.

@bctiemann commented on GitHub (Feb 27, 2025): This would apply to all GenericForeignKey relationships in scoped models. We would need a general way of specifying additional or alternate fields -- we default to `id` but can specify another field with unique values. For example we would replace `scope_id` with a generic `scope` column which would need an arbitrary accessor defined for it.
adam commented 2025-12-29 21:34:50 +01:00
Author
Owner
Copy Link

@pheus commented on GitHub (Apr 13, 2025):

Hi there! I believe this feature request might be a duplicate of #18195 – "Enable specifying prefix scope object by name during bulk import". Could you please confirm if this is the case? Thanks!

@pheus commented on GitHub (Apr 13, 2025): Hi there! I believe this feature request might be a duplicate of #18195 – "Enable specifying prefix scope object by name during bulk import". Could you please confirm if this is the case? Thanks!
adam commented 2025-12-29 21:34:51 +01:00
Author
Owner
Copy Link

@impartialcricket commented on GitHub (Jul 14, 2025):

@pheus Yes looks to be a duplicate to me. I am also encountering this same issue.

What's worse is the import form for prefixes has no documentation for scope_id, the description says "scope id". As a new user I would expect the site_name is the id, hence how I found myself here.

edit: Above occurs on NetBox Cloud v4.3.3

@impartialcricket commented on GitHub (Jul 14, 2025): @pheus Yes looks to be a duplicate to me. I am also encountering this same issue. What's worse is the import form for prefixes has no documentation for scope_id, the description says "scope id". As a new user I would expect the site_name is the id, hence how I found myself here. edit: Above occurs on NetBox Cloud v4.3.3
adam commented 2025-12-29 21:34:51 +01:00
Author
Owner
Copy Link

@sjpilot commented on GitHub (Jul 18, 2025):

Whilst this is a duplicate, the other issue is closed due to inactivity. This issue has activity.

@sjpilot commented on GitHub (Jul 18, 2025): Whilst this is a duplicate, the other issue is closed due to inactivity. This issue has activity.
adam commented 2025-12-29 21:34:51 +01:00
Author
Owner
Copy Link

@dhoffend commented on GitHub (Jul 22, 2025):

Okay .. now we've 2 closed tickets. @jeremystretch Which one will be reopend? The other issue is closed "as not planned" due to inactivity from the bot.

@dhoffend commented on GitHub (Jul 22, 2025): Okay .. now we've 2 closed tickets. @jeremystretch Which one will be reopend? The other issue is closed "as not planned" due to inactivity from the bot.
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#10687
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?