If there's somthing strange in your Django app, who you gonna call? The django-on-call app helps your users figure that out, pointing them to one of your on-call sysadmins. The admins can work out an on-call schedule among themselves, by posting a Python statement to the database (we're all consenting adults), and the view page will direct users to the appropriate on-call individual.

Quick-start

If you don't have a Django project and you just want to run django-on-call as a stand-alone service, you can use the example project. Initialize the database with:

$ python example/manage.py syncdb

See the Django documentation for more details.

Run

Run the app on your local host with:

$ python example/manage.py runserver

You may need to add the current directory to PYTHONPATH so python can find the django_on_call package. If you're running POSIX shell, that's:

$ PYTHONPATH=".:$PYTHONPATH" python example/manage.py runserver

Manage

You might have several on call positions (sysadmins, webmasters, developers, …), and you can have a separate OnCall instance for each position. You should use the admin interface to create the instances, after which your users can access them. If you're using the example project and you created an OnCall instance with sysadmin as the slug, they'll use http://localhost:8000/on-call/sysadmin/.

A list of all positions is given by the ListView bound to http://localhost:8000/on-call/. If your OnCall instances are returning something short and sweet (e.g. “John Doe (+1 234 567 8901)”), this list view may be all you need.

If you only want a few static OnCall instances, you can consider managing them with fixtures instead of using the admin interface.