Skip to main content

CR List and Detail

This page explains how users view Caution Reports in list form and open one report in detail view.

API Endpoints​

  • GET /data/caution-report/all
  • GET /data/caution-report/by-id/:id

Purpose​

List and detail flows let users:

  • find relevant CRs
  • filter them by business criteria
  • open one CR for deeper review
  • see current status, work order, note, and activity context

CR list flow​

Business meaning​

List flow is not a simple table read. It applies role-aware filtering, date and status filtering, workgroup restrictions, and search-driven narrowing before returning paginated rows.

Flow summary​

StepBusiness meaning
prepare page and limitpagination starts
check admin vs non-adminrole affects workgroup restrictions
if NOC user, force allowed workgroupsCR visibility is narrowed
build base filterstandard query filter is built
apply scope, priority, date, source, creator, area, status filtersmain list filtering happens
collect matching CR idsfilter narrowing can happen before final query
query paginated rows and total countpage result is fetched
map response rowsUI-facing response is built

Implementation note​

This matches the current implementation:

  • portal uses GET data/caution-report/all
  • backend applies workgroup rules for non-admin and NOC users
  • backend returns paginated rows plus total
  • export path also exists separately

Code refs:

  • intt-portal/src/app/components/pages/main-modules/cr/cr.component.ts:429
  • intt-portal/src/app/components/pages/main-modules/cr/cr.component.ts:621
  • mvp2-data-service/src/modules/caution-report/caution-report.controller.ts:246
  • mvp2-data-service/src/modules/caution-report/caution-report.service.ts:691

CR detail flow​

Business meaning​

Detail flow loads one CR, enforces access rules, refreshes some derived state, and returns a richer response than the list page.

Flow summary​

StepBusiness meaning
load user workgroupsaccess scope is prepared
load CR by iddetail record is fetched
apply LOB and NOC access checksunauthorized users are blocked
read latest TMF activity statuscurrent downstream state is considered
update local TMF status if neededlocal record can be refreshed
resolve CR status LOVcurrent CR status is derived
calculate aging if still activeopen CRs get derived aging
refresh closure data from latest note if neededterminal-state data can be corrected
load creator user unless source is GOTHdetail response is enriched

Implementation note​

This matches the current implementation:

  • portal opens GET data/caution-report/by-id/:id
  • backend enforces LOB and NOC restrictions
  • backend recalculates aging for non-closed/non-cancelled CRs
  • backend can refresh closure remark data from latest note

Code refs:

  • intt-portal/src/app/components/pages/main-modules/cr/cr-details/cr-details.component.ts:734
  • mvp2-data-service/src/modules/caution-report/caution-report.controller.ts:281
  • mvp2-data-service/src/modules/caution-report/caution-report.service.ts:811