An achievable way of handling external contact requests in teams

Bugs

Bugs & Wishes

Open or Pending

A real world example

Taken from an initial mail from MatWho

We need something I have started calling "groupmail" Basically this allows a group of people to have an email address and use Tiki to manage the incoming/outgoing e-mail messages. So here is a suggested use (which is the project I first need to implement it on).

Some registered Tiki users in a group called HelpDesk have an email address of help@charity.org. The mail server is set up to virus/spam check all the incoming mail and then deliver to the normal mail box (this is the backup/audit trail), but also send a copy to a second mailbox.

Groupmail will "pick up" from this second mailbox, it would be reat to be able to specify the mail folder it picks up from (using POP IMAP or directly from the mbox directories).

It would be very convenient if we could specify the folder from which e-mails are taken, the default being the INBOX. This would allow a human to sort the incoming e-mails and by putting them in the specified folder they would effectively be "sent" to the help team.

It will then sanitise the email's contents (strip out HTML, images etc?)

These incoming e-mails will be presented to the group in a list (I also imagine a Tiki module showing the contents of this list)

The list will allow a member of the group to view incoming e-mails and then flag selected ones as being "theirs" ie they have started work on them.

Once they have finished working on them they can delete them from the list, or put them back if they have not dealt with them and want someone else to work on them.

If the incoming e-mail is from a known person (the test should be customisable based on from address, Name in email contents, reference number in subject etc) it will be shown in the list with the from address as a link to a wiki page for that person. This will allow you to quickly look up the "case notes" for that person.

The flags used to indicate that someone is working on an email should update in everyone's browser very quickly, to prevent two people starting work on the same incoming email at the same time. I thought we could extend the mini-chat module to send flag status information between browsers.

Once someone is working on an incoming email they will want to do one of several things: look up the person's case notes (a wiki page), start a new contact (create a new wiki page for this person), dump the email (its spam that got through the filter), send an email back as a reply (ask for some more details before deciding to set up a new contact page), set a task to-do (for example schedule a phone call, plan a visit)... (This could be extended in many ways at this point, set up a case management system, add a bug report to a tracker, book on an event and so on)

When they have finished with an email it will get saved in to a traker, with some fields to indicate who dealt with it, what the action was (phone, made booking, sent info pack etc), is it closed/open etc

When you go to a contact's wiki page, there will be plugin this will list out all the e-mails that have been sent/received from this person. If we use trackers for the storage of contacts then the existing tracker plug-in will do.

Presentation and discussion at TikiFestMadrid

A UI prototype

To help get the requirements right, I have started on a rough non-functional prototype of the UI http://bickertons.net/test/

The Components

• Trackers should hold the "TAKEN" emails, contacts & user and group extended info.
• Groups will need a way of accessing and sharing these messages
• Group alerts used to forward mails (actually wiki pages) to other tiki users within your group

14 Jan 2009 - MB & JB planning meeting 1 (and #2 6th Feb)

Full of Tiki goodness!

• Use WebMail (tiki-webmail.php) to config and manage inbox (No more Commlib)

  • Email Messages stay on server until processed
  • Add IMAP (specify folder default INBOX) and local mbox file access to webmail (using Zend)
  • Options to "TAKE", "READ" or "DELETE" mails
  • Once "taken"
    • Convert message into tracker item (tiki-ticket)
    • Simple HTML parse into wiki-markup if pos, if not text only (Use Zend_Mail)
    • Add mapping of email parts into fields (to, from, account_id (webmail), subject, body_text, body_html, date_sent, date_received, priority, attachments, user_assigned, last_mod? etc)
    • File attachments (into File Gallery)
      For future dev

• Trackers (more info trackers):

  • User
    • Signature
    • From
    • GroupMail Status ("not in until Thursday", "reformatting - go away!" etc)
  • Group
    • Signature
    • From
    • Select webmail account/s for group

• Modules:

  • "GroupMail queue" (webmail_inbox)
    • Group dropdown + My Messages
    • Webmail accounts dropdown (for each group)
    • List of objects for that account
    • Each object:
      • "TAKE", "READ", "DELETE" button
      • "taken" flag,
      • status colour coding (goes red after an hour etc, green assigned, yellow/orange - new for GroupMail, read/unread/flagged etc for normal mail)
      • From address: underlined if previous contact (or users)
  • Mini-chat
    • Investigate & extend or add to (duplicate, but be compatible 😉
  • Who else is online?
    • Extend existing - add GroupMail Status from Tracker
  • Search GroupMails
    • Results
    • Conversation (list of messu_messages with email address/User)

• Contact tracker

  • Holds info about message senders

• The middle bit (tiki-groupmail.php)

  • Click on mail in list - "TAKE" button creates tiki-ticket)
  • When taken:
    • REPLY
      • DELETE
    • If new:
      • ADD to contacts
      • ADD or ATTACH to wiki page
    • else
      • VIEW conversation (history)
      • VIEW wiki page
    • NEW tiki-ticket (from phone call)

• Logging (v1.x)

  • Into tiki actionlog

Outcomes from TikiFestMadrid

Just some notes mainly so far - Feb 2009

• We will use the terms "Tickets" or "Cases"
  • We will use Tickets for now, this would allow for cases to be used in the future if we want to collect tickets together in to Cases. But we don't need this now, so leave that for Phase 2 or 3.
• LP suggested we put all emails in a tracker
  • Probably not, as it exposes the tracker to possible overload if flooded, and uses resources up storing junk or inappropriate mail.
• We should check each incoming email against the email address in the contacts tracker.
  It was suggested we should also allow alternative addresses to be put on the contact details to accommodate people moving mail accounts or using more than one. (Good idea for Phase 2). Also for phase 2, we could match on something in the subject line, for example a Ticket/Case number.
• We should use "data channels"
  • These will handle creation of "Ticket" tracker items, wiki pages and eventually Users and Workspaces
• It would be good to have the ability to "Watch for known people"
  Is this is already handled by the existing features of Tiki, because we will create a wiki page for each person, when we add a ticket will the watch on the wiki page get triggered. The ticket tracker will be on the page as a tracker plugin?
  • This was so a Case that has already been started should be continued by the same Operator (need a definition of terms somewhere)
• It would be good to be able to convert contacts in to Tiki users and then give them a workspace/perspective so they can login to see ther case history
  (Really good feature definately Phase 2 and we need the workspaces stuff to be finished first )