Akeeba Ticket System is primarily designed as a helpdesk component where submitting new tickets and replying to tickets takes place on the site itself. This allows for intricate, time–saving features like the ones described in the earlier sections about custom fields and InstantSearch.

There are, however, many sites where the ticket workflow is best suited to be managed via email, e.g. there are very few categories (possibly even just one), there is only a small number of people managing tickets (possibly even just one), there are no custom fields, clients are expected to prefer sending an email over logging into the site and so on and so forth. Akeeba Ticket System makes it possible to cater for any combination of the following email–to–ticket workflows:

These workflows are implemented through the Akeeba Ticket System - Fetch Email plugin and CRON jobs.

Caveats

Email messages are far more limited than full blown websites. The entirety of the information you are receiving over an email message can be summed up like this: name and email address of the sender; subject; email body; attachments.

As a result the following features cannot possibly work over email:

Moreover, receiving new tickets and/or ticket replies over email requires making sense of the subject and body of the email.

The subject is pretty straightforward... unless it contains any character which cannot be encoded in 7-bit ANSI. You see, the original email specification (RFC 822) was written back in 1982 and is in fact a standardization of the hodgepodge of message exchange protocols which sprang in the 1970s, back at the dawn of networked computers. Computers were not capable of displaying characters with diacritics beyond some very basic ones, let alone characters from different character sets like Cyrillic, Greek etc. There is a way to encode full Unicode characters in a way that is sent by email and most email clients support it. ATS will try to parse the subject using those standards and do its best to represent it as real Unicode information which can be stored in your site's database.

The body text is even more complicated. You see, email was designed to send short, plain text messages. Most of the email you see today is actually HTML email, i.e. an HTML document sent as an inline attachment, with or without an alternative, text–only representation. ATS will try its best to divine if the email is plain-text only (very popular among Linux and German users in particular), HTML–only or HTML–with–plain-text. If it's just plain text, ATS will convert it to a basic HTML representation since all ATS posts to tickets are HTML. This works for messages sent from the vast majority of mail clients but it all depends on whether the mail client uses the standard convention of attaching the subject as the first inline attachment in the message. Yes, there is no standard for that, just a convention.

The other problem is that every single image you include in a mail message, including inline images, is in fact an attachment. ATS will process all attachments as such, even if they are inline. This means that the email sender's user account needs to have the Attachments permission to allow these to be attached to their ticket. Furthermore, images anywhere in the document, even those inlined below the “reply above this line” which indicates the end of the client's reply, will be processed as attachments — even if they are part of their signature. On top of that, for security reasons, ATS will NOT display attachment inline. Any inline attachments in mail messages are shown as broken images or empty text. This may make communication with clients problematic if they are using inline images to communicate something. You will have to figure out which one of their attachments corresponds to each inline image they reference in their ticket.

Finally, you need to set up CRON jobs for ATS to periodically check for email. This may be a bit frustrating in the sense that it is not only an additional administrative burden for you as a site owner but also confusing for the client who were they to visit your site would not see their new ticket or ticket reply appear immediately but only after the CRON job has run. Running the CRON jobs too often could bog down your server, running the CRON jobs too infrequently would make clients wonder if their ticket / reply didn't make it through and possibly resend it.

Generally speaking, receiving tickets or ticket replies by email messages should be avoided when possible. The user experience visiting your site to submit a new ticket or reply to an existing ticket will be far superior to using email.