aboutsummaryrefslogtreecommitdiffstats
path: root/docs/installing/next_steps.md
diff options
context:
space:
mode:
Diffstat (limited to 'docs/installing/next_steps.md')
-rw-r--r--docs/installing/next_steps.md181
1 files changed, 181 insertions, 0 deletions
diff --git a/docs/installing/next_steps.md b/docs/installing/next_steps.md
new file mode 100644
index 000000000..2b7acbd45
--- /dev/null
+++ b/docs/installing/next_steps.md
@@ -0,0 +1,181 @@
+---
+layout: page
+title: Next Steps
+---
+# Next Steps
+
+<p class="lead">
+ OK, you've installed a copy of Alaveteli, and can see the site in a browser. What next?
+</p>
+
+ * [Create a superuser admin account](#create-a-superuser-admin-account)
+ * [Load sample data](#load-sample-data)
+ * [Test out the request process](#test-out-the-request-process)
+ * [Import Public Authorities](#import-public-authorities)
+ * [Set the amount of time [...] to respond to requests](#set-the-amount-of-time-authorities-will-be-given-to-respond-to-requests)
+ * [Add some public holidays](#add-some-public-holidays)
+ * [Start thinking about customising Alaveteli](#start-thinking-about-customising-alaveteli)
+
+
+## Create a superuser admin account
+
+Alaveteli ships with an
+<a href="{{site.baseurl}}docs/glossary/#emergency" class="glossary__link">emergency user</a>
+that has access to the admin. So when you've just created a new site, you
+should sign up to create your own account, then log into admin as the emergency
+user to promote your new account to be an administrator with
+<a href="{{ site.baseurl }}docs/glossary/#super" class="glossary__link">super</a>
+privilege.
+
+As soon as that's done, disable the emergency user, because you don't need to
+use it any more: you've superseded it with your new admin account.
+
+Alaveteli ships with sample data that includes a dummy admin user called "Joe
+Admin". If the sample data has been loaded into the database (this will depend on
+how you installed), you must revoke Joe's administrator status too, because you
+will be using your own admin account instead.
+
+### Step-by-step:
+
+First, in the browser:
+
+* Go to `/profile/sign_in` and create a user by signing up.
+* Check your email and confirm your account.
+* Go to `/admin?emergency=1`, log in with the username and password you specified in
+ [`ADMIN_USERNAME`]({{site.baseurl}}docs/customising/config/#admin_username)
+ and [`ADMIN_PASSWORD`]({{site.baseurl}}docs/customising/config/#admin_password).
+ You can find these settings in `config/general.yml`.
+* You're now on the Alaveteli admin page.
+* Click on **Users** (in the navigation menu across the top of the page), and
+ click on your name in the list of users. On *that* page, click **Edit**.
+* Change your *Admin level* to "super" and click **Save**.
+* From now on, when you are logged into your Alavateli site, you'll have access
+ to the admin (at `/admin`). Furthermore, you'll see links to admin pages off
+ the main site (which don't appear for regular users).
+
+If your installation has loaded the sample data, there will be a dummy user in
+your database called "Joe Admin" who has admin status too. You should remove
+this status so there's no risk of it being used to access your site admin. You
+can either do this while you're still logged in as the emergency user... or
+else, later, logged in as yourself:
+
+* Go to `/admin/users` or click on **Users** in the navigation menu on any
+ admin page.
+* Find "Joe Admin" in the list of users, and click on the name to see the
+ user details. On *that* page, click **Edit**.
+* Change the *Admin level* from "super" to "none" and click **Save**.
+* Joe Admin no longer has admin status.
+
+Now that your account is a superuser admin, you don't need to allow the
+emergency user access to the admin. On the command line shell, edit
+`/var/www/alaveteli/alaveteli/config/general.yml`:
+
+* It's important that you change the emergency user's password (and, ideally,
+ the username too) from the values Alavateli ships with, because they are
+ public and hence insecure. In `general.yml`, change
+ [`ADMIN_PASSWORD`]({{site.baseurl}}docs/customising/config/#admin_password)
+ (and maybe [`ADMIN_USERNAME`]({{site.baseurl}}docs/customising/config/#admin_username)
+ too) to new, unique values.
+* Additionally, you can totally disable the emergency user. Under normal
+ operation you don't need it, because from now on you'll be using the admin
+ user you've just created.
+ Set [`DISABLE_EMERGENCY_USER`]({{site.baseurl}}docs/customising/config/#disable_emergency_user)
+ to `true`.
+* To apply these changes restart the service as a user with root privileges:
+ `sudo service alaveteli restart`
+
+You can use the same process (logged in as your admin account) to add or remove
+superuser admin status to any users that are subsequently added to your site.
+If you accidentally remove admin privilege from all accounts (try not to do
+this, though!), you can enable the emergency user by editing the `general.yml`
+file and restarting Alaveteli.
+
+## Load sample data
+
+If you want some dummy data to play with, you can try loading the fixtures that
+the test suite uses into your development database. As the `alaveteli` user, do:
+
+ script/load-sample-data
+
+If the sample data has already been loaded into the database, this command won't
+do anything, but will instead <abbr
+title='PG::Error: ERROR: permission denied: "RI_ConstraintTrigger_XXXXXX" is a system trigger'>fail
+with an error</abbr>.
+
+If you have added the sample data, update the Xapian search index afterwards:
+
+ script/update-xapian-index
+
+Remember that the sample data includes a user with admin access to your site.
+You should revoke that status so it cannot be used to access your site --
+follow the steps described in the previous section.
+
+## Test out the request process
+
+* Create a new public authority in the admin interface -- give it a name like
+ "Test authority". Set the request email to an address that you will receive.
+
+* From the main interface of the site, make a request to the new authority.
+
+* You should receive the request email -- try replying to it. Your response
+ email should appear in Alaveteli. Not working? Take a look at our
+ [troubleshooting tips]({{ site.baseurl}}docs/installing/manual_install/#troubleshooting).
+ If that doesn't sort it out, [get in touch]({{ site.baseurl}}community/) on
+ the [developer mailing list](https://groups.google.com/forum/#!forum/alaveteli-dev) or [IRC](http://www.irc.mysociety.org/) for help.
+
+## Import Public Authorities
+
+Alaveteli can import a list of public authorities and their contact email addresses from a CSV file.
+
+Follow the instructions for
+[uploading public authority data]({{ site.baseurl }}docs/running/admin_manual/#creating-changing-and-uploading-public-authority-data).
+
+## Set the amount of time authorities will be given to respond to requests
+
+In most countries that have a Freedom of Information law, authorities
+have a certain number of days in order to respond to requests. Alaveteli
+helps requesters by reminding them when their request is overdue for a
+response according to the law. You can set the number of days an
+authority is given to respond to a request in the
+[`REPLY_LATE_AFTER_DAYS`]({{site.baseurl}}docs/customising/config/#reply_late_after_days),
+[`REPLY_VERY_LATE_AFTER_DAYS`]({{site.baseurl}}docs/customising/config/#reply_very_late_after_days)
+and
+[`SPECIAL_REPLY_VERY_LATE_AFTER_DAYS`]({{site.baseurl}}docs/customising/config/#special_reply_very_late_after_days)
+options in `config/general.yml`. Most laws specify that the days are
+either working days, or calendar days. You can set this using the
+[`WORKING_OR_CALENDAR_DAYS`]({{site.baseurl}}docs/customising/config/#working_or_calendar_days)
+option in `config/general.yml`.
+
+## Add some public holidays
+
+<div class="attention-box info">
+Interface introduced in Alaveteli version 0.21
+</div>
+
+Alaveteli calculates the due dates of requests taking account of the
+<a href="{{ site.baseurl }}docs/glossary/#holiday" class="glossary__link">public holidays</a>
+you enter into the admin interface.
+
+If you have set the
+[`WORKING_OR_CALENDAR_DAYS`]({{site.baseurl}}docs/customising/config/#working_or_calendar_days)
+setting for Alaveteli to `working`, the date when a response to a
+request is officially overdue will be calculated in days that are not
+weekends or public holidays.
+
+If you have set
+[`WORKING_OR_CALENDAR_DAYS`]({{site.baseurl}}docs/customising/config/#working_or_calendar_days)
+to `calendar`, the date will be calculated in calendar days, but if the
+due date falls on a public holiday or weekend day, then the due date is
+considered to be the next week day that isn't a holiday.
+
+To add public holidays, go to the
+<a href="{{ site.baseurl }}docs/glossary/#admin" class="glossary__link">admin interface</a>
+and click on **Holidays**. From here you can either add each day of holiday by
+hand, using the **New Holiday** button, or you can create multiple holidays at
+once using the **Create holidays from suggestions or iCalendar feed** button.
+
+## Start thinking about customising Alaveteli
+
+Check out [our guide]({{ site.baseurl}}docs/customising/).
+
+