rapidsms/rapidsms

Build SMS applications with Python

RapidSMS

RapidSMS is a free and open source framework for building interactive SMS applications, which integrates tightly with Django to provide a rich reporting interface. It was created by the Innovation Team at UNICEF, and is under development by the RapidSMS Team.

Features

• A framework for processing text messages through a series of phases.
• Support for sending and receiving messages from pluggable backends, including Kannel.
• A swappable routing architecture with support for background processing with Celery.
• Built-in commonly used apps in rapidsms.contrib, including registration.

Installation

RapidSMS is best installed via PyPI. To install the latest version, run:

$ pip install rapidsms

Dependencies

• djappsettings
• django-tables2
• django-selectable
• requests

Documentation

Documentation on using RapidSMS is available on Read The Docs.

License

RapidSMS is released under the BSD License. See the LICENSE file for more details.

Contributing

If you think you've found a bug or are interested in contributing to this project, check out RapidSMS on Github. A full contributing guide can be found in the online documentation.

rapidsms's Issues

cleanup internal naming of components, apps?

VM package/distribution

decision tree webui

auto restart/recver

HTTP Post

Takes in a SMS and does and http post

You can pass elements from the SMS
For example,

http://yoururl.com/SMS Sender number/param1/param2

This will allow to forward incoming sms to websites like Ushahidi

GSM modem backend and supporting python modules should be in main project repo

These are commonly need. See Forum Discussion

This commit has the added code at:

• lib/rapidsms/backends/gsm.py
• lib/pygsm

http://github.com/jwishnie/rapidsms-tostan/commit/e903ab6bd8d44abd811bca84a335f02708de12a6

Libraries are bundled as "apps"

Some apps (forms, patterns, (others?)) provide library-like functionality, but don't have an app.py, nor a webui. Therefore, they're not apps. We should come up with a sensible place to put them.

RapidSMS apps don't have dependencies

At the moment, some apps depend on other apps to function (bednets depends upon forms and patterns), which requires users to add them all to the config. This should be managed automatically, so users don't have to be aware of the internal dependencies of apps to use them.

i18n of SMS

We should have a common/shared way of implementing i18n of SMS interactions with the users.

applying labels to issues

What's the requirement for being able to attach labels to issues? It would be great if contributors are able to label issues as they submit them.

installer

Following Users

Add in functionality in the reporting module to allow users to follow other users. This will tie in to alerts.

rss integration?

Email to SMS - SMS to Email

duplicate httptester sections in rapidsms.ini

Wrote a patch for this at http://www.esnips.com/doc/7bb7e5a3-ee8d-4162-bebc-c61e6263a81d/rapidsms.ini

help system

i18n of Webui

We should have a common/shared way of implementing internationalization of the webui

SMPP backend

In thinking that there'll be a need to integrate directly with operators, I created an SMPP backend. How useful would this be if included in the main fork?

project lib/ directory

rapidsms manager should look in the project directory, and if a lib/ directory exists, it should be added to sys.path

Adds wsgi support

This was there but needs to be moved somewhere appropriate

Shared permissions/authentication scheme

Authentication and limited access to the UI has been implemented in three different projects. We should have a shared way or at least a defined standard that we use for this.

Issue Tracking Notification

Add ability to update mailing list / twitter / etc when issue updates occur.

Initial Web UI

Per Tim's suggestion. Create a generic webui framework for the core. Right now you can install the core for the webui dependencies.

Tim's Instructions:

Here's my suggestion:

The main dashboard has different sections and areas content can be rendered into. At the top, there are three columns and below it, two major columns (we might have more than this if needed).

The webui app at the moment handles the display of the dashboard so what could be done is that for each app that needs to display content on the dashboard, that app would implement a template tag probably called dashboard. When the dashboard is requested, webui would iterate through all the apps and look for the dashboard template tag. If it is found, it will be called with the different sections available. If content is returned by the templatetag, it will be rendered in that section.

We should also be looking at standardizing the template for the web interface so that:

1. The template can be modified with a different look and feel
2. Apps do not have much work to do with regards to properly positioning content.

email backend

messaging backend for sending and receiving email messages

document differences django vs rapidSMS

Document both the differences and why they exist between the Django way of doing things and rapidSMS. The intent is to ease expereinced Django developers into RapidSMS and reduce confusion.

installation and setup documentation

Are there any documentation how to setup rapidSMS? what is required beside python and django? are there such information? is so can you please point me to that direction cos all I find is outdated information from sourceforge....

There are sms gateway credentials hard-coded in the source

These a) shouldn't be on github and b) shouldn't be hard-coded.

Installation Instructions

We need one set of install instructions for RapidSMS with pyGSM on Linux.

These instructions should also be included in an install file (or install file should at least include a link to where instructions can be found).

It would be great to document a windows install too but should not be critical for this release.

webui-based triggering scheme

having certain messages trigger actions

scheduling

cron-like event scheduling within rapidsms. handy for things like scheduled message blasts

Adding the lib/contrib folder to the system path

I've made a patch that would include the lib/contrib folder to the system path. I believe this would become necessary when we start having contributed libraries that are used in RapidSMS

http://www.esnips.com/doc/8e5b0057-6884-4bce-91a6-96533c07ea51/contrib.patch

moderatable message queue

kannel backend

automated build and unit test server

we need a build server to run the tests on every commit

pygsm

port rubygsm to python

make a front page to the wiki

Web UI Library

Creation of library or module for core web ui elements.

This would include things like:

• reusable tables
• form elements
• tool tips

message persistence in the router sucks

commit SHA: e281204 introduces a way of persisting outgoing messages across router crashes that is, while inventive, kind of a total hack. I recommend we yank it out before release and contemplate adding something a bit more carefully engineered.

tree unit tests are broken

RapidSMS Avatar

avatar for github rapidsms user

Config should work out of the box

Group messaging app

• direct messaging
• group messaging
• alerts
• following
• sms to email
• email to sms

mapping module?

local settings.py

RapidSMS should look for a settings.py file in the project directory and evaluate it in the context of the generated settings module.

pygsm on windows

web UI is heavy

REST API

spin off apps

spin off apps into their own repositories

The router/backend/app inheritance needs refactoring and/or documenting

At the moment, we have something like:

Component(object)
  Receiver(Component)
    Router(Receiver)
    Backend(Receiver)
  App(Component)

The backends use the inherited Receiver methods as a queue of messages to send, and the router uses them to store messages that have already been received. It's confusing and undocumented.

No generic form builder

RapidSMS version 1 (way back) had a generic form builder. The new one doesn't.