QA review of every issue in QA Review

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

Decision: automatable = true · automation_sufficient = false · manual_test = true

Evidence reviewed: PR #14042

• shell/store/__tests__/prefs.test.ts (unit): afterLoginRoute now returns authRedirect for the home, cluster-*-dashboard and object landing-page preferences, not only for last-visited.
• shell/pages/__tests__/index.test.ts (unit, new): the redirect goes to afterLoginRoute, authRedirect is cleared once used, a bookmark beats unseen release notes, and an invalid route falls back to home.
• shell/utils/__tests__/auth.test.ts (unit): the index route no longer sets authRedirect.
• cypress/e2e/tests/pages/user-menu/preferences.spec.ts (e2e): the logged-out → visit /c/local/explorer/node → login → redirect check now runs for every landing-page option, not only "last visited".

Gaps The tests cover the store and routing logic well, but only with local login. The issue is about the GitHub OAuth round trip, where the browser leaves Rancher and comes back. The e2e comment says authRedirect only lives in the store, so nothing checks that the target survives a full page reload or the external auth callback. The maintainers' bookmark scenario (log out on page A, open a bookmark for page B, log in, land on B) is also not covered.

Suggested tests

1. e2e: in preferences.spec.ts (or a new auth spec), log out, cy.visit('/c/local/explorer/node'), run cy.reload() on the login page (to simulate leaving for an external IdP and coming back), then log in. Assert the user lands on /c/local/explorer/node. If this fails, the redirect target needs to be persisted, for example in session or local storage.
2. unit: for the auth verify/callback page used by OAuth providers (shell/pages/auth/verify.vue or equivalent), assert that after a successful provider callback the router goes to the stored redirect target and not to the landing-page preference, and that the target is cleared afterwards.
3. e2e: the bookmark case from the discussion. Set the landing page to "last visited", visit page A, log out, visit page B, log in. Assert the URL is page B, not page A.
4. unit: with authRedirect pointing at an extension route that is no longer installed, assert index.vue falls back to home and clears authRedirect. This keeps a stale bookmark from causing a redirect loop.

Why manual testing is still needed: this changes the login landing behaviour for every user and every landing-page preference (an agreed product/UX change, see the 2026-10-09 comments). The reported scenario depends on a real GitHub OAuth provider, which can't be reliably automated here. A human should verify the round trip with GitHub OAuth, plus one more external provider if one is available.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

No manual tests required. Automated tests are not yet sufficient for this issue. Please address the feedback from the QA Review Decision Model:

Decision: automatable = true · automation_sufficient = false · manual_test = false

Evidence reviewed: PR #19510

• shell/models/__tests__/secret.steve.test.ts (unit):
  • an existing helm release secret is saved as a JSON patch of only /metadata/labels and /metadata/annotations, with empty values when it has none
  • new helm secrets and other secret types still send the full body (post/put)
  • an explicitly requested method is kept
  • canEditYaml is false for secrets detected by _type or by the owner: helm label
• shell/edit/secret/__tests__/index.test.ts (unit, new):
  • in edit mode, the banner is shown instead of GenericSecretData and canYaml is false
  • in create mode and for other secret types, the editor and the Edit YAML button stay available

Gaps The core logic is well covered, but every test mocks dispatch. Nothing checks against a real Steve backend that the application/json-patch+json PATCH is accepted and that data.release is actually kept. That data-loss outcome is the heart of the bug. A rejected patch would show up as a failed save, and a wrong path would show up as lost release data. Neither would be caught.

Suggested tests

1. e2e: install a small chart, open its sh.helm.release.v1.<app>.v1 secret, edit it, add a label, and save. Intercept the request and assert it is a PATCH whose body contains only /metadata/labels and /metadata/annotations ops, with no data. Then fetch the secret through the API (with includeHelmData if needed) and assert data.release is still present and the label was applied.
2. e2e: on the same secret, assert the data tab shows [data-testid="secret-helm-release-banner"], that Edit YAML is not offered on the edit page or in the list/detail action menu, and that a helm upgrade/rollback of the app still works afterwards.
3. unit: for Secret.isHelmRelease, assert that an Opaque secret without owner: helm, and one with a different owner value, is not treated as a helm release. This guards against accidentally blocking data edits on unrelated secrets.

Manual testing: not required. This is a small, well-scoped model/form change with no complex UI flow. The suggested e2e tests would close the remaining backend-integration risk.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

Decision: automatable = true · automation_sufficient = false · manual_test = true

Evidence reviewed: PR #19354 (#18904 was closed without merging)

• shell/utils/__tests__/chart-values.test.ts (unit): strong coverage of the root cause.
  • overridesFromEditedValues: a deleted top-level or nested key keeps its default instead of being sent as null; the bug-report case (only image.pullSecrets left) yields only that override; an explicit null still removes a default; arrays are replaced.
  • mergeOverrides, mergeOverridesRawText (invalid or mid-edit YAML), overridesAreMergeable, sameYamlOverrides, changedLineNumbers
• shell/utils/__tests__/code-mirror-line-classes.test.ts (unit): line tinting.
• RcCodeMirror.test.ts, RcCodeMirror.vim.test.ts, CodeMirror.test.ts, AsyncButton.test.ts, Wizard.test.ts (unit): searchOpen, the Vim search panel, tabindex, wizard a11y.
• cypress/e2e/tests/pages/charts/chart-install-wizard.spec.ts (e2e):
  • both panes render, and an override typed in Your values appears in Chart values
  • Compare Changes shows a single full-document diff

Gaps None of the e2e tests check the install request payload, which is the acceptance criterion: "only the altered values should be sent". Also not covered end to end:

• deleting a key in the Chart values pane
• the edit/upgrade flow and its new banner
• switching between the form and Edit YAML
• invalid YAML blocking install

Suggested tests

