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

Ports must be created with a Type -- what type do we use if it's not on the list? #4332

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

Originally created by @Infiniverse on GitHub (Dec 4, 2020).

Environment

  • NetBox version: v2.9.9

Steps to Reproduce

  1. Create a port/interface
  2. Try and leave the type blank

Expected Behavior

I expected to be able to create an untyped port, but I couldn't.

When I don't know what kind of port we have (is it APC or UPC? Is it LC or SC?) I cannot create a device-type.
Sometimes we want to document even if we don't know what the specifics are yet. It would be useful to introduce an 'Unknown' type to facilitate this.

Originally created by @Infiniverse on GitHub (Dec 4, 2020). ### Environment * NetBox version: v2.9.9 ### Steps to Reproduce 1. Create a port/interface 2. Try and leave the type blank ### Expected Behavior I expected to be able to create an untyped port, but I couldn't. When I don't know what kind of port we have (is it APC or UPC? Is it LC or SC?) I cannot create a device-type. Sometimes we want to document even if we don't know what the specifics are yet. It would be useful to introduce an 'Unknown' type to facilitate this.
adam closed this issue 2025-12-29 18:34:50 +01:00
adam commented 2025-12-29 18:34:50 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 4, 2020):

This is expected behavior: The type field is a required field for the model.

When I don't know what kind of port we have (is it APC or UPC? Is it LC or SC?) I cannot create a device-type.

This is by design. A device type is intended to be a complete representation of a physical device. In cases where interfaces are modular and may vary among instances (for example, modular patch panels), they should not be added to the device type. Instead, they should be populated as needed on individual devices. (Components can be added to many devices in bulk through the NetBox UI.)

@jeremystretch commented on GitHub (Dec 4, 2020): This is expected behavior: The `type` field is a required field for the model. > When I don't know what kind of port we have (is it APC or UPC? Is it LC or SC?) I cannot create a device-type. This is by design. A device type is intended to be a complete representation of a physical device. In cases where interfaces are modular and may vary among instances (for example, modular patch panels), they should not be added to the device type. Instead, they should be populated as needed on individual devices. (Components can be added to many devices in bulk through the NetBox UI.)
adam commented 2025-12-29 18:34:51 +01:00
Author
Owner
Copy Link

@Infiniverse commented on GitHub (Dec 5, 2020):

I understand this from a purity perspective. But doesn't it mean that we cannot document our network formally until you've added any missing types? For example, we are on v2.9.9 which doesn't have a 'splice' type yet (which is coming in v2.10) - how would you recommend we document our splice ports? - there is no way of creating a port without a specific type, and all of the types are wrong which means that our documentation isn't correct.

@Infiniverse commented on GitHub (Dec 5, 2020): I understand this from a purity perspective. But doesn't it mean that we cannot document our network formally until you've added any missing types? For example, we are on v2.9.9 which doesn't have a 'splice' type yet (which is coming in v2.10) - how would you recommend we document our splice ports? - there is no way of creating a port without a specific type, and all of the types are wrong which means that our documentation isn't correct.
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
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#4332
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?