Add support for interface roles #4066

New Issue

adam · 2025-12-29T18:32:56+01:00

adam commented

2025-12-29 18:32:56 +01:00

Originally created by @marinbernard-pep06 on GitHub (Sep 3, 2020).

Environment

Python version: 3.6.9
NetBox version: 2.9.2

Proposed Functionality

NetBox already offers a way to assign roles to devices, vLANs and prefixes. I propose to add support for interface and port roles.

This FR is a duplicate of #2997, which never made it as it was decided that roles could be assigned by leveraging the tags subsystem. Since the feature is really central to us, and probably to others, I've humbly decided to create a duplicate FR in the hope of finding a decent solution.

While using tags for role assignments is quite possible, if feels like a last resort solution to me for 2 reasons:

Device, vLAN and prefix roles were implemented as distinct models in NetBox. If the need for interface/port roles is acknowledged, shouldn't this feature be built the same way, at least for the sake of consistency ?
While #3703 eases the use of namespaced tags for role assignments, there's currently no way to make such assignments mandatory. As a consequence, creating roleless ports and interfaces remains possible. In some environments, such as ours, port and interface roles are mandatory, and NetBox is unable to enforce this requirement. A dedicated field would at least allow to query the list of ports/interfaces with a blank role, something which can't be easily done with tags.

Use Case

In our environment, we use roles to normalize the configuration of our interfaces (cable color, vLANs config, PoE policy...) and ports (cable color, use-case...). Roles are currently set in the description field. Having a dedicated field, either native of custom, would make role management less error-prone.

Note that another way to deal with our requirements would be to create a mandatory custom field with a closed set of options. Unfortunately, NetBox does not support adding custom fields to ports and interfaces. If enabling the use of custom fields with ports and interfaces is preferable, it would be fine too.

Database Changes

Create a new model to represent port/interface roles. A single model for both types of roles (like for vlan/prefix roles) seems preferable, as port and interface roles are likely to overlap each other in the real world.
Extend the port and interface models by adding a many-to-one relation to the port/interface role model.

External Dependencies

None

Originally created by @marinbernard-pep06 on GitHub (Sep 3, 2020). ### Environment * Python version: 3.6.9 * NetBox version: 2.9.2 ### Proposed Functionality NetBox already offers a way to assign roles to devices, vLANs and prefixes. I propose to add support for interface and port roles. This FR is a duplicate of #2997, which never made it as it was decided that roles could be assigned by leveraging the tags subsystem. Since the feature is really central to us, and probably to others, I've humbly decided to create a duplicate FR in the hope of finding a decent solution. While using tags for role assignments is quite possible, if feels like a last resort solution to me for 2 reasons: 1. Device, vLAN and prefix roles were implemented as distinct models in NetBox. If the need for interface/port roles is acknowledged, shouldn't this feature be built the same way, at least for the sake of consistency ? 2. While #3703 eases the use of namespaced tags for role assignments, there's currently no way to make such assignments mandatory. As a consequence, creating roleless ports and interfaces remains possible. In some environments, such as ours, port and interface roles are mandatory, and NetBox is unable to enforce this requirement. A dedicated field would at least allow to query the list of ports/interfaces with a blank role, something which can't be easily done with tags. ### Use Case In our environment, we use roles to normalize the configuration of our interfaces (cable color, vLANs config, PoE policy...) and ports (cable color, use-case...). Roles are currently set in the description field. Having a dedicated field, either native of custom, would make role management less error-prone. Note that another way to deal with our requirements would be to create a mandatory custom field with a closed set of options. Unfortunately, NetBox does not support adding custom fields to ports and interfaces. If enabling the use of custom fields with ports and interfaces is preferable, it would be fine too. ### Database Changes - Create a new model to represent port/interface roles. A single model for both types of roles (like for vlan/prefix roles) seems preferable, as port and interface roles are likely to overlap each other in the real world. - Extend the port and interface models by adding a many-to-one relation to the port/interface role model. ### External Dependencies None

adam added the status: duplicate label 2025-12-29 18:32:56 +01:00

adam closed this issue

2025-12-29 18:32:57 +01:00

adam commented

2025-12-29 18:32:57 +01:00

@jeremystretch commented on GitHub (Sep 3, 2020):

I've humbly decided to create a duplicate FR in the hope of finding a decent solution.

And in violation of the contributing policy.

#2997 was not rejected because no solution could be found. It was rejected because the proposed functionality 1) is largely redundant to the tags feature, and 2) makes naive assumptions about general use cases, namely that a user would only need one value for one role on an interface.

If you need this functionality, you have three options:

Use tags.
Wait for custom fields to be added to the interface model (sometime during or after #4847).
Fork the project and implement it on your own.

Locking this issue has the discussion here and in #2997 has run its course.

@jeremystretch commented on GitHub (Sep 3, 2020): > I've humbly decided to create a duplicate FR in the hope of finding a decent solution. And in violation of the [contributing policy](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md). #2997 was not rejected because no solution could be found. It was rejected because the proposed functionality 1) is largely redundant to the tags feature, and 2) makes naive assumptions about general use cases, namely that a user would only need one value for one role on an interface. If you need this functionality, you have three options: 1) Use tags. 2) Wait for custom fields to be added to the interface model (sometime during or after #4847). 3) Fork the project and implement it on your own. Locking this issue has the discussion here and in #2997 has run its course.

adam referenced this issue

2025-12-29 22:23:24 +01:00

[PR #4066] [CLOSED] Fixes: #3016 - Add wrapper for post_save and post_delete signals #12746

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#4066