VATEAM-87711: Add Digital Form content type #18717

derekhouck · 2024-07-23T17:57:07Z

Description

Closes #87711

Testing done

Unit tests added for the Digital Form bundle class and the new fields attached to it.

Screenshots

Digital Form in the list of content types

Digital Form listed as an option in the "Add Content" page

The Create Digital Form page

QA steps

What needs to be checked to prove this works?
Digital Form creation, updating, and deletion

What needs to be checked to prove it didn't break any related things?
Creation, updating, and deletion of other content types

What variations of circumstances (users, actions, values) need to be checked?
Only administrators should be able to create Digital Forms at this time.

As an administrator

Go to Manage > Content > Add content
- Verify "Digital Form" appears as an option.
Click "Digital Form"
- Verify the form contains the following sections:
  - Form Name
  - Section
  - Form number
  - OMB Number
Fill out the required fields and click "Save"
- Verify the Digital Form saves successfully and the data you entered appears on the "View" page.
Click the "Edit" tab and verify you can successfully edit data.
Click the "Delete" tab and verify you can successfully delete a Digital Form.

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

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

github-actions · 2024-07-23T17:57:28Z

GitHub Workflows (.github/workflows/*.yml)

Have you...

pinned all affected GitHub Actions at a specific commit by SHA?
reviewed the source code of the action at the commit you are pinning?
confirmed that no GitHub security measures are being bypassed?
checked for any injection of user content into protected contexts?
reviewed Security hardening for GitHub Actions?
reviewed GitHub Workflows?

ryguyk

Approved with a couple questions. Nothing is pressing, as these would be simple changes going forward. The biggest one is around the description of the content type.

ryguyk · 2024-07-24T15:17:24Z

config/sync/field.storage.node.field_omb_number.yml

+module: core
+locked: false
+cardinality: 1
+translatable: true


I'm not certain whether this distinction is critical in practice, in this case, but it feels odd that this field would be translatable.

I no longer seem able to edit this setting in the Drupal UI for this field type. I could manually edit it, but I'm a little hesitant to do so in case it creates an unworkable configuration.

I believe the UI limitation is because you have content created already. Once we create content, things are much more set in stone. So I do think now is the time to ensure we get things as right as they can be, because once we push this to production and start using it, we're kind of stuck.

I'm not sure what that means here. As I said, I'm not sure what significance it will have, in practice, if this field is marked as translatable. I just imagine that this would never be something we would want to translate.

This might be a limitation of this being a string field. I have been unable to find an example of a string field type that is not translatable in our config, but I have found other examples of string field types that are probably not ever going to be translated with this attribute set to true:

va.gov-cms/config/sync/field.storage.node.field_facility_locator_api_id.yml

Line 18 in 9b59d45

translatable: true

va.gov-cms/config/sync/field.storage.node.field_geographical_identifier.yml

Line 18 in 9b59d45

translatable: true

va.gov-cms/config/sync/field.storage.node.field_govdelivery_id_emerg.yml

Line 18 in 9b59d45

translatable: true

va.gov-cms/config/sync/field.storage.node.field_last_name.yml

Line 18 in 9b59d45

translatable: true

va.gov-cms/config/sync/field.storage.node.field_office_id.yml

Line 18 in 9b59d45

translatable: true

va.gov-cms/config/sync/field.storage.node.field_va_form_number.yml

Line 18 in 9b59d45

translatable: true

That is not to say we should definitely follow their example, but it seems we would not be unique in leaving this attribute at its default value.

This is compelling. Probably not how these fields should be, but good evidence that it probably doesn't have a practical downside in our context.

Very nice discovery!

ryguyk · 2024-07-24T18:53:57Z

config/sync/node.type.digital_form.yml

+    when_to_delete: 0
+name: 'Digital Form'
+type: digital_form
+description: 'An online form created by the Form Builder tool.'


This description feels slightly confusing to me. It feels interesting to me to describe a piece of content of this type as something that is "created by the Form Builder tool", when, in fact, this content type is, effectively, the Form Builder tool. I'm not sure what is the chicken and what is the egg.

That said, I'm not sure I have a better idea. Perhaps something like, "Configuration for an online form presented to Veterans."

Just a thought. Not a hill I'm going to die on. Maybe this is a UX question, after all.

It probably is a UX question, but I went ahead and updated the description to your suggestion until we get a more definitive answer from Design.

ryguyk · 2024-07-24T19:04:23Z

config/sync/core.base_field_override.node.digital_form.promote.yml

@@ -0,0 +1,22 @@
+uuid: ac87a752-cc60-4bde-bd33-18098f65e851
+langcode: en
+status: true


It seems like we wouldn't need this field. I think that means we could set status: false (or perhaps remove this file altogether). That said, I'm not seeing this on the UI. So I'm a bit perplexed. I need to dig in further to understand what's going on. I imagine a lot of this is happening automatically with config export, but I don't know enough to know why.

Yes, this is one of those fields that I had to manually disable in the Drupal UI, as it was added automatically. I'm hesitant to remove it for fear that something depends on it.

ryguyk · 2024-07-24T19:26:19Z

tests/phpunit/va_gov_content_types/functional/Entity/DigitalFormTest.php

+  public function testBundleClass() {
+    $digital_form_attrs = [
+      'field_va_form_number' => '12345',
+      'field_omb_number' => '1234-5678',
+      'title' => 'Test Digital Form',
+      'type' => 'digital_form',
+    ];
+
+    $node = $this->createNode($digital_form_attrs);
+    $this->assertEquals(DigitalForm::class, get_class($node));
+    $this->assertEquals($node->getTitle(), $digital_form_attrs['title']);
+    $this->assertEquals(
+      $node->get('field_va_form_number')->getString(),
+      $digital_form_attrs['field_va_form_number']
+    );
+    $this->assertEquals(
+      $node->get('field_omb_number')->getString(),
+      $digital_form_attrs['field_omb_number']
+    );
+  }
+
+}


This looks good. I need to chew a bit on this to establish any real convictions about what I think we need to test in this space, but this looks reasonable at first pass.

ryguyk

I also wonder if we will want any validation around the format of the OMB number. We have a constraint on the length, but that doesn't currently preclude an editor from entering a 9-digit string without a dash (or from entering a 3-digit string, for example).

derekhouck · 2024-07-24T19:57:12Z

I also wonder if we will want any validation around the format of the OMB number. We have a constraint on the length, but that doesn't currently preclude an editor from entering a 9-digit string without a dash (or from entering a 3-digit string, for example).

I did not see an easy way to add pattern validation without getting into module development. We can certainly pursue that, as I expect we will eventually need to do some module work, but I was attempting to see what we could gain without it.

ryguyk · 2024-07-31T16:57:33Z

Merging into integration branch. That branch will need external review at some point.

* Add Digital Form content type * Update Digital Form description --------- Co-authored-by: Derek Houck <[email protected]>

* VATEAM-87711: Add Digital Form content type (#18717) * Add Digital Form content type * Update Digital Form description --------- Co-authored-by: Derek Houck <[email protected]> * Add chapters field to Digital Form * Add screenshot of name and dob pattern * VATEAM-88658: Script to add Digital Forms test data (#19025) * WIP: Create digital form script * Add steps * Rename exit_if_wrong_env --------- Co-authored-by: Derek Houck <[email protected]> Co-authored-by: Derek Houck <[email protected]> Co-authored-by: Derek Houck <[email protected]> Co-authored-by: Tim Cosgrove <[email protected]>

Add Digital Form content type

cc9a056

va-cms-bot temporarily deployed to Tugboat July 23, 2024 17:57 Destroyed

derekhouck changed the base branch from main to integration-form-engine-poc July 23, 2024 19:18

derekhouck mentioned this pull request Jul 23, 2024

Add Digital Form content type department-of-veterans-affairs/va.gov-team#87711

Closed

5 tasks

derekhouck marked this pull request as ready for review July 23, 2024 19:41

derekhouck requested review from a team as code owners July 23, 2024 19:41

derekhouck requested a review from ryguyk July 23, 2024 19:42

github-actions bot added the CMS Team CMS Product team that manages both editor exp and devops label Jul 23, 2024

ryguyk approved these changes Jul 24, 2024

View reviewed changes

ryguyk reviewed Jul 24, 2024

View reviewed changes

Update Digital Form description

e1a1bd3

va-cms-bot temporarily deployed to Tugboat July 24, 2024 19:52 Destroyed

derekhouck changed the title ~~Add Digital Form content type~~ VATEAM-87711: Add Digital Form content type Jul 24, 2024

va-cms-bot temporarily deployed to Tugboat July 29, 2024 17:48 Destroyed

ryguyk merged commit b613dc1 into integration-form-engine-poc Jul 31, 2024
16 of 18 checks passed

ryguyk deleted the 87711-add-digital-form-content-type branch July 31, 2024 16:57

ryguyk mentioned this pull request Jul 31, 2024

VAGOV-TEAM-87958: Integration branch for Form Engine POC #18811

Merged

29 tasks

ryguyk pushed a commit that referenced this pull request Aug 26, 2024

VATEAM-87711: Add Digital Form content type (#18717)

7658290

* Add Digital Form content type * Update Digital Form description --------- Co-authored-by: Derek Houck <[email protected]>

ryguyk pushed a commit that referenced this pull request Sep 3, 2024

VATEAM-87711: Add Digital Form content type (#18717)

209d8e4

* Add Digital Form content type * Update Digital Form description --------- Co-authored-by: Derek Houck <[email protected]>

ryguyk pushed a commit that referenced this pull request Sep 4, 2024

VATEAM-87711: Add Digital Form content type (#18717)

c7fe4ae

* Add Digital Form content type * Update Digital Form description --------- Co-authored-by: Derek Houck <[email protected]>

ryguyk pushed a commit that referenced this pull request Sep 16, 2024

VATEAM-87711: Add Digital Form content type (#18717)

f471684

* Add Digital Form content type * Update Digital Form description --------- Co-authored-by: Derek Houck <[email protected]>

ryguyk pushed a commit that referenced this pull request Sep 17, 2024

VATEAM-87711: Add Digital Form content type (#18717)

9316c27

* Add Digital Form content type * Update Digital Form description --------- Co-authored-by: Derek Houck <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

VATEAM-87711: Add Digital Form content type #18717

VATEAM-87711: Add Digital Form content type #18717

derekhouck commented Jul 23, 2024 •

edited

Loading

github-actions bot commented Jul 23, 2024

ryguyk left a comment

ryguyk Jul 24, 2024

derekhouck Jul 24, 2024

ryguyk Jul 24, 2024

derekhouck Jul 24, 2024

ryguyk Jul 25, 2024

ryguyk Jul 24, 2024

derekhouck Jul 24, 2024

ryguyk Jul 24, 2024

derekhouck Jul 24, 2024

ryguyk Jul 24, 2024

ryguyk left a comment

derekhouck commented Jul 24, 2024

ryguyk commented Jul 31, 2024

VATEAM-87711: Add Digital Form content type #18717

VATEAM-87711: Add Digital Form content type #18717

Conversation

derekhouck commented Jul 23, 2024 • edited Loading

Description

Testing done

Screenshots

QA steps

Definition of Done

Select Team for PR review

Is this PR blocked by another PR?

Does this PR need review from a Product Owner

CMS user-facing announcement

github-actions bot commented Jul 23, 2024

GitHub Workflows (.github/workflows/*.yml)

ryguyk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ryguyk left a comment

Choose a reason for hiding this comment

derekhouck commented Jul 24, 2024

ryguyk commented Jul 31, 2024

derekhouck commented Jul 23, 2024 •

edited

Loading