This is what Gunicorn is looking for when it’s running the app.
Renaming this variable to `app` has caused the app to break once
deployed on PaaS.
This commit also renames `app` to `flask_app` to make it clear which
app is wrapping which other app.
Since we version our asset filenames there’s no need for a browser to
ever fetch the same file twice. It should always cache fetch from its
own cache.
The accepted way to effect this behaviour is using the expires header,
which is what this argument to `WhiteNoise` does.
This matches what we tell people, in the README, to put in their local
environment.sh
It doesn’t matter what Jenkins sets this to, as long as it’s not
`'development'`. We think Jenkins isn’t setting it at all (in which
case the value will be `undefined`)
The CDN URLs aren’t in included in the content security policy. So
browsers will refuse to load them.
This commit:
- adds each of the CDN URLs to the
- only prepend URLs in CSS files with `/static/` if we’re running
locally (because the CDN URLs are like `static.example.com` not
`example.com/static`)
`www.notifications.service.gov.uk` domain is:
- not gzipped
The PaaS proxy used to GZip and set headers for anything served from a
path starting with `/static/`:
76dd511a8a/ansible/roles/paas-proxy/templates/admin.conf.j2 (L53-L64)
Anything served from `static.notifications.service.gov.uk` is:
- GZipped
- and as a bonus, cached by Cloudfront where possible (meaning the
requests won’t ever hit our app)
This commit moves to serving static asset from `/static/` to
`static.notifications.service.gov.uk`, to get the above listed benefits.
***
We could do even better by setting long cache expiry headers on the static subdomain (currently they’re only set to cache for 60 seconds). But that’s out of scope for this commit.
this lets us combine the two actions to create "Move to a new folder".
If the user hits enter rather than clicking a button, there is a hidden
submit button that (for now) prevents them from taking any action.
A future commit will try and understand what the user might be doing
based on which fields are populated/selected.
Bumped the notifications-utils version. The `gmt_timezones` function in
this repo and the `utc_string_to_aware_gmt_datetime` in
notifications-utils are the same, so have updated the code to always use
the version in utils.
Since you can now see them when searching you should also be able to
select and move them. Which means that they needed to be included in
the `Form`’s list of possible choices of things to move.
If you have a folder structure like this:
> FA / FB / FC
and you search for ‘FA’, it’s very noisy to see:
> FA / FB
> FA / FB / T1
> FA / FB / T2
> FA / FB / FC
> FA / FB / FC / T3
> …
It’s clearer to just show:
> FA / FB
This also has the benefit of, if you type ‘template’ (for example) you
don’t get every item any more, because it’s only looking at the name of
the thing. It used to look at the entire description, ie:
> A / B / C / Example
> Text message template
Now it only searches on the name:
> A / B / C / *Example*
> Text message template
At the moment live search works by either setting something to hidden
or displayed. When the search term is empty, it sets everything to
visible.
This doesn’t work with folders because some of them should be hidden by
default (the ones not at the current level).
We can account for this special case (empty search term) by removing
the `display` CSS attribute when the search term is empty. This means
that each item’s visibility will be controlled by whatever is set in the
CSS file. Using jQuery Setting a property to `''` removes it.
Things in subfolders need to be in the page so we can search for them.
But the default view should be only the things are the current level.
So we can use CSS to hide items that are below the current level.
So that the live search can filter things, they need to be on the page
when it loads. We want to make search work across folders, so all the
things in subfolders need to be in the page.
They also need the full path appending to them, so that you can tell
which ones are in which folders.
This won’t show items that are in a folder above the one you’re
currently in – my reckon is that when you’re narrowing down by clicking
into a folder that you only want to search for things in that folder.
The Jinja template for the ‘choose templates’ page is now pulling in
data from a lot of diparate places in order to work out what to show. As
we add more logic about what to show (in order to make the live search
work) it’s going to get harder to have all this logic in the Jinja
template.
This commit refactors it back into Python where we have more language
features for managing complex logic.
It’s a bit weird to call this file a model, in that it’s dealing with
some presentational logic, rather than just data. Conceptually it’s more
like a view model[1].
1. https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel
