Implement expanded police contact information model in Drupal

[davidmpickett]

User Story or Problem Statement

Blocked by #16812

Description or Additional Context

Steps for Implementation

Step 1 - Add the term to the Service taxonomy

• Term: https://github.com/department-of-veterans-affairs/va.gov-cms/issues/16811
• View: health_care_service_names_and_descriptions:entity_reference_non_clinical_services
  • This looks like it will automagically update the select list on VAMC Facility Non-clinical Service so long as the Type of Care for the term is set to "Non-clinical services" and published
  • Confirm that this works after #16811 is done

Step 2 - Create a new Display on a View

• View: non_clinical_services
• Display: Should be able to copy one of the 3 existing Displays. Only a few fields should need to change:
  • Display name: VA Police
  • Machine Name: va_police
  • Title: @davidmpickett will provide text
  • filter criterion: Content: Service -> Will need to bee set to VA Police once Term is added in Step 1
  • Header: Global: Text area - @davidmpickett will provide text
  • Footer: Global: Text area - @davidmpickett will provide text
  • No results behavior: Global: Text area - @davidmpickett will provide text

Here's an annotated screenshot of how the text fields in the Display will show up in the editorial experience

Step 3 - Update the Content Type

• Content Type: VAMC System VA Police page
• Add a new Viewfield field similar to the Non-Clinical Services field on the content types VAMC System Billing and Insurance, Register for Care, and Medical Records.
  • This should be in the Contact information fieldset after the Contact phone number
  • Mostly just copy and pasting the settings here. Only real difference is the Display.
  • Field label: Non-clinical Services
  • Machine name: field_non_clinical_services
  • Always use default value ✅
  • Display the default value on node edit ✅
  • Allowed display types: Block
  • Set default value ✅
    • View: non-clinical services
    • Display: "VA Police" created in Step 2
    • Advanced options: [node:field_office:target_id]/[node:field_administration:target_id]
  • Update: Contact phone number field
  • Add guidance on what should go here (a single best point of contact for the whole system)
  • Make this field editable (remove from the External Content tooltip)
  • Some kind of required logic that makes this field OR a non-clinical service required?
    • For those systems that basically have two equally important numbers, should we allow them to leave the System phone number blank if they've provided more Non clinical services?

Acceptance Criteria

• [ ] A user with the Content Publisher and VAMC Creator roles can add VAMC Non-clinical services to the VAMC System VA Police Page
• [ ] 2
• [ ] 3
• [ ] Requires design review
• [ ] Requires accessibility review
• [ ] Relevant tests are updated
• [ ] Relevant documentation is updated

Team

Please check the team(s) that will do this work.

• [ ] CMS Team
• [ ] Public Websites
• [x] Facilities
• [ ] Accelerated Publishing

[davidmpickett]

@omahane @Becapa I moved my details from #16812 to this ticket so you can use this as a base for pre-refining

[mmiddaugh]

@davidmpickett I've been comparing Drupal with front end displays for non-clinical services in the wild. Can we use this opportunity to improve this experience? (If not in Drupal, perhaps FE)

The Name of office or location field is not required and when none has been specified, there is no distinction between locations. See Gulf Coast Billing and insurance

Gulf Coast

---

When the editor has selected Provide specific hours for the service but then specified none, the hours are displayed as "Closed". See Cheyenne Billing and insurance

Cheyenne

---

When the editor has selected Provide specific hours for the service a value should be expected for From and To otherwise, the hours displayed lose meaning. See Beckley Medical Records

Beckley

[davidmpickett]

When the editor has selected Provide specific hours for the service a value should be expected for From and To otherwise, the hours displayed lose meaning. See Beckley Medical Records

I just tried replicating this and the Office Hours field wouldn't let me save a service with only an End time. It's possible that an early version of the module that powers this field didn't have this validation in place back when this particular service was last saved in 2022.

So it seems like all new instances of this will validate correctly in Drupal. But could possibly add some defense against this on front end.

[davidmpickett]

When the editor has selected Provide specific hours for the service but then specified none, the hours are displayed as "Closed". See Cheyenne Billing and insurance

So while this example definitely seems like a mistake, I don't know if we can say that having all days display Closed is always invalid. If a service is temporally unavailable (due to construction or staffing), this might be an effective way to communicate that. Also need to consider that the office hours field has to support data that migrates in from VAST, which may include facilities that are temporarily closed.

The Office Hours module as is does not seem to have a validation option that checks to ensure at least one day has hours. We'd likely need to build some client-side validation similar to the alt text guidance if we wanted to prompt editors with a "are you sure this is always closed?" message.

[davidmpickett]

The Name of office or location field is not required and when none has been specified, there is no distinction between locations. See Gulf Coast Billing and insurance

Definitely something we want to address on the Front End in Jordan's design.

From a Drupal perspective we wouldn't want to make this field always required. In situations where there is only one Service Location having no 'Name of office or location' is perfectly fine. In theory we could look into having some kind of conditional validation in situations when there is more than one Service Location (approximately 1% of Services). Not sure how complicated that would be. I'll defer to @Becapa and @omahane on lift

[aklausmeier]

@thejordanwood FYA

[aklausmeier]

@davidmpickett I feel pretty strongly that we shouldn't be solving Drupal issues with visual design if Drupal is capable of additional guardrails that can be implemented with better UX strategy. I agree with your line of thinking of exploring conditional logic.

In theory we could look into having some kind of conditional validation in situations when there is more than one Service Location

These additional use cases that are popping up are great at pushing us towards a better Veteran experience.

[davidmpickett]

@davidmpickett I feel pretty strongly that we shouldn't be solving Drupal issues with visual design if Drupal is capable of additional guardrails that can be implemented with better UX strategy. I agree with your line of thinking of exploring conditional logic.

It might be worth reframing this issue in a broader context. For instance, last year I closed this historical ticket after Jordan resolved this in the VBA design for Service Accordions. But the non-clinical services are a slightly different implementation, and the focus was adapting the FE to accommodate the existing Drupal model.

Similarly, when @thejordanwood updated the design of the Drupal interface for Service Location, it was mostly in the context of adding new fields, rearranging existing ones, and improving help text. Investigating the full conditional logic of the content model wasn't really on the table.

This might require a more expansive exploration than just being a part of one Police ticket. Some possible older tickets/epics to revisit:

• 4439

• 13932

• 14683