What happens when a user deletes their account or a project is deleted? about panoptes

[brian-c]

I like the way Reddit handles deleted accounts. The account's comments stay put, but are attributed to "(deleted)".

There's a difference between data an account has contributed and other people depend on (classifications, comments) and data they're working on (projects, workflows, collections/subject sets, subjects). I'd say keep the former (not displaying the original username) and remove the latter.

[camallen]

After chatting with @chrislintott @ttfnrob and @brian-c the following is proposed when a user deletes
their account.

1. Remove their personal information (email) and hash their login name. Replace any display name with an anonymous human readable name for talk, legacy display, etc.
2. Disable any active projects they currently own even if currently active for classifications. We can always transfer ownership and reactivate the project.
3. Do not delete any information that the user contributed as the science for understanding classifications only makes sense in regard to the project and classifying workflows.
   • As long as we aren't storing any personal information across the system there is no need to delete it.

Thoughts?

[parrish]

I'm up for that approach. I think it's a bit weird to leave comments in place with a "deleted user" name, but that's just me.

[chrislintott]

I think the point is it’s very weird if bits of a threaded discussion disappear - especially if the discussion as a whole is useful.

Chris

On 6 Jun 2014, at 15:03, Michael Parrish [email protected] wrote:

I'm up for that approach. I think it's a bit weird to leave comments in place with a "deleted user" name, but that's just me.

—
Reply to this email directly or view it on GitHub.

[camallen]

I should also have mentioned we mark the user account as disabled as well.

[parrish]

I should also have mentioned we mark the user account as disabled as well.

I figured

I think the point is it’s very weird if bits of a threaded discussion disappear - especially if the discussion as a whole is useful.

We currently allow comments to be deleted, so that's not that weird.

I guess a good example of when you'd like to hang onto a deleted users' comments is when a productive/helpful user deletes their account (ala _why or Mark Pilgrim).

[camallen]

@edpaget - i like the Activateable concern for activated_state field and enable!/disable! methods but would prefer to extract the traversable relation proxy to a PORO that accepts a container of instances calling activate!/deactivate on each instance.

I don't think the model should mutate state on it's relations. Instead when disabling a user / usergroup / project we can pass the list of relations to the activation PORO via the controller. We can test the PORO separately and ensure it's being called in integration / controller tests.

Thoughts?

[edpaget]

@camallen can you tell me if the following senario is similar to what you're envisioning?

PATCH /users/2
[
  { "op": "replace", "path": "/users/1/activated_state", "value": "inactive" }
]

users_controller.rb

def update
  # some other stuff happens
  user.disable!
  ActivationProxy.new(user, :collections, :projects, :memberships).disable_each!
end

activation_proxy.rb

class ActivationProxy
  def initialize(instance, *relations)
    @instance = instance
    @relations = relations
  end

  def disable_each
    @relations.each do |r|
    @instance.send(r).each{ |m| m.disable! }
  end
end

Or should it actually be passing each object in the relation to the proxy instead?

[camallen]

Yeah pretty much, perhaps a class method to disable all instances it receives.

users_controller.rb

def update
  # some other stuff happens
  user.disable!
  related_instances_to_disable = user.collections | user.projects | user.memberships
  ActivationProxy.disable_instances!(related_instances_to_disable)
end

activation_proxy.rb

class ActivationProxy

  def self.disable_instances!(instances=[])
    instances.each do |i|
      i.disable!
    end
  end
end

[camallen]

I think we've sorted this one via #39 and #46