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

On updating site+rack+position, sometimes position is set to null #2691

New Issue
Closed
opened 2025-12-29 18:21:08 +01:00 by adam · 1 comment
adam commented 2025-12-29 18:21:08 +01:00
Owner
Copy Link

Originally created by @candlerb on GitHub (Jun 22, 2019).

Environment

  • Python version: 3.5.2
  • NetBox version: 2.5.13
  • Browser: Chrome 75 under macOS

Steps to Reproduce

This isn't 100% reproducible, but I am posting here as it may be clear to someone what's going on. For full reproducer, see next post.

I am moving a bunch of machines between sites (data centre migration). I edit an existing machine, and change the dropdown selections:

  • select the new site
  • select the new rack
  • leave the position as "Front"
  • select the new U position (note: the correct set of available U positions in the new rack is shown)
  • click Update

However in quite a large number of cases - it seems around 50% - after saving the device it shows as "Unracked", and I have to edit it and set the U position again.

When I look at the browser network logs, I see that the POST to /dcim/devices/X/edit/ does not contain any "position" value in the formdata when this occurs. Example:

csrfmiddlewaretoken: <snip>
name: darmanager1
device_role: 25
manufacturer: 4
device_type: 43
serial: 
asset_tag: 
site: 7
rack: 46
face: 0
status: 1
platform: 
primary_ip4: 1334
primary_ip6: 
cluster_group: 
cluster: 
tenant_group: 
tenant: 
cf_Environment: 40
cf_Hardware 1st Responsibility: 
cf_Hardware 2nd Responsibility: 
cf_Warranty Expire Date: 
cf_Warranty Type: 
local_context_data: 
tags: move2
comments: 
_update:

Now, I tested with a device whose position in its old rack is U16, and I selected a new site/rack and new position U10. When I inspect the HTML in the browser, this is what I see in the relevant area:

<div class="form-group">

        <label class="col-md-3 control-label" for="id_position">Position</label>
        <div class="col-md-9">
            <select name="position" class="netbox-select2-api form-control select2-hidden-accessible" data-url="/api/dcim/racks/{{rack}}/units/" disabled-indicator="device" placeholder="None" data-additional-query-param-exclude="552" id="id_position" tabindex="-1" aria-hidden="true">
  <option value="">---------</option>

  <option value="47" disabled="disabled">U47</option>

  <option value="46" disabled="disabled">U46</option>

  <option value="45">U45</option>

... snip ...

  <option value="17">U17</option>

  <option value="16" selected="">U16</option>

  <option value="15" disabled="disabled">U15</option>

  <option value="14" disabled="disabled">U14</option>

  <option value="13">U13</option>

  <option value="12">U12</option>

  <option value="11">U11</option>

  <option value="10">U10</option>

  <option value="9">U9</option>

... snip ...

  <option value="1" disabled="disabled">U1</option>

</select><span class="select2 select2-container select2-container--bootstrap select2-container--above select2-container--focus" dir="ltr" style="width: 546px;"><span class="selection"><span class="select2-selection select2-selection--single" role="combobox" aria-haspopup="true" aria-expanded="false" tabindex="0" aria-labelledby="select2-id_position-container"><span class="select2-selection__rendered" id="select2-id_position-container" title="U10"><span class="select2-selection__clear">×</span>U10</span><span class="select2-selection__arrow" role="presentation"><b role="presentation"></b></span></span></span><span class="dropdown-wrapper" aria-hidden="true"></span></span>


                <span class="help-block">The lowest-numbered unit occupied by the device</span>

That is: the original <select> element is still there, with its original selected value (U16); plus a separate selection widget whose value is U10.

In this particular case, when I saved the device, it saved the rack position correctly.

I don't know how it works behind the scenes, but I have a guess: maybe the widget is updating the selection box at the time that the form is selected - that is, the selection is being updated from U16 to U10.

However, if the new rack position happens to be a disabled selection in the original rack, then the disabled selection is not posted in the form. This would be the case if the rack you're moving from is heavily occupied (most slots unavailable).

Expected Behavior

When device is saved, it remembers the selected site/rack and rack position.

Observed Behavior

When device is saved, it remembers the selected site/rack but the rack position is unset (null / "unracked").

