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

Tenant group details page show incorrect count of tenants in presence of child groups #7484

New Issue
Closed
opened 2025-12-29 20:23:58 +01:00 by adam · 5 comments
adam commented 2025-12-29 20:23:58 +01:00
Owner
Copy Link

Originally created by @volans- on GitHub (Jan 10, 2023).

NetBox version

v3.4.2

Python version

3.9

Steps to Reproduce

  1. Create one tenant group, say Customers
  2. Create at least one tenant setting the group to the created tenant (in my screenshots 11)
  3. Create a tenant group Test Subgroup, set the parent of this tenant group to any existing tenant group (in my screenshots the parent is Customers).
  4. Create a tenant Test Subgroup Tenant and set its parent to Test Subgroup.
  5. Go to the tenant groups page /tenancy/tenant-groups/
    • The tenant count for the Customers group is the sum of all the subgroups (12 in the screenshots)
  6. Click on the Customers group name (/tenancy/tenant-groups/1/ in my case):
    • The Tenants line show the count of only the tenants directly assigned to this group not including the subgroup (11 in the screenshots), differently from the previous page.
    • As a side note there is no mention in this detail page of the tenant group that there are child tenant groups
  7. Clicking on the count of tenants (11 in the screenshots) goes to the tenant search page filtered by the tenant group ID (/tenancy/tenants/?group_id=1 in my case):
    • Here 12 tenants are shown

Expected Behavior

  • It should be clear if the count of tenants in a tenant group should include tenants in the child groups or not, or show both counters.
  • In the tenant group details page /tenancy/tenant-groups/{id}/ the link with the count of tenants for the current group goes to a page that has a different number of results in presence of child groups, confusing the user.

Observed Behavior

Clicking on a link that show 11 as number of tenants goes to a search page that has a different number of results in presence of child groups.

See the screenshots below:

Screenshot 2023-01-10 at 11 24 58 Screenshot 2023-01-10 at 11 25 09 Screenshot 2023-01-10 at 11 25 21
Originally created by @volans- on GitHub (Jan 10, 2023). ### NetBox version v3.4.2 ### Python version 3.9 ### Steps to Reproduce 1. Create one tenant group, say `Customers` 2. Create at least one tenant setting the group to the created tenant (in my screenshots 11) 3. Create a tenant group `Test Subgroup`, set the parent of this tenant group to any existing tenant group (in my screenshots the parent is `Customers`). 5. Create a tenant `Test Subgroup Tenant` and set its parent to `Test Subgroup`. 6. Go to the tenant groups page `/tenancy/tenant-groups/` * The tenant count for the `Customers` group is the sum of all the subgroups (12 in the screenshots) 7. Click on the `Customers` group name (`/tenancy/tenant-groups/1/` in my case): * The `Tenants` line show the count of only the tenants directly assigned to this group not including the subgroup (11 in the screenshots), differently from the previous page. * As a side note there is no mention in this detail page of the tenant group that there are child tenant groups 8. Clicking on the count of tenants (11 in the screenshots) goes to the tenant search page filtered by the tenant group ID (`/tenancy/tenants/?group_id=1` in my case): * Here 12 tenants are shown ### Expected Behavior * It should be clear if the count of tenants in a tenant group should include tenants in the child groups or not, or show both counters. * In the tenant group details page `/tenancy/tenant-groups/{id}/` the link with the count of tenants for the current group goes to a page that has a different number of results in presence of child groups, confusing the user. ### Observed Behavior Clicking on a link that show `11` as number of tenants goes to a search page that has a different number of results in presence of child groups. See the screenshots below: <img width="401" alt="Screenshot 2023-01-10 at 11 24 58" src="https://user-images.githubusercontent.com/6888121/211531027-b38b819a-d9ec-4746-a73e-9cc20b50d6b8.png"> <img width="412" alt="Screenshot 2023-01-10 at 11 25 09" src="https://user-images.githubusercontent.com/6888121/211531051-094b0797-4e9a-4be6-89f1-fcd8a61e9532.png"> <img width="295" alt="Screenshot 2023-01-10 at 11 25 21" src="https://user-images.githubusercontent.com/6888121/211531069-a1e92eb0-410a-42e3-9343-6570704e38db.png">
adam added the type: bug label 2025-12-29 20:23:58 +01:00
adam closed this issue 2025-12-29 20:23:58 +01:00
adam commented 2025-12-29 20:23:58 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 10, 2023):

