generosity-market / back_end_poc Goto Github PK

Move email authentication creds from the js file to an env file, then reference those env variables in the js file

To start let’s set this number at 10. Will need to coordinate with client side to add pagination requests or infinite scroll capabilities.

Currently getting a user by their id returns user info, linked causes, donations to other causes, and preferences. This makes the fetch really slow when there is a lot of data. We want to limit it to just user info and preferences. When we do that we need separate endpoints to get the other info in a deferred call

In the UI, the user should be able to provide the current password, and what they want the new password to be. We should take that information, check and make sure the current passwords match. If they do, update the password to the one provided.

Capability to send an email is in place, now we need to create some templates for different activities. Examples: Successful donation, signup, newly created organizations/causes, etc…

This is already in the code (in controllers/donations.js and models/donation.js), just commented out. The DB was migrated before the changes were added. We will need to uncomment and hook up to a new DB to test that is is working correctly.

Currently we have a working model of how to upload a photo to an Amazon S3 bucket for causes. Instead of creating another for users, organizations, etc… let pull this out to a utility function that can be passed the image data and any other data that needs to accompany it. Eg: Name of the bucket to upload to

User should not have to have an account to donate. Currently that field is required. We need to remove the isRequired option.

Set up a microservice or put this logic in the api. Use the blog post https://www.robinwieruch.de/react-express-stripe-payment/

Change the donation route to create a user when donating. Even if that means not using a password to begin

Add these fields into the organizations data tables

Add a field in the database that says fullyFunded, default to false. Don’t return those in the active results sent back to the client side. We will add a search option for that

Let’s create some tests that reinforce the data that is being sent and returned. Used Supertest in the past, maybe go this route again?

Let’s make files for each category of routes. Some examples are Users, Causes, Organizations, Donations, etc…

Boilerplate is already there. Just finish it out. Use the Edit User route as an example. Take advantage of some of the utility functions created to help with the logic.

The route styles are not consistent. Some routes use arrow functions, others do not. Some return errors and data as .json(data), others are like .send({ User: data }). Let’s get these and others on the same code style.

Research email service provider on technical know-how and pricing. To be used for sending thank you emails to donors

If a taxID is sent during cause creation, we need to do a lookup and make sure that org exists and store that orgID in the appropriate field.

Boilerplate is already there. Just finish it out. Use the Edit User route as an example. Take advantage of some of the utility functions created to help with the logic.

In controllers/causes.js, edit the getCauses route to accept a sort parameter such as Recently Created or Nearly Funded

Other possible filters based on cause type:
Community Project, Trip, Adoption, etc...

Currently there are two versions of the fetch to verify the non-profit status of an organization. Let’s settle on one, we can use this both for setting up a new organization as well as looking up the tax id when creating a new cause.