Feat/added additional validators for custom command arguments

[Benni0]

PR Type

What kind of change does this PR introduce?

• Feature
• Bug Fix
• Refactoring (no functional or API changes)
• Documentation Update
• Maintenance (dependency updates, CI, etc.)

Summary

Adds support for the argument validators Set, Match, List, Map and Duration for custom commands.
Please review Pull Request #1977 first.

Changes

Updated the schema.json to support the new argument validators with their required properties. Also changed the python command generator to generate the appropriate code.

User experience

After this update the user has more possibilities to validate and parse custom command arguments:

• Set: allows the user to specify a list of valid argument values.
• Match: allows the user to specify a regex pattern to validate the argument value.
• List: allows the user to validate list argument values, which are parsed and passed as list.
• Map: allows the user to specify a dictionary which automatically translates argument values.
• Duration: allows the user to validate duration and timstamp argument values.

Checklist

If an item doesn't apply to your changes, leave it unchecked.

Review

• self-review - I have performed a self-review of this change according to the development guidelines
• Changes are documented. The documentation is understandable, examples work (more info)
• PR title and description follows the contributing principles
• meeting - I have scheduled a meeting or recorded a demo to explain these changes (if there is a video, put a link below and in the ticket)

Tests

See the testing doc.

• Unit - tests have been added/modified to cover the changes
• Smoke - tests have been added/modified to cover the changes
• UI - tests have been added/modified to cover the changes
• coverage - I have checked the code coverage of my changes (see more)

Demo/meeting:

Reviewers are encouraged to request meetings or demos if any part of the change is unclear

[kkedziak-splunk]

Review Summary

This PR adds support for additional splunklib validators: Set, Match, List, Map, and Duration. The schema definitions, Python code generation, and test coverage are comprehensive.

Issues found:

1. Match validator name not required in schema (schema.json): The CustomMatchValidator schema only requires ["type", "pattern"] but not "name". However the Python code generation uses validate.get("name") and embeds it directly in validators.Match('{name}', '{pattern}'). If name is None, this generates validators.Match('None', '...') — a string literal 'None', not the Python None. The name field should either be required in the schema, or the code generation should handle the missing case.

2. Potential code injection in generated Python (create_custom_command_python.py): The Match validator generates validate=validators.Match('{name}', '{pattern}') using f-strings with user-provided values. If a pattern contains a single quote (e.g. ^[a-z]+'s$), it would break the generated Python syntax. Similarly for the name field. The values should be properly escaped or use repr() for safe string embedding.

3. Set validator code generation uses str() + strip('[]'): str(allowed_values).strip('[]') works for simple strings but could produce unexpected output if values contain special characters (e.g. commas, quotes). Using ', '.join(repr(v) for v in allowed_values) would be more robust.

4. Map validator code generation uses str(option_map): f"validate=validators.Map(**{str(option_map)})" relies on Python's str() representation of a dict matching valid Python syntax. This works for simple types but is fragile. Consider using repr() instead.

5. Double period in schema description (schema.json, CustomMapValidator): Description says "...which is replaced by the value.." — double period at the end.

6. Doc says "some types" instead of a count (custom_search_commands.md): Changed from "five types" to "some types" — consider listing the actual count (10 types) or saying "the following types".

Good work adding comprehensive validator support with thorough tests.

[kkedziak-splunk]

The CustomMatchValidator only requires ["type", "pattern"] but not "name". However the Python code generation in create_custom_command_python.py uses validate.get("name") and directly embeds it as validators.Match('{name}', ...). If name is omitted, this generates Match('None', ...) with a literal string 'None'. Either make name required here, or handle the None case in code generation.

[kkedziak-splunk]

Potential code injection / syntax breakage: if pattern contains a single quote (e.g. ^[a-z]+'s$), the generated Python code validators.Match('{name}', '{pattern}') will have broken syntax. Consider using repr(name) and repr(pattern) instead of manual quoting:

validate_str = f", validate=validators.Match({repr(name)}, {repr(pattern)})"

[kkedziak-splunk]

str(allowed_values).strip('[]') is fragile — if values contain commas or quotes, the output could be malformed. Consider:

vals = ', '.join(repr(v) for v in allowed_values)
validate_str = f", validate=validators.Set({vals})"

[kkedziak-splunk]

str(option_map) relies on Python's dict __repr__ matching valid Python syntax. This works for simple types but is fragile for edge cases. Consider using repr(option_map) for safer code generation.