Email integration for new tasks

This feature has been implemented.

Clocking IT interacts with the outside world in several ways already: the web interface, Google widgets, and outgoing email notifications. This proposal extends the email process to include receiving emails back into CIT and creating new tasks.

Use cases

• Support organisation who need to manage their incoming email and get it out of individual inboxes and into a project/task management system.
• A simple method of creating a new task: email comes in to a user who then wants to make a note of it as a task. They drag the email or redirect it to a special mailbox which is forwarded into CIT.

Challenges

• Keeping track of who reported an issue.
• Making sure we don’t open CIT to spam.
• Making sure that users don’t spoof the email FROM address to impersonate other users and thereby extract information from CIT (beyond just spamming a task)
• Support different types of email formats
• Matching incoming email to a project and task

New tasks

When an email comes in with no relevant metadata, a new task is created with title the same as the subject and a new message as the body of the email. Attachments are stored. The ‘to’ address of the email is evaluated and a CIT user is found with that same email address. They are assigned to the task. cc users are also assigned. An automated response is sent to the sender to indicate that the task was created.

A problem in CIT is that every task requires a project. Solutions:

• Allow orphaned tasks with no project. They would appear somewhere special and prompt the users that they require filing in the appropriate place, which is the first step of triage for new tasks.
• A default project is used for incoming email. This might be a special ‘incoming triage’ project, but it would be up to the admin to set this to their liking.

In addition, do we assign a default user to be assigned to the task or leave it null? Each has its advantages.

It is possible to incorporate metadata from the email itself. If automated collection of this metadata is important, I’d suggest a template block at the top of the incoming email, such as the existing Bugzilla format. It has been well thought through and the compatibility would be useful.

http://www.bugzilla.org/docs/3.0/html/api/email_in.html

Identifying users

• Preference to disallow/allow unknown users from submitting issues (for spam protection)
• Support looking up a CIT account based on an email. If an account is found then attach that user as a watcher to the task, otherwise attach just the email address.
• In the case where there are multiple users with the same email, then we should add just the email address.
• When a user reports a task via email, a confirmation email should be sent to the originating email address. This needs to be a template somewhere.

This process would be simplified if users could be forced to have unique email addresses within CIT.