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

Global Search shows IP Addresses in created order, not ascending order. #8699

New Issue
Closed
opened 2025-12-29 20:40:04 +01:00 by adam · 4 comments
adam commented 2025-12-29 20:40:04 +01:00
Owner
Copy Link

Originally created by @jjenjysk on GitHub (Oct 2, 2023).

NetBox version

v3.6.3

Python version

3.11

Steps to Reproduce

  1. Create IP Address objects in the following order: 10.0.0.20/24, 10.0.0.21/24, 10.0.0.1/24
  2. Search for 10.0.0 with global search

Expected Behavior

All IPs matching show up in ascending order (similar to IP Addresses tab).

Observed Behavior

All IPs were shown in created order.

image

Originally created by @jjenjysk on GitHub (Oct 2, 2023). ### NetBox version v3.6.3 ### Python version 3.11 ### Steps to Reproduce 1. Create IP Address objects in the following order: 10.0.0.20/24, 10.0.0.21/24, 10.0.0.1/24 2. Search for 10.0.0 with global search ### Expected Behavior All IPs matching show up in ascending order (similar to IP Addresses tab). ### Observed Behavior All IPs were shown in created order. ![image](https://github.com/netbox-community/netbox/assets/142209194/2063690c-e066-441d-bed0-20f9b87b1913)
adam closed this issue 2025-12-29 20:40:04 +01:00
adam commented 2025-12-29 20:40:06 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Oct 4, 2023):

This is actually the case for all kind of models. I observed the same for the device, sites, ....

@PieterL75 commented on GitHub (Oct 4, 2023): This is actually the case for all kind of models. I observed the same for the device, sites, ....
adam commented 2025-12-29 20:40:06 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 5, 2023):

All IPs matching show up in ascending order (similar to IP Addresses tab).

While I certainly understand your expectation, IMO it's a bit of a gray area to treat this a bug. Search results are intentionally ordered first by precedence (weight), then by object type, and finally by object ID:

class CachedValue:
    class Meta:
        ordering = ('weight', 'object_type', 'object_id')

This is because 1) the ordering of values among matching results does not imply stronger or weaker relevance to the query, and 2) it's likely there are cases where sorting by raw value may result in unexpected ordering (though I can't think of any at the moment). I'd be open to treating this as a feature request if we give the later point a bit more consideration.

@jeremystretch commented on GitHub (Oct 5, 2023): > All IPs matching show up in ascending order (similar to IP Addresses tab). While I certainly understand your expectation, IMO it's a bit of a gray area to treat this a bug. Search results are intentionally ordered first by precedence (weight), then by object type, and finally by object ID: ```python class CachedValue: class Meta: ordering = ('weight', 'object_type', 'object_id') ``` This is because 1) the ordering of values among matching results does not imply stronger or weaker relevance to the query, and 2) it's likely there are cases where sorting by raw value may result in unexpected ordering (though I can't think of any at the moment). I'd be open to treating this as a feature request if we give the later point a bit more consideration.
adam commented 2025-12-29 20:40:06 +01:00
Author
Owner
Copy Link

@jjenjysk commented on GitHub (Oct 10, 2023):

Personally I'd expect at least IP addresses/ranges to show up in ascending order instead of the order they were created in. I understand that it is a gray area to consider it a bug after your explanation, but I would like this as a feature.

@jjenjysk commented on GitHub (Oct 10, 2023): Personally I'd expect at least IP addresses/ranges to show up in ascending order instead of the order they were created in. I understand that it is a gray area to consider it a bug after your explanation, but I would like this as a feature.
adam commented 2025-12-29 20:40:06 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 13, 2023):

I've opened FR #14035 to track this proposal.

@jeremystretch commented on GitHub (Oct 13, 2023): I've opened FR #14035 to track this proposal.
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
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#8699
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?