alaveteli
alaveteli copied to clipboard
mysociety
Enable admins to resend follow-up correspondence to a different email address
As I understand it currently if a follow-up/reply is sent to an email address other than the main FOI email address for a body it isn't possible for an administrator to resend that reply to another email address.
I suggest giving administrators the option to "resend to the main FOI email address for the public body" in cases where a message was originally sent to an address other than the main FOI email address for the body.
(If an initial message is re-sent after a change in the main FOI email address then the resent message goes to the new address)
Example prompting this feature request:
https://www.whatdotheyknow.com/admin/requests/336869
Another case where the requester has sent an internal review to a no-reply address and received a bounce.
Adding a +1 It would be easier for admins to resend messages to the main FOI address than to respond to bounces on request threads suggesting users send another follow-up and this time select the option to send it to the main FOI email address.
Addressing #1278 might enable us to prevent some of these cases from occurring in the first place.
Adding a +1 to this for an occurrence on WhatDoTheyKnow a few days ago.
User sent a follow up to authority Email bounced Upon investigation, authority had changed the FOI email address. I changed it in admin but couldn't redirect the follow-up message I then had to write to the user asking them to resent their follow up.
This causes more work for the user and harms the UX of using WhatDoTheyKnow.
The added trip-up here is that if a follow-up is copy-pasted and resent, Alaveteli tells the user they have already sent the message.
Just linking to the code to manually do this https://github.com/mysociety/alaveteli/wiki/Resending-Outgoing-Message-followup-to-a-new-email-address.
Feels like this would be fairly low effort to add.
On the UI side we could add some extra form elements to select from either existing contact addresses in the thread, or a manually entered address.
OutgoingMessage#to could accept an optional value, which would be passed in via params if the select/text field was filled in.
There'll probably be a bit of refactoring needed in AdminOutgoingMessageController#resend, but doesn't seem horrendous.
There are two proposals here:
- to allow admins to re-send any message to any email address
- to allow admins to re-send messages sent as replies to addresses other than the public body main FOI address, to the current public body main FOI address.
Option 1 gives admins more options / power, however could it lead to unusual / inappropriate things being done? Option 2 might be safer and more conservative.
A public record should show (without quoting the email address in question) what's occurred on the public thread.
There are two proposals here:
1. to allow admins to re-send any message to any email address 2. to allow admins to re-send messages sent as replies to addresses other than the public body main FOI address, to the current public body main FOI address.Option 1 gives admins more options / power, however could it lead to unusual / inappropriate things being done? Option 2 might be safer and more conservative.
Provided it's not a massive headache for the developers, I think option 1 would be the most helpful, as this could provide an option for requests where we've no other choice but to re-direct to an "unusual" address that we don't normally use for a public body.
I would, naturally, assume that this generated a suitable event in the audit log, so that we can see who did what/where it was sent to.
Edit: To add, the wireframe you've added looks excellent, @garethrees - this would be a very useful feature to have.
Resend logging (on admin UI and frontend UI) is already handled from what I remember, but good point, should confirm that this all works as expected on implementation.
+1 would have used it at https://www.whatdotheyknow.com/request/funds_allocated_to_each_of_the_u#comment-106794 rather than adding an annotation offering the user advice.
+1 Would have been helpful today to assist a user following a bounce message.
