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

Add cable type 'other' when connecting interfaces #6887

New Issue
Closed
opened 2025-12-29 19:46:21 +01:00 by adam · 14 comments
adam commented 2025-12-29 19:46:21 +01:00
Owner
Copy Link

Originally created by @ghost on GitHub (Aug 27, 2022).

NetBox version

v3.3.0

Feature type

Change to existing functionality

Proposed functionality

When connecting 2 interfaces together (A side, B side) you select the cable type from a drop down list.
There are quite a few different types of cables, but sometimes the cable you're using doesn't fall into the available options.
When creating interfaces, you get tons of options in the drop down, GPON, CFP2, SFP, Copper, Serial, etc.
But cables don't seem to have as many options.

This specific feature request I am requesting a cable type 'Other' in the drop down list so at least if your cable doesn't fit into the existing list you have some option rather than just leaving it blank.
I'd also like to request cable type "Stacking" if possible. If not, then 'Other' will at least get us somewhat there.

Use case

When connecting interfaces together, sometimes the cable you're using doesn't fit the currently available options. It would be nice to have an option for 'Other' in those use cases.

Database changes

None.

External dependencies

None.

Originally created by @ghost on GitHub (Aug 27, 2022). ### NetBox version v3.3.0 ### Feature type Change to existing functionality ### Proposed functionality When connecting 2 interfaces together (A side, B side) you select the cable type from a drop down list. There are quite a few different types of cables, but sometimes the cable you're using doesn't fall into the available options. When creating interfaces, you get tons of options in the drop down, GPON, CFP2, SFP, Copper, Serial, etc. But cables don't seem to have as many options. This specific feature request I am requesting a cable type 'Other' in the drop down list so at least if your cable doesn't fit into the existing list you have some option rather than just leaving it blank. I'd also like to request cable type "Stacking" if possible. If not, then 'Other' will at least get us somewhat there. ### Use case When connecting interfaces together, sometimes the cable you're using doesn't fit the currently available options. It would be nice to have an option for 'Other' in those use cases. ### Database changes None. ### External dependencies None.
adam added the type: feature label 2025-12-29 19:46:21 +01:00
adam closed this issue 2025-12-29 19:46:21 +01:00
adam commented 2025-12-29 19:46:21 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 29, 2022):

This specific feature request I am requesting a cable type 'Other' in the drop down list so at least if your cable doesn't fit into the existing list you have some option rather than just leaving it blank.

Why not just leave it blank? Both would signify an unknown value.

@jeremystretch commented on GitHub (Aug 29, 2022): > This specific feature request I am requesting a cable type 'Other' in the drop down list so at least if your cable doesn't fit into the existing list you have some option rather than just leaving it blank. Why not just leave it blank? Both would signify an unknown value.
adam commented 2025-12-29 19:46:22 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Aug 30, 2022):

because there is a programmatic difference between 'true/false' and 'null'.
Leaving the cable type blank could indicate someone forgot to specify the cable type.
Setting the value to type other shows anyone who looks at the value that it was specifically set. It just so happens to be some kind of cable that isn't available within the choices.

You could ask your same question for any other drop down field within NetBox that has some kind of 'other' catch all.

@ghost commented on GitHub (Aug 30, 2022): because there is a programmatic difference between 'true/false' and 'null'. Leaving the cable type blank could indicate someone forgot to specify the cable type. Setting the value to type other shows anyone who looks at the value that it was specifically set. It just so happens to be some kind of cable that isn't available within the choices. You could ask your same question for any other drop down field within NetBox that has some kind of 'other' catch all.
adam commented 2025-12-29 19:46:22 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 30, 2022):

It just so happens to be some kind of cable that isn't available within the choices.

But if you know what the type is, and it doesn't exist in NetBox, why not ask that the type be added?

You could ask your same question for any other drop down field within NetBox that has some kind of 'other' catch all.

Those fields are mandatory; leaving it blank is not an option, so "other" was added as a catch-all.

@jeremystretch commented on GitHub (Aug 30, 2022): > It just so happens to be some kind of cable that isn't available within the choices. But if you know what the type is, and it doesn't exist in NetBox, why not ask that the type be added? > You could ask your same question for any other drop down field within NetBox that has some kind of 'other' catch all. Those fields are mandatory; leaving it blank is not an option, so "other" was added as a catch-all.
adam commented 2025-12-29 19:46:22 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Aug 31, 2022):

Well, I sort of did. I asked for 'Stacking' as an option. Since the cable in question is a proprietary stacking cable for Aruba switches. But it would still be good to have 'other' so someone can at least continue in their NetBox deployment without having to wait however many months it might take to get a feature request pushed through to add cable type 'xyz' into the product.

@ghost commented on GitHub (Aug 31, 2022): Well, I sort of did. I asked for 'Stacking' as an option. Since the cable in question is a proprietary stacking cable for Aruba switches. But it would still be good to have 'other' so someone can at least continue in their NetBox deployment without having to wait however many months it might take to get a feature request pushed through to add cable type 'xyz' into the product.
adam commented 2025-12-29 19:46:23 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 31, 2022):

But it would still be good to have 'other' so someone can at least continue in their NetBox deployment without having to wait however many months it might take to get a feature request pushed through to add cable type 'xyz' into the product.

