Add authentication around the web portal so only registered users can access it.

As a registered user, it would be nice to be able to see a history of alerts and follow ups sent out (including who they were sent to)

The app currently uses 3.0.2, which came out in Aug 17 2015, can we upgrade to 3.2?

It'd be nice to have a view for logged in administrators to be able to see what phone numbers have interacted with the system and what state they are in (subscribed, unsubscribed, etc)

Problem

Currently, the database is stored with the instance. If anything happens to it, well, not good.

Solution

Rather than using an RDS solution, DynamoDB provides a free tier for which we will not reach the limits of. Unlike other free tiers, this does not expire after the introductory 12 months.

Notes

This should be part of the cloud formation template when this is done. For the moment, because feature parity is trying to be reached, the CF template will initially not have this.

Problem

The play.filters.hosts.allowed does not permit requests arriving from outside the local host. This causes all requests hitting port 9000 to fail.

Solution

Permit outside hosts to hit port 9000.

We've gotten issues where something is or is not working for a person. Folks part of the tech team should be able to log in and see what the status of a given phone number is.

It would be good to have an integration test framework around our TwiML route.

Currently the system only supports / assumes English for all languages. Build in locale support to match what we currently have in the Django version.

This will require updating the message processor to understand multiple responses to the join / change language / unsubscribe messages for the various languages, and then updating the alert / follow up forms to adjust local based on the subscriber stored location.

Problem

There is code in FollowupController that sets the personWord to either person or people based on the number of people detained. This needs to be language specific.

Solution

SubscriberActions probably needs to be renamed to something that has to do with language. Additionally, all of the words should be kept in the messages.* files.

Currently the system is wired to an in memory database. We need to create a production configuration that instead points this at an RDS database (schema should be the same as the existing Django version so they can be re-used)

Let's start this out right and get a dedicated Beta environment set up in an AWS account with automated build and release process.

This could be done by retrieving the canonical form of the address from geocoding, and responding asking if it's correct. It's also possible that if geocoding returns multiple possible addresses, we could ask the reporter to respond with the number corresponding to the correct address.

Problem

It would be cool to have the date that a person completed registration so we can perform analytics.

Solution

Add date to database

Problem

Zipcode is a desired field to keep in the DB for data analytics.

Discussion

Can this be pulled from the text message itself and simply ask the user to confirm? Otherwise we can ask the question in the flow itself. It may be kind of creepy to ask to confirm.

Twilio for long phone numbers currently throttles at about 1 message / second. We should swap out the message sending for SNS instead similar to the Django implementation.

Problem

Travis build is failing, but service is working fine....

This allows us to actually get coordinates for an address, cross-street, etc., and also to be able to correct some typos.

This would create the RDS database, ELB, and spin up the EC2 instances or any other related resources needed to run the service.

Currently message encoding does not appear to be working correctly for outbound messages.

Steps to reproduce:

• Sign up with a new phone number (text "join")
• Wait for response

This produces a message with ????s instead of the expected characters. It seems like our response isn't being treated as UTF-8 encoded.

Problem

The DB uses ISO-639 part 2, which is a 3 letter language code while the language files are 2 letters. This requires us to keep a mapping in the code, which is not optimal.

Solution

It may be as easy as changing the files to use the 3 letter extension and getting rid of the mapping logic. I'm not sure....

Users should be able to sign up for notifications via calling the Twilio number in addition to texting it.

So, texting JoIn with a bunch of spaces on either side should work just as well as texting join.

Problem

Sometimes, the given templates are not applicable to the alert that we want to send out.

Solution

Create a free form message for each language that the user can specify the notification to go out.

We can, if we want, try to limit geocoding results to Washington, and also don't include extra information (like "WA" or "USA" or the zip code even) in the fully formatted addresses produced by geocoding.

From the Code Bash:

It'd be great to be able to generate a Google maps link when reporting events so subscribers can accurately pinpoint the location

Users should be able to receive notifications via a phone call in addition to SMS.

Currently, reporters have to go to the web portal in order to notify subscribers. We should also support reporting via SMS for users whose numbers have been whitelisted.