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

List views of self-nesting (recursive) object types are displayed incorrectly #10872

New Issue
Closed
opened 2025-12-29 21:37:02 +01:00 by adam · 8 comments
adam commented 2025-12-29 21:37:02 +01:00
Owner
Copy Link

Originally created by @jii8by on GitHub (Mar 11, 2025).

Originally assigned to: @bctiemann on GitHub.

Deployment Type

Self-hosted

NetBox Version

v4.2.5

Python Version

3.11

Steps to Reproduce

  1. Create three regions without parent: "North America", "South America", "Europe"
  2. Create three child regions under North America: "United States", "Canada", "Mexico"
  3. Create three grandchildren within United States: "Wisconsin", "Oklahoma", "Tennessee"
  4. Navigate to /dcim/regions/ to view all regions

Expected Behavior

The three child regions that were created within North America are displayed directly below NA. Additionally, "Oklahoma", "Wisconsin" and "Tennessee" are indented under the US.

Observed Behavior

Child regions "Canada" and "Mexico" are below "Europe". Grandchild "Oklahoma" is now in "Mexico".

Image

Note that this might not be the only list view that appears to be broken. Replicating the above steps as contact groups behaves in a similar way:

Image
Originally created by @jii8by on GitHub (Mar 11, 2025). Originally assigned to: @bctiemann on GitHub. ### Deployment Type Self-hosted ### NetBox Version v4.2.5 ### Python Version 3.11 ### Steps to Reproduce 1. Create three regions without parent: "North America", "South America", "Europe" 2. Create three child regions under North America: "United States", "Canada", "Mexico" 3. Create three grandchildren within United States: "Wisconsin", "Oklahoma", "Tennessee" 4. Navigate to /dcim/regions/ to view all regions ### Expected Behavior The three child regions that were created within North America are displayed directly below NA. Additionally, "Oklahoma", "Wisconsin" and "Tennessee" are indented under the US. ### Observed Behavior Child regions "Canada" and "Mexico" are below "Europe". Grandchild "Oklahoma" is now in "Mexico". <img width="870" alt="Image" src="https://github.com/user-attachments/assets/8408f9e9-6566-4ab7-bfff-2930fba59989" /> Note that this might not be the only list view that appears to be broken. Replicating the above steps as contact groups behaves in a similar way: <img width="751" alt="Image" src="https://github.com/user-attachments/assets/5a019480-c3da-4754-bccf-5445cb4a5dc6" />
adam added the type: bugstatus: acceptedseverity: medium labels 2025-12-29 21:37:02 +01:00
adam closed this issue 2025-12-29 21:37:02 +01:00
adam commented 2025-12-29 21:37:04 +01:00
Author
Owner
Copy Link

@jnovinger commented on GitHub (Mar 11, 2025):

This is also happening in the Parent dropdown in create/edit forms and list view filter. The same behavior is happening in Tenant Groups.

@jnovinger commented on GitHub (Mar 11, 2025): This is also happening in the `Parent` dropdown in create/edit forms and list view filter. The same behavior is happening in Tenant Groups.
adam commented 2025-12-29 21:37:04 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 11, 2025):

Bumped this to medium severity as it seems pretty disruptive. Confirmed that this was introduced in v4.2.5; ordering is working as expected in v4.2.4.

@jeremystretch commented on GitHub (Mar 11, 2025): Bumped this to medium severity as it seems pretty disruptive. Confirmed that this was introduced in v4.2.5; ordering is working as expected in v4.2.4.
adam commented 2025-12-29 21:37:04 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 11, 2025):

This appears to be a regression introduced by 4ec1e6f16e under #18729.

@jeremystretch commented on GitHub (Mar 11, 2025): This appears to be a regression introduced by 4ec1e6f16ee54754d19df5c272860c2132aa2b2c under #18729.
adam commented 2025-12-29 21:37:05 +01:00
Author
Owner
Copy Link

@bctiemann commented on GitHub (Mar 11, 2025):

I was worried about these kinds of less-obvious consequences of that change.

Instead of applying the order_by centrally like in the above commit, maybe we need to do that more surgically (i.e. only on querysets that use annotate) even though that's potentially a lot of changes; or alternatively, maybe it's only these hierarchical view lists that need to be exempt and should not call super().get_queryset().

@bctiemann commented on GitHub (Mar 11, 2025): I was worried about these kinds of less-obvious consequences of that change. Instead of applying the `order_by` centrally like in the above commit, maybe we need to do that more surgically (i.e. only on querysets that use `annotate`) even though that's potentially a lot of changes; or alternatively, maybe it's only these hierarchical view lists that need to be exempt and should not call `super().get_queryset()`.
adam commented 2025-12-29 21:37:05 +01:00
Author
Owner
Copy Link

@bctiemann commented on GitHub (Mar 11, 2025):

Likely this is going to be happening on any NestedGroupModel. If we can exempt these classes from the central ordering enforcement that might be the way to go.

@bctiemann commented on GitHub (Mar 11, 2025): Likely this is going to be happening on any `NestedGroupModel`. If we can exempt these classes from the central ordering enforcement that might be the way to go.
adam commented 2025-12-29 21:37:06 +01:00
Author
Owner
Copy Link

@bctiemann commented on GitHub (Mar 11, 2025):

@jii8by Could you please check if the linked fix addresses all the situations where you've seen this behavior?

I have not yet checked whether there are any MPTT-based models that use annotate in their list view querysets, but I added a comment to caution against that pattern.

@bctiemann commented on GitHub (Mar 11, 2025): @jii8by Could you please check if the linked fix addresses all the situations where you've seen this behavior? I have not yet checked whether there are any MPTT-based models that use `annotate` in their list view querysets, but I added a comment to caution against that pattern.
adam commented 2025-12-29 21:37:06 +01:00
Author
Owner
Copy Link

@jii8by commented on GitHub (Mar 11, 2025):

@bctiemann I've added some sample data to all nested group models mentioned in the documentation:

  • dcim.Location
  • dcim.Region
  • dcim.SiteGroup
  • tenancy.ContactGroup
  • tenancy.TenantGroup
  • wireless.WirelessLANGroup

All of them behave similarly broken when trying to display a parent-child hierarchy. After applying your commit, these issues seem to be resolved.

Image
@jii8by commented on GitHub (Mar 11, 2025): @bctiemann I've added some sample data to all nested group models mentioned [in the documentation](https://netboxlabs.com/docs/netbox/en/stable/development/models/#nested-group-models): - dcim.Location - dcim.Region - dcim.SiteGroup - tenancy.ContactGroup - tenancy.TenantGroup - wireless.WirelessLANGroup All of them behave similarly broken when trying to display a parent-child hierarchy. After applying your commit, these issues seem to be resolved. <img width="781" alt="Image" src="https://github.com/user-attachments/assets/bffc73c7-72b6-4755-bc9d-3ea653d9959c" />
adam commented 2025-12-29 21:37:06 +01:00
Author
Owner
Copy Link

@ported-pw commented on GitHub (Mar 14, 2025):

The linked PR this was closed by does not seem to fix this. Using the current main branch, I still have the exact reported issue (with the regions list).

@ported-pw commented on GitHub (Mar 14, 2025): The linked PR this was closed by does not seem to fix this. Using the current `main` branch, I still have the exact reported issue (with the regions list).
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 severity: medium 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#10872
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?