implement account cancellation #2412
Conversation
|
@Changaco et al. Can we prioritize this one, please? Had some heat on Twitter tonight and don't want to be caught without this if/when people decide to abandon Gittip en masse. It's high-priority to begin with, of course. |
|
I've added some commits, but there's still a lot to do:
|
|
@Changaco Awesome. Thanks for jumping right on it. :-) |
chadwhitacre
changed the title
|
I just rebased this on #2473. |
|
Rebased onto #2474. Prolly starting to be ready for review @Changaco @seanlinsley @ESWAT @ivanmushketyk. |
|
Hashing out details on IRC. |
|
|
|
More IRC. |
|
Rebased on master and reviewed. |
|
TODO:
|
|
The test is failing because there's too little money in the escrow for our public dev marketplace. I've added 100,000 but I guess it still takes 3-5 days to go through? |
|
Nope! Went through. :-) |
Method needed as part of account closing, #2412.
Method needed as part of account closing, #2412.
|
Merged master into this, reviewed previous commits, and added a few more. |
|
Rebased on master. |
|
Current verbiage:
|
Now that the three scripts involved in account cancelation have been moved to (tested) methods on Participant, we're ready to wire up the UI. This commit rebases the original work we did on the UI on top of the separate line of development we ended up pursuing for the Participant methods.
Based on conversation in IRC: https://botbot.me/freenode/gittip/2014-06-06/?msg=15781294&page=1
We're not able to deliver on strong "we delete all your info" promises yet, because we haven't formalized a data retention policy (#397).
|
Rebased on master. |
These were actually using API that went away in #2352, but they're also unused in the simplate anyway.
Conflicts: tests/py/test_close.py
|
Oops. I merged master instead of rebasing. |
|
IIRC rebasing now will automatically drop the merge commit |
|
|
|
Looking at disbursement workflow. |
|
The methods are there and they work, but the catch is that conditions must be met. |
|
For the "Give it to the people I tip" case, they have to have tips set up. They can go do this if they haven't already (though our discovery features suck so that's a drag). For the "Send it to my bank account" case, they have to have a bank account set up. We require participants to be whitelisted before we will send money to their bank account, and that requires admin intervention. We could decide to punt on that in this case but then that opens up a fraud loophole that I don't think we want to open. |
|
In either case we want to block the option and give them instructions if they don't meet the criterion. |
Simple conditionals with instructions in non-available cases. Good enough for now?
|
@Changaco @seanlinsley @pjz @ESWAT @ivanmushketyk Ready for final review and merge! |
implement account cancellation
Implements #54. This takes the three scripts involved in account cancellation--
final-gift, untip, and deactivate--and moves them pretty much unchanged (except for removing the hashbang and print_function import) into methods on the Participant object. It also roughs in a UI.