Makes uses of the additions to utils in https://github.com/alphagov/notifications-utils/pull/9
This commit strips out a lot of the complex stuff that the views and templates
in this app were doing. There is now a cleaner separation of concerns:
- utils returns the number and type of errors in the csv
- `get_errors_for_csv` helper in this app maps the number and type of errors
onto human-friendly error messages
- the view and template just doing the glueing-together of all the pieces
This is (hopefully) easier to understand, definitely makes the component
parts easier to test in isolation, and makes it easier to give more specific
error messages.
Because this commit’s parent added a few new images, we are now serving at
least a handful of images, therefore a few additional HTTP requests. It’s better
to combine multiple HTTP requests into one for performance reasons (up to a
point).
This commit adds an extra step to the preprocessing of SASS files which takes
any images it finds, base64 encodes them and inlines them into the distributed
CSS files.
It also modifies the content security policy to allow inline images.
This commit extends the existing function to validate each row’s phone number
to also validate that all the required data is present.
It does this using the checking that the `Template` class can do when given
a template and a `dict` of values.
This commit brings in the `Template` util, added here:
https://github.com/alphagov/notifications-utils/pull/1
It also does a fair bit of tidying up, which I’ve unfortunately squashed into
this one massive commit. The main change is moving 404 handling into the
templates dao, so that every view isn’t littered with `try: … except(HTTPError)`.
It also adds new features, in a prototypy sort of way, which are:
- download a prefilled example CSV
- show all the columns for your template on the 'check' page
https://www.pivotaltracker.com/story/show/113448149
This commit adds a query string to assets URLs which is generated from a hash
of the file contents. When asset files are changed they will now be served from
a different URL, which means they wont be loaded from browser cache.
This is similar to how GOV.UK template adds its version number as a querystring
parameter for its assets.
This is mostly copied from Digital Marketplace utils:
https://github.com/alphagov/digitalmarketplace-utils/pull/102
They have it in a shared codebase, we only have one frontend app so don’t need
to do that.
Usage in a template:
``` jinja
{{ asset_fingerprinter.get_url('stylesheets/application.css') }}
```
Output:
```
static/stylesheets/application.css?418e6f4a6cdf1142e45c072ed3e1c90a
```
https://www.pivotaltracker.com/story/show/112786779
> There's an emerging convention on admin apps, to have a red strip atop the
> page, also to have a different colour for preview environment... so let's
> adopt that and see how it feels. Red for prod and gold for preview.
This commit adds config so that:
- yellow locally
- orange on preview and staging
- red on live
It will not actually work until each AWS environment uses the right config, but
can be tested locally by setting the environment variable manually, eg:
`export HEADER_COLOUR='#F47738'`
If the templates page contains text messages and emails then there’s two ways it
could be structured:
- into two sections, all text messages first, then all emails
- emails and text messages interleaved, sorted by date
I think the second one is better. Imagine a situation where you mostly do emails
but have a few text messages. You’d have to scroll past the text messages to get
to your emails. Every time.
I reckon that the most commonly accessed templates will be the most recent ones.
- initial versions kept it out of this class but updated as lots of duplication and errors as config
set up in multiple places and not all picking up credstash.
