feat(orchestrator-form-react): allow conditional omitFromWorkflowInput

[lokanandaprabhu]

User description

Hey, I just made a Pull Request!

Fixes:

https://issues.redhat.com/browse/RHDHBUGS-2590

Summary:

• allow omitFromWorkflowInput to accept conditional expressions (same format as ui:hidden)
• evaluate conditions against current form data when building the execution payload

---

---

✔️ Checklist

• A changeset describing the change and affected packages. (more info)
• Added or Updated documentation
• Tests for new functionality and regression tests for bug fixes
• Screenshots attached (for UI changes)

---

PR Type

Enhancement

---

Description

• Allow omitFromWorkflowInput to accept conditional expressions

• Support same condition format as ui:hidden for dynamic field omission

• Evaluate conditions against form data during payload building

• Add comprehensive tests and documentation for feature

---

Diagram Walkthrough

flowchart LR
  A["omitFromWorkflowInput property"] --> B["Boolean or Condition object"]
  B --> C["evaluateHiddenCondition"]
  C --> D["Evaluate against rootFormData"]
  D --> E["Omit field from payload"]

Loading

File Walkthrough

	Relevant files
Enhancement	pruneFormData.ts Support conditional omitFromWorkflowInput with expression evaluation workspaces/orchestrator/plugins/orchestrator-form-react/src/utils/pruneFormData.ts Changed omitFromWorkflowInput type from boolean to HiddenCondition to support conditional expressions Updated shouldOmitFromWorkflowInput function to evaluate conditions using evaluateHiddenCondition Added rootFormData parameter to omitFromWorkflowInput function for condition evaluation Propagated rootFormData through recursive calls for nested objects and arrays +22/-5
Tests	pruneFormData.test.ts Add tests for conditional omitFromWorkflowInput behavior  workspaces/orchestrator/plugins/orchestrator-form-react/src/utils/pruneFormData.test.ts Added test for removing properties when conditional omitFromWorkflowInput matches Added test for keeping properties when conditional omitFromWorkflowInput does not match Tests verify condition evaluation against form data using when/is pattern +51/-0
Documentation	omit-from-workflow-input-conditions.md Add changeset for conditional omitFromWorkflowInput feature workspaces/orchestrator/.changeset/omit-from-workflow-input-conditions.md Created changeset documenting the new conditional omitFromWorkflowInput feature Marked as patch version change for orchestrator-form-react plugin Describes support for expression format matching ui:hidden +6/-0      orchestratorFormWidgets.md Document omitFromWorkflowInput static and conditional usage workspaces/orchestrator/docs/orchestratorFormWidgets.md Added new section documenting omitFromWorkflowInput functionality Provided examples for static boolean and conditional expression formats Documented supported condition patterns matching ui:hidden syntax Clarified difference between omitting from payload vs hiding in UI +41/-0

---

[rhdh-gh-app]

Changed Packages

Package Name	Package Path	Changeset Bump	Current Version
@red-hat-developer-hub/backstage-plugin-orchestrator-form-react	workspaces/orchestrator/plugins/orchestrator-form-react	patch	v2.5.1

[rhdh-qodo-merge]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
🟢	No codebase code duplication found New Components Detected: - it: should remove properties when omitFromWorkflowInput condition matches - it: should keep properties when omitFromWorkflowInput condition does not match
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
⚪	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Condition eval failures: The new conditional omitFromWorkflowInput path calls evaluateHiddenCondition(omitFlag, rootFormData) without visible try/catch or fallback, so invalid/malformed conditions may throw and break payload building rather than degrading gracefully. Referred Code function shouldOmitFromWorkflowInput( schema: JSONSchema7, rootFormData: JsonObject, ): boolean { const omitFlag = (schema as WorkflowInputSchema).omitFromWorkflowInput; if (omitFlag === undefined) { return false; } if (typeof omitFlag === 'boolean') { return omitFlag; } return evaluateHiddenCondition(omitFlag, rootFormData); } Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Untrusted condition evaluation: The PR enables evaluating schema-provided omitFromWorkflowInput conditions against rootFormData, which requires verification that evaluateHiddenCondition safely handles untrusted condition objects (no prototype pollution/path traversal style access) and validates condition structure before evaluation. Referred Code import { HiddenCondition } from '../types/HiddenCondition'; import { evaluateHiddenCondition } from './evaluateHiddenCondition'; type WorkflowInputSchema = JSONSchema7 & { omitFromWorkflowInput?: HiddenCondition; }; /** * Resolves $ref references in a schema by looking in $defs */ function resolveSchema( schema: JSONSchema7, rootSchema: JSONSchema7, ): JSONSchema7 { if (!schema.$ref) return schema; // Handle #/$defs/name references const refPath = schema.$ref; if (refPath.startsWith('#/$defs/')) { const defName = refPath.replace('#/$defs/', ''); const resolved = rootSchema.$defs?.[defName]; ... (clipped 21 lines) Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rhdh-qodo-merge]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Permit boolean or condition types Update the WorkflowInputSchema type to explicitly allow boolean in addition to HiddenCondition for the omitFromWorkflowInput property. workspaces/orchestrator/plugins/orchestrator-form-react/src/utils/pruneFormData.ts [24-26] type WorkflowInputSchema = JSONSchema7 & { - omitFromWorkflowInput?: HiddenCondition; + omitFromWorkflowInput?: boolean | HiddenCondition; }; Apply / Chat Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies that the type for omitFromWorkflowInput should explicitly include boolean for better type safety and clarity, which is handled correctly by the implementation but not reflected in the type definition.	Medium
More

[mareklibra]

So many small sneaky conditions :-O
But it makes sense.

[lokanandaprabhu]

/cherrypick orchestrator-1.8

[openshift-cherrypick-robot]

@lokanandaprabhu: new pull request created: #2288

Details

In response to this:

/cherrypick orchestrator-1.8

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.