Issues

FrontEnd

• #108
• Display message if us verification fails
• If verification passes, populate representatives from Google Civic API

Backend

• Format address into US verification object
• Return boolean after check with Lob
  

Architecture

• ORM set up
• Post and get functions

QA

• Deliverability tests

Working together

This function verifies the user's address in order to show their representative list

If the address is invalidated, the user will be prompted to enter another address

Receiving this error when trying to access any of API links in the front-end.

Takeaways from the BackEnd discussion on #6 : Moving forward with a Heroku Postgres structure

• Airtable has been set and tables to migrate to Postgres

Data Structure Read more here

• Two types of users: orgs and volunteers (volunteers will come mpv+)
  • Orgs (Starter (only letters), Accelerator (analytics), Grant (completely subsidized)
  • Volunteers (which orgs are they referred from?)

BackEnd functions:

• Create data tables
• Establish APIs for: Twilio, Auth0, Lob
• Passwordless authentication
• Store new users

Testing

• Error codes from APIs
• Login errors
• Database?

Working on:

• 1. Set up Heroku Postgres & Populate @BeeXiong
• 2. Routing API Endpoints @BeeXiong
• 3. User Login (@manishapriya94
• 4. Tests @teakopp

Creating a new issue to update the Amplify Endpoint.

Per our conversation in the Send Letter Issue, updating api/amplify/{zipcode} to reflect api/representatives/{zipcode}

• Modify app.js file for routing
• Change name of Amplify Endpoint to Representatives
• Update Wiki information to reflect Representatives
• Update Front-End URL for --> @mahrsbar

• structure: creating a component (from backend data) that the b-card calls on
  • backend data
  • call on airtable data and initialize, each field is a variable name. Example:

While onboarding to join this project, it took a several minutes (sadly 😅) to realize that the project wasn't actually missing its package.json file, it was just unexpectedly down 1 level deeper (inside of server/).

My take on the project setup here is that the server directory was probably a direct copy from another location (e.g. a previous repository), so it ended up looking a bit like a monorepo setup (sub-repositories inside of a repository).

My understanding from @manishapriya94 and @BeeXiong is that this repository will continue to be a single repository dedicated to the backend server, so I feel that we should flatten the hierarchy at least for the meta files to achieve a more standard Node.js project layout and avoid confusion for onboarding additional folks in the future. 😊

Use Case

User authenticates through email in order to send campaign later (limit spam). Store their information into a database on airtable to be indexed for each campaign letter

Background info

• passport-google-oauth

Implementation

• vue + express + node set up @BeeXiong
• creating crm in airtable @manishapriya94
• setting up airtable as a database
• passport authentication

Purpose:

Part of User Login Outline
Implementing rules with Auth0 allows the user to maneuver amplify and browse many campaigns before having to login when they've chosen a letter to send.

When the user clicks 'send letter':

• A trigger kicks off that checks if the user has been previously authenticated (Via passwordless SMS).
  • If the user hasn't, they'll be sent to an Auth0 landing page
  • Previously authenticated users can continue to send the letter.

After a successful authentication, the user will be added to our database of User Volunteer where any future letters sent will be added.

We will need to modify the following:

• require authentication for app.post
• route to Auth0 page for SMS passwordless

Requiring Authentication

To implement the logic, we reference the below to require Auth0 for specific routes

• Change to app.post
• How do we do this without the frontend button?

Route to Auth0

• res.redirect to auth0 url:
• How do we do this without the page being built?

Route to Lob API

If the user is already logged in (use cookie), send the lob api call

Purpose: Users are able to donate to the cost of letter and any additional amount to the advocacy nonprofit directly. Users donating a certain amount over $30 will get a campaign sticker. Full details ProgramEquity/product#3

User Story:

1. User has authenticated and went through all steps leading up to payment of letter
2. Pick an amount to donate
3. Checkout and fill payment information
4. Successful payment accepted highlights send message button
5. send button pressed, results in confirmation, congratulated if sticker unlocked as well

@nawazkhan could you fill in subtasks for backend each sprint for this feature?

1. Setting up tables transactions, and checkout items

a. pre-req: database structure being finalized OpenSourceFellows/amplify#32. Heroku
b. transactions as a balance, id matches checkout items

type refers to:

c. checkout items table

d. API set up in Heroku and routed in index file

2. Input from frontend

GET checkout info via unit price and campaign_id
unit price is 3$ (letter), 30$ (sticker), $45 (button)

3. Routed to payment method via Checkout button

4. Store transaction data into table

Mirroring balancing object


Questions to explore:

1. setting up webhook in stripe to create line item
   2.using API to get details of balance object

6. Send message button creates lob object #59

check success_url string to determine if this button is highlighted

7. Restrict send message if payment unsuccessful

Use show and hide method for send message button

8. Show a success page

TLDR: Heroku is not deploying to ally.guide for frontend

In Heroku we're seeing the following error:

At first in package.json main was not in the correct directory, it now is but even though a new build is refreshed with each install

Let @manishapriya know if you have access issues with Heroku

What we're hoping to establish in March

• instantiate Vue app @BeeXiong perhaps use this template with vue and express?
• Create heroku variables @manishapriya94
• Create accounts and set up billing @manishapriya94
• Postgres (priority 1)
• Google Civic API @BeeXiong
• Auth0 @BeeXiong (priority 2)
• Twilio @BeeXiong (priority 3
• Lob API (priority 4) @BeeXiong
• Create wiki for API functions @manishapriya94

Heroku environment variables for each

RESOURCES

AIRTABLE

• API Docs
• Reference app code in Give
• Campaigns table in Airtable to reference
• Information to be consumed
  • Picture of org
  • Name of campaign
  • Cause
  • State
  • Number of letters
  • Summary
  • org website link

GOOGLE CIVIC API

• API Docs
• Reference app code in elevate
• Information to be consumed
  • Rep name
  • Office division
  • address
  • social media
  • picture

LOB API

• API Docs
• Information to be consumed
  • template ID

Hi! Are you new?

Current Issues:
Find our weekly discussions here

Resources:

• Overall Project Board
• FrontEnd Project Board
• Feature Breakdown

Some Definitions:

• labels: team function (APIs, database, infrastructure) and status (planning, to do, working, reviewing, stuck)

User campaign id to send frontend information on which template_id to display

Implementation

1. In campaign.js use campaigns API to match template_id to campaign id
2. Frontend will use a GET function when representative is selected

Hi @teakopp - Got an issue with the Auth0 environmental variables when deploying I believe.

Getting this error message from the logs ⬇️

Seems to be the same variable for when you had me create the .env file locally and added in...

ISSUER_BASE_URL=https://YOUR_DOMAIN
CLIENT_ID=YOUR_CLIENT_ID
BASE_URL=https://YOUR_APPLICATION_ROOT_URL
SECRET=LONG_RANDOM_VALUE

Would the fix be to add these as Heroku Config Environment Variables? 🤔

Issue: callback needs to have a URL that takes the user back to the campaign page they were on before hitting login, currently it takes the user to home

does it have to do with specifying the url path?

BACKGRUOND:

• backend needs to have those postal codes cached to the user_volunteer table
• frontend checks the token to see if user signed in to see what to display

logged in screen:

need to log in screen:

Creating the URL to direct users to when checking session authentication prior to sending letter. Referencing Rules Layer #19

• adding to .env
• secret variable in heroku

Referencing the Auth0 basic Setup

We have the following setup in Heroku
to be referenced in further routing of the user
https://git.heroku.com/murmuring-headland-63935.git

Part of verify address

Can't access ally.guide or any of the API links. Receiving the following error.

Short Description*

Integrating Lob to create mail sending capability for Amplify
https://user-images.githubusercontent.com/9143339/105809192-3cc19a80-5f77-11eb-8bb0-e8c0e8c4e059.mov

Priority 1

Describe the solution you'd like

• First, set up variable in Heroku as secret
• Route and authenticate in vue, doesn't support Vue - do we do it in Node?

Priority 2

• Format everything into letter object(it will triage based off the variables, will we want to default the dates)

Priority 3

• Business Logic:
• Configure Inputs
  • Addresses: user, representative
  • User name from signature
  • Email template ID (which corresponds to the Breathe Act, etc)

Priority 4

• What Lob API Processes (API docs here)
  • verifies address
  • Matches html templates

Questions to explore

• Putting a limit per address to throttle spam/cost
• How to store email addresses

• Things to figure out
  • Do we want to show letter tracking
  • Are we storing additional info via PostGres?

Features needed for each milestone (project board linked)

1. MVP: Pilot letter parties with SoapBox, AAAJ, and the Breathe Act (starting mid April 2021)

• Architecture SetUp
• Create custom landing for each org
• Send message to letter function
• Dashboard for organization

2. MVP+ Campaign Sponsors launched, scale 10 organizations. (August 2021)

• Cause focused design refresh
• Campaign Sponsors
• Refined Dashboard for SetUp

3. Alpha: Public facing site launched, scale 25 organizations. (November 2021)

• Make project open source
• Text based functionality

Should we revise the volunteers database schema to break down name and physical_address columns into more granular bits? I followed what I saw in the Notion Product Log but now I've noticed that in the current production database (pre-migration), those fields were actually broken down into:

name ➡️ first_name, last_name
physical_address ➡️ street_address (line 1), address_2 (line 2), city, state, zip

I haven't verified but I'm guessing that better aligns with what the Lob API will be expecting us to provide vs. just a large text field like I used? 😅

⚠️ Database migrations must never be revised, so we will need to create a new migration to alter and repopulate these. 👍🏻

Part 1 of Amplify Refresh Ally-Guide/ally-guide-app#98

Adding Lob API to routing:

• 1. Update route page with new mapping of page
  • educate --> learn, donate --> give, elevate --> amplify
• Authentication request in Node
  • Heroku URL: https://murmuring-headland-63935.herokuapp.com/
  • Lob + Node
• Update errors in test (@manishapriya94, @teakopp can we set up time for this?)

Working on

• setting up auth0 @manishapriya9
• User Rules @teakopp
• Appending user_volunteers from Auth0 table @BeeXiong
• Testing

Purpose

• Opting for a passwordless authentication to reduce user login friction while ensuring security standards are met so only US users are contacting US representatives.
• This is done using Auth0 which requires a Twilio instantiation for the sms.

How the user navigates passwordless for Amplify:

Implementation Broken Down

Setting up Auth0 issue here

• Opting for SMS and Embedded Universal login
• Create index page for Auth0 landing
• Add authentication routes to index

Opting for SMS and Embedded Universal login

• Set up Auth0 App
• Set up Twilio
• Configure landing
  

Setting up Twilio

• Added to Heroku
• limited user authentication only from US numbers

Create index page for Auth0 landing

• create frontend file for page
• Add the following embed code
• Route a login page @BeeXiong

Routing to sms authentication

• routes to embedded universal login pag

User Rules @teakopp

The user will be prompted to the sms passwordless if they attempt to send the letter and aren't authenticated. This ensures they can not send a letter unless authenticated

• create auth0.js index file
• checks user token
• redirect to authentication for post

Create auth0.js index file

• route auth page

• create auth.js file

Checks user token

Using passport and auth0

Redirect to authentication for post request

We're dealing with post request instead of get due to the 'send letter button' which is speaking to the Lob API if user is authenticated.
Using the following route customization:

Appending user data

• Data table flow : Once authenticated user sends message, populates user_volunteer with the time stamp of letter_version sent from letters_sent table.
• Justification: storing information outside of authentication will slow down database on Auth0 end
• Exporting: seems there is an extension, @BeeXiong let me know what the id column should be? (user name or phone?

Testing

• It seems we can also use actions for CI/CD of the rules with Auth0?\
• Tests

Use Case:

1. Sending a password protected custom URL (so only users can know based off of nonprofit user list)

• can do this via square and pointing to the url
  • mask url that we're pointing to (loses SEO but we don't want to be indexed in this early stage)
• via traditional htaccess, trade off is less user friendly (have to upload files)

Security Reasons:
To maintain the growth of this platform's performance and the integrity of its users, we'll grow through nonprofit based referrals for users (that way they are only responsible for the costs of their user list).

2. The user would then enter from the standpoint of the campaign:

3. Organization has a login to dashboard for their custom url and metrics

4. Do we want to create member user login now or just cache emails?

• Part of the UserFlow of Custom URL
• Do we want to ask them to save email or login?
• If Login Use Case: Member wants to save their login for easier action?

1. BackEnd creates letters_sent table which has the following pieces of information in database

   • date created
   • delivery date
   • Rep Name
   • campaign template_id

2. FrontEnd sends information on representative and campaign_id

3. BackEnd posts the following

   • from Google Civic API:

     • Representative Name

   • From Lob API
     

     • template_id
     • time created
     • delivery date

Do we happen to have any sort of subsidy from GitHub that would allow us to use GitHub Actions for continuous integration/deployment (to run our tests on each pull request, for example) without incurring any/much cost?

I'm guilty of being unfamiliar with the GitHub Actions pricing model and just using it a lot internally. 😓

I have a ton of experience with GitHub Actions, so if this is a cost-free or cost-effective option for us, I would love to help setup CI and/or CD (if we can -- and want to -- deploy our changes programmatically, that is) for the project.

User flow after #10 : Organizations have their own login

• Creating orgs after our comms team discusses their campaign
• Later, they can receive payments from Sponsors

Data Structure

• Two types of users: orgs and volunteers (volunteers will come mpv+)
• Including all data points from this form
• Plan: Base (only sending letters), Assisted (get analytics)

BackEnd functions:

• Store new user
• Dashboard
  • (Base) Upload campaign
  • (Base) Upload user emails
  • (Assisted Tier) Conversion Analytics
  • (Base) Lob Invoices

Purpose: Shifting from Airtable to Postgres for scalability and best security practices.

DATABASE_URL = API Variable

• 1. Provisioning Postgres on Heroku
• Connect Postgres to Heroku
• Migrating data from Airtable to Postgres
• Populate a postgreSQL database on Heroku

Wanted to highlligh that part of the issue for getting set up seems to be PGAdmin

The fix seems to be if we use the Postgres App to install and might be good to add as an additional step in the guide?

Currently, the package.json lists the project's license as MIT, which is a free and open source license that allows anyone to use, reuse, change, sell (🤔), etc. the contents.

I know the project is currently private, so it's not an urgent issue to attend to, but I'm curious....

1. Are we are planning to make this repository public in the future, such as an open source license would make more sense?
2. If not, should we change the license to something more prohibitive? The SPDX license type (the value we put into the package.json file) suggested for proprietary/closed source software is [confusing, IMHO] UNLICENSED.

⚠️ In the short term, I would also recommend we add a "private": true flag into the package.json to prevent accidental publishing to npm for those of us with local-and-active npm credentials. 😅

Priority 4 from Ally-Guide/ally-guide-app#98

Calling Lob API to create a letter for queuing

• Cache inputs (user address, name, letter template id, rep address)
• add button to send letter in amplify page
• Calling api on saved letter after button click (pass cached inputs)

• Error testing

Future Considerations

• Have user create account?
• Letter tracking (delivery)
• Letter cancellation?

Takeaways from the BackEnd discussion on #6

• What happens to the current airtable?

• Storing orgs

Since we are now storing physical/mailing addresses in multiple database tables, we should probably just make a new database table to hold addresses and reference them from the relevant tables (and load them with records via JOIN operations or an ORM).

This would also allow us to validate the addresses more directly for greater data integrity, e.g. require values for at least one line, a city, a state, and a zip code at the database level.

Not an urgent requirement but something that would probably be wise in the long term.

into user_table