feat(apiproduct): add Accepted Paths tab to API Product details#539
feat(apiproduct): add Accepted Paths tab to API Product details#539namansh70747 wants to merge 1 commit into
Conversation
Adds an Accepted Paths tab to the API Product details page that lists the method + path patterns the product exposes (KuadrantGH-535). As the issue notes, this information comes from the HTTPRoute referenced by spec.targetRef. The tab watches that route and flattens its spec.rules[].matches[] into one row per (method, path) pair, following the Gateway API defaults: a rule with no matches accepts all paths, and a match with no method accepts all methods. It reuses the cached-targetRef + useK8sWatchResource pattern and the loading/empty/error lifecycle already established in APIProductPoliciesTab, and the shared HTTPRouteMatch types from ratelimitpolicy. Registered as a new console.tab/horizontalNav extension alongside the existing API Product tabs. Refs Kuadrant#535 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Naman Sharma <namsh70747@gmail.com>
📝 WalkthroughWalkthroughAdds an Accepted Paths tab to APIProduct details, exposes the new component module, and renders HTTPRoute-derived method/path rows with permission, loading, error, and empty states. Matching English locale strings are added. ChangesAPIProduct Accepted Paths Tab
Sequence Diagram(s)sequenceDiagram
participant APIProductAcceptedPathsTab
participant APIProduct
participant HTTPRoute
participant AcceptedPathRow
APIProductAcceptedPathsTab->>APIProduct: watch APIProduct and read spec.targetRef
APIProduct-->>APIProductAcceptedPathsTab: targetRefToUse
APIProductAcceptedPathsTab->>HTTPRoute: watch referenced HTTPRoute
HTTPRoute-->>APIProductAcceptedPathsTab: spec.rules
APIProductAcceptedPathsTab->>AcceptedPathRow: render method, path, and match type
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
⚔️ Resolve merge conflicts
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install failed. For unrecoverable errors, disable the tool in CodeRabbit configuration. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
is this ready for review? |
Yes |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/components/apiproduct/APIProductAcceptedPathsTab.tsx`:
- Around line 98-107: The HTTPRoute fetch in APIProductAcceptedPathsTab should
be gated by its own RBAC check instead of always starting the watch. Add a
`useAccessReviews` check for the referenced `HTTPRoute` before calling
`useK8sWatchResource`, and only render/load the route when access is allowed.
Update the `httpRoute`/load-error handling around the `useK8sWatchResource` and
the error UI near the existing load-error branch so users without route
permissions see the correct permission state rather than a generic load failure.
- Around line 60-69: The access-review and fallback lookups in
APIProductAcceptedPathsTab should not depend on the global activeNamespace;
instead, derive the APIProduct’s namespace from the current route/resource
context and use that for the useAccessReview call and related resource queries.
Update the logic around useLocation, extractResourceNameFromURL, and the
APIProduct/HTTPRoute fallback paths so targetRef.namespace falls back to the
resource namespace rather than activeNamespace, ensuring the tab works in both
single-namespace and `#ALL_NS`# modes.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 78ec5191-a918-4226-b8ca-03b880f8d208
📒 Files selected for processing (4)
console-extensions.jsonlocales/en/plugin__kuadrant-console-plugin.jsonpackage.jsonsrc/components/apiproduct/APIProductAcceptedPathsTab.tsx
| const [activeNamespace] = useActiveNamespace(); | ||
| const location = useLocation(); | ||
| const productName = extractResourceNameFromURL(location.pathname); | ||
|
|
||
| const [canGet, canGetLoading] = useAccessReview({ | ||
| group: RESOURCES.APIProduct.gvk.group, | ||
| resource: getResourceNameFromKind(RESOURCES.APIProduct.gvk.kind), | ||
| verb: 'get', | ||
| namespace: activeNamespace, | ||
| name: productName, |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Use the resource’s namespace here, not activeNamespace.
Line 60 makes the watch/access-review namespace depend on the global namespace selector, but this is a named details view. In #ALL_NS# mode, or after switching projects, the tab can query the wrong namespace and fail to load both the APIProduct and its fallback HTTPRoute. Derive the APIProduct namespace from the route/resource context, then fall back from targetRef.namespace to that namespace instead of activeNamespace.
As per coding guidelines, “Support namespace handling for both single namespace and all-namespaces mode (#ALL_NS#) in resource queries”.
Also applies to: 73-79, 95-105
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/components/apiproduct/APIProductAcceptedPathsTab.tsx` around lines 60 -
69, The access-review and fallback lookups in APIProductAcceptedPathsTab should
not depend on the global activeNamespace; instead, derive the APIProduct’s
namespace from the current route/resource context and use that for the
useAccessReview call and related resource queries. Update the logic around
useLocation, extractResourceNameFromURL, and the APIProduct/HTTPRoute fallback
paths so targetRef.namespace falls back to the resource namespace rather than
activeNamespace, ensuring the tab works in both single-namespace and `#ALL_NS`#
modes.
Source: Coding guidelines
| // Fetch the target HTTPRoute | ||
| const [httpRoute, httprouteLoaded, httprouteLoadError] = useK8sWatchResource<RoutedHTTPRoute>( | ||
| targetRefToUse && targetRefToUse.kind === 'HTTPRoute' | ||
| ? { | ||
| groupVersionKind: RESOURCES.HTTPRoute.gvk, | ||
| namespace: httprouteNamespace, | ||
| name: httprouteName, | ||
| isList: false, | ||
| } | ||
| : null, |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Gate the HTTPRoute watch behind its own access review.
Line 99 starts the HTTPRoute watch without checking RBAC for that resource. If the user can read the APIProduct but not the referenced route, line 233 shows a generic load error instead of the expected permission state.
As per coding guidelines, “Use useAccessReviews hook to check RBAC permissions before rendering protected features”.
Also applies to: 230-235
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/components/apiproduct/APIProductAcceptedPathsTab.tsx` around lines 98 -
107, The HTTPRoute fetch in APIProductAcceptedPathsTab should be gated by its
own RBAC check instead of always starting the watch. Add a `useAccessReviews`
check for the referenced `HTTPRoute` before calling `useK8sWatchResource`, and
only render/load the route when access is allowed. Update the
`httpRoute`/load-error handling around the `useK8sWatchResource` and the error
UI near the existing load-error branch so users without route permissions see
the correct permission state rather than a generic load failure.
Source: Coding guidelines
2 participants
Description
Adds an Accepted Paths tab to the API Product details page, listing the method + path patterns the product exposes.
Fixes #535
Opening as a draft for review of the approach before final polish. The implementation is complete and passes lint/i18n/typecheck.
Type of change
[feat]New featureChanges made
APIProductAcceptedPathsTabcomponent. As the issue notes, the path information comes from the HTTPRoute referenced byspec.targetRef, so the tab watches that route and flattensspec.rules[].matches[]into one row per (method, path) pair.PathPrefix /), and a match with no method accepts all methods (shown as an "All methods" label).useK8sWatchResourcepattern and the full loading / no-permission / no-route / empty / error lifecycle already established inAPIProductPoliciesTab, plus the sharedHTTPRouteMatch/HTTPMethodtypes fromratelimitpolicy(rather than redefining them).console.tab/horizontalNavextension andexposedModulesentry alongside the existing API Product tabs.Columns
GET(color-coded label)/v1/carsPathPrefixTest plan
yarn lintpasses (no changes after running)yarn i18npasses (committed generated keys)yarn tsc --noEmitreports no errors insrc/Open question for reviewers
The issue notes "Consider whether this should also be displayed in the HTTPRoute details page" — that overlaps with #531 (HTTPRoute Enhanced Details). I scoped this PR to the API Product tab only; happy to factor the row-building logic into a shared helper if you want to reuse it for the HTTPRoute view too.
Checklist
t()and are in the locale file.pf-*/.co-*selectors or hex colorsconsole.logstatements left inSigned-off-by🤖 Generated with Claude Code
Summary by CodeRabbit