Create move_donation_info_to_another_voter function in donate/controller.py

[DaleMcGrew]

Please create a function in donate/controller.py called "move_donation_info_to_another_voter". Please call this function near the bottom of "voter_merge_two_accounts_for_api" in voter/controllers.py. This function should result in donations and donation history information that are spread across two voters to be merged into a single voter:

• [ ] Update all voter_we_vote_id values in the donation tables: DonateLinkToVoter, DonationFromVoter, DonationLog, and DonationSubscription.

Let's discuss problem cases that might arise.

[SailingSteve]

Sure. I would like to get basic Webhook data flowing first -- at that point all the data in postgres would stay current, including subscription expiration status.

[SailingSteve]

This has been implemented

[DaleMcGrew]

Hi Steve, I took a closer look at "move_donations_between_donors" in donate/models.py and it only seems to be moving entries from the DonationJournal. We need to move/update data from DonateLinkToVoter, DonationFromVoter, DonationLog, and DonationSubscription.

[DaleMcGrew]

Thank you @SailingSteve for your recent check in that finishes cancelling donations and refunding subscriptions. Will you have time to work on this issue next?

[SailingSteve]

Still cleaning up existing code, but I will get to this next.

[SailingSteve]

@DaleMcGrew

• Over the last few weeks, I looked at the pre-existing schema, and thought about what I would need to do to make subscriptions and webhooks work, and in the process I significantly simplified the schema. Hopefully not losing out on any potential capabilities. I left all the pre-existing tables and code in place, while building up the new capabilities. Then when the new table was working and meeting all needs, I pulled out the parts of the older code and tables that weren’t being used.
• The DonationJournal contains every bit of data we need, it has long rows, but you can find anything without a join or a multi-table lookup. By being frugal with column widths, it takes up less disk space than the prior tables.
• The stuff I pulled out:
  • DonateLinkToVoter is still there, but is not read by the code -- I don’t think it ever was.
  • DonationFromVoter is gone.
  • DonationLog is gone, superseded by DonationJournal that has a lot more columns.
  • DonationPlanDefiniton is still there but pretty useless. The ability to donate any arbitrary amount (even before my changes) made the value for persisting the plan very low. If you needed a 12.25 plan, you could just ask Stripe if “monthly-1225” existed and make it on the fly if needed, and then forget about it. As I got into the webhook, I needed to encode the voter_we_vote_id into the plan, so persisting the plans became even less useful. See donations/models.by line 368. The DonationPlanDefiniton code and table are still in place, but could be optimized out.
  • There was a half implemented table for credit cards, but that isn’t the way stripe works, and it is gone.
• The implementation of the webhooks added new requirements on the data, since the transactions from the webhooks didn’t contain subscription_ids (lame from our point of view). And the metadata that I put into stripe transactions like “voter_we_vote_id”, sticks with the one time payments from the UI and subscription setups from the UI, but does not come back with automated payments from subscriptions. So, I prepended the voter_we_vote_id to the donation_plan_id so that I could retrieve the key from webhook transactions.
• The "move_donations_between_donors" that we discussed, was just to move the donations made within a single session when an un-logged in voter makes a donation, then logs in. That is a thin use case, but was all we decided to do. Much more is possible (see Dealing with donations when not logged in).

If this needs more work, I would be happy to do it.

[DaleMcGrew]

Thank you Steve, these changes look great. Feel free to remove the tables/classes that you think we don't need. So you are saying that DonationJournal is the only donation table with voter data? If so we can close this issue.

[SailingSteve]

DonationJournal is the only table we need. DonationPlanDefiniton is still used, but is vestigial. If it were worth it, it could be removed with a few hours of work. Closing for now.