Open laflannery opened 6 months ago
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
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 👍🏻
@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
This sounds like the exact same work as we will be doing in the Q3 Phone Number effort.
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
Got it, so we'd likely need to update the Phone Paragraph type with those new options and then implement
@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?
Going to put this in a future epic for vanity/international, etc.
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.
[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, ourva-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/17326When #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:
tty
,sms
)message-aria-describedby
propAdditional info
<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.Acceptance Criteria
va-telephone
components