-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Description
Deployment Type
Self-hosted
NetBox Version
v4.1.0
Python Version
3.12
Steps to Reproduce
- Navigate to a device with module bays that existed before v4.1
- Set a parent on a module bay
a. Edit an existing module bay and set the parent to an existing module; OR
b. Add a new module bay with the parent set to an existing module
This has been verified on local systems that have been upgraded to v4.1, but you can also see an example of this happening on the demo site if you add a new module bay "Subslot 0/0" to module "Slot 0" on device "ncsu-coreswitch1". I understand that the demo site cannot be relied on and the example is purely for reference using data included in the standard database refresh.
Expected Behavior
The module bay appears in the list with the correct depth under the module bay for the parent module.
Observed Behavior
When the parent is changed on an existing module bay, the error "A node may not be made a child of any of its descendants." is presented. When a new module bay is added, the new module bay has the correct depth, but does not appear in the correct location in the module bay list.
A new module bay being added to a parent module in a new module bay appears to exhibit the expected behavior.
This looks like classic symptoms of MPTT being out of sync. When RackGroups were made nestable back in v2.8, the following migration was included:
https://github.com/netbox-community/netbox/blob/v2.8.0/netbox/dcim/migrations/0102_nested_rackgroups_rebuild.py. I do not see a similar migration accompanying https://github.com/netbox-community/netbox/blob/v4.1.0/netbox/dcim/migrations/0190_nested_modules.py.