OCPBUGS-83427: Prevent multiple providers being injected in ClusterSecretStore Form view

[sampadasawant-36]

Summary

• The External Secrets Operator ClusterSecretStore CRD defines spec.provider as a JSON Schema object with maxProperties: 1 — meaning exactly one provider (e.g. azurekv, vault, gcpsm) may be set at a time. The Console Form view was rendering all provider sub-objects with their CRD schema defaults pre-populated. Since prune() only strips empty values, all provider keys survived into the YAML, causing a validation failure: must have at most 1 items for field 'spec.provider'.
• Added isSinglePropertyObject() helper in utils.ts to detect the maxProperties: 1 + multiple-properties pattern.
• Added SinglePropertyObjectField in fields.tsx: shows a dropdown to pick exactly one active provider, renders only that provider's sub-form, and calls onChange with only { [selectedKey]: data } — preventing sibling providers from being injected into the YAML.
• Wired the new field into CustomSchemaField so it activates automatically for any operator CRD using this pattern (not just ESO).

Test plan

• Install Red Hat External Secrets Operator v1.1.0 on OCP 4.18 / 4.20
• Navigate to Installed Operators → External Secrets Operator → Create ClusterSecretStore (Form view)
• Select a provider (e.g. AzureKV), fill in the required fields
• Switch to YAML view — verify only the selected provider appears under spec.provider
• Click Create — verify resource is created successfully with no must have at most 1 items error
• Run unit tests: cd frontend && yarn test --testPathPatterns="dynamic-form/(utils|fields)"

Fixes: https://redhat.atlassian.net/browse/OCPBUGS-83427

Made with Cursor

Summary by CodeRabbit

• New Features

  • Dynamic form now detects single-property object schemas and shows a provider dropdown to render only the selected provider's fields, normalizes form data to a single provider on mount, and ensures changes emit only the active provider's data.

• Tests

  • Added unit and integration tests covering schema detection, dropdown behavior, mount-time normalization, provider switching, and nested-field updates.

[openshift-ci-robot]

@sampadasawant-36: This pull request references Jira Issue OCPBUGS-83427, which is invalid:

• expected the bug to target the "5.0.0" version, but no target version was set

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

Details

In response to this:

Summary

• The External Secrets Operator ClusterSecretStore CRD defines spec.provider as a JSON Schema object with maxProperties: 1 — meaning exactly one provider (e.g. azurekv, vault, gcpsm) may be set at a time. The Console Form view was rendering all provider sub-objects with their CRD schema defaults pre-populated. Since prune() only strips empty values, all provider keys survived into the YAML, causing a validation failure: must have at most 1 items for field 'spec.provider'.
• Added isSinglePropertyObject() helper in utils.ts to detect the maxProperties: 1 + multiple-properties pattern.
• Added SinglePropertyObjectField in fields.tsx: shows a dropdown to pick exactly one active provider, renders only that provider's sub-form, and calls onChange with only { [selectedKey]: data } — preventing sibling providers from being injected into the YAML.
• Wired the new field into CustomSchemaField so it activates automatically for any operator CRD using this pattern (not just ESO).

Test plan

• Install Red Hat External Secrets Operator v1.1.0 on OCP 4.18 / 4.20
• Navigate to Installed Operators → External Secrets Operator → Create ClusterSecretStore (Form view)
• Select a provider (e.g. AzureKV), fill in the required fields
• Switch to YAML view — verify only the selected provider appears under spec.provider
• Click Create — verify resource is created successfully with no must have at most 1 items error
• Run unit tests: cd frontend && yarn test --testPathPatterns="dynamic-form/(utils|fields)"

Fixes: https://redhat.atlassian.net/browse/OCPBUGS-83427

Made with Cursor

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 openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: sampadasawant-36
Once this PR has been reviewed and has the lgtm label, please assign cajieh for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• frontend/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: cd4e3df8-c18a-431b-88eb-d11a360e011b

📥 Commits

Reviewing files that changed from the base of the PR and between 84e19ed and 0e20e20.

📒 Files selected for processing (2)

• frontend/packages/console-shared/src/components/dynamic-form/__tests__/fields.spec.tsx
• frontend/packages/console-shared/src/components/dynamic-form/fields.tsx

🚧 Files skipped from review as they are similar to previous changes (2)

• frontend/packages/console-shared/src/components/dynamic-form/tests/fields.spec.tsx
• frontend/packages/console-shared/src/components/dynamic-form/fields.tsx

