PR 19793 review, round two

When no namespace in the list allows creating, the commit does namespace.value = null and emits null. Nothing else in the forms expected a null namespace. The select's own empty value is '', and the emit type had to be widened to string | null just for this.

What happens, and why

• Secret form: the field disappears. The Secret form is the only one that passes validators for the namespace. They're written as (val = '') => val.length, and a default parameter doesn't apply to null, so the select throws Cannot read properties of null (reading 'length') while rendering and Vue leaves nothing in its place. The user has no way to pick a namespace and no message. Create stays disabled.
• Chart install: it targets default. The wizard doesn't check the field, so Proceed and Install are enabled. targetNamespace falls back to 'default':
  • If the user can't see default, createNamespaceIfNeeded tries to create it and fails with namespaces "default" already exists.
  • If the user can see it, I captured the request going out with namespace: null. Rancher's namespace() in helmop/operation.go turns an empty value into "default". So someone with rights in default could install there with a blank field. I read that part in the source and intercepted the request, so no real install ran.
• Disabled select: a locked value gets wiped. The Fleet AppCo create form renders the select disabled, and typeToCheck doesn't skip that. A throwaway unit test confirmed the value is cleared on a select the user can't change. This one is from the unit test only; I didn't run that form in a browser.
• Other forms are fine. ConfigMap gets a clear "This resource is namespaced, so a namespace must be provided." Deployment, Service and PVC render a blank select with no error, though I didn't submit those three.

Who reaches it

Anyone with no creatable namespace in the current list, which is more than users with no rights at all. issue-8544-member can create in another project but gets here just by filtering the top nav to a read-only project, because the list stays inside the filter.

The fix

Drop the else branch and put the emit type back to string, so the value stays as it is when nothing is allowed. That matches master: the namespace shows, and Create gives the clear "forbidden" message from the server. All the problems above share this one cause, so they all go away, and it's fewer lines.

Switching null to '' looks tempting but only helps Secret. targetNamespace treats both as empty, so chart install would still target default.

Tested: the 2 touched suites pass (60 tests, with Cody's clears test changed to expect the value kept), lint is clean, and there are no new type errors. In the browser with the same filter, Secret, ConfigMap and chart install all match master, and the chart request goes out with view-only-ns, not null.

--- a/shell/components/form/NamespaceSelect.vue
+++ b/shell/components/form/NamespaceSelect.vue
@@ -51,7 +51,7 @@ interface Props {
   createAllowed?: boolean;
   /**
    * schema id of the resource being created; in create mode only namespaces the user may create it in are listed, and
-   * an existing pre-selected namespace the user may not create it in is replaced by the first one listed (or cleared)
+   * an existing pre-selected namespace the user may not create it in is replaced by the first one listed
    */
   resourceType?: string | null;
   rules?: Validator[];
@@ -84,7 +84,7 @@ const props = withDefaults(defineProps<Props>(), {
   required:                false,
 });
 
-const emit = defineEmits<{(e: 'update:value', value: string | null): void, (e: 'isNamespaceNew', value: boolean): void}>();
+const emit = defineEmits<{(e: 'update:value', value: string): void, (e: 'isNamespaceNew', value: boolean): void}>();
 
 const store = useStore();
 const { t } = useI18n(store);
@@ -262,9 +262,6 @@ function leaveNamespaceNotAllowingCreate(allowed: Set<string>) {
 
   if (firstAllowed) {
     emitChange(firstAllowed);
-  } else {
-    namespace.value = null;
-    emit('update:value', null);
   }
 }
 

You raised keeping the value in your review. My earlier fix only moved the automatic default, while Cody's moves any existing namespace the user can't create in. So cloning a ConfigMap from a read-only namespace now opens on the first allowed namespace, without saying so. I think that's better: the user couldn't have saved in the source anyway, the new namespace is visible before saving, and a clone from an allowed namespace stays where it was. Nothing to raise unless you feel differently.