1. e2e: on the rancher-demo install, go to Edit YAML, delete a default key (for example a whole service: block) in the Chart values pane, blur, and click Install. Intercept POST .../catalog.cattle.io.clusterrepos/*?action=install and assert charts[0].values contains no null and no removed key, and that the deleted default reappears in the pane after blur.
2. e2e: add image.pullSecrets: [x] in Your values and install. Assert the payload values equals exactly that override (plus global.cattle where applicable). Repeat with an explicit key: null and assert that the null is sent.
3. e2e: edit or upgrade an installed app that has custom values. Assert Your values shows only those values, the upgrade banner appears only when the chart version changes, and the upgrade payload contains only the overrides.
4. unit: in the chart install.vue tests, applyYamlToValues merges valuesYaml overrides onto the defaults and the final values built for save omits keys the user deleted. Switching from the form to YAML puts only form-changed values (and question defaults) into valuesYaml.
5. unit/e2e: invalid YAML in Your values plus Install shows an error and sends no request.

Why manual testing is still needed: the issue has priority/0 and headline labels. It is a large UX redesign of the chart values editor (two synced panes, search panel, diff view, keyboard/a11y changes), and it touches install, edit and upgrade for every chart, including custom-form charts like Monitoring and AppCo OCI charts. Regression risk is high.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

Decision: automatable = true · automation_sufficient = false · manual_test = true

Evidence reviewed: PR #19513

• pkg/rancher-components/src/components/Form/LabeledInput/LabeledInput.test.ts (unit):
  • showCronHint: false hides the hint, keeps subLabel, and leaves aria-describedby unset
  • cron-hint-change emits the initial hint, emits on value change, emits undefined when cleared, and is not emitted for non-cron types
• HelmOpTargetOptionsSection.test.ts.snap: snapshot-only update for the new prop.

Gaps The new component API is well tested, but the actual fix lives in shell/edit/workload/index.vue: the hint moves into a cron-schedule-hint column next to the input. That has no test. Nothing checks that the CronJob form shows the hint there, that aria-describedby="cron-schedule-hint" links to it, or that the long hint from the issue (53 18 30 4 3) no longer overlaps other fields.

Suggested tests

1. unit: mount shell/edit/workload/index.vue as a CronJob and emit cron-hint-change with a long string from the schedule LabeledInput. Assert [data-testid="cron-schedule-hint"] shows that text, the input has show-cron-hint=false and aria-describedby="cron-schedule-hint", and the hint element is not rendered for non-CronJob workloads.
2. e2e: go to Workloads → CronJobs → Create, type 53 18 30 4 3 in Schedule, and assert [data-testid="cron-schedule-hint"] contains the human-readable description. Change the schedule to @daily and assert the text updates. Clear it and assert the hint is empty.
3. e2e (layout guard): with the long schedule entered, assert the hint's bounding box does not overlap the Schedule input or the next form row, for example by comparing getBoundingClientRect() values.

Why manual testing is still needed: this is a visual layout fix (text overlapping other elements) with a design decision behind it. It depends on viewport width, translations and themes, so a human should check different widths and light/dark mode.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

Decision: automatable = true · automation_sufficient = false · manual_test = true

Evidence reviewed: PR #19127 (16 files, unit tests only, no Cypress)

• shell/models/__tests__/persistentvolumeclaim.test.ts (unit):
  • fetchMountedPods filters by claimName, uses a namespaced request when pagination is on or off, and returns an empty list when there is no Pod schema
  • details (status capacity/access modes, pending state, PV link)
• shell/models/__tests__/persistentvolume.test.ts (unit): fetchPersistentVolumeClaim with no claimRef, no schema, the SSP findPage path and the direct find fallback; details.
• shell/models/__tests__/workload.service.test.ts (unit): persistentVolumeClaimNames (Deployment, CronJob, Pod, dedupe from pods), StatefulSet volumeClaimTemplates prefixes and ordinal matching (the data-web-api-0 false-positive guard), and fetchPersistentVolumeClaims for SSP and non-SSP, including a scaled-to-0 StatefulSet.
• shell/detail/__tests__/persistentvolumeclaim.test.ts, persistentvolume.test.ts (unit): the useMountedPods / useBoundPersistentVolumeClaim loading, error and no-schema states.
• shell/detail/__tests__/pod.test.ts (unit): pvcHeaders drops the namespace column.

Gaps The data-layer coverage is very good, but the user-facing pieces of this headline feature have no component or e2e tests:

• the new PVC detail page with its Pods tab (the original request)
• the new PV detail page with its Claims tab
• the Storage tab on workload and pod detail pages, including the "Could not find…" empty states

Suggested tests

1. e2e: create a PVC (with the local-path provisioner or a hostPath-backed PV) and a Deployment that mounts it. Open the PVC detail page and assert the Pods tab lists the Deployment's pod(s) and not pods from other namespaces. Scale the Deployment to 0 and assert the empty-state text Could not find any Pods that mount this PersistentVolumeClaim..
2. e2e: open the Deployment detail page and assert the Storage tab lists the mounted PVC with a working link to the PVC detail page. For a workload with no PVC, assert Could not find any PersistentVolumeClaims mounted by this workload..
3. e2e: open the bound PV detail page and assert the masthead shows Source, Capacity, Reclaim Policy, Storage Class and Access Modes, and that the Claims tab lists the bound PVC. For an unbound PV, assert This volume is not bound to a PersistentVolumeClaim..
4. unit: mount shell/detail/workload/index.vue with a mocked fetchPersistentVolumeClaims that resolves to one PVC, then to none. Assert the Storage tab renders a ResourceTable with the rows, or the empty caption. Assert the tab is hidden when the PVC schema is missing (the user has no permission).
5. e2e: a StatefulSet with volumeClaimTemplates. Assert its Storage tab lists the data-<sts>-N claims, including after scaling to 0.

Why manual testing is still needed: this is a headline, priority/1 enhancement. It adds two new detail pages and new tabs across workload and pod pages, involves navigation across several pages, and has UX input (status/waiting-ux). It should also be checked by a human with SSP on and off and as a restricted user.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Decision: automatable = true · automation_sufficient = true · manual_test = true

Rationale: the defect was a client-side validation rule in shell/components/auth/login/saml.vue, and it is directly and thoroughly unit-tested. The real CLI → Rancher → SAML IdP round trip, however, depends on an external IdP and the Rancher CLI. That can't be reliably automated in this repo, and the fix is for a customer escalation (SURE-11969) on a critical auth path.

Test evidence: PR #19037

• shell/components/auth/login/__tests__/saml.test.ts (unit, new):
  • CLI login detection: each of cli, requestId, publicKey, responseType triggers CLI mode, and none of them means a browser login.
  • Response type validation (acceptance criteria): accepts kubeconfig, kubeconfig_local, kubeconfig_c-m-zx8p4nvt, and a cluster id that contains _.
  • Failure paths: rejects json, kubeconfigs, kubeconfig_ and an empty string, plus a missing requestId or publicKey. It asserts .cli-error is shown and the submit button is hidden.
  • Signing in: the cluster-scoped responseType is passed through to auth/login unchanged, along with requestId, publicKey and finalRedirectUrl.
• shell/composables/__tests__/useLogin.test.ts (unit, new): loginDisplayName labelling and fallback, focus-on-mount behaviour, and no error when there is no focus target.
• shell/mixins/__tests__/login.test.ts (unit): t is called with the component as this after the refactor to the shared helper.

Manual testing recommended because:

• saml.vue was rewritten from Options API + mixin to <script setup> with a new useLogin composable. That carries regression risk for every SAML-based provider (Okta, Shibboleth, Keycloak SAML, ADFS, Ping), for both browser and CLI login.
• End-to-end verification needs a real SAML IdP and rancher token --auth-provider=... --server=... against a downstream cluster.

Residual risk to monitor

• Browser (non-CLI) SAML login still focuses the button and redirects to the IdP.
• rancher token for both the local cluster (kubeconfig) and a downstream cluster (kubeconfig_<clusterId>) completes and returns a token to the CLI.
• The issue is a backport candidate. Re-check this on the backport branches.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. No manual tests required.

Decision: automatable = true · automation_sufficient = true · manual_test = false

Rationale: this is a small, deterministic formatting fix in the node detail memory gauge. The tests assert the exact user-visible strings for the reported cases, and the change is scoped to one gauge.

Test evidence: PR #18360 (#18359 was closed without merging)

• shell/detail/__tests__/node.test.ts (unit):
  • The memory ConsumptionGauge no longer receives a shared units label (''). This guards against the old behaviour, where a single unit was applied to both values.
  • numberFormatter scales each value on its own: 900 MiB (the "976 of 1.97 TiB" case from the issue), 3.55 GiB (the "3.55 of 15GiB" case), and 512 B for plain bytes rather than 512 iB (edge case).
• shell/components/__tests__/ConsumptionGauge.test.ts (unit):
  • used and total each go through the formatter with an empty shared unit when no units prop is given.
  • When a units prop is supplied (other gauges such as CPU and pods), it is still appended to the total. This guards against regressions in the other gauges.

Manual testing: not required. There is no complex UI flow, the risk is low, and the expected output is fully asserted.

Residual risk to monitor: the translation template node.detail.glance.consumptionGauge.amount now gets an empty unit for memory. Watch for spacing glitches in non-English locales.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. No manual tests required.

Decision: automatable = true · automation_sufficient = true · manual_test = false

Rationale: this is a store-level race condition. The fix (mark the key pending synchronously in set, and ref-count pending keys) is in shell/store/prefs.ts. The new tests reproduce the race from the issue with a controllable fake server and assert both what the UI store shows and what ends up on the server.

Test evidence: PR #19427

• shell/store/__tests__/prefs.test.ts → quick successive sets (unit):
  • Keeps a box ticked while an earlier write is still in flight: samples the UI state across microtasks while DEV and SHOW_PRE_RELEASE are set back to back. It asserts the only state ever seen is both true, so there is never a flicker or a stale overwrite. This is exactly the sequence in the issue.
  • Store agrees with the server once both writes land: both the UI and the backend end up {dev: true, pre-release: true}.
  • Same key toggled twice with another write in between (edge case): checks that the ref-counting keeps the last value (dev: false) both locally and on the server.
  • Pending count drops back to zero: a later loadServer still picks up a change from another tab, so a key can't stay "in flight" forever (failure path).
• Existing tests in the same file still cover the enqueuePreferenceWrite queue and the commitAndReconcile path, which now use holdPending/releasePending.

Manual testing: not required. The behaviour is fully deterministic at the store level and the race is reproduced directly in the tests. The UI is a plain checkbox that is bound to the store.

Residual risk to monitor: the comment on the issue notes that 2.13–2.15 don't have the write queue from #18884, so any backport needs that too and should be reviewed on its own.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

Decision: automatable = true · automation_sufficient = false · manual_test = true

Evidence reviewed: PR #19274 (CM5 → CM6 RcCodeMirror migration, 61 files; also fixes #9453 and #15479)

• cypress/e2e/po/components/code-mirror.po.ts: the page object now supports CM6 (EditorView.findFromDOM) as well as legacy CM5.
• cypress/e2e/tests/components/code-mirror-shortcuts.spec.ts (e2e, new): Emacs Ctrl-K and Ctrl-P inside the editor, and Ctrl-K opening the nav search outside it.
• extension-compatibility.spec.ts, KnownHostsEditDialog.po.ts (e2e): moved to the CM6 page object.
• The PR body itself says: "This change does not filter the release field from Helm Secrets. QA should verify the original large secret case in #16911 with a realistic release."

Gaps None of the tests exercise the scenario in this issue. There is no test that opens Show Configuration for a helm.sh/release.v1 secret with a large base64 release value and checks that the panel renders and the UI stays responsive. The fix relies only on CM6 rendering performance. The issue's suggested mitigation (detect this secret type and skip the release payload) was not implemented, so a performance regression would go unnoticed.

Suggested tests

1. e2e: intercept GET /v1/secrets* (or create a secret through the API) to return a helm.sh/release.v1 secret whose data.release is a multi-MB base64 string. From Secrets → All Namespaces, click Show Configuration. Assert the slide-in's .cm-editor is visible within a bounded timeout (for example MEDIUM_TIMEOUT_OPT), and that a follow-up interaction such as closing the panel or clicking a nav item responds within the timeout.
2. e2e: on the same large secret, open the detail page and Edit YAML. Assert the editor renders, scrolling and search (Mod-F) work, and Cancel returns to the list.
3. unit: in RcCodeMirror.test.ts, mount with a modelValue that has one very long line (around 5 MB). Assert mount completes and the DOM renders only the visible viewport, for example that the .cm-line count is far below the document line count and long-line content is virtualized. This guards against regressions to non-virtualized rendering.
4. unit (if the release filtering is added later): for the secret model or the config slide-in, assert that helm.sh/release.v1 secrets are fetched or displayed without the release value.

Why manual testing is still needed: the PR explicitly asks QA to check this with a realistic Helm release. Freezing and memory behaviour depends on the browser and is not fully captured by CI. The migration also replaces the editor on every YAML surface (resource YAML, Import YAML, chart config, cluster provisioning, logging, Harvester, multiline key/value), which is broad regression risk across the UI.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

Automated tests appear sufficient for this issue. No manual tests required.

Decision: is_automatable: true · automation_sufficient: true · manual_test: false

Rationale

• The fix is small and targets the root cause. getDynamic('component', …) in shell/core/extension-manager-impl.js now returns component definitions wrapped in markRaw. Header.vue stores the result, or null, in navHeaderRight. This stops Vue from proxying the NavHeaderRight component and removes the console warning.
• The issue is a dev-time console warning with no visible UX change, and the risk of regression is low.

Test evidence (PR #18995)

• unit: shell/core/__tests__/extension-manager-impl.test.js
  • marks retrieved dynamic components as raw so they are never made reactive: asserts that isReactive(reactive({ retrieved }).retrieved) is false for the component type.
  • does not markRaw non-component dynamic types: edge case. Other dynamic types such as models stay reactive, so nothing outside components is affected.
• unit: shell/components/nav/__tests__/Header.test.ts → describe('navHeaderRight')
  • Stores the raw dynamic component from getDynamic and asserts it is not reactive.
  • Sets the value to null when no dynamic component is registered (empty/failure path).

Manual testing: not recommended. The tests assert directly on the condition Vue warns about (isReactive), and no user flow depends on the change.

Residual risk

• Other call sites that put async component definitions into reactive state without going through getDynamic could still trigger the same warning. Watch the dev console on the home page and other pages during routine e2e runs.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

Decision: is_automatable: true · automation_sufficient: false · manual_test: true

What is already covered (PR #19540)

• unit: shell/dialog/__tests__/RotateCertificatesDialog.test.ts is thorough:
  • service lists for RKE2, K3s and imported day-2-ops clusters, including supervisor
  • default and selected-services modes, Reset, and the "+N more" collapse
  • the certificate rotation operation CR payload (OPERATION.CERTIFICATE_ROTATE) for all services and for selected services
  • a 403 error banner, the in-flight guard against closing or rotating twice, and the RKE2 generation bump
• unit: shell/models/__tests__/provisioning.cattle.io.cluster.test.ts: the rotateCertificates action is enabled or disabled based on day 2 ops, readiness and canUpdate, and promptModal is called with ownsModal: true.
• unit: Select.test.ts covers the aria-required placement.

Gaps against the acceptance criteria and suggested tests

1. unit: permission gating on the certrotate CR. The acceptance criteria say the action is visible "when the user has permission to create the operation certrotate CR (certrotate.operation.cattle.io)". The model now uses canDayTwoOps (ready && isDayTwoOpsEnabled && canUpdate), and no test ties visibility to create permission on OPERATION.CERTIFICATE_ROTATE. Add a model test asserting the action is disabled or hidden when the user cannot create the certrotate schema, and enabled when they can. If canUpdate is the intended proxy, assert that explicitly.
2. unit: "UI reflects its status". shell/detail/provisioning.cattle.io.cluster.vue now adds OPERATION.CERTIFICATE_ROTATE to both operation-type lists, and no test covers it. Add a detail-page test asserting that certrotate operation CRs for the cluster are fetched and appear in the operations list with their state, for example Running then Completed.
3. e2e: imported cluster rotate flow. Use cypress/ with intercepted APIs on an imported RKE2 cluster with day 2 ops:
   • open the cluster actions menu and click Rotate Certificates
   • choose Selected services and pick api-server and supervisor
   • click Rotate
   • assert the POST to the certrotate operation endpoint has spec.clusterRef.name set to the management cluster id and spec.args.services set to ['api-server','supervisor']
   • assert the dialog closes and the operation appears on the detail page
4. e2e: failure path. Stub the certrotate POST with a 403 and assert the error banner shows and the dialog stays open.

Why manual testing is still needed: the actual certificate rotation runs on a real imported RKE2/K3s cluster. That means services restart, the cluster shows Updating and then returns to Active, and the operation status must update on the detail page. This depends on the backend (rancher/rancher#54260) and cannot be reliably simulated. The dialog was also redesigned (RcModal, multi-select tokens), which needs a UX check.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

Decision: is_automatable: true · automation_sufficient: false · manual_test: true (priority/0, headline, large auth-flow impact)

What is already covered (PR #19495)

• unit, login: shell/components/auth/login/__tests__/AuthProviderSelect.test.ts, the new provider selection on the login page.
• unit, model and utilities: shell/models/__tests__/management.cattle.io.authconfig.test.ts, shell/utils/__tests__/auth-provider-details.test.ts and shell/utils/__tests__/auth-providers.test.ts. These cover telling instances apart and the limit of one enabled provider on community.
• unit, list and create pages: shell/pages/c/_cluster/auth/config/__tests__/index.test.ts and .../create/__tests__/provider.test.ts. These cover the list controls and the community/Prime limit on the list, the add dialog and the direct create URL.
• unit, mixin: shell/mixins/__tests__/auth-config.test.ts (enable/disable and the Norman disable() action) and shell/components/auth/__tests__/AuthProvidersPrimeNotice.test.ts.
• unit, provider forms: the OIDC, GitHub App, LDAP and AD forms now branch on the config's type rather than its id.
• e2e: existing specs were updated so configs are added on demand (cypress/e2e/blueprints/users/auth-config-stubs.ts, okta.spec.ts, openldap.spec.ts, azuread.spec.ts, cognito.spec.ts, githubapp.spec.ts). These keep single-provider coverage working on the new create route, but none of them tests multiple auth configs. A search of cypress/ finds no reference to multiple-auth-providers.

Suggested tests

1. e2e: log in when several providers are enabled. Stub /v1-public/authproviders with two enabled configs of the same type, for example two GitHub configs with different human names and descriptions, plus local. On the login page, assert both entries render with their own name and description. Choose the second one and assert the login request references that config's id rather than the provider type.
2. e2e: manage auth configs on Prime with the feature enabled.
   • From the Auth Provider list, add a second config of a type that already exists, entering a name and description.
   • Assert the request names the config at the root of the payload, and that the page returns to the list showing both configs.
   • Disable one and assert it stays on the list marked as disabled.
   • Edit it and assert Save returns to the list.
3. e2e: community limit. With the feature off and not a Prime build, and one provider enabled:
   • assert Add is unavailable on the list and the community notice is shown
   • assert a direct visit to /auth/config/create/<provider> shows the fail-whale limit page with a link back to the list
4. unit: membership management and principal display. Per the acceptance criteria, principals should show <provider type> / <auth config name> / <type> / <principal name>. Add tests for:
   • the principal display and the Users list provider column including the auth config's human name
   • a secondary sort on the auth config name
   • parsing a principal id of the form <config name>_<type>://<id>, using the principal's provider field
5. unit: type translation. Assert that _type values (githubConfig, azureADConfig, activeDirectoryConfig) and authprovider type values (githubProvider) map correctly to the UI's provider type. Include a config whose metadata.name (for example github-2) differs from its type.

Why manual testing is still needed: this is a priority/0 headline Prime feature that changes the login page, the auth provider management pages and identity across the product. Real IdP round-trips (GitHub, OIDC, LDAP/AD, SAML) with several configs of the same type, and the edition behaviour on Prime versus community, need a human check on a real environment.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

Decision: is_automatable: true · automation_sufficient: false · manual_test: true

What is already covered (PR #19106)

• unit: shell/edit/provisioning.cattle.io.cluster/__tests__/Ingress.test.ts → describe('ingress-nginx prime-only restriction')
  • On a non-Prime build creating a cluster with k8s >= v1.37.0, the NGINX card is disabled and shows the community content and doc link.
  • Below v1.37.0, the card stays enabled with the default content.
  • On Prime, the card stays enabled even at v1.37.0 or later.
  • In edit mode the restriction does not apply, which covers the "existing clusters" criterion.
  • In view mode every card is disabled.
• unit: Basics.test.ts checks that the selected Kubernetes version is passed to the Ingress component.

Gaps against the acceptance criteria and suggested tests

1. unit: "Community edition should only support Traefik". INGRESS_OPTIONS marks only ingress-nginx as prime: true. The Dual option is not restricted, and nothing asserts what Dual does on community with v1.37 or later. Add a test that pins the intended behaviour: either Dual is also disabled on community, or it is explicitly allowed.
2. unit: "Both still have an option to disable Ingress". On non-Prime with v1.37 or later, assert that the Traefik and None cards are present and disabled === false, and that choosing None emits the expected ingress-controller value.
3. unit: default and pre-selected value. If the form value is already ingress-nginx when a community user switches the Kubernetes version to v1.37 or later, for example on a clone or when the default changes, assert what happens. Either the selection moves to Traefik, or a validation error or banner blocks saving. Otherwise NGINX could be submitted through a card that is now disabled.
4. unit: transitioning banner. Assert that showTransitioningBanner is hidden on community with v1.37 or later and shown on Prime or on lower versions.
5. e2e: RKE2 create on community. In cypress/, open the custom RKE2 create page, pick a v1.37 Kubernetes version and assert the NGINX card is disabled with the "only available in SUSE Rancher Prime" text. Switch to a v1.36 version and assert it is enabled again.

Why manual testing is still needed: this removes a provisioning option for community users, which is a significant product impact. It also depends on the real Prime and community builds (RancherPrime version data) and on real v1.37 KDM versions, which unit mocks only simulate. A quick check of create and edit on both editions is recommended.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

Decision: is_automatable: true · automation_sufficient: false · manual_test: true

What is already covered (PR #19152)

• unit: shell/components/form/__tests__/RcAgentConfiguration.test.ts covers the new shared agent configuration component:
  • the requests and limits, tolerations and affinity sections
  • the showTolerations and showAffinity flags used to hide tolerations and affinity for imported clusters
  • writing and reading overrideResourceRequirements (requests.cpu/memory, limits.cpu/memory)
  • passing the agent type (cluster or fleet) to scheduling customization
• unit: shell/components/__tests__/RcContainerResourceLimit.test.ts, the new shared requests and limits component.
• unit: pkg/imported/components/__tests__/CruImported.test.ts, expanded by about 250 lines over three commits, covers the imported cluster form.
• e2e: cypress/e2e/tests/pages/manager/cluster-manager.spec.ts changed slightly (+19/−6). Judging by the size, this looks like an update to existing selectors or flows rather than a new imported-cluster agent-limits scenario.

Suggested tests

1. e2e: edit an imported cluster and set agent limits.
   • In cypress/, open an imported cluster's edit page, go to Advanced → Agents, and set CPU and memory requests and limits for both the Cluster Agent and the Fleet Agent.
   • Save and intercept the PUT.
   • Assert clusterAgentDeploymentCustomization.overrideResourceRequirements and fleetAgentDeploymentCustomization.overrideResourceRequirements contain the entered values.
   • Re-open the edit page and assert the values load back into the form.
2. e2e: layout changes on the imported cluster form. Assert that Registries now sits under Advanced, that the Agents section exists, and that tolerations and affinity are not shown for imported clusters, as agreed in the issue discussion.
3. unit: clearing limits. In the CruImported or RcAgentConfiguration tests, clear every request and limit field and assert the saved payload drops overrideResourceRequirements, or sends an empty object. It should not send empty-string quantities the API would reject.
4. e2e or unit: no regression on v2prov. The shared component is meant to be reused for v2prov clusters. Assert that the RKE2 create/edit Cluster Agent and Fleet Agent tabs still render requests and limits, tolerations and affinity, and save to spec.clusterAgentDeploymentCustomization and spec.fleetAgentDeploymentCustomization.

Why manual testing is still needed: this is a customer-driven request (SURE-7608, priority/1) that changes the imported cluster form layout. It also needs proof that the values actually reach the downstream cattle-cluster-agent and fleet-agent deployments in cattle-system and cattle-fleet-system, which needs a real imported cluster.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Decision: is_automatable: true · automation_sufficient: true · manual_test: true (priority/0, headline)

Rationale

• PR #19397 adds a telemetry extension point (EXT_IDS.TELEMETRY). SUSE extensions register a TelemetryFunction(getters), and its params are added to the dynamic content request query string by SystemInfoProvider in shell/utils/dynamic-content/info.ts. The behaviour is pure logic that unit tests can fully exercise, and the tests are extensive.

Test evidence: unit, shell/utils/dynamic-content/__tests__/info-extensions.test.ts, new, 333 lines

• Happy path: telemetry is collected from known SUSE extensions, from built-in extensions such as rancher-prime, and from extensions listed in the suseExtensions setting. Multiple functions across several extensions are merged, and the store getters are passed to each function.
• Security and isolation: telemetry from non-SUSE extensions is ignored and never called. An extension cannot overwrite any existing param (dcv, s, u, uuid, v, p, cc, bl), and encoded names cannot inject extra params.
• Failure and edge paths:
  • functions that throw, or return a non-object or an array, are skipped
  • non-scalar values and empty or whitespace-only names are dropped
  • registered values that are not functions are ignored
  • when two extensions send the same param, the first value wins
  • params are URL-encoded and appended after the standard params
  • the MAX_TELEMETRY_LENGTH size cap is enforced, including the boundary case, and dropped params are logged
  • the case of no extensions loaded is handled
• Documentation: docs/developer/extensions-telemetry.md.

Why manual testing is still recommended: the priority/0 label requires a human check. Verify with a real SUSE extension, for example Rancher Prime, that its registered telemetry params appear on the live dynamic content request and that the standard params are unchanged.

Residual risk

• The registration path (plugin.register('telemetry', …) populating ext.types.telemetry) is mocked in the tests. A small integration test through the real extension manager would close that gap.
• Older Rancher versions that load an extension using this API rely on the generic register doing nothing harmful. That is worth a quick check during manual QA.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Decision: is_automatable: true · automation_sufficient: true · manual_test: true

Rationale

• PR #19443 adds a Workspace field to the GitRepo, HelmOp, Cluster Group and Policy forms and leaves the header switcher disabled, as the acceptance criteria require. It also handles references that don't exist in the new workspace, restores them when the user switches back, and switches the header after save. The unit tests cover each part of the change, and there are e2e tests for the main clone-into-another-workspace flow.

Test evidence

• e2e:
  • cypress/e2e/tests/pages/fleet/gitrepo.spec.ts covers cloning a GitRepo into another workspace.
  • cypress/e2e/tests/pages/fleet/cluster-groups.spec.ts covers cloning a cluster group into another workspace.
• unit, new:
  • shell/edit/__tests__/fleet.cattle.io.gitrepo.workspace.test.ts and fleet.cattle.io.helmop.workspace.test.ts cover:
    • changing the workspace, and deselecting secrets, valuesFrom, downstream resources and targets that don't exist there, with the banner listing them
    • swapping in the new workspace Policy's credential
    • moving into fleet-local, which targets all clusters
    • restoring deselected references when going back to their workspace (commit 262e99b)
    • the App Collection field being disabled
  • shell/edit/__tests__/fleet.cattle.io.clustergroup.test.ts covers the new Cluster Group workspace field.
• unit, updated:
  • fleet.cattle.io.policy.test.ts covers the Policy workspace field.
  • shell/utils/__tests__/fleet-workspace.test.ts covers the shared retargeting helpers.
  • LabeledSelectWithCreate.test.ts and NamespaceSelect.test.ts check that clearing the Workspace field cannot create a namespace (failure path).
  • shell/models/__tests__/fleet.cattle.io.gitrepo.test.ts and fleet.cattle.io.helmop.test.ts check that a clone keeps its namespace and drift correction.

Why manual testing is still recommended: the change involves heavy UI integration across several Fleet forms, the header switcher and list pages. It also adds an accessibility element (the banner announced to screen readers) and needs a UX-validated flow. A quick pass should cover:

• cloning an App Bundle / HelmOp into another workspace
• the deselection banner wording
• the header following the saved resource
• an App Collection bundle keeping its credential's workspace

Residual risk

• No e2e test covers cloning a HelmOp/App Bundle or a Policy. This flow is covered by unit tests only.
• The behaviour of targets when moving between workspaces with many clusters should be watched on real installs.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

No manual tests required. Automated tests are not yet sufficient for this issue. Please address the feedback from the QA Review Decision Model:

Decision: is_automatable: true · automation_sufficient: false · manual_test: false

Note: the linked PR #19500 is still open and not merged, so its tests are not yet on the main branch.

What is already covered (PR #19500)

• unit: shell/utils/validators/formRules/__tests__/index.test.ts has new pemCertificate, pemPrivateKey, sshPublicKey and dataKey rules. Each has valid and invalid cases: chains, mismatched end lines, invalid base64, encrypted and OpenSSH keys, and length or character limits. Empty values are left to required.
• unit: shell/edit/secret/__tests__/tls.test.ts checks that invalid tls.crt or tls.key makes isFormValid false, that a blank key is allowed in edit mode, and that an invalid new key in edit mode fails.
• unit: shell/edit/secret/__tests__/ssh.test.ts checks that an invalid public or private key makes isFormValid false.
• unit: shell/edit/secret/__tests__/generic.test.ts checks that an invalid data key makes the form invalid, that only the invalid keys are passed to KeyValue, and that the form revalidates when keys change.
• unit: shell/edit/secret/__tests__/index.test.ts checks the nameRules path for a cloud credential versus a Kubernetes secret.

Suggested tests

1. unit: the Create button is disabled (acceptance criterion 2). The tests above assert on the isFormValid value from a test FormHost, not on the real Secret page. Mount shell/edit/secret/index.vue (CruSecret) with a TLS secret containing tls.crt: 'not-a-cert'. Assert that CruResource receives validation-passed === false and that the Create button is disabled. Then set a valid PEM certificate and key and assert the button is enabled.
2. e2e: create a TLS secret with an invalid value. In cypress/, go to Storage → Secrets → Create → TLS Certificate and enter a name and an invalid certificate.
   • Assert the Create button is disabled and the validation.pemCertificate message shows after blur.
   • Paste a valid certificate and key, then assert the button is enabled and the secret saves.
3. e2e: SSH Key secret. Enter an invalid public key such as opa, assert Create is disabled, then fix the key and assert it is enabled.
4. unit: other secret types and name rules.
   • Add coverage for the namespace rules (dnsLabel, noUpperCase) and the new subDomain name rule on CruSecret. For example, My_Secret should block Create.
   • Confirm basic-auth and registry secrets do not regress, so valid input still lets Create proceed.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

Decision: is_automatable: true · automation_sufficient: false · manual_test: true

What is already covered (PR #19203)

• The root cause, found in the reproduction comment, is that every update to the namespace or its project rebuilt defineAsyncComponent(...) inside the computed in identifying-fields.ts. That remounted ResourcePopover and closed the card. The fix hoists a single markRaw(defineAsyncComponent(...)).
• unit: shell/components/Resource/Detail/Metadata/IdentifyingInformation/__tests__/identifying-fields.test.ts
  • useNamespace: should keep the same ResourcePopover component when the resource updates. Props such as detailLocation update while the component identity stays the same.
  • useProject: should keep the same ResourcePopover component when the project updates. value updates to the new project name while the component identity stays the same.

These tests check an implementation detail (component identity). They do not check the behaviour the user sees, which is that the card stays open.

Suggested tests

1. unit: popover stays open across a resource update.
   • Mount IdentifyingInformation (or the namespace detail Masthead) with a reactive namespace in a project.
   • Open the project popover by triggering mouseenter on the PopoverCard target.
   • Update the reactive resource, for example change an annotation or replace project with a new object that has the same id.
   • After nextTick and flushPromises, assert the popover content and its action menu button are still rendered.
2. e2e: namespace detail popover survives live updates.
   • In cypress/, visit a namespace detail page in a project and hover the project name ([data-testid="masthead-subheader-project"]).
   • Push a websocket or resource update for that namespace, for example a PATCH to an annotation via cy.createRancherResource / cy.setRancherResource, or the existing websocket stubs.
   • Assert the popover card stays visible and that its action menu can be opened and clicked.
3. e2e (optional): the same check for the namespace popover that useNamespace creates on namespaced resource detail pages.

Why manual testing is still needed: the bug is hover behaviour that depends on timing (flicker, then trying to reach the ⋮ menu), was reported on Chrome, Brave and Firefox, and is only reproducible while the resource is being updated. Use the reproduction YAML from the issue comments, which patches the namespace every 2s, to confirm the card stays open and the menu can be used.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

Decision: is_automatable: true · automation_sufficient: false · manual_test: true

Evidence reviewed — PR #18912 (merged)

• Unit (Jest), extensive:
  • shell/pages/c/_cluster/explorer/workload-dashboard/search/__tests__/useWorkloadSearch.test.ts: debounce, minimum 3 characters, transient/unwatched findPage calls, partial metadata.name filter, namespace scoping, skips for missing schema or no list permission, grouping, totals, the "+ X more" row, error rows, and dropping stale responses.
  • .../search/__tests__/WorkloadSearch.test.ts: row rendering, namespace and action-menu clicks, Tab/Shift+Tab/Escape focus handling, whitespace stripping, keeping the dropdown open, and the empty-state messages.
  • .../workload-dashboard/__tests__/index.test.ts, composable.test.ts (nameFilter route, navigateToNamespace) and namespaceFilter.test.ts.
  • shell/components/form/__tests__/LabeledSelect.test.ts (visibleRows, forceOpen/forceClose), RcDropdown.test.ts, RcDropdownMenu.test.ts and ActionMenuShell.test.ts (container teleport).
  • shell/utils/table-views/__tests__/table-views.test.ts (queryFor with a name).
• E2E (Cypress): none. Every test above mocks the store, router and LabeledSelect, so nothing exercises the real browser flow against a Steve/vai backend.

Why it is not yet sufficient: this is a headline feature. Its main user flow is: type in the Overview search, get grouped server-side results, then go to a detail page, a namespace-filtered list, or a nameFilter list. That flow crosses several pages and depends on real vai partial-match filtering, and no automated test covers it end to end.

Suggested tests

1. e2e — cypress/e2e/tests/pages/explorer2/workloads/workload-dashboard-search.spec.ts: create a deployment and a pod with a shared prefix, such as qa-search-*. Type 2 characters and assert the "Type at least 3 characters" prompt. Type the prefix and assert the Deployments and Pods group headers appear with the correct totals, and that each row shows the name, namespace and age.
2. e2e — click a result row and assert you land on that workload's detail page.
3. e2e — click the namespace link on a result. Assert the header namespace filter changes to that namespace and the list for that resource type opens.
4. e2e — create more than 7 matching workloads of one type. Assert a + N more … row appears, and that clicking it opens the type's list with ?nameFilter=<term> and a name:<term> table-view query showing only matches.
5. e2e — change the header namespace filter to a namespace with no matches. Assert "No matching workloads" appears, which shows search respects the header filter.
6. e2e — open a result's action menu. Assert it renders outside the dropdown (not clipped), that the results stay open, and that running an action (e.g. Edit Config) closes the dropdown.
7. e2e (RBAC) — as a standard user who can only list some workload types, assert the types they cannot list never appear as groups. Intercept one type's findPage call with a 500 and assert a "Failed to fetch …" row appears while the other groups still render.

Why manual testing is required: this is a headline feature with heavy UX and interaction behaviour: keyboard focus loops, the dropdown fitting the viewport, teleported action menus and fast typing. It also changes shared components (LabeledSelect, RcDropdown, RcButton, table-view query params) that many pages depend on. QA has already asked for a manual round in the comments.

Residual risk to monitor: dropdown regressions elsewhere in the app from the LabeledSelect input-click and dropdown-alignment changes and the new <Teleport> wrapper in RcDropdown.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Decision: is_automatable: true · automation_sufficient: true · manual_test: true

Rationale: PR #19573 (merged) adds unit coverage for each piece of the new etcd snapshot configuration for imported clusters, plus Cypress coverage for when the sections and banner appear. Manual testing is still needed for the parts CI cannot reach: real downstream snapshot behaviour, real S3 buckets and credentials, and imported clusters that are still registering.

Test evidence found

• Unit
  • pkg/imported/components/__tests__/CruImported.test.ts (+580 lines):
    • The Day 2 Operations section is shown or hidden for: feature flag off, local cluster, no rke2Config/k3sConfig, RKE1, and import.
    • Etcd changes are written to both rke2Config.etcd and k3sConfig.etcd and saved.
    • With day 2 ops disabled, the etcd config is unset on save, using replace: true only when the cluster already had one.
    • S3 validation works while sections are collapsed (bucket, the credential's default bucket, endpoint format), and saving is blocked while the config is invalid.
    • Fetch handles empty or zero-value etcd configs and loads the cloud credential.
    • The configure-after-import banner wording covers both global settings, including when they agree and when they differ.
  • shell/edit/provisioning.cattle.io.cluster/tabs/etcd/__tests__/EtcdSnapshotConfig.test.ts, RcEtcdSnapshotConfig.test.ts and RcS3Config.test.ts:
    • The form emits a new object without mutating value.
    • Turning snapshots off or S3 off clears S3 and reports the form as valid.
    • An existing S3 config is kept when S3 is re-enabled.
    • Unset values fall back to placeholders, retention handling works, and the credential's default bucket is accepted.
  • .../tabs/etcd/__tests__/index.test.ts: checks the v2prov etcd tab now delegates to the shared form (regression guard), including etcd-expose-metrics.
  • pkg/imported/components/__tests__/Basics.test.ts and DayTwoOps.test.ts are updated for the restructure.
• E2E
  • cypress/e2e/tests/pages/manager/cluster-manager.spec.ts, Imported suite:
    • On import, version management and Day 2 Ops are hidden and the configure-after-import banner text matches the real global settings.
    • On edit of a registered K3s cluster, both sections and etcd-automatic-backups are shown.
    • The local cluster section order is updated.
  • New page-object helpers: cluster-edit.po.ts and cluster-import-generic.po.ts.

Why manual testing is recommended:

• Imported-cluster Day 2 Ops is high-impact provisioning functionality.
• Whether snapshots actually run on the new schedule, and whether they reach a real S3 bucket, can only be checked against a live downstream cluster and real cloud credentials. The PR author also could not verify the S3 upload.
• The v2prov etcd tab was refactored and needs a quick regression pass.

Residual risk to monitor

• Clusters with the version-management annotation but no rke2Config/k3sConfig no longer show the version management section. This is an intentional behaviour change; confirm it is acceptable.
• The Cypress run reports the day-2-ops feature as enabled via an intercept, so the real backend toggle path is not exercised in CI.
• A good next e2e addition would intercept the cluster PUT, change the cron schedule and retention, and assert the rke2Config.etcd payload.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Decision: is_automatable: true · automation_sufficient: true · manual_test: true

Rationale: PR #18497 (merged) moves nav highlighting into a shared helper, isNavItemActive/navItemClaimsRoute in shell/utils/router.js. Nav items can now claim resources through navResources. Unit tests cover the success and failure cases for both the nav item highlight and keeping the group expanded.

Test evidence found (unit)

• shell/utils/__tests__/router.test.js:
  • navItemClaimsRoute: 7 cases, covering a claimed param, a resource from meta, an unclaimed resource, no resource, no navResources, no nav item and no route.
  • isNavItemActive: 10 cases, covering its own route, nested create and detail pages, sibling routes, partial-segment non-matches, exact vs non-exact items, case-insensitive meta.nav, a navResources claim, and an item with no route.
• shell/components/nav/__tests__/Group.test.ts: the group stays expanded on the management.cattle.io.project/create route (the reported Projects bug), does not expand for an unclaimed resource, and stays open on Providers /create pages but not on siblings.
• shell/components/nav/__tests__/Type.test.ts: the active class is applied for nested routes and claimed navResources, and not for siblings, exact items, or types with no claims.
• E2E: none.

Why manual testing is recommended:

• QA has already asked for a manual round in the comments.
• Side-nav highlighting depends on navigating across several pages. The Cluster and Project Members create route is enabled only through navResources config (CRTB/PRTB) in shell/config/product/explorer.js, which has no dedicated test.
• kontainerDriver/nodeDriver changed from exact: true to exact: false, which affects highlighting in Cluster Management.

Residual risk to monitor

• Other nav items now evaluated by the shared isNavItemActive could gain or lose highlighting, because the old Type.vue logic was replaced.
• Check the side nav when creating or editing Projects/Namespaces, Cluster/Project Members, Namespaces, and Cluster Drivers/Node Drivers.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Decision: is_automatable: true · automation_sufficient: true · manual_test: true

Rationale: PR #18512 (merged) moves namespace "select or create" into new reusable components, LabeledSelectWithCreate.vue and NamespaceSelect.vue, and switches NameNsDescription.vue to use them. Both new components have direct unit tests, and an existing e2e flow now drives the "Create a new Namespace" path through the new component.

Test evidence found

• Unit
  • shell/components/form/__tests__/LabeledSelectWithCreate.test.ts (new, 300 lines):
    • The "create new" option and divider are added, and hidden when createAllowed=false.
    • Props pass through, and the __create__ sentinel value is never emitted.
    • Selecting create switches to an input and emits an empty value.
    • Typing emits on each keystroke, and cancel via the button or Escape returns to the select with the value cleared.
  • shell/components/form/__tests__/NamespaceSelect.test.ts (new):
    • Disabled when forceNamespace is set, in edit mode, or with the disabled prop.
    • override/options lists replace the store namespaces.
    • A namespace being created still appears as an option.
    • The cru-resource/setCreateNamespace dispatch and the isNamespaceNew event happen at the right times, and cancel resets to the default namespace.
  • shell/components/form/__tests__/NameNsDescription.test.ts (rewritten): disabled-state calculations, hiding parts of the form, custom keys, and forceNamespace being saved to the value on mount.
• E2E
  • cypress/e2e/tests/pages/explorer2/workloads/jobs.spec.ts: creates a Job in a new namespace through selectCreateNew('Create a new Namespace').
  • cypress/e2e/tests/pages/explorer/service-discovery/ingress.spec.ts: selects an existing namespace through the new component.
  • New page object: cypress/e2e/po/components/labeled-select-with-create.po.ts.

Why manual testing is recommended: the issue says QA mainly needs a regression pass. NameNsDescription is used on almost every create form (workloads, chart install, secrets, configmaps, and more). Moving the namespace logic out is a significant regression risk for those core create flows, especially chart installs where a namespace is forced, and RBAC-limited users who cannot create namespaces.

Residual risk to monitor

• Chart install with forceNamespace set.
• A standard user without namespace create permission must not see the "Create a new Namespace" option.
• Edit mode: the namespace should be disabled.
• The isNamespaceNew event is now emitted only when its value changes, which differs from the previous behaviour. Confirm parent forms that rely on it, such as workload create, still create the namespace on save.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

No manual tests required. Automated tests are not yet sufficient for this issue. Please address the feedback from the QA Review Decision Model:

Decision: is_automatable: true · automation_sufficient: false · manual_test: false

Evidence reviewed — PR #18776 (merged)

• Unit:
  • pkg/rancher-components/src/components/Layout/RcContentGroup/RcContentGroup.test.ts: renders the wrapper class, nests one or several children, and is re-exported from the index.
  • pkg/rancher-components/src/components/Pill/RcCounterBadge/RcCounterBadge.test.ts:
    • ariaLabel is applied, and a warning appears when status is set without one.
    • Colours resolve in order: type → status (warning/error) → full or partial override, plus disabled colours and the hover border.
  • pkg/rancher-components/src/components/RcSection/RcSection.test.ts: the default slot renders content, nothing renders when collapsed, several RcContentGroups render as siblings, and the counter slot gets its own element.
• E2E: none. Fleet spacing was only checked by screenshots in the PR.

Why it is not yet sufficient: the main bug is acceptance criterion 1: in light mode, the counter badge in a secondary section header should default to white. The PR fixes it with a CSS custom property (--rc-counter-badge-inactive-background) set only in secondary headers. The new RcSection "counter badge colour" tests only check that a .counter element exists, so nothing asserts that a secondary header gives the badge a different fill than a primary one. The colour tests also note that v-bind() CSS is not evaluated in jsdom, so this default fill is untested.

Suggested tests

1. unit — in RcSection.test.ts, mount with background: 'secondary' and a counter slot. Assert the header's .counter element (or its inline style or class) sets --rc-counter-badge-inactive-background to the white or primary-section token. Then mount with background: 'primary' and assert the property is not set, so the primary header keeps the grey badge.
2. unit — mount a real RcCounterBadge (type inactive) inside a secondary RcSection, and in a second case pass status="error" or an explicit backgroundColor. Assert the badge's resolved backgroundColor uses the inherited variable by default, and that status or the override wins over the section default (criterion 1: "allow a full override").
3. unit — for criterion 2, mount RcSection with two RcContentGroup children that each hold two form elements. Assert .section-content contains exactly two .rc-content-group children and the form elements stay inside their own group, with no wrapper div needed.
4. e2e (optional, low cost) — on the Fleet App Bundle / HelmOp AppCo edit page that dropped its hand-written wrapper divs (FleetClusterTargets, HelmOpAppCoConfigTab), assert the section content renders inside .rc-content-group and the existing fields stay visible. This guards the spacing refactor.

Why manual testing is not required: this is an isolated component-library change with low product risk. The author says it can be checked visually in Storybook, so no full manual round is needed once the tests above are added.

Residual risk: the default slot now renders as one 16px group rather than children spaced 24px apart. Any product RcSection that passes several children directly will tighten its spacing.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

Decision: is_automatable: true · automation_sufficient: false · manual_test: true

Evidence reviewed — PR #18858 (merged)

• Production changes:
  • shell/pages/c/_cluster/explorer/index.vue: adds schedulableWorkerNodes/schedulableNodes and a new workerStatsAggregation. cpuReserved, ramReserved, podsUsed, cpuUsed, ramUsed and the metricAggregations node filter are rewritten.
  • shell/models/cluster/node.js: adds cpuAllocatable, ramAllocatable, systemReservedCpu/systemReservedRam and isSchedulable. cpuCapacity and ramReserved change meaning (ramReserved now comes from podRequests).
• Test changes: only shell/detail/__tests__/node.test.ts, where two mock property names were renamed (cpuCapacity→cpuAllocatable, ramReserved→ramAllocatable).
• No test checks the corrected calculation. Nothing confirms that usage and capacity now use the same set of nodes, or that the result stays under 100%.

Suggested tests

1. unit — shell/pages/c/_cluster/explorer/__tests__/index.test.ts, metricAggregations/ramUsed/cpuUsed: mock 4 nodes, matching the issue's repro:

   • a tainted control-plane node that is not a worker
   • a cordoned worker
   • 2 schedulable workers

   Give all four node metrics. Assert that only the 2 schedulable workers' usage is summed, that total is the sum of those workers' allocatable, and that the resulting percentage is ≤ 100%. Use the issue's numbers to assert the 6.25 / 7.73 GiB case no longer happens.

2. unit — same file, fallback path: with no schedulable worker nodes (an imported cluster without node-role.kubernetes.io/worker labels, the #16863 regression), assert cpuUsed/ramUsed/cpuReserved/podsUsed fall back to currentCluster.status.allocatable/requested, and that usage is summed over all schedulable nodes rather than coming out as zero.

3. unit — same file: assert cpuUsed/ramUsed return null when metricAggregations is unavailable. Assert hasStats is true when there are schedulable workers, and false when cluster allocatable.cpu is '0' and there are no workers.

4. unit — shell/models/cluster/__tests__/node.test.ts: test the new getters:

   • cpuAllocatable/ramAllocatable read status.allocatable.
   • cpuCapacity reads status.capacity, and missing values default to '0' instead of NaN.
   • cpuReserved/ramReserved/podReserved come from podRequests.
   • systemReservedCpu/systemReservedRam clamp to 0 when capacity is less than allocatable.
   • isSchedulable is the inverse of spec.unschedulable.
   • cpuUsagePercentage divides by allocatable.

5. unit — same model test: assert the subtraction metricAggregations.memory - systemReservedRam used in ramUsed can never produce a negative "used" value (e.g. low usage with a large system-reserved amount). If it can, clamp it.

6. e2e — cypress/e2e/tests/pages/explorer/dashboard/cluster-dashboard.spec.ts: intercept /v1/nodes and /v1/metrics.k8s.io.nodemetrics with a fixture containing a tainted control-plane node and a cordoned worker. Assert the Memory and CPU "Used" gauge text shows the worker-only used/total values and a percentage ≤ 100%.

Why manual testing is required: this is a customer-reported JIRA bug in a high-visibility dashboard figure. A real reproduction needs real node metrics, taints, cordoned nodes and load. The maintainer explicitly asked for a QA pass before backporting to 2.14/2.15. The calculation also changed for every gauge on the page (CPU/Memory Reserved, Pods, Used), so it needs a regression check on RKE2, K3s, imported clusters without worker labels, and single-node all-role clusters.

Residual risk to monitor: the "Reserved" gauges now come from summed per-node podRequests instead of cluster.status.requested. Imported clusters with no worker-labelled nodes go through the fallback path.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Decision: is_automatable: true · automation_sufficient: true · manual_test: true

Rationale: PR #19389 (merged) implements the UX decision from the comments: when the registration state cannot be read, the page becomes read-only and shows the message "This user does not have permission to read secrets and registration." The unit tests cover the new permission checks, the forbidden state, and the disabled actions.

Test evidence found (unit)

• pkg/rancher-prime/pages/registration.composable.test.ts, new suite "when the user cannot read the registration":
  • The page is blocked when the secret or scc.cattle.io.registration schema is missing.
  • It is blocked when looking up the secret by id returns 403, and allowed when it returns 404 (the 403 vs 404 distinction).
  • The by-id lookup is skipped when the secret is already listed.
  • In the forbidden state, the status shows Unknown (not Unregistered) and registrationStatus is null, a warning banner shows the forbidden message, and no registration errors are reported.
• pkg/rancher-prime/pages/Registration.test.ts, "given a user who cannot read the registration":
  • The banner text and the unknown badge are shown.
  • All actions are disabled: the code input, online register, offline download, visit SCC, offline register and deregister.
  • Online register stays disabled even after a code is entered.
• pkg/rancher-prime/index.test.ts: the "register" notification is removed and never added when the user cannot read the registration.
• E2E: none.

Why manual testing is recommended:

• This is a Prime / SCC registration flow (area/scc, JIRA SURE-11884) that depends on RBAC.
• Reproducing it needs a real backend-registered system and a custom global role like hosted-admin, which are hard to set up reliably in CI.
• The fix relies on Steve hiding schemas and on 403 responses from the real API. Mocks may not match those behaviours exactly.

Residual risk to monitor

• The issue also reported that the Register button stays stuck on "Registering" after a 409 (registerOnline has no try/catch, per the comments). PR #19389 avoids this for read-restricted users by disabling the button, but does not change the error handling in registerOnline. Other failure paths may still leave the button stuck.
• Also check that admins and users with full access still see the correct Active/Unregistered state.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Decision: is_automatable: true · automation_sufficient: true · manual_test: true

Rationale: this is dead-code removal. PR #18773 (merged; it references Fixes #18224 #18772 in its body but is not formally linked to this issue) removes:

• the LEGACY feature flag
• the legacy and multi-cluster app detection and blocking screen in chart install/upgrade
• the RKE2 legacy warning banner
• the unsupported in-tree Azure cloud provider logic

The affected unit tests were updated or removed to match, and new coverage was added where behaviour remains. For a removal, tests that only assert something is absent add little value. The remaining risk is regressions in critical flows, which is why manual testing is recommended.

Test evidence found (unit)

• shell/store/__tests__/features.test.ts: the LEGACY default-value case is replaced with UNSUPPORTED_STORAGE_DRIVERS, matching acceptance criterion 1 (flag removed).
• shell/pages/c/_cluster/apps/charts/__tests__/install.test.ts: mocks for an existing app no longer need deployedAsLegacy/deployedAsMultiCluster, and the existing fetch and pull-secret tests still pass with an existing release. This covers acceptance criterion 2 (multi-cluster app checks removed).
• shell/edit/provisioning.cattle.io.cluster/__tests__/rke2.test.ts: a new test checks the azure cloud provider option is filtered out while amazon stays. The obsolete isAzureProviderUnsupported/canAzureMigrateOnEdit and version-filter cases were removed.
• shell/edit/provisioning.cattle.io.cluster/__tests__/Basics.test.ts: Azure warning and disabled-provider cases were removed, along with the props and banners they tested (acceptance criterion 3: legacy banner removed).
• E2E: none.

Why manual testing is recommended: the changes affect two critical user flows with high regression risk.

• Apps & Marketplace: the install page template changed from v-else-if="!legacyApp && !mcapp" to v-else, and the pre-checks in fetch() were removed. Install a new chart, upgrade an existing app, and open the install page by URL query.
• RKE2/K3s provisioning: the Basics tab and the cloud provider dropdown changed. Azure must no longer appear, the provider select must not be force-disabled in edit mode, and the version list must not be filtered by provider.

The PR lists 11 specific manual scenarios.

Residual risk to monitor

• Clusters still configured with cloud-provider-name: azure will no longer find that option in the dropdown on edit. Check how the select displays an existing azure value.
• Confirm that a backend still reporting the legacy feature flag does not break the Feature Flags page.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

Decision: is_automatable: true · automation_sufficient: false · manual_test: true

Evidence reviewed — PR #18786 (merged)

• Unit:
  • shell/components/auth/__tests__/Principal.test.ts, "given the principal fetch fails (user-based fallback)":
    • A principal is built from the matching management.cattle.io.user.
    • The provider comes from the principal id rather than the aggregated user.provider (github multi-principal regression).
    • The name comes from displayName, falling back to nameDisplay.
    • No principal is built when users are not loaded or no user matches.
  • shell/models/__tests__/principal.test.ts (new): avatarSrc uses the GitHub picture when one is set, and falls back to an identicon for GitHub principals without a picture and for other providers.
• E2E: none.

Why it is not yet sufficient: the fallback only works if the page has already loaded management.cattle.io.user into the store. loadPrincipalFromUser returns null when management/typeRegistered(USER) is false, and the code comment says ExplorerMembers is expected to load these users. PR #18786 does not change or test the Cluster/Project Members page, so nothing confirms that a User-Base user with the user manager role actually has users loaded there. That is the issue's acceptance scenario.

Suggested tests

1. unit — the Cluster and Project Members page (shell/list/explorer/__tests__/ExplorerMembers.test.ts or wherever the members list lives): assert it dispatches management/findAll (or the paginated equivalent) for management.cattle.io.user when the user can list users. Assert it skips that call without throwing when the user cannot.
2. unit — Principal.test.ts: when the direct rancher/find succeeds, assert loadPrincipalFromUser is not used (no rancher/create dispatch). Also assert console.error('Failed to fetch principal') is only logged when both lookups fail.
3. e2e — cypress/e2e/tests/pages/explorer/cluster-project-members.spec.ts:
   • Create a standard User-Base user with the user manager global role and make them cluster owner of local.
   • Log in as that user and intercept GET /v3/principals/* with a 403.
   • Open Cluster and Project Members and assert the other local users' display names appear, not raw u-xxxxx ids.
4. e2e — same spec: assert that a member whose principal belongs to an external provider (not in the local user list) still renders a fallback row without crashing. This is the documented limitation; see #18795.

Why manual testing is required: this is a customer-reported, RBAC-dependent JIRA bug (SURE-9020). Verifying it needs a real User-Base user with a specific global role and cluster ownership. The fix only covers local users, so external-provider members need a human check that they render acceptably.

Residual risk to monitor: Principal.vue is shared across many screens. The new fallback only applies where users are already loaded, but the avatarSrc change in shell/models/principal.js affects every GitHub principal without a profile picture.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Decision: automatable = true · automation sufficient = true · manual test = true

Rationale The fix in #19535 is limited to shell/components/auth/Principal.vue, which renders unresolved principals. Its unit tests cover the agreed design from the 2026-08-18 comment: a generic icon instead of the warning, a readable principal ID, and the error moved into a tooltip.

Test evidence: unit, shell/components/auth/__tests__/Principal.test.ts (#19535)

• it.each checks the readable ID format: github_team://8087745 → github_team 8087745, github_user://…, okta_user://test, and a plain u-abc123 ID.
• The raw principal ID (://) is never rendered.
• A question-mark RcIcon replaces the avatar, and it is ariaHidden (a11y).
• There is no .text-error and no .icon-warning. The old red error state is gone.
• An RcIconTooltip with principal.unresolved content sits next to the name, spaced with ml-5.
• Edge case: an empty principal ID falls back to principal.error, shows no info icon and still shows the question mark.
• Negative case: no tooltip appears once the principal is resolved from a matching user.
• A regression test checks that fetch now awaits loadData while the lookup is in flight.

Why manual testing is recommended

• The behaviour depends heavily on UX. Design feedback was still open in the latest comments: "Keep the info icon, or hide it?" and "Does the question mark work in place of the avatar?".
• The original report (SURE-7899) involves real AD and external-provider principals that cannot be resolved for a local admin. The unit tests mock the store lookup, not a live provider.
• The card appears in several places (Cluster/Project Membership lists, member editors) and in both light and dark themes.

Residual risk to monitor

• How it renders in each list or editor that embeds Principal.vue. Extensions built with an older shell bundle their own copy and will still show the old error.
• Whether the tooltip text reads correctly once vendor branding is applied.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. No manual tests required.

Decision: automatable = true · automation sufficient = true · manual test = false

Rationale #19090 fixes the blank YAML tab by turning off YAML viewing for cloud credentials. These are Norman resources and never expose a view link, so the YAML tab could only ever render blank. The PR also makes the generic drawer and detail page fall back to the resource's own canYaml. Both the specific fix and the generic guard are covered by unit and e2e tests.

Test evidence

• e2e, cypress/e2e/tests/pages/manager/cloud-credential.spec.ts: creates a cloud credential, opens its detail view and asserts that show-configuration-cta does not exist.
• e2e, cypress/e2e/tests/pages/manager/kubeconfig.spec.ts (new, with new page objects kubeconfig.po.ts and kubeconfig-list.po.ts): a regression guard for a type that has canYaml: false in the type-map but does have a real view link. It asserts that "Show Configuration" opens the drawer and the YAML tab is not empty.
• unit, shell/components/Drawer/ResourceDetailDrawer/__tests__/composables.test.ts:
  • YAML is fetched when canYaml is true.
  • Nothing is fetched and undefined is returned when canYaml is false.
  • Failure paths: a throwing canYaml getter and a rejected getYaml both return undefined instead of throwing.
• unit, shell/components/ResourceDetail/__tests__/index.test.ts (canViewYaml):
  • Live canYaml: false narrows the type default to false.
  • Live canYaml: true keeps the default.
  • A type-map opt-out is never overridden.
  • A throwing getter hides the toggle without failing the page load.
• unit, shell/models/__tests__/cloudcredential.test.ts: checks disableResourceDetailDrawer is true, plus a side fix to doneRoute.

Why manual testing is not required The user-visible outcome is binary (the option is shown or hidden) and is asserted end to end. Error and edge paths are unit tested. The risk to UX and navigation is low.

Residual risk to monitor

• The new generic ResourceDetail fallback hides the YAML toggle for any resource whose live model has no view link. Watch for reports of YAML views disappearing on other Norman-backed detail pages.
• If YAML support for cloud credentials is wanted in future, that needs a separate change.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Decision: automatable = true · automation sufficient = true · manual test = true

Rationale #19564 rewrites the restore dialog (shell/components/PromptRestore.vue → shell/dialog/PromptRestore.vue, now an RcModal opened through promptModal). It adds restore-mode handling for imported clusters with day 2 ops. Both acceptance criteria are asserted directly by unit tests.

Test evidence (unit)

• shell/dialog/__tests__/PromptRestore.test.ts (new, about 600 lines):
  • AC 1, Date section removed: "should not render a date section" checks the body headings are only name and restoreMode.label and that no Date formatter is rendered.
  • AC 2, etcd-only when version management is off: restoreModeOptions is ['none'] for an imported cluster with version management disabled, and all three modes are offered for RKE2 or version-managed imported clusters. The default mode is all or none accordingly. kubernetesVersion and all are never sent in the operation CR when version management is off.
  • The etcdsnapshot.rke.io/restore-mode-options annotation is filtered. Tests cover whitespace and empty entries, unknown modes, the fallback to none, and resetting the selection when the selected snapshot changes.
  • The RKE2 path still sets etcdSnapshotRestore.restoreRKEConfig for each mode.
  • Failure path: a 403 on operation CR creation shows an error banner with role="alert", no success growl, and the dialog stays open.
  • Modal behaviour: the dialog renders only when show is set, Cancel calls the owner's onClose, Restore is disabled with no snapshot, and the dialog closes after a successful restore.
• shell/models/__tests__/management.cattle.io.cluster.test.ts: a 12-case matrix for isVersionManagementEnabled (annotation × global setting).
• shell/models/__tests__/rke.cattle.io.etcdsnapshot.test.ts (new): restoreEnabled and isSnapshotTooOld, including imported snapshots resolved through the management cluster namespace.
• shell/plugins/steve/__tests__/actions.test.ts: promptRestore dispatches promptModal with component: 'PromptRestore' and ownsModal: true.

Why manual testing is recommended

• Etcd snapshot restore is a destructive, high-impact operation on real clusters. The tests mock createOperationCR and cluster.save, so the backend side (rancher/rancher#56077) is not exercised.
• The way the dialog is opened changed: it moved out of templates/default.vue and the action-menu store into promptModal. That affects every restore entry point (cluster action menu, snapshot list row action, RKE2 and imported clusters) and spans several pages.

Residual risk to monitor

• Make sure snapshots that do not carry the restore-mode-options annotation from the backend fall back correctly.
• Confirm restore still works on standard RKE2/K3s provisioned clusters, since the dialog is shared.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Decision: automatable = true · automation sufficient = true · manual test = true

Rationale #19324 adds the release welcome modal with both e2e and unit coverage. The tests follow the agreed behaviour from the 2026-10-16 decisions comment: the modal opens instantly with a loader and lazy-loaded content, shows only on first load or a newer minor version, matches the version pair strictly, and reuses the notification-centre version check.

Test evidence

• e2e, cypress/e2e/tests/pages/generic/release-welcome.spec.ts (new; tags @adminUser and @standardUser), with page object cypress/e2e/po/components/release-welcome-dialog.po.ts:
  • Shown once per minor release. Closing persists read-whatsnew = "v2.16.0", the modal is not shown on the next visit, and the release-notes notification is marked read.
  • Content from the dynamic content endpoint (**/first-run) replaces the built-in features and the Prime promo (title, products, CTA link).
  • Loading state: with a delayed response the modal opens straight away showing the loader, then the content appears.
  • Strict version matching: an entry for 2.16.1 only falls back to the built-in content and shows the version badge 2.16.
  • After a patch upgrade the modal is not shown and the release-notes notification is unread.
  • Focus lands on the close button. The modal reappears on reload until it is closed. It can be reopened from the user menu ("What's New") and closed with Esc.
