Need to handle content owned by deleted users

Traceback (most recent call last):
  File "/opt/karl3/src/karl/karl/errorlog.py", line 11, in middleware
    return app(environ, start_response)
  File "/opt/karl3/eggs/repoze.zodbconn-0.10-py2.5.egg/repoze/zodbconn/connector
.py", line 21, in __call__
    result = self.next_app(environ, start_response)
  File "/opt/karl3/eggs/repoze.retry-0.9.3-py2.5.egg/repoze/retry/__init__.py",
line 86, in __call__
    app_iter = self.application(environ, replace_start_response)
  File "/opt/karl3/eggs/repoze.tm2-1.0a5-py2.5.egg/repoze/tm/__init__.py", line
23, in __call__
    result = self.application(environ, save_status_and_headers)
  File "/opt/karl3/eggs/Paste-1.7.2-py2.5.egg/paste/registry.py", line 350, in _
_call__
    app_iter = self.application(environ, start_response)
  File "/opt/karl3/eggs/repoze.who-1.0.15-py2.5.egg/repoze/who/middleware.py", l
ine 107, in __call__
    app_iter = app(environ, wrapper.wrap_start_response)
  File "/opt/karl3/eggs/repoze.browserid-0.2-py2.5.egg/repoze/browserid/middlewa
re.py", line 92, in __call__
    return self.app(environ, start_response)
  File "/opt/karl3/eggs/repoze.bfg-1.2-py2.5.egg/repoze/bfg/router.py", line 130
, in __call__
    response = view_callable(context, request)
  File "/opt/karl3/eggs/repoze.bfg-1.2-py2.5.egg/repoze/bfg/configuration.py", l
ine 1753, in _secured_view
    return view(context, request)
  File "/opt/karl3/src/karl/karl/content/views/blog.py", line 105, in show_blog_
view
    profile = profiles[entry.creator]
  File "/opt/karl3/eggs/repoze.folder-0.4-py2.5.egg/repoze/folder/__init__.py",
line 89, in __getitem__
    return self.data[name]
KeyError: u'xxxxxxxx'

Is there consensus that Rossi's option #3 is the right track here?

I have an inkling that preserving even an otherwise empty profile with the same ID as the deleted user be potentially too much information leakage, given that profile IDs are most often made from people's names or e-mails.

On Mon, Mar 15, 2010 at 4:23 PM, Tres Seaver <email address hidden> wrote:

> Is there consensus that Rossi's option #3 is the right track here?
>
> I have an inkling that preserving even an otherwise empty profile with
> the same ID as the deleted user be potentially too much information
> leakage, given that profile IDs are most often made from people's names
> or e-mails.
>
>
 That certainly needs to be a consideration. The technical problem becomes,
though, if the profile id changes, then all references to that id need to be
tracked down and changed, effectively turning it into option 2. The
references are *probably* confined to 'creator' and 'modified_by' attributes
of content objects, but there might be other references that aren't
springing to mind. It is certainly riskier from the standpoint of
maintaining referential integrity.

Given these trade offs, I'm not sure that this is a decision I can make
without a bit more discussion and input.

What's the status of this?

I emailed OSI about it this morning, haven't heard back yet. We'll give another day and implement (3) if we can't wrap it up.

--Paul

On May 4, 2010, at 2:32 PM, Chris Rossi wrote:

> What's the status of this?
>
> --
> Need to handle content owned by deleted users
> https://bugs.launchpad.net/bugs/532867
> You received this bug notification because you are a bug assignee.
>
> Status in KARL3: Incomplete
>
> Bug description:
> Currently, users have the option of deleting themselves from Karl. This causes a problem with referential integrity with regards to content that they have authored in Karl, leading to exceptions like the one pasted below in the first comment. In order to preserve the referential integrity of the system we need to choose and implement a policy for what happens to a user's content when a user is deleted from the system. Possible policies include:
>
> 1) Delete any content for which the user is an author.
>
> 2) Transfer ownership of the content to a system user.
>
> 3) Convert the user's profile into a placeholder profile which has been scraped of any personal or identifying information.
>
> Of these, I would probably go with 3. I am going to assign to Paul for steering to determine the policy. Once the policy is determined, it can be assigned to me (or another developer) for implementation.
>
>

I'm going to chicken out and punt again on this, moving it out of this milestone. Primarily, I want the big stuff in m42 to get out of the way. Secondarily, I'd like to stabilize the way we do product backlog -> blueprint -> specs.

Chris has handled this going forward. But this task remains, to go clean up any orphans that are already in there.

Let's move this to the next iteration.

Added evolve script which creates a "Former User" profile, if needed, and assigns all orphaned content to that profile.

fixed