Fix blank Update Group create page when a ManagedOSVersion has no ownerReferences

[marcelofukumoto]

Summary

Fixes #283

The Update Group create page renders blank when a ManagedOSVersion in the namespace has no metadata.ownerReferences.

Occurred changes and/or fixed issues

managedOSVersionOptions in pkg/elemental/edit/elemental.cattle.io.managedosimage.vue called .find() on version.metadata?.ownerReferences. The optional chain stops at metadata, so when a version has no ownerReferences the call runs on undefined and throws, aborting the computed and leaving the form blank. One such version breaks the page for all Update Group creation in the namespace.

The access is now version.metadata?.ownerReferences?.find(...). Versions without owner references are skipped (they belong to no channel) instead of throwing.

Technical notes summary

A ManagedOSVersion without ownerReferences is valid: the operator only stamps owner references on versions it syncs from a channel, so versions created by hand (the custom-images workflow) have none. The rest of the extension already treats ownerReferences as optional (elemental-config.js, machineinventory.js); this line was the exception.

Areas or cases that should be tested

• OS Management > Advanced > Update Groups > Create in a namespace that has a ManagedOSVersionChannel and a standalone ManagedOSVersion without ownerReferences: the form renders and no TypeError appears in the console.
• Update Group create/edit with channel-synced versions still lists versions grouped by channel.
• Tested locally on Chrome; reviewer please verify on a different browser.

Areas which could experience regressions

• The Update Group (ManagedOSImage) version dropdown. The change only affects how the version list is built; channel-owned versions are unaffected.

Screenshot/Video

Update Group create page in a namespace that has a ManagedOSVersionChannel and a ManagedOSVersion without ownerReferences.

Before — blank form; console shows TypeError: Cannot read properties of undefined (reading 'find'):

After — form renders; the ownerReference-less version is simply not listed as an option:

Checklist

• The PR is linked to an issue and the linked issue has a Milestone, or no issue is needed
• The PR has a Milestone
• The PR template has been filled out
• The PR has been self reviewed
• The PR has a reviewer assigned
• The PR has automated tests or clear instructions for manual tests and the linked issue has appropriate QA labels, or tests are not needed
• The PR has reviewed with UX and tested in light and dark mode, or there are no UX changes
• The PR has been reviewed in terms of Accessibility
• The PR has considered, and if applicable tested with, the three Global Roles Admin, Standard User and User Base

[marcelofukumoto]

Why this change is safe

Quick write-up on the concern about versions that have no ownerReferences.

What the change does

The whole change is adding one ?:

// before
version.metadata?.ownerReferences.find(...)

// after
version.metadata?.ownerReferences?.find(...)

This line runs when we build the OS version dropdown. We go through every channel and pick the versions that belong to it.

A version "belongs" to a channel through its ownerReferences. The channel is the one that creates the version, so it stamps itself as the owner.

The problem: if a version has no ownerReferences at all, ownerReferences is undefined, and calling .find() on undefined blows up. That error is what made the whole page go blank.

Adding the ? just means: if there are no ownerReferences, don't blow up — treat it as "this version has no owner".

Is the empty case OK?

Yes.

A version with no owner = a version that no channel created (someone made it by hand with YAML, or its channel was deleted).

Our dropdown groups versions by channel. If a version has no channel, there is simply no group to put it in, so we skip it. That is the correct behavior for a "group by channel" list.

We are not inventing this idea either — the list view already expects owner-less versions and just shows --- for them. So the code already knows this can happen.

Important: before the fix the page did not "hide" this version — it crashed and showed nothing at all. After the fix, everything else shows up fine and only the owner-less version is skipped. So this is strictly better than before.

Will it break something else?

No.

• The ? only changes what happens in the one case that used to crash. Every other case behaves exactly the same as before.
• The line only builds a list of dropdown options. Skipping one option can't corrupt any data.
• I checked every other place in the repo that reads ownerReferences. They are all already guarded (?.[0]?.name || '---', or an if (... && ...length) check). So there is no other spot waiting to crash on the same version.

One thing this does NOT do (on purpose)

This fix does not make owner-less versions selectable. They still won't show in the dropdown, because there is no channel to group them under.

That was already the case before (and the page just crashed instead), so this is not a regression — it's the same behavior, minus the crash.

If we ever want hand-made versions to be selectable, that's a separate, bigger change: add an "Ungrouped / Other" group for versions that don't match any channel. Worth a follow-up if the product wants it, but not needed for this fix.

Bottom line

Safe to merge. It removes a crash and keeps everything else exactly the same.