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 a filter for Device-Type in the Device Components searches #7009

New Issue
Closed
opened 2025-12-29 19:47:50 +01:00 by adam · 3 comments
adam commented 2025-12-29 19:47:50 +01:00
Owner
Copy Link

Originally created by @martinum4 on GitHub (Sep 21, 2022).

NetBox version

v3.3.2

Feature type

Change to existing functionality

Proposed functionality

A filter for device types would greatly improve the search and bulk edit of data.

Use case

After Changes in the NetBox Data Model (in this case the addition of PoE) it can be necessary to bulk-edit existing objects.

Device-Types usually share the same nomenclature across multiple types and vendors (e.g. Slot/Module/Port for switches, Power Ports…).
Selecting the right objects to mass-edit can be greatly amplified by being able to select all ports of a specific device type, e.g. to mark them as PSE or PD.

Database changes

All required datasets are already contained within NetBox.

External dependencies

Probably none.

Originally created by @martinum4 on GitHub (Sep 21, 2022). ### NetBox version v3.3.2 ### Feature type Change to existing functionality ### Proposed functionality A filter for device types would greatly improve the search and bulk edit of data. ### Use case After Changes in the NetBox Data Model (in this case the addition of PoE) it can be necessary to bulk-edit existing objects. Device-Types usually share the same nomenclature across multiple types and vendors (e.g. Slot/Module/Port for switches, Power Ports…). Selecting the right objects to mass-edit can be greatly amplified by being able to select all ports of a specific device type, e.g. to mark them as PSE or PD. ### Database changes All required datasets are already contained within NetBox. ### External dependencies Probably none.
adam added the type: featuretopic: UI/UX labels 2025-12-29 19:47:50 +01:00
adam closed this issue 2025-12-29 19:47:50 +01:00
adam commented 2025-12-29 19:47:51 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Sep 23, 2022):

If I understand your request properly, it is not possible. The device components (like the Interface model) are not the same as the templates (InterfaceTemplate in this case). So while InterfaceTemplates have a direct relationship to a DeviceType or ModuleType, Interfaces do not.

You could select the current DeviceType from the parent interface, but I really don't see how it makes sense from a datamodel perspective, as you can change the devicetype of a device after creation. What DeviceType does the device components "belong" to then?

I get the need from a usability standpoint, I just don't see a good way to implement it without it being confusing.

Please correct me if I misunderstood what you are suggesting.

@kkthxbye-code commented on GitHub (Sep 23, 2022): If I understand your request properly, it is not possible. The device components (like the Interface model) are not the same as the templates (InterfaceTemplate in this case). So while InterfaceTemplates have a direct relationship to a DeviceType or ModuleType, Interfaces do not. You could select the **current** DeviceType from the parent interface, but I really don't see how it makes sense from a datamodel perspective, as you can change the devicetype of a device after creation. What DeviceType does the device components "belong" to then? I get the need from a usability standpoint, I just don't see a good way to implement it without it being confusing. Please correct me if I misunderstood what you are suggesting.
adam commented 2025-12-29 19:47:51 +01:00
Author
Owner
Copy Link

@martinum4 commented on GitHub (Sep 26, 2022):

Yes, it would be an indirect relationship.

I think for the most usecases described here the current DeviceType is just fine.

Personally i don't really find it confusing, if you know the limitations (DeviceType can be changed after Device creation, only instanced at creation, etc.).

I think you got me right and i see your concerns.

@martinum4 commented on GitHub (Sep 26, 2022): Yes, it would be an indirect relationship. I think for the most usecases described here the current DeviceType is just fine. Personally i don't really find it confusing, if you know the limitations (DeviceType can be changed after Device creation, only instanced at creation, etc.). I think you got me right and i see your concerns.
adam commented 2025-12-29 19:47:52 +01:00
Author
Owner
Copy Link

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

Closing this out as the proposal does not seem to be feasible.

@jeremystretch commented on GitHub (Sep 28, 2022): Closing this out as the proposal does not seem to be feasible.
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 topic: UI/UX 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#7009
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?