stephenyeargin
commented
10 years ago 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 Took care of this by creating a 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.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 :heart: 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
@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:
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.