[TTAHUB-3451]format comlog comdate history

[hardwarehuman]

Description of change

Improperly formatted communicationDate values were making their way into CommunicationLogs.data. This fixes the history and produces all valid dates. There's one date in the year 3034, but that's the date that was input by the user.

How to test

You can see what all the updates will be just by inspecting SELECT * FROM comdate_corrections;

Issue(s)

• https://jira.acf.gov/browse/TTAHUB-3451

Checklists

Every PR

• Meets issue criteria
• JIRA ticket status updated
• Code is meaningfully tested

Before merge to main

• Ready to create production PR

Production Deploy

• Staging smoke test completed

After merge/deploy

• Update JIRA ticket status

[GarrettEHill]

Please also update src/queries/dataRequests/user/communication-logs.sql as its logic around the date is now not needed.

[AdamAdHocTeam]

Might not be a bad idea to add a comment to state the intention of each of these regex.

[AdamAdHocTeam]

Looks good, I almost wonder if it could be simplified any, but I see you had to deal with weird cases. Like where you don't have the starting portion of the year ie 24 = 2024.

Some AI code:
-- Get all the bad cases. SELECT * FROM "CommunicationLogs" WHERE data->>'communicationDate' !~ '^(0[1-9]|1[0-2])/(0[1-9]|[12][0-9]|3[01])/([0-9]{4})$';

-- Sample update (obv we cant use as is) UPDATE "CommunicationLogs" SET data = jsonb_set(data, '{communicationDate}', '"01/01/1970"') WHERE data->>'communicationDate' !~ '^(0[1-9]|1[0-2])/(0[1-9]|[12][0-9]|3[01])/([0-9]{4})$';

Something like this might be used to handle the weird date cases (again AI generated) but might be what you have or close to it:

UPDATE "CommunicationLogs" SET data = jsonb_set( data, '{communicationDate}', to_jsonb( CASE WHEN data->>'communicationDate' ~ '^(0[1-9]|1[0-2])/(0[1-9]|[12][0-9]|3[01])/([0-9]{2})$' THEN regexp_replace(data->>'communicationDate', '/([0-9]{2})$', '/20\\1') ELSE data->>'communicationDate' END ) ) WHERE data->>'communicationDate' !~ '^(0[1-9]|1[0-2])/(0[1-9]|[12][0-9]|3[01])/([0-9]{4})$';

[GarrettEHill]

Looks good, I almost wonder if it could be simplified any, but I see you had to deal with weird cases. Like where you don't have the starting portion of the year ie 24 = 2024.

Some AI code: -- Get all the bad cases. SELECT * FROM "CommunicationLogs" WHERE data->>'communicationDate' !~ '^(0[1-9]|1[0-2])/(0[1-9]|[12][0-9]|3[01])/([0-9]{4})$';

-- Sample update (obv we cant use as is) UPDATE "CommunicationLogs" SET data = jsonb_set(data, '{communicationDate}', '"01/01/1970"') WHERE data->>'communicationDate' !~ '^(0[1-9]|1[0-2])/(0[1-9]|[12][0-9]|3[01])/([0-9]{4})$';

Something like this might be used to handle the weird date cases (again AI generated) but might be what you have or close to it:

UPDATE "CommunicationLogs" SET data = jsonb_set( data, '{communicationDate}', to_jsonb( CASE WHEN data->>'communicationDate' ~ '^(0[1-9]|1[0-2])/(0[1-9]|[12][0-9]|3[01])/([0-9]{2})$' THEN regexp_replace(data->>'communicationDate', '/([0-9]{2})$', '/20\\1') ELSE data->>'communicationDate' END ) ) WHERE data->>'communicationDate' !~ '^(0[1-9]|1[0-2])/(0[1-9]|[12][0-9]|3[01])/([0-9]{4})$';

What you have is good, don't use the above as it makes this harder to follow that what you already have. This is a one and done migration not something that needs to be for preferment.

[GarrettEHill]

Please also update src/queries/dataRequests/user/communication-logs.sql as its logic around the date is now not needed.

This still needs to be addressed