In addition to the usual website development and maintenance this project really allowed us to get our hand on developing a state of the art application for Outlook.
This Outlook plug-in project consisted of the following specification detailing the new features for the Boommail v1 Outlook Plug In which was to be developed for Brent Council. The Outlook plug-in was based on an existing TMC Plug-in that was built by our digital agency.
The MSI based nature of the Outlook plug-in meant that it could be possible to distribute the plug-in using Microsoft SCCM or a similar network deployment utility.
Where applicable the new functionality was to be part of both the existing plug-in and a new boommail plug-in so that existing TMC customers can make use of the new features. This gave us a fully scalable solution for customers that require both Boommail and the advanced Boommail Active Directory (AD) Option.
C++ is the one of the leading technologies within the programming industry and is typically used for systems software, device drivers, embedded software, high-performance server and client applications, and entertainment software such as video games.
Building the software in this way allowed us to programmatically control Microsoft Outlook and the way in behaved with Boomerang giving access to array of potential features
Boommail Plug-in features
To cater for the planned conversion of the TMC plug-in to meet Brent Councils requirements the following works were carried out:
New API preparation
Currently the TMC plug-in links to a TMC API. As part of the below works it was to be converted to access the Boommail API for all data transfer and services.
Introduction of company License file model
At the moment the TMC Plug-in required users to individually enter their login details to the plug-in interface. To allow for easy deployment of the Plug-in a company-wide universal license was to be deployed with the plug-in to identify the company with which to associate that user.
The license file contained an encrypted key that would be passed to the Boommail API in order to authenticate the company.
Users were then uniquely identified by using their default outlook email address (Please note that this had to be unique throughout the company unless unique identification of the sender was not required). The Sender name registered in MS Outlook would also be provided so to store with the user record for ease of administration. Both these details were to be automatically extracted from the default outlook account by Boommail.
If this is the first time a user had accessed the Boommail system and no record exists for that users email address then by default Boommail automatically created a record with default permissions set.
It was possible to filter and block users as described in the Boommail Control panel section below.
If the company license is not present then the plug-in was to ask the user to register their userID and password as is currently the case with the TMC plug-in.
If the license is invalid or the user is blocked then the API was to return a suitable message which displayed to the user.
Optional linking with Active Directory
There is an option (set in the control panel) that controled whether the Plug-in was to use the Outlook address book or the Active Directory list from the domain controller of the network (where a domain controller is accessible).
If Active Directory option is selected then all clients looked to the active directory for the list of contacts to be displayed and the phone numbers that correspond to that list.
In addition when in the Active Directory mode there is an option to define permissions for certain Active Directory Groups. In particular certain groups were able to send SMS messages by manually entering a number (as defined below in “Restrict users to…address book”) while it was possible for the default to be that other groups cannot. This was to be flexible so that other customers can configure a reverse or other set of permissions as they require.
“I want a reply” option
At the moment the TMC Outlook add-in supports inbound message replied via a virtual number that is assigned per message. This option was to be hidden and in its place was to be an “I want a reply” option which was instruct the plug-in to call the Boomerang API method that returns any user response to the operator along with a unique identifier that can be used to pair up the outbound and inbound message.
Unique Reference API
In order to ensure that each message has a unique reference Boommail was supply an API that returns a universally unique identifier for that message. This can then be used with the API call to pass a unique identifier for the Boomerang message.
Recipient identifier parameter
To meet the Brent Council itemised billing requirements in full the plug-in was send each SMS message individually to each recipient (and not batch send as it does now) and pass a parameter identifying whether that recipient is in the address book or not. If the user freely enters a number from the address book it was to be assumed that they have selected a value from the address book.
Restrict users to only send from address book
Based on a boomerang control panel permission set against each user it was then possible to define whether that user can send messages to manual numbers (i.e. whether they were to be forced to use the address book or not).
Please note we were not preventing the user from adding contacts to the outlook address book and it was assumed this can be controlled within Outlooks own permission model if desired.