• Unit, shell/components/ReleaseWelcome/__tests__/:
  • PrimeCard.test.ts: theme classes.
  • PrimePromoCard.test.ts: built-in versus dynamic content, product list, CTA href and target, aria-labelledby.
  • PrimeRegistrationCard.test.ts: benefits list, support handbook link, SCC link, dynamic content, and icons hidden from screen readers.
• Test infrastructure: cypress/support/e2e.ts marks the modal as read for all other specs, so it doesn't cover the page in unrelated tests. user-menu.po.ts now expects four menu items.

Why manual testing is recommended

• The issue is labelled headline, so product impact is large and it is the first thing every user sees after an upgrade.
• The behaviour depends heavily on UX and design (the Figma design, the Community and Prime variants, the Prime surface theme, custom branding through the existing brand logo).
• The e2e suite mocks RancherPrime: 'false'. The Prime variant (subtitle, registration card) is only covered at the component level, not end to end.
• The S3-hosted dynamic content endpoint (rancher/ui-dynamic-content) is mocked in every test.

Residual risk to monitor

• The global hideReleaseWelcome intercept in cypress/support/e2e.ts could hide regressions in specs that rely on /v1/userpreferences.
• Behaviour for users who stay logged in across an upgrade (shown on reload, not on login), which was raised as an open question in the comments.
• Air-gapped installs where the dynamic content endpoint can't be reached should fall back to the built-in content.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Decision: automatable = true · automation sufficient = true · manual test = true

