starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-13 05:50:33 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Connecting Interfaces B side is not sorted the same as A side #862

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

Originally created by @zevlag on GitHub (Apr 13, 2017).

Issue type: Bug

Python version: 2.7
NetBox version: v2.0.0-dev

https://netbox/dcim/devices/145/interface-connections/add/?interface_a=2141

When trying to connect interfaces, the A side list interfaces in this order:

GigabitEthernet0/0/1
GigabitEthernet0/0/2
GigabitEthernet0/0/3
GigabitEthernet0/0/4
GigabitEthernet0/0/5
GigabitEthernet0/0/6
GigabitEthernet0/0/7
GigabitEthernet0/0/8
GigabitEthernet0/0/9
GigabitEthernet0/0/10
GigabitEthernet0/0/11
GigabitEthernet0/0/12
GigabitEthernet0/0/13
GigabitEthernet0/0/14
GigabitEthernet0/0/15
GigabitEthernet0/0/16
GigabitEthernet0/0/17
GigabitEthernet0/0/18
GigabitEthernet0/0/19
GigabitEthernet0/0/20
GigabitEthernet0/0/21
GigabitEthernet0/0/22
GigabitEthernet0/0/23
GigabitEthernet0/0/24
GigabitEthernet0/0/25
GigabitEthernet0/0/26
GigabitEthernet0/0/27
GigabitEthernet0/0/28
GigabitEthernet0/0/29
GigabitEthernet0/0/30
GigabitEthernet0/0/31
GigabitEthernet0/0/32
GigabitEthernet0/0/33
GigabitEthernet0/0/34
GigabitEthernet0/0/35
GigabitEthernet0/0/36
GigabitEthernet0/0/37
GigabitEthernet0/0/38
GigabitEthernet0/0/39
GigabitEthernet0/0/40
GigabitEthernet0/0/41
GigabitEthernet0/0/42
GigabitEthernet0/0/43
GigabitEthernet0/0/44
GigabitEthernet0/0/45
GigabitEthernet0/0/46
GigabitEthernet0/0/47
GigabitEthernet0/0/48

If I select the same device for the B side, the interfaces are sorted in a different order:

GigabitEthernet0/0/1
GigabitEthernet0/0/10
GigabitEthernet0/0/11
GigabitEthernet0/0/12
GigabitEthernet0/0/13
GigabitEthernet0/0/14
GigabitEthernet0/0/15
GigabitEthernet0/0/16
GigabitEthernet0/0/17
GigabitEthernet0/0/18
GigabitEthernet0/0/19
GigabitEthernet0/0/2
GigabitEthernet0/0/20
GigabitEthernet0/0/21
GigabitEthernet0/0/22
GigabitEthernet0/0/23
GigabitEthernet0/0/24
GigabitEthernet0/0/25
GigabitEthernet0/0/26
GigabitEthernet0/0/27
GigabitEthernet0/0/28
GigabitEthernet0/0/29
GigabitEthernet0/0/3
GigabitEthernet0/0/30
GigabitEthernet0/0/31
GigabitEthernet0/0/32
GigabitEthernet0/0/33
GigabitEthernet0/0/34
GigabitEthernet0/0/35
GigabitEthernet0/0/36
GigabitEthernet0/0/37
GigabitEthernet0/0/38
GigabitEthernet0/0/39
GigabitEthernet0/0/4
GigabitEthernet0/0/40
GigabitEthernet0/0/41
GigabitEthernet0/0/42
GigabitEthernet0/0/43
GigabitEthernet0/0/44
GigabitEthernet0/0/45
GigabitEthernet0/0/46
GigabitEthernet0/0/47
GigabitEthernet0/0/48
GigabitEthernet0/0/5
GigabitEthernet0/0/6
GigabitEthernet0/0/7
GigabitEthernet0/0/8
Originally created by @zevlag on GitHub (Apr 13, 2017). <!-- Please note: GitHub issues are to be used only for feature requests and bug reports. For installation assistance or general discussion, please join us on the mailing list: https://groups.google.com/forum/#!forum/netbox-discuss Please indicate "bug report" or "feature request" below. Be sure to search the existing set of issues (both open and closed) to see if a similar issue has already been raised. --> ### Issue type: Bug <!-- If filing a bug, please indicate the version of Python and NetBox you are running. (This is not necessary for feature requests.) --> **Python version:** 2.7 **NetBox version:** v2.0.0-dev https://netbox/dcim/devices/145/interface-connections/add/?interface_a=2141 When trying to connect interfaces, the A side list interfaces in this order: ``` GigabitEthernet0/0/1 GigabitEthernet0/0/2 GigabitEthernet0/0/3 GigabitEthernet0/0/4 GigabitEthernet0/0/5 GigabitEthernet0/0/6 GigabitEthernet0/0/7 GigabitEthernet0/0/8 GigabitEthernet0/0/9 GigabitEthernet0/0/10 GigabitEthernet0/0/11 GigabitEthernet0/0/12 GigabitEthernet0/0/13 GigabitEthernet0/0/14 GigabitEthernet0/0/15 GigabitEthernet0/0/16 GigabitEthernet0/0/17 GigabitEthernet0/0/18 GigabitEthernet0/0/19 GigabitEthernet0/0/20 GigabitEthernet0/0/21 GigabitEthernet0/0/22 GigabitEthernet0/0/23 GigabitEthernet0/0/24 GigabitEthernet0/0/25 GigabitEthernet0/0/26 GigabitEthernet0/0/27 GigabitEthernet0/0/28 GigabitEthernet0/0/29 GigabitEthernet0/0/30 GigabitEthernet0/0/31 GigabitEthernet0/0/32 GigabitEthernet0/0/33 GigabitEthernet0/0/34 GigabitEthernet0/0/35 GigabitEthernet0/0/36 GigabitEthernet0/0/37 GigabitEthernet0/0/38 GigabitEthernet0/0/39 GigabitEthernet0/0/40 GigabitEthernet0/0/41 GigabitEthernet0/0/42 GigabitEthernet0/0/43 GigabitEthernet0/0/44 GigabitEthernet0/0/45 GigabitEthernet0/0/46 GigabitEthernet0/0/47 GigabitEthernet0/0/48 ``` If I select the same device for the B side, the interfaces are sorted in a different order: ``` GigabitEthernet0/0/1 GigabitEthernet0/0/10 GigabitEthernet0/0/11 GigabitEthernet0/0/12 GigabitEthernet0/0/13 GigabitEthernet0/0/14 GigabitEthernet0/0/15 GigabitEthernet0/0/16 GigabitEthernet0/0/17 GigabitEthernet0/0/18 GigabitEthernet0/0/19 GigabitEthernet0/0/2 GigabitEthernet0/0/20 GigabitEthernet0/0/21 GigabitEthernet0/0/22 GigabitEthernet0/0/23 GigabitEthernet0/0/24 GigabitEthernet0/0/25 GigabitEthernet0/0/26 GigabitEthernet0/0/27 GigabitEthernet0/0/28 GigabitEthernet0/0/29 GigabitEthernet0/0/3 GigabitEthernet0/0/30 GigabitEthernet0/0/31 GigabitEthernet0/0/32 GigabitEthernet0/0/33 GigabitEthernet0/0/34 GigabitEthernet0/0/35 GigabitEthernet0/0/36 GigabitEthernet0/0/37 GigabitEthernet0/0/38 GigabitEthernet0/0/39 GigabitEthernet0/0/4 GigabitEthernet0/0/40 GigabitEthernet0/0/41 GigabitEthernet0/0/42 GigabitEthernet0/0/43 GigabitEthernet0/0/44 GigabitEthernet0/0/45 GigabitEthernet0/0/46 GigabitEthernet0/0/47 GigabitEthernet0/0/48 GigabitEthernet0/0/5 GigabitEthernet0/0/6 GigabitEthernet0/0/7 GigabitEthernet0/0/8 ``` <!-- If filing a bug, please record the exact steps taken to reproduce the bug and any errors messages that are generated. If filing a feature request, please precisely describe the data model or workflow you would like to see implemented, and provide a use case. -->
adam added the type: bug label 2025-12-29 16:26:26 +01:00
adam closed this issue 2025-12-29 16:26:26 +01:00
adam commented 2025-12-29 16:26:27 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 17, 2017):

