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

unexpected interface ordering behaviour #946

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

Originally created by @bleything on GitHub (May 12, 2017).

Issue type: bug report

Python version: 2.7.5
NetBox version: v2.0.1

I've got switches that have ports named 1/g[1-48] and 1/xg[1-4]. No matter how I set the interface ordering, they always display in a specific order that doesn't make sense to me. On the device type page:

screenshot 2017-05-12 11 32 12

On a specific device page:

screenshot 2017-05-12 11 34 09

It's very possible that I am just misunderstanding how this is supposed to work... but I would expect the xgN interfaces to sort to the bottom in alphabetical mode, at the very least. And I'd expect the sorting to change when I change the interface ordering option. Aaaaaaaaand it's pretty weird that xg3 and xg4 sort differently on the device type page vs. the device page.

Is this an actual bug or am I just not understanding what's happening?

Originally created by @bleything on GitHub (May 12, 2017). ### Issue type: bug report **Python version:** 2.7.5 **NetBox version:** v2.0.1 I've got switches that have ports named `1/g[1-48]` and `1/xg[1-4]`. No matter how I set the interface ordering, they always display in a specific order that doesn't make sense to me. On the device type page: ![screenshot 2017-05-12 11 32 12](https://cloud.githubusercontent.com/assets/270/26011636/c1f417de-3706-11e7-91d2-34c7a12248fb.png) On a specific device page: ![screenshot 2017-05-12 11 34 09](https://cloud.githubusercontent.com/assets/270/26011700/ff3d2b4e-3706-11e7-9705-e59c67ddc989.png) It's very possible that I am just misunderstanding how this is supposed to work... but I would expect the `xgN` interfaces to sort to the bottom in alphabetical mode, at the very least. And I'd expect the sorting to change when I change the interface ordering option. Aaaaaaaaand it's pretty weird that `xg3` and `xg4` sort differently on the device type page vs. the device page. Is this an actual bug or am I just not understanding what's happening?
adam added the type: bug label 2025-12-29 16:27:10 +01:00
adam closed this issue 2025-12-29 16:27:10 +01:00
adam commented 2025-12-29 16:27:10 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 12, 2017):

This is happening because the intermingled alphabetic characters inside the numeric slot/position are not matched by the regexes we use for ordering. Only the leading "1" is being matched, so the interfaces are essentially unordered.

I'm going to tweak the ordering so that it uses the entire name field as a tiebreaker. This will result in a deterministic order for the names listed above, however it won't be perfect. For example, 1/g11 will be listed before 1/g2 because we're not able to cast the position as an independent integer.

@jeremystretch commented on GitHub (May 12, 2017): This is happening because the intermingled alphabetic characters inside the numeric slot/position are not matched by the regexes we use for ordering. Only the leading "1" is being matched, so the interfaces are essentially unordered. I'm going to tweak the ordering so that it uses the entire name field as a tiebreaker. This will result in a deterministic order for the names listed above, however it won't be perfect. For example, `1/g11` will be listed before `1/g2` because we're not able to cast the position as an independent integer.
adam commented 2025-12-29 16:27:11 +01:00
Author
Owner
Copy Link

@bleything commented on GitHub (May 12, 2017):

Ah, I guess I expected that when it was set to alphabetic, it would sort the entire string... but you're saying it's just a subset? What's the goal there?

@bleything commented on GitHub (May 12, 2017): Ah, I guess I expected that when it was set to alphabetic, it would sort the entire string... but you're saying it's just a subset? What's the goal there?
adam commented 2025-12-29 16:27:11 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 12, 2017):

@bleything The name is broken into segments so that we can CAST() and sort on integers to achieve a more natural ordering. Otherwise, we end up with things like:

  • ge-0/0/1
  • ge-0/0/10
  • ge-0/0/11
  • ge-0/0/2
  • ge-0/0/3

It's not a flawless approach but it's the best we have at the moment.

@jeremystretch commented on GitHub (May 12, 2017): @bleything The name is [broken into segments](https://github.com/digitalocean/netbox/blob/develop/netbox/dcim/models.py#L813) so that we can `CAST()` and sort on integers to achieve a more natural ordering. Otherwise, we end up with things like: * ge-0/0/1 * ge-0/0/10 * ge-0/0/11 * ge-0/0/2 * ge-0/0/3 It's not a flawless approach but it's the best we have at the moment.
adam commented 2025-12-29 16:27:11 +01:00
Author
Owner
Copy Link

@bleything commented on GitHub (May 12, 2017):

Ah, got it! Thanks for the explanation. Totally makes sense; it's a complicated kind of thing to order.

@bleything commented on GitHub (May 12, 2017): Ah, got it! Thanks for the explanation. Totally makes sense; it's a complicated kind of thing to order.
adam commented 2025-12-29 16:27:11 +01:00
Author
Owner
Copy Link

@bleything commented on GitHub (May 12, 2017):

Oh, and thanks for the quick fix, too!

@bleything commented on GitHub (May 12, 2017): Oh, and thanks for the quick fix, too!
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#946
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?