Build out SmsResponseController

pinging @MisterJames @tonysurma @stevejgordon for feeback on if the assumptions I’m making below are correct.

This Issue is expanding upon the following line items from Issue #1084:

• If request is confirmed add “‘N’ if you can no longer make it” and if they respond N mark unassigned
• If request is not confirmed add “‘Y’ if you can make it, ‘N’ if you can’t” and set status as above

allReady sends sms confirmation messages to requestors whose Request has been Assigned to an Itinerary. The following code sends these messages:

RequestsAssignedToIntineraryHandler
SendRequestConfirmationMessagesAWeekBeforeAnItineraryDate
SendRequestConfirmationMessagesADayBeforeAnItineraryDate
SendRequestConfirmationMessagesTheDayOfAnItineraryDate

The requestor can reply “Y” or “N” to confirm the request. This Issue includes the following work:

• identify how to attach the RequestId from the Request model to the outgoing sms messages. The RequestId has to survive the round trip of being sent out (by the classes listed above) and then trip back to SmsRequestController.
• in SmsRequestController, we look up the Request by RequestId. We cannot correlate the incoming request from the Requestor by PhoneNumber as the Requestor could have more than multiple requests that have been added to different Itineraries. If we looked up the requestor by phone number, we would end up with two requests, so we would not know which request to mark as Confirmed.
• there is code already written in SmsRequestController that needs to be uncommented based on the Requestor’s reply of “Y”/“N”
• most likely, this will involve Twilio to a greater extent than how we currently use it (which is just to send sms messages). You will need to set up a Twilio account and either use your mobile phone or open a Google Voice account to test the receiving of text messages as well as the reply of “Y”/“N” to those text messages.

[tonysurma]

Do you know of any way to put something in the HTTP headers (like the RequestId) or something else that could survive the round trip of us sending them the sms confirmation, and the requestor sending us back confirm/cancel? It seems like something… “easy”… I just don’t know enough about SMS/Twilio to know how that technology really works.

I know that there isn’t such a thing and technical no relationship between the SMS out and back to you in Twilio, so you have to match up by phone number you were texting for example

[stevejgordon]

I believe in any case, having a table to record the notifications we have sent is going to be required, so I’ll break out an issue to add that as the first part of implementing this.