Rationale #18979 moves the Kubernetes version and PSA logic out of rke2.vue into shell/composables/useKubernetesVersions.ts and usePodSecurityAdmissionTemplates.ts. The characterization tests that had been written against the rke2.vue computed properties and methods were ported to the composables and extended. The component tests were updated so they still run through the composable-backed rke2Versions and selectedVersion watchers. That gives evidence for both the extracted logic and its wiring.

Test evidence (unit)

• shell/composables/useKubernetesVersions.test.ts (new):
  • versionOptions: RKE2 and K3s grouping, RKE2 only, K3s excluded in edit mode, deprecated patch filtering on and off.
  • selectedVersion, including the cni option none being added only once.
  • chartVersions, serverArgs and agentArgs, with empty fallbacks.
  • fetchK8sVersions:
    • cached data is not re-fetched, and a partial load (one distro still null) is retried
    • defaults come from settings, falling back to the channel's latest
    • failure paths: a "No version info found in KDM" error is recorded instead of thrown, and a failure in one request keeps the data from the others
    • a failed request is retried on the next call
  • getDefaultVersion: preferred version, first-option fallback, and the Harvester-compatible paths.
• shell/composables/usePodSecurityAdmissionTemplates.test.ts (new): fetch when the user can list, skip when they can't, an error is recorded on failure, and errors are cleared on each fetch.
• shell/edit/provisioning.cattle.io.cluster/__tests__/rke2.test.ts: the ingress-controller default (Traefik), handleKubernetesChange, handleEnabledSystemServicesChanged and applyChartValues now run against the composable-owned rke2Versions. This confirms the component is still wired correctly.

Why manual testing is recommended

• The issue itself says "it needs to be tested for regressions". This is a refactor of the core RKE2/K3s provisioning form, which carries major regression risk, and parent epic #17825 continues refactoring the same file.
• There is one intentional behaviour change: KDM and version fetch failures now appear as form errors instead of failing the whole page. That should be checked in the UI.
• Version selection affects many parts of the form (Basics, CNI, addons, chart values, Harvester defaults) across create and edit flows.

Residual risk to monitor

• Edit and upgrade flows on existing clusters, and the "show deprecated patch versions" toggle.
• Creating clusters through the Harvester driver with the default version selected.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

What is already covered: #19267 moved the registry characterization tests from rke2.test.ts into shell/composables/useRegistryConfig.test.ts, which is unit level. They cover initRegistry (precedence, empty init, existing auth secret, mirrors), setRegistryConfig (override cleared, set or removed, rkeConfig created or merged), updateConfigs, and the input handlers or toggle. The logic itself is well covered.

Gap: the registry tests were removed from rke2.test.ts and nothing replaced them at the component level. No test now shows that rke2.vue still wires useRegistryConfig(props) into its fetch, save and template. The refactor also changed where state is read, from the component's this.rkeConfig / this.agentConfig to props.value.spec.rkeConfig / props.value.agentConfig. That is exactly the kind of regression a test of the composable alone cannot catch.

Suggested tests

1. unit (shell/edit/provisioning.cattle.io.cluster/__tests__/rke2.test.ts), registry initialised on fetch. Mount rke2 with a value whose agentConfig['system-default-registry'] is cluster.registry.io and a mocked system-default-registry setting. After fetch, assert that wrapper.vm.registryHost is cluster.registry.io, showCustomRegistryInput is true, and value.spec.rkeConfig.registries has configs and mirrors.
2. unit (rke2.test.ts), registry applied on save. Set registryHost and registrySecret on the mounted component and run the save path (or the before-save hook that calls setRegistryConfig). Assert that value.agentConfig['system-default-registry'] and value.spec.rkeConfig.registries.configs[host].authConfigSecretName hold the expected values in the payload sent to the store.
3. unit (rke2.test.ts), Registries tab wiring. Mount the Registries tab and emit the change events for host, secret, the custom-registry toggle and the mirror config update from the child components. Assert that the composable state and value.spec.rkeConfig.registries.configs update, so the template-to-composable bindings are proven.
4. e2e (cypress/e2e/tests/pages/manager/ cluster create spec), registry in the create payload. Create a custom RKE2 cluster, enable a custom registry with a host and auth secret, intercept POST v1/provisioning.cattle.io.clusters, and assert that the request body contains spec.rkeConfig.registries.configs['<host>'].authConfigSecretName and agentConfig['system-default-registry']. Then edit the cluster and assert the Registries tab shows the saved host again.

Why manual testing is recommended: this is a refactor of the core RKE2 provisioning form, which carries major regression risk, and the issue says there should be no change in behaviour. Private registries are common in air-gapped production setups. A manual pass should create and edit a cluster with a system default registry, a cluster-scoped registry plus auth secret, and mirrors.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

What is already covered: #19357 adds shell/composables/useClusterMembership.test.ts at the unit level. It covers:

• canManageMembers: true and false, plus no throw when no store is injected
• onMembershipUpdate, which stages the update
• saveRoleBindings: a no-op without save, and it forwards the parent ID

CruEKS.test.ts, CruGKE.test.ts and CruImported.test.ts were only adjusted so they keep working with a component that has setup(). They do not assert anything about membership.

Gap: the refactor touches six cluster forms: RKE2, AKS, EKS, GKE, Imported and Harvester. Each now relies on the composable for membershipUpdate, canManageMembers and onMembershipUpdate, and keeps a forwarding saveRoleBindings method registered as an after-save hook. No test shows that, for any form, the membership change emitted by ClusterMembershipEditor is staged and then saved against the right cluster ID (normanCluster.id, or value.mgmt.id after waitForMgmt() for RKE2). The test changes also show that wrapper.vm reactivity behaves differently for components with setup(), which raises the risk of silent wiring bugs.

Suggested tests

1. unit (shell/edit/provisioning.cattle.io.cluster/__tests__/rke2.test.ts), RKE2 saves role bindings against the management cluster. Mount rke2 and emit membership-update from ClusterMembershipEditor with a save mock. Call saveRoleBindings() with value.waitForMgmt resolving and value.mgmt.id = 'c-m-abc'. Assert that save is called once with 'c-m-abc', after waitForMgmt.
2. unit (one each in pkg/aks/.../CruAks.test.ts, pkg/eks/.../CruEKS.test.ts, pkg/gke/.../CruGKE.test.ts, pkg/imported/.../CruImported.test.ts), hosted and imported forms forward to normanCluster.id. Emit membership-update with a save mock, call saveRoleBindings(), and assert that save is called with normanCluster.id. Add a parameterised case asserting that saveRoleBindings is registered as the save-role-bindings after-save hook.
3. unit (pkg/harvester-manager/edit/__tests__/harvesterhci.io.management.cluster.test.ts), Harvester wiring. Assert that registerAfterHook is called with saveRoleBindings and 'save-role-bindings' in created(), and that a staged update is saved against normanCluster.id.
4. unit (any one form), membership editor visibility. With canViewClusterMembershipEditor mocked to false, assert that the Member Roles tab or ClusterMembershipEditor is not rendered. With it true, assert that it is rendered.
5. e2e (cypress/e2e/tests/pages/manager/ cluster create spec), a member is added when the cluster is created. Create a custom RKE2 cluster, add a standard user as a member in Member Roles, save, and intercept the clusterroletemplatebindings POST. Assert that it targets the new cluster's management ID with the chosen role.

Why manual testing is recommended: this refactor spans every cluster create and edit form (RKE2, AKS, EKS, GKE, Imported, Harvester) and carries major regression risk. Member assignment on create and edit is a security-relevant flow. A manual pass should add and remove a member on at least one RKE2, one hosted (AKS, EKS or GKE) and one imported cluster, and confirm the role bindings exist afterwards.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

Automated tests appear sufficient for this issue. No manual tests required.

Decision: automatable = true · automation sufficient = true · manual test = false

Rationale #19362 fixes both reported problems in shell/components/form/KeyValue.vue:

1. It splits the file on \r?\n and trims the key, so DOS line endings no longer leave carriage returns behind.
2. removeEmptyRows now reads the configured keyName/valueName instead of hard-coded key/value, which was the cause of the Cannot read properties of undefined (reading 'length') error.

The fix is a pure parsing change with clear inputs and outputs. That makes it a good fit for unit tests, and both problems are directly asserted.

Test evidence: unit, shell/components/form/__tests__/KeyValue.test.ts, suite onFileSelected with parseLinesFromFile The suite mounts the component with keyName: 'name', the same setup as Agent Environment Vars, so it reproduces the field-name bug.

• AC 1, carriage returns removed: it.each over Unix, DOS and mixed line endings and whitespace around keys. Each produces exactly [{FOO: bar}, {BAZ: qux}], with no stray \r.
• AC 2, import without errors and empty rows removed:
  • blank and whitespace-only lines are ignored for both Unix and DOS files, which is the exact reproduction case
  • existing empty rows are removed after parsing
  • FOO= keeps the key with an empty value and does not throw
• Edge cases:
  • everything after the first = is kept as the value (OPTS=a=b=c)
  • a line without = becomes a key with an empty value
  • whitespace inside values is kept, for both line-ending styles, matching kubectl --from-env-file

Why manual testing is not required The change is contained to one parsing method and the outcome (the parsed rows) is fully asserted, including the exact steps from the report. There is no complex UI interaction, no priority/0 label and no notable UX dependence.

Residual risk to monitor

• The tests check the parsed rows, not the generated node registration command string. If command generation adds its own formatting, an extra check there could help.
• KeyValue is shared widely, so watch for changes in other "Read from File" consumers. Values now keep leading and trailing whitespace, by design.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Decision: automatable = true · automation sufficient = true · manual test = true

Rationale #19378 turns on the existing SAML-plus-LDAP search UI for ADFS. In shell/edit/auth/ldap/config.vue, isSamlProvider now includes ADFS. The option is gated behind isRancherPrime() and the new adfs-ldap-search feature flag. The comment of 2026-09-25 confirms the API, objects and defaults are the same as for the Okta and Shibboleth providers that already support this. The UI-side gating and validation are well covered by unit tests.

Test evidence: unit, shell/edit/auth/__tests__/saml.test.ts

• supportsLDAPSearch computed: a 9-row matrix.
  • Shibboleth and Okta always return true.
  • ADFS returns true only when it is a Prime install and adfs-ldap-search is on. It is false for the other three combinations.
  • Keycloak, Ping and generic SAML stay false.
