Bug: Menu items added by ProductChildResourcePage break explorer links

[richard-cox]

Setup

• Rancher version: v2.15.0 (dev of)

Describe the bug

• create an extension with a product with a ProductChildResourcePage pointing to a resource, say pods
• the explorer product's pods link points to the extension product's pod list
• clicking on it takes the user from the explorer view to the extension view
• resource links should retain the current product

To Reproduce

  const product: ProductMetadata = { name: 'product-1', label: 'Product One' };
  const childResourcePage: ProductChildResourcePage = { type: 'pod' };

  plugin.addProduct(product, [childResourcePage]);

• Navigate to any cluster --> Workloads --> Pods

Result

• User taken to the extension product's pods page

Expected Result

• User stay in the explorer product and sees the pods list

Screenshots

[github-actions]

🎯 Agentic Issue Triage

Summary: When an extension product registers a ProductChildResourcePage for a resource type (e.g. pod), it calls configureType with a customRoute pointing to the extension product. Because configureType stores configurations globally in the type-map Vuex store (not scoped per product), this overrides the Explorer product's navigation route for that same resource type — causing Explorer menu links to redirect users into the extension product.

📍 Root Cause Analysis

The call chain is:

1. plugin.addProduct(product, [childResourcePage]) → plugin-products-base.ts → configureType(typeValue, { customRoute: route })
2. configureType commits to type-map Vuex store (state.typeOptions array), keyed only by resource type string (e.g. "pod"), not scoped by product.
3. The type-map getter at type-map.js:998 reads typeOptions.customRoute and sets it as the route for the menu nav item — regardless of which product is currently active.
4. Result: the Explorer product's pod link now uses the extension product's custom route.

Key files:

• shell/core/plugin-products-base.ts ~line 304 — where configureType is called with customRoute
• shell/store/type-map.js ~line 292, 998, 1786 — global configureType storage and customRoute lookup
• shell/core/plugin-products-helpers.ts ~line 123–177 — route generation for resource pages

🔧 Suggested Fix Direction

The customRoute stored via configureType needs to be product-scoped. Possible approaches:

1. Scope configureType per product: Attach a product key to configureType options, and when generating nav items, only apply customRoute if it belongs to the current active product. This is the safest fix with the least collateral impact.

2. Don't use configureType/customRoute for extension resource pages: Instead, have extension nav items use virtualType with explicit routes (similar to how custom pages work), bypassing the global type-map customRoute mechanism entirely.

3. Override only within product context: Ensure that when Explorer generates its nav for a type, it ignores any customRoute registered by a different product — possibly by checking route.meta.product against the current product.

🔁 Reproduction Steps

1. Install an extension that registers a product with a ProductChildResourcePage pointing to an existing K8s type (e.g. pod):

   const product: ProductMetadata = { name: 'product-1', label: 'Product One' };
   const childResourcePage: ProductChildResourcePage = { type: 'pod' };
   plugin.addProduct(product, [childResourcePage]);

2. Navigate to a cluster → Workloads → Pods in the Explorer product.
3. Observe: clicking "Pods" in Explorer's sidebar redirects the user to the extension product's pods list instead of staying in Explorer.

🧪 Testing Considerations

Since this issue already has QA/dev-automation, the fix should include a unit test in shell/core/__tests__/plugin-products.test.ts verifying that:

• configureType with a customRoute from an extension product does not affect the Explorer product's nav item route for the same type.

A Cypress E2E test could also verify the navigation behavior end-to-end, following the reproduction steps above.

📚 Relevant Code References

• shell/core/plugin-products-base.ts — configureType call with customRoute
• shell/store/type-map.js — global configureType store and customRoute usage in nav generation
• shell/core/plugin-products-helpers.ts — route generation helpers for ProductChildResourcePage
• shell/core/plugin-types.ts — ProductChildResourcePage type definition
• Extensions docs — Product Registration

✅ Suggested Sub-tasks

• Decide on fix approach (scope configureType per product vs. alternative mechanism for extension resource pages)
• Implement fix so that extension customRoute does not bleed into other products' nav for the same type
• Add unit test in shell/core/__tests__/plugin-products.test.ts covering this scenario
• Manually verify Explorer's pod/workload links are unaffected when extension with overlapping type is installed
• Check if other resource types (not just pod) are similarly affected

Generated by Agentic Triage for issue #17400 · ● 526.2K · ◷

[github-actions]

🤖 Issue grooming analysis

This issue is well-groomed and ready for triage. Here's the analysis:

✅ Clear Problem Statement
The title and description clearly identify the bug: menu items registered via ProductChildResourcePage in an extension product override the explorer product's resource links, causing navigation to redirect users into the extension product when they intended to stay in the explorer.

✅ Acceptance Criteria
The expected result is concrete and verifiable: resource links (e.g., pods) navigated from within the explorer product must stay within the explorer product and not redirect to an extension product's view.

✅ Technical Details
The specific API component (ProductChildResourcePage) is identified with a minimal, self-contained code snippet showing exactly how to trigger the problem. The affected area (extension product routing vs. explorer navigation) is clear, and the Rancher version (v2.15.0 dev) is stated.

✅ Reproducibility
Numbered reproduction steps are provided along with expected vs. actual behavior and supporting screenshots.

This analysis was generated automatically based on the repository's grooming checklist.

Note

🔒 Integrity filter blocked 8 items

The following items were blocked because they don't meet the GitHub integrity level.

• Screen not refreshing after updates #17298 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• [AI] Create E2E test automation for rancher-ai-ui #17107 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• Bug: "Mark all as read" button in Notification Center wipes URL hash fragment #16923 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• Support configuring cpu model when creating harvester guest cluster #16187 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• Spacing is wrong on node pools section when provisioning/editing EKS cluster #13888 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• Cluster Drivers list is not displaying the drivers in first access from a selected driver #13297 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• UI should display clear permission denied error messages #11263 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• Rename Azure AD to Entra ID #9963 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

Generated by Daily Issue Grooming · ● 397.5K · ◷