933d5bf68e
Previously when a service had multiple "reply to" entries setup for email or SMS, we would show the one that was selected on all screens [1][2] except the final one, where the notification is actually sent. This fixes that, with the caveat that it will also show for services with only one "reply to" entry (see notes below) - we will look at making this consistent on the previous screens in the next commit. Here's a bit more detail on how this works: - If a service has multiple "reply to" entries, the journey to send a one-off message starts with a screen to select the "sender_id", which is otherwise "None" [3]. - The "sender_id" is subsequently resolved to an actual email / phone number by calling an API [4] and plucking it out of the response JSON. - The email / phone number then get rendered as part of the preview template [5][6]. - Unfortunately the "sender_id" is removed from the session by the time we get to the "view_notification" view [7]. - However, we can get back the equivalent text from the notification JSON, which is set by the API when the notification is created [8], give or take a bit of validation code [9][10]. - But the "reply_to_text" field is also set by the API when the service only has one "reply to" entry, so it will show then as well. We could add look at the number of "reply to" entries for the service, in order to consistently only show it when there is more the one. But it seems more useful to show it on previous screens, since it provides more information than is currently show (esp. for emails). [1]:93226ec5d6/app/main/views/send.py (L441-L442)[2]:93226ec5d6/app/main/views/send.py (L966-L967)[3]:93226ec5d6/app/main/views/send.py (L247)[4]:93226ec5d6/app/main/views/send.py (L1071-L1082)[5]:93226ec5d6/app/templates/views/notifications/notification.html (L80)[6]: https://github.com/alphagov/notifications-utils/blob/master/notifications_utils/jinja_templates/sms_preview_template.jinja2 [7]:93226ec5d6/app/main/views/send.py (L1059)[8]:f8b4c9151c/app/service/send_notification.py (L87-L93)[9]:f8b4c9151c/app/models.py (L653)[10]: https://github.com/alphagov/notifications-utils/blob/master/notifications_utils/recipients.py#L482
notifications-admin
GOV.UK Notify admin application - https://www.notifications.service.gov.uk/
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
1. Install Homebrew
Install Homebrew, a package manager for OSX:
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
2. Make sure you're using correct language versions
Languages needed
Need to install node? Run:
brew install node
2.1. pyenv For Python version management
pyenv is a program to manage and swap between different versions of Python. To install:
brew install pyenv
And then follow the further installation instructions in https://github.com/pyenv/pyenv#installation to configure it.
2.2. n For Node version management
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
3. Install NPM dependencies
npm install
npm rebuild node-sass
4. Install and use virtualenvwrapper (optional)
We suggest using a virtualenv to separate the python dependencies for this project from python dependencies for other projects.
Install virtualenvwrapper:
pip install virtualenvwrapper
Then follow the virtualenvwrapper installation instructions docs to configure virtualenvwrapper for your terminal.
Set up your virtualenv:
mkvirtualenv notifications-admin
If you need to specify a certain version of python you can do this using -p, for example:
mkvirtualenv -p ~/.pyenv/versions/3.6.3/bin/python notifications-admin
Activate your virtualenv:
workon notifications-admin
5. Install Python dependencies
Install dependencies and build the frontend assets:
./scripts/bootstrap.sh
Note: You may need versions of both Python 3 and Python 2 accessible to build the python dependencies. pyenv is great for that, and making both Python versions accessible can be done like so:
pyenv global 3.6.3 2.7.15
6. Create a local environment.sh file
In the root directory of the application, run:
echo "
export NOTIFY_ENVIRONMENT='development'
export FLASK_APP=application.py
export FLASK_DEBUG=1
export WERKZEUG_DEBUG_PIN=off
"> environment.sh
7. AWS credentials
Your aws credentials should be stored in a folder located at ~/.aws. Follow Amazon's instructions for storing them correctly
8. Running the application
In the root directory of the application, run:
./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.
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
npm run watch
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:
