[CSM Portal] remove runtime mock-data mode and its dead filters - #931
Conversation
|
Warning Review limit reached
More reviews will be available in 44 minutes and 59 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (33)
📝 WalkthroughWalkthroughRemoves the entire mock-mode system (context, provider, toggle UI, seeded data files, ChangesMock-mode removal and case-type filter
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 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 |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
apps/csm-portal/webapp/src/features/csm-dashboard/api/useCaseCountsMatrix.ts (1)
91-103: 🚀 Performance & Scalability | 🟠 Major | 🏗️ Heavy liftThis turns one dashboard load into a large search fan-out.
This hook now does one
/cases/searchcall per matrix cell, anduseCaseCompositionadds another per-severity/per-state count wave on the same page. After removing mock mode, a dashboard refresh now fans out into many live backend searches instead of one aggregated read, which is likely to dominate both page latency and backend load. Please collapse these counts behind a single aggregate endpoint (or reuse an existing dashboard payload) before shipping.🤖 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 `@apps/csm-portal/webapp/src/features/csm-dashboard/api/useCaseCountsMatrix.ts` around lines 91 - 103, The counting logic in useCaseCountsMatrix is issuing one /cases/search request per matrix cell, which creates a heavy fan-out on dashboard load. Refactor the counting path to use a single aggregated backend call or reuse an existing dashboard payload instead of mapping over cells and calling api.post repeatedly; keep the result shaping in useCaseCountsMatrix and align any related counting flow in useCaseComposition to share the same aggregated source.apps/csm-portal/webapp/src/features/csm-cases/components/CasesFilterBar.tsx (1)
261-261: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winAlign the search placeholder with the live backend contract.
Line 261 still advertises customer, project, and assignee search, but the live
searchQueryonly covers case number/subject/WSO2 ID. Now that the mock/client-side path is gone, this copy will send users down unsupported paths.💡 Suggested copy update
- placeholder="Search by case #, subject, customer, project, assignee…" + placeholder="Search by case #, subject, or WSO2 case ID…"🤖 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 `@apps/csm-portal/webapp/src/features/csm-cases/components/CasesFilterBar.tsx` at line 261, The search placeholder in CasesFilterBar should match the live backend search scope, since searchQuery now only supports case number, subject, and WSO2 ID. Update the placeholder text in CasesFilterBar to remove customer, project, and assignee references and keep it aligned with the actual supported fields.
🧹 Nitpick comments (1)
apps/csm-portal/webapp/src/features/csm-cases/utils/caseType.ts (1)
24-40: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDerive
ALL_CASE_TYPESfrom the label map.These two exports duplicate the same key set, so the next type addition can easily update one and forget the other. That would make
casesFiltersUrl.tsaccept a different set of values thanCasesFilterBar.tsxcan render. Keeping one source of truth here avoids that drift.♻️ Suggested refactor
-/** All case types, in the order they appear in the type dropdown. */ -export const ALL_CASE_TYPES: BeCaseType[] = [ - "support", - "service_request", - "security_report_analysis", - "announcement", - "engagement", -]; - /** Human-readable label per case type. */ export const CASE_TYPE_LABEL: Record<BeCaseType, string> = { support: "Support", service_request: "Service request", security_report_analysis: "Security report", announcement: "Announcement", engagement: "Engagement", }; + +/** All case types, in the order they appear in the type dropdown. */ +export const ALL_CASE_TYPES = Object.keys(CASE_TYPE_LABEL) as BeCaseType[];🤖 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 `@apps/csm-portal/webapp/src/features/csm-cases/utils/caseType.ts` around lines 24 - 40, The case type list and label map in caseType.ts duplicate the same keys, which can drift out of sync. Update ALL_CASE_TYPES to be derived from CASE_TYPE_LABEL so there is one source of truth for the BeCaseType set, and keep CASE_TYPE_LABEL as the canonical map used by CasesFilterBar.tsx and casesFiltersUrl.ts. Ensure any new case type only needs to be added once in CASE_TYPE_LABEL and ALL_CASE_TYPES updates automatically.
🤖 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.
Outside diff comments:
In `@apps/csm-portal/webapp/src/features/csm-cases/components/CasesFilterBar.tsx`:
- Line 261: The search placeholder in CasesFilterBar should match the live
backend search scope, since searchQuery now only supports case number, subject,
and WSO2 ID. Update the placeholder text in CasesFilterBar to remove customer,
project, and assignee references and keep it aligned with the actual supported
fields.
In
`@apps/csm-portal/webapp/src/features/csm-dashboard/api/useCaseCountsMatrix.ts`:
- Around line 91-103: The counting logic in useCaseCountsMatrix is issuing one
/cases/search request per matrix cell, which creates a heavy fan-out on
dashboard load. Refactor the counting path to use a single aggregated backend
call or reuse an existing dashboard payload instead of mapping over cells and
calling api.post repeatedly; keep the result shaping in useCaseCountsMatrix and
align any related counting flow in useCaseComposition to share the same
aggregated source.
---
Nitpick comments:
In `@apps/csm-portal/webapp/src/features/csm-cases/utils/caseType.ts`:
- Around line 24-40: The case type list and label map in caseType.ts duplicate
the same keys, which can drift out of sync. Update ALL_CASE_TYPES to be derived
from CASE_TYPE_LABEL so there is one source of truth for the BeCaseType set, and
keep CASE_TYPE_LABEL as the canonical map used by CasesFilterBar.tsx and
casesFiltersUrl.ts. Ensure any new case type only needs to be added once in
CASE_TYPE_LABEL and ALL_CASE_TYPES updates automatically.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: b377612b-0a9c-4c39-8da2-bba6622e0316
📒 Files selected for processing (34)
apps/csm-portal/webapp/src/AppWithConfig.tsxapps/csm-portal/webapp/src/api/backend/client.tsapps/csm-portal/webapp/src/api/useDirectoryUsers.tsapps/csm-portal/webapp/src/components/header/Actions.tsxapps/csm-portal/webapp/src/components/header/MockModeToggle.tsxapps/csm-portal/webapp/src/config/authConfig.tsapps/csm-portal/webapp/src/context/mock-mode/MockModeContext.tsxapps/csm-portal/webapp/src/features/csm-cases/api/mocks/casesMocks.tsapps/csm-portal/webapp/src/features/csm-cases/api/mocks/commentsMocks.tsapps/csm-portal/webapp/src/features/csm-cases/api/useCsmCaseAttachments.tsapps/csm-portal/webapp/src/features/csm-cases/api/useCsmCaseComments.tsapps/csm-portal/webapp/src/features/csm-cases/api/useFindMyOngoingCases.tsapps/csm-portal/webapp/src/features/csm-cases/api/useGetCsmCaseDetail.tsapps/csm-portal/webapp/src/features/csm-cases/api/useGetCsmCases.tsapps/csm-portal/webapp/src/features/csm-cases/api/usePatchCsmCase.tsapps/csm-portal/webapp/src/features/csm-cases/api/usePostCsmCase.tsapps/csm-portal/webapp/src/features/csm-cases/api/useQuickCaseSearch.tsapps/csm-portal/webapp/src/features/csm-cases/components/CaseActionBar.test.tsxapps/csm-portal/webapp/src/features/csm-cases/components/CasesFilterBar.tsxapps/csm-portal/webapp/src/features/csm-cases/pages/CsmCaseDetailPage.tsxapps/csm-portal/webapp/src/features/csm-cases/pages/CsmCasesPage.tsxapps/csm-portal/webapp/src/features/csm-cases/types/csmCases.tsapps/csm-portal/webapp/src/features/csm-cases/utils/caseType.tsapps/csm-portal/webapp/src/features/csm-cases/utils/casesClientFilter.tsapps/csm-portal/webapp/src/features/csm-cases/utils/casesFiltersUrl.test.tsapps/csm-portal/webapp/src/features/csm-cases/utils/casesFiltersUrl.tsapps/csm-portal/webapp/src/features/csm-dashboard/api/mocks/dashboardMocks.tsapps/csm-portal/webapp/src/features/csm-dashboard/api/useCaseComposition.tsapps/csm-portal/webapp/src/features/csm-dashboard/api/useCaseCountsMatrix.tsapps/csm-portal/webapp/src/features/csm-dashboard/api/useGetCsmDashboard.tsapps/csm-portal/webapp/src/features/csm-dashboard/components/MyQueueSection.tsxapps/csm-portal/webapp/src/features/csm-dashboard/components/SlaAtRiskSection.tsxapps/csm-portal/webapp/src/main.tsxapps/csm-portal/webapp/vite.config.ts
💤 Files with no reviewable changes (13)
- apps/csm-portal/webapp/src/main.tsx
- apps/csm-portal/webapp/src/features/csm-dashboard/components/MyQueueSection.tsx
- apps/csm-portal/webapp/src/api/useDirectoryUsers.ts
- apps/csm-portal/webapp/src/features/csm-cases/api/mocks/casesMocks.ts
- apps/csm-portal/webapp/src/features/csm-cases/utils/casesClientFilter.ts
- apps/csm-portal/webapp/src/components/header/MockModeToggle.tsx
- apps/csm-portal/webapp/src/config/authConfig.ts
- apps/csm-portal/webapp/src/features/csm-dashboard/api/mocks/dashboardMocks.ts
- apps/csm-portal/webapp/src/components/header/Actions.tsx
- apps/csm-portal/webapp/src/features/csm-cases/api/mocks/commentsMocks.ts
- apps/csm-portal/webapp/src/api/backend/client.ts
- apps/csm-portal/webapp/src/context/mock-mode/MockModeContext.tsx
- apps/csm-portal/webapp/src/features/csm-dashboard/components/SlaAtRiskSection.tsx
Remove the header mock-vs-live toggle and the entire mock data layer: the MockModeToggle + MockModeProvider, isMockMode() and its branches in every data hook, the seeded cases/comments/dashboard mock modules, and the mock-only client-side cases filter. The app now always calls the live backend. With mock data gone, drop the cases-filter controls that only ever worked against it and have no live /cases/search support: the My-ABT/ All-customers scope toggle, and the SLA and product filters (plus the orphaned, never-rendered MyQueueSection / SlaAtRiskSection dashboard widgets built around them). The assignee filter is KEPT (disabled with a 'coming soon' note) — it will be wired to the live backend in a follow-up. The cases filter keeps search, severity, state, and project, all backed by the search API.
|
@coderabbitai review |
✅ Action performedReview finished.
|
What
Removes the runtime mock-data mode (the header Mock/Live toggle) and the entire seeded-mock layer, so the app always talks to the live backend.
Removed:
isMockMode()and its branches in every data hook.With the mock data gone, this also drops the cases-filter controls that only ever worked against it and have no live
/cases/searchsupport:MyQueueSection/SlaAtRiskSectiondashboard widgets built around those filters.The assignee filter is kept (left disabled with a "coming soon" note); it is wired to the live backend in the stacked follow-up PR. The cases filter keeps search, severity, state, and project — all backed by the search API.
Merge order
This PR is independent of the case-filters PR and is intended to merge first. The case-type + assignee work stacks on top of it.
Testing
pnpm lint,pnpm test,pnpm build,tsc -ball green.