make a 1.0 payout form

[chadwhitacre]

Closes #3743. Currently this is stubbed out with an "email us" (#3539 (comment)).

[chadwhitacre]

We have 148 ~users with a status_of_1_0_balance of resolved. Anyone who never received money on Gratipay 1.0 (not a tippee in transfers) should also be marked as resolved, as well as anyone whose current balance is solely the result of a credit card charge (though cf. #3675).

[chadwhitacre]

We'll need to add a pending-review status to the status_of_1_0_balance type.

[chadwhitacre]

I think what we want to do is replace status_of_1_0_balance with a 1_0_balance column. The question is, how do we populate that column?

[chadwhitacre]

*ahem*

s/1_0_balance/balance_1_0/g

Python identifiers can't begin with a digit. :)

[chadwhitacre]

We'll still need the status* field to track the payout process per-user.

[chadwhitacre]

Once we have balance_1_0 we can set status_of_1_0_balance to resolved where balance_1_0 = 0.

[chadwhitacre]

balance_1_0 == 0

[chadwhitacre]

balance > 0 and status == 'unresolved'

[chadwhitacre]

balance == 0 and status == 'pending-payout'

[chadwhitacre]

balance > 0 and status == 'pending-approval'

[chadwhitacre]

balance > 0 and status == 'rejected'

[chadwhitacre]

Alright, so what's the definition of a 1.0 balance? Who has a 1.0 balance and who doesn't?

[chadwhitacre]

Anyone who received money on Gratipay before 153 and hasn't withdrawn it has a 1.0 balance. Note that it's possible to have a balance and not have a 1.0 balance, because we charged in advance. I personally have $5.94 on my Gratipay account right now because of the payin minimum, but that's not a 1.0 balance.

[chadwhitacre]

We do have 35 transfers post-Gratipocalypse, mostly from final-gifts but two are take-overs.

[chadwhitacre]

We closed the final-gift loophole in #3454.

[chadwhitacre]

We have 2,808 ~users that received money under Gratipay 1.0:

=> select count(*) from (
    select distinct on (tippee)
           tippee 
      from transfers 
     where "timestamp" < '2015-05-07'
) as _;
┌───────┐
│ count │
├───────┤
│  2808 │
└───────┘
(1 row)

[chadwhitacre]

Those 2,808 may have given their money to someone else on Gratipay. That's what I did: I had a balance of $149.46 on the day of the Gratipocalypse, which I gave to new Teams over the course of the next eight weeks. In the ninth week, we started charging my card to cover my payments.

[chadwhitacre]

I suppose that this has been another loophole: giving one's balance away to new Teams. Strictly speaking, we shouldn't have allowed non-upgraded users to use their balance to fund 2.0 payments. But that's water under the bridge: we're not going to pull the money back that we've paid out to Teams.

[chadwhitacre]

Are we going to continue allowing this loophole? How would we close it?

[chadwhitacre]

Once we have balance_1_0 we could subtract that from balance, either in participants or just during payday.

[chadwhitacre]

Alright, so we should be able to compute balance_1_0 by iterating backwards through payments and transfers for the 2,808 1.0 tippees.

[chadwhitacre]

2,259 of the 1.0 tippees currently have a balance.

[chadwhitacre]

We have 4,721 participants with a balance, which I guess means that 1,913 have a balance because of charging in advance?

[chadwhitacre]

I like the idea of decrementing participants.balance by the amount of balance_1_0.

[chadwhitacre]

We have 219 participants with a 1.0 balance who are also in the payments table.

[chadwhitacre]

I think we just need notifications for rejected and pending-payout. PayPal sends a notification for payouts (cf. #3526).

[chadwhitacre]

[chadwhitacre]

[chadwhitacre]

[chadwhitacre]

Last thing on my plate is to require a PayPal route as part of all this. After that I think I'm ready for review.

[chadwhitacre]

[chadwhitacre]

Alright, ready for review.

[chadwhitacre]

So the plan is to deploy this code, and then run sql/1.0/all.sql to set status_of_1_0_payout properly.

[chadwhitacre]

Alright, let's do this.