More advanced email handling

[ihartwig]

Background

As a user of tracker, I think that our current email handling system leaves a lot to be desired. It was also designed in a different era where email was generally an endpoint and not a hosted service. Given that we have not pulled emails in several months, I think this is a good time to think about overhauling

My main complains with the existing system are:

• Horrid formatting of stored emails/lack of html rendering.
• No concept of conversations or threads/replies.
• Time delay in receiving new messages due to manual filing required by exec member.
• No support for attachments.
• No way for a non-exec TiC to respond to emails from tracker.
• Lack of a clear workflow to go from email to event (within tracker)
• No good mobile access to new email (due to gmail delegation/slow imports in tracker)
• Storage of full email text seems unnecessary since we also have it backed by gmail (minor)

What I see out there are good ticket systems that focus on interactions with customers and have a tight coupling between tasks and the email/conversations happening. Having these conversations coupled to our events - as a tool leading up to the event rather than archive - would save everyone's time and prevent many surprises to TiC at events. This would also make it much much easier for non-exec members to TiC an event. By taking advantage of the Gmail API, we can implement a much cleaner system that is not burdened by the overhead of IMAP + gmail extensions. According to the Gmail API developer pages:

The Gmail API gives you flexible, RESTful access to the user's inbox, with a natural interface to Threads, Messages, Labels, Drafts, and History. From the modern language of your choice, your app can use the API to add Gmail features like:

• Read messages from Gmail
• Send email messages
• Modify the labels applied to messages and threads
• Search for specific messages and threads

Coincidentally, these are exactly the actions I think we need to be able to perform.

Workflow Suggestions

If we do decide to build something new, we should focus on reducing the time requirements on the HoT/exec to manage email and improving the connection between a happening event and the conversations about it. I think the following workflows are a good example of what we can do.

File an email with an event on tracker

Tracker creates gmail labels for all events based on some unique combination of title/slug and event id.
An exec member can add a label to the thread in gmail for that specific event.
The tracker event page pulls up all threads under the unique gmail label on load.

File a response to an already filed thread

Since gmail handles threading (really well), and the email already has the unique event label applied, this message will appear next time the event page is loaded.

Respond to an event organizer about an event

Option 1:
File the email using the unique event label.
Respond to the email using gmail's web interface.
Response is added to the thread automatically.

Option 2:
File the email using the unique event label.
Assign a non-exec TiC.
TiC can respond to organizer using a reply function built in to tracker and integrated with tracker permissions.

Create a new event from request email

Exec member adds a special new event label to the email in gmail's web interface.
HoT can go to a view of all pending event requests in tracker, choosing one to convert into an event.
Alternatively, the HoT can decide to decline the event, logging the correspondence in tracker.
If converting into an event, the HoT can transcribe the email contents into the corresponding tracker fields and/or request more details.

Handle file attachments

When a file is being viewed on the event page (after filing), there should be functionality to download any attachments included in the message/conversation.
A stretch feature would be to automatically transfer attachments to the event's google drive or dropbox.

Implementation Suggestions

Although we store a full copy of emails now, I don't think this is necessary. We are actively using gmail as an archive of the abtech inbox. There may be a time in the future where Google decides to discontinue gmail as we know it, but I think that we will need to address this when the time comes. Instead, we can either store a label per event and use the gmail database to store the label/thread/message relationship, or we can store thread ids in our database for request from gmail later.

It seem quite unlikely that we will be able to migrate all of the old emails into a new gmail system. The best way that I can think of to handle this is to build the email modules side by side. New events will not have anything in the old email database, so there will not be any emails to display anyways.

With all of this said, I would love to work on implementing these features. Right now, it does not look like I have time to actively contribute. However, I think it would be a huge benefit to the organization to have this.