EVSS to Lighthouse Migration - Submit - Treated Disability Names

[aurora-a-k-a-lightning]

Question:

• is this as simple as using the data_translation_all_claim#scrub_disability_condition on the treatment names? is there a business reason to not do this?

Additional Information LH /validate Validation Error:

The treated disability must match a disability listed above.

Our treated disability names are not matching with the disability names. Disability name will be something like "foot pain", and treated disability names will look something like: "foot pain" Data samples:

• "Manières disease" was converted to "Manires disease" (accented letters)
• "\"PTSD with insomnia\"" => "PTSD with insomnia" (backslashes)
• "Code 7016: Heart Valve Replacement" => "Code 7016 Heart Valve Replacement" (colon)
• "Vertigo & Drop Syncope" changed to "Vertigo Drop Syncope" (ampersands being stripped out)

[sethdarragile6]

Repro'd the issue on Staging with @christinec-fftc . With the lighthouse flag on, she entered "foot pain" (with 2 spaces as a condition. She got an error in the UI, but the form was submitted. The submission form fits the pattern we were seeing, and the job status fits the error. Doing a sub.form_content_valid? also reproduces the exact exception we've been seeing.

She then retried the scenario with the TE flag OFF (EVSS-style). This time, success in the UI. Same issue in the submission form, yet the job was a success:

Other wierdness observed (I blame PDF for being an old and funky tech): the generated EVSS PDF (below) seems to clearly show the two spaces of "foot pain" preserved, yet when you copy them to Notepad, it turns into ONE space. Wth? Christine observed similar behavior with a different PDF. When copy/pasting to Sublime, it preserved the two spaces, but when pasting to Slack- two became one. Not in the cool, sexy way Prince sang about, but in an irritating, buggy way...