Rules engine for statuses

The logic on how to automatically classify requests over time is current hard-coded in the [[InfoRequest model|https://github.com/sebbacon/alaveteli/blob/master/app/models/info_request.rb]].

In order to support the different state machines for FOI in different jurisdictions, sooner or later we will probably need a rules engine, rather than trying to define configuration options in code.

One very fexible option is to base it all around search queries:

Alternatively, we could parameterise it, to make it easier and less error-prone (at a cost of some flexibility):

Of course, an option combining the two (simple and advanced) is also possible.

Current states

WhatDoTheyKnow has the following states:

waiting_response: Waiting for the public authority to reply

• The default initial state
• Can't transition here from internal_review

waiting_response_overdue: Waiting for a reply for too long

• Automatic, if today's date is after the request date + holidays + 20 days
• When a user updates / visits an item in this state, thank user and tell them how long they should have to wait
• Alert user by email when something becomes overdue

waiting_response_very_overdue: Waiting for a reply for a very long time

• Automatic, if today's date is after the request date + holidays + (60 days (for schools) or 40 days (everyone else))
• When a user updates / visits something in this state, suggest they might want to complain about it; show things they might want to do
• Alert user by email when this state happens

waiting_clarification: The public authority would like part of the request explained

• Prompt user to write followup
• if a user sends an outgoing message on a request in this state, automatically transitions to {{waiting_response}}
• three days after this state change occurs, send reminder to user to action it (assuming user isn't banned)
• Can't transition here from internal_review

gone_postal: The public authority would like to / has responded by post

• If selected, remind user that in most cases authority should respond by email, and encourage followup.
• Give most recent authority correspondence email address for user to request postal by private email.
• Encourage user to update thread with annotation at later date.

not_held: The public authority does not have the information requested

• Suggest user might want to try a different authority, or complain

rejected: The request was refused by the public authority

• Show page of possible next steps

successful: All of the information requested has been received

• Suggest they add annotations or make a donation

partially_successful: Some of the information requested has been received

• Suggest they make a donation; give ideas what to do next

internal_review: Waiting for the public authority to complete an internal review of their handling of the request

• Tell user they should expect a response within 20 days
• When sends email to authority, adds "Internal review of" to Subject
• Can be transitioned from the followup form

error_message: Received an error message, such as delivery failure.

• Thank user for reporting, and suggest they use a form to give new email address for authority if that was the problem
• Mark as needs admin attention

requires_admin: A strange reponse, required attention by the WhatDoTheyKnow team

• Redirect to form to ask for more information
• Mark as needs admin attention

user_withdrawn: The requester has abandoned this request for some reason

• Prompt user to write message to tell authority

awaiting_description (not really a state but a flag indication that there is no state)