In rare cases those running WhatDoTheyKnow decide they need to go beyond merely hiding a message and actually delete the message completely. This occurs in cases of the bulk accidental release of sensitive personal information which we don't want to retain both as we want to reduce the low risk of us accidentally losing it to zero and our continued holding of the information might not be legally justifiable.
Currently deleting a message leaves no trace. This is useful generally eg. in the cases of the deletion of spam or a misdirected message with no relation to any request for information.
As a work-round the message can now be deleted and an annotation added explaining what happened. Ideally we'd record what happened "in the system" to provide a better presentation of the history to users and so that any transparency report / takedown log would accurately reflect the occurrence.
Related: #1005 #2657 #1203 #2658
On 17 Mar 2017 @RichardTaylor wrote:
Just to note #3090 is related, if not a duplicate.
This ticket appears to be focused on transparency of what's happened for someone viewing the request page. #3090 was about recording admin actions, and reasons, and enabling the production of statistics. They are closely connected.
Also note that in the case of spam on a request thread; or the accidental sending of a totally unrelated message, we might want the ability to remove a message and leave no trace. (There's be no harm in a small note, but certainly nothing as prominent as when a substantive message has had to be hidden).
On 20 Sep 2019 @RichardTaylor wrote:
Adding a +1 following a case where this would have been useful.
On 14 September 2022 @garethrees wrote:
We do record a destroy_incoming event so we could include "reason" in the params_yaml.
We could then add destroy_incoming events to the renderable events for a thread, which renders out the reason in
a way that's styled appropriately so that it's clear it's not correspondence. We don't yet show events within the
correspondence feed (#4565).
Alternatively, we could auto-generate a Comment with the "reason" as the body. I guess we'd associate this with the
internal admin user.
The downsides with this approach is that you'd only see that a response has been removed much lower down the
thread, which may make it difficult to understand what's happening until you finally get to the event notice / annotation.
Ideally we wouldn't break the "chain" of correspondence. We'd show that there was a response in a particular place in
the thread, but it's now gone.
When we destroy an IncomingMessage, we also destroy the associated "response" InfoRequestEvent. Ideally we
wouldn't. Ideally we'd keep the "response" event, find that it no longer has an associated IncomingMessage, so
instead looks up the associated deletion event to render out the "reason".
On 14 September 2022 @garethrees wrote:
Could also consider destroying the RawEmail associated with an IncomingMessage, with the aim of this action
clearing any cached text and attachments, but still leaving the correspondence bubble present. We could then use the
IncomingMessage prominence to set the appropriate notice.
On 16 December 2022 @HelenWDTK wrote:
On a related note, we're considering starting to track thread deletions manually to enable these to be added to the
transparency report. If we able to collate the reasons why threads had been deleted, it is likely that such manual
recording would be unnecessary.
On 4 January 2023 @HelenWDTK wrote:
+1 There have been a couple of cases recently where this would have been really useful.
Replaces #2686, deleted in error
On 27 Jul 2015 @RichardTaylor wrote:
In rare cases those running WhatDoTheyKnow decide they need to go beyond merely hiding a message and actually delete the message completely. This occurs in cases of the bulk accidental release of sensitive personal information which we don't want to retain both as we want to reduce the low risk of us accidentally losing it to zero and our continued holding of the information might not be legally justifiable.
Currently deleting a message leaves no trace. This is useful generally eg. in the cases of the deletion of spam or a misdirected message with no relation to any request for information.
As a work-round the message can now be deleted and an annotation added explaining what happened. Ideally we'd record what happened "in the system" to provide a better presentation of the history to users and so that any transparency report / takedown log would accurately reflect the occurrence.
Related: #1005 #2657 #1203 #2658
On 17 Mar 2017 @RichardTaylor wrote: Just to note #3090 is related, if not a duplicate.
This ticket appears to be focused on transparency of what's happened for someone viewing the request page. #3090 was about recording admin actions, and reasons, and enabling the production of statistics. They are closely connected.
Also note that in the case of spam on a request thread; or the accidental sending of a totally unrelated message, we might want the ability to remove a message and leave no trace. (There's be no harm in a small note, but certainly nothing as prominent as when a substantive message has had to be hidden).
On 20 Sep 2019 @RichardTaylor wrote: Adding a +1 following a case where this would have been useful.
On 14 September 2022 @garethrees wrote: We do record a destroy_incoming event so we could include "reason" in the params_yaml.
We could then add destroy_incoming events to the renderable events for a thread, which renders out the reason in a way that's styled appropriately so that it's clear it's not correspondence. We don't yet show events within the correspondence feed (#4565).
Alternatively, we could auto-generate a Comment with the "reason" as the body. I guess we'd associate this with the internal admin user.
The downsides with this approach is that you'd only see that a response has been removed much lower down the thread, which may make it difficult to understand what's happening until you finally get to the event notice / annotation.
Ideally we wouldn't break the "chain" of correspondence. We'd show that there was a response in a particular place in the thread, but it's now gone.
When we destroy an IncomingMessage, we also destroy the associated "response" InfoRequestEvent. Ideally we wouldn't. Ideally we'd keep the "response" event, find that it no longer has an associated IncomingMessage, so instead looks up the associated deletion event to render out the "reason".
On 14 September 2022 @garethrees wrote:
Could also consider destroying the RawEmail associated with an IncomingMessage, with the aim of this action clearing any cached text and attachments, but still leaving the correspondence bubble present. We could then use the IncomingMessage prominence to set the appropriate notice.
On 16 December 2022 @HelenWDTK wrote:
On a related note, we're considering starting to track thread deletions manually to enable these to be added to the transparency report. If we able to collate the reasons why threads had been deleted, it is likely that such manual recording would be unnecessary.
On 4 January 2023 @HelenWDTK wrote:
+1 There have been a couple of cases recently where this would have been really useful.