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

Natural sorting #1159

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

Originally created by @bellwood on GitHub (Aug 9, 2017).

Sorting still seems to be somewhat of an issue.

I know we touch on it in IRC from time to time but I don't see an issue open for it so I'm lodging one.

My specific issue relates to rack ordering in both elevations and rack listings.

My rack names are formatted as follows:

RACK_ID.ZONE_ID.LOCATION_ID

E.g:

R21.Z04.LOC1

My problem with the ordering is that currently I see racks listed like this:

...
R21.Z04.LOC1
R21.Z05.LOC1
R22.Z04.LOC1
R22.Z05.LOC1
R23.Z04.LOC1
R23.Z05.LOC1
R24.Z04.LOC1
R24.Z05.LOC1
R25.Z04.LOC1
R25.Z05.LOC1
...

As apposed to the preferred:

...
R21.Z04.LOC1
R22.Z04.LOC1
R23.Z04.LOC1
R24.Z04.LOC1
R25.Z04.LOC1
...

Which makes using the UI a chore; you're always hunting around for the "next rack" versus it just being right there.

Any improvements that could me made here would be immensely appreciated.

Originally created by @bellwood on GitHub (Aug 9, 2017). Sorting still seems to be somewhat of an issue. I know we touch on it in IRC from time to time but I don't see an issue open for it so I'm lodging one. My specific issue relates to rack ordering in both elevations and rack listings. My rack names are formatted as follows: RACK_ID.ZONE_ID.LOCATION_ID E.g: R21.Z04.LOC1 My problem with the ordering is that currently I see racks listed like this: ``` ... R21.Z04.LOC1 R21.Z05.LOC1 R22.Z04.LOC1 R22.Z05.LOC1 R23.Z04.LOC1 R23.Z05.LOC1 R24.Z04.LOC1 R24.Z05.LOC1 R25.Z04.LOC1 R25.Z05.LOC1 ... ``` As apposed to the preferred: ``` ... R21.Z04.LOC1 R22.Z04.LOC1 R23.Z04.LOC1 R24.Z04.LOC1 R25.Z04.LOC1 ... ``` Which makes using the UI a chore; you're always hunting around for the "next rack" versus it just being right there. Any improvements that could me made here would be immensely appreciated.
adam closed this issue 2025-12-29 16:29:36 +01:00
adam commented 2025-12-29 16:29:37 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 9, 2017):

...
R21.Z04.LOC1
R21.Z05.LOC1
R22.Z04.LOC1
R22.Z05.LOC1
R23.Z04.LOC1
R23.Z05.LOC1
R24.Z04.LOC1
R24.Z05.LOC1
R25.Z04.LOC1
R25.Z05.LOC1
...

The problem here is you're expressing a hierarchy from bottom-up instead of top-down. These strings are already arranged in natural alphanumeric order: altering this logic would inevitably upset natural ordering. If it's important to order racks by location/zone, consider rearranging the naming format to:

LOCATION_ID.ZONE_ID.RACK_ID

(FYI this sort of problem is why we prefer the ISO 8601 format YYYY-MM-DD for dates over MM-DD-YYYY or DD-MM-YYYY.)

@jeremystretch commented on GitHub (Aug 9, 2017): ``` ... R21.Z04.LOC1 R21.Z05.LOC1 R22.Z04.LOC1 R22.Z05.LOC1 R23.Z04.LOC1 R23.Z05.LOC1 R24.Z04.LOC1 R24.Z05.LOC1 R25.Z04.LOC1 R25.Z05.LOC1 ... ``` The problem here is you're expressing a hierarchy from bottom-up instead of top-down. These strings are already arranged in natural alphanumeric order: altering this logic would inevitably upset natural ordering. If it's important to order racks by location/zone, consider rearranging the naming format to: LOCATION_ID.ZONE_ID.RACK_ID (FYI this sort of problem is why we prefer the ISO 8601 format YYYY-MM-DD for dates over MM-DD-YYYY or DD-MM-YYYY.)
adam commented 2025-12-29 16:29:37 +01:00
Author
Owner
Copy Link

@bellwood commented on GitHub (Aug 9, 2017):

Well the issue there is that the naming convention follows hostname "standards" where in the most specific item is far left and least is far right.

racks are in zones
zones are in locations
locations are in company

So, R23.Z04.LOC1.mycompany.com

Reversing that doesn't really make sense to me and in most sorting implementations this isn't an issue - regardless of naming convention, sorting should evaluate this properly.

E.g - hierarchy:

be2952.agr11.iad03.atlas.cogentco.com

...not

atlas.iad03.agr11.be2952.cogentco.com

I don't think this is open and shut.

@bellwood commented on GitHub (Aug 9, 2017): Well the issue there is that the naming convention follows hostname "standards" where in the most specific item is far left and least is far right. racks are in zones zones are in locations locations are in company So, R23.Z04.LOC1.mycompany.com Reversing that doesn't really make sense to me and in most sorting implementations this isn't an issue - regardless of naming convention, sorting should evaluate this properly. E.g - hierarchy: be2952.agr11.iad03.atlas.cogentco.com ...not atlas.iad03.agr11.be2952.cogentco.com I don't think this is open and shut.
adam commented 2025-12-29 16:29:38 +01:00
Author
Owner
Copy Link

@bellwood commented on GitHub (Aug 9, 2017):

Just as an aside the only reason I have these crazy rack names is because the level at which names must be unique isn't scoped to a rack group and forces having to pad otherwise simple naming with gobs of extra data that then inevitably don't sort properly unless, apparently, I flip the names backwards.

If rack names were scoped to a rack group a lot of the hack could go away.

Just my .02 that multi-location, multi-group tracking of racks in Netbox, as it sits today, is painful.

@bellwood commented on GitHub (Aug 9, 2017): Just as an aside the only reason I have these crazy rack names is because the level at which names must be unique isn't scoped to a rack group and forces having to pad otherwise simple naming with gobs of extra data that then inevitably don't sort properly unless, apparently, I flip the names backwards. If rack names were scoped to a rack group a lot of the hack could go away. Just my .02 that multi-location, multi-group tracking of racks in Netbox, as it sits today, is painful.
adam commented 2025-12-29 16:29:38 +01:00
Author
Owner
Copy Link

@LBegnaud commented on GitHub (Aug 9, 2017):

Couldn't you populate the rack group to be "Z" and the site to map to "LOC1"? Then you would be able to filter the rack elevations by zone_id

@LBegnaud commented on GitHub (Aug 9, 2017): Couldn't you populate the rack group to be "Z<number>" and the site to map to "LOC1"? Then you would be able to filter the rack elevations by zone_id
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#1159
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?