add ability to deactivate account

[chadwhitacre]

was: "UI to unclaim account"

logout and set claim_time to NULL

[chadwhitacre]

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.

[chadwhitacre]

+0 from @sigmavirus24 via twitter.

[chadwhitacre]

So far the people that have asked for this have really wanted #114 (opt out of receiving tips).

[sigmavirus24]

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.

[chadwhitacre]

@sigmavirus24 Ah, okay. Sorry. Thanks for clarifying.

[sigmavirus24]

No need to be sorry. It's hard to properly explain oneself in 140 characters or less.

[chadwhitacre]

+1 from @daid.

[chadwhitacre]

From @duckinator on #114:

I feel you need the option to at least effectively disable your account. Otherwise, it feels like lock-in, and I don't like that from anyone, no matter how much I like the service.

If you will not add this feature, please disable my account manually. I don't like being signed up for services where I can't disable or remove my account through an automated method, and would not have signed up had I been aware that that option wasn't available.

I apologize if I sound harsh, that's not my intent here. I just strongly object to being unable to disable my account to any extent (the approach here doesn't really count, IMO, but I believe is worth keeping because at least some people -- myself included -- use it).

[chadwhitacre]

@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.

[chadwhitacre]

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.

[duckinator]

@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

[chadwhitacre]

@duckinator Definitely acknowledged.

[chadwhitacre]

+1 from @liori via IRC

[chadwhitacre]

+1 from @headius via Twitter.

[reidrac]

+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.

[clone1018]

+1

[chadwhitacre]

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?

I find a button on/under my profile somewhere, marked out in red with warnings, etc., that says "Deactivate". I click it, and what happens? Looking at it from the outside, I expect that everything is just as it was before I joined in the first place:

• https://www.gittip.com/myusername/ is 404
• https://www.gittip.com/on/twitter/myusername/ sez "Has not joined," etc.

And also:

• my data is purged

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:

• participant entry
• tips
• exchanges
• transfers
• elsewhere entries
• CC/BA details in balanced

First, we can't actually completely purge your info from Balanced (see https://github.com/balanced/balanced-api/issues/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 history.html page. It would be no good for me to look at my history on Gittip one day and see one thing, and the next and see something different. That means we should leave the data in the transfers table. Furthermore, it seems to indicate that we should preserve the old participant_id somehow, because that shows up in history, "$0.25 to foobar." We want to indicate that foobar has deactivated their account (strikethrough, fadeout?), but we want it to still say "foobar" there.

Secondly, I suppose we'd like to keep an audit trail to aid in anti-fraud. We can update the queries over tips to leave out tips to/from deactivated (stub, unclaimed) accounts, but if we want an audit trail, then that means keeping tips and exchanges around in addition to transfers.

