Skip to main content

CR Ticket History

This page explains how CR ticket history is shown in the current implementation.

This flow was checked against the current code in intt-portal and mvp2-data-service.

API Endpoints​

  • GET /data/caution-report/by-id/:id
  • GET /data/caution-report/audit-log/by-id/:id

Bottom line​

The Ticket History flowchart is directionally correct, but in the current repo "ticket history" is not a single source.

For CR, history is shown through two related but different views:

  • a lifecycle timeline built from progressTracking in the CR detail response
  • an Audit Trail tab loaded from the CR audit-log endpoint

So the safest interpretation is that CR ticket history means both status progression and recorded change activity.

History view A: Lifecycle timeline​

This is the business-status history shown from CR detail data.

Current source​

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

What the backend builds​

The backend maps CR detail and creates progressTracking from:

  • current CR status LOV
  • CR creation date
  • CR activity records
  • closed date when applicable

The tracking array is initialized with these lifecycle states:

  • In-Progress
  • Assigned
  • Cancel
  • Closed

Then the backend marks which states are reached and fills dates and activity-status details based on the CR state and activity history.

Business meaning​

This view answers:

  • where is the CR in its lifecycle
  • when was it created, assigned, cancelled, or closed
  • what activity statuses support the current lifecycle stage

History view B: Audit Trail​

This is the change-log style history shown in the Audit Trail tab.

Current source​

  • GET /data/caution-report/audit-log/by-id/:id

What the backend returns​

The backend:

  1. verifies the CR exists
  2. loads audit logs for that CR record
  3. filters logs from the CR creation time onward
  4. sorts newest first
  5. enriches each row with user name when available

Current portal behavior​

The portal only loads this data when the user opens tab 2, which is labeled Audit Trail.

The audit trail table shows fields such as:

  • ticket id
  • created by
  • staff id
  • activity
  • status
  • activity message
  • created at

Business meaning​

This view answers:

  • who changed something
  • what operation ran
  • whether it succeeded or failed
  • what message or response summary was recorded

Main runtime split​

History questionCurrent source
What lifecycle stage has this CR reached?progressTracking from CR detail
What activity or status trail supports that stage?progressTracking.activityStatus and CR activities
Who performed changes and what happened in the API/audit layer?audit-log/by-id/:id

Confirmed implementation behavior​

These parts are directly confirmed from code:

  • portal loads CR detail through data/caution-report/by-id/:id
  • portal renders the ticket progress/timeline from progressTracking
  • portal loads audit data only when the Audit Trail tab is selected
  • backend audit-log query uses CR id and CR created time as the lower bound
  • backend audit rows are returned newest first

Important implementation nuance​

The flowchart label Ticket History can sound like one page or one endpoint, but the implemented behavior is broader:

  • lifecycle history is part of CR detail mapping
  • audit history is a separate endpoint and tab

So if someone is debugging "history mismatch", they should first ask which kind of history they mean.

Flowchart verdict​

The Ticket History flowchart is useful and mostly correct at business level, but the code-backed wording should make the split explicit:

  • timeline history comes from progressTracking
  • change/audit history comes from audit-log/by-id/:id

That makes the page more accurate for onboarding, support, and debugging.

Code references​

  • intt-portal/src/app/components/pages/main-modules/cr/cr-details/cr-details.component.ts
  • intt-portal/src/app/components/pages/main-modules/cr/cr-details/cr-details.component.html
  • mvp2-data-service/src/modules/caution-report/caution-report.controller.ts
  • mvp2-data-service/src/modules/caution-report/caution-report.service.ts
  • mvp2-data-service/src/modules/caution-report/caution-report-response.model.ts