VATEAM-90733: Normalize OMB info fields

[derekhouck]

Summary

• Normalizes the OMB info fields created by VATEAM-90732: Add OMB info fields to Digital Form va.gov-cms#19078

Example output

  {
    "formId": "12345",
    // ...
    "ombInfo": {
      "expDate": "8/29/2025",
      "ombNumber": "1234-5678",
      "resBurden": 30
    },
    "chapters": [
      // ...
    ]
  }

Related issue(s)

• Normalize OMB Info section va.gov-team#90733

Testing done

• Added OMB info unit tests to the Digital Form post processor and the Digital Form GraphQL query
• Pulled local Drupal data and confirmed the resulting output from content-build

What areas of the site does it impact?

Only affects the output of digital-forms.json, which is not currently generated in production.

Acceptance criteria

Quality Assurance & Testing

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Linting warnings have been addressed
• Documentation has been updated (link to documentation *if necessary)
• Screenshot of the developed feature is added
• Accessibility testing has been performed

Error Handling

• Browser console contains no warnings or errors.
• Events are being sent to the appropriate logging solution
• Feature/bug has a monitor built into Datadog or Grafana (if applicable)

Authentication

• Did you login to a local build and verify all authenticated routes work as expected with a test user

Requested Feedback

I made the decision to format the Expiration Date at this stage. As far as I can tell, we won't need it as anything other than a formatted string in the Form Renderer app, and this seems like the least expensive place to do that formatting. I am open to other suggestions.

[timcosgrove]

I have no problem with any of this provided the various GraphQL tests pass, but will hold approval until reviewed by someone on the form builder team.

[ryguyk]

Great work. One requested change that we discussed around date conversion.

[ryguyk]

Slack conversation about this: https://agilesix.slack.com/archives/D076J681TB5/p1725460391490419?thread_ts=1725460364.715049&cid=D076J681TB5

Takeaway: it might be better to not convert to a Date object (and thus introduce a time component) and instead just parse the input string to create the output string.

[ryguyk]

A possible starting point:

const removeLeadingZero = s => s.substr(0, 1) === '0' ? s.substr(1) : s;
const convertDate = dateInput => {
    const [year, month, day] = dateInput.split('-'); 	
    return `${removeLeadingZero(month)}/${removeLeadingZero(day)}/${year}`;
}

[derekhouck]

Updated. I found a regex expression that reduced the amount of code needed for removeLeadingZero, but other than that, it's mostly your starting point.

[ryguyk]

Nice work!

[ryguyk]

This will remove multiple leading zeroes, should they be present, which I think is noteworthy but also should be N/A. In fact, if it somehow were the case that a string came over with multiple leading zeroes, I think we would want them all removed, so this is great. Makes me wonder if removeLeadingZeroes is a better name, but that feels pedantic and possibly confusing given the context.

Nicely done!