CR Status Rules

This page explains how Caution Report status updates work.

API Endpoints

CR status update moves a caution report through allowed business statuses and may trigger downstream TMF or GOTH behavior.

Status update is more constrained than a generic update.

The implementation explicitly handles:

Step	Business meaning
load existing CR	target CR must exist
validate target status LOV	requested status must be valid
reject `In-Progress` target	not allowed in this manual path
if Assigned, set assignee fields	assignee data is updated
if Closed or Cancel, push note to TMF and update TMF ticket status	terminal statuses trigger downstream sync
build remark	user remark overrides system remark
if source is GOTH and status not Return, trigger GOTH handling	source-specific branch exists
save CR note and update status LOV	note and status record move together
update CR master status fields	final CR state is saved
write success audit	status update is finalized

This matches the current implementation:

backend rejects In-Progress with explicit error
Assigned updates tmfAssign and tmfAssignName
Closed and Cancel try to send note or status update to TMF using earliest activity
GOTH source gets special handling except for Return
portal uses PUT data/caution-report/update/status/:id

Code refs:

intt-portal/src/app/components/pages/main-modules/cr/cr-details/cr-details.component.ts:2960
mvp2-data-service/src/modules/caution-report/caution-report.controller.ts:180
mvp2-data-service/src/modules/caution-report/caution-report.service.ts:412