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

Optionally link Circuit Types to Circuit Providers #6915

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

Originally created by @pgnuta on GitHub (Aug 30, 2022).

NetBox version

v3.3.1

Feature type

Change to existing functionality

Proposed functionality

Add an optional, multi-select, Circuit Provider selection field to the Circuit Type add/edit forms. The reasoning behind this is that some circuit types may only be provided by a couple of Circuit Providers and thus it makes no sense for those Circuit Types to clutter up the Circuit Type selection field in the Circuit add/edit form. Selection of a Circuit Provider is already mandatory on the Circuit add/edit form and can be used to refresh the contents of the Circuit Type selection.

A one-to-many link would need to be added to the CircuitType model, linking to Provider model. A multi-select "Provider" field would be needed to be added to the Circuit Type add/edit form with instructions to 'leave it blank for all'.

The Circuit Type selection on the Circuit add/edit form would need to be changed to refresh when the "Provider" is changed. It should be changed to contain Circuit Types where the Provider matches the selection or where the Circuit Type specifies no Providers. In this way backwards compatibility is maintained.

Use case

In the case of many Circuit Types existing, some provided by only a few Providers, it makes sense to allow the user to view a limited subset of Circuit Types when creating/editing a Circuit based on their selection of the Circuit Provider.

Database changes

A one-to-many link would need to be added to the CircuitType model, linking to Provider model.

External dependencies

None

Originally created by @pgnuta on GitHub (Aug 30, 2022). ### NetBox version v3.3.1 ### Feature type Change to existing functionality ### Proposed functionality Add an optional, multi-select, Circuit Provider selection field to the Circuit Type add/edit forms. The reasoning behind this is that some circuit types may only be provided by a couple of Circuit Providers and thus it makes no sense for those Circuit Types to clutter up the Circuit Type selection field in the Circuit add/edit form. Selection of a Circuit Provider is already mandatory on the Circuit add/edit form and can be used to refresh the contents of the Circuit Type selection. A one-to-many link would need to be added to the CircuitType model, linking to Provider model. A multi-select "Provider" field would be needed to be added to the Circuit Type add/edit form with instructions to 'leave it blank for all'. The Circuit Type selection on the Circuit add/edit form would need to be changed to refresh when the "Provider" is changed. It should be changed to contain Circuit Types where the Provider matches the selection or where the Circuit Type specifies no Providers. In this way backwards compatibility is maintained. ### Use case In the case of many Circuit Types existing, some provided by only a few Providers, it makes sense to allow the user to view a limited subset of Circuit Types when creating/editing a Circuit based on their selection of the Circuit Provider. ### Database changes A one-to-many link would need to be added to the CircuitType model, linking to Provider model. ### External dependencies None
adam added the type: featurepending closurestatus: under review labels 2025-12-29 19:46:37 +01:00
adam closed this issue 2025-12-29 19:46:37 +01:00
adam commented 2025-12-29 19:46:38 +01:00
Author
Owner
Copy Link

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

Slack conversation on the topic (while its there)

