Add Filter & Field Validation in reports_workflow_manager

[Kandarimegha]

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

Description

This PR fixes two validation bugs in the reports_workflow_manager module where invalid filter names and invalid field values were accepted by the module and passed to the API without triggering any errors.
These issues caused the module to execute successfully even with malformed report configurations, leading to silent failures and incorrect report creation.
This change ensures consistent validation behavior across all templates and enforces strict schema compliance before any API call is made.

Bug Fixes Included
This update resolves critical validation gaps where invalid filter names and invalid field group fields were silently accepted, resulting in incorrect report creation without any error feedback.

Root Cause
The filter validation logic did not enforce:
Presence of required filters per template
Correct filter types
Detection of unknown filters
Field validation logic did not validate:
Expected fieldGroupName per template
Required field names
Extra/invalid field names

This incomplete schema validation allowed malformed report definitions to pass through undetected.

Fix Implemented
A unified validation framework has been introduced across all templates:
Filter Validation Enhancements
Added strict enforcement of required filters.
Validation now checks:
Missing filters
Incorrect filter types
Unknown/unexpected filters
Upon validation failure, the module now correctly returns error msg.
ensuring the Ansible task fails instead of succeeding silently.

Field Group Validation Enhancements
Added template-specific validation for:
Correct fieldGroupName
Required field names
Detection of invalid/unknown field names
Invalid field groups now result in an explicit failure.

Testing Done:

• [] Manual testing
• [] Unit tests
• [] Integration tests

Test cases covered: [Mention test case IDs or brief points]

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• All the sanity checks have been completed and the sanity test cases have been executed

Ansible Best Practices

• Tasks are idempotent (can be run multiple times without changing state)
• Variables and secrets are handled securely (e.g., using ansible-vault or environment variables)
• Playbooks are modular and reusable
• Handlers are used for actions that need to run on change

Documentation

• All options and parameters are documented clearly.
• Examples are provided and tested.
• Notes and limitations are clearly stated.

Screenshots (if applicable)

Notes to Reviewers