• Rendering: the LDAP option appears for ADFS on Prime with the flag on, and is not rendered on a community install.
• LDAP search validation:
  • Passes when all LDAP fields are filled.
  • Fails when any required field is empty (hostname, port, connection timeout, service account DN and password, user search base).
  • A certificate is required when TLS is on (fails without one, passes with one).
  • For ADFS, empty LDAP fields fail validation when the option is available and are ignored when it is not.

Why manual testing is recommended

• This is an integration with third-party identity providers (ADFS plus an LDAP directory). It cannot be meaningfully exercised in this repository's CI. The comment says "Collie QA to work with UI QA on how testing will be covered" and that the Collie QA contact will provide an environment.
• The feature is Prime-only and behind a feature flag, so the end-to-end check needs a Prime build with the flag enabled.
• Auth configuration is a security-sensitive flow. A real login with LDAP-backed user and group search needs to be confirmed.

Residual risk to monitor

• No test checks the saved payload. Confirm that openLdapConfig is persisted on the ADFS auth config and that user and group search then returns LDAP results.
• The layout of the TLS and StartTLS checkboxes changed in ldap/config.vue (.tls-options). That affects Okta, Shibboleth, OpenLDAP and FreeIPA as well, so do a quick visual check.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Decision: is_automatable: true · automation_sufficient: true · manual_test: true

Rationale PR #19153 switches the imported cluster create/edit form from Accordions to RcSection/RcContentGroup. It adds new Rc copies of KeyValue, Labels, LabelsAndAnnotations, PrivateRegistry, SelectOrCreateAuthSecret, SchedulingCustomization and ACE. It also updates both the e2e and unit tests that cover the form.

