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

Allow non-unique site names #10514

New Issue
Open
opened 2025-12-29 21:32:28 +01:00 by adam · 4 comments
adam commented 2025-12-29 21:32:28 +01:00
Owner
Copy Link

Originally created by @jakosp on GitHub (Nov 25, 2024).

NetBox version

v.4.1.6

Feature type

Change to existing functionality

Triage priority

N/A

Proposed functionality

Remove the uniqueness constraint on Site and Location names, so that multiple objects can be created with the same name.

Use case

When managing numerous branches (within Netbox), it is common for these branches to lack distinct names and are often identified solely by their location. The naming convention typically follows a pattern such as "Main Road 1," which is not akin to traditional and unique branch identifiers like "Branch A" or "Branch B."

The primary issue - in this case -arises from the high likelihood of branches sharing identical names. Here, branches are only distinguishable by the city (i.e., their region) they are located in. For instance:

  • Country A (Region)

    • City A (Region)

      • Branch Main Road 1 (Site)
      • Branch Plaza 3 (Site)

    • City B (Region)

      • Branch Main Road 1 (Site)

This naming limitation seems unnescessary as sites can be uniquely identified based on their hierarchical structure, or their Facility ID, if present.
It would completely suffice if the site would need to have a unique name within the scope of its parent.

This problem is somewhat related to issue #2669.

Database changes

It should suffice to remove the unique=True field in the site data model.

External dependencies

None

Originally created by @jakosp on GitHub (Nov 25, 2024). ### NetBox version v.4.1.6 ### Feature type Change to existing functionality ### Triage priority N/A ### Proposed functionality Remove the uniqueness constraint on Site and Location names, so that multiple objects can be created with the same name. ### Use case When managing numerous branches (within Netbox), it is common for these branches to lack distinct names and are often identified solely by their location. The naming convention typically follows a pattern such as "Main Road 1," which is not akin to traditional and unique branch identifiers like "Branch A" or "Branch B." The primary issue - in this case -arises from the high likelihood of branches sharing identical names. Here, branches are only distinguishable by the city (i.e., their region) they are located in. For instance: - Country A (Region) - City A (Region) - Branch Main Road 1 (Site) - Branch Plaza 3 (Site) - City B (Region) - Branch Main Road 1 (Site) This naming limitation seems unnescessary as sites can be uniquely identified based on their hierarchical structure, or their Facility ID, if present. It would completely suffice if the site would need to have a unique name within the scope of its parent. This problem is somewhat related to issue #2669. ### Database changes It should suffice to remove the unique=True field in the site data model. ### External dependencies None
adam added the type: featurecomplexity: mediumnetboxstatus: backlog labels 2025-12-29 21:32:28 +01:00
adam commented 2025-12-29 21:32:29 +01:00
Author
Owner
Copy Link

@tyler-8 commented on GitHub (Dec 6, 2024):

On the flip side, in many environments it is critical that site names are unique. If this feature were to be accepted, I would hope to see some kind of scoping added along side it, or maybe just a global configuration setting, similar to the setting that exists for globally unique IP objects.

@tyler-8 commented on GitHub (Dec 6, 2024): On the flip side, in many environments it is critical that site names are unique. If this feature were to be accepted, I would hope to see some kind of scoping added along side it, or maybe just a global configuration setting, similar to the setting that exists for globally unique IP objects.
adam commented 2025-12-29 21:32:29 +01:00
Author
Owner
Copy Link

@jakosp commented on GitHub (Dec 8, 2024):

While enforcing unique site names is a useful safeguard, applying this rule across the board can result in restrictions.
Instead, making site names unique within their specific hierarchy would allow NetBox to support such cases.

Ultimately, the decision should be left to the user to determine what works best for their specific situation. NetBox's structure should be flexible enough to represent their network without unnecessary restrictions. Safeguards are important, but there should be an option to disable them when needed and not technically required.

I believe that a tool like NetBox should enable its users and not unnecessarily restrict them. But please correct me here if I misunderstood something.

I support the idea of making this behavior configurable. This would prevent issues in environments where this restriction wasn't originally considered, while still allowing it to be enabled for those who need it.

Even with this change, sites would still have unique paths, such as:
/Country_A/City_A/Branch_Office and /Country_A/City_B/Branch_Office
This ensures that sites remain uniquely identifiable.

Trying to create another site with the same name and the same path should still be prevented, since this would only lead to problems.

Again, please correct me if I misunderstood something 😅

@jakosp commented on GitHub (Dec 8, 2024): While enforcing unique site names is a useful safeguard, applying this rule across the board can result in restrictions. Instead, making site names unique within their specific hierarchy would allow NetBox to support such cases. Ultimately, the decision should be left to the user to determine what works best for their specific situation. NetBox's structure should be flexible enough to represent their network without unnecessary restrictions. Safeguards are important, but there should be an option to disable them when needed and not technically required. I believe that a tool like NetBox should enable its users and not unnecessarily restrict them. But please correct me here if I misunderstood something. I support the idea of making this behavior configurable. This would prevent issues in environments where this restriction wasn't originally considered, while still allowing it to be enabled for those who need it. Even with this change, sites would still have unique paths, such as: `/Country_A/City_A/Branch_Office` and `/Country_A/City_B/Branch_Office` This ensures that sites remain uniquely identifiable. Trying to create another site with the same name and the same path should still be prevented, since this would only lead to problems. Again, please correct me if I misunderstood something 😅
adam commented 2025-12-29 21:32:30 +01:00
Author
Owner
Copy Link

@arthanson commented on GitHub (Feb 13, 2025):

This would also break bulk import with natural keys unless it is changed to support the hierarchy as well.

@arthanson commented on GitHub (Feb 13, 2025): This would also break bulk import with natural keys unless it is changed to support the hierarchy as well.
adam commented 2025-12-29 21:32:30 +01:00
Author
Owner
Copy Link

@justinbail commented on GitHub (Nov 14, 2025):

I too would like to have non-unique site names in netbox. As is netbox assigns a unique ID per site object. I like the idea of uniqueness being a configurable option. Another approach would be if a site would be created under a different tenant or region than another site with the same name then uniqueness would not be necessary as there would be a different "tree" path.

@justinbail commented on GitHub (Nov 14, 2025): I too would like to have non-unique site names in netbox. As is netbox assigns a unique ID per site object. I like the idea of uniqueness being a configurable option. Another approach would be if a site would be created under a different tenant or region than another site with the same name then uniqueness would not be necessary as there would be a different "tree" path.
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 complexity: medium netbox status: backlog 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#10514
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?