Optional check for cable label uniqueness and validation #2595

New Issue

adam · 2025-12-29T18:20:14+01:00

adam commented

2025-12-29 18:20:14 +01:00

Originally created by @larsweiler on GitHub (May 7, 2019).

Environment

Python version: 3.7.3
NetBox version: 2.6-beta1

Proposed Functionality

This enhancement adds the option for two things on cable labels:

Check for (global) uniqueness of the cable label
Validate the label against a given regular expression

The changes apply on the model validation, so that no model changes are needed. Also, the options are configurable in the configuration file and don't apply by default. There are no changes for existing installations.

With the boolean setting LABEL_UNIQUE one can switch on the global uniqueness lookup for a label prior to a database write.

With the boolean setting LABEL_VALIDATION one can optionally add a LABEL_VALIDATION_REGEX which will validate the content of the label against a set of characters or even if it matches a special style given in the regular expression. The default is '^[ 0-9a-zA-Z#-.]*$' which works with all labels used in the tests.

Use Case

As mentioned in #2746:

Cabling labels are entirely arbitrary and every organization uses whatever system works for them.

I wanted to create an optional feature to fulfil some of the requirements. A NetBox administrator can enable the (global) check of uniqueness of a cable label. Or validate the label against a given regular expression. Or enable both.

My primary intention is, that the user should be able to have the cable label checked during creation or change instead of using a validation report later on.

If none of the options are enabled, the usual behaviour for no uniqueness or label validation apply.

Database Changes

None.

The checks are done in the model's clean() function and not on a database layer in order to stay with the current model.

External Dependencies

None.

Originally created by @larsweiler on GitHub (May 7, 2019). ### Environment * Python version: 3.7.3 * NetBox version: 2.6-beta1 ### Proposed Functionality This enhancement adds the option for two things on cable labels: * Check for (global) uniqueness of the cable label * Validate the label against a given regular expression The changes apply on the model validation, so that no model changes are needed. Also, the options are configurable in the configuration file and don't apply by default. There are no changes for existing installations. With the boolean setting `LABEL_UNIQUE` one can switch on the global uniqueness lookup for a label prior to a database write. With the boolean setting `LABEL_VALIDATION` one can optionally add a `LABEL_VALIDATION_REGEX` which will validate the content of the label against a set of characters or even if it matches a special style given in the regular expression. The default is `'^[ 0-9a-zA-Z#-.]*$'` which works with all labels used in the tests. ### Use Case As mentioned in #2746: > Cabling labels are entirely arbitrary and every organization uses whatever system works for them. I wanted to create an optional feature to fulfil some of the requirements. A NetBox administrator can enable the (global) check of uniqueness of a cable label. Or validate the label against a given regular expression. Or enable both. My primary intention is, that the user should be able to have the cable label checked during creation or change instead of using a validation report later on. If none of the options are enabled, the usual behaviour for no uniqueness or label validation apply. ### Database Changes None. The checks are done in the model's `clean()` function and not on a database layer in order to stay with the current model. ### External Dependencies None.

adam closed this issue

2025-12-29 18:20:14 +01:00

adam commented

2025-12-29 18:20:14 +01:00

@jeremystretch commented on GitHub (May 7, 2019):

I'd rather not extend scope to include label validation. As quoted, labeling schemes are arbitrary and organization-specific. Some are globally unique, some only per site or per tenant, some are not unique. Introducing support for one scheme only opens the door for further iteration on an ancillary feature.

If this is something a user really needs to validate, reports are available to address this as you mentioned.

@jeremystretch commented on GitHub (May 7, 2019): I'd rather not extend scope to include label validation. As quoted, labeling schemes are arbitrary and organization-specific. Some are globally unique, some only per site or per tenant, some are not unique. Introducing support for one scheme only opens the door for further iteration on an ancillary feature. If this is something a user really needs to validate, reports are available to address this as you mentioned.

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