MVP address validation resiliency

[porta-antiporta]

From #60, where a decision on address validation resiliency was made

In the event that SmartyStreets encounters an outage:

• Create a parallel app that will intake orders
  • Backend: email is mandatory
  • Frontend: email is mandatory
  • Frontend address presence validation, no API validation
  • Backend address presence validation, no API validation
  • Remove "email is optional" text
  • Deploy to staging env
• Orders will be saved without validating address
• Upon API recovery, a background process will validate address for those orders
• Email can be used to contact users of any post processing issues encountered by that process
• Sitchover/Trigger mechanism from the primary app to this parallel app when SmartyStreets outage occurs

[hartsick]

@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?

[porta-antiporta]

@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.

[hartsick]

@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!

[porta-antiporta]

need :TIL: reaction

[hartsick]

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

[hartsick]

@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."

[porta-antiporta]

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

[hartsick]

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 ?

[rahearn]

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)

[porta-antiporta]

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).

[hartsick]

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

[porta-antiporta]

closing with #153 tracking the remaining bug.