hack4impact-mcgill / move-up-sms-tool Goto Github PK

View Code? Open in Web Editor NEW

1.0 4.0 2.0 1.42 MB

Fall/Winter 2019: a project to help clients sign up for Move Up's services via SMS.

Python 100.00%

move-up-sms-tool's Introduction

Move Up - SMS Tool

This project will allow potential clients to sign up for Move Up's services by texting a dedicated hotline.

Development Team

Project Manager: Albert Kragl

Developers: Alana Ceci, Alex Lam, Jonathan Colaco Carr, Kira Noël, Madonna Huang, Nafiz Islam, Tom Wright, Xin Rui Li, Yasasa Abey

Setup and Installation

To get the backend set up, follow the instructions in the README in the backend folder.

Running the backend requires having some environment variables defined. To do this, create a file called .env at the root of the backend folder, and define variables in the following format:

EXAMPLE_VAR=example_value
SECRET_VAR=supersecretpassword

You will need to define values for FLASK_CONFIG (can be either development, testing or production), TWILIO_AUTH_TOKEN (auth token for your Twilio account) and TWILIO_ACCOUNT_SID (SID for your Twilio account). Once this file is created with proper values, the app will automatically load them into the environment when run. To use these environment variables, you can do the following in your code:

import os

# get the value of the TWILIO_AUTH_TOKEN environment variable
env_var = os.environ.get("TWILIO_AUTH_TOKEN")

move-up-sms-tool's People

Contributors

Stargazers

Watchers

Forkers

cc-21 thomasgudjonwright

move-up-sms-tool's Issues

Create dotenv file to store environment variables

To store environment variables, we'll make use of a .env file. This will store sensitive information like our Twilio Auth Token and Account SID. This file should not be pushed to the repository (the .gitignore in the backend folder already ignores it).

The Flask code has already been configured to read from it, so we just need to create the file itself. See https://simpleit.rocks/python/flask/managing-environment-configuration-variables-in-flask-with-dotenv/.

Remove Database from Backend Flow

Now that the SMS responses get written into Airtable successfully, we can get rid of all database-related things in our code.

Update automatic response when user completes form

Instead of responding with Thank you for completing the form, and we look forward to working with you, Move Up would like the response to be Thank you for completing the form. We will reach out to you shortly with next steps. We look forward to working with you.

Remove trailing whitespaces from all client texts

If a client texts MOVEUP (with spaces at the start/end), we should remove them so that their input is still valid. We can do this for every text a client sends.

Create class in models.py to represent a client SMS response

In backend/models.py, create a class with the fields that a client's SMS response would contain:

Name
Email
Location
Address
The raw response as it was received (i.e. the entire message)

This will allow us to represent a client's SMS response more cleanly, and will make it easier to access the different parts of their response.

Create automatic response when a SMS is received

When a message is sent to our Twilio number, we should send back some kind of response. We can make it a simple message for now and possibly customize it later.

The response should let the client choose between 2 options:

Tell them where they can sign up for Move Up's service (i.e. give them the form link and Move Up's phone number)
Tell the client what information they should reply back with. We'll start with Name, Email, Location, and Age. This response should only be sent if the client sends a specific message to the Twilio number, for example "MOVEUP".

The client could respond with "1" for the first option and "2" for the second.

See https://www.twilio.com/docs/sms/quickstart/python?code-sample=code-reply-to-an-incoming-message-using-twilio-sms-1&code-language=Python&code-sdk-version=6.x

Take a SMS response and store it in Airtable

Note: this task depends on other tasks being completed.

In Airtable, we'll have a designated spreadsheet for storing SMS responses (since these will only contain a client's basic information and will be different than a full application). Once we receive the SMS response from the client, we should take it and store it in Airtable. We will have to use the Airtable API for our specific Airtable base(s).

Different approaches we could use:

Ask the client to separate their information by comma, and then split by comma
Store their entire SMS as a string

Send to different airtable for deployment vs production mode

Update config for this and make sure routes do not use the hard-coded airtable url.

Verify that client answer conforms to question type

See https://github.com/hack4impact-mcgill/move-up-sms-tool/blob/master/backend/app/main/question_views.py#L26

For example, if the question expects a 1 or 0 (i.e. a boolean answer), we need to verify that the user gave a valid response. If they didn't, we should prompt them to answer again.

Allow user to pick their sign-up method

[Related to #3]

After a user texts MOVEUP to our number, they have two options:

Get the link to the sign-up form and Move Up's phone number
Do their sign-up via SMS

The automated response should let them choose which one they would like to do.

Clean up the code

Get rid of old references, nicer comments, make it pretty...

Deploy to Heroku

We can try deploying our app to Heroku to see if things still work as expected when the app is deployed to the cloud.

The Procfile should contain web: gunicorn manage:app. Everything else will require doing things from the Heroku CLI (command line) and managing the Heroku app via their website.

Update TravisCI script to only build the project

Since this project may not have any real test cases, we can simply test if the code compiles and builds as expected. To do this, look into changing the command beside script in .travis.yml.

If we do end up adding tests, then we can update the TravisCI script to run those as well.

Create test endpoint to send SMS message

To do this, we can use our Twilio phone number: +14388003554

Let's try sending a sample text to a sample number when a request is made to a specific URL. For example, localhost:5000/sms-test.

See https://www.twilio.com/docs/sms/quickstart/python#install-python-and-the-twilio-helper-library

Deploy to Azure or GCP

Make README more detailed

Add more information to the README, including:

Basic info about the project
Team members
How to set up/run the project

Add Twilio API to requirements.txt

Add twilio~=6.0.0

Add actual questions to signup form

Update this file: https://github.com/hack4impact-mcgill/move-up-sms-tool/blob/master/backend/signup_form.json

We need to replace the dummy questions with the actual questions that we would like to ask a client that is signing up via SMS.

Improve documentation

Update config.py with proper configurations

We need to update backend/config.py so that each configuration does not have a database URL (we don't need one since we're using Airtable).

Get questions from Airtable instead of hardcoding them in a JSON file

Verify that client has not already completed the SMS form

After a client texts MOVEUP to our number and selects the SMS signup option, we need to check if they've already signed up. If they have, we should let them know and ask if they would like to overwrite their previous response. If they submit an overwritten response, we should note this in some way in Airtable.

See https://github.com/hack4impact-mcgill/move-up-sms-tool/blob/master/backend/app/main/survey_views.py#L9

Add message if client has submitted form in the past

If a client re-submits the SMS form, they will overwrite their previous submission. We should let them know that this is what happens with a message that's different from the standard greeting message.

Fix TravisCI Build

We need to make TravisCI pass so that we can start to implement tests and know when things are actually working. It looks like the reason that TravisCI is failing is because of our DB configuration; since we're using Airtable and not an actual database, we can remove SQLAlchemy as a dependency from the project and update config.py so that we don't define any DB URLs there.

We can also look into defining some configuration variables for the different Airtable URLs, since we will want to use different URLs for testing/dev/production.

This was already done in the CRM tool, take a look at this PR to see what to do: hack4impact-mcgill/move-up-crm-tool#28

Return error message if user gives invalid SMS message

If the user responds with something invalid, we should let them know and keep waiting for a valid response. Possible errors include:

Not texting either 1 or 2 when choosing which sign-up option they would like
Not texting MOVEUP to our number