Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[1/2]: Overhaul of donations module #604

Merged
merged 8 commits into from
Mar 10, 2024

Conversation

sashko9807
Copy link
Member

@sashko9807 sashko9807 commented Mar 2, 2024

  • Create a new table payments, which will hold information to payment itself such as extPaymentIntentId, chargedAmount, amount, billingName, billingEmail etc..
  • Refactored donations table to hold only information regarding the donation itself, such as an amount of payment that was allocated to specific campaign, whether that donation is anonymous, whether there is a wish to that donation.
  • Created two functions in Vault module, which would allow to increment/decrement many vaults in a single query.
  • Adapted existing API endpoints regarding donations, to the new database schema
  • Adapted tests to the new database schema

Motivation and context

Currently two major features are queued:

  • Donation to a whole category
  • Importing donations coming from Benevity

It was discussed among the PM, and dev team, that our current structure is not fit for situations, where funds from one payment can be allocated to more than one campaign.

For this reason a new structure was proposed, which makes the relation between a payment and campaign vaults M:N, with donations table being the "middle-man", connection a payment to campaign vault. Figure below"
donation-overall-structure

To make this happen, the current donations structure, was split into two tables payments and donations, with relation between those tables being 1:N(one payment, can be linked to one or more donations)
new-donation-structure-FINAL

Testing

  1. Tested whether the current donation records, are safely migrated to the new structure.
  2. Tested payment done via Stripe.
  3. Tested payment through affiliateCode
  4. Tested payment through IRIS import

Steps to test

  1. Before migration, save the current donation records(Open prisma studio->Donations -> Select one row initially-> Click on the square to select all rows then CTRL+C) in a file.
  2. Run the migration script
  3. Payments and Donations count should be the exact same
  4. Compare the new payment table, with records saved in step1(e.g. match of extPaymentintentId, billingEmail, chargedAmount etc..)
  5. Compare the new donations table, with the records saved in step1(e.g. donation type, amount, targetvaultId, personId etc..)
  6. Check whether donation via stripe is successfully imported, in the new structure
  7. Check whether donation via IRIS bank import is successfully imported in the new structure.
  8. Check whether donation via affiliateCode, is successfully imported in the new structure.

New endpoints

/donations/payments - Get information just for the made payments

- Payment table will save the information regarding the payment
- Donation table will save information regarding the donation(e.g. campaign, wish etc..)
In future situations, we might need to decrement many vaults at once as well,(e.g. payment refund etc..)

- Added some unit tests to cover vaults updates
-Did some refactoring on commonly used types, as well as test mocks
As the name of the model is used as a type, the acceptednaming convention is to name that type in singular way
Copy link

github-actions bot commented Mar 2, 2024

✅ Tests will run for this PR. Once they succeed it can be merged.

@igoychev igoychev added the run tests Allows running the tests workflows for forked repos label Mar 3, 2024
@github-actions github-actions bot removed the run tests Allows running the tests workflows for forked repos label Mar 3, 2024
Copy link
Contributor

@igoychev igoychev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all looks great to me and only a few minor comments here&there

) RETURNING id
)

SELECT * INTO payment_result FROM payment;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

payment_results looks unused, but seems not a problem

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's used in the statement below, when inserting the id of the inserted payment row, into donations table.

apps/api/src/campaign/campaign.controller.spec.ts Outdated Show resolved Hide resolved
apps/api/src/donations/donations.service.ts Outdated Show resolved Hide resolved
@@ -23,4 +28,49 @@ describe('VaultService', () => {
it('should be defined', () => {
expect(service).toBeDefined()
})

it('decrementManyVaults should throw an error if one vaults returns negative amount', async () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

great addition!

@sashko9807 sashko9807 added the run tests Allows running the tests workflows for forked repos label Mar 4, 2024
@github-actions github-actions bot removed the run tests Allows running the tests workflows for forked repos label Mar 4, 2024
@sashko9807 sashko9807 merged commit 530d9b7 into podkrepi-bg:master Mar 10, 2024
9 of 10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants