add ability to deactivate account #54
Comments
|
Also clear payment_method_token and last_bill_result, and set all tips to zero. I guess we should keep entries around in the tips and exchanges tables for accuracy. |
|
+0 from @sigmavirus24 via twitter. |
|
So far the people that have asked for this have really wanted #114 (opt out of receiving tips). |
|
More like +0.5. As a poor student I don't have much money to give to others. My original intent was to lock the account to prevent the possibility of someone else claiming it as mine. I messed up though and have no problem opting out. Hopefully soon I'll have a job in which I can contribute to others. |
|
@sigmavirus24 Ah, okay. Sorry. Thanks for clarifying. |
|
No need to be sorry. It's hard to properly explain oneself in 140 characters or less. |
|
+1 from @daid. |
|
From @duckinator on #114:
|
|
@duckinator Sorry to have locked you in. :-( Reviewing the steps at the top of this ticket, I think we want to handle this differently depending on whether the person has actually given / received money yet. |
|
That is, I'm second-guessing the policy of allowing people to grab a username on Gittip and lock it. It's one thing to say "leave me alone" on one's GitHub (eventually Twitter, Facebook, etc.) proxy page on Gittip. But right now if you "lock" your GitHub account with respect to Gittip, then your username becomes unavailable on Gittip as well. It's frustrating to find people squatting on Twitter accounts, for example. This would be a little different in that you'd have a link out to a GitHub (or other) profile for a username that is taken on Gittip. |
|
@whit537 I don't mind if you need time to figure out how to do this right, as long as it's acknowledged. If you're at least planning to do something about deleting/disabling an account, you're doing better than multiple sites I've had to deal with in the past few months. :P |
|
@duckinator Definitely acknowledged. |
|
+1 from @liori via IRC |
|
+1 from me. Deleting accounts should be included in any MVP. Please add to your "open company" definition no user lock-in :) Thanks for gittip and keep up the good work. |
|
+1 |
|
Okay, let's flesh this out and get a milestone going: https://github.com/zetaweb/www.gittip.com/issues?milestone=31&state=open What's the user story?
We can satisfy (1) and (2) by converting the participant record back to a stub. That's relatively straight-forward. #586 (3) is the tricky part. Here's what all data we have on you:
First, we can't actually completely purge your info from Balanced (see balanced/balanced-api#29). But even for data under our own control, it doesn't seem obviously correct to completely remove all of it. Why not? Well, for one, we want users who have received money from you to have an immutable Secondly, I suppose we'd like to keep an audit trail to aid in anti-fraud. We can update the queries over So do we leave |
|
Here's what Twitter does: |
Inspired by Twitter, I'm going with "deactivate" instead of "delete," because this more accurately reflects what we're actually going to do when they click The Button. We aren't going to actually delete data until further down the road.
This is the test that sent us off to chase down the security hole that was closed in 864b1de.
|
While @dhh isn't speaking directly of Gittip, his writing https://37signals.com/svn/posts/3711-canceling-efax is a crystal clear +1 for this. |
|
+1 from @DeveloperCorey via [email protected] |
|
+1 from @devavratravetkar via [email protected] |
final-gift.py is based on:
https://gist.github.com/whit537/ec82f7d908b530336380
untip.py is based on:
https://gist.github.com/whit537/b876265226c27c258dd0
deactivate-final-rename.py is based on
#54
|
+1 from https://www.gittip.com/rauschma/ via [email protected] |
|
+1 from leeceedee (on Twitter) via [email protected] |
|
+1 from @MarcelGruenauer on Twitter (two). |
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.
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.
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.
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.
|
"Learn more" link leads to https://www.facebook.com/help/224562897555674. |
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.
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.
|
#2412 is merged and deployed. |
|
Opened: June 14, 2012 Almost two years to the day! :-) |
was: "UI to unclaim account"
logout and set claim_time to NULL
The text was updated successfully, but these errors were encountered: