Our Issue Tracker component for Joomla has long had the ability (when configured) to handle ‘issues’ sent to a predetermined email address upon a mail server, and to automatically create issues. What is not quite so well known is its ability to handle updates to existing issues via received emails as well.
Certain criteria have to be established to ensure that the ‘update email’ relates to an existing reported issue. There are several steps to this.
a) When an issue creation notification is send out the sent email contains a couple of ‘special’ mail header tags. When an update email is received the presence (or absence) of these mail header tags are checked, and provide one level of confirmation that the ‘email update’ is for an existing issue.
b) The email title is also checked for the existence of a special format string. The format of this string is usually [Issue: xxxxxxxxxx] or just [xxxxxxxxxx], where xxxxxxxxxx is the issue number. It is possible to have different formats for the issue number which may be a ‘random’ ten character string, or a nine digit number preceded by zeros and a leading character (again ten characters in total), or a numeric string consisting of up to 10 digits.
[Release 1.6.8 of Issue Tracker enables a slightly more relaxed format string in that any character string may precede the issue number. The square braces are required in all cases.]
We can assist in the issue number detection by specifying one of the above issue format strings in the outgoing message notification. This is a component configuration and the format of message header and message body contents is possible for all outgoing message types.
c) The email senders address is also checked to see whether it matches the email address of the person who first raised the issue report.
If the criteria is not met then the email update is rejected. If however the email is identified as being an update for an existing issue, then the handling of the email body has to be looked at. A number of email clients (all?) such as Outlook, Thunderbird etc. (to name just a couple) permit ‘reply’ emails to incorporate the received email text in the outgoing message either preceding or following the ‘new’ message text. This is potentially annoying in that if the body text was taken as it is received, the message would contain unrequired information, which is already present in the issue ‘record’. We therefore seek to eliminate the ‘former unrequired included text’ from the message before saving the data in the issue record.
The easiest way to be specify a special ‘text string’ which is searched for in the message body and any text seen after this ‘string’ is silently ignored. This works well in practise but only if the ‘string’ is present in the message. If it is not present one is left with a decision as to whether to accept the whole message, ‘included former messages text’ or just reject the message entirely. This is obviously a decision that a configuration option permits a site to make.
It is not possible to know whether the client browser, is going to include the ‘former message text’ either before or after the ‘new’ message content,and there is no standard way for a client to indicate the present of this ‘former’ text in the message. Fortunately the most common default is for the ‘former message’ to be included after the ‘new message text’. In this situation we can try and eliminate most of this text automatically. To do this we need to ensure that the outgoing message contains our ‘'special reply text string”. We can accomplish this by the use of a ‘hidden’ HTML tag at the start of the outgoing message as follows:
[The ‘#-#-‘ string (and its derived inverse) is a component setting and can be any desired unique string that is unlikely to be provided by the user in the usual course of business.]
We add this to the email template body and it has the advantage that it will not be displayed in the message due to the span style which hides the text. If the user replies and includes the received message contents in their reply it would be picked up by the message body checking code and can then be eliminated from the message stored in the component issue.
This will not of course eliminate all unnecessary text from the ‘email update message’ but it can go a long way towards reducing it.