Uk/stripe connect

[stveep]

Hoping this gets automatically built for testing - no action needed.

[stveep]

This is ready for review. A Stripe account can be connected to the instance (giving permission to charge customers on its behalf) and associated with an enterprise in the Payment Methods tab on the edit enterprise page. Accounts can be disconnected from the same place, and there is webhook handling to ensure the stripe-enterprise association is removed from the db if users disconnect from the Stripe dashboard.

One problem that I sometimes had locally, though not on staging, is OFN requiring me to log in again after being redirected back from Stripe. I couldn't work out why. After login, it doesn't redirect correctly and the query params are lost, so the Stripe accounts end up being connected but there is no entry in the OFN database. If I go through the process again it works, and the fact that the Stripe accts are already connected doesn't affect it. This could be improved by passing the callback params through when redirecting to the OFN authentication page, or by making an entry in the database before redirecting to stripe which then gets updated (if the stripe callback is received) or deleted/warning if the details are not received.

Send me a slack if you need API keys for testing, or it's quite easy and quick to set up your own account. You can set the callback URL to localhost in the Stripe dashboard for testing the connection flow, and disconnection via OFN, but the webhook for disconnection via Stripe is probably best tested on an actual server.

[oeoeaio]

Hey mate, bit of a problem here - looks like you might have merged in a copy of a stripe-connect branch that had already been rebased. See how there are two copies of most of your commits? Commits e97baca and/or ad934f1 look to be the offenders. If you're going to rebase - you need to remember that your local copy is the single source of truth. Ideally you would keep public copies of feature branches that you are going to be rebasing to a minimum. Any public branches that you do push to will need to be written over whenever you rebase your local branch (rather than merged back into the local copy). This is because git can't tell that the commits in the un-rebased public branch are the same as those in the rebased local branch, so it just includes both copies in the commit history.

[oeoeaio]

I've had a quick go at fixing the commit history - it's in my repository stripe-connect.

From what I can gather, you were merging the public branches back in because you wanted to pick up af67f56, right? Best way to do this on a branch that you're going to be rebasing is to use git cherry-pick af67f56. That way you get the code that you actually want, without all of the baggage of the out-of-date (un-rebased) commit history as you do in a git merge.

[stveep]

Hi sorry about this - must have been something to do with switching between computers to work on and pushing to my repo in the process and/or having to merge master to deploy to staging to test the webhooks. Your repo branch looks correct as far as I can see - thanks for sorting it. Let me know if you still need me to do anything?

[oeoeaio]

No worries! I have done far far worse, trust me. :)

I'll keep playing around today and try to work out what our next steps are...

[oeoeaio]

Superseded by #1468