feat(orchestrator): expose RJSF widget config to templates

[upendhran]

Hey, I just made a Pull Request!

Expose orchestrator.rjsf-widgets as frontend configuration so workflow form templates can access public string values through rjsfConfig.<key>

• Add the frontend visible configuration schema.
• Add evaluator test coverage for rjsfConfig
• Document configuration and usage and warn that values are public and must not contain secrets

Example Usage

orchestrator:
  rjsf-widgets:
    defaultEnvironment: production

• The form widget evaluator already resolves rjsfConfig.<key>. However, this namespace was not declared as frontend visible in the Backstage config schema, so its values were filtered out before reaching the frontend

✔️ 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)

[rhdh-gh-app]

Changed Packages

Package Name	Package Path	Changeset Bump	Current Version
@red-hat-developer-hub/backstage-plugin-orchestrator-common	workspaces/orchestrator/plugins/orchestrator-common	patch	v3.8.0

[rhdh-qodo-merge]

PR Summary by Qodo

Expose orchestrator.rjsf-widgets config to RJSF template evaluation

✨ Enhancement 🧪 Tests 📝 Documentation ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Expose a dedicated, frontend-visible orchestrator.rjsf-widgets config namespace to templates via
 rjsfConfig..
• Add config schema typing/visibility annotations and document that values are public (no secrets).
• Add evaluator test coverage to ensure rjsfConfig.* reads the expected config key.

Diagram

graph TD
  T["Workflow template"] --> E(["Template unit evaluator"]) --> A(["Backstage ConfigApi"]) --> C[("orchestrator.rjsf-widgets")]
  S["orchestrator-common config.d.ts"] --> A

  subgraph Legend
    direction LR
    _tmpl["Template"] ~~~ _svc(["Runtime component"]) ~~~ _cfg[("Config namespace")]
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Explicit allow-list of exposed keys

• ➕ Stronger security posture; prevents accidental exposure of unexpected keys
• ➕ Better type safety and discoverability for template authors
• ➖ Less flexible; every new key requires a code+release change
• ➖ More maintenance and coordination between template authors and plugin releases

2. Expose a structured object (e.g., orchestrator.rjsfWidgetsConfig) instead of a free-form map

• ➕ Allows nested config with clearer namespacing and potential schema validation
• ➕ Can evolve toward richer per-widget configuration without string-only constraints
• ➖ More complexity in config schema and evaluator logic
• ➖ Potentially larger public surface area unless tightly controlled

Recommendation: The chosen approach (a dedicated orchestrator.rjsf-widgets namespace marked frontend-visible) is a good balance of flexibility and safety because it avoids exposing broader Backstage/plugin config. If the set of keys grows and security concerns increase, consider moving to an explicit allow-list to prevent accidental publication of sensitive values.

Files changed (4) +35 / -0

Enhancement (1) +8 / -0

config.d.tsDefine frontend-visible rjsf-widgets config schema (string map) +8/-0

Define frontend-visible rjsf-widgets config schema (string map)

• Extends the orchestrator config schema with an optional 'rjsf-widgets' string-keyed map. Marks the namespace with '@deepVisibility frontend' and documents that values are public and must not contain secrets.

workspaces/orchestrator/plugins/orchestrator-common/config.d.ts

Tests (1) +11 / -0

useTemplateUnitEvaluator.test.tsxAdd test coverage for rjsfConfig.* template evaluation +11/-0

Add test coverage for rjsfConfig.* template evaluation

• Adds a unit test asserting that 'rjsfConfig.defaultEnvironment' resolves via 'configApi.getOptionalString('orchestrator.rjsf-widgets.defaultEnvironment')'. Ensures the evaluator’s rjsfConfig path stays wired to the intended public config namespace.

workspaces/orchestrator/plugins/orchestrator-form-widgets/src/utils/useTemplateUnitEvaluator.test.tsx

Documentation (1) +10 / -0

orchestratorFormWidgets.mdDocument rjsfConfig mapping to orchestrator.rjsf-widgets (public) +10/-0

Document rjsfConfig mapping to orchestrator.rjsf-widgets (public)

• Documents how 'rjsfConfig.<key>' is configured under 'orchestrator.rjsf-widgets' with an example YAML snippet. Adds an explicit warning that all values in this namespace are exposed to the frontend and must not contain secrets.

