From 7beb025d74e83da6d4237d062efc12736ced391e Mon Sep 17 00:00:00 2001 From: Dave Whiteland Date: Fri, 13 Jun 2014 18:46:24 +0100 Subject: rewrite upgrading --- docs/running/upgrading.md | 47 +++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 39 insertions(+), 8 deletions(-) (limited to 'docs/running') diff --git a/docs/running/upgrading.md b/docs/running/upgrading.md index a3b292cf0..6088d9ab1 100644 --- a/docs/running/upgrading.md +++ b/docs/running/upgrading.md @@ -5,20 +5,48 @@ title: Upgrading Upgrading Alaveteli ==================== -The developer team policy is that the master branch in git should always +

+ Alaveteli is under active development — don't let the + version you're running get too far behind our latest release. This page + describes how to keep your site up-to-date +

+ +## Master branch contains the latest stable release + +The developer team policy is that the `master` branch in git should always contain the latest stable release. Therefore, in production, you should usually -have your software deployed from the master branch, and an upgrade can be -simply `git pull`. +have your software deployed from the `master` branch. + +Upgrading may just require pulling in the latest code -- but it may also require +other changes ("further action"). For this reason, for anything other than a +*patch* (see below), always read the +[`CHANGES.md`](https://github.com/mysociety/alaveteli/blob/master/doc/CHANGES.md) +document **before** doing an uprade. This way you'll be able to prepare for any +other changes that might be needed to make the new code work. + +## How to upgrade the code + +* If you're using Capistrano for deployment, + simply [deploy the code]({{site.baseurl}}docs/installing/deploy/#usage): + set the repo and branch in `deploy.yml` to be the version you want. + We recommend you set this to the explicit branch name (for example, + `0.18`, and not `master`) so there's no risk of you accidentally deploying + a new version before you're aware it's been released. +* otherwise, you can simply upgrade by running `git pull` + +## Patches Patch version increases (e.g. 1.2.3 → 1.2.**4**) should not require any further action on your part. +## Minor version increases + Minor version increases (e.g. 1.2.4 → 1.**3**.0) will usually require further -action. You should read the [`CHANGES.md`](https://github.com/mysociety/alaveteli/blob/master/doc/CHANGES.md) document to see what's changed since -your last deployment, paying special attention to anything in the "Upgrade notes" -sections. +action. You should read the [`CHANGES.md`](https://github.com/mysociety/alaveteli/blob/master/doc/CHANGES.md) +document to see what's changed since your last deployment, paying special attention +to anything in the "Upgrade notes" sections. -Any upgrade may include new translations strings, i.e. new or altered messages +Any upgrade may include new translations strings, that is, new or altered messages to the user that need translating to your locale. You should visit Transifex and try to get your translation up to 100% on each new release. Failure to do so means that any new words added to the Alaveteli source code will appear in @@ -26,7 +54,10 @@ your website in English by default. If your translations didn't make it to the latest release, you will need to download the updated `app.po` for your locale from Transifex and save it in the `locale/` folder. -Unless you're using Capistrano for deployment, you should always run the script `scripts/rails-post-deploy` after each +## Run the post-deploy script + +Unless you're [using Capistrano for deployment]({{site.baseurl}}docs/installing/deploy/), +you should always run the script `scripts/rails-post-deploy` after each deployment. This runs any database migrations for you, plus various other things that can be automated for deployment. -- cgit v1.2.3 From 2bc37caf36699133392ba20d91d4f7baa0dbd936 Mon Sep 17 00:00:00 2001 From: Dave Whiteland Date: Fri, 13 Jun 2014 18:46:24 +0100 Subject: rewrite upgrading --- docs/running/upgrading.md | 47 +++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 39 insertions(+), 8 deletions(-) (limited to 'docs/running') diff --git a/docs/running/upgrading.md b/docs/running/upgrading.md index a3b292cf0..6088d9ab1 100644 --- a/docs/running/upgrading.md +++ b/docs/running/upgrading.md @@ -5,20 +5,48 @@ title: Upgrading Upgrading Alaveteli ==================== -The developer team policy is that the master branch in git should always +

