eb3f9aad2a
At the moment, the process for accepting the data sharing and financial agreement is: 1. download a pdf * print it out * get someone to sign it * scan it * email it back to us * we rename the file and save it in Google Drive * we then update the organisation to say the MOU is signed * sometimes we also: * print it out and get it counter-signed * scan it again * email it back to the service Let's not do that any more. When the first service for an organisation that doesn't have the agreement in place is in the process of going live, then they should be able to accept the agreement online as part of the go live flow. This commit adds the pages that let someone do that. Where the checklist shows the agreement as **[not completed]** then they can follow a link where they can download it (as happens now). From here, they should then also be able to provide some info to accept it. The info that we need is: **Version** – because we version the agreements occasionally, we need to know which version they are accepting. It may not be the latest one if they downloaded it a while ago and it took time to be signed off **Who is accepting the agreement** – this will often be someone in the finance team, and not necessarily a team member, so we should let the person either accept as themselves, or on behalf of someone else. If it's on behalf of someone else we need to the name and email address of that person so we have that on record. Obvs if it's them accepting it themselves, we have that already (so we just store their user ID and not their name or email address). We then replay the collected info back in a sort of legally binding kind of way pulling in the organisation name too. The wording we’re using is inspired by what GOV.UK Pay have. Then there’s a big green button they can click to accept the agreement, which stores their user ID and and timestamp.
notifications-admin
GOV.UK Notify admin application.
Features of this application
- Register and manage users
- Create and manage services
- Send batch emails and SMS by uploading a CSV
- Show history of notifications
First-time setup
Brew is a package manager for OSX. The following command installs brew:
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Languages needed
brew install node
NPM 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.
npm install -g n
n lts
npm rebuild node-sass
The app runs within a virtual environment. We use mkvirtualenv for easier working with venvs
pip install virtualenvwrapper
mkvirtualenv -p /usr/local/bin/python3 notifications-admin
Install dependencies and build the frontend assets:
workon notifications-admin
./scripts/bootstrap.sh
Rebuilding 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
npm run watch
Create a local environment.sh file containing the following:
echo "
export NOTIFY_ENVIRONMENT='development'
export FLASK_APP=application.py
export FLASK_DEBUG=1
export WERKZEUG_DEBUG_PIN=off
"> environment.sh
AWS credentials
Your aws credentials should be stored in a folder located at ~/.aws. Follow Amazon's instructions for storing them correctly
Running the application
workon notifications-admin
./scripts/run_app.sh
Then visit localhost:6012
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.
Working with static assets
When running locally static assets are served by Flask at http://localhost:6012/static/…
When running on preview, staging and production there’s a bit more to it:
