Skip to main content

CR Update Notes

This page explains how existing Caution Report notes are edited and synchronized after they already exist.

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

API Endpoints​

  • GET /data/caution-report/get-all-notes
  • PUT /data/caution-report/note/update/:id

Bottom line​

The Update CR Notes flowchart is mostly correct for the implemented path.

Updating a CR note is not just a local text edit. In the current implementation, note update is treated as an activity-linked TMF note update flow:

  • the portal only allows editing notes owned by the current user
  • the backend requires a valid CR activity
  • TMF note update is attempted before the new local note text is saved
  • if TMF update fails, the user gets an error and the new note text is not committed locally

When this flow is used​

  • when a user edits an existing CR note from the CR detail page
  • when the edited note is tied to a CR activity
  • when support or developers need to understand why a note edit failed even though the note already existed

What starts the update​

From the portal CR detail page:

  1. user clicks edit on a note
  2. portal fills the note modal with existing activityId and note
  3. portal submits PUT data/caution-report/note/update/:id

Frontend rules confirmed from code​

The current portal behavior includes these rules:

  • activityId is required in the note form
  • note text is required
  • edit mode is only enabled for notes whose username matches the current logged-in user's staffId

So from the UI point of view, note editing is owner-restricted and activity-linked.

Main backend flow​

StepWhat the system does
Load note by idfinds the existing CR note record
Validate note existsstops if the target note cannot be found
Resolve CR activitychecks the supplied activityId against the CR activity list
Build TMF note payloaduses TMF ticketId, activityId, new note text, and current timestamp
Send update to TMFcalls TMF notes endpoint
Handle TMF failurelogs failure and rejects the update
Save local note updateonly after TMF success, updates local note text and audit fields
Write audit logrecords update result

What the TMF payload uses​

The update path sends:

  • TMF ticketId
  • activityId
  • note description
  • createdDatetime

For note update, the TMF ticketId is taken from the matched local CautionReportActivity row, not directly from the note itself.

Confirmed implementation behavior​

These parts are directly confirmed from code:

  • portal updates via PUT /data/caution-report/note/update/:id
  • backend method is updateCautionReportNote(...)
  • backend requires the target note to exist
  • backend requires a matching CR activity for the selected activityId
  • backend sends the updated note to PUT /eai/intt/notes/detail
  • backend retries TMF auth/token failures in the helper
  • backend only saves the new local note text after TMF returns success

Important difference from note creation​

Create and update do not behave the same way.

Create note​

  • local note is created first
  • TMF sync is attempted next
  • if TMF sync fails, the new local note is deleted

Update note​

  • TMF sync is attempted first
  • local note text is updated only after TMF success
  • if TMF sync fails, the new text is not committed locally

This is an important business distinction because “note edit failed” does not mean the existing stored note was lost. It means the new version could not be synchronized and therefore was not finalized.

Implementation nuance​

On TMF failure, the update path still performs a local write using the old note text before throwing the error. In practice, this behaves like preserving the existing note content rather than saving the new edited content.

So the safest reading is:

  • successful TMF response is the gate for committing the edited note text
  • failed TMF response keeps the previous note content as the effective local state

Flowchart verdict​

The Update CR Notes flowchart is reliable for the main business path:

  • existing note is selected
  • activity-linked validation matters
  • TMF synchronization is part of the update
  • failure can stop the update
  • success results in updated note content

The main nuance worth carrying forward is that update behavior is not a simple local overwrite. It is a synchronized update path with TMF as a success gate.

Code references​

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