Regex validation for JSON custom fields

[AndMrzv]

NetBox version

v3.1.10

Feature type

New functionality

Proposed functionality

Regex validation for custom fields of JSON type with regex set in the "Validation" block of custom field settings.

When I try it now it says "Regular expression validation is supported only for text and URL fields".

Use case

Json fields are very nice to have, I've been converting to them all json data previously stored in Netbox as text strings for external systems and scripts to parse exactly as it was meant in #7452
I was hoping that with json type users will now be unable to put something non-json in such fields (this kills whatever is dependent on proper data format) but you can actually put anything in a json field as long as you frame it with quotes so it could be regarded as string and not checked for being a proper json.

A very simple regex demanding field's value to be framed with curly braces would be enough to counter this (yes, user can see an error message and put a single string inside of braces but at least this would require him to think twice drastically reducing mistakes).

Even better if I have very specific data in the field, let's say I use something like
{"numeric_parameter1": 123; "numeric_parameter2": 456, "codeword": "this"}
for racks, I could compose a regex allowing changing only values and according to my rules (i.e. [0-9]{1-4}, can't be negative, etc) providing superb data integrity with unseen ease of use.

Yes, I can solve this with extra custom validators but using a native already existing feature would be cool.

Database changes

No response

External dependencies

No response

[jeremystretch]

It sounds like you're falling into the trap of wanting to use regular expressions to validate arbitrary data structures. Frankly, it's just never a good idea.

Yes, I can solve this with extra custom validators but using a native already existing feature would be cool.

It sounds cool until you're tasked with modifying a 200-character blob of regex which tries to validate a JSON object. A custom validator is going to work much better for this in pretty much every regard.

[sleepinggenius2]

What about instead of regex, an option is added to specify a JSON Schema for validation? I know that is something I was playing around with implementing as part of a custom validator, but seems like it could be useful to implement natively.

[AndMrzv]

It sounds like you're falling into the trap of wanting to use regular expressions to validate arbitrary data structures. Frankly, it's just never a good idea.

Yes, I can solve this with extra custom validators but using a native already existing feature would be cool.

It sounds cool until you're tasked with modifying a 200-character blob of regex which tries to validate a JSON object. A custom validator is going to work much better for this in pretty much every regard.

Okay, I can see the logic here. Though for me personally it is much more convenient and fast to work on 200-character regex everybody can see and be done with it rather than edit the my-validator.py, submit it, wait weeks for it's code to be reviewed and rolled into production and so on, I get that this process may be different for others.

Originally I didn't even need schema, simply not letting users to put a quoted string into a json field would be good enough.
Coming up with the validator.

[AndMrzv]

Oh, soon I will be able to hide json fields from people or make them RO with #8560 and #9166 leaving only scripts which are never wrong to populate them.

[github-actions]

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. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

[github-actions]

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.