Alaveteli makes it easy for a user to make a request. As an administrator, there are some things about that request you can change once it’s been created.
A request is automatically created when a user submits and (where necessary) confirms it. Alaveteli sends it to the authority responsible and handles any responses. Usually this process runs without needing any intervention from an administrator. But sometimes you’ll want to change some aspect of the request, or the way Alaveteli is handling it.
- What state is the request in?
- Old requests (by default, 6+ months without activity)
- Changing things about a request
- Resending a request or sending a request to a different authority
- Hiding a request
- Deleting a request
What state is the request in?
Every request moves through a series of
indicating its progress. Usually a new request will be in the
waiting_response state until something happens to change that — for
example, a response is received.
However, states can’t always be set automatically, because they require a
decision to be made on what kind of answer the authority provided in the
response. For states like this, Alaveteli invites the original requester to
describe it — for example, when a response is received they can change
the state to
not_held (if the
authority replied to say they don’t have the information requested).
Internally, Alaveteli does not just record the “described state” of a request, but also notices if anything has happened since it was last described and sets its “awaiting description” status appropriately.
Old requests (by default, 6+ months without activity)
If there is no activity on a request for some months (by default six), Alaveteli
automatically changes that request’s Allow new responses from… setting to
authority_only. Any responses will be rejected unless they are from the
authority to which the request was originally made.
If a further number of months pass with no activity, that is, by default, if a
year has passed without any updates, the request’s Allow new responses
from… setting becomes
nobody. All responses to this request will be
rejected. The request is effectively closed.
By default, any rejected responses will be bounced with a message that explains that the request has been closed because it is old, with a suggestion that the sender can email your site’s administrators directly.
You can can stop this behaviour by changing the Allow new responses from…
setting back to
normal at any time. Alternatively, you can change the way
rejected messages are handled (for example, sending such responses to the
holding pen instead of bouncing them) with the request’s Handle rejected
See changing things about a request below for how to change these settings.
You can change the number of months it takes for responses to be restricted, and
then rejected, by changing the
RESTRICT_NEW_RESPONSES_ON_OLD_REQUESTS_AFTER_MONTHS setting in the config.
Changing things about a request
To change any of these settings, go to the admin interface, click on Requests, then click on the title of the request you want to affect. Click the Edit metadata button.
|What you can change||Details|
The title is shown on the request’s page, but is also used
in the URL (the text is changed to lower case, punctuation is removed
and, if necessary, a number is added for disambiguation — this is
called the “slug”).
Note that changing the title changes the URL, because the slug changes — this means any links to the old URL will no longer work, and will return a 404 (file not found) error.
|Who can see it?||
Change the Prominence setting to one of:
|Who can respond?||
The Allow new responses from... setting can be one of:
Any response from a sender who has been disallowed by this setting will be rejected (see next entry).
This setting may change automatically when the request gets old.
|What happens to rejected responses?||
The Handle rejected responses... setting specificies
what happens to responses that are not allowed (see previous entry):
|What state is it in?||
See more about
request states, which can be customised for your installation.
You can force the state of the request by choosing it explicitly. Change the Described state setting.
You may also need to set Awaiting description if, having changed the state, you want the original requester to update the description. For example, if the state depends on the information within the response, and you want the requester to classify it — see What state is the request in? above.
|Are comments allowed?||
The Are comments allowed? setting simply allows you to choose to
allow or forbid annotations and comments on this request.
Note that this won’t hide any annotations that have already been left on the reques — it only prevents users adding new ones.
|Tags (search keywords)||
Enter tags, separated by spaces, that are associated with this request.
A tag can be either a simple keyword, or a key-value pair (use a colon as
the separator, like this:
Tags are used for searching. Users and administators both benefit if you tag requests with useful keywords, because it helps them find specific requests — especially if your site gets busy and there are very many in the database.
Although it’s a little more complex than tags on requests, categories also use tags: see more about tags for a little more information.
Resending a request or sending it to a different authority
If you have corrected the email address for an authority, you can resend an existing request to that authority to the new email address. Alternatively, a user may send a request to the wrong authority. In that situation, you can change the authority on the request and then resend it to the correct authority.
To resend a request, go to the admin interface, click on Requests, then click on the name of the request you want to change. Go to the Outgoing messages heading. Click the chevron next to the first outgoing message, which is the initial request. A panel of information about that message will appear. Click on the Resend button.
To send a request to a different authority, go to the admin interface, click on Requests, then click on the name of the request you want to change. In the Request metadata section, there is a line which shows the authority. Click the move… button next to it. Enter the url_name of the authority that you want to send the request to.
url_namemakes up the last part of the URL for their public page. So, for a request with the
url_name“example_request”, the public page URL will be
Now click the Move request to authority button. You will see a notice at the top of the page telling you that the request has been moved. You can now resend the request as above.
Hiding a request
You can hide an entire request. Typically you do this if it’s not a valid Freedom of Information request (for example, a request for personal information), or if it is vexatious.
Go to the admin interface, click on Requests, then click on the title of the request you want. You can hide it in one of two ways:
Responses to a hidden request will be accepted in the normal way, but because they are added to the request’s page, they too will be hidden.
Hide the request and notify the requester
Scroll down to the Actions section of the request’s admin page. Choose one of the options next to Hide the request and notify the user:
- Not a valid FOI request
- A vexatious request
Choosing one of these will reveal an email form. Customise the text of the email that will be sent to the user, letting them know what you’ve done. When you’re ready, click the Hide request button.
Hide the request without notifying the requester
In the Request metadata section of the request’s admin page, click the Edit metadata button. Change the Prominence value to one of these:
requester_only: only the requester can view the request
hidden: nobody can see the request, except administrators.
backpageas the prominence. The
backpageoption stops the request appearing in lists and searches so that it is effectively only visible to anyone who has its URL — but it does not hide the request.
When you’re ready, click the Save changes button at the bottom of the Edit metadata section. No email will be sent to the requester to notify them of what you’ve done.
Deleting a request
You can delete a request entirely. Typically, you only need to do this if someone has posted private information. If you delete a request, any responses that it has already received will be destroyed as well.
Go to the admin interface, click on Requests, then click on the title of the request you want to delete. Click the Edit metadata button. Click on the red Destroy request entirely button at the bottom of the page.
Responses to a deleted request will be sent to the holding pen.