This was raised as a possible enhancement in the Forum and is being developed. (the initial release is for 1.6.5) The following is an outline of the implemented and the possible drawbacks.
There are a large number of different SMS providers available around the world and it would not be worthwhile providing an interface to them all especially in a 'free' product such as Issue Tracker. Instead a better approach is to implement an interface to an existing Joomla SMS component using an API and thus pass the message along to the SMS component to forward to the relevant SMS provider.
We did not have any experience with any of the current Joomla SMS components but from reading around it was suggested that the preferred component might well be AcySMS. As of October 2014 Acyba (component authors) did not provide an API but they did have a simple PHP file which it was suggested might be used.
It has to be remembered that using any SMS mechanism will involve some extra element of cost as the SMS providers will expect payment for delivery of the message to the recipient. This varies depending upon the SMS provider used, but as of October 2014, Clickatell (one of the global providers) charge about 2.7p per message. There are also costs in our developing the interface to ensure that it would work, and also probably involve purchasing the AcySMS component from Acyba for our development work. It is not expected that we would at any time in the near future have any requirement to use an SMS interface for our own purposes, so such a development would be solely as a result of some form of donation, to cover our expected costs.
The following changes are required.
-
Change the Joomla user interface such that the additional profile option to force(?) the user to supply a suitable telephone number that would be used for the sending of any message. This could be achieved by using the User Profile plugin (Joomla standard) but it doesn't really validate the phone number provided.
In the first implementation this will not be provided. Instead it will be necessary for the system admin to manually add the required phone detaiils for the users in the IT People table. This will ensure that the correct number (and format) is provided. The expected format is that expected by AcySMS which includes a leading '+' and teh country code, followed by the actual users phone number.
We would look to implement some form of checking o number submission at some time in the future.
-
Modify the system plugin such that the information is also synchronised with the it_people table.
See above item for more information. This will not be available in the 1.6.5 version.
-
Modify the it_people table to accept the phone details, and also a new field such as to control whether the SMS interface is to be invoked for this specific user.
A new phone number field is provided in the IT People table along with a flag to indicate SMS messages are acceptable. This is implemented in release 1.6.5.
-
Modify the front end issue creation such that the raiser is provided with the ability to specify a telephone number. Where the person raising the issue is a guest (public) user then we need to capture the telephone number. This is either saved with the user details in the it_people table for an unregistered user or it is stored in the progress field for the issue if unregistered users are not enabled in the component.
Not implemented in release 1.6.5. There is a question as to whether this is a desirable feature or not? The question is whether we can trust the guest user supplied phone number without requiring the guest user to validate the number.
-
New component option to specify whether SMS integration is required.
The email component configuration has been changed to be 'messages', which will cover both Email and SMS. Each of the various options instead of having a Yes/No option has been modified to have No/Email/SMS/Both options.
An extra field to select the SMS sender provide has been added, which will be empty if AcySMS is not installed, along with a parameter to specify the maximum length of an SMS message. Any generated message with a length exceeding this value is truncated. Most (all?) SMS providers set some limit upon the length of an SMS message. A default of 160 characters is defined.
-
Modify the method involved with the sending of email notification such that SMS are sent instead of or as well as the email notification.
The message sending method has been modified to accept the four possible messaging options (described above).
-
Three new 'message' templates have been provided for SMS usage: sms_create, sms_update and sms_close. These are required due to the 'restricted' size of a SMS message, which means that the supplied email templates are not suitable. There is no distinction between user, assignee, or admin usage, as the message is likely to be terse.
-
Implement the Acyba code to invoke the interface to the AcySMS component.
A new method as been written to act as the interface between Issue Tracker and AcySMS.
-
A mechanism for testing is required. AcySMS provide a 'test' interface, which effectively does nothing, but it does have a randomly generated failure mechanism. This enables the testing of, the display of errors that may be generated from the SMS provider. All of our development and testing has made use of the 'test' interface, with only the final test prior to the release being upon a 'real' interface.
The interface checks for various settings and displays messages in the component log to assist administrators in determining where problem may be encountered.
-
Do we require any interaction with the AcySMS component to ensure that the message is send successfully(?) or do we just have to assume that it went successfully?
Depending upon the SMS provider used, there may or may not be a delivery report available from the SMS provider which would be visible in the AcySMS back end. Our testing using Clickatell certainly was visible,although there was some initial confusion as to how this was configured within Clickatell.
The link to the Acyba Developer documentation is as follows: https://www.acyba.com/acysms/387-acysms-developer-documentation.html
It consists (as of October 2014) only of the following piece of information which is reproduced below for convenience.
if ( !include_once ( rtrim(JPATH_ADMINISTRATOR,DS) .DS. 'components' .DS. 'com_acysms' .DS. 'helpers' .DS. 'helper.php' ) ) {
echo 'This code can not work without the AcySMS Component';
return false;
}
$messageClass = ACYSMS::get('class.message');
$senderProfileClass = ACYSMS::get('class.senderprofile');
$message = $messageClass->get($message_id);
if(empty($message->message_senderprofile_id)){
echo 'No sender profile found with this ID';
return ;
}
$gateway = $senderProfileClass->getGateway($message->message_senderprofile_id);
if(!$gateway->open()){
return;
}
$phoneHelper = ACYSMS::get('helper.phone');
$phone = $phoneHelper->getValidNum($receiver->receiver_phone);
if(!$phone){
echo 'Invalid phone number';
return;
}
$status = $gateway->send($message->message_body,$phone);
$gateway->close();
The above code was used as the basis of the interface with a few extra checks implemented along the way.
One thing to note is that within AcySMS it generally is not shown when messages are dispatched, apart from when the SMS provider provides a delivery report. Not all SMS providers do, so there is no easy way to determine whether a message has been dispatched with out such a report.
Possible enhancements include:
-
Make use of 'canned' messages held within AcySMS and just pass substitution fields (tags) to be placed in the AcySMS messages. This is not something that is in the initial 1.6.5 release. No work has been performed to determine how easy or difficult this may be to implement.
-
Accept entry of phone number on Issue creation for guest users, so that they may recieve SMS messages. Requires handling both situations where a user is created as an un-registered user and where the user's details are stored in a progress record. See above comments for whether this is desirable or not.
-
Add improved checks on entered phone fields in the users form entry. In the 1.6.5 implementation this is not very sophisticated.