Add banners to the VBA Facility content type

[xiongjaneg]

Description

Drupal implementation for banner content type is built to match the spec #13811

• Refer to VBA Content Specs XLS linked in VBA Pilot MVP - Drupal content modeling & spec work #13096

Acceptance Criteria

• Replicate the full-width alert for these fields
• Conditionally enabled banner doobley-doo (expandable fieldset) from CLP model
  • Fields are cleared out when Use the banner is disabled
• Fields appear within fieldsets and in order as shown in the spec
  • Fields for alert-title and alert-body
  • Alert type field (Information or Warning)
• Help text is provided by UX designer
• CLP expandable fieldset updates are tested (see CLP test as the model)
• Add link in accessibility audit ticket Accessibility audit of VBA banner content type #14896 for Laura on where to review implementation
• Follow up tickets are created to track any remaining work that arises during implementation

[swirtSJW]

Plans documented here #13811

[xiongjaneg]

@xiongjaneg final decision on options

[xiongjaneg]

Assuming the three fields from option 4, does this need a design ticket? What pattern might be used? Something similar to campaign landing page where it's hidden until the box is checked? Or that it's visible in a field group?

RE is a design ticket needed? This is relatively small but there is a dependency for front end.

[xiongjaneg]

There could be a third field for dismissability or persistence, whichever pattern design recommends.

Should there be a field for banner content type: information vs. warning. There is an existing select box used in full width alerts.

Is there need for a field for display this on other VBA pages (in Pilot MVP there is only one page)? Not needed for Pilot MVP.
@xiongjaneg stub out for that field after Pilot MVP. Edit: Done

[xiongjaneg]

@davidmpickett Some questions for clarification for pilot MVP.

1. Are we using the dismissability language or the persistence language for VBA?
2. Are we using the information vs. warning selector?

[davidmpickett]

@davidmpickett Some questions for clarification for pilot MVP.

1. Are we using the dismissability language or the persistence language for VBA?
2. Are we using the information vs. warning selector?

Unless we are radically changing how banners appear on the front end or preventing VBA editors from having these options and choosing for them, then these are required fields

[xiongjaneg]

RE: dismissable model vs persistence model, the dismissable model is the older one (check box, which cannot be required), the persistence model is a newer model (radio button, which can be required)

Decision to move forward with persistence model

[xiongjaneg]

Decision to use CLP model of giving the option to enable a banner and make the banner options appear

[xiongjaneg]

@davidmpickett @swirtSJW @omahane Please comment with any additional information or questions to help further define and size this ticket. I'll add as a candidate for sprint 95 with the understanding that it may need some clarification in sprint planning. Thank you! cc @jilladams

[xiongjaneg]

@swirtSJW @omahane Can this one be refined and pointed async now that the spec ticket is done? Wondering if we can get it refined in time for next sprint.

[omahane]

i would give this a 5.

[jilladams]

@thejordanwood FYI that during Drupal prefinement for Facilities today, we discussed having you help out on this ticket as part of ACs vs. creating a separate ticket, and want to confirm if that makes sense for you or you'd prefer a separate ticket. The work for you will be Help text on some of the fields that will be added.

And making the timing note: if we opt for a separate ticket, it'll need to be planned into the same sprint as this ticket, to work in parallel.

cc @xiongjaneg

[davidmpickett]

@thejordanwood FYI that during Drupal prefinement for Facilities today, we discussed having you help out on this ticket as part of ACs vs. creating a separate ticket, and want to confirm if that makes sense for you or you'd prefer a separate ticket. The work for you will be Help text on some of the fields that will be added.

And making the timing note: if we opt for a separate ticket, it'll need to be planned into the same sprint as this ticket, to work in parallel.

cc @xiongjaneg

FYI - We do already have a ticket for UX review of banners #14844. I have previously suggested that ticket is not necessary because we also have a ticket for reviewing the content type they are being added to #14888 (also ditto the corresponding accessibility tickets). Having them as separate tickets is partially an artifact of a previous time when banners were planned as a separate content type

[thejordanwood]

@jilladams @xiongjaneg @davidmpickett

1. I can help out on this ticket. Are we adding 3 fields – Fields for alert-title, alert-body, and alert type fields (Information or Warning)? Will this look similar to the full width alert content type?
2. I agree with Dave. Let's close UX review of VBA banner content type #14844 since we're okay with doing the UX review within this ticket.

[xiongjaneg]

Closed #14844

[davidmpickett]

MUST

• field_banner_content should use the widget Text area (multiple rows) with counter and be limited to 300 characters. This matches the limitation on VAMC banners and Design System guidance.

SHOULD

• Change "Persistence" to "Dismissible by user?" and make "Allow site visitors to dismiss banner permanently" the first choice and selected by default to match Design system guidance
• "Enable this page segment" -> "Display a banner alert on this facility"

CONSIDER

• Most of these are really questions/ideas for @thejordanwood / @ALogsdon3 to consider
• Should all instances of "banner" be "banner alert"? It is both a banner and an alert and fully understanding it requires referencing both the Banner and Alert Design System components.
• Update the field group description (This optional segment allows you to add a banner to the VBA facility.) to have more explicit guidance about the limited use cases for adding a banner alert (e.g. actual emergencies) and potentially link to this KB article (https://prod.cms.va.gov/help/vamc/about-locations-content-for-vamcs/about-alerts-and-operating-statuses/best-practices-for-vamc-system-banner-alerts)
• "Banner title" -> "Banner headline" to match terminology in Design System
• "Banner content" -> " "Banner message" to match terminology in Design System
• Consider something like this help text for Banner type field (copied from VAMC banner alert)

Currently, the CMS supports two types of alerts:

1. Informational alerts, which are used to provide helpful information to a user or something that warrants attention. Not used for negative consequences.
2. Warning alerts, which are used to warn a user, such as when there are negative consequences, but necessary when something has gone wrong.

You can read more about these alert types in the VA Design System.

[omahane]

Setting required fields

There's a bug that relates to this ticket:
https://www.drupal.org/project/drupal/issues/2912092

Banner Type

Banner Type appears to be required, having a red asterisk, but it is not required. You can submit the form without it.

Possible solution

Use constraint validator.

Dismissable

• Dismissable doesn't have a red asterisk.
• Is not required to be filled out.
• Has N/A
• Default value not set

Possible solution

Make dismissable required

• removes the N/A
• Set the value at "Allow"

Do a bulk update after deploy
Set the value during migration.

Address each issue

• Use alter statement to remove N/A
• Use JS to apply required classes
• Use constraint validator to make sure it's been filled out

[thejordanwood]

I added a VBA Banners page to the Figma file to document the help text changes that are being suggested.

[swirtSJW]

I just realized we neglected to include test coverage on this PR. So I created a followup ticket.

[davidmpickett]

Uploading video for async demo:
https://github.com/department-of-veterans-affairs/va.gov-cms/assets/51967950/0b60499d-20c8-410d-a8c2-4fbb605f1bce