[CSM Portal Microapp] Add Operations page: Service Requests, Change Requests, Incidents - #1144
Conversation
|
Warning Review limit reached
Next review available in: 33 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?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 reviews. How do review 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 refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (18)
📝 WalkthroughWalkthroughThe operations page now provides service-request and change-request tabs, with search, filtering, infinite loading, cards, detail routing, and error recovery. Change requests also have typed API models, detail rendering, and editing for planned start and customer approval/review fields. ChangesOperations experience
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant Operator
participant OperationsPage
participant ChangeRequestsTab
participant changeRequests
participant ChangeRequestDetailPage
Operator->>OperationsPage: select Change Requests
OperationsPage->>ChangeRequestsTab: render list
ChangeRequestsTab->>changeRequests: search and load pages
changeRequests-->>ChangeRequestsTab: return change-request summaries
Operator->>ChangeRequestsTab: select a change request
ChangeRequestsTab->>ChangeRequestDetailPage: navigate with id
ChangeRequestDetailPage->>changeRequests: fetch detail
changeRequests-->>ChangeRequestDetailPage: return change-request details
Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ 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 |
…equests, Incidents placeholder Mirrors the webapp's Operations feature: Service Requests reuses the Support page's own case-list/filter infra scoped to type=service_request (severity dropped, work state kept — matches the webapp's CsmIssuesView behavior when locked to a non-case type); Change Requests gets its own list/filters/detail/ edit end-to-end; Incidents stays a placeholder since no backend endpoint exists for it anywhere. Also includes the getAllCases hasMore fallback fix (mirrors the same fix already applied to adminUsers.ts's searchUsers), needed for the Service Requests list to paginate past the first page.
48a4c4f to
66abd31
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
apps/csm-portal/microapp/src/components/operations/changeRequestFilters.ts (2)
35-42: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueCount the closed date range as a single filter.
A date range (start and/or end dates) is typically perceived by users as one logical filter. You can consolidate the count to make the UI filter badge more intuitive.
💡 Proposed refactor
export function countActiveCRFilters(filters: ChangeRequestFilters): number { return ( (filters.states.length > 0 ? 1 : 0) + (filters.impacts.length > 0 ? 1 : 0) + - (filters.closedStartDate ? 1 : 0) + - (filters.closedEndDate ? 1 : 0) + (filters.closedStartDate || filters.closedEndDate ? 1 : 0) ); }🤖 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/microapp/src/components/operations/changeRequestFilters.ts` around lines 35 - 42, Update countActiveCRFilters to count closedStartDate and closedEndDate together as one logical closed-date filter: return 1 when either date is set, rather than adding separate counts for each. Preserve the existing state and impact filter counts.
44-51: 🎯 Functional Correctness | 🔵 Trivial | 💤 Low valueTrim the search query to prevent sending whitespace-only queries.
If the
searchstring only contains whitespace,search.length > 0evaluates to true, sending a useless query to the backend. Trimming the string ensures that only meaningful queries are included in the payload.💡 Proposed refactor
export function toChangeRequestSearchFilters( search: string, filters: ChangeRequestFilters, ): ChangeRequestSearchPayloadDto["filters"] { + const trimmedSearch = search.trim(); return { - ...(search.length > 0 && { searchQuery: search }), + ...(trimmedSearch.length > 0 && { searchQuery: trimmedSearch }), ...(filters.states.length > 0 && { states: filters.states }), ...(filters.impacts.length > 0 && { impacts: filters.impacts }),🤖 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/microapp/src/components/operations/changeRequestFilters.ts` around lines 44 - 51, Update toChangeRequestSearchFilters to trim the search value before checking whether it is non-empty and assigning searchQuery, so whitespace-only input is omitted while meaningful queries are sent in trimmed form.
🤖 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
`@apps/csm-portal/microapp/src/components/operations/EditChangeRequestDialog.tsx`:
- Around line 46-58: The handleSave payload in EditChangeRequestDialog must
preserve a cleared planned start instead of dropping it. Update the
plannedStartOn condition to submit an explicit null when plannedStartChanged and
plannedStart is absent, while continuing to format and submit the selected date
when present.
In `@apps/csm-portal/microapp/src/services/changeRequests.ts`:
- Line 49: Update the hasMore calculation in the change-request pagination flow
to require items.length > 0 in addition to the existing total/offset comparison.
This must stop further fetching whenever the API returns an empty changeRequests
page, even if data.total is stale or exceeds data.offset.
---
Nitpick comments:
In `@apps/csm-portal/microapp/src/components/operations/changeRequestFilters.ts`:
- Around line 35-42: Update countActiveCRFilters to count closedStartDate and
closedEndDate together as one logical closed-date filter: return 1 when either
date is set, rather than adding separate counts for each. Preserve the existing
state and impact filter counts.
- Around line 44-51: Update toChangeRequestSearchFilters to trim the search
value before checking whether it is non-empty and assigning searchQuery, so
whitespace-only input is omitted while meaningful queries are sent in trimmed
form.
🪄 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: c3ad3d91-aa5a-4cf3-9184-8a2f3aa6a86a
📒 Files selected for processing (18)
apps/csm-portal/microapp/src/App.tsxapps/csm-portal/microapp/src/components/case-detail/SectionCard.tsxapps/csm-portal/microapp/src/components/operations/ChangeRequestCard.tsxapps/csm-portal/microapp/src/components/operations/ChangeRequestsFiltersSheet.tsxapps/csm-portal/microapp/src/components/operations/ChangeRequestsTab.tsxapps/csm-portal/microapp/src/components/operations/EditChangeRequestDialog.tsxapps/csm-portal/microapp/src/components/operations/ServiceRequestsFiltersSheet.tsxapps/csm-portal/microapp/src/components/operations/ServiceRequestsTab.tsxapps/csm-portal/microapp/src/components/operations/changeRequestFilters.tsapps/csm-portal/microapp/src/components/operations/config.tsapps/csm-portal/microapp/src/config/endpoints.tsapps/csm-portal/microapp/src/pages/ChangeRequestDetailPage.tsxapps/csm-portal/microapp/src/pages/OperationsPage.tsxapps/csm-portal/microapp/src/services/cases.tsapps/csm-portal/microapp/src/services/changeRequests.tsapps/csm-portal/microapp/src/types/changeRequest.dto.tsapps/csm-portal/microapp/src/types/changeRequest.model.tsapps/csm-portal/microapp/src/types/index.ts
… pagination in Change Requests Clearing Planned start in the edit dialog silently omitted plannedStartOn from the PATCH payload instead of sending null, since the omission-guard required plannedStart to be truthy. Also guard hasMore against an empty page reporting more results are available when the backend's total is stale/inconsistent.
3d1101d
into
wso2-open-operations:dev-app-csm-portal
Summary
type: service_request. Severity is dropped (case-type-only, matches the webapp'sCsmIssuesViewbehavior when locked to a non-casetype); Work state is kept, disabled until "Work in progress" is selected (also matches the webapp).plannedStartOn,isCustomerApproved,isCustomerReviewed).openapi.yamlor the webapp's ownIssuesListUnavailable).getAllCaseshasMorefallback fix (deriveshasMorefromoffset/totalwhen the search response omits it, mirroring the same fix already inadminUsers.ts'ssearchUsers) — needed for the Service Requests list to paginate past the first page.Test plan
tsc --noEmitcleaneslintcleanvite buildclean🤖 Generated with Claude Code
Summary by CodeRabbit