e06c1f5daa
The OrganisationAgreementSignedForm class has a bug causing it to render different HTML when the page loads to when you subsequently refresh it. This commit proposes a change to the extend_params function to fix it. extend_params, is used by the OrganisationAgreementSignedForm, as well as all the other WTForms field classes we added to wrap GOVUK Frontend components. Fixing it should therefore fix any similar bugs with them. All of these fields send a dict of configuration data to the GOVUK Frontend component when they call it, at render time. This dict is 'JSON-like', meaning it's values can be all the primitives as well as lists and dicts. This also means it can go quite deep. Extending the default configuration The classes have a default dict of this data kept privately in the params variable. They let you change it by passing in an argument called param_extensions on instantiation, after that, through an attribute of the same name and at render time as the same argument (in templates). The extend_params function The param_extensions dict is used as a collection of changes to make to the default params dict. The changes are applied by the extend_params function. Its code deletes part of the param_extensions, a side effect that didn't seem a problem because it isn't used after the function has run. The bug The bug was only with the part of the HTML that got its data from the part of the param_extensions dict that was deleted by extend_params. The class with the bug set param_extensions when the field is instantiated, as part of its parent form definition. My guess is that param_extensions was stored in memory, as part of the form class, and reused when the page refreshed. At that point, extend_params had deleted part of its data, causing the bug.
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:
