alaveteli
alaveteli copied to clipboard
mysociety
Ability to delete an incoming message but leave an explanation
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
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).
+1 following a pro support case.
Adding "destroy incoming message" for search fu.
This feature request has come up repeatedly on the review agenda as a feature idea; that doesn't make it any more important than other tickets, its just review cases by their nature often involve deletion of material. There's a suggestion it might make dealing with deletions a bit easier. I think the benefits are mainly with transparency.
Admins do currently have to be careful to note the information they want for an annotation eg. the date of the deleted message, before deleting it though, so there is an "easier_admin" element to this .
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 (https://github.com/mysociety/alaveteli/issues/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".
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.