---

Walkthrough

This PR adds a discriminated-union field pattern to the dynamic form system. A new utility detects JSON schemas with maxProperties: 1 and multiple properties, triggering a dropdown-based SinglePropertyObjectField that emits onChange payloads containing only the selected property.

Changes

Discriminated Union Dropdown Field

Layer / File(s)	Summary
Schema detection utility frontend/packages/console-shared/src/components/dynamic-form/utils.ts, frontend/packages/console-shared/src/components/dynamic-form/utils.spec.ts	New isSinglePropertyObject() predicate detects object schemas with type: "object", maxProperties: 1, and multiple properties; unit tests cover various schema configurations and invalid inputs.
Discriminated union dropdown component frontend/packages/console-shared/src/components/dynamic-form/fields.tsx	SinglePropertyObjectField adds mount-time normalization, stateful dropdown selection, scoped inner SchemaField rendering for the selected property, and onChange mapping to single-key objects; CustomSchemaField routes matching schemas to this component.
Component behavior tests frontend/packages/console-shared/src/components/dynamic-form/__tests__/fields.spec.tsx	Jest + RTL tests mock heavy UI deps and @rjsf/core internals; verify dropdown option rendering, default/preselection, conditional nested-field rendering, onChange payload shaping for provider switches and nested updates, and normalization on mount.

Sequence Diagram

sequenceDiagram
  participant CustomSchemaField
  participant isSinglePropertyObject
  participant SinglePropertyObjectField
  participant SchemaField
  CustomSchemaField->>isSinglePropertyObject: check resolved schema
  isSinglePropertyObject-->>CustomSchemaField: true (maxProperties: 1, multiple props)
  CustomSchemaField->>SinglePropertyObjectField: render with schema and formData
  SinglePropertyObjectField->>SinglePropertyObjectField: determine selected key from formData or first property
  SinglePropertyObjectField->>SinglePropertyObjectField: render dropdown with property keys
  Note over SinglePropertyObjectField: User selects provider from dropdown
  SinglePropertyObjectField->>SchemaField: render inner field for selected property schema
  SchemaField->>SchemaField: render form inputs for selected property
  SchemaField-->>SinglePropertyObjectField: onChange with field value
  SinglePropertyObjectField-->>CustomSchemaField: onChange with {selectedKey: updatedValue}

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 15

