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

IPAM: Child address list for IP prefix is garbled #7368

New Issue
Closed
opened 2025-12-29 20:22:24 +01:00 by adam · 11 comments
adam commented 2025-12-29 20:22:24 +01:00
Owner
Copy Link

Originally created by @peteeckel on GitHub (Dec 16, 2022).

Originally assigned to: @DanSheps, @jeremystretch on GitHub.

NetBox version

v3.4.0

Python version

3.8

Steps to Reproduce

  1. View a prefix with multiple non-sequentially assigned child addresses
  2. Click on "IP Addresses"

Expected Behavior

The list of IP address is displayed, with "xx IPs available" rows in rows between assigned IP address ranges

Observed Behavior

All "xx IPs available" placeholders are displayed at the top of the list.

Screenshot 2022-12-16 at 09 58 40

After clicking on the row header in order to sort the list, the "xx IPs available" placeholders are all gone.

Originally created by @peteeckel on GitHub (Dec 16, 2022). Originally assigned to: @DanSheps, @jeremystretch on GitHub. ### NetBox version v3.4.0 ### Python version 3.8 ### Steps to Reproduce 1. View a prefix with multiple non-sequentially assigned child addresses 2. Click on "IP Addresses" ### Expected Behavior The list of IP address is displayed, with "xx IPs available" rows in rows between assigned IP address ranges ### Observed Behavior All "xx IPs available" placeholders are displayed at the top of the list. <img width="1267" alt="Screenshot 2022-12-16 at 09 58 40" src="https://user-images.githubusercontent.com/6815386/208062314-05c0d85e-63bd-4332-a302-366376af09a4.png"> After clicking on the row header in order to sort the list, the "xx IPs available" placeholders are all gone.
adam added the type: bugstatus: acceptedseverity: low labels 2025-12-29 20:22:24 +01:00
adam closed this issue 2025-12-29 20:22:25 +01:00
adam commented 2025-12-29 20:22:25 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Dec 16, 2022):

This is caused by an incomplete fix to https://github.com/netbox-community/netbox/issues/9328:

899b61264f

To be clear, the now intended functionality is remove the avaliable ip rows when the table is sorted. The bug here is that they are only removed when the list has just been sorted, and not when the list was allready sorted when loaded.

A workaround to the problem of the avaliable IP's not being shown is to press the small x in the column header to reset the sort.

@kkthxbye-code commented on GitHub (Dec 16, 2022): This is caused by an incomplete fix to https://github.com/netbox-community/netbox/issues/9328: https://github.com/netbox-community/netbox/commit/899b61264f8f1283c787920048e98854e95db169 To be clear, the now intended functionality is remove the avaliable ip rows when the table is sorted. The bug here is that they are only removed when the list has just been sorted, and not when the list was allready sorted when loaded. A workaround to the problem of the avaliable IP's not being shown is to press the small x in the column header to reset the sort.
adam commented 2025-12-29 20:22:25 +01:00
Author
Owner
Copy Link

@peteeckel commented on GitHub (Dec 16, 2022):

Thanks! It makes perfect sense to remove the available IP rows when the list is sorted by any column other than IP addresses. When sorted by IP addresses the would rows make sense, otherwise they don't - or am I missing something?

Removing the sorting by clicking on "x" indeed works around the problem. The question is, however, why the list initially came up sorted by "status" when I first opened it ... is the sorting stored somewhere? When I open the list of IPs for other prefixes there is no sorting enabled by default.

[Edit] The list came up sorted by IP address, not by status ... I was fooled (again) by the red "x" being displayed next to "status" when actually it is referring to the column left of it.

@peteeckel commented on GitHub (Dec 16, 2022): Thanks! It makes perfect sense to remove the available IP rows when the list is sorted by any column other than IP addresses. When sorted by IP addresses the would rows make sense, otherwise they don't - or am I missing something? Removing the sorting by clicking on "x" indeed works around the problem. The question is, however, why the list initially came up sorted by "status" when I first opened it ... is the sorting stored somewhere? When I open the list of IPs for other prefixes there is no sorting enabled by default. [Edit] The list came up sorted by IP address, not by status ... I was fooled (again) by the red "x" being displayed next to "status" when actually it is referring to the column left of it.
adam commented 2025-12-29 20:22:26 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Dec 16, 2022):

When sorted by IP addresses the would rows make sense, otherwise they don't - or am I missing something?

I can't remember exactly (so don't hold me to this), but I believe it's a question of it being hard to implement with the way ordering and the addition of the available IP rows work. The solution is a compromise as the default sort is already sorted by IP. The thing that would be missing is a reversed sort by IP address, but the amount of work required is probably not worth it.

The question is, however, why the list initially came up sorted by "status" when I first opened it ... is the sorting stored somewhere?

Yes all sorting (and chosen columns) is stored on a user-basis. You can see them and reset them in the bottom of the preference view: /user/preferences/