Again, the type field is optional, so this doesn't block anything.

@jeremystretch commented on GitHub (Aug 31, 2022): > But it would still be good to have 'other' so someone can at least continue in their NetBox deployment without having to wait however many months it might take to get a feature request pushed through to add cable type 'xyz' into the product. Again, the `type` field is optional, so this doesn't block anything.
adam commented 2025-12-29 19:46:23 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Aug 31, 2022):

I mean, I'm not sure what else to say. Does every user have to use NetBox the way you think it should be used?
I submitted the request, it sounds like you don't agree/understand it's purpose. That's fine. I'm not sure what else I can do.
This specific request is relatively low effort, if you point me to the file where these options are stored I'll work on contributing the code changes.

@ghost commented on GitHub (Aug 31, 2022): I mean, I'm not sure what else to say. Does every user have to use NetBox the way you think it should be used? I submitted the request, it sounds like you don't agree/understand it's purpose. That's fine. I'm not sure what else I can do. This specific request is relatively low effort, if you point me to the file where these options are stored I'll work on contributing the code changes.
adam commented 2025-12-29 19:46:23 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 31, 2022):

Does every user have to use NetBox the way you think it should be used?

Of course not, and that's the beauty of open source: You always have the freedom to modify it to fit your needs---and to be responsible for those changes indefinitely. For my part, I develop NetBox in accordance with what I think are the best choices to ensure its long-term viability, which unfortunately aren't always appreciated by end users with very little reason to consider use cases beyond their own.

This specific request is relatively low effort

If effort was a driving factor in whether or not to make a change, I would have given up on this project years ago.

@jeremystretch commented on GitHub (Aug 31, 2022): > Does every user have to use NetBox the way you think it should be used? Of course not, and that's the beauty of open source: You always have the freedom to modify it to fit your needs---and to be responsible for those changes indefinitely. For my part, I develop NetBox in accordance with what I think are the best choices to ensure its long-term viability, which unfortunately aren't always appreciated by end users with very little reason to consider use cases beyond their own. > This specific request is relatively low effort If effort was a driving factor in whether or not to make a change, I would have given up on this project years ago.
adam commented 2025-12-29 19:46:23 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Aug 31, 2022):

My comment about low effort is not attempting to disparage your work. I meant, since it's a pretty straight forward change a layman like myself could likely figure out how to quickly just add 1 more option to a drop down list if I could be pointed to the right area where the code for this resides.

@ghost commented on GitHub (Aug 31, 2022): My comment about low effort is not attempting to disparage your work. I meant, since it's a pretty straight forward change a layman like myself could likely figure out how to quickly just add 1 more option to a drop down list if I could be pointed to the right area where the code for this resides.
adam commented 2025-12-29 19:46:23 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Aug 31, 2022):

if you point me to the file where these options are stored I'll work on contributing the code changes.

if I could be pointed to the right area where the code for this resides.

301ebe0da3/netbox/dcim/choices.py (L1221)

But as Jeremy said you will have to maintain your own fork unless this issue gets accepted.

@kkthxbye-code commented on GitHub (Aug 31, 2022): > if you point me to the file where these options are stored I'll work on contributing the code changes. > if I could be pointed to the right area where the code for this resides. https://github.com/netbox-community/netbox/blob/301ebe0da3145d822ba1b96c3cbcce0ad59dec89/netbox/dcim/choices.py#L1221 But as Jeremy said you will have to maintain your own fork unless this issue gets accepted.
adam commented 2025-12-29 19:46:23 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Aug 31, 2022):

I guess I'm just waiting on this FR to be approved then.

@ghost commented on GitHub (Aug 31, 2022): I guess I'm just waiting on this FR to be approved then.
adam commented 2025-12-29 19:46:24 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Sep 6, 2022):

For Aruba, it is a type of DAC, using a proprietary form factor (I think), so I would say for the cable type, you choose "DAC", this is what I would do for Cisco for something like a stackwise stack as well.

@DanSheps commented on GitHub (Sep 6, 2022): For Aruba, it is a type of DAC, using a proprietary form factor (I think), so I would say for the cable type, you choose "DAC", this is what I would do for Cisco for something like a stackwise stack as well.
adam commented 2025-12-29 19:46:24 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Sep 12, 2022):

So, still waiting for this to be accepted.

@ghost commented on GitHub (Sep 12, 2022): So, still waiting for this to be accepted.
adam commented 2025-12-29 19:46:24 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 15, 2022):

As I've stated above, there's no reason to add an "other" type for cables. However, you are free to do this in your own fork if you disagree.

@jeremystretch commented on GitHub (Sep 15, 2022): As I've stated above, there's no reason to add an "other" type for cables. However, you are free to do this in your own fork if you disagree.
adam commented 2025-12-29 19:46:24 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Sep 22, 2022):

There is a reason. It's what I outlined above in the feature request.
Just because you don't agree with it doesn't mean there isn't one.

@ghost commented on GitHub (Sep 22, 2022): There is a reason. It's what I outlined above in the feature request. Just because you don't agree with it doesn't mean there isn't one.
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: feature
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#6887
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?