PRDE - Bug default text according to the team DoR (Definition of Ready)

01 - PERSON OF CONTACT (PERSON THAT CAN ANSWER QUESTIONS ABOUT THE PROBLEM):
02 - PROBLEM (WHAT'S THE ISSUE?):

@Cindy de Araujo Soares Moore described:

There is a specific scenario that we didn’t consider when discussing this ticket. On User data model creation we should always create the mappings, even for disabled RT environments.

When we process records to mdmuser data model, we depend on RT to create the Carol Platform user.

We will need this change in EntityTemplate class: https://github.com/totvslabs/mdm/pull/3515/files#diff-c06d96dd86e76637c7cd0aa7676ecd5d308f62d7343524e287df2ec5c215a22bR713-R718

On:

CAPL-3197:Validate strategies to avoid creating the ES "schema" (mapping) on ES for sta...Done

03 - STEPS TO REPRODUCE (STEP (1...N), VIDEO, SCREENSHOTS, LOGS FOLDER, HEARTBEAT, ETC. – IF IS NOT POSSIBLE TO REPRODUCE EXPLAIN THE REASON):
04 - LINKS (ADD A LINK TO THE BUG OR TO THE TENANT):
05 - EXPECTED BEHAVIOR (LIST THE EXPECTED BEHAVIORS TO CONSIDER THIS BUG AS DONE):

• On UNIFIED Tenant, the mdmUserGolden should be fan-out to customer tenants.
• The user must no be created on the UNIF tenant, only on the customer tenants after the fan-out. Following the same criterias as we have today and implemented here (
  CAPL-4790:SQL Processing: user integration with tenant user without depending on merges...Done
  )
• If customer RT storage type is FALSE and the flag shouldSendRealtime is TRUE, we should log a warn message (on the sql process task on the unified tenant)
  • If the datamodel is mdmUser, we should create the user.
• The password must not be store on ES or BQ storage type. In other words, all golden records must not store password.
  • If for some reason it is needed to create the user, we need to remove it right after creating the user.
  • We will handle only at golden level.
• gcp merge query; https://cloudlogging.app.goo.gl/24e1QP8gksGhzq4o8