Clientside validation module: Update implementation to provide an exception list

[jilladams]

Description

Client-side validation module is enabled globally for all forms. However, in several cases across several content forms in the CMS, it creates issues where required fields are not enforced as required, and it is possible to save content without the required field values.

In these cases, when the Clientside validation module is enabled (as it is on Prod), validation doesn't work as expected. For "conditionally required" fields, we have to require them on the client side. This means we rely on javascript to set the required property on such fields, and then the browser's native validation kicks in automatically to prevent submission of empty, required input fields. It is that native validation that is being short-circuited by Clientside Validation, somehow. There are several conditional field requirements on Events. (Client-side validation is required because Drupal isn't aware of conditional requirements.)

To resolve this: We would like to create an exception list for the clientside validation module, for forms to be excluded

Related defects

1. Bug: Drupal: Events can be saved with Location type: VA facility, and empty Facility Location #17426
   • PR: VACMS-17426: Requires VA facility location when the event is using a VA facility location type #17859
   • The problem is present for all required fields on the Events edit form (not the Event create form though, interestingly) if the Clientside Validation module is enabled
2. SPIKE: Understand why validation of the Operating Status Details is different for CAPs than facilities #19901 - any Content type using both the Hours widget, and the Operating status field, does not correctly validate on non-normal operating statuses having More info added. So all matching facility types need to be excluded from clientside validation.

Engineering background

Per Edmund, Clientside validation should only be enabled for 2 image forms where alt text exists, so at some point new config got imported that turned it on for all forms. CMS team has decided this module should remain enabled for all forms.

Related slack thread: https://dsva.slack.com/archives/CT4GZBM8F/p1713396251131369

• Original module implementation: Create client side validations for alt text input fields across the CMS. #15436
• Facilities work to work around this module's behavior on a Facilities form: Bug: VAMC editors can create detail pages under Work with us #17018

Acceptance criteria

• Clientside validation module config includes an exception list where forms can be excluded from clientside validation
• Clientside validation module config includes a configuration for fields to exclude (no matter whether we are validating all forms or only specific forms). The field exception has proven unjustifiably difficult to implement and is not deemed necessary at this time.
• The following content types are added to the exception list:
  • Events
  • NCA Facility
  • VAMC Facility
  • VBA Facility
  • Vet Center
  • Vet Center CAP
  • Vet Center MVC Does not have operating status
  • Vet Center Outstation
• Behavior in the following bug tickets is validated as being resolved by the exception. If not, revisit the approach with PM.
  • Bug: Drupal: Events can be saved with Location type: VA facility, and empty Facility Location #17426
  • SPIKE: Understand why validation of the Operating Status Details is different for CAPs than facilities #19901
• QA test plan written in Create a QA test plan for #17896 #20160 is run and all cases pass
• Required fields behavior is extensively tested by the Product team for all excluded forms, before the change is merged to main Not necessary at this time.
• Changes are submitted to module maintainers on https://www.drupal.org/project/clientside_validation/issues/2949540

[jilladams]

FYI @gracekretschmer-metrostar for your consideration. (cc @edmund-dunn )

[edmund-dunn]

@gracekretschmer-metrostar My memory was faulty; this was turned on for all forms. After conferring, we think this is the wrong path to follow. It has been enabled and disabling it now could have unintended consequences. That being said, it is possible to integrate clientside validation into this work.

See https://jqueryvalidation.org/category/plugin/

I found this:

$("#myform").validate({
  rules: {
    contact: {
      required: true,
      email: {
        depends: function(element) {
          return $("#contactform_email").is(":checked");
        }
      }
    }
  }
});

As a possible example to be used. My work at docroot/modules/custom/va_gov_media/js/alt_text_validation.es6.js can also be reviewed for further assistance.

We should encourage the use of clientside validation when possible and the use of #state and twig for more of the logic and less use of javascript whenever possible.

FYSA @timcosgrove

[jilladams]

@gracekretschmer-metrostar not urgent, just checking in on some older tickets with blockers. I know Edmund has been out. Wondering where this ticket sits in y'all's backlog / if you have a sense when it might be possible to look over? (Feel free to say: not high priority right now, ask us again later.)

[jilladams]

@gracekretschmer-metrostar @michelle-dooley hiya. FYI that in addition to #17424, Sitewide has a new use case for Client-side validation that would ideally depend on the fix from this ticket: #18280.

In #18280, we want to add new client-side validations on the phone paragraph type field for the following scenarios:

• Phone number field
  • Invalid format
  • Invalid length
  • Invalid characters
• Extension number field
  • Invalid characters

In order to do so, we will need some help from y'all. As far as I'm aware, the client-side validation implementation isn't documented yet, so we aren't sure how to go about using it correctly. And, theoretically because client-side validation is currently enabled for all forms, but won't be after this ticket merges, it would help us to understand when this work can be scheduled. (If we implement before this ticket closes, this ticket will regress our changes by limiting scope for client-side validation to just 2 forms, I think.)

Thanks for any insights!

[gracekretschmer-metrostar]

Slack thread: https://dsva.slack.com/archives/CT4GZBM8F/p1721406079937019

[jilladams]

Per meeting with Edmund, Grace and Daniel:

• We'll rewrite this ticket to recap our actual intentions, which are no longer to limit the module to 2 forms.
• Instead we'll hook into the module to provide an exception list for forms where it should not run. (I think.)
• Daniel to help rewrite the ticket and verify the technical approach.
• Either Sitewide or CMS teams can implement the changes, when either team is able to prioritize the work. Sitewide labels are added, for that reason.

FYI @FranECross that means this will become Drupal work we could opt to pull in at some point.

[gracekretschmer-metrostar]

@jilladams thanks for the write up. Confirming that your second bullet is correct, the exact vocabulary that Daniel used was to create a blacklist for forms to be excluded from the clientside validation module. Two other bullets I would add:

• @edmund-dunn will be available to answer any questions about the clientside validation module for sitewide developers.
• With this blacklist work, a readme file will be created, summarizing this work.

[jilladams]

Sitewide has run into another case where issues with client-side validation break expected behavior for validation on required fields:

• SPIKE: Understand why validation of the Operating Status Details is different for CAPs than facilities #19901

I'm advocating that we go ahead on Sitewide and try to pick up / prioritize this ticket, since it's been difficult for CMS to prioritize.

Per our discussion on 8/19, I've rewritten the ticket accordingly. This will need product testing on all the affected forms to make sure we don't break anything, so I also cut a QA test plan ticket for it: #20160

[jilladams]

@edmund-dunn @gracekretschmer-metrostar given the number of forms being affected by it now, could one of you add a note here just reminding us why the module needs to stay enabled globally, vs. restricting it to the 2 media forms? Just so we have that documented for the histories. (I didn't capture that back from our August meeting and can't remember now.)

[omahane]

I have looked into the module and didn't see an issue like this, so I created on. Ideally, this is done on a patch for the module itself: https://www.drupal.org/project/clientside_validation/issues/3495738#comment-15914622

[jilladams]

Nice. Added the Drupal contrib if we write it as an AC.

[omahane]

I had a conversation with some CivicActions people, and I'm going to expand the scope of the request to include a configuration for fields to exclude (no matter whether we are validating all forms or only specific forms).

[jilladams]

Added to ACs

[Agile6MSkinner]

@omahane Does that mean it needs to be refined again or is it still ready?

[jilladams]

@timcosgrove FYI, discussed this with Grace today, and Sitewide is going to pick up this work in our sprint that starts today, and we will make sure you get eyes on it before we merge.

[omahane]

Need to add the following:

node_event_form
node_event_edit_form
node_health_care_local_facility_form
node_health_care_local_facility_edit_form
node_vba_facility_form
node_vba_facility_edit_form
node_vet_center_form
node_vet_center_edit_form
node_vet_center_cap_form
node_vet_center_cap_edit_form
node_vet_center_mobile_vet_center_form
node_vet_center_mobile_vet_center_edit_form
node_vet_center_outstation_form
node_vet_center_outstation_edit_form

to /admin/config/user-interface/clientside-validation

[omahane]

I have updated the ticket to reflect the focus on form exceptions, rather than also attempting field exceptions.

[omahane]

The PR merged today (17 Jan) and should be deployed on Monday (20 Jan).

[omahane]

As of 21 January 2025, 11:17 CT, this work has not been deployed: