I've tested rapidsms with django 1.4.+ (including the development version), I think django deprecates the use of:

{% url hyphenated-arguments-example %}

When you use a hyphenated argument within a quote (single quote, for example), no error is thrown:

<a href="{% url 'rapidsms-login' %}">Log in again</a>

or:

<a href='{% url "rapidsms-login" %}'>Log in again</a>

I hope this fixes things for folks working with Edge-django.

This is a pull request to track the feature/router-setting branch. This branch attempts to separate the app phase processing and legacy threading code into a BaseRouter and LegacyRouter, respectively, and introduces a RAPIDSMS_ROUTER setting, which lets you swap routers in your settings file.

Please note: Everything in legacy.py is just a copy/paste from the old rapidSMS and will likely be deprecated or removed altogether as part of this branch, so I've made no attempt to clean up any of the existing code there.

This is especially useful for folks that directly add their rapidsms(contrib) apps to their projects without installing these apps (either in site-packages or other). Docs are a critical part especially during offline dev work; hope this makes sense.

Mostly minor fixes to provide Python 3 support. This is built on top of #453.

Will probably also need doc updates, but wanted to get this out there for review in the meantime.

See discussion here: http://groups.google.com/group/rapidsms/browse_thread/thread/cfea7e3c3e58a7ed/6adc6150019f1ba3?lnk=gst&q=datetime#6adc6150019f1ba3

contrib.handlers provides several ways to include/exclude handlers via the INSTALLED_APPS, RAPIDSMS_HANDLERS_EXCLUDE_APPS, INSTALLED_HANDLERS, EXCLUDED_HANDLERS. The various combinations of these is somewhat confusing and is somewhat overly complicated for most installs.

Some ideas:

• Use INSTALLED_APPS by default, unless INSTALLED_HANDLERS is defined. If so, then use INSTALLED_HANDLERS as the primary reference, as it will contain an explicit list of handlers. Remove all other settings.
• Adopt a registry similar to django.contrib.admin and use a similar admin.unregister workflow for removing unwanted handlers.
• Only use INSTALLED_HANDLERS. Simple and explicit, but may be tedious to maintain a large list.

This PR provides support for the master branch of Django (which will become 1.8 once released). I've combined a few different fixes in with this because they were generally reliant on each other.

Backwards incompatibility: This drops support for Django 1.4 and 1.5. This makes it possible to use transaction.atomic, allow using the url templatetag without importing it from future, and allows us to use the latest version of Celery.

Needed after this PR is merged: Documentation updates, especially for the switch from django-celery to plain old Celery. (Added to my todo list)

This PR is done on top of #452 and I'll update it once that one is approved.

I've created a simple DB backend. Is it worth moving httptester over to it for 0.13?

https://github.com/rapidsms/rapidsms/tree/feature/bulk-messaging-api/rapidsms/backends/db

An alternative to the Keyword parser, the BestMatch parser takes a set of target strings, and matches a Source string to the targets. The match does not have to be exact, the matcher returns all targets that contain the src, or start with the source (default behavior)

This can be used to perform a best-unique-match (similar to what 'gem' command uses to let you shorten subcommands).

Basic usage:

bm=BestMatch(['foo', 'bar', 'baz']) hit = bm.match('f') if len(hit)==1: print 'we found: %s' % hit[0] elif len(hit)>1: print 'which did you mean? we found: %s' % hit

The matcher has a bunch of advanced features including:

• aliases where each target can have multiple aliases (spellings)
• storing of arbitrary data with the targets to make command handling simple e.g.

bm = BestMatch([('doFoo', self.do_foo)]) hit = bm.match(src_string) if len(hit)==1: hit[0][1]()

• ignore prefixes--prefixes that can be left out of the match e.g. bm = BestMatch(['mr. smith', 'mr. jones'], ignore_prefixes='mr.') hit = bm.match('smith') hit will be => ['mr. smith']

For examples of usage, see: http://github.com/jwishnie/rapidsms-tostan/blob/41242c7b54d954e16ce7dcf46a0f351bdaa1e8e8/apps/smsforum/app.py

When using Database Router as rapidsms router, at the backend_preparation, link the database message object with the Outgoing message, making possible to retrieve the message saved using the message object.

Now when you use:

