Implement request states

[sebbacon]

As I understand it, the requirement is:

• "internal review" will work as now, but in ATEU is called "confirmatory application".
  • We need to check with Helen that we should call it that; with my random punter hat on, I think this terminology is confusing. Something with the word "appeal" somewhere in it might make sense.
  • A confirmatory application can be made when someone disagrees with the body's response, but also when there's no reply; in this case, 15 days after the request was made. The requester has a further 15 days to make the application. (We might want to set the "very overdue" date to something like 25 days, and the "very overdue" text to tell them they should make the confirmatory application soon; or some other way of alerting the user after 15 days and before 30 days of their window of appeal -- however, this is a "could have"; we have agreed that we'll let a user make a confirmatory application even after 30 days, and leave it to the authority to reject).
  • It was agreed by email with Pam that we might as well duplicate the way it works in WDTK, i.e. send the "confirmatory application" to the original authority for them to refer. In Berlin we had talked about automatically escalating / referring the request to the correct confirmatory authority (Helen said there were 2 or 3 of them IIRC, the correct one depending on the original public body). However, in lieu of getting any of the data about who gets what, it seems reasonable to send confirmatory applications to the original public body, with text saying something like "I'm not happy with the (lack of) response, please refer this request to the relevant Confirmatory Application body".
• Add "appeal to ombudsman" and "appeal to ECJ", which can only happen after an internal review has taken place.
  • For "appeal to ombudsman", the page they see after selecting it should be a help page which includes a link to https://secure.ombudsman.europa.eu/atyourservice/secured/complaintform/;
  • for "appeal to ECJ" it should take them to a different help page telling them to contact AIE's help desk
• Add "referred" state. This is for when one authority refers the user to another. It is a type of "closed" or "finished" state. The user will be directed to a help page that suggests they start a new request.
  • Wording TBC (I am concerned that referred and transferred are quite similar-sounding. The wording presented to the user should be unambiguous)
• Add "transferred" state. There's no special functionality here; when a new authority starts replying to a request, the site moderator will just add them to the list of addresses allowed to respond to it.
  • Wording also TBC

[dcabo]

I've added the 'referred' and 'transferred' states in commit 38f86f096b2f7396bff2bd0a098077378baeb78f. (Had to fix an issue in alaveteli btw.)

For 'referred' I'm redirecting to the unhappy page for now, while we get the content. Re 'transferred' and adding the new mail, I guess that for now we just wait for the next response to arrive and go to the holding pen, but if needed there could be an script running to notify the administrator.

How do we control that the internal reply has been done before allowing appeals to ECJ/Ombudsman?

[sebbacon]

Kersti said in her bugs spreadsheet: "As we had discussed we wanted the following options included:Information received, Incomplete information received, Information Not Held, Unsatisfactory answer (invalid answer), Refusal, Partial Refusal, Administrative Silence (no answer) , Referred (with check box if they state info not held)"

Just to confirm how I understand these map onto the proposal above: / existing workflow statuses:

• Information received == successful
• Not held == not_held
• Unsatisfactory answer == waiting_response (because we don't want to encourage a user to conclude something unsatisfactory, but to keep trying; if they do give up, we have user_withdrawn)
• Partial refusal == partially_successful
• Administrative silence == response_very_overdue
• Referred == new status as above. In our last phone call on the subject it was agreed that we wouldn't also record why it was referred, because Helen said the fact of referral was more important than the reason. However, we could implement this in the back-end by making the InfoRequest transition between two states when there's a tick box (not_held -> referred)

NB "unsatisfactory answer" is a new one to me. Again possible to add in (instead of suggested solution above) but it might be a bad idea because (a) we need to keep the already large list of possible states as small as possible, and (b) might it encourage users to think this is the end of the line?

The latter isn't necessarily the case, just thinking aloud.

[dcabo]

Don't remember hearing about "unsatisfactory answer" neither. I'll clarify tomorrow with Helen.

[dcabo]

After talking to Helen, we plan to add the following states (on top of the referred/transferred already added):

• Request acknowledged (i.e. 'we got the request, working on it')
• Do not hold the information but referred (effectively splitting what now in WDTK is a 'maybe they said who does')
• Partial access (a response was given, but it's redacted)
• Unsatisfactory response (they didn't answer the actual question)

This is in order to get better stats on the performance/compliance of the different public bodies.

@sebbacon: how come there's no 'extended deadline' state in WDTK, when the FOI law supports this? How do you handle the fact that the due date is different?

[sebbacon]

OK, great... comments:

• If you're relying on this for statistics, note that some states are likely to be more reliable than others. Requests that are in final states (e.g. "partial access" or "successful") are likely to get categorised in the end. But intermediate states like "acknowledged" may or may not get marked
• you'll need to be careful with the follow up page to "unsatisfactory response" to make sure they don't think it's finished -- we want them to keep going!
• Re. "extended deadline". I wasn't aware that UK FOI law did allow an extended deadline -- should send an email to the mailing list and ask there (Francis or Tony will know)

[dcabo]

I'll pass the comments on. I have the feeling that whatever goes live initially will need to be tuned afterwards when actual users show up... And I'll ask the list.

[dcabo]

Plus "extended deadline", let's not forget. I'll summarise all the new AskTheEU states next week, since we've been through a few iterations by now.

[dcabo]

This was left undone (years ago), I'm closing it now for clarity, as we pick up some minor improvements.