[CSM Portal] add case activities search endpoint (comments, attachments, field changes)

[rksk]

Purpose

The CSM portal needs a single, chronologically-ordered activity feed for a case that interleaves comments, attachments, and (optionally) field changes, so an engineer can see the full history of a case in one place. Today the entity-service only exposes comments and attachments as separate searches, and it has no way to surface recorded field changes at all. This PR adds a case activities search endpoint that returns all of these as one unified, paginated feed.

Goals

• Add POST /cases/{id}/activities/search to the entity-service, returning a paginated activity feed for a case.
• Model the feed as a vendor-neutral discriminated union on type (comment, attachment, field_change) so the frontend can render each entry appropriately.
• Let the caller opt into field-change entries via includeFieldChanges; when it is omitted or false, only comment and attachment entries are returned.

Approach

The endpoint mirrors the existing case attachment/comment search flow end to end:

• Domain (internal/domain): new SearchCaseActivitiesRequest (case id from the path, pagination, optional includeFieldChanges), SearchCaseActivitiesResponse (activity array plus total/limit/offset/hasMore, matching the sibling search responses), and CaseActivity/FieldChange/ActivityType types. CaseActivity carries the shared fields (id, type, content, createdOn, created-by name fields) plus type-specific fields set only for the matching type (commentType for comments; fileName/contentType/sizeBytes/downloadUrl for attachments; changes for field changes).
• Service (internal/service): new SearchCaseActivities on the CaseService interface. The active data-source implementation proxies the corresponding integration-service search (case id carried in the path), maps the response into the neutral domain types, and computes hasMore the same way the sibling searches do. The Postgres implementation returns a not-supported error, matching the existing attachment endpoints.
• Handler + route (internal/handler, internal/server): a new handler decodes the body, pulls the case id from the path, and the route is registered alongside the existing case attachment/comment routes.
• OpenAPI (openapi.yaml): documents the new path and the request/response/CaseActivity/FieldChange/ActivityType schemas in neutral vocabulary.

This is purely additive: no existing endpoint, type, or contract changes. It depends on a corresponding integration-service change (exposing the case activities search), tracked separately.

User stories

As a CS engineer, I want a single feed of a case's comments, attachments, and field changes so I can review the case's full history without stitching together multiple views.

Release note

Added a case activities search endpoint that returns a unified, paginated feed of a case's comments, attachments, and optional field changes.

Documentation

N/A - internal service-to-service API; the contract is captured in the repo's openapi.yaml, which this PR updates. No end-user product documentation is affected.

Training

N/A - no training-content impact.

Certification

N/A - no impact on certification exams; this is an internal API addition with no end-user-facing behavior change.

Marketing

N/A - internal platform change, nothing to promote.

Automation tests

• Unit tests

  No new unit tests: the endpoint is a thin, additive passthrough that follows the existing case attachment/comment search pattern, which is exercised by the current suite. go test ./... passes.

• Integration tests

  Covered by the existing entity-service integration flow once the paired integration-service change lands; end-to-end verification is tracked with that change.

Security checks

• Followed secure coding standards in http://wso2.com/technical-reports/wso2-secure-engineering-guidelines? yes
• Ran FindSecurityBugs plugin and verified report? N/A - FindSecurityBugs targets Java bytecode; this is Go. go vet ./... runs clean.
• Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets? yes

Samples

N/A - no samples associated with this change.

Related PRs

A corresponding integration-service change (exposing the case activities search) is tracked separately.

Migrations (if applicable)

N/A - no schema or data migrations; no persistence changes.

Test environment

Go toolchain on macOS. Verified with go build ./..., go vet ./..., and go test ./... (all pass).

Learning

Followed the existing SearchCaseAttachments/SearchCaseComments implementations in the entity-service as the reference pattern; no new libraries or external research required.

[coderabbitai]

Warning

Review limit reached

@rksk, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 26 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: bb5f9cfa-b6a7-46b6-9168-7dfe69bd58f4

📥 Commits

Reviewing files that changed from the base of the PR and between 314a593 and aa92ec0.

📒 Files selected for processing (7)

• entity-service/internal/domain/entity.go
• entity-service/internal/handler/case_handler.go
• entity-service/internal/server/routes.go
• entity-service/internal/service/case_service.go
• entity-service/internal/service/interfaces.go
• entity-service/internal/service/sn_case_service.go
• entity-service/openapi.yaml

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}