@jsenecal commented on GitHub (Aug 31, 2022): [Slack conversation on the topic](https://netdev-community.slack.com/archives/C01P0FRSXRV/p1661890508334439) (while its there)
adam commented 2025-12-29 19:46:38 +01:00
Author
Owner
Copy Link

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

IMO this seems excessive.

In the case of many Circuit Types existing, some provided by only a few Providers, it makes sense to allow the user to view a limited subset of Circuit Types when creating/editing a Circuit based on their selection of the Circuit Provider.

How many circuit types have you defined? I suspect you may be misusing this model for something other than its intended purpose. A circuit type should be pretty general in nature; common examples would be things like:

  • Internet access
  • Backup
  • MPLS/VPN
  • Site-to-site

The reasoning behind this is that some circuit types may only be provided by a couple of Circuit Providers

Here you've gotten into a different topic entirely: validation. It is already possible to restrict circuit type according to provider using custom validation, if that's what you need.

@jeremystretch commented on GitHub (Aug 31, 2022): IMO this seems excessive. > In the case of many Circuit Types existing, some provided by only a few Providers, it makes sense to allow the user to view a limited subset of Circuit Types when creating/editing a Circuit based on their selection of the Circuit Provider. How many circuit types have you defined? I suspect you may be misusing this model for something other than its intended purpose. A circuit type should be pretty general in nature; common examples would be things like: * Internet access * Backup * MPLS/VPN * Site-to-site > The reasoning behind this is that some circuit types may only be provided by a couple of Circuit Providers Here you've gotten into a different topic entirely: validation. It is already possible to restrict circuit type according to provider using [custom validation](https://docs.netbox.dev/en/stable/customization/custom-validation/), if that's what you need.
adam commented 2025-12-29 19:46:38 +01:00
Author
Owner
Copy Link

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

Here we have some vendor specific variants of existing technologies, Such as "Equinix Fabric" or "Cologix MetroConnect" which, you guessed it, are Equinixes and Cologixes services respectively.

You may also be defining Variants of EPLs depending on the Underlay or topology, or even use trademarks in there.

@jsenecal commented on GitHub (Aug 31, 2022): Here we have some vendor specific variants of existing technologies, Such as "Equinix Fabric" or "Cologix MetroConnect" which, you guessed it, are Equinixes and Cologixes services respectively. You may also be defining Variants of EPLs depending on the Underlay or topology, or even use trademarks in there.
adam commented 2025-12-29 19:46:39 +01:00
Author
Owner
Copy Link

@pgnuta commented on GitHub (Sep 1, 2022):

Putting everything aside this really is just a quality of life improvement proposal to limit the list of circuit types by selection of the provider. Whether or not we're using it wrong and have too many circuit types defined, i think, is beside the point of this FR. I'm not talking about validation, i know that that can be done with custom validation, i'm talking about a better user experience.

That being said... Our particular use-case is that we define one circuit type per GPON profile that we purchase from our vendor. This is so that we can define various things about those profiles, which are important to us, within custom fields on the circuit type. We're not talking about hundreds of profiles but certainly between 10-15 per provider. If the circuit type dropdown on the circuit add/edit form only displayed the circuit types that are provided by the selected provider, or all providers, to the user then it would be a better user experience.

@pgnuta commented on GitHub (Sep 1, 2022): Putting everything aside this really is just a quality of life improvement proposal to limit the list of circuit types by selection of the provider. Whether or not we're using it wrong and have too many circuit types defined, i think, is beside the point of this FR. I'm not talking about validation, i know that that can be done with custom validation, i'm talking about a better user experience. That being said... Our particular use-case is that we define one circuit type per GPON profile that we purchase from our vendor. This is so that we can define various things about those profiles, which are important to us, within custom fields on the circuit type. We're not talking about hundreds of profiles but certainly between 10-15 per provider. If the circuit type dropdown on the circuit add/edit form only displayed the circuit types that are provided by the selected provider, or all providers, to the user then it would be a better user experience.
adam commented 2025-12-29 19:46:39 +01:00
Author
Owner
Copy Link

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

Whether or not we're using it wrong and have too many circuit types defined, i think, is beside the point of this FR

Every feature request for NetBox must include a convincing use case to justify its implementation. If it can be shown that the cited use case results from incorrectly using existing features or models, or that it can be satisfied through alternative means, this proves the change unnecessary. This is a key part of how we manage to keep NetBox maintainable and functional long-term.

Our particular use-case is that we define one circuit type per GPON profile that we purchase from our vendor.

And this is a good example: It seems that you've repurposed the circuit type field for another function. Instead, you can use the circuit type relationship to identify only the circuit's type (e.g. "GPON"), and to add a custom field to the circuit model indicating which profile applies. This decouples the circuit's type from the subclassification of a particular profile.

@jeremystretch commented on GitHub (Sep 2, 2022): > Whether or not we're using it wrong and have too many circuit types defined, i think, is beside the point of this FR Every feature request for NetBox _must_ include a convincing use case to justify its implementation. If it can be shown that the cited use case results from incorrectly using existing features or models, or that it can be satisfied through alternative means, this proves the change unnecessary. This is a key part of how we manage to keep NetBox maintainable and functional long-term. > Our particular use-case is that we define one circuit type per GPON profile that we purchase from our vendor. And this is a good example: It seems that you've repurposed the circuit type field for another function. Instead, you can use the circuit type relationship to identify only the circuit's type (e.g. "GPON"), and to add a custom field to the circuit model indicating which profile applies. This decouples the circuit's type from the subclassification of a particular profile.
adam commented 2025-12-29 19:46:40 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Nov 2, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Nov 2, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:46:40 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Dec 3, 2022):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Dec 3, 2022): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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 pending closure status: under review 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#6915
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?