Service Request Tracker
NOTE: This repository is archived and is no longer in active use or maintenance by the City of Chicago or Code for America.
This web application is built for the City of Chicago as an interface to service requests submitted through their 311 system. It uses Chicago's Open311 API---including Chicago-specific extensions---to provide listings, lookups and subscription capabilities.
It includes the following components:
- A web application for listing service requests, searching for a specific service request based on ID, and subscribing to email updates for specific service requests
- A python script (in
/updater) that checks the Open311 endpoint for
The latest version is 1.0.2.
Installation & Configuration
To install (you may need to do this as root):
pip install -r requirements.txt cp configuration.py.example configuration.py cd updater ln -s ../configuration.py configuration.py # edit configuration.py as described below
SRTracker is broken into two components: the web app and the updater, which polls an Open311 endpoint and sends notifications about updated service requests. They can be configured together or separately.
By default, SRTracker will look for a file named
configuration.py in its directory. Alternatively, you can specify a path to the config file in the environment variable
SRTRACKER_CONFIGURATION (this is especially useful for services like Heroku). The updater will use this path as well unless you also specify a separate
UPDATER_CONFIGURATION env var.
The configuration file itself should be a python file with the following vars:
DEBUG: True or False for debug mode
SECRET_KEY: A random string used as an encryption key for cookies, etc.
OPEN311_SERVER: URL to the Open311 endpoint you are using
OPEN311_API_KEY: The API Key for the Open311 server
DB_STRING: DB connection string for storing subscriptions
EMAIL_HOST: Hostname for the SMTP server to send updates
EMAIL_PORT: Port for the SMTP server to send updates
EMAIL_USER: Username for the SMTP server to send updates
EMAIL_PASS: Password for the SMTP server to send updates
EMAIL_FROM: Email address updates should be sent from
EMAIL_SSL: True or False for whether to use SSL to send updates
SRTRACKER_URL: URL for SRTracker, e.g. 'http://localhost:5000/'. This is used to generate links in updates.
If you want to do all your configuration via environment vars, point
configuration_environ.py. It'll read in all above vars from your environment. This is great for services like Heroku.
If you are using Apache with mod_wsgi, you'll also want to make sure you configure the app before calling
run() on it in your .wsgi file. The easiest method is to setup your configuration as above and do the following in your .wsgi file:
from app import app as application application.config.from_envvar('SRTRACKER_CONFIGURATION')
Chicago-specific Open311 Extensions
This application relies upon extensions to the Open311 GeoReport v2 Spec that are specific to Chicago (for the time being). These include:
updated_atparameter: allows sorting requests by when they were updated, not just initially requests
notesfield: individual requests may have additional "follow-on" requests that define additional work/activities related to the initial request which are exposed in the
notesfield of an individual service request
Want to reuse this outside Chicago?
Chime in to issue #64 and let us know! https://github.com/codeforamerica/srtracker/issues/64
Several things about the UI for this app are pretty specific to Chicago. We have some bugs filed about making it easy to re-deploy in other cities, so if you’re interested in using this app for an Open311 service outside Chicago, please let us know on issue #64. We’d love to hear what specific features would make this easy for you to re-use and customize.
In the spirit of free software, everyone is encouraged to help improve this project.
Here are some ways you can contribute:
- by using alpha, beta, and prerelease versions
- by reporting bugs
- by suggesting new features
- by translating to a new language
- by writing or editing documentation
- by writing specifications
- by writing code (no patch is too small: fix typos, add comments, clean up inconsistent whitespace)
- by refactoring code
- by closing issues
- by reviewing patches
Submitting an Issue
We use the GitHub issue tracker to track bugs and features. Before submitting a bug report or feature request, check to make sure it hasn't already been submitted. You can indicate support for an existing issue by voting it up. When submitting a bug report, please include a Gist that includes a stack trace and any details that may be necessary to reproduce the bug, including your gem version, Ruby version, and operating system. Ideally, a bug report should include a pull request with failing specs.
Submitting a Pull Request
- Fork the project.
- Create a topic branch.
- Implement your feature or bug fix.
- Commit and push your changes.
- Submit a pull request.
Copyright (c) 2012-2015 Code for America. See LICENSE for details.