Feature: 'ping/poke' owner of ticket during trade to nudge them to complete

[jfryman]

@kzettel yesterday made a passing comment... something along the lines of 'I was getting a bit worried there for a second if the trade would go through... it'd be nice to have some ability to poke the ticket owner to see if they could ack the trade'

So, some thoughts:

• As a user, I should be able to request an update via notification, so that I can get mai tickets.
• As a ticket owner, I should be able to receive an SMS to my mobile device, so that I can get updates on new trades or pokes, so that I can sell mai tickets.
• As a ticket owner, I should only be able to be poked at most 1 time / hour (this number is arbitrary, but a starting point), so that I don't get flooded with update requests
• As a ticket owner, I should be able to approve a trade via SMS, so that I do not have to log into the website.

These are just a few thoughts, and I'm just now looking at the code so I have no concept of the LOE required here. Thoughts/comments/whatever appreciated.

[stephenyeargin]

All of this is predicated on a dream for a native SeatShare mobile application that would reduce the need for as much SMS chatter (for most users). That being said, these bits would be far easier to bite off in the interim, and offer a fall-back for future users that don't want to install the application or have simple feature phones.

---

The current setup for requesting a ticket is rudimentary. It logs an entry into a TicketHistory model and passes it on to the TicketNotifier (controller calls). So at the moment, there is not a status associated with the ticket that marks it as "requested".

As a user, I should be able to request an update via notification, so that I can get mai tickets.

Item 1 above is somewhat covered by the notification that is generated when you are assigned the ticket (as in, the ticket owner makes the assignment of the ticket to you, the user). This is still just an email notification, as that's the only communication channel currently available.

As a ticket owner, I should be able to receive an SMS to my mobile device, so that I can get updates on new trades or pokes, so that I can sell mai tickets.

Item 2 introduces the fun bits. The most direct approach would be to update the User model with additional profile fields (specifically, an SMS phone number or gateway (e.g. 5555555555@vtext.verizon.com) and then have it as a GroupUser option (soon to be renamed Membership per #87) to turn on all SMS notifications for that group. The alternative is to allow a more granular approach, where you subscribe to activity (as an owner or other actor) on a specific ticket. That is to say, "don't message me on all tickets that I'm associated with, but definitely notify me about this one." I'm leaning towards making it just a group option, similar to the scheduled emails. Took care of this by creating a Profile model for the user and allowing them to provide their phone number. Got a Twilio account and have started sending SMS notifications on basic request/assignment.

As a ticket owner, I should only be able to be poked at most 1 time / hour (this number is arbitrary, but a starting point), so that I don't get flooded with update requests

Item 3 could be a one-off, user initiated action that just sends the message "John Doe pinged you about the ticket for September 30 in Geeks Watching Hockey". If the model changes significantly, these could be automated a bit so that it follows the logic "ping the user 24 hours before the scheduled start time if a requested ticket's status has not been updated in that period of time, and ping them again 3 hours prior to the scheduled start time if it still has not been updated."

As a ticket owner, I should be able to approve a trade via SMS

Item 4 has Twilio written all over it, as I have no idea how else we would go about receiving text messages, translating them to webhooks and acting on them accordingly. I do ❤️ this idea though.

Update: We're sending outbound SMS using Twilio, but nothing yet on processing received messages. We could identify the user by their mobile phone number, but figuring out which ticket they are acting upon may be a bit trickier unless they included some other identifier, e.g. Yes 300402 to accept request_id = 300402. #121 goes more into what a that request_id would be tied to.

[bval]

Discussed this with @stephenyeargin some last night but I am going to attempt to provide an .ics endpoint that contains as much data as we have about the group status and the individual user's ticket status for each event. Would also provide some built-in calendar reminders for various types of events. iOS and Android Calendar will already notify you of any reminders that show up in the iCal feed. Not the dream solution, but seems like a decent stop-gap where we get to piggyback on the Apple/Android user experience.

[stephenyeargin]

I've added a user.profile.mobile field with #116 that will let you set your mobile number. I think Twilio is a dollar a month and a penny a text, which I think I can swing for a while. If I had added the carrier code, we could probably use the SMS-Fu gem to facilitate it through the gateway for free, but that always seemed hokie to me.

[stephenyeargin]

Signed up for a trial Twillio account.

[stephenyeargin]

Shipped some ICS stuff in #196, #202, #203, #204 (try, try again) but it currently does not include specific ticket details for your group/event.

There still needs to be some sort of Request model that works as a bit of state machine for facilitating ticket transfers. I jotted down some notes on some baseline rules for such a component:

https://gist.github.com/stephenyeargin/78adfe72f28b97e603ad