-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Introduce excludeValues as a complement to allowedValues #1792
Copy link
Copy link
Labels
priority: p2Moderately-important priority. Fix may not be included in next release.Moderately-important priority. Fix may not be included in next release.status: help wantedStatus: Unplanned work open to contributions from the community.Status: Unplanned work open to contributions from the community.type: feature request‘Nice-to-have’ improvement, new feature or different behavior or design.‘Nice-to-have’ improvement, new feature or different behavior or design.
Metadata
Metadata
Assignees
Labels
priority: p2Moderately-important priority. Fix may not be included in next release.Moderately-important priority. Fix may not be included in next release.status: help wantedStatus: Unplanned work open to contributions from the community.Status: Unplanned work open to contributions from the community.type: feature request‘Nice-to-have’ improvement, new feature or different behavior or design.‘Nice-to-have’ improvement, new feature or different behavior or design.
Type
Fields
Give feedbackNo fields configured for Feature.
Prerequisites
What are you trying to do that currently feels hard or impossible?
The current library provides an allowedValues list, which is perfect for "allow-listing" defining a small, finite set of values that are acceptable for a parameter.
However, there is no simple way to support "deny-listing" defining a small set of values that are unacceptable, while allowing all other values of that type.
Use Case: I have two common scenarios that are currently difficult to implement:
I want to define a parameter that accepts any integer except 12345.
I want to define a user parameter that accepts any username except 'admin' or 'root'.
Current allowedValues (Impossible): For the integer case, I would have to list every other integer [...12344, 12346, ...], which is infinite and not possible.
Current regex (Difficult/Fragile): This is the only workaround but this requires a negative lookahead, which is not supported (e.g.,
^(?!12345$)\d+$)or^(?!(admin|root)$).*$).This limitation makes it difficult to implement common validation rules.
Suggested Solution(s)
I propose introducing a new excludeValues parameter. This parameter would be a list of items that are explicitly forbidden.
To make this feature powerful and flexible, an item in the excludeValues list could be either a literal value OR a regex string.
Alternatives Considered
No response
Additional Details
No response