It is possible to use a cron task to fetch emails, from a specific address, and to use the contents to create or update an issue upon the site automatically.
The component needs to be configured with the details of the mail server from which the emails are to be fetched. Once configured the task will make contact with the email server, and read all of the 'UNSEEN' messages present for the connection user.
Each message is then processed. The first step is to inspect the message to determine whether this is a 'new' issue being reported or an 'update' to an already existing issue. This is achieved by checking the received email to see if there are any 'hidden' header tags which are recognised by Issue Tracker.
![[Note]](/media/com_docimport/admonition/note.png) | Note |
|---|---|
|
All email notifications sent out by Issue Tracker include two specific custom header tags that identify the issue (about which the email is concerned), by its database unique identifier and it issue number. If the sent messages are used to create a reply then these fields can be checked for when a reply is made. Unfortunately a lot of email clients strip out the headers when they reply so that means they are not present for us to check, and hence can not be relied upon. |
If the 'hidden' header tags are not present then the message subject (title) is inspected for a specific issue string. Depending upon the strength of the checking specified in the component options, the specific string would be '[Issue: xxxxxxxxxx ]' or '[ xxxxxxxxxx ]' where xxxxxxxxxx represents the issue number. If neither of these pieces of information are present then the message is assumed to represent a new problem report.
| Note |
|---|---|
|
Consideration was given to implementing checks for other information in the email header for a response, but unfortunately different email clients may add "re" "RE" "Re" "Antwort" "AW" "?p" "?p??t?s?" or some other localised "reply" prefix OR SUFFIX in the message subject. It was considered virtually impossible to keep a track on all of the possibilities and would present a continual coding nightmare. To complicate the problem there is always the situation where people change the subject of the email so one is then into a complex parsing exercise. For this reason no checks are performed to match the Email Subject title other than for the string mentioned above. |
The message is also checked, using the currently implements spam checks. i.e. Are there any 'prohibited' words, the number of included web links etc. Optionally Akismet is also supported for checking of Spam.
| Note |
|---|---|
|
A lot of the commercial ticket/issue/problem reporting systems –e.g. GitHub– work based on a customised email address per problem. Unfortunately this is not an option for a Joomla! component. The other technique commonly used is the thread ID in the mail server which again is not an option. This leaves only with possible hidden email header entries and a reply above line, both of which are implemented in the Issue Tracker feature. |
When the message is determined to be a new 'problem report', some additional checks are made.
The email address of the sender is then analysed. If the email address is not currently known by the system, and we are accepting emails from 'guest' users then optionally a new 'unregistered' user is created in the component.
The message subject is stored as the 'issue summary' for the reported problem.
The contents of the message text are stored in plain (not HTML) format in the description field of the issue.
A confirmation email is sent to the sender and also to the (default) assignee for the issue when the issue has been saved in the database.