✅ Passed checks (15 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically summarizes the main change: preventing multiple providers from being injected into the ClusterSecretStore Form view, with the Jira issue prefix as required.
Description check	✅ Passed	The description includes Analysis/Root cause, Solution description, and Test plan sections with comprehensive details. However, it lacks screenshots, browser conformance checkboxes, and explicit reviewer/assignee tags as specified in the template.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Stable And Deterministic Test Names	✅ Passed	Verified modified test titles in fields.spec.tsx and utils.spec.ts: all describe/it strings are static and contain no dynamic data (no templates, timestamps, UUIDs, pods, etc.).
Test Structure And Quality	✅ Passed	PR #16616 changes only TS/Jest files (fields.spec.tsx, utils.spec.ts) and related components; no Ginkgo test code or cluster-interaction waits are present to assess.
Microshift Test Compatibility	✅ Passed	PR updates only Jest/RTL unit tests (e.g., fields.spec.tsx); these files contain no Ginkgo-style It/Describe/Context/When and no MicroShift-incompatible OpenShift APIs.
Single Node Openshift (Sno) Test Compatibility	✅ Passed	PR #16616 only adds/updates frontend dynamic-form unit tests and helper code (4 TS/TSX files); no new Ginkgo e2e tests or multi-node/HA assumptions to assess.
Topology-Aware Scheduling Compatibility	✅ Passed	PR #16616 modifies only frontend dynamic-form TS/TSX tests and utilities; no Kubernetes controller/deployment manifests or scheduling constraints (affinity/topology spread/replica math) are introdu...
Ote Binary Stdout Contract	✅ Passed	PR diff shows 0 changed .go files (only TS/TSX under frontend), so there’s no chance of stdout contract violations in OTE main/init/process-level code.
Ipv6 And Disconnected Network Test Compatibility	✅ Passed	PR only updates console-shared dynamic-form Jest unit tests/utils; no new Go Ginkgo e2e tests found (no ginkgo/Describe/Context/It patterns in the modified areas).
No-Weak-Crypto	✅ Passed	Scanned the PR’s changed dynamic-form TS/TSX files for MD5/SHA1/DES/RC4/3DES/Blowfish/ECB and crypto/secret-token comparison patterns; none found.
Container-Privileges	✅ Passed	PR touches only frontend dynamic-form TS/TSX/tests; scanning those files shows no hostPID/hostNetwork/hostIPC/SYS_ADMIN/privileged/allowPrivilegeEscalation/runAsUser settings.
No-Sensitive-Data-In-Logs	✅ Passed	PR adds isSinglePropertyObject + SinglePropertyObjectField and related tests; the PR diff shows no new console/logging that would print passwords/tokens/PII/customer data.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[openshift-ci]

Hi @sampadasawant-36. Thanks for your PR.

I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

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.

[sampadasawant-36]

/jira refresh

[openshift-ci-robot]

@sampadasawant-36: This pull request references Jira Issue OCPBUGS-83427, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (5.0.0) matches configured target version for branch (5.0.0)
• bug is in the state New, which is one of the valid states (NEW, ASSIGNED, POST)

Details

In response to this:

/jira refresh

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 openshift-eng/jira-lifecycle-plugin repository.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@frontend/packages/console-shared/src/components/dynamic-form/fields.tsx`:
- Around line 350-361: The component currently only enforces single-key provider
selection after user interaction; fix this by normalizing pre-populated formData
on mount: after computing initialKey (using propertyNames and formData) and
initializing selectedKey state, detect if formData contains more than one
provider key and call onChange({ [initialKey]: formData[initialKey] ?? {} }) to
replace the payload with only the chosen key so stale keys are removed; keep
handleKeyChange as-is for user changes. Also add a regression test that renders
the component with formData containing two provider keys and asserts that on
mount onChange is called (or final form state) with only the single normalized
key.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 5e6db521-fa8d-40a2-9c40-b43093c970c9

📥 Commits

Reviewing files that changed from the base of the PR and between 49745c2 and 84e19ed.

📒 Files selected for processing (4)

• frontend/packages/console-shared/src/components/dynamic-form/__tests__/fields.spec.tsx
• frontend/packages/console-shared/src/components/dynamic-form/fields.tsx
• frontend/packages/console-shared/src/components/dynamic-form/utils.spec.ts
• frontend/packages/console-shared/src/components/dynamic-form/utils.ts

[openshift-ci-robot]

@sampadasawant-36: This pull request references Jira Issue OCPBUGS-83427, which is valid.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (5.0.0) matches configured target version for branch (5.0.0)
• bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

Details

In response to this:

Summary

• The External Secrets Operator ClusterSecretStore CRD defines spec.provider as a JSON Schema object with maxProperties: 1 — meaning exactly one provider (e.g. azurekv, vault, gcpsm) may be set at a time. The Console Form view was rendering all provider sub-objects with their CRD schema defaults pre-populated. Since prune() only strips empty values, all provider keys survived into the YAML, causing a validation failure: must have at most 1 items for field 'spec.provider'.
• Added isSinglePropertyObject() helper in utils.ts to detect the maxProperties: 1 + multiple-properties pattern.
• Added SinglePropertyObjectField in fields.tsx: shows a dropdown to pick exactly one active provider, renders only that provider's sub-form, and calls onChange with only { [selectedKey]: data } — preventing sibling providers from being injected into the YAML.
• Wired the new field into CustomSchemaField so it activates automatically for any operator CRD using this pattern (not just ESO).

Test plan

• Install Red Hat External Secrets Operator v1.1.0 on OCP 4.18 / 4.20
• Navigate to Installed Operators → External Secrets Operator → Create ClusterSecretStore (Form view)
• Select a provider (e.g. AzureKV), fill in the required fields
• Switch to YAML view — verify only the selected provider appears under spec.provider
• Click Create — verify resource is created successfully with no must have at most 1 items error
• Run unit tests: cd frontend && yarn test --testPathPatterns="dynamic-form/(utils|fields)"

Fixes: https://redhat.atlassian.net/browse/OCPBUGS-83427

Made with Cursor

Summary by CodeRabbit

• New Features

• Dynamic form now detects single-property object schemas and shows a provider dropdown to render only the selected provider's fields, normalizes form data to a single provider on mount, and ensures changes emit only the active provider's data.

• Tests

• Added unit and integration tests covering schema detection, dropdown behavior, mount-time normalization, provider switching, and nested-field updates.

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 openshift-eng/jira-lifecycle-plugin repository.