@kkthxbye-code commented on GitHub (Dec 16, 2022): > When sorted by IP addresses the would rows make sense, otherwise they don't - or am I missing something? I can't remember exactly (so don't hold me to this), but I believe it's a question of it being hard to implement with the way ordering and the addition of the available IP rows work. The solution is a compromise as the default sort is already sorted by IP. The thing that would be missing is a reversed sort by IP address, but the amount of work required is probably not worth it. > The question is, however, why the list initially came up sorted by "status" when I first opened it ... is the sorting stored somewhere? Yes all sorting (and chosen columns) is stored on a user-basis. You can see them and reset them in the bottom of the preference view: /user/preferences/
adam commented 2025-12-29 20:22:26 +01:00
Author
Owner
Copy Link

@peteeckel commented on GitHub (Dec 16, 2022):

That makes sense, thanks for the information. I agree, having the available IP rows as long as the sorting is by IP address would be nice, though it's certainly not worth a major effort.

@peteeckel commented on GitHub (Dec 16, 2022): That makes sense, thanks for the information. I agree, having the available IP rows as long as the sorting is by IP address would be nice, though it's certainly not worth a major effort.
adam commented 2025-12-29 20:22:26 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 16, 2022):

I believe it's a question of it being hard to implement with the way ordering and the addition of the available IP rows work.

Pretty much. We just don't have a great mechanism for annotating available IPs in between IPAddress records.

Fixing the bug itself is a bit tricky because we need to infer how the table is ordered to prepare the data, but we can't initialize the table until we have the data prepared. We'll probably need to introduce a utility function for determining a table's ordering, that can be used by both prep_table_data() under the view and by a table's configure() method.

@jeremystretch commented on GitHub (Dec 16, 2022): > I believe it's a question of it being hard to implement with the way ordering and the addition of the available IP rows work. Pretty much. We just don't have a great mechanism for annotating available IPs in between IPAddress records. Fixing the bug itself is a bit tricky because we need to infer how the table is ordered to prepare the data, but we can't initialize the table until we have the data prepared. We'll probably need to introduce a utility function for determining a table's ordering, that can be used by both `prep_table_data()` under the view and by a table's `configure()` method.
adam commented 2025-12-29 20:22:26 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Feb 15, 2023):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Feb 15, 2023): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:22:26 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 23, 2023):

This is also an issue when filtering the objects list, as non-matching objects may be incorrectly annotated as available space.

@jeremystretch commented on GitHub (Feb 23, 2023): This is also an issue when filtering the objects list, as non-matching objects may be incorrectly annotated as available space.
adam commented 2025-12-29 20:22:27 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (May 25, 2023):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (May 25, 2023): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:22:27 +01:00
Author
Owner
Copy Link

@7qbit commented on GitHub (Sep 22, 2023):

please revise this problem again. we need sorting of “Available IP addresses” on TOP.

In addition, status=sorting does not meet the expectation of sorting by status; here, confusingly available IP addresses are removed.

Thank You.

@7qbit commented on GitHub (Sep 22, 2023): please revise this problem again. we need sorting of “Available IP addresses” on TOP. In addition, status=sorting does not meet the expectation of sorting by status; here, confusingly available IP addresses are removed. Thank You.
adam commented 2025-12-29 20:22:27 +01:00
Author
Owner
Copy Link

@AM-2027 commented on GitHub (Sep 25, 2023):

Hello all,

we have recently updated our instance to 3.6.2.
Because most users have saved a sort, they could not find available IP addresses. Only after having removed the sorting.

I think you have a malfunction here, users don't expect the sorting function to remove the objects now, but a sorting by all possible "statuses".

Second problem is that it is no longer possible to sort all available IP addresses on top, which was very handy before.

I find this a malfunction because sorting behavior is not the usual one you think.

@AM-2027 commented on GitHub (Sep 25, 2023): Hello all, we have recently updated our instance to 3.6.2. Because most users have saved a sort, they could not find available IP addresses. Only after having removed the sorting. I think you have a malfunction here, users don't expect the sorting function to remove the objects now, but a sorting by all possible "statuses". Second problem is that it is no longer possible to sort all available IP addresses on top, which was very handy before. I find this a malfunction because sorting behavior is not the usual one you think.
adam commented 2025-12-29 20:22:27 +01:00
Author
Owner
Copy Link

@peteeckel commented on GitHub (Sep 25, 2023):

I agree with you that it would be useful to have a list of available IP ranges in one place.

However, having a couple of 'xxx IP Addresses Available' lines on top of a list sorted by criteria other than IP address is not really helpful, even more so as there is no other information about these ranges available. That was confusing, misleading and IMHO a bug (which was fixed subsequently).

One option to solve both issues could be a separate tab listing all free address ranges, sorted by IP address. That way they would all be visible in one place without messing up the IP address list in other views. That could even be implemented as a plugin rather easily if a feature request were unsuccessful.

Suggestion: Instead of insisting on a bugfix being reverted, please open a FR for the functionality described above.

@peteeckel commented on GitHub (Sep 25, 2023): I agree with you that it would be useful to have a list of available IP ranges in one place. However, having a couple of 'xxx IP Addresses Available' lines on top of a list sorted by criteria other than IP address is not really helpful, even more so as there is no other information about these ranges available. That was confusing, misleading and IMHO a bug (which was fixed subsequently). One option to solve both issues could be a separate tab listing all free address ranges, sorted by IP address. That way they would all be visible in one place without messing up the IP address list in other views. That could even be implemented as a plugin rather easily if a feature request were unsuccessful. Suggestion: Instead of insisting on a bugfix being reverted, please open a FR for the functionality described above.
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: low 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#7368
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?