[Customer Portal][FE][Web] Refactor case fetching with server-side filtering and pagination using new project hooks - #578
Conversation
Increase cache for project filter metadata (staleTime -> 5 minutes) and switch Support/Operations pages to use useGetProjectFilters + useGetProjectCasesPage. Resolve non-closed status IDs from filter metadata and pass them as statusIds to the cases queries, gating queries until filter metadata is available. Update loading flags and simplify client-side filtering (remove manual closed-status filtering and pagination workarounds). Also adjust OutstandingCasesList container layout to use flex sizing so it can grow/scroll correctly.
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 46 minutes and 13 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughUpdates React Query cache staleness for project filters to 5 minutes and refactors OperationsPage and SupportPage to fetch filter metadata and derive default non-closed status filters, shifting case fetching from client-side filtering and pagination to server-side pagination via Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
dileepapeiris
added
Type/Improvement
dileepapeiris
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/customer-portal/webapp/src/features/support/pages/SupportPage.tsx (1)
82-117:⚠️ Potential issue | 🟠 MajorS0 client-side filtering can now shrink the outstanding list below
SUPPORT_OVERVIEW_CASES_LIMIT.The server is asked for exactly
SUPPORT_OVERVIEW_CASES_LIMIT(5) cases viauseGetProjectCasesPage(..., 0, SUPPORT_OVERVIEW_CASES_LIMIT, ...), and then — whenincludeS0InSupportMetrics === false— S0 cases are stripped on the client (lines 113–117). With the removed fetch-more effect, there is no longer anything to backfill the page.Consequence: for projects that hide S0 from support metrics, the Outstanding Cases card will often display 0–4 items even when plenty of non-S0 outstanding cases exist beyond the first 5, and the user has no way to load more from this card. This is a UX regression versus the previous infinite-pagination + "keep fetching until we have enough non-S0 cases" flow.
Preferred fix: exclude S0 server-side by extending the
filtersin the request (e.g., aseverityIds/excludeSeverityIdsfilter derived fromfilterMetadata) so the backend returns 5 already-filtered cases. If that isn't available yet, over-fetching (e.g.,limit: SUPPORT_OVERVIEW_CASES_LIMIT * 2and then.slice(0, SUPPORT_OVERVIEW_CASES_LIMIT)after S0 removal) is a pragmatic interim workaround but still not a full fix.Also note: the empty-
statusIdsconcern and the filter-metadata-error-masking concern raised onOperationsPage.tsxapply verbatim to this file (lines 77–98).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/customer-portal/webapp/src/features/support/pages/SupportPage.tsx` around lines 82 - 117, The outstanding-cases list is being truncated by client-side S0 filtering after requesting exactly SUPPORT_OVERVIEW_CASES_LIMIT via useGetProjectCasesPage; update the request to exclude S0 server-side (preferred) by adding an appropriate severity/excludeSeverity filter derived from filterMetadata to the filters object passed to useGetProjectCasesPage so the backend returns already-filtered results, referencing useGetProjectCasesPage, filters, filterMetadata, nonClosedStatusIds, and includeS0InSupportMetrics; if backend filtering isn't available yet, pragmatically over-fetch (e.g., request SUPPORT_OVERVIEW_CASES_LIMIT * 2) and then apply the current client-side filter (isS0Case) and slice the result to SUPPORT_OVERVIEW_CASES_LIMIT, and also ensure you handle empty statusIds and surface filter-metadata errors instead of masking them as noted similarly in OperationsPage.tsx.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@apps/customer-portal/webapp/src/features/operations/pages/OperationsPage.tsx`:
- Around line 98-130: The filters fetch error is currently hidden because
OperationsPage only reads useGetProjectFilters' data but not its error state;
update the hook call to also destructure isError (e.g., const { data:
filterMetadata, isLoading: isFilterMetadataLoading, isError:
isFilterMetadataError } = useGetProjectFilters(projectId || ""); then include
that error when deciding SR loading/error: compute isSrLoading = isSrDataLoading
|| isFilterMetadataLoading and compute combinedIsSrError = isSrError ||
isFilterMetadataError (or pass isError={isSrError || isFilterMetadataError}
directly to the SupportOverviewCard); ensure the cases query gating (enabled)
still uses filterMetadata !== undefined but surface filter errors to the card by
wiring the new combined error into the card's isError prop.
---
Outside diff comments:
In `@apps/customer-portal/webapp/src/features/support/pages/SupportPage.tsx`:
- Around line 82-117: The outstanding-cases list is being truncated by
client-side S0 filtering after requesting exactly SUPPORT_OVERVIEW_CASES_LIMIT
via useGetProjectCasesPage; update the request to exclude S0 server-side
(preferred) by adding an appropriate severity/excludeSeverity filter derived
from filterMetadata to the filters object passed to useGetProjectCasesPage so
the backend returns already-filtered results, referencing
useGetProjectCasesPage, filters, filterMetadata, nonClosedStatusIds, and
includeS0InSupportMetrics; if backend filtering isn't available yet,
pragmatically over-fetch (e.g., request SUPPORT_OVERVIEW_CASES_LIMIT * 2) and
then apply the current client-side filter (isS0Case) and slice the result to
SUPPORT_OVERVIEW_CASES_LIMIT, and also ensure you handle empty statusIds and
surface filter-metadata errors instead of masking them as noted similarly in
OperationsPage.tsx.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: ac447bc1-34a6-41bc-98f8-35c8e9349355
📒 Files selected for processing (3)
apps/customer-portal/webapp/src/api/useGetProjectFilters.tsapps/customer-portal/webapp/src/features/operations/pages/OperationsPage.tsxapps/customer-portal/webapp/src/features/support/pages/SupportPage.tsx
Aggregate error states so the UI reflects failures from either service requests or filter metadata. This adds isFilterMetadataError from useGetProjectFilters, computes combinedIsSrError = isSrError || isFilterMetadataError, and passes combinedIsSrError to the OutstandingCasesList isError prop to surface errors from either source.
Destructure isError from useGetProjectFilters and introduce combinedIsCasesError (isCasesError || isFilterMetadataError). Use this combined flag for the list component's isError prop so the UI reports an error when either cases or filter metadata fetching fails.
2 participants
Description
This pull request refactors how project cases are fetched and filtered in both the Operations and Support pages of the customer portal. It introduces the use of
useGetProjectFiltersanduseGetProjectCasesPagehooks to improve filtering logic, especially for excluding closed cases, and simplifies the code by removing manual filtering and pagination logic.API and Filtering Improvements:
useGetProjectCaseshook with the newuseGetProjectCasesPagehook in bothOperationsPage.tsxandSupportPage.tsx, enabling more efficient server-side filtering and pagination. [1] [2]useGetProjectFiltershook to fetch filter metadata (such as case states) and usesresolveCasesTableDefaultStatusIdsto dynamically determine non-closed status IDs for filtering cases. [1] [2]Code Simplification and Cleanup:
UI and Styling Adjustments:
Performance Improvements:
staleTimefor project filters to 5 minutes, reducing unnecessary refetching and improving performance.Dependency Updates:
These changes collectively improve code maintainability, performance, and the accuracy of case filtering in the customer portal.