search

netbox-community / netbox

The premier source of truth powering network automation. Open source under Apache 2. Try NetBox Cloud free: https://netboxlabs.com/free-netbox-cloud/
http://netboxlabs.com/oss/netbox/
Apache License 2.0
16.03k stars 2.57k forks source link

Optional check for cable label uniqueness and validation #3163

Closed larsweiler closed 5 years ago

larsweiler commented 5 years ago

Environment

Proposed Functionality

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

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.

jeremystretch commented 5 years ago

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.