From 68c35ba1d9e705747b9e99d2ba4059760c72ec2c Mon Sep 17 00:00:00 2001 From: Dave Whiteland Date: Fri, 27 Feb 2015 13:55:16 +0000 Subject: add page about admin requests (really: edit metadata) Haven't added this is to the nav menu yet, just to give the dev team a chance to correct any factual howlers, will do so later --- docs/running/requests.md | 208 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 208 insertions(+) create mode 100644 docs/running/requests.md (limited to 'docs/running') diff --git a/docs/running/requests.md b/docs/running/requests.md new file mode 100644 index 000000000..d3733b591 --- /dev/null +++ b/docs/running/requests.md @@ -0,0 +1,208 @@ +--- +layout: page +title: Managing requests +--- + +# Managing Requests + + +

+ 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? + +Every request moves through a series of +states, +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 its state — for example, when a response is received they can +change the state to `successful`, `partially_successful` or `not_held` (if the +authority replied to say they don't have the information requested). + +
+ If a request has been waiting for over three weeks for the original + requester to describe it but has still not been described, Alaveteli + lets anyone classify it. +
+ +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. + + +## 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 +
+ Title + + 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: +
    +
  • normal
    • +
  • + backpage: request can be seen by anyone (by visiting + its URL, for example) but does not appear in lists, or search results +
    • +
  • + requester_only: request only visible to the person who + made the request +
    • +
  • + hidden: request is never shown (except to administrators) +
    • +
+
+
+ Who can respond? + + The Allow new responses from... setting can be one of: +
    +
  • anybody
    • +
  • + authority_only: responses are allowed if they come + from the authority to which the request was sent, or from any domain + from which a a response has already been accepted +
    • +
  • + nobody: no responses are allowed on this request +
    • +
+ Any response from a sender who has been disallowed by this + setting will be rejected (see next entry). +
+ What happens to rejected responses? + + The Handle rejected responses... setting specificies what happens + to responses that are not allowed (see previous entry): +
    +
  • + bounce: responses are sent back to their sender +
    • +
  • + holding pen: responses are put in the + holding pen for an administrator to deal with +
    • +
  • + blackhole: responses are destroyed by being sent to a + black hole +
    • +
+
+ 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 you choose to + allow or forbid annotations and comments on this request. + +
+
+ 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: key:value). +

+ 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. +

+
+ + -- cgit v1.2.3