Notifications model and index view

[bval]

Currently ticket requests and other types of notifications are not modeled or stored anywhere. This will make doing true push notifications tricky. We need some way to model and store these, and acknowledge them / delete them when they have been viewed.

It would also be nice to have an index view of read / unread notifications that link to the relevant ticket or whatever they concern so you can login to the app and see what requires your attention.

[stephenyeargin]

Heavily related to #100 ... shame @jfryman isn't accepting his invite :scream:

[stephenyeargin]

This also would help accomplish a few other things:

• Reduce the size of the tickets_controller (it's huge) by abstracting some of the notification lines
• Possibly play into the idea of keeping up with a ledger of who owes what (creates a paper trail of request/transfer)

May need to whiteboard this a bit.

[stephenyeargin]

Some thoughts. The idea of splitting it out into a separate model would make notification triggers a bit easier (such as traversing all upcoming events with unfulfilled TicketRequests). It would also make the accounting aspect clearer, as these would become the actual ledger entries.

---

TicketRequest model

key id
int ticket_id
int transfer_to
int transfer_from
decimal cost
text  transfer_method
text  transfer_details
time  transfer_completed
text  payment_method
text  payment_details
text  notes
timestamps

Initiated by a ticket requestor

• A TicketRequest is created each time a user who does not own a viewed ticket clicks request.
• The cost is copied from the current ticket cost
• The ticket owner reviews the details and completes the transfer, indicating the transfer method and details
• The ticket owner can adjust the cost as well
• The user_id is updated on the ticket accordingly
• Payment details can be updated later by the ticket owner
• If a request is rejected, it is deleted (?)

Initiated by a ticket owner

• A TicketRequest is an optional step - the owner can simply update the assignment without using a request to bypass accounting system (such as to themselves)
• At discretion, a TicketRequest can be generated to create an obligation to the target user
• Payment details can be updated later by the ticket owner

[bval]

Like this. Suggest we use a state machine gem to implement this as it'll model the state transitions appropriately and give us places to hook in for emitting events to the relevant parties when a request changes state. Have used the pluginaweek/state_machine gem before but there are others we could look into.

[bval]

Looking at implementing this to power the notification system: https://github.com/mailboxer/mailboxer

Would appreciate a quick gut check from others before I do. Biggest pros appear to be:

• Accomodates both system notifications and user-to-user conversations (a feature we might want to add later)
• Keeps track of read/unread state of messages (could help with #100's nudge feature)
• Largeish active maintainership
• Big fork network / lots of contributors

Cons appear to be:

• Lot of open issues / slow progress on closing them
• No native support for SMS and APN, I'd have to fork and add those (don't see this as a big deal, I'd still have to write the code if we don't use this gem)