Test evidence (PR #19153)

• e2e: cypress/e2e/tests/pages/manager/cluster-manager.spec.ts
  • Asserts the exact order of the top-level section titles for generic import (Basics, Member Roles, Labels & Annotations, Registries, Advanced), imported-cluster edit (adds K3S Options, Networking) and local cluster edit. Also asserts that Networking is absent where it should be.
  • Table of contents: there is one top-level entry per section, and clicking Registries scrolls to that section and expands it.
  • The edit flow expands Networking and Registries through the new RcSectionPo.expand(), then sets ACE FQDN/CA certs and the private registry.
• e2e support: new cypress/e2e/po/components/rc-section.po.ts. cluster-create-import.po.ts and cluster-edit.po.ts now use sections instead of accordions.
• unit:
  • pkg/imported/components/__tests__/Basics.test.ts (new): the picked Kubernetes version and the deprecated-patches toggle survive a remount inside a collapsed section, and the toggle emits show-deprecated-patches-changed.
  • RcSection.test.ts: navigating from the table of contents expands a collapsed section, renders its content and scrolls to it. A non-expandable section is left unchanged.
  • DayTwoOps.test.ts: renders as an expandable secondary section.
  • CruImported.test.ts and versionManagement.test.ts: updated for the new components.
  • The PR description also lists new unit tests for RcKeyValue, RcLabels, RcLabelsAndAnnotations and RcACE.

Why manual testing is still recommended This is mainly a layout and spacing change: 16px within a group, 24px between groups, and the "Extra" request in the issue to make labels 14px p/span. Automated tests check structure and behaviour but not visual spacing, light/dark theming or typography. The form is also large and cross-cutting, with nested sections, the TOC, version management banners and the private registry auth secret dropdown. The PR itself asks for manual checks of generic/K3s/RKE2 import and of editing local and non-local clusters.

Residual risk to monitor

• Other pages that use Labels with the new opt-in props (showLabels, showAnnotationTitle).
• View mode of labels/annotations with the system-labels toggle.
• Agent env vars "Read from File", and the empty state of RcKeyValue.
• Whether the 14px label request was fully applied across all sections.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. No manual tests required.

Decision: is_automatable: true · automation_sufficient: true · manual_test: false

Rationale The issue asks for a CI gate that blocks new a11y violations. That gate is itself automation: an a11y ratchet that compares the Cypress a11y report against a committed baseline. The two linked PRs prepare the baseline and then turn enforcement on by default.

Test evidence

• PR #19336 (Prepare for a11y enforcement)
  • cypress/e2e/tests/accessibility/baseline.json: 16 baseline violations removed, leaving only known Kubectl Shell entries. The e2e a11y suite (shell.spec.ts > Shell a11y testing) will now fail on anything not in the baseline.
  • unit: shell/components/__tests__/PromptModal.test.ts gains two tests. One checks the dialog mounts only once when the type-map changes while it is open; the other checks a different dialog renders when the requested component changes. They cover the PromptModal change that lets the dialogs be removed from the baseline.
• PR #19440 (Enforce a11y gate)
  • .github/workflows/test.yaml: A11Y_RATCHET_ENFORCE now defaults to 'true' and can be switched off with a repo variable.
  • cypress/scripts/a11y/README.md: documents the enforcement and the opt-out.
  • The ratchet's own unit tests (yarn a11y:test) already exist and cover exit codes, soft mode and completeness checks.

Why manual testing is not recommended This is CI and tooling only, with no user-facing product behaviour beyond the PromptModal fix, which has unit tests. Green or red runs of the a11y-test job are the real verification.

Residual risk to monitor

• The gate runs only with if: success(), so a broken a11y test step shows as red tests rather than a ratchet failure.
• Flaky axe rules could block unrelated PRs. The A11Y_RATCHET_ENFORCE=false escape hatch is documented.
• The baseline must be re-seeded from CI artifacts, never from local renders.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

Decision: is_automatable: true · automation_sufficient: false · manual_test: true

Already covered in PR #19151 (unit)

• THead.test.ts:
  • sortedTableColsOptions filters out hidden and non-option columns and sorts case-insensitively without changing the source list.
  • isHeaderColumnVisible handles hidden, missing and advanced-filtered columns.
• SortableTable/__tests__/index.test.ts:
  • isColumnVisible.
  • expandAll marks every row expanded by keyField.
  • collapseAll clears the expanded state.
• selection.test.ts: row selection stops at a sub-row that contains a nested .sub-table.

Gaps against the acceptance criteria

1. unit — header-right slot exposes expandAll / collapseAll (shell/components/SortableTable/__tests__/index.test.ts)
   • Mount SortableTable with subExpandable rows and a #header-right="{ expandAll, collapseAll }" slot that renders two buttons.
   • Assert that clicking "Expand all" renders the sub-row for every row, and that "Collapse all" removes them.
   • The current tests call the methods directly with .call(ctx) and never check that the slot props are wired up (AC #2).
2. unit — sorting on a hidden column (shell/components/SortableTable/__tests__/sorting.test.ts or index.test.ts)
   • Give a header hide: true and sort: 'metadata.creationTimestamp:desc', and set it as the default sort.
   • Assert that rows come out in descending creationTimestamp order, that the <th>/<td> for that column are not visible, and that fullColspan leaves it out (AC #3).
3. unit — fullColspan with advanced filtering (index.test.ts)
   • With hasAdvancedFiltering: true and one column where isColVisible: false, assert that fullColspan counts only the visible columns. The colspan logic moved from !col.hide to isColumnVisible and is untested.
4. unit — row-selected class and searchMaxWidth (index.test.ts)
   • Assert that a selected row gets the row-selected class on main-row.
   • Assert that a custom searchMaxWidth sets --sortable-table-search-max-width in the header style.
5. e2e — sub-table expand/collapse on a real list (cypress/e2e/tests/pages/... for a list that uses a sub-table)
   • Click Expand all / Collapse all and assert that every sub-row appears or disappears.
   • Assert that hovering a sub-table row does not highlight the parent main row.
   • Assert that the column options menu is listed alphabetically.

Why manual testing is required SortableTable is used across almost every list view, so regression risk is high. AC #1 is purely visual: no grid borders, bold font-weight: 600 headers, no background between the sub-table and its frame, and hover limited to sub-table rows. That needs a human check in light and dark mode. Re-ordering the column options alphabetically is also a user-visible change to existing tables.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

Automated tests appear sufficient for this issue. No manual tests required.

Decision: is_automatable: true · automation_sufficient: true · manual_test: false

Rationale PR #19390 fixes pkg/rancher-prime/index.ts. After initRegistration() resolves it checks store.state.managementReady and returns early if the user has logged out. It also adds a .catch() that logs the error only while the user is still logged in, so the "Schemas aren't loaded yet" rejection is no longer unhandled.

Test evidence (PR #19390)

• unit: pkg/rancher-prime/index.test.ts adds the suite extension: rancher-prime registration notification. It uses fake timers and a controllable initRegistration promise.
  • Happy path: an admin without an active registration gets the REGISTRATION_NOTIFICATION_ID notification.
  • Logout while resolving: management/schemaFor is never called and store.dispatch is never called.
  • Rejection after logout ("Schemas aren't loaded yet"): handled silently, with no console.error.
  • Rejection while logged in: logged with 'Failed to resolve the registration state'.
• e2e: cypress/e2e/tests/pages/user-menu/preferences.spec.ts removes the cy.on('uncaught:exception', …) workaround. That spec logs out repeatedly and reproduced the bug in about two thirds of runs, so it now acts as a regression test against a real Prime build.

Why manual testing is not recommended This is a narrow race-condition fix with no visible UI change. Unit tests cover the happy path and both failure paths, and the existing e2e spec, which no longer suppresses the error, exercises the real timing.

Residual risk to monitor

• Watch preferences.spec.ts on Prime CI runs for flakiness, which would show up as the original uncaught exception.
• Other Prime/SCC extension lookups made right after login could have similar logout races.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. No manual tests required.

Decision: is_automatable: true · automation_sufficient: true · manual_test: false

Rationale PR #19234 adds RcCodeMirror, a CodeMirror 6 editor, to @rancher/components. It exports the component, its types and its folding helpers, and adds Storybook stories. Per the PR and the issue's last acceptance criterion, existing Dashboard editors are deliberately left unchanged. Moving Dashboard editors to the new component is separate work (#19274), so this issue only delivers the component library piece.

Test evidence (PR #19234)

• unit: pkg/rancher-components/src/components/RcCodeMirror/RcCodeMirror.test.ts
  • Model updates and v-model.
  • Read-only editing is blocked.
  • input variant: wrapping, no gutters, line-break markers.
  • Keymap, theme, line number and wrap props can change after mount.
  • The read-only textbox is reachable from the keyboard.
  • Gutter order and fold marker titles.
• unit: RcCodeMirror/extensions/fold.test.ts
  • Line-match and YAML-path folding, including list indexes.
  • Full-document parse, so content beyond the initial viewport can be folded.
  • Regex patterns with g/y flags, and bracket matching.
• unit: the keymap-specific tests from the PR's final commits ("Align RcCodeMirror key behavior with CodeMirror 5") cover the Emacs, Vim and default keymaps, the Escape-then-Tab focus route, and YAML newline indentation.
• Test infrastructure: jest.setup.js adds a fuller matchMedia mock for EditorView.destroy(), and jest.config.js transpiles @replit/codemirror-vim-core.
• Storybook: Default, JSON, Read Only, Input, Custom Folding and VModel stories cover the documentation criterion.

The unit tests map onto each acceptance criterion: model updates, read-only, variant and folding helpers.

Why manual testing is not recommended The component is not yet rendered anywhere in the Dashboard, so this issue adds no user-facing product change. The remaining visual checks (input variant in light and dark mode) belong to Storybook review and to the later migration work, where a full manual pass is more valuable.

Residual risk to monitor

• Later fixes to fold.test.ts (#19466) show the parse-budget test depended on runner speed. Watch for flaky timing-based tests.
• Having more than one copy of @codemirror/state would break the editor at runtime once extensions consume it. The pinned dependency versions help but should be monitored.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. No manual tests required.

Decision: is_automatable: true · automation_sufficient: true · manual_test: false

Rationale PR #19313 fixes the hardcoded resource list in shell/config/roles.ts:

• Node becomes Nodes.
• CSIStorageCapacitys becomes CSIStorageCapacities.
• Endpoints moves from the made-up io.k8s.api.discovery group to the core namespaced group ("").

RoleDetailEdit.vue lowercases the label and saves it as the resource name, so fixing the label fixes the saved rule.

Test evidence (PR #19313)

• unit: shell/components/auth/__tests__/RoleDetailEdit.test.ts adds a resourceOptions suite that mounts the real component as a Global Role.
  • Positive cases: { apiGroupValue: '', resourceName: 'nodes' }, { '', 'endpoints' } and { 'storage.k8s.io', 'csistoragecapacities' } are offered.
  • Negative cases: the old invalid values { '', 'node' }, { 'io.k8s.api.discovery', 'endpoints' } and { 'storage.k8s.io', 'csistoragecapacitys' } are no longer offered.
  • These are exactly the { resourceName, apiGroupValue } objects that go into the saved rule, so they cover all three rows of the issue's table.
• An existing test in the same file already checks how a resource name maps to its API group.

Why manual testing is not recommended The fix is a small, deterministic data change. The unit tests assert the exact values the dropdown offers and saves, for both the new and the removed entries. Whether kubectl auth can-i patch nodes then succeeds is standard Kubernetes RBAC behaviour once the rule says nodes, not something the Dashboard decides.

Residual risk to monitor

• Existing RoleTemplates saved with node (or the invalid Endpoints group) are not migrated and need manual admin edits. Consider a release note.
• The second problem in the issue is out of scope and should be tracked separately: Cordon/Uncordon/Drain buttons depend on Norman node actions, not on a core nodes grant.
• This is a backport candidate. Re-run the same unit suite on each backport branch.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. No manual tests required.

Decision: is_automatable: true · automation_sufficient: true · manual_test: false

Rationale This task asks only for test automation. The base spec (cypress/e2e/tests/components/code-mirror-shortcuts.spec.ts) arrived with the CodeMirror 6 migration in #19274: Emacs Ctrl+K kills the line without focusing nav search, Ctrl+P moves to the previous line, Ctrl+K outside the editor still opens the search, and the keymap preference is reset in after. PR #19315 then expands it considerably.

Test evidence (PR #19315, e2e using cypress-real-events realPress/realType)

• Emacs:
  • Ctrl-Y yank, with nav search not focused.
  • Ctrl-/ undo and Ctrl-Shift-Z redo.
  • M-< / M-> to jump to document start and end.
  • M-d kills the next word; M-w + Ctrl-Y copies and yanks a region.
  • The two-key chord Ctrl-X H selects the whole document.
  • Ctrl-V pages down without pasting (layout-dependent).
  • Ctrl-F and Ctrl-H.
  • The existing Ctrl-P / Ctrl-K tests now use M-< / M-> because Ctrl-Home and Ctrl-End do nothing on a Mac.
• Default (Sublime), new suite:
  • Mod-D selects the next occurrence; Mod-Shift-D duplicates a line.
  • Platform-aware line swap; Mod-L selects a line.
• Vim, new suite:
  • $ + x; dd + u.
  • o, type a YAML key, yy/p/u.
  • The after hook resets the preference to sublime.
• Each assertion checks both the editor value and that navActionBar.jumpToInput() did not take focus, which is the real point of conflict.

Acceptance criteria: the spec runs against the current editor (now CodeMirror 6, which supersedes the "passes against CodeMirror 5" criterion) and resets the keymap preference afterwards. CI type-checks the Cypress TypeScript.

Why manual testing is not recommended The deliverable is automated coverage with no product code change. The keys that cannot be automated (browser-reserved Ctrl+N/W/T and macOS Option characters) are already documented as out of scope in the issue.

Residual risk to monitor

• Platform branches (Cypress.platform === 'darwin') are exercised only on whichever OS CI uses.
• The Ctrl-V page-down test depends on layout, so watch it for flakiness on runners with different viewports.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

Decision: is_automatable: true · automation_sufficient: false · manual_test: true

Already covered in PR #19141

• unit: shell/edit/auth/ldap/__tests__/config.test.ts
  • Both inputs render for openldap, freeipa, activedirectory, shibboleth and okta.
  • The inputs bind to model.userIDAttribute / model.groupIDAttribute.
  • They are unset by default and editable before the provider is enabled.
  • They are locked once enabled for OpenLDAP, FreeIPA and AD, and stay editable for Shibboleth and Okta.
• e2e: cypress/e2e/tests/pages/users-and-auth/openldap.spec.ts
  • testAndApply sends ldapConfig.userIDAttribute / groupIDAttribute.
  • The inputs are disabled when the config is patched to enabled: true.
• e2e: cypress/e2e/tests/pages/users-and-auth/okta.spec.ts
  • The Okta save sends openLdapConfig.userIDAttribute / groupIDAttribute.
  • The inputs stay enabled and pre-filled when Okta is enabled.

Gaps against the acceptance criteria

1. unit — enabled provider summary, LDAP banner (shell/edit/auth/ldap/__tests__/index.test.ts)
   • Mount the LDAP index.vue with model.enabled: true and both attributes set. Assert the AuthBanner rows show "User Identifier Attribute: uid" and "Group Identifier Attribute: cn".
   • With the attributes empty, assert those rows are not rendered.
2. unit — enabled provider summary, SAML LDAP search details (shell/edit/auth/__tests__/saml.test.ts)
   • With model.openLdapConfig.userIDAttribute / groupIDAttribute set on an enabled Shibboleth or Okta config, assert both rows appear in the LDAP details table, and that they are hidden when the attributes are empty.
3. unit — tooltip per provider type (config.test.ts)
   • openldap/activedirectory in create mode use authConfig.ldap.idAttribute.tip.
   • The same providers when enabled use authConfig.ldap.idAttribute.locked.
   • shibboleth/okta always use authConfig.ldap.idAttribute.samlTip.
4. unit — is-create wiring (shell/edit/auth/ldap/__tests__/index.test.ts)
   • Assert that index.vue passes :is-create="!model.enabled" to config.vue. A disabled-but-existing provider must stay editable and an enabled one must be locked; today this is checked only through the patched GET in e2e.
5. e2e — Active Directory lock (cypress/e2e/tests/pages/users-and-auth/ AD spec)
   • Mirror the OpenLDAP lock test for activedirectory. AD uses a different save path and is the most common LDAP provider in practice.

Why manual testing is required This is an auth feature (area/auth, High priority) whose purpose is user identity continuity across OU moves. That can only be confirmed against a real LDAP/AD directory with the matching backend (rancher/rancher#55642, #54912, rancher/webhook#1451):

• enable the provider with an ID attribute;
• bind permissions;
• move a user to a different OU;
• confirm the user's identity and RBAC bindings survive.

The e2e tests mock the backend responses, so they do not check this end-to-end behaviour, the webhook's rejection of changes on an enabled provider, or the SAML principal matching for Shibboleth and Okta.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Decision: is_automatable: true · automation_sufficient: true · manual_test: true

Rationale PR #19365 ("Remove Ingress section for K3s clusters") hides the RKE2-only Ingress section for K3s. The Traefik migration banner lives inside that section, so it is hidden too.

⚠️ The fix does not match the issue's Expected Result. For K3s the PR keeps the traefik checkbox under System services and removes the Ingress section instead. The unit test "should offer traefik as a system service" asserts this. Following K3s's own disable: traefik semantics, this looks intentional, but QA should confirm it with the reporter.

Other changes in the PR:

• ProvCluster.isK3s now falls back to the selected Kubernetes version when there is no management cluster yet, which is the case in the create flow.
• When creating, switching from an RKE2 to a K3s version drops the RKE2-only ingress-controller setting.

Test evidence (PR #19365)

• unit: shell/edit/provisioning.cattle.io.cluster/__tests__/Basics.test.ts
  • New rke2 suite:
    • the ingress charts are removed from the system services list;
    • the Ingress section is shown with nginxSupported and the traefik value;
    • changing the ingress selection updates serverConfig['ingress-controller'] without emitting system-service changes.
  • New k3s suite:
    • traefik is offered as a system service;
    • the Ingress section is not rendered, so the migration banner is not shown either;
    • traefik reports enabled or disabled from the disable list;
    • checking or unchecking traefik emits the correct disable list.
• unit: __tests__/rke2.test.ts
  • In create mode, switching to a K3s version deletes ingress-controller.
  • In edit mode, an existing K3s cluster's setting is left alone.
• unit: shell/models/__tests__/provisioning.cattle.io.cluster.test.ts
  • isK3s uses the management cluster when present and otherwise falls back to the kubernetesVersion string (k3s, rke2 and undefined cases).

Why manual testing is still recommended Cluster provisioning (area/clusterprovisioningv2) is high-impact. The bug shows up while the user switches the Kubernetes version dropdown between RKE2 and K3s on the create page, which is heavy interaction between several UI elements that the unit tests only simulate through handleKubernetesChange. A human should check that:

• the Ingress section and banner disappear and reappear correctly when switching versions back and forth;
• the generated YAML has no leftover ingress-controller for K3s;
• editing existing K3s and RKE2 clusters is unchanged.

Residual risk to monitor

• The behaviour differs from the issue text, as noted above.
• The isK3s fallback now affects every consumer of the getter when no management cluster exists.
• There is no e2e coverage of the create page; a Cypress check for the K3s version would harden this.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

This issue is not currently a good candidate for automated coverage.

Decision: is_automatable: false · automation_sufficient: n/a · manual_test: false

Rationale This is a documentation-only task. PR #19436 changes only two files:

• storybook/src/stories/Components/RcDropdown.stories.ts, which adds these stories: CheckboxIndicators, RadioItems, ActsOnCheckableItems, Submenus (side="right" / side="left") and OpenWithoutTrigger.
• storybook/src/stories/Components/RcDropdown.mdx, which adds sections for checkbox indicators, radio items, commands for checkable items, submenus (keyboard behaviour, hover switching, one level deep) and opening without a trigger.

No product code or component behaviour changes.

Is it automatable? No, not meaningfully at this time. The deliverable is reference documentation. The repository has no Storybook interaction or visual-regression test runner wired into CI, so adding one just to check doc examples would cost more than it is worth. The component behaviour the stories demonstrate (submenu keyboard handling, acts-on-checkable-items keeping the menu open, focus returning on close, menuitemradio/menuitemcheckbox roles) is the job of the component's unit tests from the super-charged tables work (#19217), not of this issue.

Is automation sufficient? Not applicable, since the issue is not automatable.

Is manual testing recommended? No. None of the manual-test triggers apply: no regression risk to Rancher Manager, no product behaviour change, no priority/0 or area/prime. Code review of the stories and a quick look at the Storybook deploy are enough.

Test evidence: none in PR #19436, as expected for a Storybook-only change.

Residual risk to monitor

• If RcDropdownSubmenu, RcDropdownItemCheckbox or RcDropdownItemRadio change their APIs, these stories can silently go stale. A Storybook build or smoke step in CI would catch broken imports.

This analysis was generated automatically based on the repository's QA review decision model.

Automated tests appear sufficient for this issue. No manual tests required.

Rationale The fix in #19435 is a one-line change in shell/components/nav/NotificationCenter/Notification.vue. The age label now compares calendar days (day().startOf('day').diff(created.startOf('day'), 'day')) instead of elapsed 24h periods. The old logic caused the bug: anything less than 24h old was labeled "Today", even if it was created yesterday. A new unit test with a fixed system clock covers this behavior directly.

• Automatable: ✅ Yes. This is pure date-labeling logic that can be checked deterministically with fake timers.
• Automation sufficient: ✅ Yes.
• Manual test recommended: ❌ No. The change is small and self-contained, it only affects a label in the notification center, and it has no cross-page or high-risk flows.

Test evidence (PR #19435)

• unit: shell/components/nav/NotificationCenter/__tests__/Notification.test.ts (new). It sets the system time to 2026-10-07T11:40Z and asserts the rendered .created text for four cases:
  • earlier today → Today, 00:05
  • yesterday, less than 24h ago → Yesterday, 17:04. This is the exact regression from the issue.
  • yesterday, more than 24h ago → Yesterday, 00:01
  • two days ago → falls back to the full date 2026-10-05, 23:59
• The cases cover the happy path and both edges of the day boundary, and they check the user-visible text rather than implementation details.

Residual risk to monitor

• The test pins the clock in UTC. If a user's local timezone differs a lot from the time stored on the notification, the "Today/Yesterday" boundary follows the browser's local midnight. That matches the expected behavior, but it is not exercised in a non-UTC timezone.
• The ordering of notifications ("chronological order" in the expected result) is not part of this change and has no dedicated test here.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. No manual tests required.

Rationale #19384 moves the role="tab" (with its tabindex, aria-* and keyboard handler) from the window manager tab container onto a new inner .tab-title element. The close RcButton becomes a sibling of the tab instead of a child, which removes the nested-interactive violation. The change is applied the same way to HorizontalPanel.vue and VerticalPanel.vue. The axe e2e suite and new unit tests both cover it.

• Automatable: ✅ Yes. The violation is detected by the existing axe Cypress suite, and the DOM structure can be checked in unit tests.
• Automation sufficient: ✅ Yes.
• Manual test recommended: ❌ No. This is a localized markup and CSS restructure, and both the accessibility outcome and the tab interactions are covered automatically.

Test evidence (PR #19384)

• e2e: cypress/e2e/tests/accessibility/baseline.json. The nested-interactive entry for shell.spec.ts > … > Header > Kubectl Shell is removed from the accepted baseline, so the a11y suite now fails if the violation comes back.
• e2e: cypress/e2e/po/components/kubectl.po.ts. closeTerminalByTabName now uses the sibling selector ([aria-label] + [data-testid="wm-tab-close-button"]), so the existing kubectl e2e flows still exercise closing a tab.
• unit: shell/components/nav/WindowManager/panels/__tests__/HorizontalPanel.test.ts and VerticalPanel.test.ts (both RIGHT and LEFT):
  • no focusable element (button, a, input, select, textarea, [tabindex]) is nested inside a [role="tab"]
  • each close button is rendered as the sibling of its tab
  • the tab is activated on click, keyup.enter and keyup.space
  • clicking the close button does not activate the tab (failure/edge path)

Residual risk to monitor

• Drag-and-drop of tabs between panels (dragstart/dragend stay on the outer container) is not covered by the new tests.
• Padding and focus-outline styles moved from the container to .tab-title. Visual regressions, such as focus ring placement or the close button spacing now that margin-left was removed, are not asserted.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Rationale #19385 fixes the aria-required-children violation by taking role="tablist" off the containers that also hold non-tab buttons. In its place it adds an empty role="tablist" element that adopts the tabs through aria-owns, using stable ids from a new tabId() helper. The same pattern is applied to the window manager (HorizontalPanel.vue, VerticalPanel.vue) and to TableViews/TableViewTabs.vue. The axe baseline is now empty, and unit tests check the new structure.

• Automatable: ✅ Yes. Axe catches the violation in Cypress, and the ARIA structure can be checked in unit tests.
• Automation sufficient: ✅ Yes. Every acceptance criterion (the axe violation removed) is enforced by the e2e baseline, and the structure is covered by unit tests.
• Manual test recommended: ✅ Yes. The behavior depends heavily on UX. aria-owns reparenting is handled differently across browser and screen reader combinations, and axe cannot verify how the tabs are actually announced. The change also touches two separate UI surfaces: the window manager and the table views tabs.

Test evidence (PR #19385)

• e2e: cypress/e2e/tests/accessibility/baseline.json. The last aria-required-children entry is removed ("violations": []), so any regression fails the a11y suite.
• e2e: cypress/e2e/tests/accessibility/shell.spec.ts. Adds an assertion that the move prompt modal has aria-labelledby before axe runs.
• unit: HorizontalPanel.test.ts / VerticalPanel.test.ts (RIGHT, LEFT). No button or [role="button"] inside the tablist, and the tablist's aria-owns matches the ids of every rendered [role="tab"] exactly.
• unit: TableViewTabs.test.ts. No tab menu button inside the tablist, and aria-owns lists every tab id.
• unit: tab-body.test.ts. tabId() builds ids per position and sanitizes invalid characters (/, :, ., spaces, empty string).

Manual test focus

• With a screen reader (for example NVDA/Firefox and VoiceOver/Safari), check that the window manager tabs and table views tabs are announced as "tab X of N" within a tab list, and that arrow and Tab navigation still work.
• Check that adding, removing and reordering tabs (opening several kubectl shells; creating and reordering table views) keeps aria-owns in sync.

Residual risk to monitor

• The issue body notes this may require a Tab component refactor. The aria-owns workaround is a pragmatic fix, so watch for screen reader inconsistencies reported later.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

Current evidence (PR #19445)

• unit: shell/edit/__tests__/management.cattle.io.setting.kubeconfig.test.ts. The edit form offers the false / true options, labeled ACE and Rancher-proxied.
• unit: shell/list/__tests__/management.cattle.io.setting.kubeconfig.test.ts. The Settings list shows the setting with the right enum label for false and true, and hides it when the backend does not provide it.

These tests cover how the setting is rendered, but not the save flow or the default/empty-value case. The backend dependency ("r/r update required") also means the user-visible outcome, the current context in the downloaded kubeconfig, needs a manual check. The issue still has needs-info and no explicit acceptance criteria.

Suggested tests

1. unit: Settings list shows the default when the value is unset

   • Mount shell/list/management.cattle.io.setting.vue with { id: 'kubeconfig-prefer-rancher-proxy', value: '', default: 'false' }.
   • Assert that the displayed enum label is advancedSettings.enum.kubeconfig-prefer-rancher-proxy.false (ACE), and that the row is not marked as customized or modified.

2. unit: Edit form saves the selected value

   • In shell/edit/management.cattle.io.setting/index.vue, select true in the LabeledSelect and trigger save.
   • Assert that the setting's value is the string 'true', not a boolean, and that a "Use the default value" action resets it back to 'false'.

3. e2e: Global Settings: edit and persist the kubeconfig preference

   • Go to Global Settings → Settings, find kubeconfig-prefer-rancher-proxy, open Edit, pick "Rancher-proxied" and save.
   • Assert that the PUT to /v1/management.cattle.io.settings/kubeconfig-prefer-rancher-proxy sends value: "true", that the list then shows "Rancher-proxied", and that resetting restores "ACE (Authorized Cluster Endpoint)". Use cy.intercept to stub the setting if the backend under test does not expose it yet.

4. e2e (optional, once the backend is available): Setting hidden on older backends

   • Stub /v1/management.cattle.io.settings without the new setting.
   • Assert that the Settings page renders normally and no kubeconfig-prefer-rancher-proxy row is present.

Why manual testing is still recommended

• The real effect, which context a downloaded kubeconfig uses for an ACE-enabled cluster, is produced by the Rancher backend and cannot be checked in this repository alone.
• This is an auth/kubeconfig-related global setting with broad product impact for downstream cluster access.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

No manual tests required. Automated tests are not yet sufficient for this issue. Please address the feedback from the QA Review Decision Model:

Current evidence (PR #19430)

• Only pkg/harvester-manager/l10n/en-us.yaml and pkg/harvester-manager/l10n/zh-hans.yaml changed. harvesterManager.cluster.learnMore now appends &nbsp;<i class="icon icon-external-link inline"></i> inside both <a> tags.
• No *.test.ts, *.spec.ts, __tests__/ or cypress/ files were added or changed, so nothing guards the icon against being lost in a future string edit.

The change is small and low risk, so a manual pass is not needed. A light automated check would still lock in the acceptance criteria.

Suggested tests

1. unit: The learn-more text renders both external-link icons

   • Mount the Harvester Manager cluster list component in pkg/harvester-manager that renders harvesterManager.cluster.learnMore through v-clean-html, using the real en-us translation.
   • Assert that there are exactly two a[target="_blank"] links, with href values https://harvesterhci.io/ and https://docs.harvesterhci.io/, each with rel containing noopener noreferrer, and that each link contains an i.icon.icon-external-link.inline child. This also checks that v-clean-html does not strip the <i> element or the inline class.

2. unit: Translation parity between locales

   • Load en-us.yaml and zh-hans.yaml from pkg/harvester-manager/l10n and assert that harvesterManager.cluster.learnMore has the same number of icon-external-link occurrences (2) in both, so the two locales cannot drift.

3. e2e: Harvester Clusters intro shows external-link icons

   • Visit /c/_/harvesterManager/harvesterhci.io.management.cluster with no Harvester clusters (or with the extension not installed) and assert that both learn-more links are visible, have target="_blank", and contain .icon-external-link.
   • In Prime mode (if the existing Prime e2e setup allows it), assert that the Docs link href is rewritten to the SUSE documentation site, which confirms pkg/rancher-prime/docs.ts still works.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Rationale #18866 adds RcModal, RcModalDialog, useModal and types.ts under pkg/rancher-components/src/components/RcModal/. It also adds Storybook docs and stories, and registers .rc-modal in the ShortKey preventContainer list. The unit suites are extensive and map closely to each item in "What this covers". The focus trap is mocked in unit tests, though, so the real keyboard and focus experience still needs a human check.

• Automatable: ✅ Yes
• Automation sufficient: ✅ Yes. Every acceptance criterion has at least one direct assertion, including failure and edge paths.
• Manual test recommended: ✅ Yes. This is a new shared component whose value depends on UX: real focus trapping and focus return, Esc, scrolling bodies, and select menus rendered outside the modal. focus-trap is mocked in the unit tests, and there is no e2e coverage because no consumer is migrated yet.

Test evidence (PR #18866)

• unit: RcModal/__tests__/RcModal.test.ts (~780 lines):
  • layout/slots: title, body and actions regions; primary-action paired with the default cancel button; actions replaces the whole footer; title slot overrides the prop; no heading or aria-labelledby when no title is given
  • size: small/medium/large → 480/640/960px, with a medium fallback for invalid values
  • accessibility: role="dialog", aria-modal, a unique aria-labelledby per modal, tabindex="-1", escapeDeactivates: false, allowOutsideClick: true (menus outside the modal stay clickable), background mousedown prevented, trap deactivated on close, fallbackFocus when nothing is tabbable
  • stateless show: renders and tears down with show, stays open after emitting close until the consumer sets show false, re-arms the trap on reopen
  • closing/events: background click versus clickToClose: false; Esc always emits cancel → close, even with no cancel button; non-Esc keys are ignored; slot scope close/cancel/primaryAction; open emitted on each open
  • teleport: falls back to <body> when #modals is missing, and picks up #modals when it is added later
  • scrolling body: becomes a tab stop and a named region only while it scrolls; initial focus order is autofocus → first body control → scrolling body → footer
  • attributes: class and data-testid fall through to the dialog
• unit: RcModal/__tests__/useModal.test.ts. Covers open/close, payload, onClose returning false to keep the modal open, and an integration test wiring useModal to RcModal (Esc, background click and cancel all close it).
• unit: shell/initialize/__tests__/install-plugins.test.ts. Global shortcuts are suppressed inside .rc-modal.
• Storybook: storybook/src/stories/Components/RcModal.stories.ts and RcModal.mdx, with Default, Confirmation, WithSections, WithSelect, Autofocus, TallContent, RichTitle and WiredWithComposable stories.

Manual test focus (Storybook)

• Tab and Shift+Tab stay inside the modal, and focus returns to the trigger button on close.
• WithSelect with clickToClose: false: the LabeledSelect options are clickable and the modal does not close.
• TallContent: the body scrolls with arrow keys once focused, and the title and actions stay visible.
• Visual check against the Figma spec (padding, 40px/16px/24px gaps, right-aligned actions) in light and dark themes.

Residual risk to monitor

• The PR title says it migrates two modals, but the changed files only add the component. When consumers are migrated, add Cypress e2e coverage there.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. No manual tests required.

Rationale #19450 wraps the prefs/get(TABLE_VIEWS) read in savedViewsEntry (shell/mixins/resource-table-views.js) in a try/catch. On an older host that throws Unknown preference: table-views, it returns undefined, so the mixin's data() no longer throws and ResourceTable renders. A new unit test mimics an old host. The scheduled Extension Compatibility Test (Cypress against Rancher 2.10–2.15) is the end-to-end check for this exact regression.

• Automatable: ✅ Yes
• Automation sufficient: ✅ Yes. The unit test asserts the outcome the issue asks for, and the existing cross-version e2e workflow reproduces the original failure.
• Manual test recommended: ❌ No. The fix is a narrow defensive guard, and the multi-version Extension Compatibility Test runs exactly the scenario that failed (Elemental list pages on 2.10–2.15).

Test evidence (PR #19450)

• unit: shell/components/__tests__/ResourceTable.extension.test.ts, new suite "on a Rancher from before table views". It builds a context whose store throws Unknown feature for features/get and Unknown preference for prefs/get, runs the mixin's real data() and all computeds, and asserts savedViews === [], openedViewId === undefined and showTableViews === false. In short, the table renders without table views.
• e2e: cypress/e2e/po/components/code-mirror.po.ts. CodeMirrorPo.first() now re-queries on each call, which fixes the page object used by the Extension Compatibility Test cases 8.2 / 8.3 named in the issue.
• Secondary: .github/workflows/extension-compatibility-test.yml runs the Cypress extension compatibility spec against each released Rancher UI.

Residual risk to monitor

• The issue lists two other unguarded reads of the same preference: shell/mixins/resource-table-views.js:772 and shell/composables/useSavedTableViews.ts:32. The PR diff only guards savedViewsEntry. If those paths can be reached while isConfigurableTablesEnabled is false (for example from an extension using useSavedTableViews directly), they could still throw on older hosts. Watch the next scheduled Extension Compatibility runs on 2.10–2.15.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. No manual tests required.

Rationale #19450 adds a viewQuery prop to SortableTable. ResourceTable.vue passes showTableViews ? settledQuery : null into it. paginationChanged() now reports filtering.searchQuery as this.viewQuery ?? this.searchQuery, and a new viewQuery watcher calls debouncedPaginationChanged(). Together these make sortable-table-interaction fire, which calls extension table hooks, whenever the table views query changes. That is the behavior the issue requests.

• Automatable: ✅ Yes
• Automation sufficient: ✅ Yes. New unit tests cover the reported payload and the re-emit on change, and the Extension Compatibility Test 6.1 Table Hook (load, filter, sort) on latest covers the full flow.
• Manual test recommended: ❌ No. The behavior is an extension API contract that is fully observable in CI (the console marker TABLE HOOK TRIGGERED), and it is not UX-heavy.

Test evidence (PR #19450)

• unit: shell/components/SortableTable/__tests__/table-hooks.test.ts (new):
  • without table views, the search box query is reported (no regression for 2.10–2.15 behavior)
  • with table views, the raw view query (state:Error nginx) is reported as filtering.searchQuery
  • an emptied view query ('') is reported as empty, not as the stale search box query (edge case)
  • a change to viewQuery triggers debouncedPaginationChanged exactly once
  • with external pagination, the pagination-changed request still uses the search box query, so the view query does not leak into Steve requests (failure path guard)
• e2e: the Extension Compatibility Test 6.1 Table Hook on latest (extension-compatibility.spec.ts:494) asserts the hook fires on filter.

Residual risk to monitor

• The ResourceTable → SortableTable :view-query binding is only covered by the e2e workflow, not by a unit test.
• With server-side pagination and table views, check that hooks are not called twice per change (once from the watcher and once from the page reset). The issue says they share the same debounce, but this is not asserted.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

Current evidence (PR #19475)

• unit: pkg/rancher-components/src/components/Form/ToggleSwitch/ToggleSwitch.test.ts. The old "adds/removes focus class" tests are replaced by one test asserting that focusing the input does not add .focus to the slider. This covers the last acceptance criterion ("Unit tests are updated for the ToggleSwitch focus behavior").
• Everything else is CSS-only. :focus / .focused rules were removed or changed to :focus-visible in RcButton.vue (ghost and link variants), Checkbox.vue, ToggleSwitch.vue, NamespaceFilter.vue, NotificationCenter/Notification.vue, AddRepoLink.vue and ContainerShell.vue. Design tokens were swapped in nav/Group.vue, TopLevelMenu.vue and IconOrSvg.vue.
• No automated test checks "ring on keyboard focus", focus return after Enter/Escape on a dropdown, the hover background on the row action button, or the side nav tokens.

Suggested tests

1. e2e: Keyboard focus still shows the ring; mouse click does not

   • On Workloads → Pods, click a row's action button (RcButton link variant), a header ghost button, a ToggleSwitch, a Checkbox and the NamespaceFilter. After each click, assert that the element has outline-style: none (or no --primary-keyboard-focus outline).
   • Then reach each control with keyboard Tab (using a real keyboard event helper so :focus-visible matches) and assert that the outline is present, with the --primary-keyboard-focus color.

2. e2e: Dropdown focus return with keyboard

   • Focus a row action button with Tab, press Enter to open the menu, then press Escape.
   • Assert that the menu is closed, document.activeElement is the trigger, and the trigger matches :focus-visible (ring visible).

3. e2e: Row action button keeps its hover background

   • Hover the row action button and read its background-color, then trigger mousedown and mouseup. Assert that background-color is unchanged and is not transparent.

4. e2e: Side nav uses the new design tokens

   • Open the cluster explorer with Workloads → Pods selected. Assert that the expanded group container (.group-highlight) has background equal to the computed --rc-section-background-secondary, while a collapsed sibling group keeps --nav-bg.
   • Assert that the active item uses --active / --on-active, and --active-hover on hover.
   • Repeat in the dark theme (switch the theme preference).

5. unit: RcButton no longer forces focus styling from a class

   • Mount RcButton with variant="link" and variant="ghost", call the exposed focus(), and assert that no focused class is applied. This mirrors the new ToggleSwitch test and guards against reintroducing click-triggered rings.

Why manual testing is still recommended

• The behavior depends heavily on UX and visuals (focus ring versus click, hover flicker, side nav colors in light and dark themes), and it spans many components across several pages.
• The PR also changes TopLevelMenu.vue and IconOrSvg.vue, beyond the components listed in the issue. It drops the fallbacks (for example var(--active-nav, var(--primary-hover-bg)) → var(--active)), so check the top-level menu, pinned clusters and custom-branded or extension themes.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

Automated tests appear sufficient for this issue. No manual tests required.

Decision: automatable = ✅ true · automation sufficient = ✅ true · manual test = ❌ not needed

Rationale The fix in #19491 is one condition in the view.query watcher in shell/mixins/resource-table-views.js. It changes if (!typed) to if (!typed || !query), so a cleared query settles at once instead of waiting for the debounce. The bug was deterministic and timing-based. That makes it a good fit for fake-timer unit tests, and the PR adds them.

Test evidence (PR #19491)

• shell/components/__tests__/ResourceTable.viewSwitch.test.ts (unit), two new cases:
  • should apply clearing the query at once: clearing nginx to '' sets settledQuery to '' straight away, with no timer advance.
  • should settle the same query again when it is cleared and retyped faster than the debounce: replays '' → n → … → nginx at 10ms per keystroke, which is Cypress typing speed. It asserts the settled values are exactly ['', 'nginx']. This is the clear-and-retype sequence the issue asked to cover, and the gap the existing table-hooks.test.ts coverage missed.
• The existing tests in the same suite still cover the "query changed" case (fixed by #19450) and the saved-view flush case. Those are the regression edges around this change.
• The nightly Extension Compatibility Test (cypress/e2e/tests/pages/extensions/extension-compatibility.spec.ts, test 6.1 Table Hook (load, filter, sort)) is the e2e that originally caught the bug. It exercises the real hook path end to end against Rancher latest.

Why no manual test

• This is a small internal timing fix with no visible UI change, apart from clearing now feeling instant.
• It is covered by deterministic unit tests plus an existing e2e regression gate.
• None of the manual-test triggers apply (no priority/0, no area/prime, no complex multi-page UX).

Residual risk to monitor

• The unit tests check settledQuery, not that addTableHook callbacks fire. The proof that hooks fire comes from the nightly compatibility run. Confirm that the Rancher latest row of the next run is green on test 6.1.
• Clearing now sends an immediate list request with no debounce. Watch for any reports of extra requests on very large lists.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Decision: automatable = ✅ true · automation sufficient = ✅ true · manual test = ⚠️ required

Rationale #19571 removes the Prime-only exception and gates Ingress-NGINX on Kubernetes ≥ v1.37.0 for all editions, in both create and edit modes. The logic is driven by props and computed values (ingress/index.vue, rke2.vue, shared.ts, IngressCards.vue), which suits unit tests. The PR covers every acceptance criterion at unit level.

Test evidence (PR #19571)

• shell/edit/provisioning.cattle.io.cluster/__tests__/Ingress.test.ts (unit):
  • AC1, no new NGINX clusters on 1.37+: omits the nginx card when creating a cluster with k8s >= v1.37.0. updates the create options when the Kubernetes version changes checks the switch from 1.36 to 1.37. does not enable nginx on Kubernetes 1.37 when Traefik is unavailable covers the fallback edge case. The Prime-only tests and the getVersionData mock were removed, so the rule now applies to both editions.
  • AC2, block upgrading while on standalone NGINX: disables the nginx card when editing a cluster targeting k8s >= v1.37.0, shows the blocking message when an edited cluster still uses standalone nginx, ignores selection of disabled nginx on k8s >= v1.37.0, and keeps dual mode available when editing….
  • AC3, warn about no switching back: an 8-row it.each matrix for nginxUpgradeWarning. It covers nginx→traefik, nginx→dual, dual→traefik, traefik/none (no warning), already on 1.37, and no previous version. A separate case checks that a target below 1.37 shows no warning.
• shell/edit/provisioning.cattle.io.cluster/__tests__/rke2.test.ts (unit): an it.each over ingressNginxUnsupported for create/edit, v1.36/1.37/1.38, and nginx/traefik/dual/none. This flag feeds validationPassed, so it gates save.
• shell/edit/provisioning.cattle.io.cluster/__tests__/IngressCards.test.ts (unit, new): the Recommended label is hidden when Traefik is the only option and updates when options change. The Legacy label is kept.

Why manual test is required

• Large product impact: this changes which ingress controllers can be provisioned or upgraded on every RKE2 cluster, for both Community and Prime.
• Major regression risk in the cluster provisioning and upgrade flow, which the unit tests only exercise with mocked components.
• Suggested manual checks:
  • Create an RKE2 cluster on 1.36, then on 1.37+, and confirm NGINX is hidden on 1.37+.
  • Edit an NGINX cluster on 1.36 and set the version to 1.37: the error banner shows and save is blocked.
  • Switch that cluster to Traefik or Dual: the warning banner shows and the upgrade succeeds.
  • Confirm K3s clusters are unaffected.
  • Run the checks on both a Prime and a Community instance.

Residual risk to monitor

• No test asserts that the Save/Create button is actually disabled in the full rke2.vue form. Only the computed ingressNginxUnsupported is tested.
• The rule relies on semver.gte with RKE2 version strings such as v1.37.0+rke2r1. Check pre-release or odd version strings from real KDM data during manual QA.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

Decision: automatable = ✅ true · automation sufficient = ❌ false · manual test = ⚠️ required

What is already covered (PR #19604)

• shell/components/form/__tests__/LabeledSelect.test.ts (unit) adds a keepSearchOnBlur prop suite of about 17 cases. It covers keeping and clearing on blur, the placeholder showing the kept text, restoring the text and re-searching on focus, Escape handling (keep, clear, stopPropagation), forceClose, click outside, option select, aria-description, and the opt-out default.
• shell/pages/c/_cluster/explorer/workload-dashboard/search/__tests__/WorkloadSearch.test.ts (unit) checks that keepSearchOnBlur is passed. It also checks that forceOpen() is called with no arguments on the action-menu and Tab blur paths.

Why this is not yet enough The original bug was intermittent and depended on how focus was lost ("usually cleared, sometimes stays"). That timing comes from real-browser focus and blur ordering inside vue-select. jsdom does not reproduce it faithfully, and several unit cases call forceOpen() or set isOpen directly instead of driving real focus changes. The issue explicitly asks that the fix be tested on the Workload Overview search, including the row action menu case. Today that is covered only with a stubbed LabeledSelect.

Suggested tests

1. e2e: Workload Overview search keeps the text when you click outside

   • Spec: cypress/e2e/tests/pages/explorer2/workloads/workload-dashboard*.spec.ts, or the existing Workload Overview spec.
   • Type ngi into [data-testid="workload-dashboard-search"] and click the page body.
   • Assert: the input value is empty, the input placeholder equals ngi, and the dropdown is closed.
   • Re-focus the input. Assert: the value is ngi again and results come back without retyping.

2. e2e: kept text survives Tab-away and the row action menu path

   • Type a term, press Tab, and assert the same kept placeholder as in test 1.
   • Separately: type a term, open a result row's action menu, then click elsewhere on the page. Assert the text is kept the same way as in test 1. This is the "consistent however focus is lost" criterion.

3. e2e: Escape clears the kept text

   • After blur with kept text, focus the select wrapper and press Escape.
   • Assert: the placeholder goes back to the default workloadDashboard.search.placeholder text, and the page-level Escape handling is not triggered.

4. unit: hint styling for the kept text

   • In LabeledSelect.test.ts, assert that kept text is only ever rendered through the placeholder attribute, never as the input value, so it gets the grey hint styling.
   • Assert that the default keepSearchOnBlur=false leaves the existing placeholder unchanged. This guards existing select-from-a-list users.

Why manual test is required

• The behaviour depends heavily on UX: the grey hint styling, how focus feels, and keyboard and screen-reader behaviour through the new aria-description.
• It involves several interacting UI parts: the search input, the dropdown, row action menus, and Tab and Escape.
• Manually check the Workload Overview search in Chrome and Firefox, then spot-check one other searchable LabeledSelect to confirm it is not affected, since the prop is opt-in.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Decision: automatable = ✅ true · automation sufficient = ✅ true · manual test = ⚠️ required

Rationale #19585 adds a new RemoveOperationDialog.vue, built on RcModal, and a DayTwoOperation base model whose promptRemove() opens it for all four operation.cattle.io.* types. The delete-and-redirect logic moves into a shared doneLocationAfterRemove util. Both acceptance criteria are covered directly by unit tests.

Test evidence (PR #19585)

• shell/dialog/__tests__/RemoveOperationDialog.test.ts (unit, new):
  • AC1, warn on an in-progress delete: should warn and block delete for a %s operation runs for Pending, InProgress and undefined. should not warn and should allow delete runs for Succeeded, Failed and Canceled. Other cases check that ticking the acknowledgement checkbox enables Delete and unticking disables it again, and that an unacknowledged in-progress operation cannot be removed.
  • AC2, uses RcModal: asserts on rc-modal-title, show/hide via modal.show, and autofocus on the checkbox.
  • Failure and edge paths: delete error banner with the dialog kept open, no closing while the request is in flight, cancel without deleting, redirect away from the deleted operation's detail page, and the kind label for each of the four operation types.
• shell/models/__tests__/day-two-operation.test.ts (unit, new): all four operation models extend DayTwoOperation, and promptRemove dispatches RemoveOperationDialog with ownsModal.
• shell/utils/__tests__/operation-cr.test.ts covers the phase matrix and null/undefined status for isOperationInProgress. shell/utils/__tests__/prompt-remove.test.ts covers the extracted redirect logic, which is also used by the generic PromptRemove, so it guards that refactor against regressions.
• shell/components/__tests__/PromptModal.test.ts and shell/composables/__tests__/focusTrap.test.ts (unit): the new dialog renders through PromptModal, and the focus-trap change skips tabindex="-1" elements.

Why manual test is required

• This is part of the Day 2 Ops for imported RKE2/K3s clusters epic (#16453). It is a destructive action on live cluster operations, and the warning depends on the real status.phase values set by the backend controller.
• The focusTrap.ts change applies to every modal that uses the focus trap, so it carries a small cross-app keyboard and focus regression risk.
• Suggested manual checks on an imported cluster with Day 2 Ops enabled:
  • Delete a running snapshot or rotation: the warning shows and Delete stays disabled until you tick the acknowledgement.
  • Delete a completed operation: there is no warning.
  • Delete from the operation's detail page: you are redirected to the list.
  • Tab through another RcModal dialog to confirm keyboard focus still works.

Residual risk to monitor

• If the backend reports a terminal phase other than Succeeded, Failed or Canceled, the dialog will treat it as in progress and over-warn. Confirm the phase names against the operator's CRD.
• Bulk delete from the list goes through the generic path and was not reviewed here. Confirm whether the warning should also apply to multi-select deletes.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. No manual tests required.

Decision: automatable = ✅ true · automation sufficient = ✅ true · manual test = ❌ not needed

Rationale The root cause was the .v-popper__popper popover border showing as a white edge around tooltips on the selected cluster icon. #19605 fixes it with one CSS rule in shell/assets/styles/global/_tooltip.scss: border-color: transparent for .v-popper--theme-tooltip. The PR backs this with both a style unit test and real-browser e2e assertions on the exact element from the report.

Test evidence (PR #19605)

• cypress/e2e/tests/navigation/side-nav/main-side-menu.spec.ts (e2e): after hovering the first cluster icon, it now calls:
  • BurgerMenuPo.checkIconTooltipBorderIsTransparent(), which asserts the shown tooltip's computed border-top-color is rgba(0, 0, 0, 0). That means the white border is gone.
  • checkIconTooltipArrowMeetsIcon(), which asserts the tooltip arrow's left edge is within 0.5px of the icon's right edge. That means the tooltip is not offset or clipped.
• cypress/e2e/po/side-bars/burger-side-menu.po.ts: the new page-object helpers above.
• shell/assets/styles/global/__tests__/tooltip.test.ts (unit, new): compiles the real SCSS. It asserts popovers keep 1px solid var(--border), tooltips override only border-color: transparent, and no other border* property is overridden. That guards the arrow spacing against regressions.

Why no manual test

• This is a narrow cosmetic CSS fix whose visible result, a transparent border and the arrow lined up with the icon, is asserted in a real browser by e2e.
• The unit test keeps the change limited to tooltips, so other popovers are not affected.
• None of the manual-test triggers apply.

Residual risk to monitor

• The rule applies to every tooltip in the app, not just the side bar. A missing border could look odd on themes where the tooltip background is close to the page background. The e2e runs only in the default theme.
• The issue still carries needs-info. Consider removing it now that #19605 has merged.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Decision: automatable = ✅ true · automation sufficient = ✅ true · manual test = ⚠️ required

Rationale When ui-configurable-tables is off, #19534 restores three things: the server-side stateFilter and nameFilter handling, the "State/Name filter applied … Clear filter" bar in ResourceList, and client-side state filtering for cert-manager lists. Each piece is gated by isConfigurableTablesEnabled, and the unit tests cover both flag states for each piece.

Test evidence (PR #19534)

• shell/mixins/__tests__/resource-fetch-api-pagination.test.ts (unit):
  • parseStateFilter and parseNameFilter: null, undefined, empty, single and multiple values, trailing commas, and the IN/CONTAINS equality.
  • paginationChanged: the request includes metadata.state.name IN … and metadata.name CONTAINS … when the flag is off, includes both together, and includes neither when table views are on.
  • The $route.query.stateFilter and nameFilter watchers re-request the list when the flag is off and do nothing when it is on. This covers Clear filter and the Back button.
• shell/components/ResourceList/__tests__/index.test.ts (unit):
  • The state bar shows a badge per state, including a model-computed state (expiring) and an unmatched state (error) that falls back to the state colour.
  • Clear filter removes only stateFilter and keeps the rest of the query.
  • The name bar shows the term and its Clear filter keeps the rest of the query.
  • Neither bar renders when table views are on.
• pkg/cert-manager/list/__tests__/cert-manager.io.certificate.test.ts (unit, new): no filter, a single state, comma-separated states, the client-only expired state, no matches, empty segments, and no filtering when table views are on. The issuer, cluster issuer and order lists share the same ClientStateFilterList component through extends.

Why manual test is required

• The flow spans several pages behind a feature flag: Workload Overview state count → filtered Pods list → Clear filter, and cert-manager overview bucket → each of four lists. The links are not tested end to end.
• The two flag states (ui-configurable-tables on and off) share the same links, so regression risk is high in both.
• Suggested manual checks:
  • With the flag off, click Completed, Active and similar counts on Workload Overview. Confirm the list shows only matching pods, the bar shows, and Clear filter restores the full list.
  • Use a Workload Overview search "+ more" link and confirm the Name filter bar appears.
  • Open each cert-manager overview bucket link.
  • Repeat the same checks with the flag on and confirm the states go into the search bar instead.

Residual risk to monitor

• There is no e2e for the dashboard-to-list deep link. Consider one in a follow-up, for example: visit /c/local/explorer/pod?stateFilter=running with the flag off and assert the filter bar and row states.
• The server-side state filter depends on metadata.state.name being indexed by Steve for every workload type linked from the dashboard.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Decision: automatable = ✅ true · automation sufficient = ✅ true · manual test = ⚠️ required

Rationale #19335 rewrites RotateEncryptionKeyDialog.vue as a <script setup> component on RcModal, with an ownsModal prompt. The dialog now changes based on whether a snapshot exists and how old it is. All three backup states from the issue are asserted directly in unit tests, along with both rotation paths and the error and in-flight edge cases.

Test evidence (PR #19335)

• shell/dialog/__tests__/RotateEncryptionKeyDialog.test.ts (unit, rewritten):
  • No backup: warns and disables Rotate Keys when there is no snapshot. The noBackup warning shows, Take Snapshot is shown, and Rotate is disabled. does nothing while there is no snapshot to fall back on confirms that no save or operation CR is created.
  • Old backup (≥ 1 day): warns but allows rotation when the latest snapshot is stale. The outdated warning shows the day count, Take Snapshot is shown, and Rotate is enabled.
  • Fresh backup (< 1 day): shows no warning and no take-snapshot button when the latest snapshot is recent.
  • Edge cases: the newest of several snapshots is picked. A regression test checks the date is read from snapshotFile.createdAt rather than the top-level created. Rotate is disabled while loading.
  • Rotation paths: an imported Day 2 Ops cluster creates an operation CR, and a non-Day-2 cluster gets generation incremented and saved.
  • Failure handling: errors show in a role="alert" banner and the dialog stays open. The dialog cannot be closed or rotated twice while a request is in flight. takeSnapshot starts the snapshot and closes the dialog.
• shell/models/__tests__/provisioning.cattle.io.cluster.test.ts (unit): rotateEncryptionKey dispatches the dialog with ownsModal: true.
• shell/components/__tests__/PromptModal.test.ts (unit): the dialog renders through PromptModal in ownsModal mode.

Why manual test is required

• Encryption key rotation is a high-risk cluster operation: it re-encrypts every secret and restarts control-plane nodes. It is part of the Day 2 Ops epic (#16453), so it has large product impact.
• The dialog is meant to match the linked Figma design, which depends on visuals and layout: the snapshot card, a large modal, and the copyable snapshot ID.
• Suggested manual checks:
  • On a cluster with no snapshots, confirm the warning and that Rotate is disabled. Use Take Snapshot, wait for it to complete, and reopen the dialog.
  • On a cluster with a snapshot older than one day, confirm the warning and that rotation works.
  • On a cluster with a fresh snapshot, confirm there is no warning.
  • Run these on both a provisioned RKE2 cluster and an imported cluster with Day 2 Ops.
  • Check that "View snapshots" opens the Snapshots tab.

Residual risk to monitor

• The exact 1-day boundary (24h) is not unit-tested. The tests use 14 minutes and 9 days.
• The zh-hans outdated string drops the ICU plural form. It still works but is worth a translation check.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

This issue is not currently a good candidate for automated coverage.

Decision: automatable = ❌ false · automation sufficient = n/a · manual test = ❌ not needed

Rationale This is a release-maintenance task. #19594 bumps CURRENT_RANCHER_VERSION in shell/config/version.js from '2.15' to '2.16' and updates runtime-rancher-version in branches-metadata.json. The only behaviour that matters is that the generated docs links point at a live v2.16 docs site. The site lives outside this repository (ranchermanager.docs.rancher.com and fleet.rancher.io), so routine CI cannot reliably assert that the links resolve. A unit test asserting the constant equals '2.16' would only restate the change.

Test evidence (PR #19594)

• shell/components/fleet/__tests__/__snapshots__/HelmOpTargetOptionsSection.test.ts.snap (unit snapshot): the Fleet docs link changes from https://fleet.rancher.io/next/reference/ref-crds#… to the versionless https://fleet.rancher.io/reference/ref-crds#…. This shows that the existing version-derived URL logic picks up the bump.
• No new test files were added, which is expected for a constant bump.

Why no manual test

• The change is small and low risk, and it follows the same process as the 2.15 bump (#17667).
• A maintainer already confirmed the v2.16 docs base is live (comment on 2026-10-15).
• None of the manual-test triggers apply: no priority/0, no area/prime, no UX or multi-page interaction.

Residual risk to monitor

• Fleet docs links now resolve to the unversioned "latest" path instead of /next/. Spot-check one Fleet docs link in the UI after release to confirm the anchor (#_bundledeploymentoptions) still exists.
• The process improvement in #18032 would make future bumps less manual.

This analysis was generated automatically based on the repository's QA review decision model.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Decision: automatable = ✅ true · automation sufficient = ✅ true · manual test = ⚠️ required

Rationale #19562 adds a View in Fleet link to FleetManagedBanner.vue and a new FleetManagedBadge.vue, using icon-fleet-alt from @rancher/icons 2.0.66. The badge is wired into both mastheads (Resource/Detail/Masthead/index.vue and ResourceDetail/Masthead/latest.vue). The link-targeting and permission rules are pure logic, and unit tests cover them thoroughly, including every listed permission condition.

Test evidence (PR #19562)

• shell/components/Resource/Detail/__tests__/FleetManagedBanner.test.ts (unit, rewritten):
  • Banner: renders for gitrepo, helmop and bundle, and names the product. It does not render with no resource, no metadata, no labels, or only unrelated labels.
  • Link targets: GitRepo and HelmOp go to c-cluster-fleet-application-resource-namespace-id. Bundle goes to c-cluster-product-resource-namespace-id under the fleet product.
  • Permission conditions: no link when the Fleet feature is disabled, when the user cannot list the source type, when the workspace is not in the user's workspace list, or when the user cannot list workspaces. Also no link for an unknown kind or missing namespace/name labels, while the banner still shows.
• shell/components/Resource/Detail/__tests__/FleetManagedBadge.test.ts (unit, new): the badge renders with the icon-fleet-alt icon and the "Managed" text for a Fleet-managed resource, and is hidden otherwise.
• shell/components/ResourceDetail/Masthead/__tests__/latest.test.ts (unit): the resource is passed to FleetManagedBadge through the title-bar title-suffix slot.

Why manual test is required

• The behaviour depends heavily on UX and visuals that unit tests cannot check:
  • the secondary link style;
  • the text-no-break wrapping, where the whole link moves to the next line rather than breaking;
  • the 16px badge with an 18px icon, the inactive background, and alignment next to the state badge.
• It also involves navigation across products, from a cluster resource into Fleet.
• It needs Rancher 2.16 with Fleet v0.17.0-alpha.6 or newer for the fleet.cattle.io/managed-by-* labels, so it should be confirmed against real Fleet-deployed resources.
• Suggested manual checks:
  • Deploy through a GitRepo, a HelmOp and a Bundle. On each resource's detail page, confirm the badge and banner link show and the link opens the right Fleet page.
  • Narrow the window and confirm the link wraps as a whole.
  • Log in as a user without access to that workspace and confirm the link is hidden.
  • Check light and dark themes.

Residual risk to monitor

• Resource/Detail/Masthead/index.vue now always renders the title-suffix slot. No unit test covers the badge in that masthead, only in latest.vue.
• As the issue notes, a user with access to a workspace but not to the specific GitRepo, or a source that has been deleted, can still see a dead link.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

Decision: automatable = true, automation sufficient = false, manual test = true

Evidence found (PR #19568): unit tests only, no e2e

• shell/models/__tests__/principal.test.ts: displayType shows "GitHub User (github-2)" and "GitHub Team (github-2)", and leaves the config name off when it matches the provider ✅
• shell/models/__tests__/management.cattle.io.user.test.ts (new): provider / providerDisplay show "GitHub (github-2)", show "Multiple" for users of two configs of the same type, and sort a named config right after its provider ✅
• shell/components/auth/__tests__/Principal.test.ts: the member-list fallback gets the provider type from authProvider ✅
• shell/models/__tests__/management.cattle.io.authconfig.test.ts: canCloneConfig (blocked for local auth, for providers without a form, and by the Community limit; allowed when the multiple-providers flag is on) and the goToClone route with ?cloneConfig= ✅
• shell/utils/__tests__/auth-providers.test.ts: configNameOfPrincipal, providerOfConfig, and cloneableAuthConfigFields, which strips identity, enablement, access mode, allowed principals, password-typed fields and secrets nested in openLdapConfig ✅
• shell/pages/c/_cluster/auth/config/create/__tests__/provider.test.ts: clone values, the github-2 name suggestion, refusing a source of another provider, the clone title, and the not-found error ✅
• shell/mixins/__tests__/auth-config.test.ts: cloned values are applied after the defaults and aren't shared with the form ✅
• AuthProvidersPrimeNotice.test.ts and auth/config/__tests__/index.test.ts: the Prime notice links and the rows sorted by name ✅

Gaps and suggested tests

1. unit: shell/dialog/__tests__/SloDialog.test.ts. Not covered: the single logout dialog now resolves its label through providerKey(authProvider.type). Mount it with authProvider = { id: 'github-2', type: 'githubProvider' } and assert the name uses the model.authConfig.provider."github" translation, not a missing key. Add a case for a provider whose id equals its type.
2. unit: users list fallback for an unlisted config. providerOfConfig falls back to the raw config name when the config isn't in /v1-public/authproviders (disabled configs aren't listed). Assert what providerDisplay shows in that case (for example okta-3), so the Users list label is a deliberate choice rather than an accident.
3. e2e: Cypress clone flow (cypress/e2e/tests/pages/users-and-auth/). With the authconfig and schema APIs intercepted, open the auth provider list, use the row action menu to Clone a GitHub config, and assert:
   • the URL is /auth/config/create/github?cloneConfig=github
   • the title reads "Clone GitHub" and the name field is prefilled with github-2
   • non-secret fields such as hostname and client ID are prefilled, and the client secret is empty
   • Clone is disabled for local auth and under the Community limit
4. e2e: Prime notice and provider order. On the provider list, assert the restyled notice title, that the action links to the SUSE Rancher Prime page (Community) or to Feature Flags (Prime with the flag off), and that a provider added during the session appears in name order without a reload.
5. e2e: Users list Provider column. With intercepted users and auth providers, assert the column shows "GitHub (github-2)" for a named config and "Multiple" for a user of github + github-2, and that sorting puts the named config right after its provider.

Why manual testing is still needed: the clone flow writes a real auth config against a live identity provider and needs secrets re-entered and a connection test. The issue is area/auth, High priority, and part of the multiple-auth-providers epic, with UI spanning the provider list, the create page, the Users list and member lists. Testing against real GitHub/LDAP backends is recommended.

Residual risk: clone values come from the Norman schema resourceFields; a provider whose secret fields aren't marked password and aren't in SECRET_FIELDS could leak into the cloned form.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

Decision: automatable = true, automation sufficient = false, manual test = true

Evidence found (PR #19566)

• shell/pages/c/_cluster/apps/charts/__tests__/index.test.ts, hook: beforeUnmount: asserts that cluster/forgetType is dispatched with CATALOG.APP (unit). This checks that the fix is wired in, but not the user-visible result (the Installed Apps list keeps its rows when the apps watch fires).

Suggested tests

1. e2e: Cypress, Charts → Installed Apps. Intercept the apps list with 2–3 apps. Visit Apps → Charts, then Apps → Installed Apps, and assert the list shows every app (not "There are no rows to show"). Then send an app change over the websocket (or re-intercept the list with a changed app) and assert the list still shows all apps with the update.
2. e2e: Charts page statuses after a round trip. Go Charts → Installed Apps → Charts and assert the chart cards still show their installed and upgradeable badges, which proves the forgotten apps are fetched again when you return to Charts.
3. unit: a regression guard for the Installed Apps page. With the store mocked, assert that the installed apps list resource fetches and watches catalog.cattle.io.app itself after forgetType runs, so the list doesn't depend on state left behind by the Charts page.

Why manual testing is still needed: the bug depends on websocket timing and on the order in which route components unmount and mount. Unit tests can't reproduce that reliably, and forgetType running while Installed Apps is loading is a regression risk for a core flow (area/performance). Follow the repro steps with a few Fleet GitRepos, and also check fast back and forth between the two pages.

Residual risk: forgetType also drops the apps watch. Any other open view that depends on the apps store (for example the cluster dashboard apps card) could flicker when you leave Charts.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

Automated tests appear sufficient for this issue. No manual tests required.

Decision: automatable = true, automation sufficient = true, manual test = false

Rationale: this is a small change that replaces a GenericPrompt with a new TableViewPublishModal built on RcModal. The unit tests cover every acceptance criterion and the failure and cancel paths.

Evidence found (PR #19580): unit

• shell/components/TableViews/__tests__/TableViewPublishModal.test.ts (new):
  • the title is tableViews.publish.title ("Publish") and the body is tableViews.publish.body ✅
  • the filter warning shows only when hasFilter is set, and is absent otherwise ✅
  • Confirm emits publish and closes ✅
  • Cancel closes without publishing ✅
• shell/components/TableViews/__tests__/TableViewTabs.test.ts, updated:
  • shareView opens TableViewPublishModal and nothing is created until the user confirms ✅
  • hasFilter is passed through for views with and without a filter ✅
  • confirming publishes the view and keeps its place in the tab order ✅
  • a failed publish keeps the user's view and reports the error ✅

Manual testing: not needed. The change is narrow, matches the Export, Share and Import modals that already exist, and doesn't change how publishing works.

Residual risk (low): the asyncButton.publish translations were removed, so any other caller of applyMode: 'publish' would lose its labels. The confirm button reuses the tableViews.tab.share label, so check it reads as intended.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

This issue is not currently a good candidate for automated coverage.

Decision: automatable = false, automation sufficient = n/a, manual test = true

Rationale: the fix (PR #19582) is a single CSS rule, min-height: 0 on .cluster-row-pin.icon in shell/components/ClusterRowPin.vue, which stops the button's 40px min-height from pushing the description down. The bug is purely visual spacing, about 12px. jsdom-based unit tests don't compute layout. A Cypress pixel or offset assertion on row height would be brittle across themes, fonts and browsers, and the repository has no visual-regression tooling to check it reliably.

Test evidence: the PR adds or changes no test files.

Manual testing: recommended. The result depends strongly on how the page looks. Check:

• Home and Cluster Management: for a cluster with a description, the name and description sit together as before the pin was added
• the pin still shows on hover and toggles correctly
• the row height matches rows without a pin
• the hover and keyboard focus area of the pin button is still usable now that its min-height is 0
• both light and dark themes

Residual risk: with min-height: 0 the pin's click target could shrink. Watch for usability or accessibility reports.

This analysis was generated automatically based on the repository's QA review decision model.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Decision: automatable = true, automation sufficient = true, manual test = true

Rationale: PR #19584 changes selectedViewIdFor and isViewDirty in shell/utils/table-views/views.ts so that, before any tab is picked, the table's own tab stays in front and is judged dirty against the table as it comes. Unit tests cover both repro scenarios and the regressions around them.

Evidence found (PR #19584): unit, shell/components/TableViews/__tests__/TableViewTabs.test.ts

• selectedViewIdFor(saved, applied, undefined) now returns null, so before a pick the table's own tab stays in front even when it holds a saved view's config ✅
• "should keep a filter typed on the table's own tab before any pick there, when it is a saved view's": isDirty is true, and switching to that view and back keeps the filter (scenario 2) ✅
• "should leave the changes on the table's own tab when it is saved as a new view before any tab is picked" (scenario 1) ✅. This test was later changed by #19630 / #19628 so the draft is cleared, which is intended there.
• The import test was updated to use initialViewId: 'aaa', which keeps the picked-view path covered ✅

Why manual testing is still needed: table views involve heavy interaction between the tab bar, tab menus, unsaved-changes indicators and reloads. The bug only appears on a fresh reload before any tab is clicked, which unit tests simulate only by leaving out initialViewId. Run both repro steps on Deployments after a hard reload.

Residual risk: a saved view used to be selected automatically when the table's config matched it (for example from a shared link or the default view on load). Check that the default view and linked queries still select the expected tab.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

Decision: automatable = true, automation sufficient = false, manual test = true

Evidence found (PR #19570)

• shell/core/__tests__/plugin-helpers-context.test.ts (new, unit), testing context matching through getApplicableExtensionEnhancements:
  • an exact match still works ✅
  • extra context keys are ignored ✅
  • a wrong value or a missing key doesn't match ✅
  • a nested annotation subset matches ✅
  • a nested value that differs or is missing doesn't match ✅
  • no context at all doesn't match ✅
  • arrays are compared exactly ✅
  • an empty requirement always matches ✅
  • context is combined (AND) with resource ✅
• shell/edit/auditlog.cattle.io.auditpolicy/__tests__/__snapshots__/Filters.test.ts.snap: snapshot update only (usercbutton="false").

Gaps and suggested tests

1. unit: shell/detail/__tests__/provisioning.cattle.io.cluster.test.ts. Assert that extCustomParams contains the cluster's metadata.annotations in three cases: no provisioner extension (only { annotations }), a provisioner extension ({ provider, annotations }), and a model extension (customProvisionerHelper). Also assert annotations default to {} when metadata has none. This is the core of the issue and is currently untested.
2. unit: shell/components/form/__tests__/ArrayList.test.ts.
   • With useRcButton: true, the add control is an RcButton with the ${componentTestid}-button test id and addIcon.
   • With removeAllowed: false, rows get the renamed hide-remove class.
   • The columns slot receives a working remove callback.
3. unit: shell/components/form/__tests__/ArrayListGrouped.test.ts.
   • With useRc: true, each item renders an RcSection titled by getItemTitle(scope).
   • The RcSectionActions trash action removes that row.
   • The legacy remove button isn't rendered.
   • With useRc: false, InfoBox is still used.
4. unit: MatchExpressions, NodeAffinity, PodAffinity and NameNsDescription.
   • useRc swaps the add and remove buttons for RcButton and keeps the input-match-expression-add-rule test id.
   • NodeAffinity and PodAffinity pass node-selector-{i} / pod-selector-{i} titles.
   • descriptionColSpan overrides the default span-3/span-6.
5. e2e: regression guard for shared form components. In the workload create Scheduling tab and the Role Template edit page (RoleDetailEdit.vue, where the mr-20 and margin-right: 75px rules were removed), assert node and pod selector terms can still be added and removed, and that the role rule column headers line up with their inputs.

Why manual testing is still needed:

• Public extension API change. context matching moved from exact equality to a recursive subset match, so existing extensions that name fewer keys now match more widely.
• Untested shared components. The PR also changes widely used form components (ArrayList, ArrayListGrouped, MatchExpressions, Node/PodAffinity), mostly without tests.
• Built-in hosted-provider tabs. Check that the AKS, EKS and GKE detail tabs still appear only on their own cluster type.
• Annotation-gated tab. Check that a test extension tab gated on an annotation appears and disappears as the annotation changes.
• Form layouts. Check the workload scheduling and Role Template forms for layout regressions.

Residual risk: any ArrayList consumer that passes removeAllowed: false now gets the narrower hide-remove grid layout.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.

Automated tests appear sufficient for this issue. A round of manual tests is still required.

Decision: automatable = true, automation sufficient = true, manual test = true

Rationale: PR #19612 moves the lookup of the installed app (from appNamespace and appName) above the if (!this.chart) return check in shell/mixins/chart.js. That restores existing, so showSelectVersionOrChart is true again. The unit tests cover the root cause, the condition that controls the dropdown, and the new exception for managed apps.

Evidence found (PR #19612): unit

• shell/mixins/__tests__/chart.test.ts, "when the chart of an installed app cannot be found":
  • cluster/find is still dispatched for app-ns/app-name ✅
  • existing is set ✅
  • mode is edit ✅
• shell/pages/c/_cluster/apps/charts/__tests__/install.test.ts, showSelectVersionOrChart: the four combinations of regular or managed app and chart found or missing, including the new rule that managed apps whose chart is missing get no selector ✅
• fetch() when the chart is missing: the first step's Next button is disabled ✅

Why manual testing is still needed: chart install and upgrade is a core multi-step flow, and the PR reorders fetchChart, so the app is now looked up before the chart and version info. Run the repro steps (install from a repo, remove the repo, Edit/Upgrade) and check:

• the Chart dropdown lists the available charts
• picking a chart enables the Version dropdown and Next
• a normal upgrade of an app whose chart is found still works
• a Rancher- or Fleet-managed app shows the managed warning without a chart selector

Residual risk: existing.fetchValues(true) now runs before the chart is resolved, so the values and YAML prefill on upgrade should still match what was there before.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

Automated tests appear sufficient for this issue. No manual tests required.

Decision: automatable = true, automation sufficient = true, manual test = false

Rationale: the fix in PR #19630 adds forgetDraft(tab.id) after duplicateView in openSaveAsNew (shell/components/TableViews/TableViewTabs.vue). The source tab's unsaved draft is thrown away and not saved onto that view, which matches what was agreed in the comments ("left as saved = discard changes").

Evidence found (PR #19630): unit, shell/components/TableViews/__tests__/TableViewTabs.test.ts

• "should save that tab's changes as a new view, leaving that tab as saved": the new view has the query, drafts.bbb is undefined, and the tab that was in front keeps its own draft (drafts.aaa), which is the edge case of another tab's changes ✅
• "should leave the tab in front as saved once its changes are saved as a new view": the new view gets the changes, the source view's stored query is unchanged (not overwritten), and its draft is cleared ✅
• "...before any tab is picked": the table's own tab (__default) draft is cleared too ✅

Manual testing: not needed. The change is a single targeted line, and the tests check both that the stored source view is unchanged and that the draft is cleared, for saved views and for the table's own tab.

Residual risk (low): this deliberately reverses an assertion added in #19584 ("leave them on that tab too"). Make sure no other flow relied on the source keeping its draft.

This analysis was generated automatically based on unit and e2e evidence linked to this issue.

A round of manual tests is required. Automated tests are not yet sufficient for this issue.

Please address the feedback from the QA Review Decision Model:

Decision: automatable = true, automation sufficient = false, manual test = true

Evidence found (PR #19630): unit

• shell/utils/table-views/__tests__/query-history.test.ts (new). It covers:
  • undo and redo a word at a time, and nothing past either end ✅
  • a new step after a pause ✅
  • grouping a run of deletions ✅
  • typing over a selection ✅
  • paste, cut, suggestion and clear as steps of their own ✅
  • dropping the redo stack after a new change ✅
  • caret position on undo and redo ✅
  • reset ✅
  • changeOf mapping ✅
• shell/components/TableViews/__tests__/TableViewQueryInput.test.ts, "undo and redo":
  • Ctrl+Z, Ctrl+Shift+Z and Ctrl+Y ✅
  • Edit-menu historyUndo via beforeinput ✅
  • history reset when historyKey changes ✅

Gaps and suggested tests

1. unit: Mac shortcuts (acceptance criterion: Cmd+Z / Cmd+Shift+Z). Mock @shell/utils/platform so isMac is true. Assert that metaKey + z undoes and metaKey + shift + z redoes. Also assert that on a Mac ctrlKey + z and metaKey + y do nothing, and that on other platforms metaKey + z does nothing.
2. unit: guards in historyStep. Assert that a shortcut with altKey is ignored, and that an undo keypress during an IME composition (compositionstart without compositionend) is ignored. Also assert that historyRedo from beforeinput redoes.
3. unit: external value changes reset the history. After typing, setProps({ value: 'other' }) from outside (a tab switch or a link) and assert that Ctrl+Z doesn't emit, so undo can't jump back into another view's query. Also check that the ResourceTable → TableViewControls → TableViewQueryInput chain passes historyKey through as tabViewChanges increments.
4. e2e: Cypress on a table-views list (for example Deployments).
   • Type state:active name:web, then press Ctrl+Z and assert the box shows state:active.
   • Press Ctrl+Shift+Z and assert it shows state:active name:web again.
   • Delete a word in the middle and press Ctrl+Z; assert the text comes back in place.
   • Switch tabs, then press Ctrl+Z; assert the other tab's query isn't undone.

Why manual testing is still needed: the box is a contenteditable with highlighting, and the user-visible behavior depends heavily on the browser and OS. That includes where the caret lands in the real DOM (the original bug put text back "in the wrong place"), the macOS Edit menu, IME composition, and Chrome, Firefox and Safari differences. jsdom can't fully reproduce these.

Residual risk: the custom history fully replaces the browser's own undo, so spell-check replacements (insertReplacementText) and drag-and-drop now each record a separate step. Check they undo cleanly.

This comment was generated automatically to highlight missing automated coverage and suggest next tests to add.