The issue here is that interfaces are retrieved via API 2.0 irrespective of their parent device(s); for example, /api/dcim/interfaces/?device_id=123 instead of /api/dcim/devices/123/interfaces/. Thus, the ordering logic needs to be passed explicitly.

One option is to glean the ordering logic from the filter if a device has been specified. However, this is messy because a) we need to manually process the GET query parameter in the API view and b) multiple devices can be specified (potentially with different ordering logic).

Another option would be to introduce a query parameter to explicitly state the ordering logic. For example, /api/dcim/interfaces/?device_id=123&ordering=name. This is a cleaner approach, however it requires significantly reworking the Javascript used by the web UI to populate hierarchical selections via the API. I believe this is the better approach.

A third option would be to replicate the legacy API endpoint as an alternative to the current one, but I strongly oppose this option as it introduces redundancy in the API (since the same data can be retrieved via either endpoint).

@jeremystretch commented on GitHub (Apr 17, 2017): The issue here is that interfaces are retrieved via API 2.0 irrespective of their parent device(s); for example, `/api/dcim/interfaces/?device_id=123` instead of `/api/dcim/devices/123/interfaces/`. Thus, the ordering logic needs to be passed explicitly. One option is to glean the ordering logic from the filter if a device has been specified. However, this is messy because a) we need to manually process the GET query parameter in the API view and b) multiple devices can be specified (potentially with different ordering logic). Another option would be to introduce a query parameter to explicitly state the ordering logic. For example, `/api/dcim/interfaces/?device_id=123&ordering=name`. This is a cleaner approach, however it requires significantly reworking the Javascript used by the web UI to populate hierarchical selections via the API. I believe this is the better approach. A third option would be to replicate the legacy API endpoint as an alternative to the current one, but I strongly oppose this option as it introduces redundancy in the API (since the same data can be retrieved via either endpoint).
adam commented 2025-12-29 16:26:27 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 14, 2017):

Fixed in cd263484c3. Because we're limiting the device filter for components to a single device, this change is being deferred until v2.1.0.

One option is to glean the ordering logic from the filter if a device has been specified. However, this is messy because a) we need to manually process the GET query parameter in the API view and b) multiple devices can be specified (potentially with different ordering logic).

Turns out it was possible to do this within the filter itself, which makes for a fairly clean fix.

@jeremystretch commented on GitHub (Jun 14, 2017): Fixed in cd263484c351bdd09fe36b56ff05e820eb03fa03. Because we're limiting the device filter for components to a single device, this change is being deferred until v2.1.0. > One option is to glean the ordering logic from the filter if a device has been specified. However, this is messy because a) we need to manually process the GET query parameter in the API view and b) multiple devices can be specified (potentially with different ordering logic). Turns out it was possible to do this within the filter itself, which makes for a fairly clean fix.
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#862
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?