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

Introduce "Connector Types" under "Device Components" to allow additional power connector types #7202

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

Originally created by @ypid on GitHub (Nov 4, 2022).

NetBox version

v3.3.7

Feature type

Data model extension

Proposed functionality

Introduce a new data model ConnectorType that allows users to define additional connector types. The naming is kept generic so that the ConnectorType could be used in all models that define ports (like PowerPort), PowerOutlet and Interface but this proposal is only about the power domain.

  • Model(s): Supported options: PowerOutlet, PowerOutletTemplate, PowerPort, PowerPortTemplate
  • Name
  • Slug or ID: Not sure yet what is best. What happens when you export device types with user defined connector types?
  • Group name (optional): Description that will show up in the form: Either a predefined group name like "DC" (see Power Ports) or a group that is not used by NetBox to organize in a new group..
  • Image/drawing (later): #8323

This proposal supersedes/closes the following alternatives:

Terminology: The term "custom" should be avoided in the context of this proposal. "Custom" is used differently in NetBox. The term "additional" is preferred as it expresses the different mindset behind the ConnectorType model that extends predefined/hardcoded ConnectorType that NetBox ships with. This proposal introduces the term "connector" to keep it generic, as mentioned above.

A word about Interface: While I would have use cases for additional Interface types, I am not sure that this is common enough or even wanted in NetBox. If an interface type is common enough, it should be added to NetBox directly. So I don’t propose other connector types here but I am open to be convinced other.

Use case

Issues raised in the past have shown that users have connector types that are either too unusual or legacy to be added to NetBox directly. It allows to accurately model power connections with all the benefits NetBox users know and love like being able to search, validate data with Reports. It will also integrate nicely with the planned feature #8323.

Database changes

Yes.

External dependencies

No.

Originally created by @ypid on GitHub (Nov 4, 2022). ### NetBox version v3.3.7 ### Feature type Data model extension ### Proposed functionality Introduce a new data model `ConnectorType` that allows users to define additional connector types. The naming is kept generic so that the `ConnectorType` could be used in all models that define ports (like `PowerPort`), `PowerOutlet` and `Interface` but this proposal is only about the power domain. * Model(s): Supported options: `PowerOutlet`, `PowerOutletTemplate`, `PowerPort`, `PowerPortTemplate` * Name * Slug or ID: Not sure yet what is best. What happens when you export device types with user defined connector types? * Group name (optional): Description that will show up in the form: `Either a predefined group name like "DC" (see Power Ports) or a group that is not used by NetBox to organize in a new group.`. * Image/drawing (later): #8323 This proposal supersedes/closes the following alternatives: * https://github.com/netbox-community/netbox/issues/10546 Terminology: The term "custom" should be avoided in the context of this proposal. "Custom" is used differently in NetBox. The term "additional" is preferred as it expresses the different mindset behind the `ConnectorType` model that extends predefined/hardcoded `ConnectorType` that NetBox ships with. This proposal introduces the term "connector" to keep it generic, as mentioned above. A word about `Interface`: While I would have use cases for additional `Interface` types, I am not sure that this is common enough or even wanted in NetBox. If an interface type is common enough, it should be added to NetBox directly. So I don’t propose other connector types here but I am open to be convinced other. ### Use case Issues raised in the past have shown that users have connector types that are either too unusual or legacy to be added to NetBox directly. It allows to accurately model power connections with all the benefits NetBox users know and love like being able to search, validate data with Reports. It will also integrate nicely with the planned feature #8323. ### Database changes Yes. ### External dependencies No.
adam added the type: featurestatus: duplicate labels 2025-12-29 20:20:24 +01:00
adam closed this issue 2025-12-29 20:20:25 +01:00
adam commented 2025-12-29 20:20:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 4, 2022):

Similar proposals have previously been raised and rejected. You can find them here on GitHub by searching closed issues. Please also see this FAQ explaining why NetBox does not permit users to invent custom connector types.

Issues raised in the past have shown that users have connector types that are either too unusual or legacy to be added to NetBox directly.

If there's a valid reason to add new types that will benefit a substantial portion of the user base, we'll happily do so. You're welcome to reopen #10546.

@jeremystretch commented on GitHub (Nov 4, 2022): Similar proposals have previously been raised and rejected. You can find them here on GitHub by searching closed issues. Please also see [this FAQ](https://github.com/netbox-community/netbox/wiki/Frequently-Asked-Questions#how-can-i-add-new-interface-types) explaining why NetBox does not permit users to invent custom connector types. > Issues raised in the past have shown that users have connector types that are either too unusual or legacy to be added to NetBox directly. If there's a valid reason to add new types that will benefit a substantial portion of the user base, we'll happily do so. You're welcome to reopen #10546.
adam commented 2025-12-29 20:20:26 +01:00
Author
Owner
Copy Link

@ypid commented on GitHub (Nov 4, 2022):

I get your point and why you reject this proposal. Without having checked, I would assume the plugin API cannot extend power port types. Feel free to correct me if I am wrong.

You're welcome to reopen #10546.

Done that.

  1. Representing each type as a database object would impose a substantial performance penalty.

I don’t think this counts (anymore). NetBox (by now) has all the caching infrastructure to deal with this if it were a real problem. Maybe you can remove this argument from the FAQ?

  1. Allowing custom types would make the device library much more difficult, if not impossible, to use.

Not impossible but it needs to be considered. Using the slug as I already proposed can work, then the type could be prefixed for export (e. g. https://github.com/netbox-community/devicetype-library/) so that it is clear that this is an additional connector type.

@ypid commented on GitHub (Nov 4, 2022): I get your point and why you reject this proposal. Without having checked, I would assume the plugin API cannot extend power port types. Feel free to correct me if I am wrong. > You're welcome to reopen #10546. Done that. > 3. Representing each type as a database object would impose a substantial performance penalty. I don’t think this counts (anymore). NetBox (by now) has all the caching infrastructure to deal with this if it were a real problem. Maybe you can remove this argument from the FAQ? > 4. Allowing custom types would make the device library much more difficult, if not impossible, to use. Not impossible but it needs to be considered. Using the slug as I already proposed can work, then the type could be prefixed for export (e. g. https://github.com/netbox-community/devicetype-library/) so that it is clear that this is an additional connector type.
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 status: duplicate 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#7202
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?