Add NCA facility fields from Facilities API to CMS

[omahane]

User Story or Problem Statement

Per #13123, there are fields that are in the Facilities API that are not in the CMS.

Acceptance Criteria

The following fields are added to the CMS	Label	Machine Name	Field Type	Facilities API key	New CMS field
Cemetery classification	field_nca_classification	List (text)	properties.classification	Yes
Website	field_link	link	properties.website	No
Timezone	field_timezone	Text (plain)	properties.time_zone	Yes
Mailing address	field_mailing_address	Address	properties.address.mailing	Yes
Physical address	field_address	Address	properties.address.physical	No
Fax number	field_fax_number	telephone	properties.phone.fax	No
Phone number	field_phone_number	telephone	properties.phone.main	No
Hours	field_office_hours	Office hours	properties.hours	No

• [x] fields are locked down the way other facilities are, preventing changes from CMS editors
• [x] I expect a test on the migration is added On review: Migrations are hard to test bc you test after it runs. This is adding new data to an existing migration, and we have logical points to verify success already. Removing AC.

Questions for refinement

• [x] Do we need to have a design for any of this content? Answer: If we are following existing patterns all this should be using the locked content field group the same as on other products. Same field labels, same help text.
• [x] Is there any expectation that we'll be showing this content? - Answer: Not yet. This is just to get it in.

Implementation steps

## Design principles Veteran-centered - [x] `Single source of truth`: Increase reliability and consistency of content on VA.gov by providing a single source of truth. - [ ] `Accessible, plain language`: Provide guardrails and guidelines to ensure content quality. - [ ] `Purposely structured content`: Ensure Content API can deliver content whose meaning matches its structure. - [ ] `Content lifecycle governance`: Produce tools, processes and policies to maintain content quality throughout its lifecycle. Editor-centered - [ ] `Purpose-driven`: Create an opportunity to involve the editor community in VA’s mission and content strategy goals. - [x] `Efficient`: Remove distractions and create clear, straightforward paths to get the job done. - [ ] `Approachable`: Offer friendly guidance over authoritative instruction. - [ ] `Consistent`: Reduce user’s mental load by allowing them to fall back on pattern recognition to complete tasks. - [ ] `Empowering`: Provide clear information to help editors make decisions about their work. ### Team Please check the team(s) that will do this work. - [ ] `CMS Team` - [ ] `Public Websites` - [x] `Facilities` - [ ] `User support`

[swirtSJW]

Looks good. Only minor concern is about the field name for non VA location website. answered in slack

[swirtSJW]

Based on ^^ I think we want to re-use "field_link" as opposed to "field_non_va_location_url"

[swirtSJW]

@omahane Wondering if field_nca_classification ought to be a select list that we can normalize to in the migration. Are there just two classifications in the data?

[omahane]

Per Adam, it's possible new classifications could be added on the CDW side and would get passed on through: https://dsva.slack.com/archives/CJ162GDDJ/p1682086392200209?thread_ts=1681847189.858779&cid=CJ162GDDJ

[swirtSJW]

We also need timezone.

[omahane]

We also need timezone.

I couldn't find an already existing field, so I added this when I created this ticket.

[kmariepat-cityfriends]

Ask lighthouse team on Monday 5/1 about any existing standard on timezone

[omahane]

Ask lighthouse team on Monday 5/1 about any existing standard on timezone

After looking at the data, it appears that they use the TZ identifier as described here: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

After deduping the ones in the sandbox, I found this list

time_zone": "America/Chicago",
time_zone": "America/New_York",
time_zone": "America/Detroit",
time_zone": "America/Indiana/Indianapolis",
time_zone": "Asia/Seoul",
time_zone": "Europe/Berlin",
time_zone": "America/Kentucky/Louisville",
time_zone": "America/Menominee",
time_zone": "America/Denver",
time_zone": "America/Los_Angeles",
time_zone": "America/Phoenix",
time_zone": "America/Boise",
time_zone": "America/Puerto_Rico",
time_zone": "America/St_Thomas",
time_zone": "Asia/Manila",
time_zone": "Pacific/Honolulu",
time_zone": "Pacific/Guam",
time_zone": "America/Anchorage",
time_zone": "America/Sitka",
time_zone": "America/North_Dakota/New_Salem",
time_zone": "Pacific/Saipan",
time_zone": "America/Metlakatla",
time_zone": "America/Indiana/Vincennes",
time_zone": "America/Juneau",
time_zone": "Pacific/Pago_Pago",

[omahane]

@swirtSJW I was going to pick this up, but I realized that we were talking about the Timezone and hadn't determined if we were making this field or using the contrib module for it.

[omahane]

@swirtSJW I'm wondering what the "test on migration" should look like or do?