Device Role Category or Custom Field #3399

New Issue

adam · 2025-12-29T18:28:44+01:00

adam commented

2025-12-29 18:28:44 +01:00

Originally created by @ryanmerolle on GitHub (Feb 24, 2020).

Environment

NA Feature Request

Proposed Functionality

It would be useful to either setup a Device Category hierarchy to Device Roles so we can group Network, Datacenter, Server/Compute, Storage and other Device Categories to Device Roles. If this is not an easy feature request, then allowed custom fields to be added to Device Roles would also work.

Use Case

With netbox set as my infra source of truth, I am using it to provide our business application monitoring tools context about our infra in order to enrich alerting. The device roles are super useful, but it would be nice to have one more level to group these roles into categories. The only other way is to apply these categories to the device types via custom categories which is a level lower than we would want to. Example: All compute leafs should be listed as network devices and all PDUs should be listed as power or datacenter devices. To do this on each model of a device labeled as a PDU device role does not seem logical.

Database Changes

External Dependencies

Update objects int he hierarchy to show their device category where the device role is also showed. Not as important as long as we can query the API for this linkage.

Originally created by @ryanmerolle on GitHub (Feb 24, 2020). ### Environment NA Feature Request ### Proposed Functionality It would be useful to either setup a Device Category hierarchy to Device Roles so we can group Network, Datacenter, Server/Compute, Storage and other Device Categories to Device Roles. If this is not an easy feature request, then allowed custom fields to be added to Device Roles would also work. ### Use Case With netbox set as my infra source of truth, I am using it to provide our business application monitoring tools context about our infra in order to enrich alerting. The device roles are super useful, but it would be nice to have one more level to group these roles into categories. The only other way is to apply these categories to the device types via custom categories which is a level lower than we would want to. Example: All compute leafs should be listed as network devices and all PDUs should be listed as power or datacenter devices. To do this on each model of a device labeled as a PDU device role does not seem logical. ### Database Changes ### External Dependencies Update objects int he hierarchy to show their device category where the device role is also showed. Not as important as long as we can query the API for this linkage.

adam added the pending closure label 2025-12-29 18:28:44 +01:00

adam closed this issue

2025-12-29 18:28:44 +01:00

adam commented

2025-12-29 18:28:44 +01:00

@jeremystretch commented on GitHub (Feb 25, 2020):

Example: All compute leafs should be listed as network devices and all PDUs should be listed as power or datacenter devices.

It sounds like you're trying to encode additional information into a field with a set context. A hierarchy likely isn't the best way, as you will inevitably come across a situation where devices of the same functional role need to be grouped differently for some reason.

You have a few options:

Introduce a custom field on the device model to be used in parallel to role assignment
Use tags to a similar effect
Store the mapping of roles to grouping in the system that's consuming this information (though you still risk running into the limitations of using a hierarchy)

@jeremystretch commented on GitHub (Feb 25, 2020): > Example: All compute leafs should be listed as network devices and all PDUs should be listed as power or datacenter devices. It sounds like you're trying to encode additional information into a field with a set context. A hierarchy likely isn't the best way, as you will inevitably come across a situation where devices of the same functional role need to be grouped differently for some reason. You have a few options: 1. Introduce a custom field on the device model to be used in parallel to role assignment 2. Use tags to a similar effect 3. Store the mapping of roles to grouping in the system that's consuming this information (though you still risk running into the limitations of using a hierarchy)

adam commented

2025-12-29 18:28:44 +01:00

@ryanmerolle commented on GitHub (Feb 27, 2020):

@jeremystretch I agree with your assessment of my current options, I was thinking the same thing. My only hesitations:

I can ensure user input in the data model by restricting to a custom field with a drop down of predefined options. I cannot ensure the user selects the correct one unless I create a report that keeps track of device role association to these custom categories and audit for discrepancies in netbox reporting.
Tags are free form and harder to ensure data quality.
This would require all systems that consume this information to keep this mapping. I have this need for my tooling that is wider infra focused, so requiring tooling I do not necessarily own to keep this mapping is less than ideal.

The hierarchical inheritance/group of device role -> device type -> device makes sense to me. I just assumed either level above it in the model would be make sense or the adjusting the model to allow device role to have custom fields. That way, no user or workflow would set a device category during creation, it would just be set for them when they selected the device role.

One additional option would be to scrap my current device roles. The roles are quite useful for me with future automation, but the reality is that if I make them more high level for the downstream systems to filter by, then that solves the problem. It just eliminates more granular data I could use for configuration generation or other workflows in my specific network focus.

@ryanmerolle commented on GitHub (Feb 27, 2020): @jeremystretch I agree with your assessment of my current options, I was thinking the same thing. My only hesitations: 1. I can ensure user input in the data model by restricting to a custom field with a drop down of predefined options. I cannot ensure the user selects the correct one unless I create a report that keeps track of device role association to these custom categories and audit for discrepancies in netbox reporting. 2. Tags are free form and harder to ensure data quality. 3. This would require all systems that consume this information to keep this mapping. I have this need for my tooling that is wider infra focused, so requiring tooling I do not necessarily own to keep this mapping is less than ideal. The hierarchical inheritance/group of device role -> device type -> device makes sense to me. I just assumed either level above it in the model would be make sense or the adjusting the model to allow device role to have custom fields. That way, no user or workflow would set a device category during creation, it would just be set for them when they selected the device role. One additional option would be to scrap my current device roles. The roles are quite useful for me with future automation, but the reality is that if I make them more high level for the downstream systems to filter by, then that solves the problem. It just eliminates more granular data I could use for configuration generation or other workflows in my specific network focus.

adam commented

2025-12-29 18:28:45 +01:00

@stale[bot] commented on GitHub (Mar 12, 2020):

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. Please see our contributing guide.

@stale[bot] commented on GitHub (Mar 12, 2020): 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. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

2025-12-29 18:28:45 +01:00

@stale[bot] commented on GitHub (Mar 19, 2020):

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.

@stale[bot] commented on GitHub (Mar 19, 2020): 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.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#3399