from rapidsms import router
...
outgoing_message = router.send('Testing message', connections)
# Now you can get the database messages and transmissions
print outgoing_message.database_message.status
outgoing_message.database_message.transmissions.all()

This is building up on your django-19 branch @vkurup. I removed all the deprecation warnings, apart from the one thrown in django-selectable. I'm working on fixing that deprecation warning in the django-selectable repository. Also dropped support for Django 1.7 and Python 3.3, added support for Python 3.5.

In summary:

• Added support for Python 3.5, Django 1.9
• Removed support for Python 3.3, Django 1.6, Django 1.7
• Fixed the build by pinning the django-tables2 version to 1.0.*

This rapidsms doesnot have alot of novice-user tutorial documentation and all. Anyways, I am trying to set up a practical rapidsms SMS application to communicate over the Kannel gateway in Ubuntu -- I intend to use my smartphone as a GSM modem and another phone to send and recieve messages. I have created a rapidsms app and all the code in settings.py file looks like the tutorial 1: http://rapidsms.readthedocs.io/en/develop/tutorial/tutorial01.html#tutorial01 In other words, my application can ping and pong from the messageTester.

Using the following tutorial: http://rapidsms.readthedocs.io/en/develop/topics/backends/kannel.html When i try to run this command from the terminal( its some form of fakesms test): /usr/lib/kannel/test/fakesmsc -m 1 "123 789 text ping-kannel" i dont get the results!?!

Any help how to solve this issue?

Someone asked me the difference between RapidPro and RapidSMS today, and I'm not 100% sure I gave them the right answer.

There's no wikipedia page for RapidPro, and no mention of it on the RapidSMS page:

https://en.wikipedia.org/wiki/RapidSMS

I'm assuming RapidSMS is no longer under development, and that new projects should be built on RapidPro rather than SMS. Could someone update the README to reflect what RadidPro is and when to still use RapidSMS?

Thanks.

There is an import error in rapidsms 0.21.1, looks like rapidsms is using a obsolete module which has been remove in django 1.9, actually since django 1.7. The module is importlib found in django from django.utils.importlib import import_module. This was a compatibility library for python 2.6 when still supported and thus it has been obsolete since 2.7 It appears that this module has been removed also in django since django Django 1.7. In django 1.9 thus when you try to import from rapidsms.apps.base import AppBase you get this kind of error

ImportError                               Traceback (most recent call last)
<ipython-input-1-b7d874691b1f> in <module>()
----> 1 from rapidsms.apps.base import AppBase

/usr/local/lib/python2.7/dist-packages/rapidsms/apps/base.py in <module>()
      4 from django.utils.encoding import python_2_unicode_compatible
      5 
----> 6 from ..utils.modules import try_import, get_class
      7 
      8 

/usr/local/lib/python2.7/dist-packages/rapidsms/utils/modules.py in <module>()
      5 import inspect
      6 
----> 7 from django.utils.importlib import import_module
      8 
      9 

ImportError: No module named importlib

This behavior in happening in debian 8, python 2.7.9

As mentioned multiple times on the mailing list, it's time for the next release to have some backwards-incompatible changes, in order to properly modernize RapidSMS.

Here are the things that I think need to be done before we release 1.0.

• [x] Document Django compatibility plan (Drop support for Django < 1.7, plan to support 1.8 with no deprecation warnings, with each subsequent point release supporting the next version of Django)
• [x] Drop Python 2.6 support
• [ ] Update our use of Celery (See #456)
• [ ] Remove extensible data models
• [x] Remove contrib.locations (a move which was supposed to happen a long time ago)
• [ ] Update documentation
• [ ] Review outstanding issues / PRs (They may not necessarily be addressed in this release)

Some of this has been started in #469, which I will merge soon to begin this process. Completing the above will leave RapidSMS in a more sustainable place for further improvements.

Comments, questions?

HI,

I have start exploring the rapidsms for one of my project and I completed the tutorials successfully but when I tried to run the poll application than didn't find any appropriate documentation for the supported version of dependency projects so poll application didn't work for me at all.

I have tried almost all the fork versions of poll app but none of them work. I am not sure if the issue is with the django version or something else.

I will be really thankful if someone could even give me right direction to try the correct code of poll. Thanks in advance