MeteorJS Developer to develop a web application!

Description

We require a MeteorJS developer to develop a web application to assist an operator to send SMS notifications. The SMS notifications will be sent to customers who have made pre-booked reservations for a limousine service. The application will display a list of upcoming reservations, and allow the operator to select an individual reservation, and then compose a message and send the message to the customer, either immediately or scheduled. Message templates will be used to assist with the message composition. The SMS messages will be sent via an email-to-SMS gateway, so the application will only need to interact with an email server (presumably an SMTP server) in order to send the SMS messages. The reservations data is obtained from the reservations system via a SOAP/XML API. The application is for internal use only, and rapid development is more important than usability & aesthetics.

Detail

The application will need to perform the following:

Query a reservation system, via a SOAP/XML API, to extract reservation data.

Display the reservations in a list in chronological order. If the State & Country fields do not match a predefined "local" pair of values, the time zone should be inferred from the State & Country, as there is no explicit time zone field in the reservation data. The inferred time zone will be used to convert the date/time of the reservation into the local time zone, allowing the remote reservations to be displayed in the correct order and with the booking time displayed in local time

Only future reservations from current to the next 12 hours should be displayed

The reservations query should run automatically at a user defined frequency. (e.g every 5 minutes, or every 10 minutes etc). Additionally, the user must be able to manually trigger an immediate query.
Allow the user to select a reservation, and then compose a message that is based on a user chosen template, with template tags being replaced with reservation fields. There will not always be a direct 1:1 mapping between the tags and the fields - currently there is one tag that will require more than one field to be combined, and another tag for which a choice will need to be made between a) a single field, or b) if that single field is empty, combine the data from a set of other fields instead.

The message will be displayed to the user, and be able to be edited. The phone number that has been extracted from the reservation will also be displayed, and will also be able to be edited.

The message will then be emailed to an SMS gateway, either immediately, or scheduled, as selected by the user. The email address will be formed by using the phone number as the user/account name, to which the SMS gateway email domain is appended.

The system will allow message templates to be created, and edited, and deleted.

The message template tag definitions may be hard coded. There are 7 different tags.

The SMS status of the reservations needs to be shown - there will be four statuses: Unsent, Scheduled, Sent, and Not Required.

The status will be automatically changed to Scheduled immediately after the user invokes the message scheduling function.

The status will be automatically changed to Sent immediately after the user invokes the message sending function. Additionally, a SOAP message will also be sent to the reservation system, which will update the status of the reservation.

When a Scheduled message is actually sent, the same SOAP message will be sent to update the reservation status in the reservations system.

The schedule times needs to be viewable, but only one reservation at a time will suffice.

For a message in the Scheduled status, the user will be able to override the scheduled time, and immediately trigger a sending of the message, or change the scheduled time, or cancel the schedule altogether. When the scheduled time is cancelled, the status should be set to Unsent.

When the reservations query is executed, any reservations which are no longer present in the returned data from the API, but are in the local data store, should be removed from the display & local data store, and any scheduled messages removed from the scheduling queue.

The application should be secured with a single, password protected login account.

The application is not required to persist the scheduled reservations list, but may do so if preferred.

Work done to date
The node-soap package has been tested with the SOAP API, and appears to be compatible - it consumes the WSDL and also allows queries to be performed. There is a Meteor wrapper (meteor-soap) for this package.

Deliverables
The MeteorJS application & source code.
Brief written instructions for installing and using the application, focusing on aspects which are not self evident from the above specification.

Non-deliverables
No installing and configuration on a hosting provider is required.