Currently our request model does not hold a country property. While we start in US this is not a major issue, but if we get any non US usage, then holding this would be useful as we need to know a requests country in order to call the Twilio API correctly.
By default we use a US country code for the Twilio validation, but this will cause any non US requests to fail phone number validation (or return a valid US number instead of for the correct nationality).
We could also ensure we send this with GeoCode request to get the lat/long to avoid ambiguity.
@tonysurma - I would propose there we add this to the model and update places where we add/import requests.
@mgmccarthy - Do you know if GASA can send the country in their request API calls? If not, perhaps for can set a default based on the Org lookup?
Currently our request model does not hold a country property. While we start in US this is not a major issue, but if we get any non US usage, then holding this would be useful as we need to know a requests country in order to call the Twilio API correctly.
By default we use a US country code for the Twilio validation, but this will cause any non US requests to fail phone number validation (or return a valid US number instead of for the correct nationality).
We could also ensure we send this with GeoCode request to get the lat/long to avoid ambiguity.
@tonysurma - I would propose there we add this to the model and update places where we add/import requests.
@mgmccarthy - Do you know if GASA can send the country in their request API calls? If not, perhaps for can set a default based on the Org lookup?