So do we leave tips, exchanges, and transfers untouched? This would have the effect that if you ever rejoined Gittip, your giving graph would be reactivated. That always kinda creeps me out about Facebook. An alternative—and I'm not sure it's really better—is to keep that data, but go to pains not to reactivate it on rejoin. Note that we are talking about slowly forgetting this data site-wide (see #397), so perhaps that would make this strategy acceptable?

[chadwhitacre]

Here's what Twitter does:

---

[chadwhitacre]

+1 from @kutf on #823.

[chadwhitacre]

+1 from @jackncoke via Twitter.

[chadwhitacre]

+1 from @mythz via Twitter.

[chadwhitacre]

@mythz' case raises an interesting question: he has received money and has a balance on Gittip. What happens to that balance when he deactivates his account? I guess we give it back to the people it came from? In his case it's simple because he hasn't regifted or withdrawn any of that money, so it'd be easy to give it back. But of course if he had regifted or withdrawn some of that money then it gets more complicated.

[chadwhitacre]

An easy answer would be that the money goes to Gittip. That feels kind of overbearing, though of course the person deactivating their account can withdraw their funds or regift all the money to the participant(s) of their choosing before deactivating their account. I think as long as we include a notice to that effect in the deactivation workflow then this could be acceptable.

Gah. That's gross, though. When someone is deactivating an account with a balance, they are very probably at a low ebb w/r/t Gittip. It'd just be salt rubbed in the wound to then see "And now we're taking your money." :-(

[mythz]

I think the natural solution would be just to refund the money back.

[chadwhitacre]

How about this:

1. If they have a bank account attached, we deposit their remaining balance there. If they don't have a bank account attached then of course they'd have to withdraw the money manually first.
2. Else, if they have gifts set up, we split the balance amongst everyone they give to (but how does the $24 limit play into this?).
3. Else, we split the balance amongst everyone they receive from, according to the ratio of total amounts received from everyone they've received from.

[mythz]

You're probably best to ask for feedback from "gifters" rather than "giftees".

As someone who wants to close their account, I would prefer the money to go back to the "gifter" since I don't want any inconvenience caused to them for having "gifted".

[chadwhitacre]

@mythz Right. Since you don't have a bank account or gifts set up, you'd fall under case 3 above.

[mythz]

Cool, works for me.

[chadwhitacre]

Cool, thanks for the feedback.

[chadwhitacre]

+1 from @azf via Twitter.

[chadwhitacre]

+1 in private email

[mythz]

Umm, I'm still on Gittip: https://www.gittip.com/mythz/ how can I take myself off it?

[sprice]

My gittip account is gittip.com/sprice after joining with GitHub. One day I logged in with twitter and it created the account gittip.com/1b7fa5755568. Now I can't connect my twitter account to my proper gittip account so I'd like to delete the second account (1b7fa5755568).

[chadwhitacre]

+1 from @sugarcreek via support@gittip.com

[chadwhitacre]

+1 from vvvv group via support@.

[chadwhitacre]

+1 from @imelda via support@gittip.com.

[chadwhitacre]

@sprice Sorry for the trouble and the late reply. My hunch is that you got bit by #1433, which we just fixed last night. If you sign into www.gittip.com/sprice using GitHub and then connect your Twitter, that should remove 1b7fa5755568.

[chadwhitacre]

+1 from @kivikakk on Twitter.

[chadwhitacre]

+1 from emendlow in email to support@gittip.com.

[chadwhitacre]

+1 from @astanin on Twitter.

[chadwhitacre]

+1 from @mattt to support@gittip.com.

[chadwhitacre]

+1 from @builtinpgh via private email.

[chadwhitacre]

+1 from @tmcw via support@gittip.com.

[chadwhitacre]

I wrote a script for distributing a balance as a final gift:

https://gist.github.com/whit537/ec82f7d908b530336380

[chadwhitacre]

Per #1170, the procedure I'm following for doing these manually is:

• run untip.py foo to zero out tips to foo
• deal with final balance per user instruction:
  • issue a credit card refund using the Balanced dashboard
  • issue a bank account payout using the Balanced dashboard (or let it run on Thursday?)
  • refund to patrons
  • distribute to tippees, pro-rated, using final-gift.py
• update participants set claimed_time=null where username='foo';
• update participants set username='deactivated-foo', username_lower='deactivated-foo' where username='foo';
• set participants.session_token to null to log the user out

[zwn]

I wrote a script for distributing a balance as a final gift:

https://gist.github.com/whit537/ec82f7d908b530336380

Yay. Making transfers outside of payday? Can we please not do that? I don't know if there are some assumptions in the code about that (I'd bet there are).

[chadwhitacre]

@zwn We regularly do exchanges outside of payday, though this is the first transfer outside of payday iinm. The only manifestation I've noticed to date is that the exchange/transfer is listed on the history page under the prior payday.

If we don't do transfers (and exchanges?) except during payday, then do we need a mechanism to schedule transfers/exchanges for the next payday?

That seems like bad UX to me. I think we should be able to do transfers and exchanges outside of payday, to be able to respond quickly to user support requests. I would agree that we should understand and document and test this functionality more fully.

[zwn]

I think we should be able to do transfers and exchanges outside of payday, to be able to respond quickly to user support requests. I would agree that we should understand and document and test this functionality more fully.

Agreed (emphasis mine).

[chadwhitacre]

+1 from @jmromer via support@gittip.com.

[bruceadams]

+1 from @mgussekloo via support@gittip.com.