Originally created by @candlerb on GitHub (Jun 22, 2019). ### Environment * Python version: 3.5.2 * NetBox version: 2.5.13 * Browser: Chrome 75 under macOS ### Steps to Reproduce ~~This isn't 100% reproducible, but I am posting here as it may be clear to someone what's going on.~~ For full reproducer, see next post. I am moving a bunch of machines between sites (data centre migration). I edit an existing machine, and change the dropdown selections: - select the new site - select the new rack - leave the position as "Front" - select the new U position (note: the correct set of available U positions in the new rack is shown) - click Update However in quite a large number of cases - it seems around 50% - after saving the device it shows as "Unracked", and I have to edit it and set the U position again. When I look at the browser network logs, I see that the POST to `/dcim/devices/X/edit/` does not contain any "position" value in the formdata when this occurs. Example: ``` csrfmiddlewaretoken: <snip> name: darmanager1 device_role: 25 manufacturer: 4 device_type: 43 serial: asset_tag: site: 7 rack: 46 face: 0 status: 1 platform: primary_ip4: 1334 primary_ip6: cluster_group: cluster: tenant_group: tenant: cf_Environment: 40 cf_Hardware 1st Responsibility: cf_Hardware 2nd Responsibility: cf_Warranty Expire Date: cf_Warranty Type: local_context_data: tags: move2 comments: _update: ``` Now, I tested with a device whose position in its old rack is U16, and I selected a new site/rack and new position U10. When I inspect the HTML in the browser, this is what I see in the relevant area: ``` <div class="form-group"> <label class="col-md-3 control-label" for="id_position">Position</label> <div class="col-md-9"> <select name="position" class="netbox-select2-api form-control select2-hidden-accessible" data-url="/api/dcim/racks/{{rack}}/units/" disabled-indicator="device" placeholder="None" data-additional-query-param-exclude="552" id="id_position" tabindex="-1" aria-hidden="true"> <option value="">---------</option> <option value="47" disabled="disabled">U47</option> <option value="46" disabled="disabled">U46</option> <option value="45">U45</option> ... snip ... <option value="17">U17</option> <option value="16" selected="">U16</option> <option value="15" disabled="disabled">U15</option> <option value="14" disabled="disabled">U14</option> <option value="13">U13</option> <option value="12">U12</option> <option value="11">U11</option> <option value="10">U10</option> <option value="9">U9</option> ... snip ... <option value="1" disabled="disabled">U1</option> </select><span class="select2 select2-container select2-container--bootstrap select2-container--above select2-container--focus" dir="ltr" style="width: 546px;"><span class="selection"><span class="select2-selection select2-selection--single" role="combobox" aria-haspopup="true" aria-expanded="false" tabindex="0" aria-labelledby="select2-id_position-container"><span class="select2-selection__rendered" id="select2-id_position-container" title="U10"><span class="select2-selection__clear">×</span>U10</span><span class="select2-selection__arrow" role="presentation"><b role="presentation"></b></span></span></span><span class="dropdown-wrapper" aria-hidden="true"></span></span> <span class="help-block">The lowest-numbered unit occupied by the device</span> ``` That is: the original `<select>` element is still there, with its original selected value (U16); plus a separate selection widget whose value is U10. In this particular case, when I saved the device, it saved the rack position correctly. I don't know how it works behind the scenes, but I have a guess: maybe the widget is updating the selection box at the time that the form is selected - that is, the selection is being updated from U16 to U10. However, if the new rack position happens to be a *disabled* selection in the original rack, then the disabled selection is not posted in the form. This would be the case if the rack you're moving from is heavily occupied (most slots unavailable). ### Expected Behavior When device is saved, it remembers the selected site/rack and rack position. ### Observed Behavior When device is saved, it remembers the selected site/rack but the rack position is unset (null / "unracked").
adam added the type: bugstatus: accepted labels 2025-12-29 18:21:08 +01:00
adam closed this issue 2025-12-29 18:21:08 +01:00
adam commented 2025-12-29 18:21:08 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Jun 22, 2019):

I have a 100% reproducer now.

  • Create two racks, "testrack1" and "testrack2" (they can be in the same site)
  • Create device "testdev1" in testrack1, Front, position U1 (any 1U device type is OK)
  • Create device "testdev2" in testrack1, Front, position U2 (ditto)
  • Now edit "testdev2"
    • Set rack to testrack2
    • Set position to U1
    • Click Update

You will find that testdev2 is now in testrack2, but its position is "unracked". That is, the selection of position U1 has been forgotten.

I think this supports my theory: because position U1 was unavailable in the original rack, and was disabled in the dropdown, the web page javascript is unable to select this position for the new rack.

(Presumably this problem would also manifest itself when the destination rack has a larger number of U positions than the source rack, but that's an unusual case)

@candlerb commented on GitHub (Jun 22, 2019): I have a 100% reproducer now. * Create two racks, "testrack1" and "testrack2" (they can be in the same site) * Create device "testdev1" in testrack1, Front, position U1 (any 1U device type is OK) * Create device "testdev2" in testrack1, Front, position U2 (ditto) * Now edit "testdev2" * Set rack to testrack2 * Set position to U1 * Click Update You will find that testdev2 is now in testrack2, but its position is "unracked". That is, the selection of position U1 has been forgotten. I think this supports my theory: because position U1 was unavailable in the original rack, and was disabled in the dropdown, the web page javascript is unable to select this position for the new rack. (Presumably this problem would also manifest itself when the destination rack has a larger number of U positions than the source rack, but that's an unusual case)
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: bug
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#2691
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?