> On Wed, 2009-09-09 at 17:33 -0400, Christopher Vollick wrote: >> On 8-Sep-09, at 11:20 PM, Craig Andrews wrote: >> >> > I've temporarily given up on the language work, as it's just too >> > much for >> > me right now - I'll get back to it when Evan is around. >> > >> > On to my new task: User deletion. >> > >> > When a user is deleted, what exactly should happen? >> > >> >> The ticket for User Deletion is here: http://status.net/trac/ticket/155 >> It has some notes on implementation. >> >> I also did some work on this once when I was trying to learn my way >> around the software. >> I don't know if it's useful or good, but it's here: >> http://gitorious.org/~cvollick/laconica/cvollicks-clone/commits/ >> userDelete >> >> It's behind master because I stopped working on it a while ago. >> All the changes are in one place though. >> >> Also, when I was planning out how to do it I wrote a document so I >> knew what I was doing. >> >> It looked like this: >> Ok... >> So... >> User::delete(); >> >> First, change the nickname to 'deleteduser<ID>'. >> This might be safer if we restricted it so normal people can't change >> their nickname to start with deleteduser. >> >> Then remove all profile info. >> >> Remove all login info. >> >> Delete all notices by that user. >> Perhaps make it an option to delete all content. >> I say that notices that are part of a conversation are not to be >> deleted. >> I may be wrong in that. >> >> Remove their avatar. >> Perhaps make it a Deleted Avatar in place of the default. >> >> Leave this account subscribed to all the people it's subscribed to. >> Unsubscribe everyone from this account. >> Also take the user out of any groups. >> Also, unset the "Autosubscribe" option. >> user.autosubscribe >> >> Notify all subscribers in some way that this user has deleted their >> account. >> Perhaps it could even be in the form of a post of sorts. >> >> Remove all other information attached to their account, like sms >> stuff, twitter stuff, open id stuff, oath stuff, etc. >> confirm_address >> profile_block >> profile_tag >> remember_me >> user_openid >> design >> I've decided to leave the invitations. >> We shouldn't cancel all pending invitations just because the inviter >> left. >> >> Maybe not change the username and put a sort of probation on it so >> that someone else can't just scoop the name. >> Probably make that configurable. >> >> >> > I'm thinking that the >> > user's account/profile is delete, group memberships removed, and all >> > notices he ever made are deleted. However, this breaks >> > conversations from >> > a historical perspective - and that's my concern. >> > >> In my implementation I was going to set it up to have the notice >> deletion be an option. >> I was going to make it so that notices that are in conversations are >> never deleted, though. > > Nice process, Christopher. > > Giving the site's content license a consideration, it may shed some > light on how to approach this. As part of this implementation, we > probably only need to consider deleting notices from a StatusNet > platform that uses (by default) CC 3.0 license. > > When I started to write this reply, I agreed that notices that are part > of a conversation should not be deleted because it made more 'sense'. > > However, in the case of CC 3.0, while anyone has some rights (i.e., > having a copy to share and remix) to a previously published work, the > author of that work has full rights e.g., deleting ones own notice. > Moreover, the author even has rights to keep their notices on the site > (provided there is no conflict with the Terms of Service). > > This is my understanding. > > -Sarven
So are you saying that we *must* have 2 options when a user deletes their account: keep my notices, and delete my notices? Also, I'm curious why the account has to have the username changed, then all of this deletion/changing happen. It seems like we can delete all the notices (Notices::delete(), all the rows in all the other tables (File_to_post::delete() Subscription::delete(), etc), then delete the row from the user table (just like how a SQL cascade would work). If we start a transaction at the start of User::delete, then call all the other delete's, then end the transaction, there's no race condition, and it should be quickier to develop, methinks. ~Craig _______________________________________________ Laconica-dev mailing list [email protected] http://mail.laconi.ca/mailman/listinfo/laconica-dev
