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 location to rack clone fields #9928

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

Originally created by @alehaa on GitHub (Jul 2, 2024).

NetBox version

v4.0.6

Feature type

Change to existing functionality

Proposed functionality

When creating or editing a device, all racks in a location are selectable, including racks in child locations. If you select a rack in a child location, saving the device is rejected with this error message:

Rack RACK01 does not belong to location PARENT.

Therefore, I suggest that all racks of a location (including child locations) can be selected in the form. When saving, the location of the device will be replaced by the location of the rack, thus automatically correcting it if needed.

Steps to reproduce:

  • Create location PARENT
  • Create child location CHILD
  • Create rack RACK01 in CHILD
  • Create new device. Select location PARENT and RACK01 as rack.
  • Save

Use case

The structure of the locations is entirely up to the NetBox user. A typical scenario could be to have parent locations for the room and child locations for the rack rows named "R1", "R2", ... in each room. Searching for the room is quite easy because it is unique. Finding the right rack row is not as easy, as there are several with the same name.

Also, it seems a bit odd that the racks are selectable in the UI and the backend does not accept the user's choice.

Database changes

None

External dependencies

None

Originally created by @alehaa on GitHub (Jul 2, 2024). ### NetBox version v4.0.6 ### Feature type Change to existing functionality ### Proposed functionality When creating or editing a device, all racks in a location are selectable, including racks in child locations. If you select a rack in a child location, saving the device is rejected with this error message: > Rack RACK01 does not belong to location PARENT. Therefore, I suggest that all racks of a location (including child locations) can be selected in the form. When saving, the location of the device will be replaced by the location of the rack, thus automatically correcting it if needed. **Steps to reproduce:** * Create location PARENT * Create child location CHILD * Create rack RACK01 in CHILD * Create new device. Select location PARENT and RACK01 as rack. * Save ### Use case The structure of the locations is entirely up to the NetBox user. A typical scenario could be to have parent locations for the room and child locations for the rack rows named "R1", "R2", ... in each room. Searching for the room is quite easy because it is unique. Finding the right rack row is not as easy, as there are several with the same name. Also, it seems a bit odd that the racks are selectable in the UI and the backend does not accept the user's choice. ### Database changes None ### External dependencies None
adam closed this issue 2025-12-29 21:24:34 +01:00
adam commented 2025-12-29 21:24:35 +01:00
Author
Owner
Copy Link

@alehaa commented on GitHub (Sep 13, 2024):

I volunteer to work on a PR for this feature.

@alehaa commented on GitHub (Sep 13, 2024): I volunteer to work on a PR for this feature.
adam commented 2025-12-29 21:24:36 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 16, 2024):

Thanks @alehaa, I've assigned this to you.

@jeremystretch commented on GitHub (Sep 16, 2024): Thanks @alehaa, I've assigned this to you.
adam commented 2025-12-29 21:24:36 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 19, 2024):

Searching for the room is quite easy because it is unique. Finding the right rack row is not as easy, as there are several with the same name.

@alehaa It sounds like what you're after is a mechanism to easily filter for objects assigned to a location or any of its child locations. Is that accurate?

@jeremystretch commented on GitHub (Sep 19, 2024): > Searching for the room is quite easy because it is unique. Finding the right rack row is not as easy, as there are several with the same name. @alehaa It sounds like what you're after is a mechanism to easily filter for objects assigned to a location _or_ any of its child locations. Is that accurate?
adam commented 2025-12-29 21:24:36 +01:00
Author
Owner
Copy Link

@alehaa commented on GitHub (Sep 21, 2024):

No, the (device) objects are pretty easy for us to find. However, creating / editing them sometimes has pitfalls.

Real life problem on our site:

  1. Employee creates new device.
  2. Employee assigns device to location Data Center Room 01, rack Rack 17.
  3. Operator saves the device.
  4. NetBox displays error because Rack 17 is not in Datacenter Room 01, but in Datacenter Room 01 > Row A.

This problem occurs because the Device edit form displays all racks in a location, including child locations. There are (at least) two possible solutions:

  1. Limit the racks in the device edit form to those of the location, NOT including child locations. This would reflect the implementation of dcim.models.Device.check().
  2. Change the implementation of Device.check() / Device.save() so that the location (and perhaps the site) is copied from the rack. Since the rack has a defined location / site, its clear where the device should be located.

However, my inquiry was that solution 1 could make the workflow a bit difficult for employees: While it is clear to search for the location Data Center Room 01, searching for Row A might result in multiple items from different locations named the same. The device edit form doesn't display additional information about a location's parent locations. Also, a technician might not even know what row a rack is in, only the room (parent location). Typing the room into the location field of the device edit form wouldn't show the child locations, so you might be able to select them if you only know the parent location.

@alehaa commented on GitHub (Sep 21, 2024): No, the (device) objects are pretty easy for us to find. However, creating / editing them sometimes has pitfalls. Real life problem on our site: 1. Employee creates new device. 2. Employee assigns device to location `Data Center Room 01`, rack `Rack 17`. 4. Operator saves the device. 5. NetBox displays error because `Rack 17` is not in `Datacenter Room 01`, but in `Datacenter Room 01 > Row A`. This problem occurs because the Device edit form displays all racks in a location, including child locations. There are (at least) two possible solutions: 1. Limit the racks in the device edit form to those of the location, NOT including child locations. This would reflect the implementation of `dcim.models.Device.check()`. 2. Change the implementation of `Device.check()` / `Device.save()` so that the location (and perhaps the site) is copied from the rack. Since the rack has a defined location / site, its clear where the device should be located. However, my inquiry was that solution 1 could make the workflow a bit difficult for employees: While it is clear to search for the location `Data Center Room 01`, searching for `Row A` might result in multiple items from different locations named the same. The device edit form doesn't display additional information about a location's parent locations. Also, a technician might not even know what row a rack is in, only the room (parent location). Typing the room into the location field of the device edit form wouldn't show the child locations, so you might be able to select them if you only know the parent location.
adam commented 2025-12-29 21:24:36 +01:00
Author
Owner
Copy Link

@alehaa commented on GitHub (Nov 22, 2024):

@jeremystretch are there any open questions? Since my previous PR was automatically closed, I don't know how to rework my code at the moment.

@alehaa commented on GitHub (Nov 22, 2024): @jeremystretch are there any open questions? Since my previous PR was automatically closed, I don't know how to rework my code at the moment.
adam commented 2025-12-29 21:24:37 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 9, 2025):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jul 9, 2025): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/main/CONTRIBUTING.md).
adam commented 2025-12-29 21:24:37 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Aug 8, 2025):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Aug 8, 2025): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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: low netbox pending closure status: needs owner 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#9928
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?