Dbex user identifiers status check

[NB28VT]

Summary

Overview

Implements the back end portion of a highly-requested fix to confusing and misleading error messages Users encounter when attempting to fill out Form 526. This has been a significant source of frustration for Veterans, as the message blocks the User from proceeding and prompts them to reach out to a Contact Center, but only provides a limited and in some cases completely inaccurate indication of what the problem is.

A recent round of Medalia research made this need even more clear.

The changes are placed behind a feature gate as we may want to release this progressively. The front end is implemented here

Here is a demo of the UX for the page before and after the changes:

Screen.Recording.2024-01-02.at.5.57.15.PM.mov

Changes

Adds a new set of Form 526-related metadata to the main user profile JSON object returned from the user endpoint (/v0/user) that drives that portion of the VA website.

The data is nested under the "claims" portion of the profile and lists a handful of User identifier fields we require to be present for a User to proceed with filling out Form 526, and indicates whether we have them or not:

{
  "form526_required_identifier_presence": {
    "participant_id": true,
    "birls_id": false,
    "ssn": true,
    "birth_date": true,
    "edipi": true
  }
}

The changes are hidden behind a feature flag to allow us to safely test this in staging.

(Note, an earlier version of these changes was PRed over the summer, but this fix was deprioritized. I've elected to start with a fresh branch for various reasons I can expand on )

The Problem

The front end logic for Form526 prevents a user from starting their claim if any of the following data is missing in the User object we have stored for them:

• Date of Birth
• SSN
• BIRLS ID (Beneficiary Identification and Records Locator Sub System)
• EDIPI (Electronic Data Interchange Personal Identifier)
• Participant ID

Currently, when some of this data is missing, we stop them from proceeding with the form, and display one of a number of different messages like the one included at the top of this PR description

After tracing through some convulted code in the front and back end (link to findings report here), I discovered these messages aren't even really accurate, aren't standardized and in some cases don't tell the User anything useful at all.

The Solution

As implemented in the front end PR for this fix, the front end will use the more detailed metadata added in this PR to display a single standard message along with the exact list of what is missing, so they can pass that information along to the contact center.

• Which team do you work for, does your team own the maintenance of this component?: I am on the DBex team, working specifically to improve submission success rates on the 526ez form. This work will only affect the 526ez flow, which is maintained by myself and my team.

• (If using a flipper, what is the end date of the flipper being required/success criteria being targeted) Unknown, my team is still new and working out what our release strategy will be, but I imagine after a couple weeks of having these improved messages live we will feel comfortable enabling them for all users.

Related issue(s)

• See report mentioned above for more detail on how the problem was identified and addressed

Testing done

Testing this locally is a little challenging, as we need to muck with the mock data for a user and even then I could only figure out how to remove a handful of the data we are checking for (figured out how to delete the BIRLS ID, SSN and birth date for a User).

For the other cases, automated tests in the front and back end give me a good amount of confidence this works as intended.

What areas of the site does it impact?

This should only affect the Form 526 workflow.

Acceptance criteria

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No error nor warning in the console.
• Events are being sent to the appropriate logging solution
• Documentation has been updated (link to documentation)
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Feature/bug has a monitor built into Datadog or Grafana (if applicable)
• If app impacted requires authentication, did you login to a local build and verify all authenticated routes work as expected
• I added a screenshot of the developed feature

Requested Feedback

N/A

[mchae-nava]

Nice! LGTM

[NB28VT]

@jerekshoe recall we spoke about this some months ago, apologies for the delay in revisiting it my team deprioritized this fix for a while. I figured you may be the best person to look at this but feel free to delegate.

The PR description should make things clear enough but feel free to ping me if it makes more sense to hop on a call at some point.

One open I question I have is if we want to/it's even possible to do testing on this staging. You may recall I asked for your help in learning how to modify some of the XML for mock data users to remove SSN, birth date etc. which is how I was able to test this locally. Is it possible to do something along those lines in staging or is it probably best just to open the feature gate for a small amount of users to start in production?

Thanks!

[dickdavis]

🗣️ Have you tried a different approach that didn't require stubbing out the messages? For example:

RSpec.describe Users::Form526UserIdentifiersStatusService do
  describe '#call' do
    subject(:call_service) { described_class.call(user) }

    describe 'participant_id validation' do
      let(:user) { build(:user, participant_id:) }

      context 'when participant_id is missing' do
        let(:participant_id) { nil }

        it "returns a hash with 'participant_id' marked false" do
          result = call_service
          expect(result['participant_id']).to be_falsey
        end
      end

      context 'when participant_id is present' do
        let(:participant_id) { '8675309' }

        it "returns a hash with 'participant_id' marked true" do
          result = call_service
          expect(result['participant_id']).to be_truthy
        end
      end
    end
  end
end

[NB28VT]

Thanks, good suggestion, this needs to go out soon but I'll keep this in mind for my next specs!

[dickdavis]

LGTM, thanks for addressing the feedback. I left one additional comment about the specs, but I don't want to hold you up, so feel free to ignore if you don't feel it needs to be addressed.