Chris Hill-Scott b2ba2afbcd List templates in alphabetical order
Currently templates are ordered by the newest created first. This made
sense when, after creating a new template, you were landed on the page
that listed all the templates. In other words, you needed to see
confirmation of the thing that you’ve just done.

Now (since https://github.com/alphagov/notifications-admin/pull/1195)
you get landed on the page for just that template. So you always see
the template you’ve just created, no matter how the list of templates is
ordered. So we are free to change the order of the templates.

Ordering by time created is not great, because it gives users no control
over which templates appear first. For example, our research reported
this from one team:

> One frustration they have is that when you add a new template it
> automatically goes to the top of the list. To get round this, whenever
> they add a new template they delete all of the existing ones and start
> again because they want to keep their templates in numerical order.
> They'd like to be able to control the order of templates in the list.

We _could_ give people some sort of drag-and-drop template ordering
thing. But this feels like overkill. I think that alphabetical order is
better because:

- it’s easily discoverable – anyone who wants to know how a list is
  ordered can quickly tell just by looking at it
- it’s universal – everyone knows how alphabetical ordering works
- it’s familiar – this is how people documents on their computer are
  ordered; there’s no new UI to learn
- it’s what users are doing already – from the same service as above:
  > They number their templates 1,2a, 2b, 3a etc

So this commit changes the ordering from newest created first to
alphabetical.

Previous changes to template order and navigation:
- https://github.com/alphagov/notifications-admin/pull/1163
- https://github.com/alphagov/notifications-admin/pull/1195
- https://github.com/alphagov/notifications-admin/pull/1330

Implementation notes
---

I refactored some of the tests here. I still don’t think they’re great
tests, but they’re a little more Pythonic now at least.

I also added a sort by template type, so that the order is deterministic
when you have, for example, an email template and a text message
template with the same name. If you have two text message templates with
the same name you’re on your own.
2017-11-23 15:11:07 +00:00
2017-11-23 15:11:07 +00:00

Requirements Status Coverage Status

notifications-api

Notifications api Application for the notification api.

Read and write notifications/status queue. Get and update notification status.

Setting Up

AWS credentials

To run the API you will need appropriate AWS credentials. You should receive these from whoever administrates your AWS account. Make sure you've got both an access key id and a secret access key.

Your aws credentials should be stored in a folder located at ~/.aws. Follow Amazon's instructions for storing them correctly.

### Virtualenv

mkvirtualenv -p /usr/local/bin/python3 notifications-api

### environment.sh

Creating the environment.sh file. Replace [unique-to-environment] with your something unique to the environment. Your AWS credentials should be set up for notify-tools (the development/CI AWS account).

Create a local environment.sh file containing the following:

echo "
export SQLALCHEMY_DATABASE_URI='postgresql://localhost/notification_api'
export SECRET_KEY='dev-notify-secret-key'
export DANGEROUS_SALT='dev-notify-salt'
export NOTIFY_ENVIRONMENT='development'
export ADMIN_CLIENT_SECRET='dev-notify-secret-key'
export ADMIN_BASE_URL='http://localhost:6012'
export FROM_NUMBER='development'
export MMG_URL='https://api.mmg.co.uk/json/api.php'
export MMG_API_KEY='MMG_API_KEY'
export LOADTESTING_API_KEY='FIRETEXT_SIMULATION_KEY'
export FIRETEXT_API_KEY='FIRETEXT_ACTUAL_KEY'
export STATSD_PREFIX='YOU_OWN_PREFIX'
export NOTIFICATION_QUEUE_PREFIX='YOUR_OWN_PREFIX'
export REDIS_URL="redis://localhost:6379/0"
"> environment.sh

NOTES:

  • Replace the placeholder key and prefix values as appropriate
  • The SECRET_KEY and DANGEROUS_SALT should match those in the notifications-admin app.
  • The unique prefix for the queue names prevents clashing with others' queues in shared amazon environment and enables filtering by queue name in the SQS interface.

Postgres

Install Postgres.app. You will need admin on your machine to do this.

Redis

To switch redis on you'll need to install it locally. On a OSX we've used brew for this. To use redis caching you need to switch it on by changing the config for development:

    REDIS_ENABLED = True

To run the application

First, run scripts/bootstrap.sh to install dependencies and create the databases.

You need to run the api application and a local celery instance.

There are two run scripts for running all the necessary parts.

scripts/run_app.sh
scripts/run_celery.sh

Optionally you can also run this script to run the scheduled tasks:

scripts/run_celery_beat.sh

To test the application

First, ensure that scripts/bootstrap.sh has been run, as it creates the test database.

Then simply run

make test

That will run pycodestyle for code analysis and our unit test suite. If you wish to run our functional tests, instructions can be found in the notifications-functional-tests repository.

To remove functional test data

NOTE: There is assumption that both the server name prefix and user name prefix are followed by a uuid. The script will search for all services/users with that prefix and only remove it if the prefix is followed by a uuid otherwise it will be skipped.

Locally

python application.py purge_functional_test_data -u <functional tests user name prefix> # Remove the user and associated services.

On the server

python server_commands.py purge_functional_test_data -u <functional tests user name prefix> # Remove the user and associated services.
Description
The API powering Notify.gov
Readme 58 MiB
Languages
Python 98.5%
HCL 0.6%
Jinja 0.5%
Shell 0.3%
Makefile 0.1%