+ Alaveteli is under active development — don't let the + version you're running get too far behind our latest release. This page + describes how to keep your site up-to-date +

+ +## Master branch contains the latest stable release + +The developer team policy is that the `master` branch in git should always contain the latest stable release. Therefore, in production, you should usually -have your software deployed from the master branch, and an upgrade can be -simply `git pull`. +have your software deployed from the `master` branch. + +Upgrading may just require pulling in the latest code -- but it may also require +other changes ("further action"). For this reason, for anything other than a +*patch* (see below), always read the +[`CHANGES.md`](https://github.com/mysociety/alaveteli/blob/master/doc/CHANGES.md) +document **before** doing an uprade. This way you'll be able to prepare for any +other changes that might be needed to make the new code work. + +## How to upgrade the code + +* If you're using Capistrano for deployment, + simply [deploy the code]({{site.baseurl}}docs/installing/deploy/#usage): + set the repo and branch in `deploy.yml` to be the version you want. + We recommend you set this to the explicit branch name (for example, + `0.18`, and not `master`) so there's no risk of you accidentally deploying + a new version before you're aware it's been released. +* otherwise, you can simply upgrade by running `git pull` + +## Patches Patch version increases (e.g. 1.2.3 → 1.2.**4**) should not require any further action on your part. +## Minor version increases + Minor version increases (e.g. 1.2.4 → 1.**3**.0) will usually require further -action. You should read the [`CHANGES.md`](https://github.com/mysociety/alaveteli/blob/master/doc/CHANGES.md) document to see what's changed since -your last deployment, paying special attention to anything in the "Upgrade notes" -sections. +action. You should read the [`CHANGES.md`](https://github.com/mysociety/alaveteli/blob/master/doc/CHANGES.md) +document to see what's changed since your last deployment, paying special attention +to anything in the "Upgrade notes" sections. -Any upgrade may include new translations strings, i.e. new or altered messages +Any upgrade may include new translations strings, that is, new or altered messages to the user that need translating to your locale. You should visit Transifex and try to get your translation up to 100% on each new release. Failure to do so means that any new words added to the Alaveteli source code will appear in @@ -26,7 +54,10 @@ your website in English by default. If your translations didn't make it to the latest release, you will need to download the updated `app.po` for your locale from Transifex and save it in the `locale/` folder. -Unless you're using Capistrano for deployment, you should always run the script `scripts/rails-post-deploy` after each +## Run the post-deploy script + +Unless you're [using Capistrano for deployment]({{site.baseurl}}docs/installing/deploy/), +you should always run the script `scripts/rails-post-deploy` after each deployment. This runs any database migrations for you, plus various other things that can be automated for deployment. -- cgit v1.2.3 From 0ca1a6446b8ccd6345227a4ac5c1a31bf90a558b Mon Sep 17 00:00:00 2001 From: Dave Whiteland Date: Tue, 17 Jun 2014 17:28:17 +0200 Subject: rewrite first para to refer to specific release tags It's true it's on master, but unwise to use that in production. Also, it's helpful to link to the releases on github! --- docs/running/upgrading.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'docs/running') diff --git a/docs/running/upgrading.md b/docs/running/upgrading.md index 6088d9ab1..4074e7a14 100644 --- a/docs/running/upgrading.md +++ b/docs/running/upgrading.md @@ -14,8 +14,11 @@ Upgrading Alaveteli ## Master branch contains the latest stable release The developer team policy is that the `master` branch in git should always -contain the latest stable release. Therefore, in production, you should usually -have your software deployed from the `master` branch. +contain the latest stable release -- so you'll be up to date if you pull from +the `master` branch. However, on your production site, +you should know precisely what version you're running, and deploy Alaveteli +from a [*specific* release tag](https://github.com/mysociety/alaveteli/releases). Upgrading may just require pulling in the latest code -- but it may also require other changes ("further action"). For this reason, for anything other than a -- cgit v1.2.3 From d41e59dc1af1880e96a8f13b7efdcc9746aa36d8 Mon Sep 17 00:00:00 2001 From: Gareth Rees Date: Thu, 19 Jun 2014 10:42:00 +0100 Subject: Move Administrator Privileges to Admin Manual Administrator Privileges section has nothing to do with installing, so moved it to the Admin Manual. --- docs/running/admin_manual.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'docs/running') diff --git a/docs/running/admin_manual.md b/docs/running/admin_manual.md index bd3a44855..1e749f845 100644 --- a/docs/running/admin_manual.md +++ b/docs/running/admin_manual.md @@ -297,5 +297,24 @@ hanging the application altogether), so please: * Restrict your use of them to cases that can't otherwise be easily covered. * Keep them as simple and specific as possible. +## Administrator privileges +The administrative interface is at the URL `/admin`. +Only users with the `super` admin level can access the admin interface. Users +create their own accounts in the usual way, and then administrators can give +them `super` privileges. + +There is an emergency user account which can be accessed via +`/admin?emergency=1`, using the credentials `ADMIN_USERNAME` and +`ADMIN_PASSWORD`, which are set in `general.yml`. To bootstrap the +first `super` level accounts, you will need to log in as the emergency +user. You can disable the emergency user account by setting `DISABLE_EMERGENCY_USER` to `true` in `general.yml`. + +Users with the superuser role also have extra privileges in the website +front end, such as being able to categorise any request, being able to view +items that have been hidden from the search, and being presented with "admin" +links next to individual requests and comments in the front end. + +It is possible completely to override the administrator authentication by +setting `SKIP_ADMIN_AUTH` to `true` in `general.yml`. -- cgit v1.2.3 From 301e78b1b8f9b96b51c078b9bc59acc81c9debb8 Mon Sep 17 00:00:00 2001 From: Dave Whiteland Date: Thu, 3 Jul 2014 14:49:29 +0100 Subject: explicit use of 'tag' now when referring to releases --- docs/running/upgrading.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) (limited to 'docs/running') diff --git a/docs/running/upgrading.md b/docs/running/upgrading.md index 611712bf6..2142bfd47 100644 --- a/docs/running/upgrading.md +++ b/docs/running/upgrading.md @@ -7,8 +7,9 @@ Upgrading Alaveteli

