PR 19793 review

defaultNamespace picks the last-used namespace, then default, then the first one. It never looks at permissions, and it runs before the check comes back. namespaceSelectOptions then adds the current value back to the list so the select can display it, so the namespace the PR filtered out reappears at the top.

Who hits it

Anyone whose default isn't creatable. I reproduced two of these, and the third is the same code path:

• The first namespace alphabetically is read-only (issue-8544-first).
• A Cluster Member with View All Projects opens on default (issue-8544-cm). For that role the check says default isn't creatable, but it's preselected and listed.
• The last-used namespace came from a different resource type: a user who can create ConfigMaps in one project and Secrets in another. I saw this pref steer the form during testing, but I didn't run this exact role split.

The setup script in the description can't show it, because view-only-ns sorts after secrets-ns1. Rename it aaa-view-ns and it appears.

The fix

When the check comes back, if the current value is still the default and isn't allowed, select the first allowed namespace. Any other value stays, so a clone or a namespace being typed isn't touched. If nothing is allowed, nothing moves, which matches master. A disabled select now skips the check, so a locked value (the Fleet AppCo create form) can't move. That also saves a request and a spinner on a select nobody can change.

Tested: 4 new unit test cases, and the "moves the default" test fails without the fix. The 3 touched suites pass (65 tests), lint is clean and there are no new type errors. In the browser, it clears the case for issue-8544-first and issue-8544-cm on Secret and chart install, and issue-8544-cm on Deployment. issue-8544, member, read-only and admin behave as before.

--- a/shell/components/form/NamespaceSelect.vue
+++ b/shell/components/form/NamespaceSelect.vue
@@ -95,7 +95,7 @@ const inStore = computed(() => store.getters['currentStore']());
 const nsSchema = computed(() => store.getters[`${ inStore.value }/schemaFor`](NAMESPACE));
 
 const typeToCheck = computed(() => {
-  if (!isCreate.value || props.override || props.options || props.forceNamespace || !props.resourceType) {
+  if (!isCreate.value || props.override || props.options || props.forceNamespace || props.disabled || !props.resourceType) {
     return null;
   }
 
@@ -118,6 +118,15 @@ watch(typeToCheck, async(type) => {
   if (type === typeToCheck.value) {
     namespacesAllowingCreate.value = allowed;
     loadingNamespacesAllowingCreate.value = false;
+
+    // defaultNamespace does not know about permissions, so it can be a namespace the user cannot create in
+    if (allowed && namespace.value === store.getters['defaultNamespace'] && !allowed.has(namespace.value as string)) {
+      const firstAllowed = realNamespaceOptions.value[0]?.value;
+
+      if (firstAllowed) {
+        emitChange(firstAllowed as string);
+      }
+    }
   }
 }, { immediate: true });
 

This PR removes the last real use. What's left is the getter, getReadOnlyActiveNamespaces, the readonly param on getActiveNamespaces, a mapGetters entry nobody reads, and a fixture line in the PR's own new test. Removing them stops the old links.update rule from being reused by accident. GitHub search finds no other use in the rancher org or in harvester-ui-extension, but I can't see third-party extensions. A follow-up would be fine too.

Our checklist says no new files there, and this function has one caller, so it could live in NamespaceSelect.vue. That also drops the store: any. A fair answer from Cody would be that it mirrors shell/utils/project-permissions.ts, which came from your PR 18840, so skip this one if you don't feel strongly.

The description says a Steve without the feature, "e.g. Harvester's", falls back to every namespace. Both our Harvesters, v1.8.0-rc5 and v1.9.0-rc4, return resourcePermissions, so the check will really run there.

• No change today. The installed extension (1.10.0-dev.7) sent no check on the PR's shell and offered the same options as on master, on 8 create forms. So nothing should change until it's rebuilt against this shell.
• No empty dropdown risk found. I asked Harvester's API about the 22 type names its create forms could use, as admin. Real schemas report create in every namespace, and virtual names such as harvesterhci.io.secret have no schema, so the form skips the check rather than showing an empty list.
• Not tested: an extension rebuilt on this shell, and a non-admin Harvester user. The second needs Harvester data changes, which need your OK.

• e2e-test (admin, @navigation, @extensions): kubewarden.spec.ts fails in its before-all hook, waiting for the extension repo to go Active, on both attempts. The same spec fails with the same assertion on master at 261b8932f. The other 12 specs in that job pass.
• Branch Milestone: branches-metadata.json still maps master to v2.16.0 while this PR is on v2.17.0. PRs 19794, 19795 and 19796 are red on the same check.
• Build, unit, lint, type-check and every other e2e job are green. I also ran the PR's 3 touched suites locally: 61 pass.
• One question for you: the issue has the QA/dev-automation label and the PR has unit tests only, with no e2e for a restricted user. I don't know if the team expects one here.