Deprecated: Joomla\Input\Input implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /homepages/13/d380392445/htdocs/Jlive/libraries/vendor/joomla/input/src/Input.php on line 41

Deprecated: Return type of Joomla\Input\Input::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /homepages/13/d380392445/htdocs/Jlive/libraries/vendor/joomla/input/src/Input.php on line 170

Deprecated: Joomla\CMS\Input\Input implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /homepages/13/d380392445/htdocs/Jlive/libraries/src/Input/Input.php on line 31

Deprecated: Joomla\CMS\Input\Cookie implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /homepages/13/d380392445/htdocs/Jlive/libraries/src/Input/Cookie.php on line 21

Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/13/d380392445/htdocs/Jlive/libraries/src/Uri/Uri.php on line 141
Email - Macrotone Blogs

Macrotone Blogs

Macrotone blogs upon Joomla, our products and other matters.
Categories
Tags
Archives
Calendar
Categories:   All Categories
Suggested keywords
x

Email

Subscribe to this list via RSS
Geoffrey Chapman

Issue Tracker: Handling received emailed issue updates

issues-48Our 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:

#-#- Text following text is ignored –#-#

 [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. 

Tags:
Issue Tracker Email updates joomla
Geoffrey Chapman

Test email in foreign languages

We have been working with the emailing of problem reports to our Issue Tracker component recently in particular with the specific problem of languages using ISO-8859-2 character sets.

Having made some code changes to handle this, we were thinking of how it might be possible to test out other languages, with other character sets such as Chinese, Korean etc.

The little grey cells starting thinking about the various translation sites upon the web, and whether there might be any that could not only perform a translation of some specific text but also complete the task by emailing the translation to a specific address.

After some searching it seems that this is not an unusual requirement and we found several that could possibly do what we required. A lot only handled the translation part of the requirement, but the sending of the email was not that common. It was important that the email was sent from the third party since if we used a local email client the details in the message header and body did not accurately reflect the correct character set in use, and this was the one thing we wanted to test.

A number of sites imposed limitations such as the number of characters in the message, the number of messages that could be sent etc., which is generally reasonable since they are endeavouring to make a living from providing a service and would prefer to charge.  However these limitations were not of a major concern to us, especially as the text content could be anything at all, as long as the character sets were represented.

We obviously will not list all of the sites we investigated but the one which we found suitable for our needs was WorldLingo and though it insisted in creating accounts for both our sender and receiver of the generated emails, this was something we could easily live with. There is a vast range of possible languages to choose from, certainly more than we will ever use or test I suspect, and the machine translations were more than adequate for our purposes.

Our requirements were not all that unusual at all, and I suspect others might have the same sort of need, in which case hopefully this may act as a pointer.

Update: One interesting side effect we noticed was that, when we sent the email (via WorldLingo) it was 'processed' by our component and automatically send a reply acknowleging receipt. Since the emails from WorldLingo are all sent out with individual identifers in the email address the reply was sent to the named worldlingo address which then forwarded it to use (the sender). The interesting aspect was that the text was 'translated' on the reply and didn't quite match what was the 'original' text in English. One of the interesting aspects of translating in this case from English->Japanese->English. Not a concern to use but just goes to show how things can get confusing in translation.

Tags:
Issue Tracker joomla Language Email Electronic
Geoffrey Chapman

Mail ISO-8859-2 character sets

We recently received a report that the email fetching feature within our Joomla Issue Tracker component wasn’t handling the subject header and email body correctly for the ISO-8859-2 character set. This character set is used by a number of Eastern European countries, so we were interested in resolving the problem if we possibly could.

We tend to use the standard PHP imap routines and it was immediately obvious how we should handle the subject, but implementing a call to the imap_mime_header_decode method. This worked well and was a very quick fix.

Continue reading
Tags:
Email Issue Tracker joomla PHP
Geoffrey Chapman

Design Criteria for processing emailed issues

We have been busy with a forthcoming feature for our Issue Tracker, which is the ability to receive emails with details of new issues or emails containing updates to previously raised issues.

After much thought and consideration the following design criteria are  deemed necessary in the email issues functionality. They are included in no specific order of
priority.

Continue reading
Tags:
components joomla Issue Tracker Email
Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries