EVSS Migration - 526 Submit - Military Service Address (Discovery)

[sethdarragile6]

Issue Description

Lighthouse recently started conversations around the use of submit requests elements pertaining to the military address of the veteran that EVSS had used, but they omitted. From LH:

It turns out they [EVSS] were internally mapping militaryStateCode to state, and militaryPostOfficeTypeCode to city. That is how the values would be displayed in VBMS. So, we were wondering if you could keep collecting the information as you do today from the Veteran, but map those to state and city on our Claims v2 526 request? That should still mimic the existing functionality without adding additional attributes to our request.

Long story short: LH would like us map the veteran's military address to LH's single address fields

slack thread 1 - ? OG thread from Kayla, I couldn't find it Kayla - My team is looking to confirm if the 526 submission flow on VA.gov needs to support Military address types. Is your team the correct team to direct that question to? We are specifically wanting to know if you are currently using militaryStateCode or militaryPostOfficeTypeCode in the EVSS Form526 request. I discussed this further with Michael Harlow to confirm how EVSS was treating these attributes. It turns out they were internally mapping militaryStateCode to state, and militaryPostOfficeTypeCode to city. That is how the values would be displayed in VBMS. So, we were wondering if you could keep collecting the information as you do today from the Veteran, but map those to state and city on our Claims v2 526 request? That should still mimic the existing functionality without adding additional attributes to our request.

slack thread 2

---

Tasks

• [ ] Better understand how EVSS would map military addresses. For example, militaryPostOfficeTypeCode in EVSS is actually an enum with possible values APO, DPO, and FPO, and so does not map directly to a city
• [ ] Better understand how we (vets-api) gathers and transforms this data (if at all)
• [ ] Understand how internationalPostalCode comes into play, as this appears to be related to address mappings
• [ ] Talk to EVSS/LH via Michael Harlow/Bonnie Craig

Acceptance Criteria

• [ ] Artifact for LH detailing the outcome of this discovery (Diagram / documentation / something else)
• [ ] Update implementation ticket with finer details resulting from discovery
• [ ] Produce a list of pertinent questions for Lighthouse (Kayla) to post in the migration channel

Screenshots

Private Zenhub Image (from EVSS/LH Mapping doc)

---

How to configure this issue

• [ ] Attached to a Milestone (when will this be completed?)
• [ ] Attached to an Epic (what body of work is this a part of?)
• [ ] Labeled with Team (product support, analytics-insights, operations, service-design, Console-Services, tools-fe)
• [ ] Labeled with Practice Area (backend, frontend, devops, design, research, product, ia, qa, analytics, contact center, research, accessibility, content)
• [ ] Labeled with Type (bug, request, discovery, documentation, etc.)

[sethdarragile6]

Here's how we process military and (international) addresses in vets-api currently (in data_translation_all_claim.rb, --> def translate_mailing_address)

1. Determine what type of address: a. if the state is AA, AE, or AP, then the type is MILITARY b. otherwise, if country is USA, then the type is DOMESTIC c. otherwise, the type is INTERNATIONAL
2. If type is a. DOMESTIC, then populate city, state, zipFirstFive and zipLastFour per usual b. MILITARY, then populate militaryPostOfficeTypeCode with the city, stripped of whitespace and uppercased, and militaryStateCode with the state zipFirstFive and zipLastFour per usual c. INTERNATIONAL, populate internationalPostalCode from a lookup from international_postal_codes.json based on the country field city per usual

I'm assuming that, if it's a military address, we're expecting city to come in as "APO", "DPO", "FPO"- albeit possibly with whitespace and mixed case. We should confirm whether or not there is front end validation for this, because it seems that the backend code is trying to sanitize a freeform text field here

Other than that little nagging doubt, it would seem that our logic mirrors Lighthouse's expectations. I will post out to the migration channel to be sure, of course.

[sethdarragile6]

Resolved all my questions with Michael Harlow on this thread. Updated implementation story with relevant deets.

[sethdarragile6]

Dug a little more into militaryPostOfficeTypeCode, and inferred that these are coming in as expected, i.e. 'APO'. I was unable to trace it from the front-end directly, complicated by the fact that this information apparently gets pulled in from an external source. But investigating some "black hole submissions" detailed by Sam (and with his help) I was able to clearly delineate that

1. There used to be a problem with unscrubbed values in this field, like 'Apo' or 'APO ', when hitting EVSS
2. A fix was made 2021-08-05 to remove whitespace and uppercase the result
3. From 2021-08-07 on, the problem went away