Update how phone numbers for Support services are added in the CMS

[laflannery]

Status

[2024-08-20] [Dave] Created separate tickets for Vanity and International phone numbers [2024-07-25] [Dave] This probably needs to be split into multiple tickets.

1. Adding Vanity and International options to Phone Paragraph type
2. Migrating content type & FE to use Phone paragraph type

[2024-07-12] [Fran] Moved to Next Refinement because until the changes described in this ticket are implemented, we are blocked from using the 'va-telephone' design component. [2024-07-12] [Fran] Note that 'Call us links' have NOT been updated to va-telephone components - Laura pointed out that because we have a bit too much wriggle room in the CMS for adding phone numbers, our va-telephone component cannot easily support all the different types of numbers it'll receive. (The GIBILL number on va.gov/education is a good example of an outlier). Her ticket: https://github.com/department-of-veterans-affairs/va.gov-cms/issues/17326

When #17326 is addressed, we can convert (at least most of) these phone numbers to va-telephone and remove the custom events on them.

Background

We are trying to get all our products on VA.gov to be in alignment with the DS, which means they should always be using the most up to date versions of all available components when possible. In order for the components to work and be rendered correctly on the front end, the content must be passed in a particular way. Unfortunately, the way we have the Support Service phone number fields set up in the CMS, the data cannot be passed properly to the component.

Description

The Support Service content type was created a while ago, long before the DS component, so what was needed for a particular front end component was not considered. This component and the applicable props now do a lot of the display and functionality that the Support Service CMS fields are manually doing.

Considerations for updates:

• The facility services have a "Type" field that we might want to consider using here because it includes options for Phone, Fax, SMS, TTY
  • When the editor chooses a type, data is able to be passed to the FE which can then be used to set the appropriate prop for the component (e.g. tty, sms)
  • This also allows for conditional fields in the CMS
  • When "Phone" is chosen an "Extension" field displays but does not when the other options are chosen
  • If this pattern was considered a good option, we could consider adding additional options so that this could cover all scenarios needed for the component:
  • Vanity - If selected this should trigger an conditional field for the vanity info
  • International
• Name of support service: This is an existing field
  • The text provided in this field should be used for the message-aria-describedby prop
• Link:
  • This is used for items that aren't phone numbers sometimes so we should keep this field for those uses (Example)
  • This information would not be used for phone numbers anymore though. Should be make this conditional somehow so that it only shows it needed?
• Phone number: Still applicable but we need to change the data being entered
  • Currently: The entire visible label was being entered in here. Examples:
  • TTY: 711
  • +1-918-781-5678
  • 877-222-VETS (8387)
  • Future: Only the standard, digits only phone should be entered in here. Examples:
  • 711
  • 918-781-5678
  • 877-222-8387
  • FE QUESTION: Should they not be entering the dashes between the numbers either? Should be be validating and/or providing help text against that or is that ok and the component can handle those?
• Extension: This field doesn't current exist
  • I don't believe any Support Services have an extension but since we are thinking about this anyway we should consider all scenarios
  • The extension number needs to be passed to the component separately, which is also the way this is done in Facility services, as a separate field.

Additional info

• VA.gov FE usage: These phone numbers are used in the right column of benefits landing pages, example: Education & training as well as in the Need more help at the bottom of multiple resources pages
• CMS BE usage: There is a content type for Support Service and there is also an inline editor that appears on the Benefits Landing page content type. It's in the Right rail accordion in the right column. Any changes we make we should be sure appear in both places (I'm not sure if it happens automagically)
• There is also a DST ticket for a possible update to the <va-telephone> component because we have one instance of a vanity phone number (the GIBILL number) that even if we did have the proper data coming from Drupal, the component wasn't going to support this.
  • I'm not positive if/when this would get done. I'm also not positive what this would look like when it would happen.
  • With that in mind, would changes we make now work for this GIBILL number?
  • Could we make changes now, update the CMS and the front end but allow this GIBILL number to not use the component?

### DRUPAL - Update phone\_number Paragraph Type to include new options
- [ ] https://github.com/department-of-veterans-affairs/va.gov-cms/issues/18999
- [ ] https://github.com/department-of-veterans-affairs/va.gov-cms/issues/18959
- [ ] Add two new options to field_phone_number_type: Vanity & International
- [ ] Add logic to paragraph type that hide/displays appropriate fields when Vanity or International are selected (do they get Extension field?)
- [ ] Add new field for Vanity Info (what should limits on this field be?)
- [ ] Add new field for country code? for International
- [ ] Test on multiple content types

### DRUPAL - Update support\_service Content Type to use phone\_number Paragraph Type
- [ ] BLOCKED by previous task list
- [ ] Data migration of ?? existing phone numbers in field_phone_number to phone_number Paragraph Type
- [ ] Hide field_phone_number on Drupal UI for Support Service
- [ ] Add phone_number Paragraph Type to Support Service (cardinality?)
- [ ] Test it
- [ ] Keep PR in Pending Integration until FE work is ready

### FE - Update Content Build query(ies) + template(s)
- [ ] BLOCKED by previous task list
- [ ] Use new phone number data source for Support Services
- [ ] Name of support service: This is an existing field The text provided in this field should be used for the message-aria-describedby prop
- [ ] Test on all templates where Support Service shows up
- [ ] Keep PR in Pending Integration until Drupal PR merges & deploys

### DRUPAL - Cleanup
- [ ] BLOCKED by previous task list
- [ ] Verification on Prod of all above changes is complete
- [ ] Remove field_phone_number from Support Service

Acceptance Criteria

• [ ] the way we have the Support Service phone number fields set up in the CMS has been changed so that the data CAN be passed properly to the component.
• [ ] Requires design review
• [ ] Requires accessibility review
• [ ] Notify Fran Cross so that tickets can be unblocked/written to update 'Call us links' to va-telephone components

[omahane]

The only place that we have something like what you're describing for the phone number at present is in Service Locations, using the field_phone (a paragraph type). https://prod.cms.va.gov/node/add/health_care_local_health_service

[randimays]

FE QUESTION: Should they not be entering the dashes between the numbers either? Should be be validating and/or providing help text against that or is that ok and the component can handle those?

The web component doesn't like dashes. In many cases we're having to remove them in content-build / the FE

Could we make changes now, update the CMS and the front end but allow this GIBILL number to not use the component?

We can make exceptions in the code for this type of phone number 👍🏻

[FranECross]

@davidmpickett @dsasser @jv-agile6 I feel like this needs some review/love love outside of a refinement meeting to determine the best approach. Would all/some of you be the ones to do that? BTW this ticket is currently blocking implementing the 'va-telephone' component. Thanks! (I'm scooting it back to the backlog. cc @Agile6MSkinner

[davidmpickett]

This sounds like the exact same work as we will be doing in the Q3 Phone Number effort.

• Migrate existing phone numbers from phone field to phone paragraph type
• Update graphql query
• Remove old field after prod verification

[laflannery]

This requires more work that the existing phone pattern does not support:

If this pattern was considered a good option, we could consider adding additional options so that this could cover all scenarios needed for the component:

• Vanity - If selected this should trigger an conditional field for the vanity info
• International

[davidmpickett]

Got it, so we'd likely need to update the Phone Paragraph type with those new options and then implement

[davidmpickett]

@laflannery I took a first pass at adding task lists here. Would love a sanity check.

One of the first steps would be defining the exact requirements for the Vanity and International phone number types. Do you feel like you have the info to specify those? Or should we make a little spike ticket for you and I to collaborate on that?

[Agile6MSkinner]

Going to put this in a future epic for vanity/international, etc.