Per the bug report template that you completed when submitting this issue:

Additionally, do not rely on the demo instance for reproducing suspected bugs, as its data is prone to modification or deletion at any time.

Please modify your issue above to specify the NetBox version in use and provide reproduction steps that do not reference the demo instance.

@jeremystretch commented on GitHub (Jan 10, 2023): Per the bug report template that you completed when submitting this issue: > Additionally, **do not rely on the demo instance** for reproducing suspected bugs, as its data is prone to modification or deletion at any time. Please modify your issue above to specify the NetBox version in use and provide reproduction steps that do not reference the demo instance.
adam commented 2025-12-29 20:23:59 +01:00
Author
Owner
Copy Link

@volans- commented on GitHub (Jan 10, 2023):

Updated issue.

@volans- commented on GitHub (Jan 10, 2023): Updated issue.
adam commented 2025-12-29 20:23:59 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 12, 2023):

Ok, so there's an inconsistency between the number of child tenants reported in the tenant group list versus when viewing an individual tenant group. This is because the group list is showing the total number of child tenants within the group, whereas the group view considers only those which are immediate children of the group.

I see three options here:

  1. Change the list view to report only the number of immediate children. This seems like a poor choice, as we often want to see the total count per group.
  2. Change the tenants table when viewing a single group to include all child tenants, and add a "group" column to the table indicating the parent of each.
  3. Leave both as they are but better convey the context of the child tenants table, and adjust the tenants count displayed above it to match the number of results returned when following the link.

Leaving this open for discussion as I don't have a strong preference between options 2 and 3. However, I'll note that whatever we decide should be implemented consistently across all models which employ recursive nesting (e.g. regions, site groups, etc.).

@jeremystretch commented on GitHub (Jan 12, 2023): Ok, so there's an inconsistency between the number of child tenants reported in the tenant group _list_ versus when viewing an _individual_ tenant group. This is because the group list is showing the _total_ number of child tenants within the group, whereas the group view considers only those which are _immediate_ children of the group. I see three options here: 1. Change the list view to report only the number of immediate children. This seems like a poor choice, as we often want to see the total count per group. 2. Change the tenants table when viewing a single group to include _all_ child tenants, and add a "group" column to the table indicating the parent of each. 3. Leave both as they are but better convey the context of the child tenants table, and adjust the tenants count displayed above it to match the number of results returned when following the link. Leaving this open for discussion as I don't have a strong preference between options 2 and 3. However, I'll note that whatever we decide should be implemented consistently across all models which employ recursive nesting (e.g. regions, site groups, etc.).
adam commented 2025-12-29 20:23:59 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (May 4, 2023):

I am going to try and pick this up.

One thing to note, I believe this used to be the case with Locations as well and we fixed it to include all children so I would lean towards #2 and altering the detail view (I think that is what #2 is getting at) as that seems to be the biggest one that diverges. Both the filtered list view and the tenant group list view seem to report consistently and just the TG detail view does not report the same value as it is operating on immediate children. Maybe include the immediate children in there as well perhaps? Like:

Tenants (immediate): 12 (1)

@DanSheps commented on GitHub (May 4, 2023): I am going to try and pick this up. One thing to note, I believe this used to be the case with Locations as well and we fixed it to include all children so I would lean towards #2 and altering the detail view (I think that is what #2 is getting at) as that seems to be the biggest one that diverges. Both the filtered list view and the tenant group list view seem to report consistently and just the TG detail view does not report the same value as it is operating on immediate children. Maybe include the immediate children in there as well perhaps? Like: Tenants (immediate): 12 (1)
adam commented 2025-12-29 20:23:59 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (May 10, 2023):

Upon review, with the release of 3.5 at the earliest (may have been earlier) and with the move to use related_objects, this appears to be fully resolved with no further action required.

@DanSheps commented on GitHub (May 10, 2023): Upon review, with the release of 3.5 at the earliest (may have been earlier) and with the move to use related_objects, this appears to be fully resolved with no further action required.
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 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#7484
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?