[CSM Portal] add case-scoped Task visibility (list + detail) - #1194
Conversation
Adds a lightweight, read-only Tasks tab on the Case detail page so CS engineers can see the sub-items associated with a case (subject, state, due date, assignee) without leaving the portal. Plumbed end-to-end: entity-service task lookup against the backing data source, a thin CSM backend proxy, and new webapp hooks/components wired into the case detail page. List and get-by-id only; no create/edit/time-logging.
|
Warning Review limit reached
Next review available in: 43 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 (21)
✨ 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 |
github-actions
Bot
added
App/CSM Portal
Area/Backend
Area/Frontend
Entity Service
Platform/Web
labels
…se task list
Aligns the case-scoped task list endpoint with this codebase's established
search convention (POST .../search with a JSON body) instead of the GET with
query-param pagination it originally shipped with. Adds
SearchCaseTasksRequest, updates the handler to decode a JSON body, and has
sn_task_service build a POST request against the downstream
cases/{id}/tasks/search path with the same response shape as before.
Aligns useGetCaseTasks with this webapp's list/search convention (POST + body payload instead of GET + query params), matching useSearchChangeRequests/useSearchDeployments. Renamed to useSearchCaseTasks and added BeCaseTasksSearchPayload for the pagination body; response shape (tasks/total/offset/limit) is unchanged.
Replace GET /cases/{caseId}/tasks?limit=&offset= with
POST /cases/{caseId}/tasks/search, matching this codebase's search
convention. The pagination is now carried in a JSON body forwarded
verbatim to the entity service, instead of query parameters.
|
@coderabbitai resume |
✅ Action performedReviews resumed. |
2 participants
Purpose
CS engineers working a case in the CSM portal currently have no visibility into the case's sub-items (task-like records with a subject, state, due date, and assignee). This PR adds that visibility directly on the Case detail page. No related issue link (internal tracking only).
Goals
Add a read-only "Tasks" tab to the Case detail page that lists a case's tasks and lets an engineer open a detail dialog for a single task. This is distinct from, and does not touch, the existing Call Requests feature.
Approach
Plumbed end-to-end across all three components:
Taskdomain type, a service that fetches case-scoped tasks and a single task by id from the backing data source, a handler, and route wiring (GET /cases/{caseId}/tasks,GET /tasks/{id}).SearchCaseTasks,GetTaskon the entity client;TaskHandlerwith matching routes) forwarding to the entity-service, with unit tests and a mock entity client.useGetCaseTasks,useGetTask), aTasksWidgetlist component +TaskDetailDialog, ataskStateutility for state display, and a new "Tasks" tab wired intoCsmCaseDetailPage.tsx.Scope is intentionally narrow: this is list + get-by-id only. There is no create, edit, or time-logging capability for tasks in this change.
A corresponding change on the backing data-source side (to expose task records) is tracked separately, outside this repo.
User stories
As a CS engineer viewing a case, I can see its associated tasks (subject, state, due date, assignee) and open any one of them for more detail, without leaving the case detail page.
Release note
Adds a read-only "Tasks" tab to the Case detail page in the CSM portal, showing a case's sub-items and a detail view for each.
Documentation
N/A — internal CS-engineer portal feature; no external/product docs impacted.
Training
N/A — no training content impact.
Certification
N/A — no certification exam impact.
Marketing
N/A — internal tooling feature, not customer-facing.
Automation tests
tasks_test.gocovering the new handler against a mocked entity client, plus updatedhelpers_test.gomock.TasksWidget.test.tsxcovering list rendering states.Security checks
go vet(entity-service, csm backend) andeslint/tsc(webapp) clean insteadSamples
N/A — no new samples.
Related PRs
Stacked alongside #1192 (change request approval-stage visibility) and #1193 (Problem management list/detail views), all part of the same CSM-portal read-visibility workstream this session. No direct code dependency between them.
Migrations (if applicable)
N/A — no schema/data migration; purely additive read endpoints.
Test environment
Verified locally against a full local stack pointed at ServiceNow DEV (real data), Chrome (latest, macOS) for the browser check.
Learning
N/A — followed existing patterns from sibling read-visibility features (e.g. Task SLA, Problem) in this codebase for entity-service/backend/webapp layering.
Note on PR size: this PR spans 21 files across three components (entity-service, csm-portal backend, csm-portal webapp) because it's a single feature threaded through the full stack — somewhat over the usual single-PR target, consistent with the sibling Problem-detail PR (#1193, 24 files) kept as one PR for the same reason. No individual file exceeds ~240 changed/added lines.