workspaces/orchestrator/docs/orchestratorFormWidgets.md

Other (1) +6 / -0

public-rjsf-widget-config.mdAdd changeset for public rjsf-widgets config exposure +6/-0

Add changeset for public rjsf-widgets config exposure

• Adds a patch changeset for the orchestrator common and form-widgets packages. Documents that the new 'orchestrator.rjsf-widgets' namespace is publicly readable by workflow templates and must not contain secrets.

workspaces/orchestrator/.changeset/public-rjsf-widget-config.md

[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]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 🔗 Cross-repo conflicts (1) 📜 Skill insights (0)

Context used

✅ Compliance rules (platform): 11 rules

✅ Cross-repo context

  Explored: repo: redhat-developer/rhdh-operator (sha: 3df5f74e)

  Explored: repo: redhat-developer/rhdh-local (sha: 2ae9e8c8)

  Explored: repo: redhat-developer/rhdh (sha: e431ad4e)

  Not relevant to this PR: redhat-developer/rhdh-chart

1. Frontend config schema drift 🔗 Cross-repo conflict ≡ Correctness

Description

RHDH’s backend dynamic plugin loader relies on each installed dynamic plugin’s
dist*/configSchema.json to determine config schema/visibility, but this PR adds `@deepVisibility
frontend for orchestrator.rjsf-widgets only in orchestrator-common`. Since RHDH
Operator/rhdh-local enable Orchestrator as four dynamic plugins, verify that the generated
configSchema.json shipped with those plugins includes orchestrator.rjsf-widgets, otherwise
rjsfConfig.* reads may be stripped from frontend config and resolve as undefined.

Code

workspaces/orchestrator/plugins/orchestrator-common/config.d.ts[R86-93]

+    /**
+     * Public string values available to form widget templates through `rjsfConfig.<key>`.
+     * Do not store secrets in this configuration because workflow authors can access every value.
+     * @deepVisibility frontend
+     */
+    'rjsf-widgets'?: {
+      [key: string]: string;
+    };

Relevance

●●● Strong

Team previously fixed dynamic-plugin config schema issues by splitting schemas and wiring
package.json configSchema (PR#2212); similar concern raised in PR#2512.

PR-#2212
PR-#2512

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR introduces a new frontend-visible orchestrator.rjsf-widgets schema in
orchestrator-common, while the template evaluator reads orchestrator.rjsf-widgets.* from
frontend config. In RHDH, dynamic plugins supply configSchema.json for schema/visibility; Operator
and rhdh-local enable Orchestrator as four dynamic plugins, so the schema must be present in those
dynamic plugins’ generated configSchema.json for the frontend to receive the values.

workspaces/orchestrator/plugins/orchestrator-common/config.d.ts[86-93]
workspaces/orchestrator/plugins/orchestrator-common/package.json[13-42]
workspaces/orchestrator/plugins/orchestrator-form-widgets/src/utils/useTemplateUnitEvaluator.ts[224-227]
External repo: redhat-developer/rhdh, packages/backend/src/index.ts [41-51]
External repo: redhat-developer/rhdh-operator, docs/orchestrator.md [69-76]
External repo: redhat-developer/rhdh-operator, config/profile/rhdh/default-config/flavours/orchestrator/dynamic-plugins.yaml [2-17]
External repo: redhat-developer/rhdh-local, orchestrator/configs/dynamic-plugins/dynamic-plugins.yaml [2-21]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
RHDH loads dynamic-plugin config schemas from each installed plugin’s `dist*/configSchema.json` and uses that schema/visibility to decide what config is exposed to the frontend. This PR adds `orchestrator.rjsf-widgets` as `@deepVisibility frontend` in `orchestrator-common`, and the form-widgets evaluator reads `orchestrator.rjsf-widgets.*` via `configApi`.

If the dynamic-plugin build/export pipeline (and/or the specific Orchestrator dynamic plugin packages shipped/installed by Operator and rhdh-local) does **not** embed the `orchestrator-common` schema into the installed plugins’ `configSchema.json`, then `orchestrator.rjsf-widgets.*` may not be present in the frontend-visible config and `rjsfConfig.*` template units will return `undefined` in real RHDH deployments.

## Issue Context
- Operator/rhdh-local enable Orchestrator as four dynamic plugins (no explicit `orchestrator-common` dynamic plugin entry).
- RHDH backend dynamic plugin loader locates per-plugin `configSchema.json`.

## Fix Focus Areas
- workspaces/orchestrator/plugins/orchestrator-common/config.d.ts[86-93]
- workspaces/orchestrator/plugins/orchestrator-common/package.json[13-42]
- workspaces/orchestrator/plugins/orchestrator-form-widgets/src/utils/useTemplateUnitEvaluator.ts[224-227]

## Suggested fix approaches
Choose one (in order of preference):
1) **Validate packaging/export:** Confirm that the Orchestrator dynamic plugin build/export process produces `configSchema.json` for the installed Orchestrator dynamic plugins that already contains the `orchestrator.rjsf-widgets` schema from `orchestrator-common`. If not, adjust the export pipeline to include `orchestrator-common`’s `configSchema` contributions.
2) **Make schema explicit in an installed plugin package:** Add the `orchestrator.rjsf-widgets` schema (with `@deepVisibility frontend`) to a package that is definitely shipped as a dynamic plugin in Operator/rhdh-local (e.g., Orchestrator frontend/back), ensuring its `configSchema.json` includes the new key.
3) **If required, coordinate downstream:** If neither packaging nor schema relocation is feasible, update downstream deployment docs/config (Operator/rhdh-local) to ensure the schema-providing package is installed in the dynamic plugins set.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 58.05%. Comparing base (5093b6b) to head (804993a).
⚠️ Report is 6 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4130   +/-   ##
=======================================
  Coverage   58.05%   58.05%           
