-
-
Notifications
You must be signed in to change notification settings - Fork 196
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Help users find delivery errors and submit request_email updates #6871
Comments
We can already point people at an advanced search https://www.whatdotheyknow.com/search/latest_status:error_message, so we could write up a doc/pdf to share as suggestions for potential volunteers. #5640 would help this workflow, but for an initial version we could just direct people to use the "Other" option when reporting. |
Perhaps we could get this to the point where the admin team could, in some cases, not research new request addresses in response to bounces but leave it to users, particularly the requester, to propose a new address. Currently the change request form only covers finding a new email address. We should also prompt users to check a body still exists, and if it doesn't prompt us to mark it defunct and check we list any successor. |
I think thats the suggestion in #1782 |
This issue has been automatically closed due to a lack of discussion or resolution for over 12 months. |
Similar to #3522, #5640, #3477.
There should be a place that lists all requests classified as
error_message
("Delivery Error"). Users – whether request author or otherwise – should then be able to submit aPublicBodyChangeRequest
for the associated authority. I'm imagining a workflow akin to the classification game. Perhaps instead of the classification form we render a newPublicBodyChangeRequest
form at the bottom of the request when using this workflow.It would be nice if the submitted change request also included the request URL when generating the admin notification so that it's really quick to approve the change and then navigate to the correspondence to resend it.
The starting point could be #6788 or #6777.
The text was updated successfully, but these errors were encountered: