Skip to main content

CR GOTH Create

This page explains the GOTH-sourced Caution Report creation path.

This flow was checked against the current code in mvp2-data-service and mvp3-caution-report-queue-service.

API Endpoints​

  • POST /data/caution-report/goth/create

Bottom line​

The GOTH Create CR flowchart is mostly correct and it represents a genuinely different create path from normal CR creation.

GOTH creation is:

  • a separate public endpoint
  • queue-driven through a dedicated RabbitMQ message
  • validated and mapped from GOTH payload fields
  • duplicate-checked before create
  • saved as a CR with source = GOTH
  • followed by GOTH and TMF-related downstream handling

What starts the flow​

The entry point is:

  • POST /data/caution-report/goth/create

Unlike normal CR creation, this route is marked @Public() and does not attach creator identity from the current portal session.

Instead, creator context comes from the GOTH payload itself through heroAgent.

Input shape confirmed from code​

The GOTH payload includes fields such as:

  • gothTicketNo
  • source
  • creationDate
  • heroAgent.name
  • heroAgent.staffId
  • customerName
  • customerContactNo
  • customerEmail
  • latitude
  • longitude
  • symptom
  • reasonOfUrgency
  • attachment
  • comment
  • duplicateFlag

Main runtime flow​

StepWhat the system does
Accept public requestcontroller receives goth/create request
Clone attachmentsprepares attachment array
Send RabbitMQ commandsends create-goth-caution-report
Validate payloadworker validates required fields, datetime, hero agent, coordinates, and attachments
Resolve areaderives area data from latitude and longitude
Resolve severitymaps GOTH urgency input to CR severity configuration
Resolve diagnosismaps GOTH symptom input to diagnosis code and impacted element
Prepare CR statusstarts the CR in In-Progress
Run duplicate checkchecks nearby matching CRs unless duplicateFlag is already true
Return duplicate response if neededreturns duplicate CR details instead of creating a new CR
Build CR recordcreates CR data with GOTH ticket and agent fields
Assign workgroupmaps diagnosis to a workgroup such as ENCC or SAO
Generate CR ticket numbercreates the internal Antrix CR ticket number
Resolve nearby FDCderives cabinetId from nearby FDC data when possible
Save CRwrites the new caution report
Save note and metadatastores creation note, LOVs, and area data
Save attachmentsstores GOTH attachments if present
Try TMF dispatch pathattempts GOTH-to-TMF downstream handling
Fallback to Manual Assign if neededupdates CR status LOV to Manual Assign when downstream dispatch fails
Dispatch back to GOTHperforms GOTH-side follow-up dispatch when building data is available
Return final responsereturns success or a duplicate/error response

What makes GOTH create different from normal CR create​

Normal CR createGOTH create
authenticated portal routepublic integration route
uses logged-in user staffIduses heroAgent.staffId from payload
sends create-caution-reportsends create-goth-caution-report
standard portal form modelexternal GOTH payload model
generic create responsecan return duplicate-specific response

Duplicate handling​

This is one of the most important GOTH-specific behaviors.

The worker checks for nearby duplicate CRs based on:

  • latitude and longitude
  • system module alarm rules
  • mapped impacted element
  • created date window

If a duplicate is found and duplicateFlag is false, the flow returns a Duplicate CR response instead of creating a new CR.

That response includes details such as:

  • existing Antrix ticket number
  • GOTH ticket id
  • building id
  • latitude and longitude
  • symptom
  • urgency reason

Confirmed stored GOTH fields​

When the worker builds the CR, it stores GOTH-specific fields such as:

  • source
  • gothTicketId
  • gothAgentName
  • gothStaffId
  • gothCreatedDate

This is why GOTH-created CRs later show different creator/source information in the detail response.

Notes and attachments​

The worker writes a creation note in this format:

  • Created GOTH Caution Report: <crTicketNo>|<gothTicketId>

If attachments are included:

  • they are saved into CR storage
  • empty descriptions are not allowed later in the downstream TMF path
  • attachment sync errors are logged as failures

Downstream behavior after create​

After the CR is created, the flow does more than just stop at the database save.

The worker attempts downstream handling that includes:

  • GOTH-to-TMF dispatch logic
  • TMF attachment upload when dispatch succeeds
  • fallback of CR status LOV to Manual Assign when TMF dispatch fails
  • GOTH-side follow-up dispatch when building data exists

So the business meaning is:

  • GOTH create is a create-plus-handoff path
  • downstream success can affect whether the CR continues automatically or needs manual follow-up

Flowchart verdict​

The GOTH Create CR flowchart is reliable for the main business path.

The most important code-confirmed points are:

  • it is a separate public route
  • duplicate detection is built into the create flow
  • the CR is created using mapped GOTH fields, not the normal portal user payload
  • downstream TMF/GOTH handling is part of the overall flow
  • failed downstream dispatch can move the CR into Manual Assign rather than fully failing the entire create

That last point is the main nuance worth keeping visible in the docs.

Code references​

  • mvp2-data-service/src/modules/caution-report/caution-report.controller.ts
  • mvp3-caution-report-queue-service/src/modules/caution-report/caution-report.controller.ts
  • mvp3-caution-report-queue-service/src/modules/caution-report/caution-report.service.ts
  • mvp2-data-service/src/modules/caution-report/caution-report.dto.ts
  • mvp2-data-service/src/modules/caution-report/caution-report-response.model.ts