=======================================
  Files        2409     2409           
  Lines       96354    96354           
  Branches    26808    26831   +23     
=======================================
+ Hits        55937    55938    +1     
+ Misses      38953    38949    -4     
- Partials     1464     1467    +3     

Flag	Coverage Δ		*Carryforward flag
adoption-insights	84.55% <ø> (ø)		Carriedforward from 5093b6b
ai-integrations	69.71% <ø> (ø)		Carriedforward from 5093b6b
app-defaults	69.79% <ø> (ø)		Carriedforward from 5093b6b
augment	46.67% <ø> (ø)		Carriedforward from 5093b6b
boost	76.77% <ø> (ø)		Carriedforward from 5093b6b
bulk-import	72.56% <ø> (ø)		Carriedforward from 5093b6b
cost-management	13.55% <ø> (ø)		Carriedforward from 5093b6b
dcm	60.72% <ø> (ø)		Carriedforward from 5093b6b
extensions	56.59% <ø> (ø)		Carriedforward from 5093b6b
global-floating-action-button	71.18% <ø> (ø)		Carriedforward from 5093b6b
global-header	66.50% <ø> (ø)		Carriedforward from 5093b6b
homepage	47.50% <ø> (ø)		Carriedforward from 5093b6b
install-dynamic-plugins	59.95% <ø> (ø)		Carriedforward from 5093b6b
intelligent-assistant	74.61% <ø> (ø)		Carriedforward from 5093b6b
konflux	91.98% <ø> (ø)		Carriedforward from 5093b6b
lightspeed	69.02% <ø> (ø)		Carriedforward from 5093b6b
mcp-integrations	83.40% <ø> (ø)		Carriedforward from 5093b6b
orchestrator	66.87% <ø> (+0.01%)	⬆️
quickstart	63.74% <ø> (ø)		Carriedforward from 5093b6b
sandbox	79.56% <ø> (ø)		Carriedforward from 5093b6b
scorecard	85.34% <ø> (ø)		Carriedforward from 5093b6b
theme	88.52% <ø> (ø)		Carriedforward from 5093b6b
translations	5.12% <ø> (ø)		Carriedforward from 5093b6b
x2a	79.20% <ø> (ø)		Carriedforward from 5093b6b

*This pull request uses carry forward flags. Click here to find out more.

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5093b6b...804993a. Read the comment docs.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[lokanandaprabhu]

/lgtm

[lokanandaprabhu]

Thanks @upendhran for your contribution.