-
Notifications
You must be signed in to change notification settings - Fork 308
Conversation
@@ -0,0 +1,5 @@ | |||
BEGIN; | |||
|
|||
ALTER TABLE participant ADD COLUMN braintree_id text NOT NULL DEFAULT ''; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have a braintree_customer_id
field already, is that what you were looking for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, cool. :-)
I'm seeing a handful of cases where an absorbed account has a |
I also see the seven customers that Braintree knows about that we don't. |
, ("/customers/{}".format(customer_id),) | ||
) | ||
|
||
er = ExchangeRoute.insert(p, 'braintree-cc', card_id) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before we do this, we should check whether a route exists for braintree-cc
. If so, the user had updated his card, and we should just leave the participant as is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay.
We want a clean slate with Braintree going forward. We want exactly one Braintree customer per open account. I'm not sure yet about how cards should sync up. |
That's something I can handle next week as cleanup. As of now, we should be focusing on linking whatever |
One case where I see us having two braintree customers for one open account is #3473 (comment). It's safe to delete the 'migrated' customer. |
I'm seeing a number of closed and a few suspicious accounts with a |
I also want to see which cards are |
It would be Bad™ if we started charging users on cards that they had disconnected. Kind of a wtf to even have those in the export from Balanced, or at least not being invalidated at Braintree, if indeed that is what is happening. |
Results using 8c34500 with the import log and the production database:
|
So now for each |
I'm not seeing |
The closest I'm seeing is |
Aren't cards deleted entirely when we call |
status: function() {
return this.get('can_debit') ? 'active' : 'removed';
}.property('can_debit') |
Is |
From #3391 (comment):
|
I just satisfied myself that the SQL in |
🚀 |
👀 |
I'm testing a single sync. Then I'm ready to run it for real! |
Okay! I'm seeing |
Last chance for review ... |
/me waits for Travis on principle ... |
I'm expecting this script to run for 15 or 20 minutes, since there's more network traffic with the additional API and database calls. |
Okay! 🚦 |
Script started. |
|
Hmm, only delete if the card exists? We'll also have to patch up all the other inserts/deletes to not repeat themselves if this wasn't the first record or so. |
@rohitpaulk There was only one sync but a few deletes. Fortunately deletes are easier to work around. |
Script restarted ... |
At the end of this script, |
Down from 26 to 12 so far. :-) |
💇 |
2 left! |
Okaaaaaay, more than 20 minutes. 🕝 |
No more 💳 for |
|
So now a Customers & Payment Methods export from Braintree should have 3,619 records, right? |
Sigh. 3,618. :-/ Oh well, close enough! !m @rohitpaulk |
!m @whit537 |
Closes #3287. Braintree has received data from Balanced. Now we need to knit the customer records in Braintree with our participants table.