MVP address validation resiliency about test-at-home HOT 12 OPEN

@porta-antiporta gotcha. we're not technically requiring those elements on the backend (just letting API tell us what is needed), so was confused! thanks for clarifying!

from test-at-home.

@porta-antiporta For this, when address validation is disabled we could easily require that certain fields be provided (eg mailing address 1, city, state, zip code) in addition to email. What do you think?

from test-at-home.

@hartsick yes to clarify the ask is:

email is mandatory in addition to existing mandatory fields

so however which way we achieve that is fine by me.

from test-at-home.

need :TIL: reaction

from test-at-home.

@hursey013 could you tackle the front end parts of this? related to #89

from test-at-home.

@porta-antiporta I also removed the "This step is optional, but we will not be able to provide tracking without an email." if email is required.

the label is a little weird since it may be interpreted as a suggestion: "To receive updates on the status of your order from USPS, please provide an email address."

from test-at-home.

@hartsick i think for an MVP for a backup of a backup, that content change is sufficient.

from test-at-home.

I think we're done with the intake application, except for deploying to a production environment. I believe one of the staging environments already have this work on it based on deploy in Circle, but not sure of the URL. @rahearn ?

from test-at-home.

right now, https://test_at_home-stage.app.cloud.gov/ should have smarty streets enalbed (though likely with a key that doesn't have any credits left...) and https://test_at_home-stage.app.wb.cloud.gov/ has the version with smarty streets disabled (and thus other fields should be required to be present)

from test-at-home.

just ran a quick validation on the app that has smartystreets disabled:

• email address presents as optional (no *)
• email address is optional (was able to submit the request and got to confirmation page)
• was unable to check to see if on the persisted info, there's a way to discern whether an entry was one run with smarty sheets disabled or enabled. (presume we could detect that via absence of the JSON response).

from test-at-home.

I'm looking at that server and it's not what I expect it to look like if smarty was actually disabled—I suspect the env var isn't set correctly in the environment? will look into in the morning

from test-at-home.

closing with #153 tracking the remaining bug.

from test-at-home.