VAMS-20163 news release contact number

[brianseek]

Description

Adds media contact phone number to press releases. Adds query into paragraph entity for phone. Adds the va-telephone webcomponent into IntrinsicElements. Changes the person_profile to use the phone type paragraph for phone instead of the incorrect phone string, this created changes beyond press release. Updates mocks to return more data for contacts and phone.

Generated description

This pull request includes several changes to the handling and formatting of contact information, particularly phone numbers, in the pressRelease and newsStory data queries. The changes ensure that phone numbers are now treated as arrays of objects, allowing for multiple numbers and additional details such as type and extension.

Changes to contact information handling:

• src/data/queries/pressRelease.ts: Updated the params function to include field_press_release_contact.field_telephone and modified the formatter function to handle phone numbers as arrays of objects with additional details. [1] [2]
• src/data/queries/tests/__snapshots__/newsStory.test.tsx.snap: Added detailed phone number information to the snapshot for news stories.
• src/data/queries/tests/__snapshots__/pressRelease.test.tsx.snap: Updated the snapshot for press releases to include detailed contact information with phone numbers.
• src/data/queries/tests/pressRelease.test.tsx: Added a test to handle missing or null contact fields correctly and updated the params function test to include field_press_release_contact.field_telephone.
• src/mocks/newsStory.mock.json: Updated the mock data to include detailed phone number information.
• src/mocks/pressRelease.mock.json: Updated the mock data to include detailed contact information with phone numbers.
• src/mocks/staffProfile.mock.js: Updated the mock response to include detailed phone number information.

Changes to tests and components:

• src/templates/layouts/pressRelease/index.test.tsx: Updated the test to check for the presence of multiple phone numbers and their attributes. [1] [2]
• src/templates/layouts/pressRelease/index.tsx: Modified the PressRelease component to render multiple phone numbers with their respective details.
• src/templates/layouts/staffProfile/dataService.test.tsx: Removed phone number fields from the test data. [1] [2]

Ticket

closes #20163.

Developer Task

• PR submitted against the main branch of next-build.
• Link to the issue that this PR addresses (if applicable).
• Define all changes in your PR and note any changes that could potentially be breaking changes.
• PR includes steps to test your changes and links to these changes in the Tugboat preview (if applicable).
• Provided before and after screenshots of your changes (if applicable).
• Alerted the #accelerated-publishing Slack channel to request a PR review.
• You understand that once approved, you are responsible for merging your changes into main. (Note that changes to main will move automatically into production.)

Testing Steps

• visit https://pr919-ecv45kblfrhxoqa2qmcqu5oykoou4eo5.tugboat.vfs.va.gov/boston-health-care/news-releases/clinical-study-on-use-of-raman-spectroscopy-device-to-detect-skin-cancer/
• verify that the phone number is displayed
• inspect the element and verify that it is using <va-telephone> webcomponent

Screenshots

Reviewer

Reviewing a PR

This section lists items that need to be checked or updated when making changes to this repository.

Standard Checks

• Code Quality: Readabilty, Naming Conventions, Consistency, Reusability
• Test Coverage: 80% coverage
• Functionality: Change functions as expected with no additional bugs
• Performance: Code does not introduce performance issues
• Documentation: Changes are documented in their respective README.md files
• Security: Packages have been approved in the TRM

Merging an Approved Layout

When merging a layout, you must ensure that the content type has been turned on for next-build inside the CMS. This CMS flag must be turned on for editors to preview their work using the next build preview server.

Resource types (layouts) that have not been approved by design should NOT be pushed to production. Ensure that slug.tsx does not include your resource type if it is not approved.

The status of layouts should be kept up to date inside templates.md. This includes QA progress, development progress, etc. A link should be provided for where testing can occur.

Merging a Non-Approved Layout

Your new resource type should not be included inside slug.tsx. Items added here will go into production once merged into the main branch. It is imperative that we do not push anything live that has not been approved.

Ensure that this layout has been added to the templates.md file with the current status of the work.

[laflannery]

Looks good - I Tested standard phone numbers and exts. I don't currently know of any instances where Fax, TTY or SMS are used here so I wasn't able to confirm those

[cvalarida]

😅 What happens if these are false-y? I can't think of a reason we'd ever want empty strings for any of these, but this will turn those empty strings into null. 🤔 Probably fine? 🤷

[brianseek]

I was also dubious about this, but was trying to follow style/pattern. Getting existential about the identity of a defect ticket, it was feeling weird to shift that style for this work. Mostly because I would then feel the need to change other un-related areas to match. I think next steps around this sort of thing for me at least would be to hook my local drupal up to local next to start playing around with different missing data states.

[cvalarida]

I'd like to see a few things up, but I think it looks generally good.