VATEAM-90732: Add OMB info fields to Digital Form

[derekhouck]

Description

Adds all fields necessary to render an accurate OMB info component on each form. Specifically, adds the following two fields:

• Expiration date (string, will be converted to expected pattern in content-build)
• Respondent Burden (integer, in minutes)

These two fields are grouped together with OMB Number to form an "OMB Info" field group.

• Closes Create OMB Info section in Digital Form content type va.gov-team#90732

Testing done

Updated the Digital Form bundle class test with the new fields. Tested the form and view displays locally.

Screenshots

The "OMB info" field group in the form display:

The "OMB info" field group in the node display:

QA steps

As an administrator

1. Go to Manage > Content > Add content > Digital Form
   • Verify the "OMB info" field group is visible and the following fields are contained within it:
     • "Respondent burden"
     • "OMB Number"
     • "Expiration date"
2. Verify all three of the above fields are required.
3. Enter data in the "Respondent burden" field
   • Verify you can only enter numbers.
   • Verify you can only enter numbers greater than or equal to 0.
4. Select a date in the "Expiration date" field.
   • Verify it displays the date in MM/DD/YYYY format.
5. Fill out the other required fields on the Digital Form and click "Save" at the bottom of the page.
   • Verify the Digital Form saves successfully and the view page looks similar to the above screenshot.

Definition of Done

• Documentation has been updated, if applicable.
• Tests have been added if necessary.
• Automated tests have passed.
• Code Quality Tests have passed.
• Acceptance Criteria in related issue are met.
• Manual Code Review Approved.
• If there are field changes, front end output has been thoroughly checked.

Select Team for PR review

• CMS Team
• Public websites
• Facilities
• User support
• Accelerated Publishing

Is this PR blocked by another PR?

• DO NOT MERGE

Does this PR need review from a Product Owner

• Needs PO review

CMS user-facing announcement

Is an announcement needed to let editors know of this change?

• Yes, and it's written in issue ____ and queued for publication.
  • Merge and ping the UX writer so they are ready to publish after deployment
• Yes, but it hasn't yet been written
  • Don't merge yet -- ping the UX writer to write and queue content
• No announcement is needed for this code change.
  • Merge & carry on unburdened by announcements

[ryguyk]

Looks great!

I do have some lingering questions about how configuration like this will be presented/honored/etc. in our custom form experience, but I do think this work will be useful regardless.

[derekhouck]

I do have some lingering questions about how configuration like this will be presented/honored/etc. in our custom form experience, but I do think this work will be useful regardless.

If we can tie our custom display into Drupal's display configuration system, that would be ideal, but I don't know off-hand how much work that would be at this time.

[ryguyk]

If we can tie our custom display into Drupal's display configuration system, that would be ideal, but I don't know off-hand how much work that would be at this time.

We can, at least to some degree. But there's still the question of how things map from the default display to our custom display. For example, does a fieldset become its own page? Or, perhaps to ask it better, since we will have designs for each page of the wizard-like experience, do we define fieldsets accordingly?

In other words, we should be able to access the display configuration, but there are some questions in my head about what we should do with that information or how what that means for how we configure it in the first place.