Deleting a message from mailing list archives

[Ethan Jucovy]

Sometimes there's been a need to delete a message from a mailing list
archive, including the sender.

There's no UI for it, but a site admin can do this through the ZMI.
First you have to find (using the URL) the message and delete it from
the list's archive folder. That will kill the message itself and make
links to it return 404. Then to remove it from the list of messages
you also have to remove it from the catalog. That's the object called
ISearchableArchive under the mailing list object -- you have to find
the object's record (again using its URL) in the catalog entries and
remove it. (It looks like just performing a reindex doesn't work.)

To my knowledge this has come up a few times on CoActivate.org and
once or twice on OpenFSM.net. Giving list managers the ability to
delete messages would be nice.

I filed a ticket: http://trac.socialplanning.org/opencore/ticket/2913

Exposing the function with a UI adds a few complications. Threading
could get weird - I haven't tested this to see how it would currently
behave if you delete a message which has replies. (Would the replies
get stranded? Would they have broken links to the parent message? Or
would the thread just rebase itself to the first reply? What if you
delete a message which has both children and a parent?) I've only
ever deleted leaf-node messages.

An alternative approach would be to redact the message's subject, body
and sender. We'd also need to delete any attachments on the message,
since messages often end up with a plaintext copy of the email itself
attached. Redacting would circumvent the threading questions. It
would also mean links don't break which would be more user-friendly
and transparent - instead the user would see "this message has been
deleted by a list manager" (maybe even noting who deleted it, when,
and optionally why?)

I don't know if redacting the sender would cause problems .. if Listen
needs the sender field to be an email address, we could replace it
with the manager who deleted the message, or a dedicated site-wide
address.

If we redact a message which has replies, the replies might leak the
message's content, sender or subject. Maybe the list manager should
have an option to redact "this message and all replies" .. I don't
think we should always assume this is wanted.

If we go with hard deletion, the same reply-leak problem applies.
Again, maybe the list manager should be given the option to delete all
replies.

I think I prefer the redaction approach, mostly the transparency
argument is what tips the balance for me.

Not a very high priority for me, but I wanted to get my thinking down
and see if anyone has reactions or other thoughts.


--
Archive: http://www.coactivate.org/projects/opencore/lists/opencore-dev/archive/2010/10/1287584902172
To unsubscribe send an email with subject "unsubscribe" to opencore-dev-***@public.gmane.org Please contact opencore-dev-manager-81qHHgoATdGNjXQcXLqYpGD2FQJk+8+***@public.gmane.org for questions.

[Robert Marianski]

I've also had this need myself.

Post by Ethan Jucovy
Sometimes there's been a need to delete a message from a mailing list
archive, including the sender.
There's no UI for it, but a site admin can do this through the ZMI.
First you have to find (using the URL) the message and delete it from
the list's archive folder.  That will kill the message itself and make
links to it return 404.  Then to remove it from the list of messages
you also have to remove it from the catalog.  That's the object called
ISearchableArchive under the mailing list object -- you have to find
the object's record (again using its URL) in the catalog entries and
remove it.  (It looks like just performing a reindex doesn't work.)
To my knowledge this has come up a few times on CoActivate.org and
once or twice on OpenFSM.net.  Giving list managers the ability to
delete messages would be nice.
I filed a ticket: http://trac.socialplanning.org/opencore/ticket/2913

...

Yea, this is exactly what I've done in the past too. A ui for this
would be helpful.

Post by Ethan Jucovy
Exposing the function with a UI adds a few complications.  Threading
could get weird - I haven't tested this to see how it would currently
behave if you delete a message which has replies.  (Would the replies
get stranded?  Would they have broken links to the parent message?  Or
would the thread just rebase itself to the first reply?  What if you
delete a message which has both children and a parent?)  I've only
ever deleted leaf-node messages.

I think they would have broken links to the parent message. But I'd be
worried that it might break some view code as well. It might depend on
having the pointer back resolvable without sanity checking, so maybe
the link generation itself could break because the catalog no longer
has that brain. This is all just speculation though, because I haven't
tried it myself :P

If a ui is built for it, there should be some strategy for how to deal
with the responses.

Post by Ethan Jucovy
An alternative approach would be to redact the message's subject, body
and sender.  We'd also need to delete any attachments on the message,
since messages often end up with a plaintext copy of the email itself
attached.  Redacting would circumvent the threading questions.  It
would also mean links don't break which would be more user-friendly
and transparent - instead the user would see "this message has been
deleted by a list manager" (maybe even noting who deleted it, when,
and optionally why?)
I don't know if redacting the sender would cause problems .. if Listen
needs the sender field to be an email address, we could replace it
with the manager who deleted the message, or a dedicated site-wide
address.
If we redact a message which has replies, the replies might leak the
message's content, sender or subject.  Maybe the list manager should
have an option to redact "this message and all replies" .. I don't
think we should always assume this is wanted.
If we go with hard deletion, the same reply-leak problem applies.
Again, maybe the list manager should be given the option to delete all
replies.
I think I prefer the redaction approach, mostly the transparency
argument is what tips the balance for me.
Not a very high priority for me, but I wanted to get my thinking down
and see if anyone has reactions or other thoughts.

...

I'm not sure, but there might still be hidden views exposed that are
edit forms on the messages themselves. It might be possible to use
these existing views and only edit the response to say the message has
been redacted. If this is desired in all cases, maybe it's better to
instead of building a new ui, encourage use of the edit forms.

I could see some cases though where removing the messages themselves
is important, because seeing a response from someone could be a leak.
But with deleting, having a strategy for merging or recursively
removing responses is important.

Just my 2 cents.
Robert


--
Archive: http://www.coactivate.org/projects/opencore/lists/opencore-dev/archive/2010/10/1287766432495
To unsubscribe send an email with subject "unsubscribe" to opencore-***@lists.coactivate.org. Please contact opencore-dev-manager-81qHHgoATdGNjXQcXLqYpCm6D+***@public.gmane.orgg for questions.