alaveteli icon indicating copy to clipboard operation
alaveteli copied to clipboard

Button to revert status of requests marked for admin attention

Open RichardTaylor opened this issue 10 years ago • 5 comments

If the described state is:

attention_requested

There should be a one click way of reverting the status of the request to what it was before it was flagged for admin attention and marking the status as up to date.

I think this would probably be sensible for or requires_admin or error_message statuses too.

RichardTaylor avatar Aug 08 '14 22:08 RichardTaylor

Also confirmed as a useful feature by the Czech Republic site admin - who asked for 'a clear status that would complete the "case"'.

crowbot avatar Aug 21 '15 07:08 crowbot

+1

Just to explain that what admins have to do here at the moment is review the event history for a request to find out if it was previously set to successful / partially successful / rejected and reset it to that.

This feature would help in many cases of reports for admin attention. It would particularly assist in cases where the report form has been used inappropriately to send us a message rather than really make a report.

A "clear report" link in the email to admins might help, in addition to a button on the admin page.

RichardTaylor avatar Nov 10 '20 14:11 RichardTaylor

This cropped up again with a request today, as well as making it a much faster task for admins, it also would help to prevent the wrong state being chosen in error from the event log

Sally

sallytay avatar Sep 03 '21 12:09 sallytay

+1

RichardTaylor avatar Jun 08 '22 15:06 RichardTaylor

Context

After dealing with a reported request, to reset the state admins need to review the event history to find the previous status, remember it, then go to the edit page for the request to reset this state. It's pretty tedious and occasionally we revert to an incorrect status.

We want a one-click way of reseting this state.

Scope

If a request is in a reported state (attention_requested , requires_admin, error_message), we'll add a new section in the "Actions" grouping on the request's admin page. In it we'll have a label, the button, and an indication of the previous state that the request is going to be put back into.

Doc

Technical Considerations

I think we'll probably need to store the previous state in the params_yaml of the report_request event.

Alternatively, we may be able to use calculated_state. Note how below, the response event is described as successful but then calculated as attention_requested now that the report has been made. It may be that we can essentially do the reverse when reporting a request.

Screenshot 2022-09-14 at 13 59 48

I'm a little less sure on the mechanics of all this, so it's worth exploring the code to see which approach makes more sense conceptually.

Out of Scope

A link in the email of reports was suggested, but that adds extra complexity to the controller handling these, in terms of handling different HTTP verbs, how we present the params in the URL, and giving an indication of what the request is being reset to. What happens to old links if they're clicked but the request is no longer reported? Too much hassle for the value at this stage.

We do want a Reportable in future (https://github.com/mysociety/alaveteli/issues/6931), but extracting out all of the report mechanics from InfoRequest is going to be too difficult for the value in this context. If we can make any refactorings that help directly with this issue and also benefit a future Reportable though, we should.

garethrees avatar Sep 14 '22 13:09 garethrees