Alaveteli is under active development — don't let the - version you're running get too far behind our latest release. This page - describes how to keep your site up-to-date + version you're running get too far behind our latest + release. + This page describes how to keep your site up-to-date

## Master branch contains the latest stable release @@ -16,9 +17,10 @@ Upgrading Alaveteli The developer team policy is that the `master` branch in git should always contain the latest stable release -- so you'll be up to date if you pull from the `master` branch. However, on your -production site, -you should know precisely what version you're running, and deploy Alaveteli -from a [*specific* release tag](https://github.com/mysociety/alaveteli/releases). +production +site, you should know precisely what version you're running, and deploy +Alaveteli from a [*specific* release +tag](https://github.com/mysociety/alaveteli/releases). Upgrading may just require pulling in the latest code -- but it may also require other changes ("further action"). For this reason, for anything other than a @@ -32,7 +34,7 @@ other changes that might be needed to make the new code work. * If you're using Capistrano for deployment, simply [deploy the code]({{site.baseurl}}docs/installing/deploy/#usage): set the repo and branch in `deploy.yml` to be the version you want. - We recommend you set this to the explicit branch name (for example, + We recommend you set this to the explicit tag name (for example, `0.18`, and not `master`) so there's no risk of you accidentally deploying a new version before you're aware it's been released. * otherwise, you can simply upgrade by running `git pull` -- cgit v1.2.3