Custom script - racks/sites inconsistency #3588

New Issue

adam · 2025-12-29T18:30:01+01:00

adam commented

2025-12-29 18:30:01 +01:00

Originally created by @cpmills1975 on GitHub (Apr 20, 2020).

Environment

Python version: 3.7.7
NetBox version: 2.8.0

Expected Behavior

If creating a device in a rack, the rack I've specified should be on the site specified. Given site A containing rack A1 and site B containing rack B1, it shouldn't be possible to create a device in rack A1 on site B.

Observed Behavior

Given a site A containing rack A1 and a site B containing rack B1, it seems I am able to create a device in rack A1 on site B. This doesn't seem right.

Discussion

I'm writing a custom script to parse an actual Excel workbook to import devices.
My input workbook includes the name of the rack which I resolve using

rack_obj = Rack.objects.get(name=rack_name)

I request the site in the custom script form using

site_obj = ObjectVar(
    label="Site",
    queryset=Site.objects.all()
)

I pass both of these to the Device constructor:

with transaction.atomic():
    device = Device(site=site_obj, rack=rack_obj, <other_stuff>)

and the device is created, in the rack specified and on the site specified - regardless of whether the rack specified actually exists on that site.

I've worked around this by changing the rack query to search for the rack name given in the site specified:

rack_obj = Rack.objects.get(name=rack_name, site=size_obj)

and this helps, but it seems odd that I should be able to create the object in a rack on the wrong site.

Reading the code, I see that the site is mandatory but the rack is optional. Would this be better the other way round or perhaps mandating that one of these is specified? If just the rack, the site should be derived from the site that the rack exists on? If both, should there be some error checking in place to make sure the rack and site are consistent?

Originally created by @cpmills1975 on GitHub (Apr 20, 2020).  ### Environment * Python version: 3.7.7 * NetBox version: 2.8.0  ### Expected Behavior If creating a device in a rack, the rack I've specified should be on the site specified. Given site A containing rack A1 and site B containing rack B1, it shouldn't be possible to create a device in rack A1 on site B.  ### Observed Behavior Given a site A containing rack A1 and a site B containing rack B1, it seems I am able to create a device in rack A1 on site B. This doesn't seem right.  ### Discussion I'm writing a custom script to parse an actual Excel workbook to import devices. My input workbook includes the name of the rack which I resolve using ``` rack_obj = Rack.objects.get(name=rack_name) ``` I request the site in the custom script form using ``` site_obj = ObjectVar( label="Site", queryset=Site.objects.all() ) ``` I pass both of these to the Device constructor: ``` with transaction.atomic(): device = Device(site=site_obj, rack=rack_obj, <other_stuff>) ``` and the device is created, in the rack specified and on the site specified - regardless of whether the rack specified actually exists on that site. I've worked around this by changing the rack query to search for the rack name given in the site specified: ``` rack_obj = Rack.objects.get(name=rack_name, site=size_obj) ``` and this helps, but it seems odd that I should be able to create the object in a rack on the wrong site. Reading the code, I see that the site is mandatory but the rack is optional. Would this be better the other way round or perhaps mandating that one of these is specified? If just the rack, the site should be derived from the site that the rack exists on? If both, should there be some error checking in place to make sure the rack and site are consistent?

adam closed this issue

2025-12-29 18:30:01 +01:00

adam commented

2025-12-29 18:30:02 +01:00

@jeremystretch commented on GitHub (Apr 20, 2020):

Thank you for your interest in NetBox. GitHub issues are intended for reporting reproducible bugs and requesting features, and must be submitted using one of the templates provided here. For general discussion, questions, or assistance with installation issues, please post to our mailing list instead.

@jeremystretch commented on GitHub (Apr 20, 2020): Thank you for your interest in NetBox. GitHub issues are intended for reporting reproducible bugs and requesting features, and must be submitted using one of the templates provided [here](https://github.com/netbox-community/netbox/issues/new/choose). For general discussion, questions, or assistance with installation issues, please post to our [mailing list](https://groups.google.com/forum/#!forum/netbox-discuss) instead.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#3588