2015-11-20 10:31:28 +00:00
# notifications-admin
2015-11-18 16:32:15 +00:00
2020-05-20 10:52:55 +01:00
GOV.UK Notify admin application - https://www.notifications.service.gov.uk/
2015-11-23 14:37:29 +00:00
2016-03-03 07:41:53 +00:00
- Register and manage users
- Create and manage services
- Send batch emails and SMS by uploading a CSV
2016-02-03 15:18:57 +00:00
- Show history of notifications
Use a Node-based tools for handling assets
…or how to move a bunch of things from a bunch of different places into
`app/static`.
There are three main reasons not to use Flask Assets:
- It had some strange behaviour like only
- It was based on Ruby SASS, which is slower to get new features than libsass,
and meant depending on Ruby, and having the SASS Gem globally installed—so
you’re already out of being a ‘pure’ Python app
- Martyn and I have experience of doing it this way on Marketplace, and we’ve
ironed out the initial rough patches
The specific technologies this introduces, all of which are Node-based:
- Gulp – like a Makefile written in Javascript
- NPM – package management, used for managing Gulp and its related dependencies
- Bower – also package management, and the only way I can think to have
GOV.UK template as a proper dependency
…speaking of which, GOV.UK template is now a dependency. This means it can’t be
modified at all (eg to add a global `#content` wrapper), so every page now
inherits from a template that has this wrapper. But it also means that we have a
clean upgrade path when the template is modified.
Everything else (toolkit, elements) I’ve kept as submodules but moved them to a
more logical place (`app/assets` not `app/assets/stylesheets`, because they
contain more than just SASS/CSS).
2015-12-15 08:20:25 +00:00
2021-02-22 16:56:09 +00:00
## Setting up
Use a Node-based tools for handling assets
…or how to move a bunch of things from a bunch of different places into
`app/static`.
There are three main reasons not to use Flask Assets:
- It had some strange behaviour like only
- It was based on Ruby SASS, which is slower to get new features than libsass,
and meant depending on Ruby, and having the SASS Gem globally installed—so
you’re already out of being a ‘pure’ Python app
- Martyn and I have experience of doing it this way on Marketplace, and we’ve
ironed out the initial rough patches
The specific technologies this introduces, all of which are Node-based:
- Gulp – like a Makefile written in Javascript
- NPM – package management, used for managing Gulp and its related dependencies
- Bower – also package management, and the only way I can think to have
GOV.UK template as a proper dependency
…speaking of which, GOV.UK template is now a dependency. This means it can’t be
modified at all (eg to add a global `#content` wrapper), so every page now
inherits from a template that has this wrapper. But it also means that we have a
clean upgrade path when the template is modified.
Everything else (toolkit, elements) I’ve kept as submodules but moved them to a
more logical place (`app/assets` not `app/assets/stylesheets`, because they
contain more than just SASS/CSS).
2015-12-15 08:20:25 +00:00
2021-02-22 17:12:03 +00:00
### Python version
2020-05-16 16:00:38 -07:00
2021-02-22 17:12:03 +00:00
At the moment we run Python 3.6 in production.
2020-05-16 16:00:38 -07:00
2021-02-22 17:12:03 +00:00
### NPM packages
2020-05-16 16:00:38 -07:00
2017-04-18 14:04:10 +01:00
```shell
2020-05-20 10:52:55 +01:00
brew install node
2017-04-18 14:04:10 +01:00
```
2021-02-22 17:12:03 +00:00
[NPM ](npmjs.org ) is Node's package management tool. `n` is a tool for managing different versions of Node. The following installs `n` and uses the long term support (LTS) version of Node.
2020-05-16 16:00:38 -07:00
```shell
2020-05-20 10:52:55 +01:00
npm install -g n
n lts
2016-01-14 16:26:56 +00:00
```
2016-01-12 13:37:50 +00:00
2021-02-22 17:12:03 +00:00
### `environment.sh`
2020-05-22 09:48:04 +01:00
In the root directory of the application, run:
2016-03-23 14:09:07 +00:00
```
echo "
2016-08-04 18:01:08 +01:00
export NOTIFY_ENVIRONMENT='development'
2017-11-06 13:07:21 +00:00
export FLASK_APP=application.py
2021-02-22 16:54:56 +00:00
export FLASK_ENV=development
2017-11-06 13:07:21 +00:00
export WERKZEUG_DEBUG_PIN=off
2016-03-23 14:09:07 +00:00
"> environment.sh
```
2021-02-22 16:56:09 +00:00
### AWS credentials
2016-08-17 15:59:16 +01:00
2021-02-22 16:44:13 +00:00
To run parts of the app, such as uploading letters, you will need appropriate AWS credentials. See the [Wiki ](https://github.com/alphagov/notifications-manuals/wiki/aws-accounts#how-to-set-up-local-development ) for more details.
2016-03-23 14:09:07 +00:00
2021-02-22 17:12:03 +00:00
## To run the application
2016-02-03 15:18:57 +00:00
```shell
2021-02-22 17:12:03 +00:00
# install dependencies, etc.
make bootstrap
# run the web app
2021-02-22 16:41:30 +00:00
make run-flask
2016-02-03 15:18:57 +00:00
```
2015-11-25 15:29:12 +00:00
2021-02-22 17:12:03 +00:00
Then visit [localhost:6012 ](http://localhost:6012 ).
## To test the application
```
# install dependencies, etc.
make bootstrap
make test
```
2018-07-10 15:16:14 +01:00
## Updating application dependencies
`requirements.txt` file is generated from the `requirements-app.txt` in order to pin
versions of all nested dependencies. If `requirements-app.txt` has been changed (or
we want to update the unpinned nested dependencies) `requirements.txt` should be
regenerated with
```
make freeze-requirements
```
`requirements.txt` should be committed alongside `requirements-app.txt` changes.
2018-12-14 16:25:31 +00:00
2020-05-20 10:52:55 +01:00
## Automatically rebuild the frontend assets
If you want the front end assets to re-compile on changes, leave this running
in a separate terminal from the app
```shell
npm run watch
```
2018-12-21 12:54:19 +00:00
## Working with static assets
2018-12-14 16:25:31 +00:00
2018-12-21 12:54:19 +00:00
When running locally static assets are served by Flask at http://localhost:6012/static/…
2018-12-14 16:25:31 +00:00
When running on preview, staging and production there’ s a bit more to it:
2018-12-21 12:54:19 +00:00
