feat: add YAML editor functionalities

[cnotv]

Fixes #1480

NOTE: This logic is a per-case issue. There is no built-in functionality.

• Moved initialization logic within a single function
• Created comparison function
• Imported existing FileDiff component, avoiding duplication in code and configuration
• Added all the missing crossed unit tests

Views

Policy server

Kapture.2026-04-24.at.10.41.17.mp4

Cluster admission policy

Kapture.2026-04-23.at.17.20.33.mp4

Admission Policies

Kapture.2026-04-24.at.11.20.45.mp4

[cnotv]

Set back to draft again, so I can add the functionality to every editor. Done

[rak-phillip]

I think that this looks good, and I only want to double check the UX because it doesn't necessarily match Dashboard patterns for editing YAML, especially when taking into account Policy server/Cluster admission policy. The three buttons for editing the form/yaml/compare changes is usually reserved for multi-step wizards in Dashboard and this pattern is applied to a workflow that's more akin to editing resources, where "Edit as YAML" would be down in the footer.

That's not to say that this is explicitly incorrect, I want to confirm that the UX does not subvert expectations, taking the rest of Dashboard into account.

edit: hmmm... after typing all of this, I am now realizing that the "Edit Options/Edit YAML" pattern is already quite established throughout the Kubewarden UI. I think that my initial observation and concern is less relevant. The pattern fits correctly with pre-existing Kubewarden.

[cnotv]

I think that this looks good, and I only want to double check the UX because it doesn't necessarily match Dashboard patterns for editing YAML, especially when taking into account Policy server/Cluster admission policy. The three buttons for editing the form/yaml/compare changes is usually reserved for multi-step wizards in Dashboard and this pattern is applied to a workflow that's more akin to editing resources, where "Edit as YAML" would be down in the footer.

That's not to say that this is explicitly incorrect, I want to confirm that the UX does not subvert expectations, taking the rest of Dashboard into account.

edit: hmmm... after typing all of this, I am now realizing that the "Edit Options/Edit YAML" pattern is already quite established throughout the Kubewarden UI. I think that my initial observation and concern is less relevant. The pattern fits correctly with pre-existing Kubewarden.

This use of the editor has been directed by @oboc-sts
I leave it to you guys to discuss this and confirm to be ok.

[oboc-sts]

The pattern used here is inline with the "form / yaml / compare changes" functionality used in a few places across the dashboard in a variety of places, usually as part of a multi-step process indeed... but this doesn't mean we can't use it as a standalone interface if the situation asks for it - the consistency targets the mental models in terms of functionality and interaction patterns, not necessarily the context in which they are used. cc @rak-phillip

This being said, I thing it looks and behaves as it should @cnotv , it's good to go from my side 🚀

[rak-phillip]

@cnotv @oboc-sts I was hoping that my edit would be enough to express that I was coming to the realization that this was an accepted and intended pattern, and I thank you both for taking my concerns/observations into account 🙂

[cnotv]

@cnotv @oboc-sts I was hoping that my edit would be enough to express that I was coming to the realization that this was an accepted and intended pattern, and I thank you both for taking my concerns/observations into account 🙂

No harm done, I just wanted to double-check, taking the chance. TBH I feel better with a designer approval either case 😅
Sorry for not specifying it earlier.

[rak-phillip]

LGTM

[kravciak]

In some policies default values from are reported as changes.
I randomly found Pod Privileged Policy or Rbac Prohibit Watch On Secrets, but they are probably more.

Screencast.From.2026-04-30.08-37-18.mp4

[cnotv]

In some policies default values from are reported as changes. I randomly found Pod Privileged Policy or Rbac Prohibit Watch On Secrets, but they are probably more.

Screencast.From.2026-04-30.08-37-18.mp4

I guess we have to review as we initialize every single policy and find the default values to be added like that. It seems like the whole logic is not clearly defined in steps.
I'll try to remake it, thanks.

[cnotv]

Ok this issue seems to require way too much efforts into restructuring all the code, so I will just close it.